Re: [TLS] TLS Proxy Server Extension

[Matt McCutchen <[e-mail]>]

On Thu, 2011-07-28 at 12:48 -0700, David A. McGrew wrote:
> > - If you're going to require support from the client, you might as  
> > well
> > do something to support client authentication on the server-side
> > connection, e.g., tunnel the PKCS#11 protocol back to the client.
> 
> It would be great to promote client authentication, though I'm not  
> exactly sure what you are proposing.  Do you mean to pass PKCS#11  
> through a TLS extension?

No, I imagine PKCS#11 would use several round trips, so a new
ContentType would be needed.  It's probably possible to define a more
efficient protocol than a serialization of PKCS#11, but also more work.
Whatever the protocol would be, it has to nest to handle multiple
proxies.

> > - It would be better design to put the whole certificate acceptance  
> > test
> > (trust anchor validation + server name check) on the client.  Schemes
> > such as DANE replace the certificate acceptance test as a whole.
> 
> I also have the sense that it is best to have the client do all the  
> work in most cases.   But do you think it would be OK to eliminate the  
> possibility that the proxy does some of the work?

Not sure.  Do you have a use case for the proxy doing some or all of the
work?  My point was that splitting the server name check from the trust
anchor validation is specific to PKIX certificate acceptance and serves
no purpose that I can foresee, while doing the whole test on the client
often makes sense because the client is prepared to do the whole test in
the absence of a proxy.

> > - One approach would be to do a real escrowed TLS where the client
> > negotiates directly with the server but releases the confidentiality  
> > key
> > and optionally also the integrity key to the proxy.  This subsumes all
> > of the above concerns but doesn't allow the proxy to manipulate the
> > handshake in any finer way than blocking the connection if it doesn't
> > like the outcome.
> 
> I think that propagating secret or private keys from one device to  
> another is not a good idea, for crypto reasons which are outlined in  
> Section 6 of the draft.

I missed the potential attack when the stream is edited under a single
integrity key.  And indeed, I am having trouble coming up with any
scheme that is fundamentally simpler than two separate TLS connections
and does not introduce security problems.  You may still wish to provide
as much client-to-server negotiation transparency as possible.

Another comment:

>    The ProxyInfo
>    proposal [...]
>    allows the client to refuse to deal with untrusted proxies.

This has to be understood carefully.  An "untrusted proxy" is just a
MITM attacker.  In general, we already have a mechanism for refusing to
deal with them: it's called server authentication.  The above benefit
exists /compared to the alternative/ of a proxy trust anchor.

-- 
Matt