Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18

[S Moonesamy <[e-mail]>]

Hi Andrew,
At 19:30 18-06-2012, Andrew Sullivan wrote:
>To whom would it be confusing?  The draft is indeed aimed at
>implementers of DNSSEC (that is, people putting signing and validation
>into code), and not at users of DNSSEC.  I'm also not sure about which
>places are not clear about what they're changing.  Some things are
>simply facts that have become clear about the way the protocol works,
>but places where the actual text of the original documents is either
>added to or altered are, as far as I know, marked.  Could you give an
>example of things you think aren't clear as to what they have changed?

I mentioned "implementers who are fully conversant with the ins and 
outs of DNSSEC".  There are people implementing code using DNSSEC 
signing and/or validation who are will be using the DNSSEC document 
set.  The text in the draft does not mention that it is aimed at, for 
example, BIND, Unbound and Powerdns implementers only.

In the review posted at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05954.html 
I mentioned three parts of the draft which did not seem clear to 
me.  I'll comment more on this below.

>It is hard to see how there is a rush here.  The earliest version of
>this draft was submitted in 2005.  I know things have slowed down
>around the IETF, but I can't think of seven years as a rush.

Jiankang Yao commented on this in a message at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06315.html 
The other part of the comment was "raises questions about whether the 
DNSSECbis documents will ever be advanced in the near future from 
Proposed Standard to Internet Standard".

>This view seems to be shared by others.  I think we can change the
>term to "DNSSEC" and, on first reference, say "(sometimes known as
>DNSSECbis)" in order to make clear that the document is not referring
>to the earlier incarnation.

Ok.

>5155 isn't being modified, but the class of things we call DNSSEC is:
>this section is there to tell people that NSSEC3 isn't really
>optional, because if you don't implement it you won't be able to
>validate .com, .net, or .org to name but three relevant zones.  That's
>supposed to be clear from the first paragraph; is it not?

The above explanation is clear.  The first paragraph of Section 2.1 
is clear.  This draft updates RFC 5155.  When I performed the review 
I compared the requirements in the last paragraph of Section 2.1 with 
what's in RFC 5155 to find out whether there is a change in the requirements.

>There aren't any, but we can't practically require it because under
>memory constraints a cache is going to be emptied anyway.

Ok.

>That's a good point.  I don't know of anywhere, but I'm not sure this
>document is an appropriate place to define it.  Since the DNS is a
>tree structure, "ancestor" has the same meaning it would for other
>tree structures.  I think it would be a very bad idea to add
>definitions of this sort to this document, because the term applies to
>all of the DNS and not just to DNSSEC.  The DNS RFCs are hard enough
>to navigate as it is.

Agreed.

>The problem that is described in the paragraph immediately before this
>paragraph -- the one you quoted just above.  Richard Barnes also
>complained about not understanding this section, so I acknowledge
>there's a problem here, but I'm not sure how to fix it.  What is
>unclear to you?

I found your answer to Richard Barnes' comments clear.  I'll quote it:

   "In the original specification, an attacker could use such an RR
    to prove the non-existence of some name in a subordinate zone.
    That was the problem."

Quoting from Section 4.1 of the draft:

   "[RFC4035] Section 5.4 under-specifies the algorithm for checking non-
    existence proofs.  In particular, the algorithm as presented would
    incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove
    the non-existence of RRs in the child zone."


I'll suggest text and leave it to the editor to see what's better:

   In [RFC4035] Section 5.4, an attacker could use an NSEC or NSEC3 RR from
   an ancestor zone to prove the non-existence of RRs in the child zone.


   An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:

    o  the NS bit set,
    o  the SOA bit clear, and
    o  a signer field that is shorter than the owner name of the NSEC RR,
       or the original owner name for the NSEC3 RR.

   The algorithm in [RFC4035] Section 5.4 is updated as follows:

   Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume ...

As a matter of style I would replace Section 5.4 altogether so that 
it is clear to the reader.

>I think the intention was that the reader would have the original open
>along with this document when reading.  How would you like it
>rewritten?

I generally go through all the normative references before reading a 
draft.  I also refer to the original (opened) document when 
reading.  Although I don't think that it will be done, I would 
suggest updating the actual RFCs instead of publishing a set of clarifications.

I'll keep to the publication recommendation I made previously.  I 
suggest not to pay too much attention to that.  I cannot give the 
draft a pass.  The IESG can do that and nobody will be unhappy. :-)

Regards,
S. Moonesamy