Subject: Re: Stricter TLS Usage in HTTP/2

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Jun 2014 15:17:11 -0700

On 22 May 2014 12:58, William Chan (陈智昌) <[email-masked]> wrote:

> agl@ thought it'd be nice if we could change the spec to reflect
> Chromium's stricter stance here (
> https://codereview.chromium.org/291093002/#msg14). Is this controversial?
> Can we change the spec's guidance here to be more strict?
>

I've opened https://github.com/http2/http2-spec/issues/491 to track this.
The feedback I've gotten from Mozilla folks is that this would be
acceptable to them, though unilateral action from Chrome is not.

The suites we most need to talk about are those that include RC4, 3DES and
AES CBC modes.

Looking at the registry we could simply decide to forbid anything but AEAD
modes, which excludes the suites that use the following constructs: NULL,
RC2, DES, IDEA, DES40, SEED, MD5 (which is used with RC4), and some ARIA
and CAMELLIA modes.  I suspect that the loss of many of these will not be
too hard on folks.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Jun 2014 07:05:33 +0300

On Jun 4, 2014, at 1:17 AM, Martin Thomson <[email-masked]> wrote:

> agl@ thought it'd be nice if we could change the spec to reflect Chromium's stricter stance here (https://codereview.chromium.org/291093002/#msg14). Is this controversial? Can we change the spec's guidance here to be more strict?
> 
> I've opened https://github.com/http2/http2-spec/issues/491 to track this.  The feedback I've gotten from Mozilla folks is that this would be acceptable to them, though unilateral action from Chrome is not.

I don’t understand the objection. Chrome, as a TLS client, can propose any list of ciphersuites that is acceptable to its developers. Just as IE unilaterally disabled RC4, and pretty much all browsers have disabled RC2 at some point (each doing this unilaterally), why is it unacceptable for Chrome to do this now for the non-AEAD version of AES-CBC? (yes, there’s an AEAD version [1], although no TLS ciphersuites are defined)

As for the proposal itself, the HTTP version is negotiated in the same ClientHello as the list of supported ciphersuites. Making the chosen ciphersuite depend on the version of HTTP selected introduces some new logic to TLS. I don’t think this should be added to the HTTP spec.

Yoav

[1] http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2

---

From: Patrick McManus <[email-masked]>
Date: Wed, 4 Jun 2014 08:24:20 -0400

On Wed, Jun 4, 2014 at 12:05 AM, Yoav Nir <[email-masked]> wrote:

> As for the proposal itself, the HTTP version is negotiated in the same
> ClientHello as the list of supported ciphersuites. Making the chosen
> ciphersuite depend on the version of HTTP selected introduces some new
> logic to TLS. I don’t think this should be added to the HTTP spec.

making the chosen ciphersuite depend on the version of HTTP selected is
already a requirement of HTTP2. The proposal here is about a change to that
criteria. Section 9.2

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Wed, 4 Jun 2014 15:42:58 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrick McManus
 > making the chosen ciphersuite depend on the version of HTTP selected is already a requirement of HTTP2. The proposal here is about a change to that criteria. Section 9.2

Do we want to revisit that? Personally, I feel that mandating stronger cipher suites makes a lot of sense but there're a couple of caveats:
- I'm not sure how this plays with opportunistic TLS
- I think we need to be stronger on the use of ALPN. Maybe "Implementations of HTTP/2 MUST support ALPN on all TLS connections" under 9.2? There's a server requirement under 3.4 but unless I'm mistaken no hard requirement on the client.
- I'd like to hear from someone who deals with offloaded or off-box decryption of TLS as to how this will play out for them.

Richard

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jun 2014 08:49:06 -0700

> I don’t understand the objection. Chrome, as a TLS client, can propose
any list of ciphersuites that is acceptable to its developers. Just as IE
unilaterally disabled RC4, and pretty much all browsers have disabled RC2
at some point (each doing this unilaterally), why is it unacceptable for
Chrome to do this now for the non-AEAD version of AES-CBC? (yes, there’s an
AEAD version [1], although no TLS ciphersuites are defined)

We already have this capability, and it isn't what you describe, quite.

Basically, clients, particularly browsers, will need to offer all the sites
they do today, unless they want to regress performance in a big way (hint:
not going to happen). So the ClientHello contains lots of suites we don't
like, sometimes even RC4. Though Microsoft have made the courageous choice
to allow a regression there to reduce the likelihood that RC4 is used, good
for them.

The ClientHello will include http/1.1 and h2. But we are saying that you
can't select h2 unless you select a "good" suite. Given normal selection
processes in the software I know, as long as both parties have good suites,
those will be chosen.

Now the potential change here to software is in servers who might like to
follow the "SHOULD" in the draft and fall the handshake. NSS can do that,
but I recognize that not all software is created equal, so the draft
permits the handshake to complete. Clients have to do that check anyway.
The HTTP/2 implementation need only add a little code like what Will
shared, and it's good.

The problem with that is that if any implementation hard fails a connection
because of a suite the spec permits, they effectively create an alternative
de facto spec. One that isn't documented. Their peers would have to know
about this so that they wouldn't cause breakage when they deploy HTTP/2.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 4 Jun 2014 11:52:31 -0400

On Wed, Jun 4, 2014 at 11:42 AM, Richard Wheeldon (rwheeldo) <
[email-masked]> wrote:

> Do we want to revisit that?

perhaps to make it stronger :)

