[DNSOP] A new review of draft-ietf-dnsop-rfc4641bis-10 -- part (A)

[Alfred Hönes <[e-mail]>]

After a long delay, I have revisited the
"DNSSEC Operational Practices, Version 2" I-D and performed
a full review from scratch for the most recent draft version,
draft-ietf-dnsop-rfc4641bis-10.

For convenience, and to accommodate message size limitations,
I have split my review comments into 3 parts:

  (A)  Technical flaws,
  (B)  Editorial flaws, and
  (C)  Editorial nits

Only the first two parts will be sent to the dnsop list,
the bulky third part is given as fodder to the authors only.

Here we go with part (A);
please consider to provide feedback for the items below on the list.



(A)  Technical flaws
++++++++++++++++++++

(A.1)  Normative set of documents defining DNSSEC

In Section 1, 1st para, the draft says:

   This document describes how to run a DNS Security (DNSSEC)-enabled
   environment.  It is intended for operators who have knowledge of the
|  DNS (see RFC 1034 [RFC1034] and RFC 1035 [RFC1035]) and want to
|  deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035
|  [RFC4035]).  [...]

However, the DNSSEC WG once has made the decision to include some
other documents into the list of what should be regarded as the
integral set of "core" documents defining DNSSEC[bis].
IIRC, that decision has been made in late 2009, and consequentially
it has been recorded in the AXFR RFC (see section 2, page 7 of
RFC 5936).  These additions are:
   - RFC 4509 ,
   - RFC 5155 ,
   - RFC 5702 , and
   - draft-ietf-dnsext-dnssec-bis-updates
     (now at draft version -16 and expected to be submitted to the
     IESG very soon, likely in parallel to this memo).
Therefore, I suggest to amend the above "see" list in the draft
by adding these four documents, and accordingly to promote the
References to them to Normative (the dnssec-bis-updates I-D needs
to be added to the References).

(A.2)  Section 1.1 -- improper/imprecise description of key usage

Section 1.1 improperly talks about public key usage in _key exchanges_.
However, in the context of DNSSEC, the public part of asymmetric key
pairs are used for _signature verification_ , and only that usage is
relevant for this document.

So please change:

OLD:
                                                    [...]  It is also
   assumed that the reader understands that the public part of the key
   pair is published in the DNSKEY Resource Record and that it is the
|  public part that is used in key exchanges.
                               ^^^^^^^^^^^^^
NEW:
                                                    [...]  It is also
   assumed that the reader understands that the public part of the key
   pair is published in the DNSKEY Resource Record and that it is the
|  public part that is used in signature verification.
                               ^^^^^^^^^^^^^^^^^^^^^^

(A.3)  Section 3.4.1 -- improved section title

In Section 3.4,

| 3.4.  Cryptographic Considerations

... I suggest to make the title of Section 3.4.1 more precise.

OLD:
| 3.4.1.  Key Algorithm

NEW:
| 3.4.1.  Signature Algorithm
or:
| 3.4.1.  Digital Signature Algorithm
or:
| 3.4.1.  Digital Signature and Hash Algorithms


(A.4) Section 3.4.1/3.4.2 -- additional considerations wrt ECDSA

Given the pressure by important governmental/international
stakeholders in support of Elliptic Curve (EC) cryptography
and the large amount of DNS response packet space consumed
by RSA (and DSA) keys and signatures, I strongly recommend
to give the reader a glimpse of perspective on ECDSA usage with
DNSSEC; draft-ietf-dnsext-ecdsa currently is in the RFC Editor
queue in state "RFC-Editor" and already supported by major DNS
implementations.

For instance, it would IMO make sense to add at the end of Section
3.4.1 or 3.4.2 a new paragraph like this:

|  Operators concerned with performance and key/signature size issues
|  related to RSA and DSA usage with DNSSEC should follow the ongoing
|  standardization -- and consequential implementation -- progress for
|  the use of digital signature algorithms based on Elliptic Curve (EC)
|  Cryptography with DNSSEC, which promises much shorter key and
|  signature sizes than RSA/DSA for equivalent cryptographic strenght.
|  In particular, the use of ECDSA with DNSSEC is now specified
|  [RFC.ietf-dnsext-ecdsa] and is expected to be available for use in
|  the foreseeable future.


(A.5) Section 4.1.1.2, 2nd bullet below Figure 3 and 2nd-to-last para

For completeness and consistency with other parts of the document,
I strongly recommend to expand on the present text and explicitly
mention the propagation delay that needs to be taken into
consideration, beyond the TTL-based cache expiry period.
(See also the dnsop-dnssec-key-timing draft.)

