Subject: [dnsext] Summary WGLC: draft-ietf-dnsext-ecdsa

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 19 Jan 2012 12:57:13 -0500

Dear colleagues,

This working group last call has completed, during the last call we had 
enough support and reviews to meet the WG requirements.

During the last call a few suggestions about how to improve the text 
were made, the editors have applied these to the latest version.
During the last call a suggestion was made to optimize the binary 
formats, that proposal did not receive any support.

I will be submitting this document in the next few days to the IESG.

	Olafur
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Rene Struik <[email-masked]>
Date: Thu, 19 Jan 2012 13:42:08 -0500

Hi Olafur:

I may have missed this, but I never saw an announcement for WG last call.

More importantly, though, the last versions do not really seem to have
addressed my comments sent prior to the July 2011 meeting in Quebec.

Rene

On 19/01/2012 12:57 PM, Olafur Gudmundsson wrote:
>
> Dear colleagues,
>
> This working group last call has completed, during the last call we
> had enough support and reviews to meet the WG requirements.
>

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363

---

From: Rene Struik <[email-masked]>
Date: Thu, 19 Jan 2012 13:53:24 -0500

Hi Olafur:

My comments on the earlier draft were sent July 21, 2011 (with
apparently an update just sent out ealry January, during the Xmas break).

I would appreciate if the authors indicate for each of the comments
below that they did not wish to accommodate their rationale.

Best regards, Rene

http://www.ietf.org/mail-archive/web/dnsext/current/msg11483.html

  Re: [dnsext] WGLC: Elliptic Curve DSA

------------------------------------------------------------------------

  * /From/: Rene Struik <rstruik.ext at gmail.com
    <mailto:[email-masked]>>
  * /To/: Olafur Gudmundsson <ogud at ogud.com <mailto:[email-masked]>>
  * /Cc/: dnsext at ietf.org <mailto:[email-masked]>
  * /Date/: Thu, 21 Jul 2011 19:01:07 -0400
  * /In-reply-to/: <4E14D100.5010705 at ogud.com
    <mailto:[email-masked]>>
  * /References/: <4E14D100.5010705 at ogud.com
    <mailto:[email-masked]>>
  * /List-id/: DNS Extensions working group discussion list
    <dnsext.ietf.org>

------------------------------------------------------------------------

Dear colleagues:

Please find below my editorial and technical comments on draft-ietf-dnsext-ecdsa-01.

Best regards, Rene

==

Summary of the draft:
The draft specifies two two elliptic curve signature algorithms for use with DNSSEC that were heretoforth not defined,
viz. ECDSA with suite B curves and hash functions at 128-bit and 192-bit crypto bit strength). As pointed out, the main 
rationale for doing so are that use of ECDSA and ECDSA public keys (a) allows smaller size data fields; (b) may allow
computational savings; (c) introduces algorithms with crypto primitives of equivalent cryptographic bit strength.

==

Summary of comments:

1) Editorial:
The draft would benefit from tightening up some of the language, especially since this may lower the chance of confusing 
noncryptographic people.

2) Technical:
The draft results in data fields of size 4n octets, where n is the octet-length of the underlying curve. In fact, one can 
do better and use data fields of size 3n octets, without loss of functionality.

==

Detailed comments:

--

I. Editorial and semi-editorial comments:

(E-a) p.2, Clause 1, first para: 
With RSA, "key" should read "modulus" (e.g., "using 1024 or 2048 bit moduli"). The same remark applies to interchanges 
of keys and moduli with RSA, e.g., third para ("3072-bit keys").

(E-b) p.2, Clause 1, second para:
I suggest adding the following references: 
(1) for P-256 and P-384, xref FIPS Pub 186-3; 
(2) for ECDSA, xref FIPS Pub 186-3 (esp. necessary, so as to specify how to map hash output (bit string) to an integer in Zn); 
(3) SHA-256 and SHA-384, xref FIPS Pub 180-3.
{Note RS: With the availability of RFC 6090 "Fundamentals of ECC", should one refer that RFC as well, besides FIPS Pub 186-3?}

