Re: [TLS] TLS Proxy Server Extension

Marsh Ray <marsh@extendedsubset.com> Fri, 29 July 2011 15:22 UTC

Return-Path: <marsh@extendedsubset.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 97E6F11E807A for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 08:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 Ccu+Qe-fnxis for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 08:22:33 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8511E8072 for <tls@ietf.org>; Fri, 29 Jul 2011 08:22:32 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1QmotT-000Flc-67; Fri, 29 Jul 2011 15:22:31 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F34816070; Fri, 29 Jul 2011 15:22:28 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+wK8bt1ljTB+3H0tr7a4PKWgnQkooaCq8=
Message-ID: <4E32D033.7020601@extendedsubset.com>
Date: Fri, 29 Jul 2011 10:22:27 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: David McGrew <mcgrew@cisco.com>
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com>
In-Reply-To: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 15:22:33 -0000

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!

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