Re: [TLS] TLS Proxy Server Extension

David McGrew <> Fri, 29 July 2011 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8389821F86AA for <>; Fri, 29 Jul 2011 13:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.837
X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a9afNeIWzOuo for <>; Fri, 29 Jul 2011 13:00:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8E50321F86A4 for <>; Fri, 29 Jul 2011 13:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4881; q=dns/txt; s=iport; t=1311969630; x=1313179230; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=cl4qHHuB1tw8UpIKF4ShQv6ZRo6aUIEZQ5It+VBon2g=; b=H4pj7gjHXjTQ1J87EU7pGQy2+oBXc/H+NC886ZXbFm8m+YFtgx798sdv wOUWNpp6g/q/WkGU+rbkZBEnfBszYcGNNpNO6qch3/j47IpxrYw3H18km 2zHO/WK4JOdybAYHP2fMaSb/KsXKNHAeoxrJ0t58KQD78IOdAGKqGvv0o k=;
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7904040"
Received: from ([]) by with ESMTP; 29 Jul 2011 20:00:29 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p6TK0S1k008264; Fri, 29 Jul 2011 20:00:28 GMT
Message-Id: <>
From: David McGrew <>
To: Marsh Ray <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 29 Jul 2011 13:00:28 -0700
References: <> <>
X-Mailer: Apple Mail (2.936)
Cc: Philip Gladstone <>,
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: Fri, 29 Jul 2011 20:00:31 -0000

Hi Marsh,

On Jul 29, 2011, at 8:22 AM, Marsh Ray wrote:

> On 07/26/2011 10:01 AM, David McGrew wrote:
>> The ProxyInfo extension only provides information about proxies to
>> the client; it does not provide any information to the server about
>> either the client or other proxies on the path.  This is acceptable
>> when there are no client certificates in use, which is (regrettably)
>> common in practice.  It would be possible to generalize the ideas in
>> this note to also provide information to the server about the client
>> and other proxies on the path.  Nonetheless, that goal is out of
>> scope for this note.
> It's good that the draft is explicit about what is not being  
> provided to
> to the server.
> But, please, won't somebody think of the poor servers?
> As someone who works on the security of an authentication service
> delivered through TLS, I feel the need to oppose the standardization  
> of
> functionality with the potential to undermine the security of our  
> service.
> It was once said that the driving purpose of the design of SSL was to
> make users *feel* secure enough to be comfortable entering their  
> credit
> card number on the web and I've seen little or no evidence to refute
> that claim. In this model, all the paranoia is expected to reside with
> the user.
> One of the unfortunate artifacts of the resulting design is that the
> server has no way to prove the nonexistence of a MitM, he can only  
> hope
> that the client will do a good job of this. We all know how well this
> works when put to the test by an active attacker. Client certificates
> are currently the only tool available for server admins to participate
> in preventing this important class of attacks. The authors of this  
> draft
> seem to feel the relative infrequency of client certificate usage is
> "regrettable", yet they propose standardizing a scheme which will  
> break
> them entirely!

Important clarification: we have not proposed any standards action, we  
have requested comments on a draft.  I felt that the approach outlined  
in the draft deserved to be discussed even though it does not address  
the issue of client authentication to the server.  I would strongly  
prefer a solution that works with client certificates, if one can be  
worked out.   (I think the ideal security goal here would be something  
like three-party mutual authentication and authentication checking.   
If we are willing to be invasive to TLS, we could do something like  
that.  If C/S/P each issued nonces and signed all of the nonces, that  
would get us most of the way there.   That sounds like an interesting  
design exercise, but I am skeptical that we could get broad  
deployment.  How close we can get to that goal is something worth  

In the absence of a client certificate, the proxy extension does  
improve security, because it restores server authentication and  
authorization, and that operation is essential when the client is  
using password-based authentication  to the server.


> Consider, for example, the scenario which was described to me by  
> someone
> in the retail sector. She was responsible for auditing security  
> policies
> for a retail credit card website. They interpreted the relevant laws  
> and
> industry regulations to mean that they were obligated to intercept
> employee web browser usage to monitor for and block various forms of
> undesired content. However, employees may also have personal credit
> cards with the same issuer, the statements of which they might  
> sometimes
> access from their desk at work. But the organization considered itself
> forbidden from snooping on that traffic.
> I don't know if or how they got it sorted out, my point being only  
> that
> there are several parties involved here and it's not clear at all the
> circumstances under which one party may have an absolute right to
> impersonate, decrypt, or MitM the traffic even between its own clients
> and servers.
> If you operate a financial or government site, you may be under  
> various
> legal obligations to ensure that certain information is transmitted  
> only
> to the intended recipient. Today this is commonly done (weakly) with
> non-client certificate HTTPS websites. If or when MitM interception
> becomes standardized and widespread it will obligate the use of client
> certificates to satisfy this requirement while at the same time  
> breaking
> their functionality entirely.
> Any standardization of MitM or interception functionality must take  
> into
> account the requirements of the server operators as an equal party and
> stakeholder in the security of the connection.
> - Marsh