IETF Logo Mail Archive

Re: [Cfrg] Curve manipulation, revisited

"Salz, Rich" <rsalz@akamai.com> Mon, 29 December 2014 18:54 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB33F1A8EA9 for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 10:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 ir_iFiEbZSC8 for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 10:54:55 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 347361A8BC0 for <cfrg@irtf.org>; Mon, 29 Dec 2014 10:54:54 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0176B47618; Mon, 29 Dec 2014 18:54:54 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E992847613; Mon, 29 Dec 2014 18:54:53 +0000 (GMT)
Received: from email.msg.corp.akamai.com (unknown [172.27.123.34]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E4366202A; Mon, 29 Dec 2014 18:54:53 +0000 (GMT)
Received: from usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 29 Dec 2014 13:54:53 -0500
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.15]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Mon, 29 Dec 2014 13:54:53 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Mon, 29 Dec 2014 13:54:52 -0500
Thread-Topic: [Cfrg] Curve manipulation, revisited
Thread-Index: AdAjl/XHthMsDMFsTnCzzBTHSUfucwAADutQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236EE7@USMBX1.msg.corp.akamai.com>
References: <CAMfhd9W684XMmXn3ueDmwrsQ_ZdiFG+VqYLxkvs7qDwiJdpk6w@mail.gmail.com> <1725646678.805875.1419539885135.JavaMail.yahoo@jws100115.mail.ne1.yahoo.com> <CAMfhd9Ua5fFZk46Xx1AN2VgyJ=Yng6fnO8aN-_ZfzXQn0Xbxhg@mail.gmail.com> <CA+Vbu7zqFcu8d1053mZ_eEm0q=np6T3snSQ4rfY0k1-4hBVDsA@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D55236DA1@USMBX1.msg.corp.akamai.com> <68DF78C2-9F4D-457C-A32E-88A58E74A371@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D55236ECC@USMBX1.msg.corp.akamai.com> <A7D3783D-0159-486E-8136-63E90E20AC0B@gmail.com>
In-Reply-To: <A7D3783D-0159-486E-8136-63E90E20AC0B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xP_7Y6tWZ6Wxr36xuKjHqvw3H9k
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Curve manipulation, revisited
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 18:54:57 -0000

> The signatures on X509 certificates are a separable issue. But the signatures
> in the ServerKeyExchange using the private key associated with the public
> key in the X509 certificates are very much a part of TLS.

True, yes, foggy from too much eggnog, I guess.
 
> When measuring the performance of the TLS handshakes, the ECDHE
> derivation takes a similar amount of time as the ECDSA signature. That is the
> reason for moving away from RSA public keys to ECDSA public keys. If we can
> use public keys which will be even faster, that’s a net win.
> 
> So again, why not?

Two major reasons.  X25519 is useful by itself without Ed25519 so there's no reason to tie them together.  Having them separate docs lets them progress at their own, natural, rate.  Which brings me to my second reason: I think there are no valid reasons to delay X25519, while the discussion around Ed25519 is, well, let's just say it's still at the pre-consensus state. :)  Does that make sense?

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz@jabber.me Twitter: RichSalz

v2.23.0 | Report a Bug | By Email