Re: [TLS] PR #23 for RFC4492bis

[David Benjamin <[e-mail]>]

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

>
> > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <[e-mail]>
> wrote:
> >
> > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote:
> >> 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.
> >
> > 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).
>
> 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.
>

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