Re: [TLS] TLS Proxy Server Extension

The discussion in a nutshell:

http://www.dilbert.com/fast/2011-08-02

On 2011-08-01 21:15, David McGrew wrote:
> 
> On Aug 1, 2011, at 9:15 AM, Martin Rex wrote:
> 
>> David McGrew wrote:
>>>
>>> Again, it seems that you do not quite understand what we are trying  
>>> to
>>> achieve.   There is current practice that uses proxies in a way that
>>> is bad for clients (and you outline many of the reasons below).  We
>>> aim to improve the situation for clients and the security of the
>>> overall solution.  One important point: it is possible to design a
>>> solution in which the proxy does not contain a CA.
>>
>> You're trying to give the proxy the authority to impersonate
>> _every_ server.
> 
> On the contrary, the goal here is to not have the proxy impersonate  
> any other device, at least not impersonate in the cryptographic sense.
> 
>>  Whether it is through an super-CA-cert or whether
>> you're extending the protocol so that the client believes a forwarded
>> certificate with _no_ proof-of-posession for that cert is a mere
>> implementation detail, and has no impact of the size of the security
>> problem that you want to newly create.
>>
> 
> It's hard to parse that sentence, but if I understand you right, you  
> think that it is important for the client to have a strong assurance  
> that the subject of the server certificate is an active participant in  
> the session.   I agree that is a highly desirable property.
> 
> I think the right theoretical approach to analyzing this sort of  
> protocol would be to start with a formal model of TLS as a two-party  
> authentication protocol, and extend it to accomodate a three-party  
> system with the appropriate role definitions.  Fortunately, only the  
> authentication aspects need to be considered, and some of the key  
> establishment goals can be ignored, which makes the analysis easier.   
> If we had the freedom to design the system from scratch, the obvious  
> approach would be to have C, S, and P each issue nonces that get  
> signed by each other party, along with the other data that gets  
> currently signed, and indication of the role of each signer.  What is  
> most interesting is: how close can one get to this ideal protocol by  
> extending TLS?
> 
>>
>>>
>>> Propagating TLS session key material is a worse idea for a lot of
>>> reasons.  It would be a fragile solution in which easy-to-make
>>> implementation mistakes could undermine security.
>>
>> I'm sorry, but that is a completely bogus claim.
>>
>> If the proxy is terminating both TLS connections, it will have access
>> to traffic encryption and mac keys of both connections can can leak
>> those just as easily.  Sharing the traffic encryption keys will not
>> make this any worse.
>>
>>
>>>
>>> It would require considerable new implementation work.
>>
>> You mean because it would require an additional network channel to
>> talk to the proxy? yes.  It can not happen "by accident".
>>
>>
>>>
>>> It would make crypto validation considerably harder if not  
>>> impossible.
>>
>> Nope.  That is orthogonal.
> 
> On the above three points: allowing a proxy to coordinate betwen two  
> TLS sessions allows one to preserve most of the TLS protocol and  
> implementation.   In contrast, a solution that propagates session keys  
> will require new implementation work for the data plane, state  
> management, and so on.  If the proxy attempts to modify the session,  
> all sorts of significant crypto problems will crop up.  There will be  
> HTTP proxies that expect to modify the traffic, and it would be unwise  
> to expect that a proxy implementer would respect the injunction to not  
> modify the session, if a specification for session key propagation  
> were developed.
> 
> It seems like a major difference that we have is that you expect a  
> "read only" solution to be viable, while I don't.  A read-only  
> decryption proxy would be considerably easier to implement correctly.   
> However, I have zero confidence that a read-only decryption proxy  
> would not evolve into a read/write proxy, which would introduce very  
> significant security problems.
> 
>>
>>
>>>
>>> If it aimed to preserve end-to-end authentication, it would be
>>> fundamentally incompatible with Authenticated Encryption in general
>>> and the AEAD facility in TSL 1.2 in particular, and it would probably
>>> end up getting misused and abused in practice.
>>
>> Correct, the use of AEAD would break the security, since this mode  
>> does
>> not use seperate traffic encryption and mac keys.  Personally, I  
>> consider
>> AEAD a bad idea, so I don't mind disabling these cipher suites when
>> traversing such a proxy.
>>
> 
> Your personal opinion on AEAD goes against a lot of theory and  
> standards work of the last decade.  Have you considered providing your  
> criticisms in writing?
> 
>>
>>>
>>> If it did not aim to preserve end-to-end authentication,
>>> then it would require considerable changes to the TLS protocol, to
>>> prevent keystream insertion attacks and keystream re-use.  Perhaps
>>> worst of all, it would create a mechanism that could more easily be
>>> abused; a server could (mis)use it and give away session keys without
>>> the knowledge or consent of the client.
>>
>> I have no clue what you mean.
> 
> Then think about the situation in which the proxy has the encryption  
> keys and the authentication keys, and yet there is just a single TLS  
> session, and consider the changes that would be needed to the TLS  
> protocol in order to retain security even when the proxy is modifying  
> the session data.
> 
> 
>>  If the proxy terminates the clients
>> TLS connection and establishes a new connection to the real server,
>> then it will have to impersonate the real server to the client
> 
> No, that's not right, at least not if "impersonate" is meant in the  
> cryptographic sense.   If "impersonate" is meant in the sense that a  
> proxy can modify the traffic passing through it, then yes, that is a  
> goal for the system; it is a requirement if TLS is to be used to  
> protect communications when an HTTP proxy is present (for many types  
> of proxies).
> 
> 
>> in any case
>> and will always have all keying material available to do anything bad
>> to either or both peers.
>>
> 
> In any solution in which a proxy has session keys, it is required that  
> the client and server trust the proxy to do the right thing.
> 
> One thing that really surprises me about your line of thinking is the  
> fact that you feel that a protocol that can propagate a session key to  
> a proxy would encourage better respect of privacy.  A server could use  
> that protocol to pass keys to a middlebox without the knowledge or  
> consent of the client, and the client could do so without the  
> knowledge or consent of the server.   With the key propagation  
> approach, there is very little that you and I can do to prevent this  
> sort of behavior.  (Side note: one could design a solution that  
> required both the client and server to approve of the presence of the  
> proxy; in fact, I've been through that design exercise.  However, it  
> would be easy for implementers to ignore the stipulation that both  
> sides accede to the proxy, and they would be motivated to do so.)
> 
> I think we've both stated our views well enough that people have a  
> reasonable idea of what we think.   It would be good to let others who  
> care about the topic have a chance to offer their own thoughts.
> 
> David
> 
>> So security-wise, the TLS proxy that you are proposing is at the
>> far end of badness, there is _nothing_ that can possibly be worse,
>> but a few thinghs might be *MUCH* better.
>>
>>
>> -Martin
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 