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

Eric Rescorla <ekr@rtfm.com> Sun, 29 June 2014 21:30 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5021D1A0027 for <tls@ietfa.amsl.com>; Sun, 29 Jun 2014 14:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRtEjkMf-6a3 for <tls@ietfa.amsl.com>; Sun, 29 Jun 2014 14:30:27 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C2F1A0026 for <tls@ietf.org>; Sun, 29 Jun 2014 14:30:26 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w61so7235348wes.15 for <tls@ietf.org>; Sun, 29 Jun 2014 14:30:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hp+cGrOPJexdnZydCcfyo2z4NyRDuAMrLx8s2/b5WVc=; b=DvqHh+hVGuWBWA7c3LhwmKKkFOqJqtAjRnIZz4JFfROfVd8gESSVhXVKF7u5uigYq5 dS1agegpei/ZIqDdQjmSI5SJqFQRJlWonK4b47tuva7h4Piuzm7kx23MxxtbQnB5XaVC LEt5vWGs7KJBYJKmIFwXuZvfb0Ijllq0hS+2fAThnzB7UShHjEV26ajgl0ktQm0NZK6E zTLLIKbTvit872g4kMA5LtAdc5OmPJBzAFUCDYLCuSPHG+x6E7aqmHSw0nPqXCf7xw/R 9+7+7lCYeiFmQLI1exv0tdZ/MZSNgddTW56EGQzFfoXWV5OFQs1fsBV56PVJyudZe528 bKDQ==
X-Gm-Message-State: ALoCoQkw/t6X2ijdRgMx7x5zC77vGcctYzNyuSomTL+viuiJdbwu1jUvu1Q86yjZExSa+/I/N4PT
X-Received: by 10.180.81.72 with SMTP id y8mr25284771wix.7.1404077425078; Sun, 29 Jun 2014 14:30:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.57.202 with HTTP; Sun, 29 Jun 2014 14:29:44 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <53B07640.2050000@nthpermutation.com>
References: <53AC97B8.2080909@nthpermutation.com> <CABcZeBN5uY4bteXW=OFC1z3ANoSC8AqxG6E6artdOKPF=VxdJg@mail.gmail.com> <53AD56D2.7060200@cs.tcd.ie> <53AF1E98.2080906@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA48@USMBX1.msg.corp.akamai.com> <53AF47E3.9020906@nthpermutation.com> <CACsn0cmYbPeyUCMvRc=8MqVGMDSv1mKbxiQutqpPw_oR6cfD-A@mail.gmail.com> <53AF517F.7050504@nthpermutation.com> <CABcZeBMs+03GefqNaBbhF8FRdw_Pmpe6NkDqesssb-FruRaEdw@mail.gmail.com> <53B07640.2050000@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 29 Jun 2014 14:29:44 -0700
Message-ID: <CABcZeBOZRmsmsx8d-gOLhvKKmQGGEWuNfQV_hcN=k0bTRbw7Pg@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=f46d04428cf428cf6504fd0040dc
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aFwai4CyW8Mc0pXFlAKbyTGMwtE
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jun 2014 21:30:29 -0000

On Sun, Jun 29, 2014 at 1:25 PM, Michael StJohns <msj@nthpermutation.com>
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 <msj@nthpermutation.com>
> wrote:
>
>>  On 6/28/2014 7:04 PM, Watson Ladd wrote:
>>
>>
>> On Jun 28, 2014 3:55 PM, "Michael StJohns" <msj@nthpermutation.com>
>> 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".
>

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.
Do you believe that the IETF made some statements about the quality
of HMAC by publishing RFC 2104 and including HMAC in our protocols?



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

-Ekr