Re: [Cfrg] Citing specs in specs

(Moving to TLS because that is where this draft is)

On Sat, Mar 1, 2014 at 8:02 PM, Paul Lambert <paul@marvell.com> wrote:
>
> The curve25519 is NOT a good normative reference IETF protocols.
> It¹s useful as an informative reference on the curve
> Selection, but lacks clarity and completeness on
> implementation details.

Since when does a normative reference contain implementation details?

IEEE 745 doesn't, RnRS doesn't, the ANSI C standard doesn't, POSIX
doesn't, etc. This doesn't affect being able to judge compliance which
is the normative function of a spec.

If you want RFCs, try writing a NTP protocol implementation (that is,
a client that keeps track of the current time accurately) without
understanding PLL control theory. This isn't in the spec at all, but
is completely necessary to get a functioning implementation.

Furthermore, the Curve25519 paper describes a very clever
implementation in great detail.

>
> One of the main reasons 25519 is popular is that a nicely optimized
> open source library is available for some of the more
> Useful curve functions.
>
>
> On 3/1/14, 9:21 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
>>[[ Subject line changed to be relevant to the discussion ]]
>>
>>On Mar 1, 2014, at 4:16 AM, Robert Ransom <rransom.8774@gmail.com> wrote:
>>
>>> On 2/28/14, David McGrew <mcgrew@cisco.com> wrote:
>>>> I am wary of relying on the curve25519 paper as a normative reference.
>>>> Perhaps your goal here is to provide an informational document (the
>>>> draft that you mention above) that offers implementation guidance,
>>>> instead of a normative reference?
>>>
>>> RFC 4492 (ECC ciphersuites for TLS) cites ANSI X9.62, IEEE 1363, and a
>>> few documents labeled as Œstandards¹ by the corporations which
>>> authored them as normative references.  It cannot be implemented
>>> without the information in ANSI X9.62 and IEEE 1363.  ANSI X9.62 is
>>> available from ANSI for 100 USD; IEEE 1363 is available from ANSI for
>>> 168 USD.
>>
>>I have been told by implementers that you can implement RFC 4492 just
>>fine without those references, only with [SECG]. What information in the
>>ANSI and IEEE spec do you feel is needed to implement 4492?
>
> We should be working here to document Edwards/Montgomery curves to
> the same level of clarity as the SECG documents.  Perhaps we
> could be even more concise and complete - SECG left out
> details of most optimizations.
>
> My favorite examples of clarity are:
> http://www.nsa.gov/ia/_files/nist-routines.pdf
>
> http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf
>
> Right now there is no equivalent documentation as the nist-routines.pdf
> for Edwards/Montgomery curves.

So your argument is that until such a document is written, the IETF
should not approve any RFC containing such a curve because absent such
a document, the specification is unclear? I disagree: the information
you demand to be placed into the spec can be figured out in a few days
of research in the library. There are numerous standard references on
bignum arithmetic, and given this with the paper of Montgomery, there
is nothing else that is needed to write an implementation that is
correct.

Sincerely,
Watson Ladd
>
> Paul
>
>>
>>> It is true that the author of the Curve25519 paper is neither a large
>>> corporation nor an organization with ³Standards² in its name, and did
>>> not label Curve25519 as a Œstandard¹ in the paper's title.  However,
>>> the Curve25519 scalar multiplication function specified in the paper
>>> became a Œstandard¹, in the sense which IETF claims to use the word,
>>> when software developers came to the rough consensus that it was a
>>> good cryptographic primitive to use, and wrote and deployed running
>>> code which implements it.
>>
>>That is not the sense which the IETF claims to use the word.
>>
>>> The Curve25519 paper is available for free
>>> from the URL <http://cr.yp.to/ecdh/curve25519-20060209.pdf>.
>>>
>>> What is your objection to using the Curve25519 paper as a normative
>>> reference for the standard Curve25519 scalar multiplication function?
>>
>>The paper is at a URL; the contents of that URL can change any time. RFCs
>>can sometimes make normative reference to URLs that seem very stable, and
>>Dan's might or might not be. Dan has a history of poking at the IETF
>>(sometimes for good reason), so it is quite believable that he might
>>change the contents of that URL just to make a point. Having a more
>>stable reference would clearly be better.
>>
>>--Paul Hoffman
>>_______________________________________________
>>Cfrg mailing list
>>Cfrg@irtf.org
>>http://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg

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