Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2

Yoav Nir <> Thu, 06 November 2014 07:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D63B1A0117 for <>; Wed, 5 Nov 2014 23:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Nj9zySMoVpo for <>; Wed, 5 Nov 2014 23:28:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD1691A00E6 for <>; Wed, 5 Nov 2014 23:28:32 -0800 (PST)
Received: by with SMTP id h11so584445wiw.9 for <>; Wed, 05 Nov 2014 23:28:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SgeKVJeVZ3fjg6LoBGe5x5aM3bI9cDqVmkFWPJZabLk=; b=wD7L6plydqV4RLkPq8SUnF41PK7raMmpNQ7umdKNSjjX4/8HDcl7ufgkHeJhnCpM8j vJhpWjxgVDOHOhgK+yPvUIc0IKxOWmVl7aqv+R6hH6PoEJ3Y3WZRTFa4g8STytLZTgdB 4L/GM/qruNgH3bu5knfW2US9DnABIkXZ24B/YSRf7iwuL/llrHBI5lssa+xYOZ9cNznZ gfGQPHJytBaa5ZVE7RlDBSQHlBjJ79CYvKSxBN4L1/SSPJ23Q/qR+lTuychi1iNBIhLB mE0enXtwVhs0Hpfr8gHR2/mUG8rH4CfjnL8Yi3j/ro+/HUTgWWwRvhy+flhFV9rEqxPD IXNw==
X-Received: by with SMTP id o20mr39140369wiv.12.1415258464913; Wed, 05 Nov 2014 23:21:04 -0800 (PST)
Received: from ([]) by with ESMTPSA id td9sm7173574wic.15.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 23:21:04 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 06 Nov 2014 09:21:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Dave Garrett <>
X-Mailer: Apple Mail (2.1990.1)
Cc: " (" <>
Subject: Re: [TLS] Proposal: a minimal TLS 1.3 for HTTP/2
X-Mailman-Version: 2.1.15
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: Thu, 06 Nov 2014 07:28:36 -0000

Hi, Dave

I believe that ultimately this does not solve the issue raised about 9.2.2 on the httpbis list.

The issue there was that a client would propose AES-CBC and AES-GCM (forgive me for shortening the grouping suites) with “h1” and “h2”, and then it’s up to the server to know that the AES-CBC and “h2” combination is prohibited by the HTTP/2 spec. This could be done either by the HTTP layer checking on the TLS layer, or by adding callbacks and APIs for the HTTP layer to make the choice of ciphersuite for the TLS layer, or by incorporating some HTTP/2 specifications into the TLS layer. People claimed that this was either ugly or hard to implement.

The issue does not go away with your proposal. The reason servers support “h1” at all is to support legacy clients, and the reason clients propose “h1” and non-AEAD ciphersuites at all is to support legacy servers. What your proposal does is move the pain point from ciphersuite selection to version selection. A client would still propose TLS 1.0, TLS 1.1, TLS 1.2, and if it’s updated, TLS 1.3. A server would still have to know that the “h2” and TLS 1.2 combination is invalid, and the complexity remains.

It’s true that the current requirement in HTTP/2 has this issue anyway, as it prohibits TLS versions under TLS 1.2, but I’m in the “rip out 9.2.2 and live with whatever the TLS layer negotiates” camp.