Subject: draft-ietf-dnsext-ecc-key-10

From: Alfred Hönes <[email-masked]>
Date: Wed, 2 Jan 2008 15:25:51 +0100 (MEZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello,
as already indicated to you, Donald, I also have reviewed
the (formally expired) Internet-Draft authored by you,
            draft-ietf-dnsext-ecc-key-10.

IMHO, should ever DNSSEC want to be successfully deployed,
there will be a strong need for ECC to use (see Section 6
of your draft).  Thus, this document will be needed as an
integral part of any serious DNSSEC deployment at large.

After the separation of DNSSEC keying material from other
keying material potentially to be stored in the DNS has been
performed a few years ago (to accomodate the lack of selective
lookup and response size considerations), it is certainly a
good idea to have a single format for ECC keys and ECC signatures,
respectively, independent from the particular use case.
Doing so simplifies the code base and thereby eventually adds
to the overall security.

I therefore strongly support continuing this effort.

The comments below address all kinds of flaws and issues
I got aware of studying the -10 revision of your memo and
quickly looking at a few details of its evolution so far.

The items below are presented in textual order.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:

   <original draft text>
---
   <modified text>

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.  I also try to accomodate published
RFC-Ed policy on style and punctuation etc. in my proposals.

(1)  General topics

(1a)
Your draft still sometimes makes use of the (mostly) deprecated
first-generation DNSSEC RR type names where it is clear that it
should better refer to *any* type of RR carrying ECC keys or,
to a lesser extent, ECC signatures.
Below, I'll point in detail to the places to be improved.

(1b)
A few citations have slipped past the trailing period of the
sentence they belong to.
Below, I'll point in detail to the places to be corrected.

(1c)
An editorial accident must have happened, replacing all
apostrophes in the text by dollar signs, so please:

           s/\$/'/g

I will not list the details belo unless a text fragment needs
to be quoted for other reasons as well.

(2)  Section 1

(2a)  first paragraph -- instance of (1b)

I suggest to move the references closely to the primary key word, DNS:

   The Domain Name System (DNS) is the global hierarchical replicated
   distributed database system for Internet addressing, mail proxy, and
|  other information. [RFC1034] [RFC1035] The DNS stores data in
   resource records and has been extended to include digital signatures
   and cryptographic keys in some of these resource records.
---
|  The Domain Name System (DNS) [RFC1034] [RFC1035] is the global
   hierarchical replicated distributed database system for Internet
|  addressing, mail proxy, and other information.  The DNS stores data
   in resource records and has been extended to include digital
   signatures and cryptographic keys in some of these resource records.

(2b)  second paragraph -- typo

s/eigest/digest/

(3)  Section 2

(3a)  first paragraph -- re: (1a)

The text refers to "RRKEY" RRs.  What's that?  Perhaps "DNSKEY" !!!
(Shame over all DNSSEC gurus not having detected that flaw over so
many years!)

I suggest to introduce a shorthand notation for 'generic' <key>
RRs carrying ECC keys, and making use of that term subsequently:

   Elliptic curve public keys are stored, using the structure described
|  below, in the DNS within the RDATA portions of key RRs, such as RRKEY
   [RFC4034] and IPSECKEY [RFC4025] RRs.
---                                                                ^^
   Elliptic curve public keys are stored, using the structure described
   below, in the DNS within the RDATA portions of key RRs, such as
|  DNSKEY [RFC4034] and IPSECKEY [RFC4025] RRs.  Below, such resource
|  records will be denoted generically as ECK RRs.
|  Future specifications of DNS RRs designated to store application
|  specific keying material may state their possible ECC variant by
|  simply declaring the RR as an ECK RR in the sense of this Section.

(3b) diagram

In the representation of the first octet of the ECK data structure,
I suggest to remove the hyphens enclosing 'FMT', making the notation
more conformant to the subsequent text that talks about the 'SMFMTABZ'
flag octet.

       +-+-+-+-+-+-+-+-+-+- ...
       |S M -FMT- A B Z|
       +-+-+-+-+-+-+-+-+
       |    ...
---
       +-+-+-+-+-+-+-+-+-+- ...
       |S M  FMT  A B Z|
       +-+-+-+-+-+-+-+-+
       |    ...

Alternatively, perhaps easier to read, more precise, and more common
in style, it should be considered to make the description one-stage
hierarchical for these flags.

To this end,

a) change the above quoted detail to:

       +-+-+-+-+-+-+-+-+-+- ...
       |    ECKflags   |
       +-+-+-+-+-+-+-+-+
       |    ...

