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

Yoav Nir <> Thu, 06 November 2014 08:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9283C1A06FD for <>; Thu, 6 Nov 2014 00:03:01 -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 WVi159DI-zfL for <>; Thu, 6 Nov 2014 00:02:58 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58E4F1A1A12 for <>; Thu, 6 Nov 2014 00:02:58 -0800 (PST)
Received: by with SMTP id f15so494209lbj.23 for <>; Thu, 06 Nov 2014 00:02:56 -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=ehL5n/WnNq0F70ixH5HGOZ2Q5gAQNut8vWQ6wz2G5sM=; b=AsCES/nRbn5ltbkNLdXlumLaLD+fc7T7+nJP2rjscqPjdo2/PHksE22scenvghaGz0 KwnXd30pu1uugF6Ms48fmUH0OvmCKi57mjxEros+jy+YRQQIwct3RYhyl9bwfF/a1Af3 i9+VygheDDYRj6U1l0+DtgCHwj5S2jfKw2zNarEhTJVa+k11qiFzoXXg+S8zjEWgqi3p hPvV9Uv5jpC9BFkkS79EqF5lgKuLnST/oiZh1I9CneT1GJvut6fDtz3Qs6GLwVvuGCoq XyrNRBO/PUPkar2WEnhtkagE600Xq+4b6qx/HdOHct1slZPG6uX3tHmscBxUtfe2IIHy X1RA==
X-Received: by with SMTP id t5mr2063013lag.88.1415260976641; Thu, 06 Nov 2014 00:02:56 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d9sm2235937lbp.49.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 00:02:56 -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 10:02:54 +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 08:03:02 -0000

Having this intermediate version also makes supporting HTTP/2 more difficult

The most common platform for an HTTPS server is Apache + modssl. Getting HTTP/2 support into Apache involves installing modhttp2. No way of getting around that necessity. But your proposal would require a new version of OpenSSL to be installed. That makes the administrator depend on the release schedule of OpenSSL. That’s a problem.


> On Nov 6, 2014, at 9:50 AM, Dave Garrett <> wrote:
> For clients wanting to attempt a fallback, yes, this might not be a perfect solution. It is, 
> however, far better than the current state. Ciphers would not have to be assessed and implementation 
> of the restrictions would be far more simple and clear. Moving the painpoint, as you say, would be a 
> notable improvement. One simple check vs. a handful of possibly complex checks.
> At this point, Greg Wilkins' proposal looks to be the best available option getting any discussion:
> An HTTP/2 handshake would not be able to include any legacy ciphers, and if this fails then the 
> client could then fallback and retry with HTTP/1.1 instead. It gets a more robust handshake in 
> exchange for a slightly slower fallback if the server does not support any modern ciphers. I should 
> note that this is already something Mozilla is implementing with respect to RC4. The plan is to do 
> the initial handshake without RC4 and only offer it as a possibility if the more ideal cipher set is 
> rejected. (fallback order becomes: 1.2-RC4, 1.2+RC4, 1.1+RC4, 1.0+RC4)
> Dave
> On Thursday, November 06, 2014 02:21:02 am Yoav Nir wrote:
>> 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.
>> Yoav