Re: [TLS] Next protocol negotiation

[Marsh Ray <[e-mail]>]

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

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.

or

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