Do you mean a TLS extension code point per TLS version? 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.
Cheers, Andrei -----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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
