Re: [TLS] Updated EdDSA in TLS drafts

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 09 June 2015 10:14 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 17DF21B2B78 for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 03:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wpKoWkLsecoQ for <tls@ietfa.amsl.com>; Tue, 9 Jun 2015 03:14:17 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928B31B2B73 for <tls@ietf.org>; Tue, 9 Jun 2015 03:14:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5517DBEE6; Tue, 9 Jun 2015 11:14:15 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haw4my31WTDn; Tue, 9 Jun 2015 11:14:12 +0100 (IST)
Received: from [172.16.20.132] (62-50-200-74.client.stsn.net [62.50.200.74]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23281BE49; Tue, 9 Jun 2015 11:14:11 +0100 (IST)
Message-ID: <5576BC72.2090507@cs.tcd.ie>
Date: Tue, 09 Jun 2015 11:14:10 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <87zj4ah6i0.fsf@latte.josefsson.org> <55756B76.4070103@cs.tcd.ie> <87wpzdjoei.fsf@latte.josefsson.org>
In-Reply-To: <87wpzdjoei.fsf@latte.josefsson.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="grcVuv40sDoDGlpb2lIk9e4U1un3iSqKM"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/A1g7nIm-h1zyLSVRbaT4cQRRMKI>
Cc: tls@ietf.org
Subject: Re: [TLS] Updated EdDSA in TLS drafts
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: Tue, 09 Jun 2015 10:14:20 -0000

Hi Simon,

On 09/06/15 09:07, Simon Josefsson wrote:
> Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
> 
>> Hiya,
>>
>> On 08/06/15 10:52, Simon Josefsson wrote:
>>> More feedback is appreciated!
>>
>> My v. high level feedback is that we really don't want
>> to get too far ahead of cfrg here. They've not yet got
>> all details of their preferred signature scheme using
>> that curve defined and it'd be really dumb for any IETF
>> WG to get ahead of that by accident.
>>
>> So while working on this draft is a fine thing, I don't
>> think we want to get to IETF LC for things like this until
>> after cfrg have figured out their preferred signature
>> scheme. (And the cfrg chairs tell me that ought be done
>> soon - in a few months.)
> 
> Thanks for feedback.  I believe these documents are quite far away from
> LC-ready so that this aspect shouldn't be a problem.

Yep, I think that's correct. But I'd be somewhat wary of
making design decisions in the meantime - we really don't
want to end up with a cfrg-annointed signature scheme that
ends up being hard to integrate because of decisions made
now. (And folks who care about what cfrg are doing on that
should get involved on the cfrg list.)

> 
> I view the EdDSA/Ed25519 effort similar to the Brainpool/GOST efforts.
> If CFRG happens to pick EdDSA, then fine, but that isn't the
> motivational factor here.

Well, maybe. With no hats, I personally don't think we want
more unused ciphersuites, and especially not ones that are
almost-but-not-quite the same as one that uses the eventual
cfrg-annointed signature scheme. (Unless there's a good
reason to not use the cfrg stuff of course, in which case
we're in a different situation.)

But so long as the TLS WG don't bake in too much stuff and
so long as cfrg continue to make progress in a timely fashion
it should all work out.

Cheers,
S.

> 
> /Simon
> 
>> Note that waiting until the cfrg position is clear
>> does not mean that the IETF has to mindlessly adopt what
>> cfrg have done, but we won't want to ignore their work
>> either. And fwiw, I guess I'd take the same position for
>> any work item for almost any new ECC work for the moment.
>> Since cfrg are nearly done and seem to be making progress
>> now, pre-empting their decisions wouldn't be a good plan.
>>
>> Cheers,
>> S.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>