Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

On Aug 1, 2011, at 1:38 PM, Martin Rex wrote:

> 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

Those are colorful metaphors.  I assume that if you are willing to  
deploy such rhetorical excess, you do not actually understand what is  
being proposed.

David