Re: [Cfrg] Citing specs in specs

On 3/2/14, 10:38 AM, "Watson Ladd" <watsonbladd@gmail.com> wrote:

>(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?

No - I’m asking that an RFC be well written and contain enough information
to implement the RFC.

Paul

>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