Subject: [TLS] Early code point assignments for 25519/448 curves

From: Sean Turner <[email-masked]>
Date: Mon, 23 Nov 2015 09:21:22 -0500

All,

We’ve received an early code point assignment for the following 4 (four) elliptic curve points that will go in the "Supported Groups" Registry:

// ECDH functions.
ecdh_x25519
ecdh_x448

// Signature curves.
eddsa_ed25519
eddsa_ed448

These points will be included in the following 2 (two) drafts:
	draft-ietf-tls-tls13
	draft-ietf-tls-rfc4492bis.

Early code points are permitted in the “Supported Groups” registry and the chairs (that’s us) need to determine whether there is support for these assignments.  Some input has already been received and those people do not need to respond again to this call, but we’d like to hear from others whether they support early code point assignment for these curves.  If you do not please state why.  We’re looking for input by November 30th.

J&S

---

From: Andrei Popov <[email-masked]>
Date: Mon, 23 Nov 2015 18:37:08 +0000

Thanks Sean,

I support early code point assignment for these curves.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, November 23, 2015 6:21 AM
To: <[email-masked]> <[email-masked]>
Subject: [TLS] Early code point assignments for 25519/448 curves

All,

// ECDH functions.
ecdh_x25519
ecdh_x448

// Signature curves.
eddsa_ed25519
eddsa_ed448

J&S
_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls%0a&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c261c2c7f387a43402fae08d2f41163f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=u5jdsbd0xLIjVOBsxqiaed3hzP5c1JCenrcGW6LVUVE%3d

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Nov 2015 22:56:30 +0200

I support early code point assignment.

It’s been suggested that as long as the CFRG signature curves document is not finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything in any draft is subject to change up to the time it’s published and people who implement internet draft should make allowances for such a risk. I see no problem with assigning numbers now. It does not make sense to ship a version of a product that you’ll have to support backwards compatibility with forever. But it is up to implementers to be smart enough about this.

Yoav

> On 23 Nov 2015, at 4:21 PM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 13:16:35 -0800

On 23 November 2015 at 12:56, Yoav Nir <[email-masked]> wrote:
> It’s been suggested that as long as the CFRG signature curves document is not finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything in any draft is subject to change up to the time it’s published [...]

In your opinion, do you see the semantics of the codepoints changing
in any meaningful way?  It's one thing to say "accept the risks", but
if anyone thinks that there are necessary changes forthcoming, that
would give me pause.  If everyone says that it's highly unlikely, I'm
supportive of the notion that we get a codepoint.

Are we happy that we will only be needing the PureEdDSA variants and
that no-one will be asking for the HashEdDSA versions?  I ask because
I've heard it suggested (I think Karthik mentioned this) that we might
want to sign the transcript directly in TLS 1.3 rather than rely on
collision-resistance of the selected hash function.  That would be
harder without access to HashEdDSA.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Nov 2015 21:38:40 +0000

Hiya,

On 23/11/15 14:21, Sean Turner wrote:
> All,
> 
> We’ve received an early code point assignment for the following 4

Is the word "request" missing above? Either that or I'm forgetting
more than I suspected:-)

> (four) elliptic curve points that will go in the "Supported Groups"
> Registry:
> 
> // ECDH functions. ecdh_x25519 ecdh_x448
> 
> // Signature curves. eddsa_ed25519 eddsa_ed448

I think 3 of the above are clearly fine now.

I'd suggest holding off on eddsa_ed448 for a while until CFRG
are done, but maybe establishing now that there is consensus in
the WG to allocate that as soon as CFRG are done (where "done"
means folks can implement and interop, not that the RFCs are
issued).

AFAIK the state of play within CFRG on that is that the chairs
plan to do a few polls for the couple of remaining issues in
a few weeks, so we're not talking about a major delay and to
be fair, CFRG recently have delivered more or less when they
said they would.

My reason to suggest this is just in case CFRG discover some
last minute stuff. While burning a code-point for that wouldn't
be a problem, we'd be better off without the confusion.

But if (the chairs tell me) there's clear consensus for some
other action here, I'll consider myself in the rough and go with
that.

Cheers,
S.

> draft-ietf-tls-tls13 draft-ietf-tls-rfc4492bis.
> 
> Early code points are permitted in the “Supported Groups” registry
> and the chairs (that’s us) need to determine whether there is support
> for these assignments.  Some input has already been received and
> those people do not need to respond again to this call, but we’d like
> to hear from others whether they support early code point assignment
> for these curves.  If you do not please state why.  We’re looking for
> input by November 30th.
> 
> J&S _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Nov 2015 14:01:32 -0800

