Re: [TLS] Next protocol negotiation

Marsh Ray <> Thu, 21 January 2010 08:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 170153A69BD for <>; Thu, 21 Jan 2010 00:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_74=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5dK1JjtNaNny for <>; Thu, 21 Jan 2010 00:19:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3B74B3A68BE for <>; Thu, 21 Jan 2010 00:19:35 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NXsGE-0004iG-7o; Thu, 21 Jan 2010 08:19:26 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id B0FEA631F; Thu, 21 Jan 2010 08:19:24 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX18brI2kGYSDfNurreMHDRj5/cuaaArY2dA=
Message-ID: <>
Date: Thu, 21 Jan 2010 02:19:22 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Yoav Nir <>
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
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 08:19:36 -0000

Yoav Nir wrote:
> On Jan 20, 2010, at 6:52 PM, Adam Langley wrote:
>> 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 wonder if the 'channel bindings' work will end up throwing a monkey
wrench in this. Will the SSL proxy be required to know all the secrets
of the higher-level protocols in order to terminate the SSL?

>> I admit that by using TLS we are bypassing (preferably) these 
>> middleware boxes.

Who wouldn't want to? Do they provide any value-add to the exchange of
data (legitimate or otherwise)?

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

1. Doesn't this represent to some degree a failure of the basic TCP/UDP
address+port model (or perhaps it is being outgrown)? Maybe packet
headers are just no longer sufficient for making the block vs. route

2. If this is true, what depth of inspection is necessary to provide
security? Is it destined to grow ever deeper? Semantic web indeed!

3. This is a fascinating discussion.

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

So if one wants to define a new protocol and have it routable over the
21st century internet, it needs to either:

1. Appear indistinguishable from innocuous web surfing over HTTP/HTTPS.


2. Explicitly support inspection in its design. It would have to be so
amenable to inspection that firewall vendors recommend that it be
allowed as a more secure alternative to HTTP. This is impossible in the
general case, but it would be possible to support actual data type
checking in the protocol. Something similar to having a list of allowed
XML schemata against which requests and responses are validated.

What do you all think of this?

- Marsh