b) replace the first line below the (2-part) diagram,

   SMFMTABZ is a flags octet as follows:

  by the following snippit:

------snip------
  The ECKflags field is structured as follows:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |S|M| FMT |A|B|Z|
       +-+-+-+-+-+-+-+-+
------snip------

(4)  Section 5

(4a)  first paragraph

I suggest to make precise reference to the "SIG (0)" RRs that have
survived the DNSSEC rev.1 massacre:

   The signature portion of an RR RDATA area when using the ECC
   algorithm, for example in the SIG and RRSIG [RFC4034] RRs is shown
   below.
---
   The signature portion of an RR RDATA area when using the ECC
   algorithm, for example in the "SIG (0)" [RFC2535][RFC2931] and
   "RRSIG" [RFC4034] RRs is shown below.

I have added double quotes in both cases for the sake of uniformity.
References to bothe RFC 2931 (Normative) and RFC 2535 (Obsoleted,
hence only Informative possible) would need to be added when following
this recommendation.

(4b)  second paragraph

"KEY RR" is too specific there.
For seamless continuation from Section 2, I suggest to change:

   R and S are integers (mod Q).  Their length is specified by the LQ
|  field of the corresponding KEY RR and can also be calculated from the
         v                    ^^^
|  SIG RR$s RDLENGTH. They are right justified, high-order-octet first.
---
   R and S are integers (mod Q).  Their length is specified by the LQ
|  field of the corresponding ECK RR and can also be calculated from the
                              ^^^
|  SIG RR's RDLENGTH. They are right justified, high-order-octet first.

(4c)  explanations of the 'S' EC signature field

For added calrity of the structure of the explanations, I propose
to indent the additional clauses given to the same level as used
in the explanations for the 'R' EC signature field :

        S = ( K^(-1) * (hash + X*R) ) mod Q.

|       S must not be 0.  In this astronomically unlikely event,
             generate a new random K and recalculate R and S.

|       If S > Q/2, set S = Q - S.

        The pair (R,S) is the signature.
---
        S = ( K^(-1) * (hash + X*R) ) mod Q.

|            S must not be 0.  In this astronomically unlikely event,
             generate a new random K and recalculate R and S.

|            If S > Q/2, set S = Q - S.

        The pair (R,S) is the signature.

(4d)  last paragraph -- typo

s/ragne/range/

(5)  Section 6, second paragraph

s/and and/and/

(6)  Section 7, first paragraph

Item (1c) applies.  Also, I suggest to leave RFC 4034 off the ref's
used here, as this text explains procedural/policy aspects, not
on-the-wire format issues.  This, I propose to change:

   Keys retrieved from the DNS should not be trusted unless (1) they
   have been securely obtained from a secure resolver or independently
   verified by the user and (2) this secure resolver and secure
   obtainment or independent verification conform to security policies
|  acceptable to the user.  [RFC4033] [RFC4034] [RFC4035] As with all
   cryptographic algorithms, evaluating the necessary strength of the
   key is essential and dependent on local policy.
---
   Keys retrieved from the DNS should not be trusted unless (1) they
   have been securely obtained from a secure resolver or independently
   verified by the user and (2) this secure resolver and secure
   obtainment or independent verification conform to security policies
|  acceptable to the user [RFC4033] [RFC4035].  As with all
   cryptographic algorithms, evaluating the necessary strength of the
   key is essential and dependent on local policy.

