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

[Watson Ladd <[e-mail]>]

On Thu, Mar 13, 2014 at 10:56 PM, Paul Lambert <[e-mail]> wrote:
>
>
> On 3/5/14, 7:11 PM, "David McGrew" <[e-mail]> wrote:
>
>>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.
>
> I was never advocating blocking these specifications.

I have to apologise: I misread your initial email as saying that the
Curve25519 was an insufficient normative reference as meaning that it
didn't define things clearly enough, and therefore you thought the
spec was ambiguous. I realise now you meant that, independent of the
citation issue, you wanted more documentation.

>
> The use of Edwards and Montgomery curves for Internet protocols are
> relatively new.  There are gaps in the documentation of these new
> mechanisms that should be filled at some point. I was trying to
> constructively point to worked examples from twenty years of ECC
> specifications.

And that is currently being worked on by Robert Ransom, who seems to
have taken over right now from myself. I'll probably jump in this
weekend and write up the algorithms that are required to compute point
multiples, together with the precautions to avoid side channels.

The big problem with Edwards is we don't have a good point format yet.
Robert Ransom has a good idea, but I haven't seen explicit formulas
for encoding and decoding yet.

Sincerely,
Watson Ladd
>
> Paul
>
>>>
>>> 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
>>>
>>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin