Re: [TLS] Next protocol negotiation

Yoav Nir <> Thu, 21 January 2010 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58ECB3A6891 for <>; Wed, 20 Jan 2010 22:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sb-4Nlk6NukG for <>; Wed, 20 Jan 2010 22:00:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B75B43A688C for <>; Wed, 20 Jan 2010 22:00:17 -0800 (PST)
X-CheckPoint: {4B57EAFE-10007-14201DC2-FFFF}
Received: by (Postfix, from userid 105) id 6B8B929C005; Thu, 21 Jan 2010 08:00:13 +0200 (IST)
Received: from ( []) by (Postfix) with ESMTP id 44FA329C002; Thu, 21 Jan 2010 08:00:13 +0200 (IST)
X-CheckPoint: {4B57EAFE-10000-14201DC2-FFFF}
Received: from ( []) by (8.12.10+Sun/8.12.10) with ESMTP id o0L60DT7019128; Thu, 21 Jan 2010 08:00:13 +0200 (IST)
Received: from ([]) by ([]) with mapi; Thu, 21 Jan 2010 08:00:27 +0200
From: Yoav Nir <>
To: Adam Langley <>
Date: Thu, 21 Jan 2010 08:00:03 +0200
Thread-Topic: [TLS] Next protocol negotiation
Thread-Index: AcqaXwcPoRmt4qteThiSn+9LJEa4eA==
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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: Thu, 21 Jan 2010 06:00:19 -0000

On Jan 20, 2010, at 6:52 PM, Adam Langley wrote:

> On Wed, Jan 20, 2010 at 8:26 AM, Marsh Ray <> 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.)

Currently, it is, but processing power is cheap and getting cheaper.

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

Actually, I think this will shift the cost/benefit analysis of the SSL-inspecting proxies.  As more applications move to the "all the Internet over port HTTPS" paradigm, the administrators will have more incentive to deploy these proxies. If policy says that all files sent to people in other companies needs to be scanned by the data leakage prevention software, and some application like Skype sends files to your contacts over port 443, then you need something to look into the SSL. So I agree with Marsh - the proxy will become more common with time.

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