Subject: [dnsext] draft-hoffman-dnssec-ecdsa-04 -- crypto-strength considerations

From: Alfred Hönes <[email-masked]>
Date: Sun, 12 Dec 2010 21:13:20 +0100 (MEZ)

First the easy part:

Apparently due to a copyedit flaw, the 4th paragraph of Sect.1 of
draft-hoffman-dnssec-ecdsa-04 erroneously states:

                ... the equivalent strength of SHA-256 and SHA-384
  is half the length of the key.
          ^^^^^^^^^^^^^^^^^^^^^

The hash algorithms SHA-xxx do not have a key parameter.  :-(
The clause therefore should be edited to say:

                ... the equivalent strength of SHA-256 and SHA-384
  is half the hash size (as indicated in the algorithm designations).

[ I have added the parenthetical explanation to make the sentence
  unambiguously understandable even to those not fluent in the
  properties of the SHS algorithms.  If it is deemed unnecessary,
  please feel fre to drop it. ]

Now, more fundamentally, regarding Francis' point:

  It has been pointed out in the past that observed practice for RSA
  key sizes for DNSSEC purposes is not based on "hard" arguments from
  cryptography/cryptanalysis.

  Currently, the DNSSEC "algorithm" code points for both RSA and DSA
  signatures entail a rather unfortunate coupling of the signature
  algorithm (indepentent of key size) with a fixed, specific member
  of the SHS family of hashes.  This seems to be contrary to crypto
  state-of-the-art and the spirit of the DSS, which requests matching
  of the hash algorithm to the key size (according to NIST SP 800-57),
  for all three signature schemes (DSA, RSA, and ECDSA) supported in
  the current DSS, FIPS 186-3.

  Therefore, *if* we want to continue to decouple the "algorithm" code
  point from crypto-strength, it might be considered to only assign a
  *single* code point for "ECDSA-RECP-SHA", which would be used for
  the entire family of adopted standard, randomly-chosen MODP fields
  and Elliptic Curves thereover ("Random ECP groups"); in this case,
  the size of the public keys published in DNSKEY RRs would determine
  both the EC parameters and the matching hash function.
  Doing so would perhaps require an IANA sub-registry for that new,
  single "algorithm" code point that lists the pairing:
  key-size  --> { curve, hash },
  which would be populated by this document with two entries for
  P-256/SHA-256 and P-384/SHA-384.
  If someone later wanted to specify more choices, they could do so
  by registering additional entries, e.g. using P-521/SHA-512 or
  the curves from RFC 5639 with matching hash functions (which would
  offer a 512/512 choice as well).

  However, the alternative with two DNSSEC "algorithm" code points
  as specified in the current draft indeed implicitly carries the
  message that, for ECDSA usage in DNSSEC, the arguments from crypto-
  geeks take precedence over other arguments and the same pairing
  of strength-matched algorithms be used for KSK and ZSK of a zone.
  This arguably also would have benefits regarding interoperability
  and implementation security (less options --> simpler code -->
  less complexity --> less risk)..

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]                     |
+------------------------+--------------------------------------------+