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

Michael StJohns <msj@nthpermutation.com> Mon, 30 June 2014 16:32 UTC

Return-Path: <msj@nthpermutation.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 99FBC1A03C3 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 09:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RL4OiFs2BaSw for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 09:32:06 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6CB1A03C6 for <tls@ietf.org>; Mon, 30 Jun 2014 09:31:37 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so7132696qcv.19 for <tls@ietf.org>; Mon, 30 Jun 2014 09:31:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oj1eaIbpfA2VHEvOziswoWbaTfbiBcWBo9SD5Aahrhg=; b=KwoKCaw3NljxmndE7Fi7H5XQHmmnKxg62A5ajmlnk8YHpxj6TnXQxXqf4X18z2a4Fl 3cwFGEdLW05MFLTLI6ObJuE9waZxIjVMIHdpIujwjfm/a9Z2ghTVVjZZE6QbDMFMkfgx 3XGkUCtR5s7ecFzXfna7EI3poHsGbwby7ePdBU5I8LRurURgfbOZ1MfoQCFJ1+WaSZzp WnAq0B5mAsZgQI/yCIOuxXSaycUwZ6MmYa41F+IH+YXZnzrNm540olDlBHmzlRH1DDXk Zbg6L6XAqqTSbJhDigBj5xe7BF/VPgk+pRhRSMsfonMnK2UVy+YTs9gBknNjJy4TXzTw AfYg==
X-Gm-Message-State: ALoCoQkF+DETpZvts1P0Eo4pr2uN59vUsc7L28N8HroNJ5T82ECQiCIYpQYUz+0r69rTeKp1ZD/W
X-Received: by 10.140.101.86 with SMTP id t80mr33088221qge.108.1404145896891; Mon, 30 Jun 2014 09:31:36 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id y81sm12413283qgd.13.2014.06.30.09.31.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 09:31:36 -0700 (PDT)
Message-ID: <53B190E7.6050800@nthpermutation.com>
Date: Mon, 30 Jun 2014 12:31:35 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, "Salz, Rich" <rsalz@akamai.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> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFA95@USMBX1.msg.corp.akamai.com> <CACsn0cm1TvZsdreOK7WejWqOqU4SNAcvKRyy5sSZMJjyYzq1=Q@mail.gmail.com>
In-Reply-To: <CACsn0cm1TvZsdreOK7WejWqOqU4SNAcvKRyy5sSZMJjyYzq1=Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gPgyUqZrCe5U-ZArFSeP5mENGn8
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: Mon, 30 Jun 2014 16:32:07 -0000

Two opposing views on whether Curve25519 is destined for IETF 
standardization status.... and hence some of my confusion.

Rich - "here’s how to do the math for 25519 and other things needed to 
interoperate" is sort of the definition of what a cryptographic standard 
is - only question is whether its an externally owned/maintained 
document offered as an Informational RFC or an IETF standards track 
document.  If the latter, then the standard  (and indirectly the math) 
gets an IETF imprimatur and we haven't offered those - yet - for 
cryptographic standards.

Mike



On 6/30/2014 12:36 AM, Watson Ladd wrote:
> On Sun, Jun 29, 2014 at 8:12 PM, Salz, Rich <rsalz@akamai.com> wrote:
>> Ø  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.
>>
>> Mike, I know you’ve been involved in this stuff since before this stuff
>> existed J, but I don’t understand this. Why do we have to make any assurance
>> about anything other than ‘here is how to interoperate using 25519 in TLS’?
> No, we are defining a standard, and we are making assurances. Let's
> not kid ourselves: SPF might say experimental, but if you try to send
> mail without it, you'll find out just how much of a standard it is. As
> for making assurances, if someday a massive break is discovered in TLS
> 1.3 because we neglected cryptographic knowledge, we will rightfully
> be blamed for it.
>
> If 25519 was ROT13, a proposal to include it would rightfully be
> laughed out of this WG. We've established the principle, now we're
> just haggling over its limits.
>
> Sincerely,
> Watson Ladd
>
>>
>>
>> We’re not defining a standard, we’re not assuring the world about anything.
>> We’ll have an RFC that says “here’s  how to do the math for 25519 and other
>> things needed to interoperate” and we’ll have other RFC’s that say “here’s
>> how to use that curve in this protocol.”
>>
>>
>>
>> Why does it need to be more than that?  I know that I am not alone in this
>> confusion.
>>
>>
>>
>>                  /r$
>>
>>
>>
>> --
>>
>> Principal Security Engineer
>>
>> Akamai Technologies, Cambridge, MA
>>
>> IM: rsalz@jabber.me; Twitter: RichSalz
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>