Subject: Requiring TLS 1.3 as alternative to HTTP/2 section 9.2.2

From: Dave Garrett <[email-masked]>
Date: Tue, 28 Oct 2014 01:42:57 +0000

It looks like HTTP/2 section 9.2.2 is on the chopping block, with little push-back thus far, so I'm going to ask the obvious question: what's going to replace it?

Attempting to enforce cipher requirements here is problematic, however removing these requirements will also add its own interoperability problems. If a server were to follow the spec without these requirements, then a browser that already implements them will reject the connection. Unless everyone is also going to pledge to remove already implemented security checks, this will be an issue. Without 9.2.2, even RC4 is valid for HTTP/2 traffic, which seems like something implementors would fight against introducing.

There were a few people that suggested simply waiting for TLS 1.3 and requiring that instead of TLS 1.2 plus a series of hacks. Is it possible to fast-track TLS 1.3 from its current draft to standardization for HTTP/2, and move further TLS development to 1.4? This is the simplest solution and obsoletes almost all of section 9.2, not just 9.2.2.

I guess the real question is: can two working groups work together here?

-- Dave

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Oct 2014 18:58:08 +0200

Hi, Dave. This is just my opinion

HTTP, whether /1 or /2 is not unique. If anything, HTTP/1 is more
vulnerable to all sorts of attacks because of the COOKIE that is attached
to every request.

On Tue, Oct 28, 2014 at 3:42 AM, Dave Garrett <[email-masked]>
wrote:

> It looks like HTTP/2 section 9.2.2 is on the chopping block, with little
> push-back thus far, so I'm going to ask the obvious question: what's going
> to replace it?
>

IMO nothing.  TLS is deprecating RC4, standardizing encrypt-then-mac,
adding new AEAD ciphers, etc. These decisions make HTTP/2 more secure right
along with HTTP/1, SMTP, LDAP and all other protocols that use TLS. HTTP/2
is not a special case.

Attempting to enforce cipher requirements here is problematic, however
> removing these requirements will also add its own interoperability
> problems. If a server were to follow the spec without these requirements,
> then a browser that already implements them will reject the connection.
> Unless everyone is also going to pledge to remove already implemented
> security checks, this will be an issue. Without 9.2.2, even RC4 is valid
> for HTTP/2 traffic, which seems like something implementors would fight
> against introducing.
>

RC4 is no more dangerous to HTTP/2 than it is to HTTP/1.

There were a few people that suggested simply waiting for TLS 1.3 and
> requiring that instead of TLS 1.2 plus a series of hacks. Is it possible to
> fast-track TLS 1.3 from its current draft to standardization for HTTP/2,
> and move further TLS development to 1.4? This is the simplest solution and
> obsoletes almost all of section 9.2, not just 9.2.2.
>

TLS 1.3 is just getting started whereas HTTP/2 is almost done. I estimate
at least a year before TLS 1.3 is done, and I don't think HTTP/2 proponents
want to wait that long.

> They can, but standardization takes time.

Yoav

---

From: Michael Sweet <[email-masked]>
Date: Tue, 28 Oct 2014 13:01:31 -0400

Dave,

> On Oct 27, 2014, at 9:42 PM, Dave Garrett <[email-masked]> wrote:
> 

TLS/1.2 mandates TLS_RSA_WITH_AES_128_CBC_SHA, so at the very least that cipher suite will have priority over any of the RC4 cipher suites, assuming that they are enabled at all on the server.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Oct 2014 10:07:58 -0700

I’ve asked the TLS WG chairs of their estimate of when 1.3 will LC, and the answer was that they’re hoping to WGLC around Dallas, but that may be “too aggressive.” 

My perception is that there isn’t yet a lot of confidence about that date.

Regards,

> On 27 Oct 2014, at 6:42 pm, Dave Garrett <[email-masked]> wrote:
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Albert Lunde <[email-masked]>
Date: Tue, 28 Oct 2014 12:13:17 -0500

On 10/27/2014 8:42 PM, Dave Garrett wrote:
> push-back thus far, so I'm going to ask the obvious question: what's
> going to replace it?
>
> requiring that instead of TLS 1.2 plus a series of hacks. Is it possible
> to fast-track TLS 1.3 from its current draft to standardization for
> HTTP/2, and move further TLS development to 1.4? This is the simplest
> solution and obsoletes almost all of section 9.2, not just 9.2.2.

It's feasible to take a server that supports TLS 1.2, and disable legacy 
TLS ciphers that came from previous TLS/SSL versions.

This could satisfy the requirements of 9.2.2, and serve up HTTP 1.1 as 
https too. But this is just server configuration rather than a special 
handshake. It's a non-hack.

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: Erik Nygren <[email-masked]>
Date: Tue, 28 Oct 2014 14:03:36 -0400

