On 31 October 2016 at 23:35, Eric Rescorla <[email protected]> wrote: > Our current implementation also processes the extension unconditionally. > > I'm not convinced that this represents an improvement, both for the reason > that Kurt > indicates and just in terms of simplicity of story. The current design is > simply > "if supported_versions is present, then use it", whereas trying to clip it > on 1.2 > is inherently more complicated. I'm not particularly bothered by the anomaly > that David mentions between legacy_version and supported_versions, > especially > given that we're perfectly happy to tolerate deviation the other way.
My biggest concern is that there are a number of corner cases here where it is unclear what to do because the current wording doesn't specify it (see my original questions at the start of this thread). Like, I said earlier, it could be made to work If retaining <TLS1.2 in supported_versions is desirable, but in that case we need to specify how we should treat legacy_version and what to do if it isn't 0x0303 - and in the RSA key exchange case which client_version are we using? Matt > > -Ekr > > > On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin <[email protected]> > wrote: >> >> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx <[email protected]> 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 >>> > <[email protected]> >>> > 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.) >> >> David >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
