Subject: HTTPS 2.0 without TLS extension?

From: Zhong Yu <[email-masked]>
Date: Mon, 22 Jul 2013 07:06:02 -0500

The draft mandates TLS extension ALPN for any https 2.0 connections,
but why is that necessary? Why can't we also establish an https 2.0
connection through the Upgrade mechanism, without ALPN? TLS extension
may not be available/convenient on some platforms for some time;
requiring it may discourage some potential implementers.

Zhong Yu

---

From: Mike Belshe <[email-masked]>
Date: Mon, 22 Jul 2013 09:01:38 -0700

It should be available quite easily through OpenSSL and NSS long before
http/2 ships.

The structured integration with the SSL handshake is a much cleaner
protocol.

Mike

---

From: Zhong Yu <[email-masked]>
Date: Mon, 22 Jul 2013 11:47:48 -0500

Suppose a TLS connection is established without ALPN. Then an HTTP/1.1
request is sent over with Upgrade: HTTP/2.0. How should the server
respond?

1. drop the connection
2. respond with a 400 error
3. ignore Upgrade header, treat it as a normal request
4. upgrade the connection to 2.0

The simplest and the most sensible thing to do seems to be #4. If
that's the case, it means most servers would not enforce the
requirement of ALPN. This may start an evolution path that under the
pressure of interoperability eventually all implementations treat ALPN
as optional.

Though "Upgrade" mechanism is less ideal than ALPN, since the server
must support it anyway on TCP connections, I don't see why we should
forbid it on TLS connections.

Zhong Yu

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 22 Jul 2013 22:24:13 +0300

> request is sent over with Upgrade: HTTP/2.0. How should the server
<snip>

There's also second abnormal case:
TLS handshake without ALPN, but the application data starts with
HTTP/2.0 magic...

> forbid it on TLS connections.

What about servers that are not willing to implement upgrade (it is fair
amount of complexity)?

I.e. is there path to totally obsolete HTTP/1.1 in the far future?

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Jul 2013 19:44:31 +0000

On Jul 22, 2013, at 10:24 PM, Ilari Liusvaara <[email-masked]> wrote:

> HTTP/2.0 magic…

I'm guessing that if either the TLS application data or the TCP connection in HTTP starts with the magic, it's HTTP/2.0.  Otherwise, why would we need the magic^H^H^H^HConnection Header?

> What about servers that are not willing to implement upgrade (it is fair

They'd have to stick to HTTP/1 for now, because no sane client start off with HTTP/2 for now.

> I.e. is there path to totally obsolete HTTP/1.1 in the far future?

Not by having servers or client that refuse to negotiate the version. It's also possible that by the time we can assume that we don't need HTTP/1 any more, we may have to contend with HTTP/3. 

Yoav

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 23 Jul 2013 15:18:08 +1200

On 23/07/2013 4:01 a.m., Mike Belshe wrote:
> It should be available quite easily through OpenSSL and NSS long 
> before http/2 ships.
>

Sigh. Missed the news yesterday? come relatively large number of 
corporates are still using Java installations installed since 1994.

We are expecting HTTP/2 to start "shipping" preliminary implementations 
in the next year or two right? You can expect a minimum 5 years upgrade 
window (sorry terrible pun) if the libraries are ready and published 
*today*. Depending on the library like this just won't cut enough slack.

> The structured integration with the SSL handshake is a much cleaner 

Sure, and the sane people will use it. Not everybody is sane though.

Eliminating viable options for moving to HTTP/2 does not seem like a 
reasonable path to be taking this early in the process.

Amos

---

From: David Morris <[email-masked]>
Date: Tue, 23 Jul 2013 07:25:40 -0700 (PDT)

On Tue, 23 Jul 2013, Amos Jeffries wrote:

> Sigh. Missed the news yesterday? come relatively large number of corporates
> are still using Java installations installed since 1994.

While I agree with your concern, Java was released in 1995 so it is
unlikely there are many, if any, Java installations from 1994.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 23 Jul 2013 10:34:29 -0700

FWIW, it seems reasonable to me to have the spec allow HTTPS 2.0 without
TLS extension. If you want to Upgrade, be my guest. I have no plans for my
browser to support that, and I don't think Google servers will support it
either, because we care strongly about the advantages of TLS-ALPN vs
Upgrade.

IIRC, Twitter doesn't use NPN for the same reasons (lack of TLS extension
support on certain mobile clients). I believe they don't care about public
interop though, they just use dedicated VIPs with clients they control.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Jul 2013 17:52:05 +0000

On Jul 23, 2013, at 8:34 PM, William Chan (陈智昌) <[email-masked]> wrote:

> FWIW, it seems reasonable to me to have the spec allow HTTPS 2.0 without TLS extension. If you want to Upgrade, be my guest. I have no plans for my browser to support that, and I don't think Google servers will support it either, because we care strongly about the advantages of TLS-ALPN vs Upgrade.
> 

What about a regular TLS handshake (without the ALPN extension) followed by the HTTP/2 magic?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jul 2013 10:57:05 -0700

> What about a regular TLS handshake (without the ALPN extension) followed by the HTTP/2 magic?

Probably not a good idea on the web generally, unless you have a
really good hint that the server is OK with that.