(E-c) p.2, Clause 1, second para:
Replace DS RR by delegating signer resource record (DS RR).

(E-d) p.2, Clause 1, third para:
This para suggests that public keys on the curve P-256 have size 256 bits, but this conflicts the representation in Clause 4, 
first para, where their (affine) representation is 512 bits.
{BTW - I strongly suggest using "octet" units, rather than "bits", since this seems to better align with other crypto-related 
IETF documents, and non-IETF documents (ANSI, SECG, etc.).}

(E-e) p.2, Clause 1, third para:
This para attemts to quantify comparisons of the size of RSA and ECDSA public keys, but does omit this for RSA signatures and ECDSA
signatures. Suggest to correct (for 128-bit crypto bit strength).

(E-f <http://www.surfcanyon.com/search?f=sl&q=f&partner=wtigca>) p.2, Clause 1, fourth para, l.2:
The term "matching" is somewhat unfortunate: why not state that the curve and the hash function are picked with the same cryptographic
bit design strength?

(E-g) p.2, Clause 1, fourth para, l.6:
Unkeyed hash functions do not have a key, so please replace "...is half the length of the key" by "... is half the output size (in bits)".
{Note RS: please note the "(in bits)" phrase, which should also be added to the corresponding statement on cryptographic bit strength for 
public keys (cf. same para, l.4-5: change to "...is half the bit-length of the key"). 

(E-h) p.2, Clause 1, fourth para, l.6:
Replace "using matched strength" by "using the same cryptographic bit strength".

(E-i) p.2, Clause 1, fourth para, l.7:
The notion of "weaker half" of a signature algorithm is somewhat confusing, since, e.g., with ECDSA, while the strength is not entirely 
proven (to my knowledge), it depends on at least three factors, including (1) underlying hash function; (2) underlying ECDHP; 
(3) ECDSA peculiarities. Changing "choosing the weaker half of" by "choosing the weaker cryptographic primitive [or: component] of the 
signature algorithm.

(E-j) p.2, Clause 1, fourth para, l.7-10:
The RSA example would be clearer if <http://www.surfcanyon.com/search?f=sl&q=if&partner=wtigca> one would state that RSA with 2048 modulus is believed to have 112 bit cryptographic bit strength,
since then the discussion about equivalent bit strength becomes simply an exercise in comparing this with the presumed strength of
SHA-256 (half the output size or 128-256/2).

(E-k) p.2, Clause 1, fifth para:
Performance of cryptographic operations is highly platform-dependent, so absolute numbers should be avoided at almost all cost. Moreover, it
is (of course) dependent on the crypto primitive in question -- something that is not mentioned (e.g., is the factor 5x computational advantage
ECDSA signing compared to RSA signing for P-256 vs. RSA-3072, or for something else?). I would suggest to replace "Signing with ECDSA is" by 
"signing with ECDSA may be" and adopt the corresponding absolute language for the verification numbers accordingly as well. Moreover, please 
pick a curve for which these numbers apply. 
{Note RS: as a side note: to illustrate that one has to be careful here, please cf. to Slide 48 of
http://www.ietf.org/proceedings/78/slides/saag-7.pdf, which suggests that for some platforms, both signing and verification for ECDSA is faster
than with RSA (and not just signing, as in this draft).}

(E-l) p.3, Clause 1, sixth para, l.4:
Perhaps, replace "is copied liberally from" by "borrows heavily from"?

(E-m) p.3, Clause 2, l.2:
Replace "the implementation of SHA-384 in DNSSEC" by "the use of SHA-256 in DNSSEC" (after all, now it seems one discusses the implementations 
of SHA-256 and SHA-384 themselves [at least, to me, as nonnative speaker]).

(E-n) p.3, Clause 3:
This clause discusses the need for corresponding parties to have access to the same system-wide parameters, in casu for ECDSA. 
However, the remainder of this clause only talks about the elliptic curve domain parameters (P-256, resp. P-384), but does not mention the 
hash function (SHA-x, etc.) underlying ECDSA, the encoding rules (bit/octet order, etc.) for messages to be signed, etc. This is confusing.

(E-o) p.3, Clause 4, first para:
The x- and y-coordinates of public key Q should be properly introduced. Of course, crypto people know that this corresponds to the affine
representation of points on the corresponding prime curve, but this should be left less as guess work.
In fact, I would strongly urge to use the same representation convention for public keys as used <http://www.surfcanyon.com/search?f=sl&q=if%20used&partner=wtigca> elsewhere, such as, e.g., wiht RFC 3279 
(Clause 2.3.5, ECPoint), with ANSI X9.62-1999 (4.3.6), or with SEC1 or RFC5480. This format nicely allows unique representation of the point
of infinity (0x00), affine points (0x04 | x | y), and compressed points (PC=0x02 or 0x03 | x). Thus, one can represent Q as (0x04 | x | y).

(E-p) p.3, Clause 4, second para:
The signature components r and s are integers, but r | s is an octet string. Please add the following text a the end of the paragraph:
"where "r" and "s" are represented each as octet string, with size the octet size of the (prime) order of the underlying prime curve.

(E-q) p.4, Clause 4, third para:
The two bulletized items should also refer to the underlying ECDSA specification (FIPS Pub 186-3) as well.

(E-r) p.4, Clause 4, fourth para, l.1:
It seems that one cannot state "MUST support" and then offer an "and/or" option. Suggest to change this to support for both signing *and* 
verification (so as to avoid ambiguities here).

(E-s) p.4, Clause 5, second para, l.3:
Not sure why one would not just refer to SHA-1 (which is Algorithm 1, as defined in Clause 11 of RFC 5155). If one somehow does not wish
to admit to using SHA-1, it would really help to add clause numbers, so as to help the reader find all this (some IETF specifications are 
extremely large and making life easier should be explicit goal of writing).

(E-t) p.4, Clause 6, second para:
The picks for TBA-1, TBA-2, and TBA-3 are really obscure; this is much clearer once one disects the examples in Clause 6.1 ff. Also here, 
why not make life easier on the reader and change the last sentence to "The examples use the following algorithm codes:
Code 4 for ECDSAP256SHA256 (TBA-1), ...", etc?

(E-u) p.6, Clause 8, l.2:
Again, please change "half the size of the key" to "half the bit-size of the underlying curve". (Considering the pick in Clause 4 for Q, half 
of the key would be the bit-size of the curve, rather than half the bit-size).

(E-v) pp.3-4, Clause 4 (or, perhaps, more general remark):
Currently, the clause does not make for easy reading, since it just defines the signature format and the public key format and does not
even hint at the clauses in the corresponding base line documentation (RFC 4033,4034, 4035) where all this "falls into place".
I would strongly suggest adding more clues, so as to make this for less esoteric reading. Why not include some text that captures the following
(here, mentioned for 128-bit crypto strength):
The DNSKEY Resource Record is defined in RFC 4034, Clause 2.1.
-the algorithm field (RFC4034, 2.1.3) is set to ECDSAP256SHA256 {TBA-1};
-the public key is set to the representation for the public key introduced in Clause 4;
etc.
Note RS: RFC 4034 already includes Algorithm Type 4 for ECC (cf. Annex A.1), but currently this is undefined.

--

II. Technical comments:

(T-a) p.3, Clause 4, first para:
In this para, the ECDSA signature is 2n octet field, as is the public key Q, where n is the octet size of the order of the underlying curve.
Since the size of the public key Q is important (cf., also Clause 1, third para, last sentence), why not be somewhat more economical here and
represent Q by its x-coordinate only? This does not seem to lead to any loss of functionality, whereas shaving off 25% of the data field 
overhead, from 4n octets to 3n octets. Some details follow:

Underlying motivation:
(1) The point of sending the public key Q along seems to be that one has an identifier for the public signature verification key that one also has
in a white list on the verifier's machine? (If one does not have a white list check on the verifier, the authentication procedure is completely
broken, since then anyone can produce valid signatures.) This assertion seems to be validated by Clause 5.3.1 of RFC 4035 (which discusses 
authentication).
(2) To identify a public key Q residing on a verifier's machine, one does not need the entire public key; the x-coordinate suffices: after all,
no two public signature verification keys belonging to valid signers will have the same x-coordinate (for otherwise, one knows the private key 
of the other).

Suggested improvement:
The above assertions lead to the following 33% size improvement, with following (very modest) changes required:

1) Signing side:
-Clause 4, first para:
Represent the public key Q by its x-coordinate, rather than by the pair x-coordinate and y-coordinate (here, we denote the result by Q');
-Data to be signed: hash data with Q' included, rather than Q (this has no security implications at all, as one can easily see).

2) When verifying an ECDSA signature, "decompress" first:
- Use Q' as index to recover the key Q at verifier's machine;
- Use Q to veerify the ECDSA signature by computing R'=(1/s) (eG +rQ), where e= h(m,Q') and checking that f(R')=r (mathematical short-cut 
notation for ECDSA signature verification).

