Re: HTTPS 2.0 without TLS extension?

Yoav Nir <> Fri, 26 July 2013 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9950F11E80FB for <>; Fri, 26 Jul 2013 13:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.261
X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OI8A0YJt7vOi for <>; Fri, 26 Jul 2013 13:06:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FEEB11E813A for <>; Fri, 26 Jul 2013 13:06:02 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1V2oFl-0002L9-Qw for; Fri, 26 Jul 2013 20:04:41 +0000
Resent-Date: Fri, 26 Jul 2013 20:04:41 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1V2oFd-0002K3-EP for; Fri, 26 Jul 2013 20:04:33 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1V2oFX-0001Z1-05 for; Fri, 26 Jul 2013 20:04:33 +0000
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id r6QK3pmZ030033; Fri, 26 Jul 2013 23:03:51 +0300
X-CheckPoint: {51F2D627-11-1B221DC2-1FFFF}
Received: from ([]) by ([]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 22:03:51 +0200
From: Yoav Nir <>
To: Zhong Yu <>
CC: Martin Thomson <>, "William Chan (陈智昌)" <>, HTTP Working Group <>
Thread-Topic: HTTPS 2.0 without TLS extension?
Date: Fri, 26 Jul 2013 20:03:50 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.7
X-W3C-Hub-Spam-Report: AWL=-0.223, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.452, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1V2oFX-0001Z1-05 21f402a5c7c2943ca9a8c5fa0961659e
Subject: Re: HTTPS 2.0 without TLS extension?
Archived-At: <>
X-Mailing-List: <> archive/latest/18931
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Jul 26, 2013, at 3:21 AM, Zhong Yu <> wrote:

> On Tue, Jul 23, 2013 at 5:34 PM, Martin Thomson
> <> wrote:
>> On 23 July 2013 11:57, William Chan (陈智昌) <> 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:
> 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. 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. 

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.