Re: [TLS] Next protocol negotiation

Adam Langley <agl@google.com> Wed, 20 January 2010 16:52 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08823A6837 for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:52:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.31
X-Spam-Level:
X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZtg2Qpzh-lL for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:52:41 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 939383A6823 for <tls@ietf.org>; Wed, 20 Jan 2010 08:52:40 -0800 (PST)
Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id o0KGqZDd015603 for <tls@ietf.org>; Wed, 20 Jan 2010 16:52:35 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264006355; bh=zIu5DvuTawucP0rufBQz2Q7JxMY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bUCkNtSFa3KBcSx2lemhaFT5TIcsPcu3GBAbP3xuXsm5s0xMHOMJRUnObQZGnyffR eAGLPRLnqjdwUHdhJYjmQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=VVL8dNDa/3bFkLFb9I0icpBUj0k+75vAdRXFEjHvpKVqjYVveunTVLLDOCuBwIS3P 94rUkDKangxsvNGwKb7Zg==
Received: from pxi41 (pxi41.prod.google.com [10.243.27.41]) by spaceape24.eur.corp.google.com with ESMTP id o0KGqXLo020889 for <tls@ietf.org>; Wed, 20 Jan 2010 08:52:34 -0800
Received: by pxi41 with SMTP id 41so4097315pxi.27 for <tls@ietf.org>; Wed, 20 Jan 2010 08:52:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.56.9 with SMTP id e9mr156984wfa.62.1264006352867; Wed, 20 Jan 2010 08:52:32 -0800 (PST)
In-Reply-To: <4B572EA6.8040902@extendedsubset.com>
References: <a84d7bc61001200520t4e3be7d4sb0bb614abb0b5e4e@mail.gmail.com> <c331d99a1001200646o55d7d2f6wfaad058b84e6024e@mail.gmail.com> <a84d7bc61001200705v39b37ba3qaea1ca4149afb0a0@mail.gmail.com> <4B5723A5.8050508@gnutls.org> <a84d7bc61001200757p30ffded4y8b0f34b157fa4dc4@mail.gmail.com> <4B572EA6.8040902@extendedsubset.com>
Date: Wed, 20 Jan 2010 08:52:32 -0800
Message-ID: <a84d7bc61001200852p18ca82e4me4214661d7b0be9b@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] Next protocol negotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 16:52:42 -0000

On Wed, Jan 20, 2010 at 8:26 AM, Marsh Ray <marsh@extendedsubset.com> wrote:
> Adam Langley wrote:
> 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.

Organisations that deploy intercepting proxies and port blocking
middleware (etc) have reasonable policy goals that they are trying to
implement. These people, for the most part, are not bad nor evil.

But one cannot expect them to understand the value of the end-to-end
principle. They are evaluating different solutions and balancing cost
and utility, as it effects them. It turns out that many of them end up
choosing networking hardware for caching, virus-scanning, content
control etc.

These network based solutions can be cheap, but they achieve these
cost reductions, in part, by imposing negative externalities on the
rest of the world. It's the case these days that HTTP traffic will
usually be 'transparently' intercepted at least once. DNS traffic is
likewise adulterated, as are many other protocols. Because of this,
protocol advances are delayed or lost. (HTTP pipelining is one
example, there are many others including our own SDCH[1]).
Unfortunately, these losses to the world are non-obvious to many and
hard to measure.

TLS is attractive because it is obviously much more resistant to these
machinations. (I'm aware that such devices do exist to intercept SSL,
but they should hopefully be intrinsically more limited.)

I admit that by using TLS we are bypassing (preferably) these
middleware boxes. Because of this, the cost/benefit analysis of these
boxes will hopefully shift so that people start to look for other
solutions. We know that we'll have to provide alternatives, but these
can be designed so as not to consign the public Internet to slow
stagnation at the bottom of the protocol stack.

[1] http://en.oreilly.com/velocity2008/public/schedule/detail/2598

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

Port 53 is not as clean as one might hope. CONNECT and port 443 often
works, but then we have the same issue as we currently face: how to
disambiguate protocols when the TCP port mechanism is unavailable.
Next protocol negotiation is our proposed solution.

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

You're welcome although, as noted, the actual delay usually ends up
being several multiples for web pages as subresource discovery is
slowed down for other domains.


AGL