Re: [TLS] draft-ietf-tls-tls13-16

Stephen Checkoway <> Wed, 28 September 2016 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EFE112B198 for <>; Wed, 28 Sep 2016 09:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 odX7W3vo2WJC for <>; Wed, 28 Sep 2016 09:02:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B23F12B20B for <>; Wed, 28 Sep 2016 09:02:42 -0700 (PDT)
Received: by with SMTP id w11so59180187oia.2 for <>; Wed, 28 Sep 2016 09:02:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=VDZjey8yHLVv/malDTATKIw/xUtHkvYluYoZyJap7ak=; b=ty1clCrcELVoQJ5N5gAobpXk4t5y3JnTCrNOJdHVITrc2RIxBpR2HYEXy/Z7KXadsV fQlgztzvZjVN/zWwkheQQY9p0dVeB0lg7G/KrQeZsvKkyV+WT6UKxLlgYE0jue05V7ZE QrD4y1J9C3Mr/Y7Z6ONEEBThScoj+txS3ExuPXruCRAptfVgCGpWncDwbjvAqYs9lU/l cE8FcEgiOIBnsSnq4S0ZnVDMmLAnYghx55ggGK417yYyXfijZgmJ2DLXtSTtKSkrKi2c Dnoc4zGL9dc1HrvHQNIIP01aYgTtQKmfLLXbPvj7rdUdvTFyCh6CReJqB8YAsQ2MhPe+ Yn0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=VDZjey8yHLVv/malDTATKIw/xUtHkvYluYoZyJap7ak=; b=YqEonBUzrAr2NdaXN7z974T0AnyO8txN+Vv7W+oaqZbJ+e8pj27WpJTPbxB3y7/bhA sXl0ahcA5jVpGFqo6E3OJFhXPuuH1tSHrAwWNAUVDYGZdXeYykfWTTZQ/UoSohkLN4wX aqQReeC8gqrWJcET7Z/FPzNWSKvFvRChP8O/fIqb34U8WPUQCIN1n92KlOaKUl4j6gvr cFTPmDH/M5Ju8B2AqXYOaW+EIWVUz4gMBqm6lIgZFjEaBXPgz1bNa+yuWQVUol6dG1GN jabLtxPpmQ/JyPy4YamLRAFxcFcLUuBpNYZ1xeFB7NI9K3aXfvjgztqH+0DPgGJ8CAGM 8WdQ==
X-Gm-Message-State: AA6/9RlaupCDg03qIao9be/d0ejU5Qw9eK7NJJyLnaNrjPIZN08shYhB4LufxtbQ+FibuQ==
X-Received: by with SMTP id g204mr2846182itb.42.1475078560991; Wed, 28 Sep 2016 09:02:40 -0700 (PDT)
Received: from ( []) by with ESMTPSA id y76sm3172387ioi.5.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Sep 2016 09:02:40 -0700 (PDT)
Received: from (router []) by (Postfix) with ESMTPSA id E44FDAC2C24 for <>; Wed, 28 Sep 2016 11:02:38 -0500 (CDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Stephen Checkoway <>
In-Reply-To: <>
Date: Wed, 28 Sep 2016 11:02:38 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "" <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [TLS] draft-ietf-tls-tls13-16
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: Wed, 28 Sep 2016 16:02:58 -0000

> On Sep 22, 2016, at 6:42 PM, Eric Rescorla <> wrote:
> - New version negotiation format (*) [IMPORTANT: this got lost in the ChangeLog]

4.2.1 Supported Versions says, "The extension contains a list of
   supported versions in preference order, with the most preferred
   version first."

C.2 Negotiating with an older client says, "If the
   "supported_versions" extension is present, the server MUST negotiate
   the highest server-supported version found in that extension."

I'm skeptical of the server respecting client preferences in any situation*, but if servers are required to negotiate the highest supported version (which I think is sensible), then there's no point to the client giving preference order.

I propose moving the text about which version a server must negotiate out of the appendix to 4.2.1 and replacing the text mentioning client preference order with arbitrary order. (We could mandate descending version order, but it seems silly for the server to reject 0304, 0302, 0303 
if it's willing to negotiate 0304, for example.)

* The only time to take the client's preference into account is if the server really has no opinion on an option--e.g., two equivalent-strength cipher suites--but the client can specify a preference for an option that requires less computation/power for it. But I'm not entirely convinced that's worth the implementation cost.

Stephen Checkoway