Re: [TLS] TLS Proxy Server Extension

[Martin Rex <[e-mail]>]

David McGrew wrote:
> 
> Martin Rex wrote:
> > 
> > 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.

Exactly in that sense.  You do not have the slightest proof that
the server, which your proxy impersonates, is actually involved.
The proxy could be making up the entire conversation and the
client will not be able to tell the difference.


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

Been there, done that, and really disliked it:
     http://tools.ietf.org/html/draft-housley-evidence-extns-01


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

You mean by having the entire TLS security architecture walk the plank,
you could get away with fairly minor code changes?


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

Such an evolution would have the prerequisite of a client cooperating.

And your solution to not have pretty TLS loose virginity at some point
in the future, is to rape her right away, i.e. start with an
almighty TLS proxy?


-Martin