Re: [TLS] TLS Proxy Server Extension

David McGrew <mcgrew@cisco.com> Fri, 29 July 2011 19:32 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 4F4195E801A for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 12:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.884
X-Spam-Level:
X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.285, 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 aqkAfm18bR2g for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 12:32:49 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8482D5E8011 for <tls@ietf.org>; Fri, 29 Jul 2011 12:32:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2638; q=dns/txt; s=iport; t=1311967969; x=1313177569; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=kMf6SjgWcYZQQ/45g/bvaqbjaC5+ENHsUm9rFnhKnzY=; b=N2YRF9J9P+z/KGLL+UN/5m/8/ilfPgemIFvUqpUS3iE2po7yWxvig2TY Gb8DgTnNYcRFisRVl1ZYTYwbn/E0QOfswwaKb3+aYeJP6aOCxABXUIUi8 f2f5Cf7fR5bm1+cEWKyOYCCYVwyiLxf3rtpsRpZmCYbNJ5tvqUIHsJ1M6 w=;
X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7897144"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 19:32:48 +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 p6TJWlBP023800; Fri, 29 Jul 2011 19:32:47 GMT
Message-Id: <15A155F5-2F01-408A-AA0F-3AA834C335F3@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: mrex@sap.com
In-Reply-To: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp>
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 12:32:46 -0700
References: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp>
X-Mailer: Apple Mail (2.936)
Cc: tls@ietf.org, pgladstone@cisco.com
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 19:32:50 -0000

Hi Martin,

On Jul 27, 2011, at 11:17 AM, Martin Rex wrote:

> Matt McCutchen wrote:
>>
>> On Tue, 2011-07-26 at 08:01 -0700, David McGrew wrote:
>>> I would like to request feedback on a new draft that Philip  
>>> Gladstone
>>> and I put together, which aims to solve some of the security  
>>> problems
>>> that happen when there is a (HTTP) proxy present and TLS is in use.
>>
>> It doesn't seem that this work is in any way specific to HTTP.
>
> Only for Web-Browser scenario can I personally see a very limited
> value that does not amount to 100% wiretapping.
>
> Are you aware of rfc2804 "IETF Policy on Wiretapping"?
>
>  http://tools.ietf.org/html/rfc2804
>
> Standardizing MITM attacks on TLS-protected communication
> ("lawful intercept?") seems like an extremely bad idea to me.

Standardizing MITM attacks would be awful, but that's not at all what  
the draft is proposing.

>
> Checking whether some data conforms to a certain company policy will
> almost always be illegal in European countries, where we have
> sensible data protection laws.

Firewalls are illegal in Europe?  That can't be right.

IANAL, but it appears that the approach of the draft (which notifies  
the client about the presence of a proxy, as well as provides info on  
the server) could help to meet the EU Data Protection Directive, in  
that it informs the data subject when his/her personal data are being  
processed by a proxy, a condition that must be met in some cases.

>>
>>
>> - One approach would be to do a real escrowed TLS where the client
>> negotiates directly with the server but releases the  
>> confidentiality key
>> and optionally also the integrity key to the proxy.  This subsumes  
>> all
>> of the above concerns but doesn't allow the proxy to manipulate the
>> handshake in any finer way than blocking the connection if it doesn't
>> like the outcome.
>
> For the purpose of "centralized malware screening", for the incoming
> Web traffic of Web Browsers that are well known to interpret such
> data in arbitrarily stupid ways (such as active content, img src,  
> (i)frame,
> javascript, css), sharing the encryption traffic keys with the Proxy
> would be perfectly sufficient, and that also enables the clients
> to clearly limit who is able to read the traffic.  No super-CA- 
> equivalent
> keys would need to be on the malware-scanning Proxy.
>
>


In what way is a protocol that propagates secret keys to a proxy any  
better with regard to privacy?   Note that if such a protocol is used  
by a server, then the client is not informed.

David