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

From: Dave Garrett <[email-masked]>
Date: Mon, 3 Nov 2014 16:51:09 -0500

It was suggested by an HTTP WG member that I propose this on the TLS WG list. HTTP WG list CCed.

TL;DR: Please publish an improved TLS spec for HTTP/2 before working on an ideal one.

HTTP/2 has a problem: Section 9.2.2 of the current draft imposes security restrictions onto the 
usage of TLS that some implementors believe may be difficult to properly handle based on their various 
situations. There are interoperability issues that must be considered because of it. There would be 
new interoperability issues if it were to be removed at this late stage.

The general consensus, I believe, is that 9.2.2 imposes reasonable restrictions, however these 
restrictions do not ideally belong in an HTTP spec but rather a TLS spec. The pre-existing system to 
negotiate this topic is the TLS version, however TLS 1.3 is not and will not be ready in time for a 
final HTTP/2 specification. Section 9.2.2 could possibly be passed with some modification, however it 
is not the ideal solution.

I would like to propose a relatively simple solution:

1) Move the current TLS 1.3 draft and all future development to TLS 1.4
2) Write a new TLS 1.3 draft based on TLS 1.2 with no compression and requiring AEAD and FS
3) Rewrite HTTP/2 section 9.2 with a requirement of TLS 1.3 instead of TLS 1.2 with restrictions

This is more appropriately a proposal for a TLS 1.2.1, however the versioning scheme is not set up 
to handle this.

The goal of this proposal is to merely take the TLS requirements that are desired for HTTP/2 and to 
publish them in a separate, more appropriate specification. This would notably simplify negotiating a 
valid HTTP/2 connection over TLS. A streamlined TLS 1.3 spec would also be available for usage with 
HTTP/1.1 connections as well as any other applications. This would make setting up properly 
configured TLS far simpler, as mitigations for known-bad portions of the TLS 1.2 spec would no longer 
be needed. (e.g. compression & RC4 need not be disabled; they are not supported in TLS 1.3) The 
minimum key size requirements of 9.2.2 could also be added to make them far easier to enforce.

This TLS 1.3 proposal contains nothing fundamentally new. It merely aims to remove old no longer 
acceptable portions of the spec in order to simplify the process of implementing modern standards. 
As such, it would maintain on-the-wire compatibility with TLS 1.2 with the sole exception of the 
version number. The only differences would be restrictions what can be negotiated. The process of 
implementing and testing this would be relatively simple, making it feasible to finalize within the 
timeframe needed to be mandated by HTTP/2. (with possibly only a small delay, which already seems to 
be a possibility)

Dave

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Nov 2014 15:16:07 -0800

-HTTP

> 2) Write a new TLS 1.3 draft based on TLS 1.2 with no compression and requiring AEAD and FS

The reason we are all getting approval to spend inordinate amounts of
time and money on TLS 1.3 is that it is going to make things better,
not just with respect to security (TLS 1.1 and 1.2 tried that and it
didn't make a material difference to actual security), but also with
respect to latency.

My prediction is that not doing the latency improvements, and doing a
revision with a promise to follow with another revision a short time
afterwards will result in virtually no one using this intermediate
revision.  But that's just my prediction.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Nov 2014 19:59:37 -0500

> afterwards will result in virtually no one using this intermediate revision.  But
> that's just my prediction.

Agreed.

At one point we considered just doing "TLS 1.2 the editorial fix-up" edition.  Someone could still do that.  Codifying existing practice, pulling in widely supported extensions and cipher suites, etc.  But it will probably be a lot of work for very little gain.  (Compared to say the HTTP/1.1 great rewriting....)

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Yoav Nir <[email-masked]>
Date: Thu, 6 Nov 2014 09:21:02 +0200

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 6 Nov 2014 10:02:54 +0200

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.

Yoav

> On Nov 6, 2014, at 9:50 AM, Dave Garrett <[email-masked]> 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:
> 
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0481.html
> 
> 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
>> 
>> 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

---

From: Dave Garrett <[email-masked]>
Date: Thu, 6 Nov 2014 02:50:10 -0500

Dave

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Nov 2014 21:08:46 -0800

On 5 November 2014 23:50, Dave Garrett <[email-masked]> wrote:
> I should
> note that this is already something Mozilla is implementing with respect to RC4.

We're only doing that because it aligns the incentives correctly.
Sites using RC4 get to continue doing so (for now), but are penalized
for doing so.

Requiring Greg's proposed fallback causes almost all browser users to
be penalized for attempting to use HTTP/2.  Very few sites currently
use a TLS profile that is even potentially HTTP/2 compatible, so those
users are the ones who pay.

I don't like creating externalities like this.