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