a) 2nd bullet

OLD:
   new DNSKEY:  At the "New DNSKEY" stage (SOA serial 1) DNSKEY_Z_11 is
      introduced into the key set and all the data in the zone is signed
      with DNSKEY_Z_10 and DNSKEY_Z_11.  The rollover period will need
|     to continue until all data from version 0 of the zone has expired
      from remote caches.  This will take at least the Maximum Zone TTL
      of version 0 of the zone.

NEW:
   new DNSKEY:  At the "New DNSKEY" stage (SOA serial 1) DNSKEY_Z_11 is
      introduced into the key set and all the data in the zone is signed
      with DNSKEY_Z_10 and DNSKEY_Z_11.  The rollover period will need
|     to continue until all data from version 0 of the zone has been
                                                               ^^^^^
|     replaced in all secondary servers and then has expired from remote
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      caches.  This will take at least the Maximum Zone TTL of version 0
      of the zone.

b) 2nd-to-last paragraph

OLD:
   At every instance, RRSIGs from the previous version of the zone can
   be verified with the DNSKEY RRset from the current version and vice-
   versa.  The duration of the "new DNSKEY" phase and the period between
   rollovers should be at least the Maximum Zone TTL of the previous
|  version of the zone.

NEW:
   At every instance, RRSIGs from the previous version of the zone can
   be verified with the DNSKEY RRset from the current version and vice-
   versa.  The duration of the "new DNSKEY" phase and the period between
   rollovers should be at least the Maximum Zone TTL of the previous
|  version of the zone plus the maximum propagation delay to secondary
|  servers.


(A.6) Section 4.1.3 -- wrong key designators in text

In the last two paragraphs of this section (below Figure 5),
text apparently has been borrowed from Section 4.1.4 without
being properly adjusted for the new context: In all instances of
"DNSKEY_S_n" and "DS_S_n" (where "n" is "1" or "2"), "_S_" needs
to be replaced by "_K_" (9 instances total).

The revised paragraphs then should read (including a comma added
on the 1st line of the final paragraph):

NEW:
   When the child zone wants to roll, it notifies the parent during the
   "new DS" phase and submits the new key (or the corresponding DS) to
