Subject: HTTP/2.0 draft, NPN/ALPN, and TLS

From: Chris Burdess <[email-masked]>
Date: Mon, 09 Dec 2013 18:19:42 +0000

I see from the archives that there has already been some discussion on
this subject; I wanted to add my 2 cents and proposal.

Problems with upgrading to HTTP/2.0 using NPN/ALPN:

1. NPN/ALPN is not supported in many development frameworks. Especially
Java doesn't even have it on the roadmap for the next version, it's been
reported as an issue but is currently not even assigned. Python does
have it but only since 3.3. This will harm uptake since it will take a
long time to even start development and even when that's happened, many
deployment environments cannot be upgraded to the latest whizzy
features. The only solution for developers is to create their own entire
TLS libraries and deploy those, which creates fragmentation, and
introduces a high probability of error and security vulnerability.

2. the mechanism for upgrading plaintext HTTP and HTTP over TLS is
assymmetric. This adds unnecessary complexity.

Confidentiality is an important desired property of next generation
Internet protocols. However, I would argue that the correct place to
implement it is in IPsec rather than the TLS layer. This lowers the cost
of all applications, not just HTTP. Eventually (hopefully sooner rather
then later) the carriers will pull their fingers out and actually
implement IPv6, and then IPsec will basically be standard. That's the
future we want to be looking forward to, rather than trying to reinvent
everything at every single level of the stack. When your connection is
secured with IPsec, TLS is redundant and a duplicated waste of effort,
so it should be dropped. This means that the primary focus should be on
the "plaintext" HTTP protocol.

Obviously that isn't going to happen overnight, however it may well
happen before there is widespread deployed support for the current
NPN/ALPN proposal. In the meantime we want a confidentialy solution that
works. I propose that there be a standard STARTTLS-like HTTP Upgrade
mechanism that can convert the plaintext HTTP connection (on port 80)
not only to HTTP/2.0 but also start TLS. This allows one port to
negotiate everything and makes running servers on separate ports
especially for TLS redundant. When this has happened, operators can
decide to remove TLS completely from the equation as it becomes
redundant itself in the wake of IPsec. No need for a multitude of
special magic port numbers especially for TLS versions of existing
protocols. There is no more HTTPS, just HTTP.

The Upgrade mechanism should be able to be implemented using existing
widely deployed languages and frameworks.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 09 Dec 2013 13:33:45 -0500

Chris,

On Dec 9, 2013, at 1:19 PM, Chris Burdess <[email-masked]> wrote:
> ...
> not only to HTTP/2.0 but also start TLS.

RFC 2817 defines how to upgrade a plaintext HTTP connection to TLS. Conceptually it could be combined with the plaintext HTTP/2.0 upgrade defined in the current draft - we'd just need to define the order of things when multiple upgrades are specified (i.e. TLS first, then the HTTP/2.0 startup sequence...)

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Chris Burdess <[email-masked]>
Date: Mon, 09 Dec 2013 21:48:49 +0000

> RFC 2817 defines how to upgrade a plaintext HTTP connection to TLS. Conceptually it could be combined with the plaintext HTTP/2.0 upgrade defined in the current draft - we'd just need to define the…

Thanks for the pointer. Are there serious objections to using the
Upgrade mechanism to initiate TLS as well as HTTP/2.0, or is it just a
case of "well, we could save like 12 bytes by putting it into the TLS
handshake"? If the latter, then surely the disadvantages outweigh the
advantages considerably.

Apart from anything else RFC 2817 reiterates that duplicate TLS-only
ports were a bad design idea and should be deprecated - 16 years ago.
Now we actually have an opportunity to do something about this. We
should take that opportunity.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 13:58:52 -0800

> handshake"? If the latter, then surely the disadvantages outweigh the

There are several fairly significant drawbacks to requiring the use of Upgrade.

 - For it to be possible, we'd need to mandate support.  StartTLS
support isn't a huge implementation burden on its own, but the
feedback we've had from server implementers is that there are
non-trivial performance and code complexity drawbacks from this.

 - Doing TLS negotiation at the same time as protocol negotiation
(what ALPN and NPN effectively do) saves a round trip.  I can't
understate how important this is to an important constituency of the
community.

 - Upgrade has proven deployment issues.  The WebSocket upgrade is not
particularly successful in the wild.

> should take that opportunity.

To be fair, that's very old advice.  The modern way of doing things is
to avoid providing the unsecured option in the first place.  That ship
sailed with HTTP, so we're still struggling with how to find a path
forward.

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 9 Dec 2013 23:05:38 +0100 (CET)

On Mon, 9 Dec 2013, Chris Burdess wrote:

