[dnsext] draft-hoffman-dnssec-ecdsa-01

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

I have a few technical points to be discussed for the DNSSEC
EDCDA draft, draft-hoffman-dnssec-ecdsa-01.


(1)  bit string vs. octet strings

Cryptographers are used to think in bit strings of arbitrary
bit size.  DNS folks usually deal with octet strings.

Since the introduction of bit strings does not incur any visible
benefit here, I suggest to avoid the notion of bit strings entirely
throughout the draft and use octet string oriented language and
octet string sizes for field descriptions.


(2)  representation of EC keys

Section 3 of the draft says (in its first paragraph):

|  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.

This is by far underspecified for the intended audience of this memo.

Section 2.3.3 of the SEC-1 Standard specifies the precise algorithm
to convert an EC point to a 'normalized' octet string.
This algorithm is widely adopted (IEEE, ANSI, NIST, IETF PKIX, etc.).
Making explicit reference to the resulting data format should
provide benefits for re-using existing crypto-APIs as well.

I recommend to normatively quote this specification in a similar
way as it is done in various new RFCs, including this week's
RFC 575? series.

Further, the restriction to uncompressed form seems unnecessary,
or even detrimental to the intended benefit of savings in DNS
response packet size as well as consumed bandwidth and delay.
The use of the compressed form essentially would cut down the
EC key size to half the size of the uncompressed form.

Note that generation of the compressed form is trivial, and
verifiers will perhaps prefer to expand it on receipt or first use.
The additional overhead incurred at the recipient (essentially
one GF(p) square root operation) is needed only once, and hence
can be amortized over multiple subsequent signature verification
operations.

The internal form of the keys should be transparent to DNS data
management and on-the-wire operations.
Since raising the requirements level for resolvers at a later stage
would be very problematic, I strongly recommend to provide a future-
proof specification, and hence my personal preference would be for a
"MUST implement" requirement for the compressed form of EC public
keys for signature verifiers, and a "SHOULD implement" for signers.

The draft text also is silent about the 'quality' requirements.
SEC-1 and various NIST publications contain verification procedures
and requirements for key generators, signers, and verifiers.
Such requirements are already imported in recent IETF documents,
cf. the abovementioned RFC 575? series.
I suggest that the draft be amended by related normative text,
after discussion of the assurance level the WG deems needed for
this application of ECC.


(3)  Precision if data element/field specification

Given the intended audience of the draft, the size of the data
elements used in the specification should be made explicit.

I suggest to introduce a parameter 'm' (this is 'mlen' in SEC-1)
into the table in Section 3 and make systematical use of it in
Section 4.



Combined Proposal for Section 3 -- ECDSA Parameters

OLD:

   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:

   FIPS 186-3                  RFC 5114
   ------------------------------------------------------------------
   P-224 (Section D.1.2.2)     224-bit Random ECP Group (Section 2.5)
   P-256 (Section D.1.2.3)     256-bit Random ECP Group (Section 2.6)
   P-384 (Section D.1.2.4)     384-bit Random ECP Group (Section 2.7)

NEW:

   Verifying ECDSA signatures requires agreement between the signer and
|  the verifier of the parameters used.  For the purpose of DNSSEC, this
|  is implicitely achieved by use of dedicated algorithm numbers carried
|  in the RDATA of DNSSEC resource records.  For the sake of improved
|  interoperability, the number of options should be kept small.
|
   FIPS 186-3 [FIPS-186-3] lists some NIST-recommended elliptic curves.
|  These are the same curves as listed in RFC 5114 [RFC5114].  We denote
|  the octet size of the integers used in the underlying MODP arithmetic
|  by "m" for easy use in field specifications below.  The curves used
|  in this document (and being assigned distinct algorithm numbers by
|  IANA per Section 7 below) are:

|  FIPS 186-3               RFC 5114                                 m
|  -------------------------------------------------------------------
|  P-224 (Section D.1.2.2)  224-bit Random ECP Group (Section 2.5)  28
|  P-256 (Section D.1.2.3)  256-bit Random ECP Group (Section 2.6)  32
|  P-384 (Section D.1.2.4)  384-bit Random ECP Group (Section 2.7)  48


Combined Proposal for Section 4 -- DNSKEY and RRSIG Resource Records for ECDSA

1st para:

OLD:

   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.

NEW:

   ECDSA public keys consist of a single value, called "Q" in FIPS
|  186-3.  In DNSSEC keys, Q is an octet string that represents the
|  compressed or uncompressed form of a curve point and is formed by
|  application of the algorithm specified in Section 2.3.3 of [SEC1].
|  Note that while the uncompressed form is an octet string of size 2m+1;
|  the compressed form is comprised of m+1 octets.
|
|  [[  add language on domain parameter and key verification ]]
|
|  [[  add language on implementation requirements
|      for signers and verifiers (resolvers)  ]]

[[ add normative ref to SEC-1, 2009 edition ]]

2nd para:

OLD:

   The ECDSA signature is the combination of two non-negative integers,
   called "r" and "s" in FIPS 186-3.  The two integers, each of which is
   formatted as a simple bit string, are combined into a single longer
   bit string for DNSSEC as the concatenation "r | s".

NEW:

   The ECDSA signature is the combination of two non-negative integers,
   called "r" and "s" in FIPS 186-3.  The two integers, each of which is
|  formatted as an octet string (in network byte order) of size m, are
|  combined for DNSSEC into a single octet string of size 2*m as the
   concatenation "r | s".


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