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