Re: [TLS] supported_versions question

Kurt Roeckx <kurt@roeckx.be> Mon, 31 October 2016 22:34 UTC

Return-Path: <kurt@roeckx.be>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946CF129B98 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 15:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-mFl2XmKHRG for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 15:34:34 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63FE129BA4 for <tls@ietf.org>; Mon, 31 Oct 2016 15:34:33 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 68D60A8A0406; Mon, 31 Oct 2016 22:34:32 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 27C671FE023E; Mon, 31 Oct 2016 23:34:31 +0100 (CET)
Date: Mon, 31 Oct 2016 23:34:31 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: David Benjamin <davidben@google.com>
Message-ID: <20161031223431.6j23de5gyqx6vpop@roeckx.be>
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com> <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaCe89epMMzCA0BNfXWss9FWpDze8ScydufdoTNTNqmW1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAF8qwaCe89epMMzCA0BNfXWss9FWpDze8ScydufdoTNTNqmW1g@mail.gmail.com>
User-Agent: NeoMutt/20161014 (1.7.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GO54FLLIJb99ncxPk4x-gtT93no>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] supported_versions question
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2016 22:34:39 -0000

On Mon, Oct 31, 2016 at 07:11:10PM +0000, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara <ilariliusvaara@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.


Kurt