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 15:13 +0000 12/5/05, Geoffrey Sisson wrote:
>
> >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.
> 
> I hate dropping into document politics as a backdrop for a technical 
> discussion.  I mean, I just wanted to re-express the original intent 
> because I think the solution is more complicated than it need to be.

Hi Ed,

This was in response to your comment:

> I think it's unwise to design a standard part of the protocol based on
> the data content of the zone.

It was simply to clarify that the methods described in
draft-ietf-dnsext-dns-name-p-s are not part of the NSEC epsilon
protocol, but are implementation details that may be disregarded
without protocol violation.  The NSEC epsilon protocol is defined
solely by draft-ietf-dnsext-dnssec-online-signing.  I'm not sure
how I was invoking document politics by attempting make this
clarification.

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

[snip]

> E.g., in the example you raise, enumeration isn't an issue, so I'd say
> it's a bad example to use in the sense that it isn't a realistic dilemma.

You may prefer this real-life example:

We at Nominet maintain a zone for the sch.uk domain with the following
structure:

$ORIGIN sch.uk.

<school>.<locality> IN NS <nameserver 1>
<school>.<locality> IN NS <nameserver 2>

e.g.:

------------------------ Begin included text ------------------------

. . .

appleton.oxon	IN	NS	ns0.netcentral.co.uk.
appleton.oxon	IN	NS	ns1.netcentral.co.uk.

aston-and-cote	IN	NS	ns0.netcentral.co.uk.
aston-and-cote	IN	NS	ns1.netcentral.co.uk.

. . .

------------------------- End included text -------------------------

For a query with QNAME asbo.oxon.sh.uk., using the modified method
would result in this NSEC RR:

    oxom\255{59}.sch.uk. IN NSEC oxon\000.sch.uk. NSEC RRSIG

The response could then be used to deny the existence of any of the
300+ DNS names in the oxon.sch.uk. domain.  In fact, the existence of
_any_ desired DNS name in .sch.uk could be trivially denied by
generating a suitable QNAME and then replaying the result.

> The essence of my comment is that the attempts to remove 
> enumerability from DNSSEC mean "violating" assumptions made in the 
> decision tree [1] used long ago to arrive at the NXT record.

I think this more a comment on draft-ietf-dnsext-dnssec-online-signing
than on draft-ietf-dnsext-dns-name-p-s (which is a supporting document
for the former).

>                                                            Being an 
> approximation, there will be in accuracies.  The question isn't 
> whether there are, but whether the inaccuracy will cause a problem. 

I hope I've been persuasive that the use of the "modified method" with
some zones will result in unacceptable inaccuracies, which is why it's
not the only one presented.

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