> Personally, I feel that mandating stronger cipher suites makes a lot of
> sense but there're a couple of caveats:

we've implemented both the alt-svc and encryption drafts and enforce the
requirements of 9.2 and have not found this to be a problem.

---

From: Cory Benfield <[email-masked]>
Date: Wed, 4 Jun 2014 17:18:20 +0100

> - I think we need to be stronger on the use of ALPN. Maybe "Implementations of HTTP/2 MUST support ALPN on all TLS connections" under 9.2? There's a server requirement under 3.4 but unless I'm mist…

This is a pain in the neck on platforms relying on OpenSSL. There's
_no_ Python version or package that makes ALPN available at this point
in time. This is in part because OpenSSL only has ALPN support in
beta. It's already the case that Twisted cannot be a conforming HTTP/2
server at the moment, let's not torpedo Python HTTP/2 clients as well.

Is there any reason NPN isn't good enough?

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Wed, 4 Jun 2014 16:34:52 +0000

From: Cory Benfield [mailto:[email-masked]] 
 > This is a pain in the neck on platforms relying on OpenSSL. There's _no_ Python version or package that makes ALPN available at this point in time. This is in part because OpenSSL only has ALPN support in beta. It's already the case that Twisted cannot be a conforming HTTP/2 server at the moment, let's not torpedo Python HTTP/2 clients as well.

 > Is there any reason NPN isn't good enough?

NPN would be fine IMO. Having neither would be a problem. The layering issues get potentially ugly. How would a lib know whether or not to allow a connection?

Richard

---

From: Roland Zink <[email-masked]>
Date: Wed, 04 Jun 2014 18:38:32 +0200

> - I think we need to be stronger on the use of ALPN. Maybe "Implementations of HTTP/2 MUST support ALPN on all TLS connections" under 9.2? There's a server requirement under 3.4 but unless I'm mist…
If the client knows in advance that the next hop does HTTP/2, then does 
it still need to do ALPN?

---

From: Cory Benfield <[email-masked]>
Date: Wed, 4 Jun 2014 17:47:07 +0100

> NPN would be fine IMO. Having neither would be a problem. The layering issues get potentially ugly. How would a lib know whether or not to allow a connection?

Happy to mandate at least one of NPN and ALPN for both servers and
clients. Servers _should_ support both but I see no reason to turn
that into a must.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jun 2014 09:58:43 -0700

> clients. Servers _should_ support both but I see no reason to turn

You have to have one of:
- support ALPN
- support NPN
- support both on client, either on server
- support either on client, both on server

Or you get the problem where peers support different mechanisms and
negotiation fails.

We have chosen the first option. The document didn't say MUST, but it is
still normative this regard.

