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

From: [email-masked]
Date: Fri, 12 Jun 2015 11:02:30 -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 for ephemeral key exchange in Transport Layer Security (TLS)
        Authors         : Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-curve25519-00.txt
	Pages           : 12
	Date            : 2015-06-09

Abstract:
   This document specifies the use of Curve25519 for ephemeral key
   exchange in the Transport Layer Security (TLS) protocol, as well as
   its DTLS variant.  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-00

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: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jun 2015 22:56:54 +0300

> 	Filename        : draft-ietf-tls-curve25519-00.txt

"Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no
common curves suitable for ECDSA."

You mean MUST NOT select ECDSA certificate? Because TLS 1.2 rules
seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA
certificate.

"This section defines a new point format suitable to encode Curve25519
public keys, as well as an identifier to negotiate this new format in
TLS, and includes guidance on their use."

Is this format going to be the chosen one for TLS 1.3? Because TLS 1.3
can't negotiate point formats for ECDHE.

Also, I don't see the value of trying to negotiate the point format,
and I think that the negotiation will act as an implementation error
source.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 12 Jun 2015 16:04:48 -0400

> and I think that the negotiation will act as an implementation error

I would suggest claiming that this point format is "uncompressed" and the
only point format for Curve25519.

-Ekr

>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jun 2015 13:43:25 -0700

> seemingly allow selecting ECDHE_RSA ciphersuite with ECDSA

This seems right to me.  The point here is that when a named_curve (or
named_group) identifies 25519, then it can't be used for ECDSA.  25519
is always OK with an _RSA_ suite.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 15 Jun 2015 13:03:45 +0000

> is always OK with an _RSA_ suite.

It seems that provided there's also a named_curve for ECDSA
that matches the certificate, then one might use 25519 for a key
exchange that is signed with ECDSA.

If both are supported I don't see why this combination should be
excluded.  What problem does the exclusion solve?

If 25519 ECDH is faster and safer than with ECDSA why not use it
even with servers that sign the parameters with ECDSA?

-- 
	Viktor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Jun 2015 16:29:19 +0300

> even with servers that sign the parameters with ECDSA?
 
The problem is that clients that support 25519 ECDHE might not
support any curve usable for ECDSA.

And even if they did, they are very unlikely to support 25519
ECDSA.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Jun 2015 06:47:53 -0700

> And even if they did, they are very unlikely to support 25519

Taking a step back, RFC 4492 doesn't contemplate the case that you could
use curve X for (say) ECDHE and not for signature, though it *does*
allow for you to use different curves:

   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
   different curves for (i) the ECDSA key in its certificate, and (ii)
   the ephemeral ECDH key in the ServerKeyExchange message.  The server
   must consider the extensions in both cases.

So the problem is that the signal that RFC 4492 contemplates is not
sufficiently
rich to support this case. However, it's obviously desirable that you be
able to
do Curve25519 ECDHE while still doing P256 for signature.

It seems that there are two potential solutions here (assuming that the CFRG
actually comes up with a Curve25519-based signature scheme).

1. Decide that it's not ECDSA
2. Pretend that there are two curves: Curve25519_kex and Curve25519_sig.

In the latter case, implementors of this draft would just advertise
Curve25519_kex
and future implementors of the signature draft would  advertise
Curve25519_sig.
Note that we don't have to decide this questions now, since the issue does
not yet
arise. We can just state that advertising Curve25519 doesn't mean that you
should do ECDSA with it.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2015 09:57:50 -0700

> exchange that is signed with ECDSA.

Perhaps I wasn't clear about this.

I'm saying that we need one named_curve for 25519 + ECDH and another
for Ec25519 + "ECDSA".

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2015 09:59:35 -0700

> arise. We can just state that advertising Curve25519 doesn't mean that you

And I'd be happy with this outcome too.  That is, we might decide
later to reuse the code point.

Of course, I'd still argue not to do the overload, based on the
potential for implementations to support one and not t'other.

---

From: Dave Garrett <[email-masked]>
Date: Mon, 15 Jun 2015 16:33:27 -0400

> I'm saying that we need one named_curve for 25519 + ECDH and another

Related issue:
"Add ability to negotiate curves for ECDHE independently of curves for ECDSA signatures #162"
https://github.com/tlswg/tls13-spec/issues/162

https://tlswg.github.io/tls13-spec/#negotiated-groups

The simple solution would just be to just fork all codepoints into separate ECDH & ECDSA versions. (except the 10 or so <100-bit security level ones that should just get dropped) If this already effectively needs to be done for Curve25519, then doing it for all at seems like the most straightforward route. There's enough bits available that the high bit could just be used to indicate ECDSA-only, all the new ones could just be old+0x8000, and they'd be easy to distinguish from each other as-needed.

Dave

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jun 2015 23:06:07 +0200

> potential for implementations to support one and not t'other.

I agree.  I changed the document to say:

  Servers MUST NOT select an ECDSA certificate if there are no common
  curves suitable for ECDSA.

https://gitlab.com/jas/ietf-tls-newcurves/commit/e9bf1cbfe136d5b53cc9e52681b0a98ccaabcb44#diff-1

> I'm saying that we need one named_curve for 25519 + ECDH and another

I am currently thinking the same.  That's what
draft-josefsson-tls-eddsa2 does.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jun 2015 23:12:16 +0200

> only point format for Curve25519.

I'm happy to do that.  Anyone against?  If I understand correctly, I
would drop most of the montgomery_x_le ECPointFormat registration and
instead say: use ECPointFormat "uncompressed" and send the public-key
formatted as follows [...].

/Simon

---

From: Martin Thomson <[email-masked]>
Date: Mon, 15 Jun 2015 14:22:35 -0700

> formatted as follows [...].

The CFRG draft defines 25519 to take a 32 byte string.  Use that
directly.  Just *claim* that it's uncompressed.

You don't have to add a 4 at the front, or mess around with forms.
Just define (by reference to draft-irtf-cfrg-curves, preferably) the
format.  We have plenty of contextual information available in TLS, we
just need the bytes.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jun 2015 23:40:11 +0200

> format.  We have plenty of contextual information available in TLS, we

I agree!  Committed as follows:

https://gitlab.com/jas/ietf-tls-newcurves/commit/e7b449ee5af70c2a0851f617ce225f93cc86d993#diff-1

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Jun 2015 21:32:53 +0300

> https://gitlab.com/jas/ietf-tls-newcurves/commit/e7b449ee5af70c2a0851f617ce225f93cc86d993#diff-1

+1.

But seemingly examples of encoding got stripped in process. Could be
a good idea to take the DH test vectors from cfrg-curves and also
show the resulting premaster secret (note: The hexadecimal versions
are already little-endian, as can be seen by computing mod 16 on
the decimal integer versions).

Also, could be a good idea to add Curve448 while at it too (Note: The
DH final result in testcase is wrong, the correct one seems to be:

07fff4181ac6cc95ec1c16a94a0f74d12da232ce40a77552281d282b
b60c0b56fd2464c335543936521c24403085d59a449a5037514a879d

As per https://www.ietf.org/mail-archive/web/cfrg/current/msg06770.html )

-Ilari