Subject: [TLS] PR #23 for RFC4492bis

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Jul 2016 15:46:00 +0300

Hi

Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a PR.

https://github.com/tlswg/rfc4492bis/pull/23

If there are no objections, I will accept it and submit version -08 this Friday.

Thanks

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Jul 2016 17:06:25 +0300

> If there are no objections, I will accept it and submit version -08 this Friday.

While scanning through, I noticed that the Ed25519 and Ed448 "curves"
are still there. I think negotiating those should be done the same way
as in TLS 1.3 (those would then appear as hash=7 signature=3/4 IIRC).

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Jul 2016 17:59:06 +0300

> On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <[email-masked]> wrote:
> 

IMO this makes it very complex. TLS 1.3 replaces the old signature_algorithms extension that had pairs of signature algorithm/hash algorithm with one that has 16-bit values.

It changes things for ECDSA as well. We’re not going to change ECDSA in TLS 1.2. So if we wanted to adopt that we would still interpret 0x04,0x03 as ECDSA (with whatever curve) along with SHA-256, while 0x07,0x03 would be Ed25519, not ECDSA with some unknown hash function 0x07.

Seems strange to me, but I’ll make whatever changes the group wants.

Yoav

---

From: David Benjamin <[email-masked]>
Date: Mon, 04 Jul 2016 16:12:06 +0000

On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir <[email-masked]> wrote:

> IMO this makes it very complex. TLS 1.3 replaces the old
> signature_algorithms extension that had pairs of signature algorithm/hash
> algorithm with one that has 16-bit values.
>
> It changes things for ECDSA as well. We’re not going to change ECDSA in
> TLS 1.2. So if we wanted to adopt that we would still interpret 0x04,0x03
> as ECDSA (with whatever curve) along with SHA-256, while 0x07,0x03 would be
> Ed25519, not ECDSA with some unknown hash function 0x07.
>

Oops, I think I agreed to backport this at IETF 95 and completely forgot.
Sorry about that! My bad.

Although, thinking about it now, I'm not sure if we should bother. As you
mention, it's weird since ECDSA still needs to be interpreted in the 1.2
style, despite being spelled in the 1.3 way. We'd also end up with the new
scheme being defined in two places.

It seems better to get X25519 / X448 out the door first as that has no
prerequisites. X25519 in TLS already has running code today. Chrome ships
it, and Google servers have it enabled. The 1.1.0 release of OpenSSL is
also slated to have support.

Ed25519 / Ed448, on the other hand, don't even have an embedding in X.509
yet (though hopefully the main question remaining will get resolved in
curdle soon). Then there's the timeline for draft-irtf-cfrg-eddsa, which
I'm not familiar with. New signature schemes also depend on CAs being
willing to sign them which, for the web PKI, I expect will not be fast. Saying
new signature schemes are only defined for 1.3 and up seems reasonable
enough to me, though I suppose it depends on how the timelines for all the
other drafts end up looking.

David

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Jul 2016 21:23:32 +0300

> On 4 Jul 2016, at 7:12 PM, David Benjamin <[email-masked]> wrote:
> 
> On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> https://github.com/tlswg/rfc4492bis/pull/23 <https://github.com/tlswg/rfc4492bis/pull/23>
> >>
> Oops, I think I agreed to backport this at IETF 95 and completely forgot. Sorry about that! My bad.
> 
> Although, thinking about it now, I'm not sure if we should bother. As you mention, it's weird since ECDSA still needs to be interpreted in the 1.2 style, despite being spelled in the 1.3 way. We'd also end up with the new scheme being defined in two places.
> 
> It seems better to get X25519 / X448 out the door first as that has no prerequisites. X25519 in TLS already has running code today. Chrome ships it, and Google servers have it enabled. The 1.1.0 release of OpenSSL is also slated to have support.
> 
> Ed25519 / Ed448, on the other hand, don't even have an embedding in X.509 yet (though hopefully the main question remaining will get resolved in curdle soon). Then there's the timeline for draft-irtf-cfrg-eddsa, which I'm not familiar with. New signature schemes also depend on CAs being willing to sign them which, for the web PKI, I expect will not be fast. Saying new signature schemes are only defined for 1.3 and up seems reasonable enough to me, though I suppose it depends on how the timelines for all the other drafts end up looking.

The CFRG draft is not the limiting factor. We’re waiting for draft-ietf-curdle-pkix-00. 

But honestly, I don’t think anyone is going to be issuing EdDSA certificates any time soon. The commercial CAs have just recently starting using ECDSA, and even for local CAs you generally don’t use a new algorithm until every relying party in your environment supports it.

Yoav