Final notes RS:
1) If one wishes, one could send either Q'=x-coordinate of Q or Q itself (in case one somehow feels that one needs options (should not be 
necessary, though)). In that case, the "normal" representation of elliptic curve points -- affine representation of Q = (0x04, x, y); new 
x-coordinate only representation Q' = (0x01, x) would do. This does (a) not conflict any ECPoint representations already in use; (b) this does 
allow different representations of the public key in the DNSKEY RR (RFC 4034, Clause 2.1.4), so doing away with need to define new algorithm id 
(RFC 4034, Clause 2.1.3).
2) RFC 4035, Clause 5.1.3 (authentication procedure) already caters for the scenario that one may have "more than one match", so - if one really 
wishes one could compute both Q and -Q from Q' (i.e., compute both (x,y) and (x,-y) given x-coordinate Q') and run the authentication algorithm 
as already specified. 
2) Security is exactly the same as with original construct.
3) There are no nontechnical considerations to be concerned about (note that Q' does not provide any insight on the y-coordinate of Q).

Best regards, Rene

On 06/07/2011 5:17 PM, Olafur Gudmundsson wrote:
> Dear Colleagues
>
> This message starts a Working Group Last Call for
> "Elliptic Curve DSA for DNSSEC" located at
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecdsa-01.txt
> This document is on Standards track.
>
> This WGLC will conclude on midnight on July 21'th UTC.
>
> Please review the document and sent a statement that you reviewed the
> document.  If the review raises any issues, please note what they are.
> Remember that we need a minimum of 5 reviewers.
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 11:06:28 -0800

> I may have missed this, but I never saw an announcement for WG last call.

That statement is completely untrue: you responded to that announcement.

> addressed my comments sent prior to the July 2011 meeting in Quebec.

Correct. You asked for many changes, and no one else supported your request.

--Paul Hoffman

---

From: Rene Struik <[email-masked]>
Date: Thu, 19 Jan 2012 14:11:55 -0500

Hi Paul:

So, was the WGLC the one in July 2011? Olaf did not reference that WGLC,
which was eons ago (half a year). Now, there seem to have been three
versions since  2 1/2 weeks, with nothing prior for 5 1/2 months. Some
more clarity, except a short line that seems to be out of the blue would
be appreciated.

I am curious as to why "nobody" supported squeezing down message sizes.
Was this seriously considered? What was the technical rationale for not
supporting my modest suggestions.

What is your rationale for not supporting this???

Shouldn't technical merit of comments be discussed openly. I thought
IETF was all about openness.

Rene

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 11:30:12 -0800

On Jan 19, 2012, at 11:11 AM, Rene Struik wrote:

> So, was the WGLC the one in July 2011?

Yes. You replied on that thread, according to the WG archives.

> Olaf did not reference that WGLC,
> which was eons ago (half a year).

Which part of the word "Last" are you confused about? :-)

