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

[Ben Laurie <ben@algroup.co.uk>]

bert hubert wrote:
> 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/msg00468.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.

I don't see why. All its saying, admittedly at great length, is that you
have to determine the closest encloser.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
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/>