Basically, I don't feel strongly about the switch to the proposed version negotiation mechanism. But if we are going to make this change based on the theory of having only one extension point and actively defending it, then we should probably follow the theory and send a separate TLS extension per TLS version. > I don't think we should depart from the "highest mutually supported version" > negotiation algorithm... Correct, but it's not clear what represents "the highest" protocol version in the world where national TLS "standards" exist. Is country X-TLS (e.g. with integrated MITM support) a higher version than TLS 1.3? The server will make a choice based on the server's preferences. In a way, the proposed version negotiation mechanism makes it slightly easier to implement servers that support country X-TLS alongside IETF TLS versions.
Cheers, Andrei -----Original Message----- From: Hubert Kario [mailto:hka...@redhat.com] Sent: Wednesday, September 14, 2016 11:03 AM To: Andrei Popov <andrei.po...@microsoft.com> Cc: David Benjamin <david...@chromium.org>; tls@ietf.org Subject: Re: [TLS] Version negotiation, take two On Wednesday, 14 September 2016 17:39:59 CEST Andrei Popov wrote: > Do you mean a TLS extension code point per TLS version? yes, e.g. if extension 0x00a0 is present assume TLSv1.3 support, 0x0121, TLSv1.4; same way EMS and MtE works > One argument against this was that this makes it difficult to express > the client's prioritization of TLS versions, but IMHO arguably the > server should not care. I don't think we should depart from the "highest mutually supported version" negotiation algorithm, any kind of preference in the client list is likely to cause additional problems - version misnegotiation if client will want to advertise support for TLSv1.3 and TLSv1.5 but not TLSv1.4 it will still be able to do that > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Hubert Kario > Sent: Wednesday, September 14, 2016 9:40 AM > To: David Benjamin <david...@chromium.org> > Cc: tls@ietf.org > Subject: Re: [TLS] Version negotiation, take two > > On Wednesday, 14 September 2016 16:17:50 CEST David Benjamin wrote: > > > Yes, we find list intolerance too---servers which only look at the > > second byte in a cipher suite, servers which forgot a default in > > their NamedGroup switch-case, servers which get confused on unknown > > HashAlgorithms, servers which require the final extension > > non-empty---but this is dramatically less than version intolerance. > > It's usually within tolerable levels that we needn't resort to fallbacks. > > > > The proposal switches from something which we know does not work to > > something new. Perhaps this new one will break too, but it is very > > similar to things that have worked before, and I am hopeful that > > GREASE will help. > > Was the option to do "one extension point = specific TLS version supported" > > discussed too? What arguments are there against it? > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
