Re: [TLS] Version negotiation, take two

[Hubert Kario <[e-mail]>]

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?
 
> Cheers,
> 
> Andrei
> 
> -----Original Message-----
> From: Hubert Kario [mailto:[e-mail]] 
> Sent: Wednesday, September 14, 2016 11:03 AM
> To: Andrei Popov <[e-mail]>
> Cc: David Benjamin <[e-mail]>; [e-mail]
> 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:[e-mail]] On Behalf Of Hubert Kario
> > Sent: Wednesday, September 14, 2016 9:40 AM
> > To: David Benjamin <[e-mail]>
> > Cc: [e-mail]
> > 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


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