Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 14 July 2015 16:55 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 F2F1B1A0146 for <tls@ietfa.amsl.com>; Tue, 14 Jul 2015 09:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 DDaFRskZVfwW for <tls@ietfa.amsl.com>; Tue, 14 Jul 2015 09:55:50 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F191A011F for <tls@ietf.org>; Tue, 14 Jul 2015 09:55:50 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id D1FAF900B2; Tue, 14 Jul 2015 19:55:47 +0300 (EEST)
Date: Tue, 14 Jul 2015 19:55:47 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20150714165547.GB1094@LK-Perkele-VII>
References: <20150706114814.10143.87075.idtracker@ietfa.amsl.com> <2960351.rch1apE1uy@pintsize.usersys.redhat.com> <87k2u5samu.fsf@latte.josefsson.org> <17744104.AefDTyBEY2@pintsize.usersys.redhat.com> <878uairce7.fsf@latte.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <878uairce7.fsf@latte.josefsson.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9Vzzrz0DuJbYTrP7GYMKBwBefJ8>
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-curve25519-01.txt
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: <https://mailarchive.ietf.org/arch/browse/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, 14 Jul 2015 16:55:52 -0000

On Tue, Jul 14, 2015 at 05:23:44PM +0200, Simon Josefsson wrote:
> Hubert Kario <hkario@redhat.com> writes:
> 
> > So unless the PKIX and TLS parts are defined at the same time, in the same 
> > document, we definitely need to keep them apart.
> 
> It is conceivable to reuse the NamedCurve values for TLS authentication
> without affecting the ECHDE use, nor delaying the Curve25519 ECDHE work.
> 
> Compare how we "reuse" the ECDHE ciphersuite values to refer to
> Curve25519 (instead of defining new ciphersuites for Curve25519), and
> how we are "reusing" the "uncompressed" code point to refer to
> Curve25519-compressed code points (instead of defining new
> ECPointFormat).

Well, allowing curve to set point format isn't much of a stretch (and in
fact, TLS 1.3 as of currently requires this).

If one does only "uncompressed" format, all current ECDHE curves work
as a triple:
- Keybytes: How many bytes of private key it wants.
- Generate: Take in private key, output public key.
- Agree: Take in private key and peer public key, output premaster secret
  (or ES/SS in TLS 1.3).

(Instantiating that for both uncompressed NIST P-256 and Curve25519 is
left as an simple excercise).

> Allocating new values when that creates additional costs and no improved
> clarity seems wasteful to me.  This approach is what people have
> suggested for most other allocations here, so I prefer to stick to that
> philosophy unless it is clear that there is consensus for something
> else.  What do others think?

Well, that would imply that implementation that supports Curve25519 and/
or Curve448 sigs has to also do ECDHE with exactly those curves. And
conversely, anything that does both Curve25519 and Curve448 ECDHE and
does signatures with either has to do signatures with both.

In implementation, signatures are quite a bit more complicated than
ECDHE.


-Ilari