if it's only a few weeks, let's just do all the signature code points
then.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Nov 2015 00:08:10 +0200

On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> > It’s been suggested that as long as the CFRG signature curves
> > document is not finalized, we should wait with the eddsa_* ones.
> > I don’t believe so. Anything in any draft is subject to change up
> > to the time it’s published [...]
> 

My personal view is (I haven't asked Simon about this) is that:
- Ed25519 is currently technically stable. There seems to be consensus
  not change it in any way that would break verification.
- Ed448 is unimplementable right now due to two missing functions.
- Once those two are missing (there is call for proposals this
  week) functions are decided, Ed448 should become technically
  stable.

> harder without access to HashEdDSA.

I would say that using HashEdDSA is a bad idea in that case. HashEdDSA
has fixed "prehash" function and if that hash breaks, the HashEdDSA
scheme breaks (the same is not true w.r.t. hash function for PureEdDSA).

Also, the prehashes might not be the same for Ed25519ph and Ed448ph,
plus I consider interfaces that let one use this dangerous (IUF
signing is dangerous!).

If one wants to have the entiere transcript signed in reasonable way,
one would have to implement hash firewalling at TLS level and require
PureEdDSA.

If doing that, might also be good idea to throw a prefix that screws 
many formats ('1E 80 00 00' might be one, it should screw at least ASN.1,
JSON and CBOR).

Also, the absence of indication of PRF hash in the signed data[1] bugs
me, since I need to assume CCR (CR of both hashes does not imply CCR)
in order to show security.

[1] Heck, that indication was in my original proposal (I didn't
quite understand its significance back then).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Nov 2015 14:20:15 -0800

> plus I consider interfaces that let one use this dangerous (IUF

That suggests that the construction of CertificateVerify is dangerous
in the same way, doesn't it?

---

From: Bill Frantz <[email-masked]>
Date: Mon, 23 Nov 2015 15:01:01 -0800

On 11/24/15 at 2:08 PM, [email-masked] (Ilari 

>week) functions are decided, Ed448 should become technically

I would prefer not to assign a code point until we know what it 
means. (i.e. can write code which interoperates.)

>if it's only a few weeks, let's just do all the signature code points

I would like to hear from implementers about how much this delay 
would affect them. We're coming into the December madness, so 
perhaps they want to spend time with their families. :-)

Otherwise, I'm in favor of early code points. We can always burn 
ones we dont want. We can either document them as obsolete, do 
not use, or if deployment is low enough, reassign them later if needed.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Nov 2015 07:54:21 +0200

> in the same way, doesn't it?

The problem is that in general, one must not act on invalid data (and
IUF signatures positively encourage acting on invalid data), but in
case of TLS CertificateVerify, one is expected to act on data, even
if invalid, and TLS protocol is designed with that in mind.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Nov 2015 16:48:57 +0200

> harder without access to HashEdDSA.

Also, one problem with signing the transcript directly is that because
of the context prefixes, one would either have to buffer all messages
or compute multiple hashes.

It is made worse by the fact that some hashes and signatures don't
mix very well. For example, trying to use SHA-512 with ECDSA is not a
good idea[1] (and nobody knows yet what the heck X448ph will use[2]).

Also, does the present 1-RTT construct in fact rely on collision-
resistance of the prf-hash?

[1] Well, it would be a good idea with ECDSA/P-521, but who uses
that?

[2] Proposals so far have included:
- SHA-512
- SHA3-512 (whee, SLOW)
- Shake256@512b (not a hash, but cryptographically looks OK).
- Sakee256@512b with some prefixing.
(That's just including the ones in more formal proposing, not
the earlier more handwavy proposals).

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Sat, 28 Nov 2015 20:21:45 +0200

> On 28 Nov 2015, at 4:48 PM, Ilari Liusvaara <[email-masked]> wrote:
> 

I think buffering all messages is fine for a regular handshake. The problem begins when you have a certificateRequest later in the negotiation, leading to a certificateVerify which signs the entire transcript. This means that we need to keep the transcript for the duration of the connection just in case the server decides to send a certificateRequest.

If a late certificateRequest signed something other than the entire transcript, I would be very much in favor of signing directly.

Yoav