RE: WGLC on DNSSEC bis document set

[Samuel Weiler <weiler@tislabs.com>]

Most of the items I found during my review of the DNSSECbis documents
were either omissions or editorial in nature.  I've included a summary
below.  I don't think any of these are major technical issues -- most
are matters which are well understood but incorrectly or inadequately
documented.  This message is intended mostly as a reference list.  I
suggest that we start separate threads for each issue that needs
discussion (such as the mnemonics message I just end).  For several of
these items, more extensive discussion has been sent to the editors'
list and many more minor nits have been sent to the editors.

In -protocol, the DS-13 resolver-side grandparent problem fixes are
missing.  Section 3.1.4.1 tells servers authoritative for both a zone
and its grandparent how to answer a DS query (with NODATA), and
section 4.2 tells resolvers to ask the parent zone for the DS, but it
doesn't tell resolvers how to find the parent zone.  RFC3658 section
2.1.2.2 has the needed closest encloser logic.

-protocol needs to discuss the safety property and the resolver-side
mandatory algorithm rules (per Mark Andrews' message).  I'll post more
about this in a separate thread.

The docs need to do a better job explaining the DNSKEY->DNSKEY
indirection.  Intro's diagram (DNSKEY->[DS->DNSKEY]*->RRset) misses it
entirely, as pointed out earlier.  Intro and/or protocol need to
explicitly say that having only a single DNSKEY in a zone works, and
there are times when the mention of SEP/ZSK/KSK is confusing and
perhaps misleading.

As my comments on -intro noted, there are some very messy editorial
changes that I think would be wise to complete before advancing that
document.

David Blacka found a problem with the canonical ordering section in
-records (good eye, David!)

In -records section 4, just as in the NSEC doc, "authoritative" is not
locally defined and may confuse readers.  -protocol section 2.2 does
the job admirably.  I suggest a direct reference from records section
4 to protocol section 2.2.

-protocol section 3.2.2 implies that the default is to ignore the CD
bit setting, which has the potential to deny data to clients that
specifically want unvalidated data.  The default should be to honor it
(and copy it to outgoing queries).  We can allow resolvers to un-set
the bit (with a MAY), but need to add lots of Security Considerations
text to explain how this might deny service to unsuspecting clients.
Furthermore, it should be clarified that a resolver MAY choose to set
CD even though the incoming query didn't set it (ie. if the resolver
is planning to do validation itself).  (Credit to Mark Andrews for
this last observation.)

-protocol sections 3.2.2 and 4.2 (and perhaps others) say one MUST do
something unless local policy is not to.  If it's reasonable for local
policy to override something, a 2119 MUST doesn't make much sense.
(Noticed by workshop participants.)

I posted a specific MUST/SHOULD concern to the list re: out-of-date
RRSIGs.

I previously observed that intro's security considerations doesn't say
enough about how DNSSEC can make the DNS more fragile.  protocol-05's
security considerations actually does that pretty well.  I'd like to
see more Security Considerations text across the board, but this
concern has been addressed.

And I just sent a note about mnemonics.

-- Sam

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