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

[Andrew Sullivan <[e-mail]>]

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
[e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext