Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Fri, 29 July 2011 20:00 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8389821F86AA for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 13:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.837
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9afNeIWzOuo for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 13:00:30 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8E50321F86A4 for <tls@ietf.org>; Fri, 29 Jul 2011 13:00:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; 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 mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2011 20:00:29 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TK0S1k008264; Fri, 29 Jul 2011 20:00:28 GMT
Message-Id: <13649A96-FC0E-4DA6-99DA-C49E20AD9421@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4E32D033.7020601@extendedsubset.com>
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: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <4E32D033.7020601@extendedsubset.com>
X-Mailer: Apple Mail (2.936)
Cc: Philip Gladstone <pgladstone@cisco.com>, tls@ietf.org
Subject: Re: [TLS] TLS Proxy Server Extension
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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:
>>
>> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00
>
>> 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  
exploring.)

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.

David

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