Is there an operational approach we can take that gets us to the right
place eventually
(or at least within a reasonable time-frame)?

For example, if servers SHOULD NOT negotiate h2 via ALPN over anything
below TLS 1.3
starting a year after TLS 1.3 reaches a particular status?   This would
presumably need
to be an expectation set now, followed by an action by UTA or similar in a
year or so from now?
This unfortunately still leaves the onus on the server-side since the
client-side doesn't
have a way to specify the allowed protocol versions in the ALPN message.

What would be the impact on HTTP/2 client implementers if they knew that
clients would start falling back to HTTP/1.1 if they didn't incorporate TLS
1.3
support within some time window after it was available?

Another option might be to add an ALPN token for h2-requiring-tls-1.3
that would be added in by client implementations when they add TLS/1.3
support
with h2-15 or whatever it is being dropped at some point subsequently?

I'd like to see us move in the right direction, but I agree with Yoav and
others
that it would be unfortunate to introduce interop issues that result in
connection
failures.  The ordering of HTTP/2 and TLS 1.3 is backwards from an ideal
world
for this, but it seems like it might be better to try and aim for something
that gets
us into a good state 18 months out from now if it means reduced complexity
in both the short-term and the long-term.  The cost seems to be that the
initial
HTTP/2 implementations may start falling back if not updated within some
time period.

     Erik

On Tue, Oct 28, 2014 at 1:07 PM, Mark Nottingham <[email-masked]> wrote:

> I’ve asked the TLS WG chairs of their estimate of when 1.3 will LC, and
> the answer was that they’re hoping to WGLC around Dallas, but that may be
> “too aggressive.”
>

---

From: Jason Greene <[email-masked]>
Date: Tue, 28 Oct 2014 13:47:57 -0500

> 
> On Oct 28, 2014, at 1:03 PM, Erik Nygren <[email-masked]> wrote:
> The ordering of HTTP/2 and TLS 1.3 is backwards from an ideal world
> for this, but it seems like it might be better to try and aim for something that gets
> in both the short-term and the long-term.  The cost seems to be that the initial
> HTTP/2 implementations may start falling back if not updated within some time period.

What about the question of scope with 1.3 that Dave asked? If you limit 1.3 to just ciphers
and negotiation (e.g. fallback scsv etc), does that potentially improve the schedule? I suppose the challenge is the required interop events and implementation.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Jason Greene <[email-masked]>
Date: Tue, 28 Oct 2014 13:58:00 -0500

> that would be added in by client implementations when they add TLS/1.3 support

I don’t think that would be necessary. A TLS 1.3 client is supposed to request 
the most recent version, and the server is likewise required to support the
most recent version requested that it has the ability to do so.

---

From: Erik Nygren <[email-masked]>
Date: Tue, 28 Oct 2014 15:32:26 -0400

> most recent version requested that it has the ability to do so.

I think where you end up is:

   client_hello:  {  min_vers="TLS-1.0", max_vers="TLS-1.3", alpn=("h2")  }

which means that a server only supporting TLS-1.2 will end up negotiating
TLS-1.2 plus alpn=h2
and the client has no way to prevent or express this in the client_hello
with a single alpn token.

    Erik

---

From: Dave Garrett <[email-masked]>
Date: Tue, 28 Oct 2014 20:11:14 +0000

One possible route is to do the following:

1) Re-version all current TLS 1.3 work as TLS 1.4
2) Write a new TLS 1.3 draft that is JUST TLS 1.2 with HTTP/2 section 9.2.2 applied
3) Make this new minimal TLS 1.3 mandatory for HTTP/2 over TLS

This effectively means bumping all on-the-wire changes for the current TLS 1.3 draft to 1.4 and making 1.3 simply be 1.2 without non-AEAD ciphers or compression. (renegotiation would still be a question, though) Just throw in a MTI cipher or two and publish it. As there would be nothing fundamentally new to test, just spec removal, the path to implementation, testing, and standardization would be far simpler.

HTTP/2 doesn't need ideal TLS now; it merely needs competent TLS. All 9.2.2 was attempting was to formalize the best current practices and keep old known bad policy from spilling over into the new. Simply publishing it via the correct route is all that's really needed to move forward with it. TLS 1.4 can be released when it's ready.

HTTP/1.1 and other applications would also have easy access to a simplified TLS 1.3 standard, as well. Sure, it wouldn't actually give anything new, but it would guarantee nothing particularly old and bad. It's a useful incremental improvement, and one that would hopefully have better adoption rates.

-- Dave