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.)
David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
