Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Sat, 30 July 2011 13:20 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 2C37621F89BE for <tls@ietfa.amsl.com>; Sat, 30 Jul 2011 06:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.789
X-Spam-Level:
X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 01HMdNset7i5 for <tls@ietfa.amsl.com>; Sat, 30 Jul 2011 06:20:15 -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 42F9421F8876 for <tls@ietf.org>; Sat, 30 Jul 2011 06:20:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3394; q=dns/txt; s=iport; t=1312032015; x=1313241615; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=9IfPfive7zmvJul0W3AQdwtjP9JoNbmhM3eCYROlkYI=; b=ExsIDyALAt47E9KnC0mdOmKB/6zSJQB0lsNP4No4X2lhO7eKwM4ixO4S rv7Sb8iF6b/6cDRlPgUEIwbrhrJv6yBs4QaTeyK4cqbSwbfhxitV+aDOj I2mq8YBBKhIyN7wTOteIq7x7/OsNNB59x2xeO6/Czsh/0pMGthS+tAz0O o=;
X-IronPort-AV: E=Sophos;i="4.67,291,1309737600"; d="scan'208";a="8059271"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2011 13:20:14 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6UDKDWF007102; Sat, 30 Jul 2011 13:20:13 GMT
Message-Id: <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4E337BF4.8030307@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: Sat, 30 Jul 2011 06:20:12 -0700
References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> <D142B8F0-3F3C-4D69-918E-C15F42E84CBF@cisco.com> <4E337BF4.8030307@extendedsubset.com>
X-Mailer: Apple Mail (2.936)
Cc: 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: Sat, 30 Jul 2011 13:20:16 -0000

It seems that you do not understand the intent of the draft or the  
authors.

The use case here is web filtering as it is used by organizations and  
consumers, in which a consumer or an organization chooses to use a  
service or a product that acts as an HTTP proxy, and configures their  
clients to do so.  It is desirable in such cases to use TLS whenever  
possible, and it is certainly desirable that the client be able to  
authenticate the proxy.  The intent of the authors is to enable TLS to  
be used when an proxy is present, and to make clients informed about  
both the proxy and the server, and to provide cryptographically strong  
authentication of both.  The client should be able to decide if it  
accepts the proxy for a particular session, and the scope of the proxy  
should be limited, and the proxy should not lie to the client.   The  
client should also have the full information about the server on the  
other end of the connection.

We oppose the development of a technology that would help a country  
spy on its citizens, and we certainly oppose the development of  
standards in that area.  The IETF can't control how the technologies  
that it develops are used, or who uses them, of course, which makes it  
imperative to not develop any mechanisms that could be used in that way.

David

On Jul 29, 2011, at 8:35 PM, Marsh Ray wrote:

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