(7)  Section 8 -- typo

s/in/is/ :

   Assignment of meaning to the remaining ECC data flag bits or to
|  values of ECC fields outside the ranges for which meaning in defined
   in this document requires an IETF consensus as defined in [RFC2434].
---                                                          ^v
   Assignment of meaning to the remaining ECC data flag bits or to
|  values of ECC fields outside the ranges for which meaning is defined
   in this document requires an IETF consensus as defined in [RFC2434].

(8)  References

(8a)  incomplete references

Some references given are incomplete, omitting STD or BCP designations,
or even omitting the RFC number, e.g.:

   [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
|    Requirement Levels", March 1997.
---
   [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate
|    Requirement Levels", BCP 14, RFC 2119, March 1997.

I suggest to replace the following ref's with the approriate standard
lines from rfc-ref.txt:

  [RFC2119]  (see above),
  [RFC2434]  (BCP 26)
  [RFC1034]  (STD 13)
  [RFC1035]  (STD 13)
  [RFC2671]  (Note: update in progress!, might refer to w.i.p.)
  [RFC4025]

(8b)  ECC References

The ECC References given in the draft are quite aged and might be
difficult to obtain (as I had experienced already a few years ago).

I therefore would like to propose to make a ref. to the much more
recent 'HEHCC':

  Roberto Avanzi, Christophe Doche, Tanja Lange, Kim Nguyen, et al.,
  "Handbook of Elliptic an Hyperelliptic Curve Cryptography",
  Chapmann & Hall / CRC, 2006, <urn:ISBN:978-1-58488-518-4>.

It might also be useful to quote the readily online SECG documents
from <http://www.secg.org/> , already repeatedly referenced in RFCs.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 2 Jan 2008 11:55:16 -0500

Hi Alfred,

Thank you for these detailed comments which I will review. However, it is very unlikely that this (expired) draft in anything like its current form will be advanced in the near future. Will I agree that the case for ECC in DNSSEC is very strong, it more likely that a much less general approach, targeted at supporting a few specific ECC types at most, would meet with more success, both in the standards process and in deployments, than the generality of draft-ietf-dnsext-ecc-key-10.

Donald
====================================================
 Donald E. Eastlake 3rd      +1-508-786-7554 (work)
 Motorola Laboratories
 111 Locke Drive
 Marlborough, MA 01752 USA
 [email-masked]

-----Original Message-----
From: Alfred HNnes [mailto:[email-masked]] 
Sent: Wednesday, January 02, 2008 9:26 AM
To: Eastlake III Donald-LDE008; [email-masked]
Cc: [email-masked]
Subject: draft-ietf-dnsext-ecc-key-10

Hello,

   <original draft text>
---
   <modified text>

(1)  General topics

(1a)

(1b)

(1c)

           s/\$/'/g

(2)  Section 1

s/eigest/digest/

(3)  Section 2

(3b) diagram

       +-+-+-+-+-+-+-+-+-+- ...
       |S M -FMT- A B Z|
       +-+-+-+-+-+-+-+-+
       |    ...
---
       +-+-+-+-+-+-+-+-+-+- ...
       |S M  FMT  A B Z|
       +-+-+-+-+-+-+-+-+
       |    ...

To this end,

       +-+-+-+-+-+-+-+-+-+- ...
       |    ECKflags   |
       +-+-+-+-+-+-+-+-+
       |    ...

------snip------

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |S|M| FMT |A|B|Z|
       +-+-+-+-+-+-+-+-+
------snip------

(4)  Section 5

(4a)  first paragraph

(4b)  second paragraph

s/ragne/range/

s/and and/and/

(7)  Section 8 -- typo

s/in/is/ :

(8)  References

  [RFC2119]  (see above),
  [RFC2434]  (BCP 26)
  [RFC1034]  (STD 13)
  [RFC1035]  (STD 13)

(8b)  ECC References

Best regards,
  Alfred HÎnes.

--