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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 4 Dec 2006 17:29:10 -0800

Seems to me that this discussion consists of endless demands for further particulars followed by the complaint that the answers to those particulars is too long.

NSEC3 is not at all complex by crypto standards. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of bert hubert
> Sent: Monday, December 04, 2006 4:38 PM
> To: David Blacka-CR
> Cc: Mike StJohns; Paul Vixie; [email-masked]
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
> 
> On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote:
> > I feel compelled to point out that NSEC3 isn't that complicated to 
> > actually *do*.  If it is complex, it is complex to analyze. 
>  That is, 
> > it can be hard to convince yourself that it works without a bit of 
> > mental stretching.
> 
> It has a 51 page draft, and it details only *non*-existence.
> 
> I am referring to NSEC3 non-existence proofs. Perhaps I 
> missed something, but messages like:
>  
> "In practice, then, we must show an NSEC3 record that 
> encloses the hash of  x.C, one that encloses the hash of *.C, 
> and any RR owned by C (which could  be an NSEC3, in which 
> case it would be owned by the hash of C). A resolver  
> verifying this proof would have to try longer and longer 
> closest enclosers  to determine which was being demonstrated 
> as C, if an NSEC3 is presented.
>  If any other RR was used, then C would be the owner. Once C 
> has been  determined, the resolver can easily check x.C and 
> *.C against the proof."
> 
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/m
> sg00468.html
> 
> .. look rather like I need to solve for a system of 
> constraints within my software.
> 
> But perhaps this applied to a previous draft, of perhaps I am 
> dense (most likely). The mind boggles however at the failure 
> modes implied by the wording quoted above.
> 
> 	Bert
> 
> -- 
> http://www.PowerDNS.com      Open source, database driven DNS 
> Software 
> http://netherlabs.nl              Open and Closed source services
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 
> 

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 12 Dec 2006 10:51:13 -0800

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. 

> From: Masataka Ohta [mailto:[email-masked]] 
> Sent: Tuesday, December 12, 2006 2:20 AM
> To: Hallam-Baker, Phillip
> Cc: Paul Vixie; Christian Huitema; Ralph Droms; bert hubert; 
> [email-masked]
> 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
> 
> 
>