Subject: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-08

From: Alfred Hönes <[email-masked]>
Date: Fri, 16 Jan 2009 18:12:18 +0100 (MEZ)

I followed up to the new draft version and again have taken
a closer look at draft-ietf-dnsext-dnssec-bis-updates-08.

Furthermore, I have revisited the notes I once had made on
studying RFC 4033..4035, looking for potential additions
that could be considered for the above draft.

(A)
First, my editorial considerations for the current draft:

(A.1)  Section 1

The front matter of the document already correctly notes that the
memo Updates RFC 5155.  Concurring with the spirit of the trailing
notes in both section 2.1 and 2.2 and the perceived consensus of
the WG on what comprises the current core DNSSEC document set,
I suggest to amend the first paragraph of the Introduction,
in order to unambiguously communicate to the reader what should
be understood now as the "core DNSSECbis document set".

For instance, we could replace the current clause:

   This document lists some clarifications and corrections to DNSSECbis,
   as described in [RFC4033], [RFC4034], and [RFC4035].

by:

|  This document lists some clarifications and corrections to the core
|  DNSSECbis specification, as originally described in [RFC4033],
|  [RFC4034], and [RFC4035], and later amended by [RFC5155]. (See
|  Section 2.2 for more recant additions to that core document set.)

(A.2)  Section 4.1, first paragraph

The current text says:

   Section 5.2 of [RFC4035] includes rules for how to handle delegations
|  to zones that are signed with entirely unsupported algorithms, as
                    vvvvvvvvvv                        ^^^^^^^^^^
|  indicated by the algorithms shown in those zone's DS RRsets.  It does
   not explicitly address how to handle DS records that use unsupported
|  message digest algorithms.  In brief, DS records using unknown or
|  unsupported message digest algorithms MUST be treated the same way as
   DS records referring to DNSKEY RRs of unknown or unsupported
|  algorithms.
   ^^^^^^^^^^

Here, the unspecific term "algorithm" is used three times and
juxtaposed to "message digest algorithm".
I'm aware of the fact that the simple, unspecific term "algorithm"
once was clear enough when there was no specific reason to care of
*the* digest algorithm in use; but now, cryptographic hashes are in
the security focus and subject to crypto agility, so a more specific
and balanced wording would contribute to the clarity of the memo.

(The original terms, "algorithm [number]" and "digest type" do not
reflect the rather similar function of both fields; hash functions
are also 'algorithms'.)

To make the distinction more clear, I suggest to expand the plain
"algorithm" (as already done in Section 4.2) by using either
"signature algorithm" or "public key algorithm" ;  perhaps it would
suffice to replace the first and the last instance of "algorithm".

(A.3)  Section 4.1, penultimate paragraph

The draft says:

   To paraphrase the above, when determining the security status of a
|  zone, a validator discards (for this purpose only) any DS records
                     ^^^^^^^^
   listing unknown or unsupported algorithms.  If none are left, the
   zone is treated as if it were unsigned.

I would appreciate replacing  "discards"  by  "disregards"  here;
it better reflects the alluded behavior and should better help to
avoid the possible misconception that the current text already tries
to counter with the parenthetical addition "(for this purpose only)"
[ Implementers are used to associate "discard" with 'free()' ! ]

(A.4)  Section 4.8, first paragraph

Typo;   s/validor/validator/

(A.5)  Section 5.4, first paragraph
                 v                                   v
|  A NSEC3 record, that matches an Empty Non-Terminal, effectively has
   no type associated with it.  [...]

I'd classify the two commas in the first sentence as spurious
and disturbing, and hence suggest to drop them.

(B)
Back to the original document set.

Below are some issues I offer to be considered for being dealt with
in additional sub-sections of Section 5 of the draft.
If rejected, a "Keep for Update" record should be made.

(B.1)
I once had noted that RFC 4033 and 4034 made arguably normative
references to documents they claim to Obsolete, like:
    "For details, see RFC yyy."

Doing so -- at least in the way it came out -- IMHO was not a
good idea.
The present draft however seems not to be a suitable place to
correct these flaws.
I'd rather suggest to "Keep for Update" these observations.

These were the reference instances I had made note of originally:

         RFC 4033, page 4      -->    RFC 3757
         RFC 4033, page 7      -->    RFC 3755

         RFC 4034, page 12     -->    RFC 3845

(B.2)  RFC 4035, Sections 2.2 and 2.3

There is a contradiction in RFC 4035:

Section 2, on pp. 5/6 says:

                 [...]  Note that RRSIG RRs are closely tied to the
   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
|  RR types, do not form RRsets.  In particular, [...]
             ^^^^^^^^^^^^^^^^^^

Contrary to that, the third paragraph of Section 2.3 says:

|  An NSEC recors (and its associated RRSIG RRset) MUST NOT be [...]
                                      ^^^^^^^^^^^

Admitting RRSIG records to form an RRset would be fatal for the
application of the rules in RFC 1034/1035 requiring that only
complete RRsets be placed into DNS responses from authoritative
servers and truncation hence has to be performed on RRset boundaries.

However, Section 3 again talks about RRSIG RRsets.

I have not (yet) checked systematically whether the allusion of an
"RRSIG RRset" re-appears in other places of the DNSSECbis document set.

In order to clarify the intended usage of terms and concepts
(also for future document authors!) I propose to consider adding
a note to the draft.

Another nit for Section 2.3 of RFC 4035:  The fourth paragraph should
talk of RRSIG in the plural form, perhaps adding "(s)" as follows:

   The type bitmap of every NSEC resource record in a signed zone MUST
   indicate the presence of both the NSEC record itself and its
|  corresponding RRSIG record(s).
                             ^^^

(B.3)   RFC 4035, Section 3.1

The text in the first paragraph of 3.1 does not list DNSKEY RRs
as subject to special inclusion rules, and there is no bullet
below it giving the details; only RRSIG, NSEC and DS are listed
and dealt with in the text and the (three) bullets.
However, there are *four* subsections 3.1.1 through 3.1.4 specifying
the rules for all four RR types mentioned above.

I suggest adding a clarifying note that Section 3.1 should also
have mentioned DNSKEY RRs and pointed to Section 3.1.2 for the rules.

(Optionally, it might be useful to say that NSEC3 now also is on
the list and point to the proper section of RFC 5155.)

(B.4)  RFC 4035, Section 5.3.2

The third line from the bottom of page 29 contains a confusing
explanation of a term in the  "RR(i) = ..."  formula describing
the component of the signed_data for an RRSIG RR corresponding
to a specific resource record; it says:

|    type is the RRset type and all RRs in the class

It should perhaps better say:

|    type is the resource record's type (same for all RRs in the RRset)

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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