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

From: [email-masked]
Date: Mon, 06 Jul 2015 04:48:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Curve25519 and Curve448 for Transport Layer Security (TLS)
        Authors         : Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-curve25519-01.txt
	Pages           : 11
	Date            : 2015-07-06

Abstract:
   This document specifies the use of Curve25519 and Curve448 for
   ephemeral key exchange in the Transport Layer Security (TLS) and
   Datagram TLS (DTLS) protocols.  It updates RFC 5246 (TLS 1.2) and RFC
   4492 (Elliptic Curve Cryptography for TLS).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-curve25519/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-curve25519-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-curve25519-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 Jul 2015 14:20:04 +0200

On Monday 06 July 2015 04:48:14 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Transport Layer Security
> Working Group of the IETF.
> 
>         Title           : Curve25519 and Curve448 for Transport Layer
> Security (TLS) Authors         : Simon Josefsson
>                           Manuel Pegourie-Gonnard

As is described in secion 5.1. of RFC 4492, and then reiterated in 
section 2.2. of this draft - the elliptic_curves (a.k.a. supported_groups) 
guides both the ECDH curves and curves understandable by peer for ECDSA 
signatures.

As Curve25519 and Curve448 can only be used for ECDHE, maybe they should be 
defined/named in the registry as such, to remove any ambiguity[1]:

         enum {
              Curve25519_ecdh(TBD1),
              Curve448_ecdh(TBD2),
         } NamedCurve;

 1 - to not redo the mistake of diffie-hellman-group1-"really-group2"-sha1 in 
     SSH: https://tools.ietf.org/html/rfc4253#section-8.1 when the 25519 and 
     448 are defined for some form of ECDSA
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 12 Jul 2015 16:39:37 +0200

> defined/named in the registry as such, to remove any ambiguity[1]:

I don't care strongly.  One disadvantage with this is that if we decide
to reuse these NamedCurve allocations to have something to do with
Ed25519, the naming above will be confusing.  However, I believe it is
already likely that Ed25519 will have its own NamedCurve.

/Simon

---

From: Hubert Kario <[email-masked]>
Date: Tue, 14 Jul 2015 10:34:26 +0200

> already likely that Ed25519 will have its own NamedCurve.

Given that there certainly will be implementations that support ecdh and not 
the signatures, we certainly *don't* want to reuse this codepoint for anything 
else.

So unless the PKIX and TLS parts are defined at the same time, in the same 
document, we definitely need to keep them apart.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Jul 2015 17:23:44 +0200

Hubert Kario <[email-masked]> writes:

> Given that there certainly will be implementations that support ecdh
> and not the signatures, we certainly *don't* want to reuse this
> codepoint for anything else.
>

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).

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?

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Jul 2015 19:55:47 +0300

> Curve25519-compressed code points (instead of defining new

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).

> 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

---

From: Hubert Kario <[email-masked]>
Date: Mon, 20 Jul 2015 12:55:37 +0200

On Tuesday 14 July 2015 17:23:44 Simon Josefsson wrote:
> >> > As Curve25519 and Curve448 can only be used for ECDHE, maybe they
> >> > should
> >> > be
> >> > 

the point is, that if Ed25519 for signatures is defined, an implementation 
that doesn't understand it[1] can't advertise that fact

 1 - be it because it wasn't updated yet, or because the programmers don't 
consider it important enough yet - that doesn't matter
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 20 Jul 2015 14:39:03 +0300

> that doesn't understand it[1] can't advertise that fact

Are you thinking about 1.0/1.1? In 1.2 it can: signature_algorithms
(I'm not confident new signature algorithm would work without either
that nor new ciphersuites).

There are other shortcomings tho:
- If Ed25519 is supported, one also needs to support Curve25519.
- If Ed25519 and Curve448 are supported, one needs to support
  Curve25519 and Ed448.
- And the cross case from previous.

So with the same, in TLS 1.2, the following combinations would
be possible:
- None at all.
- Curve25519
- Curve448
- Curve25519 & Curve448
- Curve25519 & Ed25519
- Curve448 & Ed448
- Curve25519 & Curve448 & Ed25519 & Ed448.

-Ilari

---

From: Hubert Kario <[email-masked]>
Date: Mon, 20 Jul 2015 13:42:01 +0200

> - Curve25519 & Curve448 & Ed25519 & Ed448.

if we define separate codepoints for Curve25519 and Ed25519, yes
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 20 Jul 2015 16:02:54 +0300

> if we define separate codepoints for Curve25519 and Ed25519, yes

That list was assuming the following:
- TLS at least 1.2 (I don't see much point with bothering with
  lesser versions here).
- Unified 255/448 bit signature algorithm as one of SignatureAlgorithm
  codepoints, using ECDSA ciphersuites.
- The same codepoint used for both 25519 kex and sig curve (and the
  same for 448).

Breaking any of those three assumptions changes things here.

-Ilari