Subject: [TLS] Call for WG adoption draft-josefsson-tls-curve25519

From: Joseph Salowey <[email-masked]>
Date: Wed, 20 May 2015 08:47:55 -0700

This is the WG call for adoption of:

https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt

This draft specifies the use of Curve25519 for ephemeral key exchange in
the TLS and DTLS.  This draft serves as the starting point (it’s expired
and needs to be updated in light of
http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).  If you object to
the adoption of this draft, please let us know why by 20150602.

Note: We’re not doing an early code point assignment for this draft,
because it clearly needs to resurrected and tweaked.  Once that happens,
there’s nothing stopping a request from the authors for an early code point
assignment.

Thanks,

J/S

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 May 2015 08:50:20 -0700

I am in favor of adopting this draft.

-Ekr

On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey <[email-masked]> wrote:

> http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).  If you object
> to the adoption of this draft, please let us know why by 20150602.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 May 2015 20:15:04 +0300

> the adoption of this draft, please let us know why by 20150602.

Adopt.
 
> there’s nothing stopping a request from the authors for an early code point

Agreed:

- Add curve448?
- Do bit masking like cfrg-curves specifies?
- Add zero key check like crfg-curves specifies[1]?
- Why the point format and prefix? Expecting other point formats without
  new codepoint allocation[2]? Or some software engineering reason?

[1] While it is not helpful with properly designed protocols, it is
helpful with less-well-designed ones. It is very cheap anyway.

[2] AFAIK, not allowed in 1.3 anyway.

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 May 2015 14:50:24 -0500

Adopt.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 May 2015 00:48:57 +0300

Me too.

I notice that while the draft doesn’t say that explicitly, it uses existing *_ECDHE_* ciphersuites, so that no new ciphersuites are required, despite the fact that this ECDHE has different point formats and different back-end math than the existing ECDHE.  I wonder if we can also get away with using *ECDSA* ciphersuites for EdDSA signatures.

Yoav

> On May 20, 2015, at 6:50 PM, Eric Rescorla <[email-masked]> wrote:
> 
> On Wed, May 20, 2015 at 8:47 AM, Joseph Salowey <[email-masked] <mailto:[email-masked]>> wrote:
> https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt <https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt>
> 
> This draft specifies the use of Curve25519 for ephemeral key exchange in the TLS and DTLS.  This draft serves as the starting point (it’s expired and needs to be updated in light of http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ <http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/>).  If you object to the adoption of this draft, please let us know why by 20150602.
> 
> Note: We’re not doing an early code point assignment for this draft, because it clearly needs to resurrected and tweaked.  Once that happens, there’s nothing stopping a request from the authors for an early code point assignment.
> 
> Thanks,
> 
> J/S

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 May 2015 17:55:13 -0500

On Thu, May 21, 2015 at 12:48:57AM +0300, Yoav Nir wrote:
> I notice that while the draft doesn’t say that explicitly, it uses
> existing *_ECDHE_* ciphersuites, so that no new ciphersuites are
> required, despite the fact that this ECDHE has different point formats
> and different back-end math than the existing ECDHE.  I wonder if we
> can also get away with using *ECDSA* ciphersuites for EdDSA
> signatures.

I think so.  That would be excellent.  (One case of not adding a factor
to the ciphersuite cartesian product.  Rejoice.)

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 21 May 2015 11:30:40 +0200

Hi,

Joseph Salowey wrote:
> and needs to be updated in light
> of http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).  If you
> object to the adoption of this draft, please let us know why by 20150602.

No objection, adopt. Good that this is being worked on again.

> there’s nothing stopping a request from the authors for an early code
> point assignment.

Agreed.

Aaron

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 21 May 2015 17:33:19 -0400

> https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt

I'm in favor of TLS WG adoption of this draft.

    --dkg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2015 23:01:30 +0200

> can also get away with using *ECDSA* ciphersuites for EdDSA

This is an interesting idea, thanks for mentioning that.  It would ugly
for "ECDSA" in a cipher suite name to not actually mean that ECDSA is
used, but it is a valid engineering tradeoff to sometimes prefer ugly
things that simplify over beautiful things that complicate.

/Simon

>> This draft specifies the use of Curve25519 for ephemeral key
>> exchange in the TLS and DTLS.  This draft serves as the starting
>> point (it’s expired and needs to be updated in light of
>> http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/
>> <http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/>).  If you
>> because it clearly needs to resurrected and tweaked.  Once that
>> happens, there’s nothing stopping a request from the authors for an
>> early code point assignment.
>> 
>> Thanks,
>> 
>> J/S
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2015 23:08:58 +0200

> - Add curve448?

Given that it has been added to the CFRG document, I assume that this is
a given.  Right now Ed448-Goldilocks is in
draft-josefsson-tls-additional-curves but it can be moved.

> - Do bit masking like cfrg-curves specifies?

I don't have a strong opinion.  I believe that tls-curve25519 should not
deviate from cfrg-curves on this without a really strong reason.

> - Add zero key check like crfg-curves specifies[1]?

Ditto.

It is not clear to me whether the current wording for this and the
previous issue will remain in the cfrg-curves document though.

>   new codepoint allocation[2]? Or some software engineering reason?

What would you prefer instead?  Maybe Manuel Pegourie-Gonnard can chime
in here.

/Simon

---

From: Rob Stradling <[email-masked]>
Date: Fri, 29 May 2015 22:32:56 +0100

> things that simplify over beautiful things that complicate.

The TLS 1.3 draft renames the Supported Elliptic Curves extension so 
that it can contain non-EC groups.  So renaming things in the IANA TLS 
registries doesn't seem to be prohibited, AFAICT.

Could we rename the TLS_ECDHE_ECDSA_* cipher suites so that they're not 
specific to ECDSA?  (TLS_ECDHE_EC_* perhaps?)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 30 May 2015 11:23:43 +0300

> On May 30, 2015, at 12:01 AM, Simon Josefsson <[email-masked]> wrote:
> 

It’s based on Elliptic Curves; it’s a Digital Signature; it’s an Algorithm. The “ECDSA” label seems to still fit.

If we wanted to be really radical while losing backward compatibility, we could call the ciphersuite SIG_with_DHE, and use point formats for supporting RSA, DSA, ECDSA and EdDSA for signatures and DHE,ECDHE and Curve25519 for key agreement.

But since we do want backward compatibility, I think lumping all kinds of elliptic curve ephemeral D-H on “_ECDHE_” and all kinds of elliptic curve signatures on “_ECDSA_” is fine, even though ANSI X9.62 has labeled only the particular signature scheme used with P-256 as “ECDSA”.

Yoav