Re: [TLS] Next protocol negotiation

Marsh Ray <> Wed, 20 January 2010 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA2DB3A6878 for <>; Wed, 20 Jan 2010 08:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ebt2YcKDFH4R for <>; Wed, 20 Jan 2010 08:26:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EA90D3A67D7 for <>; Wed, 20 Jan 2010 08:26:28 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NXdNp-000Ehe-0y; Wed, 20 Jan 2010 16:26:17 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 56ABE631F; Wed, 20 Jan 2010 16:26:15 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX182VroPBrBVpkWV9ZqV8XX+Q/MWa6hL6Bc=
Message-ID: <>
Date: Wed, 20 Jan 2010 10:26:14 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Adam Langley <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Next protocol negotiation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2010 16:26:29 -0000

Adam Langley wrote:
> On Wed, Jan 20, 2010 at 7:39 AM, Nikos Mavrogiannopoulos
> <> wrote:
>> Ok now I see your point. However I still suggest solving issues at the
>> appropriate layer, even that has some performance cost.
> The appropriate layer for protocol disambiguation is TCP.
> Unfortunately, this mechanism has stopped functioning for practical
> purposes and we're aware that we aren't the only group facing this
> problem.

One point of view is that firewall admins are ports because of their
intentional policies and it is their right to control what goes on on
their own network. Port 443 is going to be less useful over time as more
sites deploy SSL-inspecting proxies.

I don't particularly like that point of view, but it does seem to be the
reality. So we have a situation where people desiring to make a new
simple, secure protocol have to smuggle their traffic (even outbound
connections) like some kind of malware.

Once we're honest about what we're doing, other options might be available:

Port 443 to a proxy server with the CONNECT verb usually works.

It is rumored that many firewalls will pass anything over port 53.

On many corporate Windows PCs, the 'proxy server' info available in the
registry is the only reliable way to make outbound connections.

> Burning an additional round trip on protocol discovery is unacceptable
> for us[1]. 200ms is a good round-trip time on a 3G network and the
> nature of web content means that progressive discovery of additional
> resources amplifies this delay.
> Also, consider that without a suitable mechanism, we might be
> condemning future protocols to forever limiting their initial
> handshake to something that is HTTP compatible.

You might also be able to use HTTPS to tunnel to an appropriate proxy.

> We (Google) don't mind
> putting in the work to make more fundamental changes but others,
> perhaps, would choose not to for reasons of expediency, and would pay
> this technical debt forever more.
> [1]

Thank you guys for caring about 200ms of my finite lifetime.

- Marsh