Re: [TLS] supported_versions question

Dave Garrett <> Tue, 01 November 2016 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24EC1129BFB for <>; Mon, 31 Oct 2016 17:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id khi1d2A_IYny for <>; Mon, 31 Oct 2016 17:19:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69570129981 for <>; Mon, 31 Oct 2016 17:19:18 -0700 (PDT)
Received: by with SMTP id z190so181455517qkc.2 for <>; Mon, 31 Oct 2016 17:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=XbsNC2Q1QJAObatZgAo8/ik6jRmn5Q3E5HCyLFzv/+s=; b=GxbVhZ5e7GGmHNpT6xbwNInguStvy4X3lXS+4hn5yKokPJPjzYalt2kPWPkXUOp1RA omGTLgUtViyUoXSBkOtz4fiB1SEQFdgk+4Tj/llCWtTN4ms2lcTYP1IRG/UHD5DAeW/g Ew+kyZQfI8ifMfA5wZSjtRSZR7JHAI2IOeaAHFZmOD/In/3iPavHmSimSvwZffZVMIjp e8N8DipdLk4PImP8kDfsmmlF8wKniMBXvI4QmnoX4Gj4gMFvIO6ybpSvFEJOVQzHTVTQ mE2wWNcmFidk+Y4yGe28OFEvzeaqFeVeahtJ6T9/XybDWyv4ezoY5x6JrMFCKQqQuliK fi8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=XbsNC2Q1QJAObatZgAo8/ik6jRmn5Q3E5HCyLFzv/+s=; b=CblqQkWJe72SRiZaUnfuS03EqB/UdDL1NLp5ZQ6wGEQkxio/0i7B1po80A7s4TGpMm zSdX+dKiyd1W0XXWzbCFnNPSHS652R5QxC27GnsSASPtHV7ssYyilrxYLegMYoIkV47E XdAYKEgkmtLrQqb9h9lct92ctePuBxTWtZd3JHVHmIMJC/cDswjLzlnNpctEvPbo26t5 a4/bIZwPP+66N6nmql66SosR+Y+QtsYYL2V9tcTlO2kY8frdq8CWI0Rh6ypvDPnsMcER G+14v9Xjcs4RwDz95zzwHlcKT7Vzlcij6dYj3kw+5agAhJkH9/CogWPqgQszLrazbITv ToJA==
X-Gm-Message-State: ABUngve7D6oqpWDIwm515sVWMX1MD8D0H2XzNyHa5q4mrEBrW28o3kHGk6V4mAPIJDsOfw==
X-Received: by with SMTP id r77mr24574832qka.318.1477959557539; Mon, 31 Oct 2016 17:19:17 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id o31sm128014qtf.20.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 31 Oct 2016 17:19:16 -0700 (PDT)
From: Dave Garrett <>
To: Matt Caswell <>
Date: Mon, 31 Oct 2016 20:19:15 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] supported_versions question
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Nov 2016 00:19:20 -0000

On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> On 31/10/16 23:53, Dave Garrett wrote:
> >> I came up with some alternative wording that I think captures the discussion:
> >>
> >>
> >
> > 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.
> If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
> 0x0303 (TLS1.2) - or vice versa, which client_version should be used
> in an RSA key exchange calculation?

Why would this ever happen? What client is offering to support TLS 1.1 via the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension? This is a very contrived implementation error; if you need to account for it, abort the connection with an error. As to the vice versa, dropping 1.0/1.1 support from the extension avoids that.

The simplest route here is to always use the extension if it exists, and use the legacy value if not. With 1.0/1.1 removed from the extension, that means that 1.0/1.1 cannot be negotiated with the extension, which I see as fine; they'll only be negotiated with servers that don't support the extension. (the theoretical case of a server wanting to negotiate 1.0/1.1 with a client using the extension is not one worth supporting; 1.2+ or bust is reasonable, here)