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

On 09/12/13 18:33, Michael Sweet wrote:
>> 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.
> 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...)

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.

Received on Monday, 9 December 2013 21:50:13 UTC