[dnsext] draft-hoffman-dnssec-* (DNSSEC algorithm drafts)

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

For brevity, I refer in a single message to the following
recent DNSSEC algorithm related drafts:

1.)   draft-hoffman-dnssec-alg-allocation-01
2.)   draft-hoffman-dnssec-dsa-sha2-00
3.)   draft-hoffman-dnssec-ecdsa-00

I have reviewed these drafts, and I support adopting them all
as DNSEXT work items.  Set aside the policy direction for #1,
there seems to be very little need of technical discussions,
so this will not represent a significant contribution to the
overall wg workload.

[ Refraining from a few extraneous rounds in sustained and/or
  recurring circular discussions might provide ample wg cycles
  for dealing with these drafts .   :-)  ]


#1 seems to be overdue and it is editorially already almost done;
I noticed a single nit, listed in the appendix of this message.

IMHO, what needed to be said regarding the intent and direction
of this draft already has been said on the list.

IANA reportedly now supports provisional registrations with a
timeout set for expiry (unless confirmed by document action),
which do not become visible in the published registries.
I suggest to adopt these procedures for the benefit of draft
authors, abating the need to defer example generation to AUTH48
and thus allowing better review and verification of examples.


#2 and #3 are certainly needed in order to let DNSSEC keep pace
with the development of crypto-algorithm science and technology,
and with related fundamental standards, and to ensure longer term
DNSSEC deployment support by significant authorities.

An important additional momentum driving the modern algorithms
into DNSSEC is the potential savings in DNS response size, as
explained in these drafts.

Not addressing these issues and broadening the algorithm portfolio
in DNSSEC might otherwise turn out as a major obstacle to large
scale DNSSEC deployment -- a goal always supported vividly by
a majority on this list.

I have found only a single issue deserving clarification in #2
and a bunch of minor issues to be addressed for #3 -- see below
for the details.

Thus, filling in the promised examples seems to be the only
significant task left for the author ...  :-)
... but that can only be done in a useful way once algorithm
numbers have been assigned, hence the urgent need for #1 !!


Appendix: review result details

(1)   draft-hoffman-dnssec-alg-allocation-01

Section 3, 2nd para, contains an extraneous word.
Please correct:

    [...] mandatory to implement in the that standard, [...]
---                                ^^^^
    [...] mandatory to implement in that standard, [...]


(2)   draft-hoffman-dnssec-dsa-sha2-00

I suggest improving the reasoning in Section 1 by amending its 2nd
para, which states:

   RFC 2536 [RFC2536] describes the KEY and SIG resource records (RRs)
   for the DSA with SHA-1 signature algorithm.  At the time RFC 2536 was
   written, SHA-1 was the only hash algorithm that was defined for use
   with DSA, and the only key size allowed was 1024 bits.  FIPS 186-3
   ([FIPS-186-3]) extends the original DSA definition to permit larger
   keys.  This document neither updates nor replaces RFC 2536.

This text reports what had been done in RFC 2536 for the KEY and SIG
 RRs, and then the recent developments in FIPS 186.
The subsequent paragraphs discuss some Pros and Cons of DSA with
SHA-2 hashes, and then indicate which additions to the *DNSSECbis*
documents (RFC 403x) are needed to support that, thus introducing
what will be done in the following sections for the *DNSKEY* and
*RRSIG* RRs.

I miss a link in the chain: what happened from RFC 2535 to RFC 403*,
i.e. the step to the new DNSSEC RRs.  Since RFC 2536 already has
been obsoleted by DNSSECbis, the last sentence quoted above should
be deleted.

Hence, I propose to change/amend the 2nd para of Section 1 as follows:

   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv                           v
|  For the original DNSSEC version, RFC 2536 [RFC2536] described the KEY
   and SIG resource records (RRs) for the DSA with SHA-1 signature
   algorithm.  At the time RFC 2536 was written, SHA-1 was the only hash
   algorithm that was defined for use with DSA, and the only key size