> 1. NPN/ALPN is not supported in many development frameworks. Especially Java 
> doesn't even have it on the roadmap for the next version, it's been reported 
> as an issue but is currently not even assigned. Python does have it but only 
> since 3.3. This will harm uptake since it will take a long time to even 
> start development and even when that's happened, many deployment 
> environments cannot be upgraded to the latest whizzy features.

This argument has been mentioned over and over again and it is doesn't get 
better even when repeated. Nobody is forced to use inferior software or 
products, nobody is preventing anyone from contributing to open source 
products.

Let's have rough consensus and running code guide us. If that means leaving 
some sub-groups behind for a while, then so be it. They'll adapt in one way or 
another.

I don't believe in standards adapted for the lowest common denomimator. And I 
hate to even start thinking where that might be...

> The only solution for developers is to create their own entire TLS libraries

There's only like 8 or something quite capble existing open source TLS 
libraries already that will accept your contributions today. And another bunch 
of commercial ones you can probably pay to get things done for. But sure, you 
can also create yet another lib if that's your game.

> it [ipsec + ipv6] may well happen before there is widespread deployed 
> support for the current NPN/ALPN proposal.

I would claim that browsers and others so far have shown that in the 
application layer things move MUCH faster than in lower layers when it comes 
to development and adaption on the wider internet. Compare SPDY vs SCTP. 
Compare TLS 1.2 support vs how ipsec or ipv6 are rolling out.

Yes there are challenges involved in relying on new TLS features. But if those 
features greatly help us, I think they should be properly explored and not 
dismissed only because not everyone has kept up with development.

-- 

  / daniel.haxx.se

---

From: Chris Burdess <[email-masked]>
Date: Tue, 10 Dec 2013 07:31:12 +0000

> understate how important this is to an important constituency of the

But, as I said before, the place that we want to end up is with the
confidentiality (and authentication) layer being provided by IPsec, and
TLS deprecated. So saying that the optimal solution is dependent on a
technology that we want to deprecate in the medium term is not ideal.

The performance and code complexity issues that have been reported: do
these apply to switching protocols across the board? or merely to
starting TLS? Because if they apply to Upgrade as a whole then we need
to start looking for a better solution for plaintext, since that's the
long term future of the entire protocol. I reiterate - whatever the
proposal for HTTP/2 now, it needs to consider IPsec.

> particularly successful in the wild.

Arguably this is because of the lack of real world use cases that can be
solved considerably more easily and efficiently by using WebSockets in
comparison to plain old XMLHttpRequest, rather than anything
particularly difficult to implement about Upgrade.

> sailed with HTTP, so we're still struggling with how to find a path

IPsec solves that problem extremely elegantly.

---

From: Chris Burdess <[email-masked]>
Date: Tue, 10 Dec 2013 07:58:06 +0000

On 09/12/13 22:05, Daniel Stenberg wrote:
> ... Nobody is forced to use inferior software
> or products

In the real world, most people are forced to work with whatever they're
told to.

> Let's have rough consensus and running code guide us. If that means
> leaving some sub-groups behind for a while, then so be it. They'll adapt
> in one way or another.

I'm a fan of prototyping as much as anyone else, but that doesn't mean
you should ship the first prototype you make that works. The sub-groups
that you leave behind will create horrible hacks in order to adapt.
These horrible hacks will plague their communities and be exploited
ruthlessly by black hats. You can prevent that happening through design.

> application layer things move MUCH faster than in lower layers when it
> comes to development and adaption on the wider internet. Compare SPDY vs
> SCTP. Compare TLS 1.2 support vs how ipsec or ipv6 are rolling out.

SPDY deployment is basically 100% Google. The only reason it has had the
traction it currently has is because Google controls both the server and
Chrome. Although Firefox now has some support there are basically no
non-Google SPDY servers outside of single organizations with specific
requirements like Facebook.

TLS/1.2 is not a huge success story either. The vast majority (>90%) of
TLS traffic uses TLS/1.0 because it "just works". Even SSLv3 has more
traction than TLS/1.1 or TLS/1.2. For instance:

  http://www.ietf.org/mail-archive/web/tls/current/msg10599.html

Arguably even IPv6 rollout is going faster than that. And the thing is
that IPv6 is already there and has been for years at the endpoints. All
it really needs is for the carriers to pull the switch and connect them
up, which can happen a lot more quickly than developing and deploying
new application software.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 10 Dec 2013 08:01:37 -0500

On Tue, Dec 10, 2013 at 2:58 AM, Chris Burdess <[email-masked]> wrote:

> SPDY deployment is basically 100% Google.

 that's not right.

. spdy is in (listed in order of appearance) chrome, firefox, opera, and
ie. Its supported on the server side at google, twitter, facebook,
wordpress, in nginx, as an apache module, and by at least one cdn. Its in
F5 Big IP and (I think) the citrix load balancer product too. sdpy has been
shown to work and the engineers who have done that work have gotten
together in this forum to create an open specification for it.

