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

Michael StJohns <> Mon, 30 June 2014 16:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF6691A0392 for <>; Mon, 30 Jun 2014 09:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ci0U6ygl7GIN for <>; Mon, 30 Jun 2014 09:02:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 066691A0389 for <>; Mon, 30 Jun 2014 09:02:11 -0700 (PDT)
Received: by with SMTP id i13so6441458qae.5 for <>; Mon, 30 Jun 2014 09:02:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=65gqcrlQVpjHwpI48vktt9hDPCfkLIufKLswXASiy5U=; b=hMPZnZcUOqJkBydUb/aEKg7QiyqI4btVSknpBqxWz1BSFHC+e+qV88tr768m6bWPRK Tlc8PETidaSErttQj3eA/tqJNoG4AszF6Ci0qhS6lFVZRyHyQ1jd0K3G1M/Tuc7+o45O Q/VkgYzxzq///OwuXW2QxtA1Al/nOuWabomszraKOwdHo1+iFFkHu3eeog7uRHoITXfG VS3cqEBF23TyU/UkXK7iNAUDsoPKTS/HP3tzDh2AhRec28Y2edcNefPMCZmm/SZKhNtM 8qJiHciZN8a0LPqj0odlqfdY4E0FPFth8+rhEYuXKrt3Jyxb2GWdaNc+zw5fS+gAMa7S 2FaA==
X-Gm-Message-State: ALoCoQk6cr7sTegB46vFrg6lnyRMLQD1dH8PopnPOoGKJrzW3iNo7eyjmrTVcxqFSlWJFriAoesj
X-Received: by with SMTP id 67mr59805256qgv.51.1404144130892; Mon, 30 Jun 2014 09:02:10 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by with ESMTPSA id x1sm32634838qaj.19.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 09:02:10 -0700 (PDT)
Message-ID: <>
Date: Mon, 30 Jun 2014 12:02:09 -0400
From: Michael StJohns <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eric Rescorla <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090704070701000209010603"
Cc: "" <>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Jun 2014 16:02:16 -0000

On 6/29/2014 5:29 PM, Eric Rescorla wrote:
> On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns 
> < <>> 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
>>     < <>> wrote:
>>         On 6/28/2014 7:04 PM, Watson Ladd wrote:
>>>         On Jun 28, 2014 3:55 PM, "Michael StJohns"
>>>         < <>> 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:
>     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, 

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: 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