Re: [TLS] TLS Proxy Server Extension

[Marsh Ray <[e-mail]>]

On 07/30/2011 08:20 AM, David McGrew wrote:
> It seems that you do not understand the intent of the draft or the authors.

The intent is nearly irrelevent. The text of the spec and the bits on 
the wire are what matters.

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

HTTP has explicit support for proxies and you can connect to them 
securely via TLS already. Wouldn't this all be done more appropriately 
at the HTTP layer?

> The intent of the authors is to enable TLS to be
> used when an proxy is present,

But the intent of TLS is to prevent man-in-the-middle attacks, i.e., to 
prevent you from proxying it.

Just because you can exploit it almost reliably with a custom root CA on 
today's clients doesn't mean that it's not deeply contrary to the 
security architecture of TLS.

Design a secure way for the legitimate endpoints to agree to share some 
session key material with you in a way that doesn't impersonate anyone. 
I might even support such an extension (but good luck convincing the 
servers of the world).

> and to make clients informed about both
> the proxy and the server, and to provide cryptographically strong
> authentication of both.

This concept of polyamorous TLS is more radical than its proponents want 
to accept.

Current TLS:
Client strongly authenticates server via trusted CA
Server may authenticate client, but usually server relies on client to 
stop S-C MitM
Any proxy can only slow or drop connections

"TLS proxy" via root cert on client:
Client can't authenticate server any stronger than weakest proxy allows
Client may not even be aware of proxies
Any proxy may degrade security of connections arbitrarily
Any proxy may get pwned and expose its root CA private key
Any proxy may prevent the use of protocol features and extensions
Any proxy can both read and modify plaintext
Server can't authenticate client at all, client certs are busted forever
Server can't authenticate proxy at all
Server probably can't detect proxy downgrade
Proxy relies on client to stop P-C MitM
Server relies on proxy to stop S-P MitM

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

But by installing the custom root CA in the browser you've weakened the 
guarantees (which derive from "MUST"s and "MUST NOT"s) to merely 
"should"s and "should not"s. I.e., you've removed the strong crypto 
guarantees from the perspective of the legitimate client and (by 
extension) the server, who are the only parties given any security 
guarantees at all in the current TLS RFCs.

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

Meh. It already exists for anyone controlling a trusted root or sub-CA, 
why would they choose to turn on this functionality?

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

Put it another way: don't develop mechanisms that break basic security 
guarantees. Even better would be to improve on them.

- Marsh