Re: HTTPS 2.0 without TLS extension?

Zhong Yu <> Fri, 26 July 2013 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E04A511E8165 for <>; Fri, 26 Jul 2013 14:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.824
X-Spam-Status: No, score=-9.824 tagged_above=-999 required=5 tests=[AWL=0.175, 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 Euc-QJSP2prd for <>; Fri, 26 Jul 2013 14:32:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E7C4011E8163 for <>; Fri, 26 Jul 2013 14:32:46 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1V2pbd-0006H4-39 for; Fri, 26 Jul 2013 21:31:21 +0000
Resent-Date: Fri, 26 Jul 2013 21:31:21 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1V2pbU-0006DT-RQ for; Fri, 26 Jul 2013 21:31:12 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1V2pbT-0004O7-Qo for; Fri, 26 Jul 2013 21:31:12 +0000
Received: by with SMTP id vb8so419682obc.1 for <>; Fri, 26 Jul 2013 14:30:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=j8g1fY/DGuPjpj/OfQXOIJP/qt1av86QwCK9uIJ4QA0=; b=ADrUWu07f7PmjM5YLdeFeQ61nWnIWLVyUpL6SOqLTVYoJ6BZS4NMBLBwCpJeZq3DcN osGpgLY5tTJntdqCtK0lZJtu+Yz64kU1xYESFfEv6ly1CylUiHMtWEfx6uuqP6BLYeGT Tiu5FcXg78JpqG8NFWa4jKDorMJX3hi4mdWOogTuFyXZo+EF1SW/EdGxe0nkBmUrX5G/ jJ6FPhl9P99m0YpMVYpisSekd9ejKvjoUvcM/8VmKYu3J64axnuGeQtP0FRj8d2UllS5 dGTbrYeLgEi6MUnfAqLhC2tX0wThqCCFxSstbJNUgXpRl8RmryHgNw80sGGWj3KATdyx BKJQ==
MIME-Version: 1.0
X-Received: by with SMTP id o9mr44351860obr.54.1374874245794; Fri, 26 Jul 2013 14:30:45 -0700 (PDT)
Received: by with HTTP; Fri, 26 Jul 2013 14:30:45 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Fri, 26 Jul 2013 16:30:45 -0500
Message-ID: <>
From: Zhong Yu <>
To: Yoav Nir <>
Cc: Martin Thomson <>, "William Chan (陈智昌)" <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.668, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1V2pbT-0004O7-Qo 88dcddadca5215ab641115d0de88af9a
Subject: Re: HTTPS 2.0 without TLS extension?
Archived-At: <>
X-Mailing-List: <> archive/latest/18932
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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.