Re: [TLS] [Cfrg] Citing specs in specs

[David McGrew <[e-mail]>]

On 03/04/2014 12:02 PM, Watson Ladd wrote:
> Dear all,
> This is provisionally my last word on the matter.
>
> Any consensus based process only works if people will block a largely
> formed consensus for a good reason only. A document being unclear, or
> having unanalyzed security properties, or major issues with regards to
> alternatives not being discussed are good reasons. But the argument
> that Paul I think is making, that until the CFRG produces a draft ala
> RFC 6090 for Edwards curve we cannot use them, is fundamentally
> unconvincing.
>
> First off, let me note that black box implementations of Curve25519
> using the paper are possible: I've written them, Adam Langley has
> written them, as have lots of other people. So that leaves the
> argument that the implementations require too much knowledge about
> cryptography, and that such an issue is worth blocking specs.
>
> The simplest argument for why it is unconvincing is the date of RFC
> 6090 vs. the dates of protocols that included Suite B and ECC. RFC
> 4869 includes Suite B a full 4 years before RFC 6090 was published.
> Now, it is possible that Paul's argument was valid, but simply wasn't
> raised at the time RFC 4869 was being published. But I don't see any
> evidence that implementors of RFC 4869 were hamstrung by the
> nonexistence of RFC 6090.
>
> The second reason I am unconvinced is that I don't see why we
> shouldn't assume the availability of standard references such as the
> Handbook Of Elliptic and Hyperelliptic Curve Cryptography, or volume 2
> of Knuth, to implementors. Such documents are available for far less
> money than ISO standards, and in many regions of North America, Europe
> and Asia, can be found for free in the library. The goal of a spec is
> to explain to humans what is to be done: including excessive
> information makes this much harder.
>
> Finally, Mr. Lambert writes in terms of the "onus" being on CFRG to
> produce such a document, which he calls a "usable normative
> reference". Such a bare assertion is entirely unconvincing.

 From our charter: "The CFRG serves as a bridge between theory and 
practice, bringing new cryptographic techniques to the Internet 
community and promoting an understanding of the use and applicability of 
these mechanisms via Informational RFCs".     We have an opportunity to 
promote the understanding, use, and applicability of newer ECC 
mechanisms, and I hope that we do so.   I woud not say we have the 
"onus" to do so, but if CFRG does anything in this area, it should do 
what its charter says.

> Furthermore, CFRG owes Paul nothing. While I would be happy to review
> such a document for accuracy, I have no obligation to review or
> produce such a document, and the same holds for all the members of the
> CFRG. I can just as easily say that Mr. Lambert has the onus to
> produce such a document.
>
> I've changed my mind about the desirability of such a document as Mr.
> Lambert wants. It would be nice if it existed, and it would be a nice
> project to learn CWEB. However, I see no reason to consider the
> absence of such a document a good reason to block
> draft-josefsson-tls-curve25519-04.

draft-josefsson-tls-curve25519-04 defines a way to use a variant of 
Curve25519 in TLS, by describing the differences between RFC4492 
(Weierstrass ECC in TLS) and Curve25519 processing, and some differences 
and clarifications relative to the Curve25519 processing described in 
the PKC2006 publication.   This is clear from the following quotes:

"Private keys MUST be selected as specified in [Curve25519].  That is, 
private keys are 255-bits numbers with the following properties: ..."

"ECPoint.point differs from the definition of public keys in 
[Curve25519] in two ways: ..."

"Again, in line with [RFC4492] and as a departure from the convention 
chosen in [Curve25519], the x coordinate is converted to a byte  string 
using big endian order. ..."

"The following subsections describe the differences between using 
Curve25519 and the curves defined by RFC 4492 for key exchange in TLS. ... "

Defining a new thing by its differences from two existing things is not 
the best way to get a clear and easy to implement specification.    The 
authors could improve clarity by brining in more of the description of 
Curve25519, or by referencing external work such as an informational 
draft/RFC that describes Curve25519 (preferably the same variant as in 
draft-josefsson-tls-curve25519).

One way that RFC6090 added clarity was by clearly separating normative 
references from informative ones, and relying only on a small sufficient 
set of normative references that were early (pre-1994).   It would be 
good to have this sort of clarity for IETF work on Curve25519.

It would be better to have a separate draft/RFC on Curve25519, as 
described above, because it will be clearer and more conducive to re-use 
of the mechanism across IETF protocols.   If no separate normative 
document is produced, then it will be important for 
draft-josefsson-tls-curve25519 to incorporated a more complete 
description of Curve25519.

Disclaimer: I have not tried to implement 
draft-josefsson-tls-curve25519, and I'm not claiming that it is 
ambiguous.   The authors deserve thanks for writing this document. Our 
aim should be to produce clear, well-understood specifications.   Not 
all RFC are clear or well-understood, but we don't need to emulate that 
precedent.

David



>
> Sincerely,
> Watson Ladd
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>