> Now, there seem to have been three

There was a WGLC with an end date. There were comments during WGLC. Some comments asked for changes, and there were multiple people who supported those changes. The authors (Wouter and I) made those changes. There were some comments from you that asked for extensive changes, and no one supported your request. We didn't make those changes.

> supporting my modest suggestions.

I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion.

> What is your rationale for not supporting this???

If one person proposes a technical change to a spec and no one else agrees with them, it is not a good idea to make that change.

> Shouldn't technical merit of comments be discussed openly.

You did openly discuss the technical merits of your proposal. No one supported your assertions.

> I thought

No, the IETF is about many things. It is also openness, about not letting one person derail standards actions, about not unnecessarily encumbering protocols with questionable IPR if it doesn't add much value, and about making progress.

--Paul Hoffman

---

From: Rene Struik <[email-masked]>
Date: Thu, 19 Jan 2012 15:20:31 -0500

Hi Paul:

I am not a lawyer, but I honestly do not see the IPR flags (or ghosts?) you seem to see in just about any technical suggestion. Sending just the x-coordinate of an affine elliptic curve point Q:=(x,y) has been suggested eons ago, where eon > 20 years (possibly, in Koblitz's 1985 paper).

It seems that one can block any change to one's own drafts by raising fear, uncertainty, and doubt about IPR ghosts that are not there, and purportedly triggered by suggestions by others who take time to review this on technical merit and that seem ill-founded. If you believe I am wrong here, please communicate with me offline here.

Why not even taking the editorial inaccuracies into account?

Rene

(end of discussion for me)

==

I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion

It is also openness, about not letting one person derail standards actions, about not unnecessarily encumbering protocols with questionable IPR if it doesn't add much value, and about making progress.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 19 Jan 2012 16:05:01 -0500

>I cannot speak for everyone, but I can say why I didn't support it: it would possibly involve IPR hassles. The IPR hassles are not worth it here, in my opinion.

+50....

EC point compression is a known IPR rat hole.  AIRC - The group chose to slap a thick timber across the hole and glue and nail it down.

Mike

---

From: Rene Struik <[email-masked]>
Date: Thu, 19 Jan 2012 16:14:20 -0500

There may be IPR about representing Q:=(x,y) in a compressed format
Q':=(x,y'), where one can *faithfully* reconstruct Q from Q' and the
elliptic curve domain parameters alone (so-called lossless compression).
To my knowledge, any *lossy* compression technique, including
representing Q:=(x,y) by its x-coordinate x only, is not covered at all
by IPR.