We do recognize that - for a short while at least - NPN is more accessible
to some. So many people have enabled NPN to facilitate testing of other
parts of the protocol.

---

From: Adam Langley <[email-masked]>
Date: Wed, 4 Jun 2014 10:05:07 -0700

> to some. So many people have enabled NPN to facilitate testing of other

For those using NPN, I still plan on following the previously
announced NPN deprecation[1] for Google which result in NPN
disappearing in ~8 months on Google sites.

[1] https://www.imperialviolet.org/2013/03/20/alpn.html

Cheers

AGL

---

From: Cory Benfield <[email-masked]>
Date: Thu, 5 Jun 2014 08:43:49 +0100

> still normative this regard.

Ah, I didn't spot that in the document. Well that's exceptionally
awkward for me. And let's not beat around the bush, NPN is not just
'more accessible', it's basically 'the only option'. Until OpenSSL
1.0.2 comes out ALPN is unavailable to me (and to many other
implementations). For organisations large enough to be using their own
crypto libraries Even when it does come out it'll be functionally
unavailable to me for several more months, given that I'll have to
plumb support for it through three separate OSS packages all of which
run on their own schedules. (I speak from experience here, having
started adding NPN support to PyOpenSSL in March and still not having
the pull request merged.)

What's the rationale for (effectively) putting the normative MUST on
the technology that is harder to get hold of? Is there a meaningful
security advantage of ALPN over NPN?

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Jun 2014 11:45:24 +0300

Hi Cory.

ALPN has no security advantage over NPN. The reverse can be argued. It is, however simpler and more in line with “the way we do things in TLS”, so the TLS working group selected ALPN over NPN. ALPN will soon be an RFC, whereas NPN won’t.

OpenSSL was very quick to implement NPN, so it’s strange that they are very slow to implement ALPN. I wish I had a better answer than “take it up with them” or “that’s life”. Unfortunately, I don’t.

Yoav

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 5 Jun 2014 12:32:52 +0200 (CEST)

On Thu, 5 Jun 2014, Cory Benfield wrote:

> Ah, I didn't spot that in the document. Well that's exceptionally awkward 
> for me. And let's not beat around the bush, NPN is not just 'more 
> accessible', it's basically 'the only option'. Until OpenSSL 1.0.2 comes out 
> ALPN is unavailable to me (and to many other implementations).

This is not really true. curl supports client-side ALPN (and subsequent http2) 
right now using one of 4 different TLS libraries. Sure, if you want the 
bleeding edge functions to may use a bleeding edge/non-released version during 
development. But there's nothing that prevents you from doing so or from 
working with those TLS libraries to get ALPN into a release version you can 
use. I believe PolarSSL, GnuTLS and NSS already do.

This ("we can't use new TLS features") is the same argument already iterated 
numerous times usually from Java people and I've argued against it before: 
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1716.html

I would reverse the argument and say that if your languauge/environment cannot 
keep up with protocol development then perhaps that says something.