I think an ipsec multiplexed web browser would be awesome - I encourage you
to go build one, measure it, find as many other people interested in
standardization and bring the results here. I'd be very interested in that
work.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 10:21:57 -0500

Martin,

> non-trivial performance and code complexity drawbacks from this.

I've never understood this.  CUPS has implemented HTTP Upgrade as long as it has supported HTTPS, and then most of the "complexity" is on the client (get a 426, send an OPTIONS request to upgrade and then re-send the original request).

> understate how important this is to an important constituency of the

I think Chris's question was: why can't we do TLS Upgrade and HTTP/2.0 Upgrade at the same time using the HTTP Upgrade header?

> particularly successful in the wild.

Yes, proxies have been problematic.  I am getting a testbed setup to determine if there are ways we can make HTTP/2.0 upgrade (and thus TLS upgrade) more reliable in the face of proxies, but to paraphrase some of the feedback I've seen when people complain that NPN/ALPN is not widely supported, we shouldn't try to develop for the lowest common denominator of proxy.

> sailed with HTTP, so we're still struggling with how to find a path

Using TLS does not automatically make a protocol secure.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2013 10:11:11 -0800

On 9 December 2013 23:31, Chris Burdess <[email-masked]> wrote:
> TLS deprecated.

I'm not sure that this premise has been agreed.

---

From: Chris Burdess <[email-masked]>
Date: Wed, 11 Dec 2013 11:23:35 +0000

> I'm not sure that this premise has been agreed.

If you don't agree with this, I can think of only 3 reasons:

1. you think that the application layer is better than the transport
layer to secure the connection
2. you think that the connection should be secured both at the transport
layer and at the application layer (double encryption)
3. you think that the connection should not be secured at all

I don't believe that you think 3, since you have argued in favour of TLS.

Regarding 2, this is redundant, requires considerably more effort, and
I'm not sure exactly what you might think the benefits are.

Regarding 1, we could weigh up the benefits of each side:

Pro transport layer:
- all application layer protocols benefit without having to design in
anything special for them (transparency)
- can secure UDP as well as TCP connections
- IPsec can secure more of the packet envelope than TLS or any other
application level system
- doesn't require PKI (which can be a vulnerable point)

Pro application layer:
- TLS is better known
- TLS supports NAT traversal at the protocol layer (maybe not really an
issue with IPv6)
- ISPs might charge more to support IPsec since it is seen as a B2B feature
- can do user-level (as opposed to endpoint-level) authentication,
although typically this is done within the particular application
protocol as well

Perhaps there are other salient issues not listed here. On balance of
the above, to me it looks like the transport layer is a head ahead.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 11 Dec 2013 14:08:07 +0200

Hi Chris.

> anything special for them (transparency)
Transparency works both ways. IPsec has no APIs, partially because it is part of the transport layer, but mostly because it isn't necessarily happening on the same box as the endpoint. Without APIs, the client cannot communicate the server identity to the security layer, so IKE has no way of validating if the credential is valid for what the client is trying to do.  So if the user types "www.example.com", but the certificate has "CN=hackerzRus.net". How is the IKE implementation to know. Similarly, how can the browser know that IPsec was successful and what algorithms are used?
> - doesn't require PKI (which can be a vulnerable point)
Not nearly as vulnerable as providing pair-wise shared keys to hosts or gateways. TLS also supports PSK ciphersuites. The reason PKI is deployed rather than PSK, is that having a PSK for each host you might visit is not practical. So if you want IPsec to scale to what TLS does today, you'll need PKI there as well.
> - TLS is better known
IPsec and TLS are roughly the same age, and both have seen a lot of deployment. It's true that IPsec has not been used by consumers.
> - TLS supports NAT traversal at the protocol layer (maybe not really an
So does IPsec.
> - ISPs might charge more to support IPsec since it is seen as a B2B feature
You can do IPsec on your own CPE or on your own machines, same as TLS.
> although typically this is done within the particular application
So can IKE, at least since v2 (2006).
> the above, to me it looks like the transport layer is a head ahead.

IPsec (or more correctly - IKE) requires mutual authentication. This means distributing credentials to all users. TLS's server authentication is what makes it deploy-able in a way that IPsec has never been.
Yoav

---

From: Chris Burdess <[email-masked]>
Date: Wed, 11 Dec 2013 20:49:17 +0000

Hi Yoav,

> IPsec (or more correctly - IKE) requires mutual authentication. This means distributing credentials to all users. TLS's server authentication is what makes it deploy-able in a way that IPsec has ne…

Thanks very much for this, plenty of stuff to think about.