Re: [TLS] TLS Proxy Server Extension

Marsh Ray <> Sat, 30 July 2011 03:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 224C411E80E6 for <>; Fri, 29 Jul 2011 20:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FQ0N5QxyBMGc for <>; Fri, 29 Jul 2011 20:35:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9177411E807E for <>; Fri, 29 Jul 2011 20:35:18 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1Qn0Kc-0009se-4s; Sat, 30 Jul 2011 03:35:18 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id B0CA2606F; Sat, 30 Jul 2011 03:35:15 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1+T+pFg5UchHMplb2cLMmplWTWmxtiGccM=
Message-ID: <>
Date: Fri, 29 Jul 2011 22:35:16 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: David McGrew <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Sat, 30 Jul 2011 03:35:19 -0000

On 07/29/2011 05:24 PM, David McGrew wrote:
> On Jul 29, 2011, at 1:44 PM, Martin Rex wrote:
>> I am strongly opposed to have any document describing such proxies
>> published as an RFC!
> And yet you would favor a protocol that propagates decryption keys
> around the network?

I'm with Martin on this one.

If the goal is to allow well-regulated eavesdropping of a TLS protocol 
stream it would be better done via a mechanism which transfers the 
minimum necessary secret key material to the authorized party with the 
consent of both legitimate endpoints. Although I've often wanted such a 
thing for debugging, I don't like it. But it would be preferable to 
having middleboxes falsely impersonating the identity of servers.

Just because you can convince a client to accept your trusted root cert 
it doesn't give you the moral authority to impersonate the identity of a 
third party or deceive them about the connection's security properties. 
Otherwise, by that logic, there are hundreds of governments and 
corporations around the world which would be justified in doing so.

> We don't have a choice about whether or not TLS proxying will be done on
> the Internet; it is being done.

Over the internet? Really? The only case I've heard of was Syria using a 
Blue Coat on their people. I'd assume China has built the capability as 

> What we can choose is whether or not the
> IETF improves how it is being done.

But this is not really "TLS proxying" at all since the TLS is actually 
being stripped off entirely and re-established with a largely 
independent context.

 From a purely technical perspective it sounds as if people want to 
convert TLS from a "two party plus PKI" protocol into a "three party 
plus" protocol, without actually defining the implications of all the 
new trust relationships it brings up.

- Marsh