Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

[Michael StJohns <[e-mail]>]

On 6/29/2014 5:29 PM, Eric Rescorla wrote:
>
>
>
> On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     In line below.
>
>
>     On 6/28/2014 7:51 PM, Eric Rescorla wrote:
>>
>>
>>
>>     On Sat, Jun 28, 2014 at 4:36 PM, Michael StJohns
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         On 6/28/2014 7:04 PM, Watson Ladd wrote:
>>>
>>>
>>>         On Jun 28, 2014 3:55 PM, "Michael StJohns"
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>         >
>>>         > On 6/28/2014 6:24 PM, Salz, Rich wrote:
>>>         >>>
>>>         >>> *sigh* If the IETF is really going to get into the
>>>         business of standardizing
>>>         >>> > crypto, we need to get the process for doing so right
>>>         the first time rather
>>>         >>> > than just plugging it in to TLS and hoping we don't
>>>         have to redo it over and
>>>         >>> > over again.
>>>         >>
>>>         >> Agree.  But again, it's "back into the business"  Because
>>>         we did it before with TLS1, IPsec, and ECC curves therein.
>>>         >
>>>         >
>>>         > Um... huh?  Can you provide specifics about which
>>>         cryptographic algorithms  we standardized?  This is news to me.
>>>
>>>         Camellia, RC4, HMAC. Of course we still screwed up TLS 1.0
>>>         by ignoring lessons from IPSEC.
>>>
>>>
>>
>>         I can't find an RC4 RFC, but Camellia and HMAC are both
>>         Informational rather than Standards track.
>>
>>
>>     I'm not sure why this is a relevant distinction. These documents are
>>     published by IETF and we make normative references to them in
>>     Standards Track documents. See, for instance:
>>
>>     http://datatracker.ietf.org/doc/rfc2104/referencedby/
>
>     Hi Ekr - thanks for the question.
>
>
>     I think the question you're asking is "Why is the distinction
>     between Internet Standard and informational RFC relevant to the
>     use of Curve25519"?  That's the one I'll try and respond to.  Let
>     me know if I got the question wrong.
>
>
> Sure, we can take it as that question.
>
>     Fact: Almost any one who wants to can publish an Informational RFC.
>     Fact: Informational RFCs are not Internet Standards. They may be
>     products of the IETF, but do not have to be.  They tend to be
>     evaluated less strenuously than standards track RFCs.
>     Fact:  Every single cryptographic standard that the IETF has
>     published as an RFC has been Informational.  None of them appear
>     to be products of the IETF, but I could have missed one.
>     Fact:  The IETF has made no claim as to the strength of viability
>     of crypto published as Informational RFCs. E.g. we're just a user
>     of cryptography, not an originator.
>
>     Observation:  The Curve25519 documents could have been published
>     as Informational along the same basis as above.  Some of them may
>     still be.
>     Observation:  The CFRG was asked to comment on Curve25519 -
>     specifically to give a recommendation.
>     Observation:  At least one person on this email thread (and others
>     elsewhere) have used the phrase "standardize Curve25519" - another
>     used the word "preferred".
>
>     Tentative Theory: There is some desire to publish Curve25519 as an
>     IETF Standards track document.  That is to give Curve25519 the
>     mantle of "cryptography acceptable to the IETF".
>
>
Sorry - delete from "That is to give..." - this was a bad edit.  I not 
actually sure what that last sentence was supposed to be.

> This is where you lost me. Consider the following sequence of events:
>
> 1. Someone publishes a Curve25519 Informational RFC.
> 2. The CFRG sends the IETF a message saying "We think the Curve25519
> is a good curve and the IETF should adopt it for use in IETF protocols"
> (presumably in more formal language).
> 3. The TLS WG publishes a standards track document (assuming for
> the moment that we believe that we are going to adopt any standards
> track ECC cipher suites) which refers to the RFC published in #1.
>
> To the best of my knowledge, there isn't any procedural problem with
> doing this and it would be effectively what we did with, for instance, 
> HMAC.

I thought I covered this by:
> If I am in fact misreading the tea leaves, and a Curve25519 
> cryptographic standard is to be published to the IETF as a DJB 
> contribution and Informational and not a product of the IETF, then 
> there are no implications and I'll leave this in peace.  But anecdotal 
> evidence suggests that this is in doubt.

What DJB has written is the basic algorithm.  What needs to be written 
is the adaptation of that algorithm into a form that provides "enough 
detail to ensure interoperability between different implementations" 
[quote from RFC2040 on RC5].  My belief is that document should not be 
solely a TLS document.   If that document is written as an external DJB 
document and we reference it for TLS, that's fine - that's what we did 
with HMAC.   If instead we choose to write that document as a product 
and standard of the IETF, that's a whole different matter.  If we choose 
to "prefer" it then that's an even more interesting matter.

Up to this point the IETF hasn't "owned" a cryptographic standard. 
Creating an IETF standard based on Curve25519, if that happens, will be 
an endorsement, however indirect, of the underlying cryptographic 
constructs by the IETF.


> Do you believe that the IETF made some statements about the quality
> of HMAC by publishing RFC 2104 and including HMAC in our protocols?
>

No.  But HMAC was simply a re-publication by the authors to allow for 
better access by implementers, not an IETF standard.   Also, HMAC was 
more of a cryptographic mode rather than a cryptographic standard - the 
security of the mode was based on assumptions of the underlying hash(es) 
- less fundamental analysis was required so our use of it wasn't suspect.


>
>
>     That last implication is new for the IETF.  AFAIK, each and every
>     cryptographic algorithm and mode documented by the IETF has an
>     owner elsewhere and such claims of assurance are made there and
>     maintenance and changes are done there.
>
>
> Can you tell me who that someone else is for HMAC or RC4?

At the time of publication, HMAC was the product of its authors and a 
republication of: 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430. These 
days its part and parcel of FIPS198.

With respect to RC4, I can't find that the IETF ever published an RFC 
documenting RC4 - but in any case it was a Ron Rivest trade secret that 
leaked and which Ron's been nice about letting us use - I'm not sure of 
its current legal status.   OTOH, Rivest did author RFC2040 on RC5 and 
RC5 modes.   It has this line in it: "This memo is a restatement of 
existing published material. "


Later, Mike