Re: Last Call: 'Minimally Covering NSEC Records and DNSSEC On-line Signing' to Proposed Standard

[Geoffrey Sisson <[e-mail]>]

Edward Lewis <[e-mail]> wrotes:

> At 10:53 -0500 11/22/05, The IESG wrote:
> >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-name-p-s-01.txt
> 
> #   This document describes two methods:
> #
> #   1.  An ``absolute method'', which returns the immediate predecessor
> #       or successor of a domain name such that no valid DNS name could
> #       exist between that DNS name and the predecessor or successor.
> #
> #   2.  A ``modified method'', which returns a predecessor and successor
> #       which are more economical in size and computation.  This method
> #       is restricted to use with zones consisting exclusively of owner
> #       names that contain no more than one label more than the owner
> #       name of the apex, where the longest possible owner name (i.e. one
> #       with a maximum length left-most label) would not exceed the
> #       maximum DNS name length.  This is, however, the type of zone for
> #       which the technique of online signing is most likely to be used.
> 
> I have two comments to make on this.
> 
> One is that I think it's unwise to design a standard part of the 
> protocol based on the data content of the zone.  I'm referring to the 
> sentiment in the last sentence of the quoted section.  This is not a 
> concrete comment, just a design guideline, and it is less important 
> than my next comment.

Note that -ietf-dnsext-dns-name-p-s has been requested for publication
as Experimental, so it's not part of the protocol.  The described
methods are provided as an aid to implementors and are not normative.

> Keeping in mind that we discourage (or should, I recall talking about 
> this) caches from being used to speak authoritatively about data and 
> the behavior of negative caches, does it really matter if the NSEC 
> contents are "true?"  Especially when what is "true" can change with 
> dynamic update.
> 
> My point here is, perhaps the modified method is all that is needed, 
> regardless of the kind of data in the zone.  Can we get away with one 
> approximately good method instead of having to define two exacting 
> methods?  Can't we simplify this?

The "modified method" would be quite broken for some types of zones,
e.g. ones with lots of deeply-nested empty non-terminals.  For example:

    $ORIGIN 5.6.8.1.4.4.e164.arpa.

    1.1.2.2.3.3 IN NAPTR <blah>

    9.9.2.2.3.3 IN NAPTR <blah>

    . . .

When using the modified method, a query with a QNAME of
4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa. would produce this response:

    2\255{62}.5.6.8.1.4.4.e164.arpa. IN NSEC 3\000.5.6.8.1.4.4.e164.arpa. ...

This would potentially deny the existence of quite a few existing DNS
names, substantially increasing it's utility for replay attacks.

Geoff

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