Re: [TLS] supported_versions question

Dave Garrett <davemgarrett@gmail.com> Mon, 31 October 2016 23:53 UTC

Return-Path: <davemgarrett@gmail.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 4EC53129BD0 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 16:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 X8dW1Ocxje_9 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 16:53:28 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 3CEBA129462 for <tls@ietf.org>; Mon, 31 Oct 2016 16:53:28 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id z190so180926016qkc.2 for <tls@ietf.org>; Mon, 31 Oct 2016 16:53:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=JZxEwWU/31Uf5d8EmX4xFYqoG3j/tjqstcglxlCz5RQ=; b=mC0TL1q4jAdd75xeqqMcsSQ89MzXHcMUa15XRC3XnsjqQhWGixpbqSXbG/nzpLFGSI gfbVAvLnXUjegQQiq/OOGaRqlmuDt/QHawEpwpX/ttCqAwQdOAdrJNTTWeYSa/5M/LAh 8igEH1sHl9asIRl8f0Y5TW9qJ8f9ZZzuhRwtODG1xtQduJPieRK7l94g3UsnMhb11IAH 3HXNwTJKNUKQYpajfE7OTkVsW1JilF5A/MVcPYMHwACLTGAADJodaYglXX70pJluuAny arEo9HR55n0FpRK+dcC71mICGRoShs/1SiIAqZIiWBKbHHXUHU3G9CbQmEGhRBCZSqik nw/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=JZxEwWU/31Uf5d8EmX4xFYqoG3j/tjqstcglxlCz5RQ=; b=OIbhg5+HgXivc0zCbjmBTUwpcVEVhydlRmSoDZaSq8ZzPGYnoSFkO317+lMTf/IR2V j9F9QFp9Z66KeVLPI1OKINWweXLPmLOn/BHrezq3u8WwtoliIx+uIDl/lmkSx+3Rtk4R Xylayr+flhgNLZWk9CKqmKsNJdNPGS2KqjwKdLO8WFRGLllI6flYEPGXM9ZKr8rRJmo8 wpxb7xMvrH+/MY1wJO2J7AS6NUimKLJruiO/hYb25j3wo7F51nqoM9SzPlt6f8fTT3mL z3bI6iAnDxE70JW5cXcgTg8CnS9IXZyyMLILImYyVg5gulCoooYDBFfFCq9Cgbgvkpce qenA==
X-Gm-Message-State: ABUngvcTdOjhAxCBI5apYBzYjIj90UXCm6gvVxKxkOE4PV6Uf6ao4661YAy99yG5EhjBOw==
X-Received: by 10.55.170.131 with SMTP id t125mr26937568qke.15.1477958007350; Mon, 31 Oct 2016 16:53:27 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id v10sm14464375qkg.20.2016.10.31.16.53.26 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 31 Oct 2016 16:53:26 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 31 Oct 2016 19:53:25 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAMoSCWaVJy9f6NFy1Msc1_VSDxRFM2pruhecWb+22N4ct-t0+g@mail.gmail.com> <CAF8qwaAEfa2V4g+fqG0we+cer5PPrgA3jLQZbJfvq5dKTvs_-A@mail.gmail.com> <CAMoSCWaFUXYB6NFaJ0rpYY8Nk7XMUtW5+9J_i_6MdDm0F=-r9g@mail.gmail.com>
In-Reply-To: <CAMoSCWaFUXYB6NFaJ0rpYY8Nk7XMUtW5+9J_i_6MdDm0F=-r9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201610311953.25606.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BGBc1_A0OWvPTA89q1WRWNh0vA4>
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:53:30 -0000

On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote:
> On 31 October 2016 at 23:13, 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.)
> 
> I came up with some alternative wording that I think captures the discussion:
> 
> https://github.com/tlswg/tls13-spec/pull/748

I see no reason to require servers to validate the legacy version value. That's just excess complexity. If the extension is there, then it should take absolute precedence. If not, use the old system. Nothing will have a higher value there except old probers.

Ditching TLS 1.0/1.1 from the extension sounds fine, though. There's not going to be any servers accepting this extension that won't negotiate 1.2+.


Dave