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

[Michael StJohns <[e-mail]>]

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.

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".

Implication: The IETF will have to make some pronouncement or assurance 
as to the viability of Curve25519 to the wider world.  The IETF will 
have to maintain the Curve25519 standard.

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.  We are not - at least at this time - a 
cryptographic standards body.  The change to become one should be 
intentional, rational and measured.

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.

>
>
>     The IETF does not own change control on either of these.
>
>
> How does this matter? Unlike protocols, cryptographic algorithms aren't
> really versioned. If we wanted to do a new version of HMAC, we would
> presumably call it HMAC-2 or something. What's needed is a stable
> reference.

Cryptographic algorithms are not versioned - mostly  (Although see 
co-factor changes to ECDH for example), but Cryptographic Standards 
certainly are.  RSA has gone through 5 or 6 versions, FIPS186 is now 
"-4", etc.

The algorithm part of a cryptographic standard is usually the least 
controversial and most stable part of the standard.  The hard stuff is 
the translation and representation language (for example the argument 
about Curve25519 with respect to big or little endian representation of 
the big integers).  There are also sometimes enhancements or new 
guidance's that can be added:  For example key pair generation for EC 
key pairs in F(p) - one version is to randomly generate a number in the 
interval [1..P), another one is to randomly generate a number in 
2^(n+64) and take that mod P.

In short, the algorithm is just a small part of the standard.

The cryptographic standard has to give us (the IETF) an interface we can 
use to the cryptographic algorithm.    If that standard is not an IETF 
standard, then we take what we're given and hope it meets our needs.

I find the fact that the current TLS curve25519 draft directly 
references DJB's paper problematic as the paper is missing even the 
basics necessary for what I would consider a cryptographic standard.   
DJB's paper is equivalent to no more than section 5 of the RSA 2.2 
http://www.emc.com/emc-plus/rsa-labs/pkcs/files/h11300-wp-pkcs-1v2-2-rsa-cryptography-standard.pdf 
standard.  What's needed is a document that fills in the rest and that 
the TLS (and IPSEC and SMime and... can reference) and it's unclear if 
we have the time, resources or desire to do this.

So yes, I think the question of IETF standard or Informational RFC is 
relevant.

Mike


>
> -Ekr