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

From: Alfred Hönes <[email-masked]>
Date: Thu, 5 Apr 2012 00:41:02 +0200 (MESZ)

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: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 11 Apr 2012 15:47:33 +0200

Hi,

> draft-ietf-dnsop-rfc4641bis-10.

A very long delay, the wglc ended somewhere last year...

> please consider to provide feedback for the items below on the list.

I have omitted all items that I have adopted without feedback necessary.
In other words, all omitted items will make the next version of the
document.

> queue in state "RFC-Editor" and already supported by major DNS

A glimpse perhaps, but we (the editors) think your suggested is too
strong. Also, we think that there is too little experience with ECDSA to
make good observations. Which major DNS implementations are you
referring to that have already implemented ECDSA?

> |  the foreseeable future.

We would like to say that ECDSA is out of scope for Version 2 of DNSSEC
Operational Practices. We suggest the following text at the end of
3.4.1, which summarizes ECDSA and will not be discussed here.

    Also at the moment of publication, digital signature algorithms
    based on Elliptic Curve (EC) Cryptography with DNSSEC [] are being
    standardized and implemented. The use of EC has benefits in terms
    of size. On the other hand, one has to balance that against the
    amount of validating  resolver implementation that will not
    recognize EC signatures and thus treat the zone as insecure. Beyond
    the observation of this trade-off, we will not discuss further
    considerations.

> parent zone -- or have I missed something important there?

The only client zone data that needs to be stable is the NS and DNSKEY
RRsets. So, the serial may be incremented during the pre-publish and
redelegation phases. However, for clarity it might indeed be better to
take over your suggestion.

Ok, although I have made it:

> |  data (or negative responses) after it has been fetched from an
>        ^^^^^^^^^^^^^^^^^^^^^^^^
> |  authoritative server or.  By using a signature validity

> (2nd para, 3x) will likely need text adjustments as well.

I have replaced all occurrences by "name".

Best regards,
  Matthijs

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 11 Apr 2012 21:30:08 +0200 (MESZ)

Matthijs,

thanks for dealing with my comments so expeditiously.
(This extends to the other review comments as well.)

Please see a few follow-up remarks inline below.

On 11 Apr 2012 15:47:33 +0200, Matthijs Mekking wrote:
> Hi,
>
> On 04/05/2012 12:41 AM, Alfred Hönes wrote:

So will I, again.

>> ...
> strong. Also, we think that there is too little experience with ECDSA
> to make good observations. Which major DNS implementations are you

Admittedly,  "major DNS implementors" would have been better than
"majot DNS implementations" at this stage.

However, quoting from NIST SP 800-81r1, "Secure Domain Name System
(DNSSEC) Deployment Guide", (April 2010), page 9-4:

                        "[...]  The migration path for USG DNSSEC
     operation will be to ECDSA (or similar) from RSA/SHA-1 and
     RSA/SHA-256 before Septhember 30th, 2015.

... and from the same document, on page 9-6:

    "The use of RSA in DNSSEC is approved until the year 2015.
     By this time, it is expected that Elliptic Curve Cryptigraphy
     will be specified in the DNSSEC.  USG DNSSEC administrations
     should plan to migrate to the use of ECDSA (or similar) when
     it becomes available in DNSSEC components."

... one can see that there are strong market forces at work.
The commercial pressure to qualify for USG (U.S. Government) use
of networking components and software will likely lead to widespread
support soon.  There's nothing like "(or similar)" in view currently
as an alternative.
The repeated, IMHO non-rational fear of actual applicability of
patent claims is not justified; the EC groups chosen have been
selected carefully to make it possible to avoid the specific
optimizations for GF(2^n) based EC computations that in fact *might*
be covered by some patent claims -- see RFC 6090 for the detailed
report that all we need is based on academic publications that
predate the said patent applications.

>     the observation of this trade-off, we will not discuss further

Agreed.

The idea was to raise awareness among the reader community for
upcoming important developments, not to perform an evaluation,
and this aim is achieved with that text.

>> ...

That's a clever choice; "name" is more neutral, and together with
"FQDN" (where applicable) looks/sounds much better in the context
of the I-D.

Best regards,
  Alfred.