RE: DNSSEC - Signature Only vs the MX/A issue.

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Don't say that you are agreeing with someone when you are intentionally misinterpreting what they said to claim the opposite.

This conversation is closed. 

> -----Original Message-----
> From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] 
> Sent: Tuesday, December 12, 2006 2:20 AM
> To: Hallam-Baker, Phillip
> Cc: Paul Vixie; Christian Huitema; Ralph Droms; bert hubert; 
> namedroppers@ops.ietf.org
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
> 
> Hallam-Baker, Phillip wrote:
> 
> > AS I have been saying for over a decade security is risk 
> management, 
> > not risk elimination.
> 
> I fully agree with you that there ain't no such thing as 
> cryptographical security.
> 
> > The point you make is not new, Bruce Scheneir made it together with 
> > Carl Ellison in a paper some years back. He was wrong then 
> and Secrets 
> > and Lies is essentially explaining why.
> 
> Hugh?
> 
> You failed to deny my point that DNSSEC and plain DNS are 
> equally secure.
> 
> > Most cases of administrative incompetence will result in a complete 
> > loss of service. DNSSEC does not add a significant number 
> of new ways 
> > to screw up and the remedy is exactly the same.
> 
> Complex protocols are more complex to implement and operate 
> and, thus, insecure.
> 
> For example, it is a lot more likely that DNSSEC software has 
> buffer overflow valunerability than plain DNS software.
> 
> > The cases where administrative incompetence leads to a 
> security breach 
> > are not as likely as direct attack and in any case very 
> difficult to 
> > exploit successfully without inside knowledge that allows for more 
> > powerful attacks.
> 
> I'm not sure what you mean "direct attack" but I understand 
> that you failed to make a point on the merits of deploying DNSSEC.
> 
> 						Masataka Ohta
> 
> 
> 

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>