Re: HTTPS 2.0 without TLS extension?

It is difficult to support-- proxies sometimes mess with the bytes on port
80, and debugging the problem when this occurs is impractical. Plus, it
encourage an inspection of the data flowing by, which, even if not done for
nefarious purposes, might ossify things. With encryption (and ALPN/NPN)
comes the ability to rev the protocol or deploy new protocols easily.
History and experience have demonstrated this..

Negotiating upgrade in a LAN/VPN setting is interesting, however, because
this problem is far more manageable in that environment.

-=R
On Jul 26, 2013 2:33 PM, "Zhong Yu" <zhong.j.yu@gmail.com> wrote:

> On Fri, Jul 26, 2013 at 3:03 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> >
> > On Jul 26, 2013, at 3:21 AM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
> >
> >> On Tue, Jul 23, 2013 at 5:34 PM, Martin Thomson
> >> <martin.thomson@gmail.com> wrote:
> >>> On 23 July 2013 11:57, William Chan (陈智昌) <willchan@chromium.org>
> 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:)
> >
> > It would only be a chicken and egg situation if Java ruled the world.
>
> I didn't mean Java rules the world; it's the only platform I'm
> personally familiar with therefore I was giving some feedback from
> Java's perspective.
>
> > The TLS working group will publish ALPN as an RFC. Soon after, there
> will be updates of OpenSSL, SChannel (or whatever Microsoft calls it these
> days), and NSS. By then, it would be quite a lot of chicken to lay a java
> egg and carry metaphors way further than they should be.
> >
> >> 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.
> >
> > Will those earlier versions of Java support HTTP/2 ?
> >
> >> Obviously Java will have to support ALPN when HTTP2 and ALPN gains a
> >> strong foothold.
> >
> > I don't see much need for ALPN before HTTP/2 is ready, but we might see
> implementations of the draft in months. And those implementations will come
> with ALPN.
> >
> >> 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.
> >
> > Nobody is forcing anyone to support upgrade. Some people from Google
> said they have no interest in HTTP/2 in the clear, so they could have
> servers that don't support Upgrade.
>
> So if a client is talking to google on an ordinary https 1.1
> connection, then decides to upgrade to 2.0, google will refuse to do
> that? What would be the reason?
>
> >
> > Like you, I think HTTP/2 should not depend on the upgrade mechanisms,
> and that if a connection (with or without TLS) begins with the magic
> header, it should be treated as HTTP/2 even if there was neither Upgrade
> nor ALPN, and that any implementation that has Upgrade in the clear, should
> have Upgrade in TLS. I just don't buy the Java argument.
>
>