Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

It seems that you do not understand the intent of the draft or the  
authors.

The use case here is web filtering as it is used by organizations and  
consumers, in which a consumer or an organization chooses to use a  
service or a product that acts as an HTTP proxy, and configures their  
clients to do so.  It is desirable in such cases to use TLS whenever  
possible, and it is certainly desirable that the client be able to  
authenticate the proxy.  The intent of the authors is to enable TLS to  
be used when an proxy is present, and to make clients informed about  
both the proxy and the server, and to provide cryptographically strong  
authentication of both.  The client should be able to decide if it  
accepts the proxy for a particular session, and the scope of the proxy  
should be limited, and the proxy should not lie to the client.   The  
client should also have the full information about the server on the  
other end of the connection.

We oppose the development of a technology that would help a country  
spy on its citizens, and we certainly oppose the development of  
standards in that area.  The IETF can't control how the technologies  
that it develops are used, or who uses them, of course, which makes it  
imperative to not develop any mechanisms that could be used in that way.

David

On Jul 29, 2011, at 8:35 PM, Marsh Ray wrote:

> On 07/29/2011 05:24 PM, David McGrew wrote:
>>
>> On Jul 29, 2011, at 1:44 PM, Martin Rex wrote:
>>>
>>> I am strongly opposed to have any document describing such proxies
>>> published as an RFC!
>>
>> And yet you would favor a protocol that propagates decryption keys
>> around the network?
>
> I'm with Martin on this one.
>
> If the goal is to allow well-regulated eavesdropping of a TLS  
> protocol stream it would be better done via a mechanism which  
> transfers the minimum necessary secret key material to the  
> authorized party with the consent of both legitimate endpoints.  
> Although I've often wanted such a thing for debugging, I don't like  
> it. But it would be preferable to having middleboxes falsely  
> impersonating the identity of servers.
>
> Just because you can convince a client to accept your trusted root  
> cert it doesn't give you the moral authority to impersonate the  
> identity of a third party or deceive them about the connection's  
> security properties. Otherwise, by that logic, there are hundreds of  
> governments and corporations around the world which would be  
> justified in doing so.
>
>> We don't have a choice about whether or not TLS proxying will be  
>> done on
>> the Internet; it is being done.
>
> Over the internet? Really? The only case I've heard of was Syria  
> using a Blue Coat on their people. I'd assume China has built the  
> capability as well.
>
>> What we can choose is whether or not the
>> IETF improves how it is being done.
>
> But this is not really "TLS proxying" at all since the TLS is  
> actually being stripped off entirely and re-established with a  
> largely independent context.
>
> From a purely technical perspective it sounds as if people want to  
> convert TLS from a "two party plus PKI" protocol into a "three party  
> plus" protocol, without actually defining the implications of all  
> the new trust relationships it brings up.
>
> - Marsh