|  allowed was 1024 bits.  The DNSSECbis documents listed above have
|  introduced the DNSKEY and RRSIG RRs replacing these old DNSSEC RR
|  types, but they have not changed the algorithm portfolio (see in
|  particular Appendix A of [RFC4034]).

   FIPS 186-3 ([FIPS-186-3]) extends the original DSA definition to
|  permit larger keys.
                        ^^^^^

[[ 2nd sentence deleted; perhaps better join this remaining sentence
   with the subsequent paragraph! ]]


(3)   draft-hoffman-dnssec-ecdsa-00

There are a couple of editorials to be corrected, and in Section 7,
wisdom has to be added.
I omit verbous reasoning for the straightforward editorials.

(3a)   Section 3

|  Verifying ECDSA signatures require agreement between the signer and
   the verifier of the parameters used.  FIPS 186-3 [FIPS-186-3] lists
   some NIST-recommended elliptic curves.  These are the same curves
   listed in RFC 5114 [RFC5114].  The curves used in this document are:
---                                  v
|  Verifying ECDSA signatures requires agreement between the signer and
   the verifier of the parameters used.  FIPS 186-3 [FIPS-186-3] lists
|  some NIST-recommended elliptic curves.  These are the same curves as
   listed in RFC 5114 [RFC5114].  The curves used in this document are:

[[ better use  "... same ... *as* ..." ]]


(3b)  Section 4, 1st para -- significant word omission

   ECDSA public keys consist of a single value, called "Q" in FIPS
   186-3.  In DNSSEC keys, Q is a simple bit string that represents the
|  uncompressed form of the curve.
---
   ECDSA public keys consist of a single value, called "Q" in FIPS
   186-3.  In DNSSEC keys, Q is a simple bit string that represents the
|  uncompressed form of a curve point.
                        ^      ^^^^^^

Important note for the list:

   In ECC, the public key is a point on the elliptic curve, and the
   SEC standards have defined different representations for it.
   The uncompressed form trades on-the-wire space in favor of reduced
   processing complexity at the signature verifier.

   An alternative would be the compressed form that essentially only
   requires a single bit to represent the y-coordinate of that point,
   thus cutting the size of the key representation almost to half,
   but which necessitates additional calculations at the signature
   verifier (using the equation of the elliptical curve, perhaps
   making use of clever shortcuts depending on the finite field on
   which the curve is defined) to recover the entire value of the
   y-coordinate.

   Other IETF WGs have favored the uncompressed form, but the
   restrictions imposed by theoretical and practical DNS response
   size limitations might call for revisiting this topic for DNSSEC.

   Can implementors of ECC (outside DNSSEC) quantify the relative
   cost (in processing time) of using the compressed form?


(3c)   Section 7, 1st para -- word omission

|  This document updates the IANA for digest types in DS records,
   currently called "Delegation Signer Resource Record, Digest
   Algorithms".  The following entry is added:
---                              vvvvvvvvvv
|  This document updates the IANA registry for digest types in DS
   records, currently called "Delegation Signer Resource Record, Digest
   Algorithms".  The following entry is added:


(3d)  Section 7, new "Algortihm Number" entries

To my knowledge, at this point in time there does not exist a formal
specification for the use of these algorithms with DNS transaction
security (TSIG) -- which now is no more regarded as a component of
DNSSEC.
I strongly suggest to definitely say in the registration templates
that TSIG support is not available, and leave an update to such
specification, once it eventually is adopted.

Hence I suggest to perform the following change (3 occurrences):

   Trans. Sec.    **** Unknown; will fill in later ****
---
   Trans. Sec.    No


(3e)  Section 8 -- incomplete sentence

                                               [...].  Such an
   assessment could, of course, change in the future if new attacks that
|  work better than the ones known today.
---                                     ^
                                               [...].  Such an
   assessment could, of course, change in the future if new attacks that
|  work better than the ones known today are discovered.
                                        ^^^^^^^^^^^^^^^^

[[ Alternatively, use "found" instead of "discovered",
   as in the DSA draft. ]]


Kind regards,
  Alfred Hönes.

-- 

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