Re: [TLS] supported_versions question

Eric Rescorla <ekr@rtfm.com> Mon, 31 October 2016 23:35 UTC

Return-Path: <ekr@rtfm.com>
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 9343C129BC6 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 16:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 IxWJWPR0pL6r for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 16:35:52 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32A7129ADD for <tls@ietf.org>; Mon, 31 Oct 2016 16:35:51 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id l124so20848134ywb.3 for <tls@ietf.org>; Mon, 31 Oct 2016 16:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A9Y61Zm2IIobsMFeMNgurKXS4WxHrX90GprLUSUYZ/o=; b=VDJSJxF2Jt9yJsSWWGZNJaDXfhrbTyoeBOgkkVsgx2hl5D/wrZSc9F32iGjsNx5CQi Sd06YOze4mOM9nGhsXLPp/IBaz1BYrnDyo4Ne1kfLn9QYS3uTkJOw6+3+crTPCuju54v DxOSFp8wPRLJnKqwMtK0tljDbNtBs6FbEB8V7WdhqGbAeKvU6loIwG5YmdNnJc1wgvsX 8G8hl5RvDBZix6EDihQhyiDUYnHdqZ3yczrBg9+XfZcf6jPH6mMfzqjr1bmF/nhRcNcs PBoz7ixM7bsfFcmKVcSZpaMHxDTAP+rUS+VGkuv19Tbfl1FHRQA9r0o+CVKXWF05NDUZ mGMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A9Y61Zm2IIobsMFeMNgurKXS4WxHrX90GprLUSUYZ/o=; b=k8Lm7QlbouO8Qnd/dRwdHb2pBFKXNM0CfXDWLbtkILx6fPVxQOQtF7kHa8ZV+ru2W/ idCfnkc9L0qbQDTEdGjDB61d2KpTe/7VjvdXLYZEQ/t1gauGdbcVb4yQu41+WrBfyYmd JHZZVPrXx8p8XKwXWl1sI+a9kKMVd8crlLs/3jnNR3ot8+87MVUUk34YJ4tE1OG+ZUMi 4+wXuJaAJgu5tgexFnE1Gz+ICK0PaUjO79vkry96Jfy1EtJ/+Aoj/zBJ9k2j8SPCuuW4 ALArn82W7Oewk1NXJPuZmH73EBFsgTmHk9C5NrHSHG61vrhtJq1At2KEh8kiAQ9lC4ND YE2Q==
X-Gm-Message-State: ABUngvd4gBmOVSG66riCBzhu6CB3Nm3RWLYB6kBBMWiUxwJo74QUQPtEjTHx9oll6i83vboMjsb0Dg49r9NaCQ==
X-Received: by 10.129.121.1 with SMTP id u1mr8085763ywc.146.1477956950956; Mon, 31 Oct 2016 16:35:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Mon, 31 Oct 2016 16:35:10 -0700 (PDT)
In-Reply-To: <CAF8qwaAEfa2V4g+fqG0we+cer5PPrgA3jLQZbJfvq5dKTvs_-A@mail.gmail.com>
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com> <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaCe89epMMzCA0BNfXWss9FWpDze8ScydufdoTNTNqmW1g@mail.gmail.com> <20161031223431.6j23de5gyqx6vpop@roeckx.be> <CAF8qwaAEfa2V4g+fqG0we+cer5PPrgA3jLQZbJfvq5dKTvs_-A@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 31 Oct 2016 16:35:10 -0700
Message-ID: <CABcZeBPjye1RZZKXNB9mkeJ_uFc2QxyW3bX80NDK6uAn2x50qg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=94eb2c0a8f820e72a0054031abff
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9Ba1HkUebo1BBj4JEGAMEucd9iQ>
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 23:35:54 -0000

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.

-Ekr


On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin <davidben@chromium.org>
wrote:

> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx <kurt@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 <
> 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.
>
>
> 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
>
>