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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
