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

On 09/12/13 21:58, Martin Thomson wrote:
> 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.

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.

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

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

IPsec solves that problem extremely elegantly.

Received on Tuesday, 10 December 2013 07:31:39 UTC