|  the parent.  The parent publishes DS_K_1 and DS_K_2, pointing to
|  DNSKEY_K_1 and DNSKEY_K_2, respectively.  During the rollover ("new
   DNSKEY" phase), which can take place as soon as the new DS set
|  propagated through the DNS, the child replaces DNSKEY_K_1 with
|  DNSKEY_K_2.  Immediately after that ("DS/DNSKEY removal" phase), it
   can notify the parent that the old DS record can be deleted.

|  The drawbacks of this scheme are that during the "new DS" phase, the
|  parent cannot verify the match between the DS_K_2 RR and DNSKEY_K_2
|  using the DNS -- as DNSKEY_K_2 is not yet published.  Besides, we
   introduce a "security lame" key (see Section 4.3.3).  Finally, the
   child-parent interaction consists of two steps.  The "Double
   Signature" method only needs one interaction.


(A.7) Section 4.1.5, Figure 7 -- wrong parent SOA serial

In the second part of Figure 7 (stage "new DS"), the parent SOA
serial needs to be incremented from the previous stage, which is
the "initial" stage for that zone.

So please correct:

OLD:
   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
|   SOA_0 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

NEW:
   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
|   SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->


(A.8)  Section 4.3.5.1, Figure 9 -- wrong child SOA serials?

According to the prose in this section, as far as I understand it,
the "redelegation" phase should happen with stable client zone data
at both the old (A) and new (B) DNS operator and only change the
parent zone -- or have I missed something important there?

If these considerations apply, the client SOA serial increment shown
in the redelegation phase in Figure 9 seems to be inappropriate and
need to be decremented (to the values shown for the "pre-publish"
phase; if so, the next client SOA serial in the "post migration"
phase needs to be decremented as well.

Further, for consistency in style, the phase name "redelegation"
should be shown in lowercase, like all other phases in the figure.

To sum up, I suggest the following changes:

OLD:
    ------------------------------------------------------------
|         Redelegation                 |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_B                           DS_B
    ------------------------------------------------------------
    Child at A:        Child at B:           Child at B:

|    SOA_A2             SOA_B1                SOA_B2
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     [...]

NEW:
    ------------------------------------------------------------
|         redelegation                 |   post migration      |
    ------------------------------------------------------------
    Parent:
              NS_B                           NS_B
              DS_B                           DS_B
    ------------------------------------------------------------
    Child at A:        Child at B:           Child at B:

|    SOA_A1             SOA_B0                SOA_B1
     RRSIG_Z_A(SOA)     RRSIG_Z_B(SOA)        RRSIG_Z_B(SOA)

     [...]


(A.9)  Section 4.4 -- technical clarification

Since RFC 2308 specified the caching behavior for negative responses,
which arguably do not deliver "data", the text in Section 4.4 needs
a small addition to properly represent the negative caching behavior
as well:

OLD:

   Without DNSSEC, all times in the DNS are relative.  The SOA fields
   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
|  elapsed after a slave server synchronized with a master server.  The
|  Time to Live (TTL) value and the SOA RR minimum TTL parameter
|  [RFC2308] are used to determine how long a forwarder should cache
|  data after it has been fetched from an authoritative server.  By
   ^^^^
   using a signature validity period, DNSSEC introduces the notion of an
   absolute time in the DNS.  Signatures in DNSSEC have an expiration
   date after which the signature is marked as invalid and the signed
   data is to be considered Bogus.

NEW:

   Without DNSSEC, all times in the DNS are relative.  The SOA fields
   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
   elapsed after a slave server synchronized with a master server.  The
   Time to Live (TTL) value and the SOA RR minimum TTL parameter
   [RFC2308] are used to determine how long a forwarder should cache
|  data after it has been fetched from an authoritative server or
                                                              ^^^
|  negative responses, respectively.  By using a signature validity
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   period, DNSSEC introduces the notion of an absolute time in the DNS.
   Signatures in DNSSEC have an expiration date after which the
   signature is marked as invalid and the signed data is to be
   considered Bogus.


(A.10)  Section 5.1, ff. -- term "RRlabel" needs clarification

I have trouble understanding what the term "RRlabel" means and
what precisely the draft wants to state in the text passages
where it is used.  This term, used as a single word, is very
uncommon and has not been used in published RFCs so far, and
it is nowhere formally defined in this memo; yet it recurs for
a total of 8 instances in Sections 5.2, 5.3.1, and 5.3.3.

The first occurrence is in the first sentence of the last para
of Section 5.1, which says:

| The NSEC3 record uses a hashing method of the requested RRlabel.

If the draft wants to introduce a new term, it should precisely
define it upon first usage (or in a terminology section).
I also do not fully understand what "requested" means here --
a QNAME in a DNS query? (that's not a 'label' in the sense of
STD 13, but a FQDN); subsequent text in Section 5.2 (3rd para):

|  For large zones where there is an implication of "not readily
|  available" RRlabels, such as those where one has to sign a non-
|  disclosure agreement before obtaining it, NSEC3 is preferred. [...]

... might even be understood as indicating 'request for registration'
(via a registrar into a zone that has restrictive policies on what
relative domain names can be registered).  That needs clarification.

But, firstly, back to the last para of Section 5.1!

Upon further investigation: what's hashed for NSEC3 aren't single
labels, but the fully qualified domain names registered in the zone
-- the details are specified in Section 7.1 of RFC 5155, and also
quoted shortly in Section 5.3.1 of the draft.  And these are not
the domain names "requested" in DNS queries (QNAMEs) -- unless these
happen to match FQDNs for which RFC 5155 has made mandatory the
generation of NSECe RRs (in particular, for secure delegations
and for wildcards), or for which the Opt-out policy in force has
chosen to generate NSEC3 records.
Thus, as long as there is no sensical definition of the term, maybe
"the requested RRlabels" might better be replaced by
"the names registered in the zone".

Note that the subsequent instances of "RRlabel" in Sections 5.2
(1st and 3rd para, 1x each), 5.3.1 (1st para, 2x), and 5.3.3
(2nd para, 3x) will likely need text adjustments as well.


(A.11)  Appendix C, Figures 12 and 13 -- wrong parent SOA serial

The change for Figure 7 shown above in item (A.7) applies literally
to Figure 12 in Appendix C, and again to Figure 13 in Appendix C
-- with the caveat that the key designations are for "_S_" keys as
in Figure 11, not for "_K_" keys as in Figures 7 and 12.


(A.12)  Appendix D, Figure 14 -- wrong child SOA serials?

The changes for Figure 9 shown above in item (A.8) applies literally
to Figure 14 in Appendix D as well.



Part (B) will follow quickly in a subsequent message.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+