On 31 October 2016 at 23:13, David Benjamin <david...@chromium.org> wrote: > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx <k...@roeckx.be> wrote: >> >> On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote: >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara >> > <ilariliusva...@welho.com> >> > wrote: >> > >> > > On Mon, Oct 31, 2016 at 06:43:52PM +0000, Matt Caswell wrote: >> > > > A few supported_versions questions: >> > > > >> > > > 1) What should a server do if supported_versions is received but >> > > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just >> > > > ignore legacy_version? >> > > >> > > If legacy_version > TLS1.2, the spec requires server to ignore >> > > legacy_version. >> > > >> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but >> > > ignoring legacy_version is reasonable in this case too. >> > > >> > > > 2) What should a server do if supported_versions is received, >> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does >> > > > not >> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail >> > > > the >> > > > handshake, use the legacy_version, or use use the versions in >> > > > supported_versions? >> > > >> > > There's also the case where supported_versions has TLS 1.1 and TLS >> > > 1.4, >> > > the latter the server has never heard about... >> > > >> > > > 3) If the answer to (2) above is ignore the legacy_version, and just >> > > > use the versions in supported_versions, which client_version should >> > > > be >> > > > used in the RSA pre-master secret calculation? The one in >> > > > legacy_version, or the highest one in supported_versions? Presumably >> > > > it has to be the one in legacy_version, otherwise thing will fail >> > > > when >> > > > the client talks to a server that doesn't understand >> > > > supported_versions? >> > > >> > > Yeah, I presume putting the version in legacy_version is the only sane >> > > thing to do. But causes other problems with downgrade protection. >> > > >> > > OTOH, RSA key exchange is known to be very broken and is affected by >> > > all kinds of downgrade (and other) attacks. So if one wants actual >> > > security, it needs to be removed. >> > > >> > >> > We could say the versions extension only applies to 1.2 and up. I.e. >> > don't >> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and >> > 1.0 >> > when they see them in the version list. That keeps the protocol >> > deployable >> > on the Internet as it exists, avoids having to evaluate too versioning >> > schemes (if you see the extension, you don't bother reading >> > legacy_version >> > at all), while avoiding the weird behavior where, given this >> > ClientHello: >> > >> > legacy_version: TLS 1.2 >> > supported_versions: {TLS 1.1} >> > >> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2. >> >> So I guess you're also saying that a server that implements TLS >> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should >> ignore the supported_versions even when it knows about it? >> >> I guess I have same questions but with only TLS 1.3 disabled, to >> be sure when we need to look at it. > > > Hrm, actually I hadn't thought of that. Yeah, I guess a server which > disables versions must then gate supported_version handling on whether TLS > 1.3 is enabled. That's not a dealbreaker, but is certainly additional > gnarliness. > > (Our current implementation just processes the extension uncondtionally, but > we'll also happily negotiate old versions out of it.)
I came up with some alternative wording that I think captures the discussion: https://github.com/tlswg/tls13-spec/pull/748 Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls