Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

Hi Marsh,

On Jul 29, 2011, at 11:33 AM, Marsh Ray wrote:

> On 07/29/2011 11:52 AM, Yoav Nir wrote:
>>
>> This draft does not invent TLS proxies or even standardize them.
>
> The IETF defines no such thing as a "TLS proxy". I don't even see  
> how such a thing can be defined without violating some basic  
> guarantees of the protocol, but I'm open to being educated on that.
>
>> It invents a way for the client to recover some of the information  
>> that
>> is lost because of the existing use of TLS proxies.
>
> I'm really sympathetic to the necessity of the lesser evil in  
> practice.
>
> But "TLS proxies" currently work poorly today because they are  
> underspecified and they violate certain protocol assumptions.  
> Sometimes they end up weakening security and breaking higher-layer  
> stuff.
>
>> I can see how this draft could be extended to support client
>> certificates, but that would require changes to the server as well,
>> and a change to the state machine that elevates this draft in the new
>> taxonomy from "trivial" to "significant",
>
> That would be a good thing in my view because the underlying changes  
> actually are significant.
>
>> so we probably don't want
>> that at all. But client certificates are already broken now behind a
>> TLS proxy.
>
> What is this "TLS proxy" of which you speak? I see no SHOULDs or  
> MUSTs or which apply to it, much less any cryptographic guarantees  
> about it.
>
> More importantly, what is its security model?

Some appropriate security goals are outlined in Section 6.  They are  
client-oriented; as you pointed out, ideally the server would gain  
some assurances about the client as well.

>
> All I see usually amounts to "convince the client to install our  
> trusted root and then the MitM can get away with almost anything".  
> Perhaps this draft is admirable in that it defines a mechanism with  
> which the MitM MAY choose to communicate certain info to the client,  
> but I feel it is handwaving over the deeper questions and tacking  
> features on top of an architecture which isn't really defined at all.

I would be interested to hear your thoughts on what sort of  
architecture would be good.

It might be appropriate to have the certificate held by the proxy have  
an attribute that states that it is a proxy.  An attribute could be  
used to limit the scope of the proxy as well, based on e.g. DNS.  That  
sort of mechanism would ensure that a proxy would be known to the  
client; it couldn't hide its presence just by not sending the TLS  
Proxy Extension.

David