On Thursday, 15 September 2016 12:22:03 CEST Hubert Kario wrote: > On Wednesday, 14 September 2016 19:02:14 CEST Andrei Popov wrote: > > > 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? > > it means the same when I disable support for TLS 1.2 in current version of > OpenSSL - it should negotiate TLS 1.1 as it is the highest mutually > supported version. We don't care what the server's or client's code can do > in absolute, we care what it is configured to do. See also: FALLBACK_SCSV > handling. > > 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. > > and a list with opaque version identifiers (just int16 values) won't?
also, I'm not sure if it's really such a bad thing, it's certainly better than some Russian sites selecting TLS_RSA_WITH_AES_128_CBC_SHA but actually using GOST cipher... -- 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
