Subject: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

From: Joe Salowey <[email-masked]>
Date: Tue, 12 Jan 2016 16:03:13 +0000

Whoops, thanks for the correction.  It should be the code point assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448, Ed25519 and Ed448. 

Thanks,

Joe

On 1/12/16, 6:24 AM, "Simon Josefsson" <[email-masked]> wrote:

>Adam Langley <[email-masked]> writes:
>
>> Curve25519, as the name suggests, operates on 255-bit numbers. When
>> encoded as bytes, there's obviously a 256th bit that needs to be
>> specified.
>>
>> Curve25519 implementations didn't set the bit but did used to vary on
>> how they parsed it. Some would take a 256-bit number and reduce it
>> while others would ignore the bit completely.
>>
>> However, I believe that implementations have converged on ignoring it.
>> That behaviour is specified in draft-irtf-cfrg-curves and tested via
>> the test vectors.
>>
>> Currently https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
>> says that implementations SHOULD reject inputs with the high-bit set.
>> I think that should be dropped. The X25519 function is specified in
>> terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec
>> should just use that draft.
>
>I agree.
>
>/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 12 Jan 2016 20:26:11 +0100

The same concern still applies: what does it mean to allocate code
point for the 4492bis-05 description?  The document currently says to
reject invalid ECDH keys, but I believe we want to remove that text.  We
could ask Yoav to issue a 4492bis-06 quickly that fix this issue, and
then proceed with early code point allocation.

Further, I believe allocating code points for Ed25519/Ed448 is premature
since 1) the CFRG draft on Ed448 is not updated, and 2) 4492bis-05 does
not contain sufficient detail to implement EdDSA authentication in TLS.
See draft-josefsson-tls-eddsa2-02 for some discussion to make EdDSA
work in TLS, as it relates to PKIX handling as well.

To be clear: I support allocating a code point for X25519 as described
in 4492bis with the relaxed public key check.

/Simon

> Whoops, thanks for the correction.  It should be the code point
> assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448,
> Ed25519 and Ed448. 
> 
> Thanks,
> 
> Joe
> 
> 
> 
> 
> 
> >> Curve25519 implementations didn't set the bit but did used to vary
> >> on how they parsed it. Some would take a 256-bit number and reduce
> >> it while others would ignore the bit completely.
> >>
> >> However, I believe that implementations have converged on ignoring
> >> it. That behaviour is specified in draft-irtf-cfrg-curves and
> >> tested via the test vectors.
> >>
> >> Currently
> >> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
> >> says that implementations SHOULD reject inputs with the high-bit
> >> set. I think that should be dropped. The X25519 function is
> >> specified in terms of bytes in draft-irtf-cfrg-curves and I think
> >> the TLS spec should just use that draft.
> >
> >I agree.
> >
> >/Simon

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Jan 2016 22:21:21 +0200

> On 12 Jan 2016, at 9:26 PM, Simon Josefsson <[email-masked]> wrote:
> 
> point for the 4492bis-05 description?

Allocating code points just means an implementation of draft-05 is likely to interoperate just fine with an implementation of the final RFC.

Of course nothing is ever final until the RFC is out, so there’s always a risk involved, but it is considered prudent to allocate numbers when we’re reasonably certain of the calculations and on-the-wire formats. Any debate about whether we should or should not check certain inputs for certain conditions need not be a bar for allocating numbers.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jan 2016 23:31:45 +0200

On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
> Allocating code points just means an implementation of draft-05 is
> likely to interoperate just fine with an implementation of the final
> RFC.
> 
> Of course nothing is ever final until the RFC is out, so there’s
> always a risk involved, but it is considered prudent to allocate
> numbers when we’re reasonably certain of the calculations and on-
> the-wire formats. Any debate about whether we should or should not
> check certain inputs for certain conditions need not be a bar for
> allocating numbers.

Assuming CFRG chairs really did declare consensus on Ed448 hash, then
the final characteristics of Ed448 are known and I have a reference
implementation.

And the PKIX draft looks implementable (has wrong example?)

More serious interop hazard is what to do with X25519/X448 and THS
(some of the proposed stuff is not wire-compatible).

-Ilari

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Jan 2016 11:04:37 +0000

> On 12 Jan 2016, at 21:31, Ilari Liusvaara <[email-masked]> wrote:
> 

This CFRG co-chair would like to see an updated CFRG draft before the code point is allocated.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 13 Jan 2016 08:40:29 -0800

