Re: HTTPS 2.0 without TLS extension?

[Zhong Yu <[e-mail]>]

On Tue, Jul 23, 2013 at 5:34 PM, Martin Thomson
<[e-mail]> wrote:
> On 23 July 2013 11:57, William Chan (陈智昌) <[e-mail]> wrote:
>> I find your argument for mandating HTTP Upgrade to HTTP/2.0 over TLS
>> uncompelling. If others find it compelling, I would be interested in hearing
>> so.
>
> If we are going to enable variant modes of operation, then the
> justification will need to be quite strong.  I don't believe that
> there are many up-sides to this particular mode of operation that
> would argue for its inclusion.
>
> If all this comes down to is an inability to talk ALPN, maybe someone
> can help us understand the situation that makes it difficult to deploy
> that (I can imagine a few cases where this might be the case, but it
> would be better to get to concrete cases).

I sent some questions to Java SSL people and got a response:

http://mail.openjdk.java.net/pipermail/security-dev/2013-July/008236.html
http://mail.openjdk.java.net/pipermail/security-dev/2013-July/008271.html

My take is that Java will not add official support of ALPN before ALPN
becomes a stable and well accepted standard. So it's a chicken and egg
situation here. (Imagine how embarrassing it would be if Java standard
API supports NPN:)

Since the support of ALPN requires API change, Java is unlikely to
back port the support to earlier versions of Java, which a lot of
deployments will be stuck on for some time.

Obviously Java will have to support ALPN when HTTP2 and ALPN gains a
strong foothold.

So I think the best thing to do in the meantime is to make ALPN
optional; clients and servers should support TLS+Upgrade (which is
trivial, suppose Upgrade must be supported anyway on plain TCP) for
the time being. This will help HTTP/2.0 to be adopted earlier,
consequently it'll push Java to support ALPN sooner.

Zhong Yu

>
> I'll note that TLS + HTTP Upgrade is not the only option on the table
> for people who find themselves wanting HTTP/2.0 but unable to deploy
> ALPN.