Fear, uncertainty, and doubt should not be based on not understanding
the difference between these two compression methods (or portraying
everything under the universe vaguely similar suspect). Sadly, it
apparently is. (But, perhaps, an "favored" way to mute discussion on
technical merit and portraying the world in black-and-white terms (the
nuclear option, so to speak).)

-50

Rene

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 13:59:31 -0800

On Jan 19, 2012, at 12:20 PM, Rene Struik wrote:

> I am not a lawyer, but I honestly do not see the IPR flags (or ghosts?) you seem to see in just about any technical suggestion.

Fine. I do see IPR issues, and so do others. Why should your single voice be more valid than our group of voices, particularly on a subject where none of us can prove anything either way?

> It seems that one can block any change to one's own drafts by raising fear, uncertainty, and doubt about IPR ghosts that are not there, and purportedly triggered by suggestions by others who take time to review this on technical merit and that seem ill-founded.

You are badly misrepresenting what happened. You made a proposal *that no one else supported*. No one "blocked" your proposed change.

> If you believe I am wrong here, please communicate with me offline here.

You making this offer in public is disingenuous: you and I *have* had this discussion offline, both when you were a Certicom employee and afterwards. Pretending that we didn't already have the discussion, or that having the discussion again even though neither of us have any better facts would be valuable, is not useful to advancing this document.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 19 Jan 2012 17:09:32 -0500

Dear colleagues,

> You are badly misrepresenting what happened. You made a proposal *that no one else supported*. No one "blocked" your proposed change.

Olafur (the shepherd for this document) is travelling, so in his stead
and with my chair hat on, I want to underline what Paul said there.
There was a proposal on the list; there was zero follow-up, and nobody
expressed support for adding it.  The document editor didn't agree it
was a good idea.  Therefore, the change doesn't go into the document.
That's the end of the story: we don't need to debate whether there is
IPR here, make charges about FUD, or anything else.  There is no
consensus, rough or otherwise, in favour of the change, and so it's
not a candidate to be the product of the WG.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]