Right now, it is also dead-simple at least for clients to simply use both NPN 
and ALPN (and pretending they're only one method) for the libs that can do it 
and over time when ALPN really takes off drop the NPN parts.

-- 

  / daniel.haxx.se

---

From: Cory Benfield <[email-masked]>
Date: Thu, 5 Jun 2014 11:56:46 +0100

On 5 June 2014 11:32, Daniel Stenberg <[email-masked]> wrote:
> This is not really true. curl supports client-side ALPN (and subsequent
> http2) right now using one of 4 different TLS libraries. Sure, if you want
> the bleeding edge functions to may use a bleeding edge/non-released version
> during development. But there's nothing that prevents you from doing so or
> from working with those TLS libraries to get ALPN into a release version you
> can use. I believe PolarSSL, GnuTLS and NSS already do.

Broadly agreed: I acknowledge that there are open-source TLS
implementations that support ALPN, and I'll be looking at them
closely. However, the notion that there's "nothing that prevents me"
from working with TLS libraries to get ALPN into a release version is
untrue. I am not paid to do open-source HTTP/2 development: I do it on
my own time. I get no commercial or financial support. I also have
other responsibilities, both open-source and personal. This means I
have an extremely limited pool of resource for moving things forward,
especially things that are not under my complete control (like TLS
libraries). Getting ALPN support ends up being a huge time-sink for
me, either as a rewrite of my own code (to use NSS and make installing
it something less than a total pain in the ass) or forcing through
support of ALPN on other platforms (read OpenSSL). Agreed that this is
not the same as "impossible", but it's certainly a long long way from
"easy".

> I would reverse the argument and say that if your languauge/environment
> cannot keep up with protocol development then perhaps that says something.

What it says is "screw those languages and environments, they should
be more popular or get commercial support". The ability to quickly
move to support new features is granted by developer time, and that is
obtained either through popularity or financial support. My
implementation has neither. If your advice is that I should abandon my
implementation then fair enough, but otherwise I'm going to at least
raise an objection to onerous burdens.

I'd like to point out that ALPN and NPN are, as Yoav mentioned, not
security features. I've not complained about using new versions of TLS
or more secure TLS configuration, despite the fact that it has also
caused me difficulty. This is because I am in agreement: more security
is good, and I'm happy to expend my limited time on improving that.
I'm less delighted about being boxed in on features that fundamentally
have nothing to do with security and, as far as I can tell, everything
to do with "this didn't come out of the IETF so it sucks". Why are we
abandoning a protocol with a broad installed base?

I don't expect to prevail on this point: the ALPN decision was made
long ago and it's clear that I'm in a very small minority of people
who are affected. I can also appreciate why supporting both NPN and
ALPN is a long-term undesirable state of affairs. I don't even think I
really disagree with the specification, and I certainly don't think
there's any malice here. I just want to alert the WG to the fact that
this aspect of the spec is inconvenient. Basically I want the WG to
come out and say "Yes, we know it's inconvenient, and no, we don't
care". Then I'll get off my soapbox and shut up.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Jun 2014 16:01:27 +0300

> raise an objection to onerous burdens.

I don’t think any of Java, OpenSSL or Python are lacking in popularity. That they are not updated with things that haven’t made it yet to RFC is more a testament to their huge install base that makes them slower to react, but not actually slow. I would have liked it if OpenSSL to add ALPN if 1.0.0x and 1.0.1x, but that’s their choice, I guess. 

> abandoning a protocol with a broad installed base?

We are abandoning NPN - an experimental extension used for nothing except negotiating SPDY, itself an experimental feature. Hopefully, but the time HTTP/2 is an RFC there will be a non-beta version of OpenSSL with ALPN. Regarding Java, I have no idea.

> care". Then I'll get off my soapbox and shut up.

The spec is currently a draft. Although it’s not likely at this stage, anything in it can change, so all implementations based on it are necessarily experimental, even if they’re put in production.

Yoav

---

From: Jason Greene <[email-masked]>
Date: Thu, 5 Jun 2014 08:58:56 -0500

> We are abandoning NPN - an experimental extension used for nothing except negotiating SPDY, itself an experimental feature. Hopefully, but the time HTTP/2 is an RFC there will be a non-beta version…

I’m on the Java EE EG, and I can tell you that Java EE8 plans to add APIs targeting HTTP/2 and that puts a priority on Java SE8 (the current release) to support everything needed. In the meantime, implementors will just add it themselves. It’s not that complicated IMO.

BTW I agree with the earlier comment that its a bad idea to go with NPN just because the libraries haven’t caught up. It might be slightly painful at first, but its far worse to have the spec tied to a non-ratified extension. 

Finally NPN is just as “inaccessible" as ALPN in Java ATM

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

---

From: Simone Bordet <[email-masked]>
Date: Fri, 6 Jun 2014 08:18:02 +0200

Hi,

> Finally NPN is just as “inaccessible" as ALPN in Java ATM

For the record, there are implementations of both NPN and ALPN in
Java; they do require some special setup because there is no JDK API
to add TLS extensions, but they are there.
ALPN served by Jetty is already working live (using Chrome and SPDY).
I can give pointers if interested.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz