Re: [TLS] On Curve25519 standardization

Michael StJohns <> Mon, 30 June 2014 20:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4089E1A0300 for <>; Mon, 30 Jun 2014 13:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F6me9z4Vto7y for <>; Mon, 30 Jun 2014 13:59:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F12C81A00DB for <>; Mon, 30 Jun 2014 13:59:05 -0700 (PDT)
Received: by with SMTP id m5so6816112qaj.37 for <>; Mon, 30 Jun 2014 13:59:05 -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 :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 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 with ESMTPSA id a3sm9235358qaa.37.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 13:59:04 -0700 (PDT)
Message-ID: <>
Date: Mon, 30 Jun 2014 16:59:04 -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: "Salz, Rich" <>, Watson Ladd <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] On Curve25519 standardization
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 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.