On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir <ynir.i...@gmail.com> wrote: > > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <ilariliusva...@welho.com> > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
