Re: [TLS] supported_versions question

[Hubert Kario <[e-mail]>]

On Monday, 31 October 2016 20:19:15 CET Dave Garrett wrote:
> On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> > On 31/10/16 23:53, Dave Garrett wrote:
> > >> I came up with some alternative wording that I think captures the
> > >> discussion:
> > >> 
> > >> https://github.com/tlswg/tls13-spec/pull/748
> > > 
> > > I see no reason to require servers to validate the legacy version value.
> > > That's just excess complexity. If the extension is there, then it
> > > should take absolute precedence. If not, use the old system. Nothing
> > > will have a higher value there except old probers.> 
> > If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
> > 0x0303 (TLS1.2) - or vice versa, which client_version should be used
> > in an RSA key exchange calculation?
> 
> Why would this ever happen? What client is offering to support TLS 1.1 via
> the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension?
> This is a very contrived implementation error; if you need to account for
> it, abort the connection with an error. As to the vice versa, dropping
> 1.0/1.1 support from the extension avoids that.

could be a result of fallback dance

And I think it should be treated the same way signature_algorithms are - 
inapplicable to TLS1.1 and lower - thus ignore completely

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