Re: [TLS] TLS Proxy Server Extension

Martin Rex <> Mon, 01 August 2011 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 875B81F0C49 for <>; Mon, 1 Aug 2011 13:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.929
X-Spam-Status: No, score=-9.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p8wvftTHGghK for <>; Mon, 1 Aug 2011 13:38:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB91B1F0C3D for <>; Mon, 1 Aug 2011 13:38:28 -0700 (PDT)
Received: from by (26) with ESMTP id p71KcW1S011117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 22:38:32 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (David McGrew)
Date: Mon, 1 Aug 2011 22:38:31 +0200 (MEST)
In-Reply-To: <> from "David McGrew" at Aug 1, 11 12:15:22 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [TLS] TLS Proxy Server Extension
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Aug 2011 20:38:30 -0000

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:

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