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

On 9 December 2013 13:48, Chris Burdess <dog@gnu.org> wrote:
> 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.

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.

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

Received on Monday, 9 December 2013 21:59:20 UTC