Hi All,

Looks like I jumped too soon on this one.  In particular, both the CFRG
signature draft and 4492bis need to be updated.  Let's hold of on code
point assignment until then.

Thanks,

Joe
(crawling back under my rock now)

On Wed, Jan 13, 2016 at 3:04 AM, Alexey Melnikov <[email-masked]>
wrote:

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 14 Jan 2016 16:14:26 +0100

Allocating a code point for X25519 could be done and is long overdue
(first draft September 2013).  X448 is also stable.  Code points for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.  I agree with Yoav's
assertion that the curve point verification issue is not big enough to
stall code point allocation.

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Jan 2016 07:17:59 -0800

I concur.

-Ekr

On Thu, Jan 14, 2016 at 7:14 AM, Simon Josefsson <[email-masked]>
wrote:

> >> This CFRG co-chair would like to see an updated CFRG draft before the
> code
> >> point is allocated.
> >>

---

From: Brian Smith <[email-masked]>
Date: Thu, 14 Jan 2016 13:22:15 -1000

> stall code point allocation.

I agree with this.

Cheers,
Brian

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 19 Jan 2016 09:53:23 -0800

Any objections to early allocation for X25519 and X448?  Are there
implementers with code ready to test interop?

Thanks,

Joe

---

From: David Benjamin <[email-masked]>
Date: Tue, 19 Jan 2016 18:00:40 +0000

BoringSSL has a pair of implementations ready (in C and in our fork of Go's
TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29.
It's not currently enabled in any Chrome builds, but I'm expecting to
change this soon.

David

---

From: Andrei Popov <[email-masked]>
Date: Tue, 19 Jan 2016 18:59:54 +0000

Yes, please allocate, esp. 25519. MS will start testing interop soon.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of David Benjamin
Sent: Tuesday, January 19, 2016 10:01 AM
To: Joseph Salowey <[email-masked]>; Brian Smith <[email-masked]>
Cc: Adam Langley <[email-masked]>; Simon Josefsson <[email-masked]>; [email-masked]
Subject: Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

BoringSSL has a pair of implementations ready (in C and in our fork of Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so 29. It's not currently enabled in any Chrome builds, but I'm expecting to change this soon.

David

On Tue, Jan 19, 2016 at 12:54 PM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
Any objections to early allocation for X25519 and X448?  Are there implementers with code ready to test interop?

Thanks,

Joe

On Thu, Jan 14, 2016 at 3:22 PM, Brian Smith <[email-masked]<mailto:[email-masked]>> wrote:
Simon Josefsson <[email-masked]<mailto:[email-masked]>> wrote:
Allocating a code point for X25519 could be done and is long overdue
(first draft September 2013).  X448 is also stable.  Code points for
Ed25519 and Ed448 is more problematic since TLS authentication has
historically had interaction with PKIX certs.  I agree with Yoav's
assertion that the curve point verification issue is not big enough to
stall code point allocation.

I agree with this.

Cheers,
Brian

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cf98a69f5749b4201db9608d320fa7d41%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5vehoTyQrunKJOKqeWolH9TSAndHSWhX4zKz5RsBcJ0%3d>

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 25 Jan 2016 14:57:58 -0800

OK We'll ask for early code point assignment for

ecdh_x25519 (29), ecdh_x448 (30)

On Tue, Jan 19, 2016 at 10:59 AM, Andrei Popov <[email-masked]>
wrote:

> *From:* TLS [mailto:[email-masked]] *On Behalf Of *David Benjamin
> *Sent:* Tuesday, January 19, 2016 10:01 AM
> *To:* Joseph Salowey <[email-masked]>; Brian Smith <[email-masked]>
> *Cc:* Adam Langley <[email-masked]>; Simon Josefsson <
> [email-masked]>; [email-masked]
> *Subject:* Re: [TLS] Correction: early codepoint assignment for
> Curve25519, Curve448, Ed25519 and Ed448
>
>
>
> BoringSSL has a pair of implementations ready (in C and in our fork of
> Go's TLS stack for testing). We're using the value in the TLS 1.3 draft, so
> 29. It's not currently enabled in any Chrome builds, but I'm expecting to
> change this soon.
>
>
> David
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cf98a69f5749b4201db9608d320fa7d41%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5vehoTyQrunKJOKqeWolH9TSAndHSWhX4zKz5RsBcJ0%3d>
>
>