---

From: Zhong Yu <[email-masked]>
Date: Tue, 23 Jul 2013 13:46:44 -0500

I agree TLS-ALPN is much better than TLS-Upgrade, but it'll take the
rest of the world some time to get there. Allowing TLS-Upgrade
meanwhile probably will not lessen the motivation to deploy ALPN,
since it's in the best interest of all clients and servers to reduce a
round trip.

*If* the spec allows TLS-Upgrade, some servers will use it before they
can do ALPN, and some clients will support it. Chrome will face the
heat - a competitor browser can talk to a server in HTTPS/2.0 with
Upgrade, yet Chrome can only talk to it in HTTPS/1.1.  Will Chrome
stick to its principle and refuse to speak with the vulgar Upgrade? I
bet a lunch that it will budge.

Therefore if the spec allows TLS-Upgrade, it might as well mandate it.

The other option is to absolutely forbid TLS-Upgrade and disown any
implementation that does it, deliberately or accidentally (the latter
being more likely).

Zhong Yu

On Tue, Jul 23, 2013 at 12:34 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> FWIW, it seems reasonable to me to have the spec allow HTTPS 2.0 without TLS
> extension. If you want to Upgrade, be my guest. I have no plans for my

---

From: Zhong Yu <[email-masked]>
Date: Tue, 23 Jul 2013 13:50:01 -0500

> Therefore if the spec allows TLS-Upgrade, it might as well mandate it.

I mean, "it might as well mandate all compliant implementations to
support the Upgrade mechanism on a TLS connection"

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 23 Jul 2013 11:57:20 -0700

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.

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 23 Jul 2013 14:29:26 -0700

On Tue, Jul 23, 2013 at 11:46 AM, Zhong Yu <[email-masked]> wrote:

> rest of the world some time to get there.

​It's going to take the rest of the world some time to deploy HTTP/2, as
well.  Do you think that ALPN will be harder to deploy than HTTP/2?

> Allowing TLS-Upgrade
> TLS

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Jul 2013 15:34:04 -0700

On 23 July 2013 11:57, William Chan (陈智昌) <[email-masked]> wrote:
> 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'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.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 24 Jul 2013 21:34:25 +1200

On 24/07/2013 9:29 a.m., Ryan Hamilton wrote:
> On Tue, Jul 23, 2013 at 11:46 AM, Zhong Yu <[email-masked] 
> <mailto:[email-masked]>>wrote:
>
> ​It's going to take the rest of the world some time to deploy HTTP/2, 
> as well.  Do you think that ALPN will be harder to deploy than HTTP/2?
>

Red herring argument.  If ALPN is the mandatory requirement of HTTP/2 it 
cannot be harder. They will be equal or HTTP/2 will be harder - since it 
includes more than just ALPN.

The issue in question is whether or not ALPN should be mandatory in the 
first place, or if allowing other mechanisms will encourage faster 
HTTP/2 adoption. Whether or not those other mechanisms are slower or 
worse than ALPN - do they encourage or help rollout?

IMHO, this is an issue where we can afford to wait and see. Probably we 
will end up with ALPN as mandatory the others as optional to encourage 
the more efficient method.

Amos

---

From: Zhong Yu <[email-masked]>
Date: Thu, 25 Jul 2013 19:21:32 -0500

> 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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Jul 2013 20:03:50 +0000

> situation here. (Imagine how embarrassing it would be if Java standard

It would only be a chicken and egg situation if Java ruled the world. 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.

> 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

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.

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

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.

---

From: Zhong Yu <[email-masked]>
Date: Fri, 26 Jul 2013 16:30:45 -0500

On Fri, Jul 26, 2013 at 3:03 PM, Yoav Nir <[email-masked]> wrote:
> 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.
>

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?

---

From: Roberto Peon <[email-masked]>
Date: Fri, 26 Jul 2013 14:43:01 -0700

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" <[email-masked]> wrote:

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

---

From: Eliot Lear <[email-masked]>
Date: Sun, 28 Jul 2013 06:46:39 +0200

On 7/23/13 7:34 PM, William Chan (陈智昌) wrote:
> FWIW, it seems reasonable to me to have the spec allow HTTPS 2.0
> without TLS extension. If you want to Upgrade, be my guest. I have no
> plans for my browser to support that, and I don't think Google servers
> will support it either, because we care strongly about the advantages
> of TLS-ALPN vs Upgrade.

Not only that, I don't think we can reasonably call this HTTP 2.0 if we
have no path to do it in the clear.

---

From: Michael Sweet <[email-masked]>
Date: Sun, 28 Jul 2013 08:12:24 -0400

... and don't forgot some of the more obscure usage of HTTP, such as HTTP over USB in the USB-IF's IPP USB Specification:

    http://www.usb.org/developers/devclass_docs

There isn't much point in using TLS over USB (and a lot of cost issues for that class of printer against it), and we need to continue to use the same USB end points/interfaces, so upgrade remains an important feature of HTTP/2.0 for me/Apple...

Sent from my iPad

On 2013-07-28, at 12:46 AM, Eliot Lear <[email-masked]> wrote:

> Not only that, I don't think we can reasonably call this HTTP 2.0 if we have no path to do it in the clear.