Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

Hi Martin,

On Jul 28, 2011, at 11:21 PM, Martin Rex wrote:

> Matt McCutchen wrote:
>>
>>> and that also enables the clients
>>> to clearly limit who is able to read the traffic.
>>
>> Huh?  The proxy's ability to pass decrypted data to someone else is  
>> no
>> different than if it were bridging two TLS connections.
>
> No, that is entirely different.
>
> Revealing the traffic **encryption** keys to the proxy requires  
> cooperation
> of the client, so a sensible client implementation can ask for consent
> and the user may deny consent, whereas a proxy with a super-CA-cert
> can subvert any connection for that client, no matter where that
> client goes--and MitM all connections any time, including those that  
> do
> not traverse that proxy.

It sounds like you misunderstand the proposal.  The approach we are  
going for is one in which the client is fully informed about both the  
proxy and the server, and the client is free to choose to trust them  
or not.

>
>
>>
>>> No super-CA-equivalent
>>> keys would need to be on the malware-scanning Proxy.
>>
>> You speak as if that were in a whole different class of badness,  
>> but the
>> actual effect is simply to give up integrity as well as  
>> confidentiality
>> to the proxy.
>
> You would not reveal the MAC keys, of course. only the encryption  
> keys.
>
> There is no need to allow the proxy to modify the traffic.  If the
> proxy doesn't like some of the data, it should not pass it along and
> terminate the connection.
>
> -Martin

No, this undermines the cryptographic security.  Please see Section 6  
of the draft.

A malware-screening proxy needs to be able to modify the traffic  
flowing through it.  It would be pointless for it to detect malware,  
and then pass it on to the client!

David