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

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jun 2012 22:30:34 -0400

Hi,

I'm the shepherd for this document.  Thanks for the review.  Some
questions and comments inline.

On Tue, May 22, 2012 at 10:12:27AM -0700, S Moonesamy wrote:
> Summary: This document is not ready for publication as a Proposed Standard.
> 
> The proposal seems targeted at implementers who are fully conversant
> with the ins and outs of DNSSEC.  Although the proposal is
> well-written, it lacks clarity as to what is being changed in the
> "DNSSECbis document set".  It may end up being more confusing.

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?

> There was an announcement that the DNSEXT WG would be shut down.
> The rush to publish these clarifications raises questions about
> whether the DNSSECbis documents will ever be advanced in the near
> future from Proposed Standard to Internet Standard.

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.

> 
> "DNSSECbis" seems more like an internal IETF term to identify the
> document set.  RFC 4033, for example, does not have any mention of
> "DNSSECbis".  I suggest using "DNSSEC protocol document set" and
> amending the title accordingly.

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.
 
> In Section 2.1:
> 
>   "Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
>    SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
>    signal that a zone MAY be using NSEC3, rather than NSEC.  The zone
>    MAY be using either and validators supporting these algorithms MUST
>    support both NSEC3 and NSEC responses."
> 
> It is not clear from the above text which parts of RFC 5155 is being
> modified.

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?

> In Section 3.1:
> 
>   "Section 4.7 of RFC4035 permits security-aware resolvers to implement
>    a BAD cache.  Because of scaling concerns not discussed in this
>    document, that guidance has changed: security-aware resolvers SHOULD
>    implement a BAD cache as described in RFC4035."
> 
> From Section 4.7 of RFC 4035:
> 
>   "To prevent such unnecessary DNS traffic, security-aware resolvers MAY
>    cache data with invalid signatures, with some restrictions."
> 
> If I understood the text from this draft, the "MAY" is being changed
> into a recommendation.  In which cases would it better not to follow
> the recommendation?

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

> In Section 4.1:
> 
>   "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."
> 
> Where is ancestor zone defined?

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.

>   "Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
>    existence of any RRs below that zone cut, which include all RRs at
>    that (original) owner name other than DS RRs, and all RRs below that
>    owner name regardless of type."
> 
> It is not clear what is being clarified.

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?

> In the Introduction Section:
> 
> The IETF is now using two maturity levels. "Draft Standard" has been
> changed to "Internet Standard"

Good catch, thanks.  I suggest "when advancing the DNSSEC documents
along the standards track".  How's that?

> In Section 6.3:
> 
> This section discusses about errors in the examples in RFC 4035.  As
> a stylistic comment, it is clearer to the reader if he/she could see
> the actual examples with the corrections made.

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?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 21 Jun 2012 20:45:36 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: "S Moonesamy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 19, 2012 10:30 AM
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-bis-updates-18

> ......

 SM does not mean seven years is a rush.
He mean that this draft survives almost 7 years and the draft has not clear clue of being ready to be published before announcement of DNSEXT WG shutting down.
Only after the announcement, someone said that this draft is ready for publication.
Many readers,  I think it is not only SM,  feel that there is a little surprise or unexpected.

From 0 month to 6 year and 11 month, there is no sign of ready.
From 6 year and 11 month to 6 year and 12 month, suddently say that "it is ready to go"

This is a rush, not 7 years as a rush.

If I understand SM correctly, I think That is why there is a rush.

Jiankang Yao

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Jun 2012 10:03:01 -0400

> He mean that this draft survives almost 7 years and the draft has not clear clue of being ready to be published before announcement of DNSEXT WG shutting down.

I see.  

With respect, I think I must have said about thirty times over the
past several years, "It is time to get this document published."  The
minutes from meetings at IETF 77 and IETF 78 both say that it seems
time to publish the document, just for example; I haven't even looked
at the list arhives.  SM was not an active participant in DNSEXT for
much of that time, so he might well have overlooked those previous
discussions.  Did you miss them also?

I will cheerfully accept responsibility for having failed to press
hard enough.  I nevertheless object to the characterization of "rush".
It's simply not true.  This document has been pursued in the most
leisurely way possible.

Best regards,

Andrew (as shepherd)

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 21 Jun 2012 13:31:33 -0700

Hi Andrew,
>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.

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

>to the earlier incarnation.

Ok.

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

>memory constraints a cache is going to be emptied anyway.

Ok.

>all of the DNS and not just to DNSSEC.  The DNS RFCs are hard enough

Agreed.

>there's a problem here, but I'm not sure how to fix it.  What is

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.

>along with this document when reading.  How would you like it

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