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

Martin,

On Dec 9, 2013, at 4:58 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> ...
> - 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.

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).

> - 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.

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?

> - Upgrade has proven deployment issues.  The WebSocket upgrade is not
> 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.

>> 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.
> 
> 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.

Using TLS does not automatically make a protocol secure.

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 10 December 2013 15:22:32 UTC