Re: [TLS] On Curve25519 standardization

Michael StJohns <msj@nthpermutation.com> Mon, 30 June 2014 20:59 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 4089E1A0300 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 13:59:08 -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 F6me9z4Vto7y for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 13:59:07 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12C81A00DB for <tls@ietf.org>; Mon, 30 Jun 2014 13:59:05 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id m5so6816112qaj.37 for <tls@ietf.org>; Mon, 30 Jun 2014 13:59:05 -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=S79On4TsMNvoxHHfyvddQskCVEfOL0v8sDBo7ws9xeY=; b=Tfkm/3QIBXgLGxKAHrFftqjZ+bKKpon2i+n+Qn7I04W3KpmVBJVTv5HFecMZvKSyb0 PuGc29A1zSfafNOEwWR75BTeHAq6SkvVqcDySBgL81tPbclWgRS7rb6p4BxvUKTZA9GB SNI3b3+3/ASYl+s878ByEYUoinu9OCMOReYY4gAcNDzQXHxvR1ymfzbBcpn2RmP8c/yt bFg4sSLoDjQpCX07LX2HHWVYIYnZTOjS7mg7xC71SHenH9YGMxDWlKDOIskRnIVhd2Y+ 2BMhzh2rEMmxsUTyehlXt/je4z/m8ZdfAafT+d+Cpl8/kmw4m79UrwuUgK8nliRO/hG5 zauA==
X-Gm-Message-State: ALoCoQmtAmnhRYcgI9M5kzoGfQRazt70l3h8JRm0vM+ybOz2bSN0lCaWlY8IZW2mZFERAl3Ai3Lx
X-Received: by 10.224.72.13 with SMTP id k13mr65720759qaj.54.1404161945174; Mon, 30 Jun 2014 13:59:05 -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 a3sm9235358qaa.37.2014.06.30.13.59.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 13:59:04 -0700 (PDT)
Message-ID: <53B1CF98.6010304@nthpermutation.com>
Date: Mon, 30 Jun 2014 16:59:04 -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: "Salz, Rich" <rsalz@akamai.com>, Watson Ladd <watsonbladd@gmail.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> <53B190E7.6050800@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFD52@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71854BEFD52@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wx9jku43rAeKhAqG7wUmCPEKl6k
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] On Curve25519 standardization
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 20:59:08 -0000

Someplace in the middle of all this the question I asked seems to have 
gotten lost.  Basically, "would generating IETF curves obviate the need 
for Curve25519 or others?" which I would say got answered "no".  The 
rest of all this is a side show with how Curve25519 gets into the IETF 
toolkit. 'nuff said.

On 6/30/2014 2:13 PM, Salz, Rich wrote:
> So on the one side, folks at the CFRG meeting and such said they want an IETF RFC document on how to use and represent 25519.  That the external documents aren't enough.
>
> On the other side, you are saying "no half measure" and that if we specify how to implement and use 25519, then we are writing a crypto standard and we've never done that before.
>
> Do I have that right?

I would agree with "need a document to represent and use 25519", its who 
said that and how it was said that I'm unclear on.   That document will 
have the form of a crypto standard irrespective of who writes it.  If it 
gets published like each and every other RFC we've done on crypto - as 
Informational and externally originated, then it isn't anything new.   
If we run it through our standards process, then it is.

>
> If yes, then my reply is "so what."  Nobody's asking the IETF, little more than a collection of mailing lists, to take liability should 25519 be cracked or have a back door.

I actually used the word "assurance".  Standards bodies don't get stuck 
with liability per se.

The IETF has an open process, scope of expertise and a reasonable 
commercial and international reputation.  Putting the IETF stamp of 
approval (in the form of placing it on the standards track) on a 
specific cryptographic algorithm and its associated standards lends that 
reputation to the standard more or less with a hit to the reputation if 
there's a failure.  If we want to begin doing this for cryptography in 
general, then we need to understand the real-world implications, both of 
the endorsement and possible failures.

Mike