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...

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

Attachment: signature.asc
Description: This is a digitally signed message part.

TLS mailing list

Reply via email to