Re: [TLS] TLS Proxy Server Extension

Martin Rex <mrex@sap.com> Wed, 27 July 2011 18:17 UTC

Return-Path: <mrex@sap.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 7F9E021F8BB9 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 11:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.871
X-Spam-Level:
X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 kBUL5WmYCu17 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 11:17:29 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB95921F8867 for <tls@ietf.org>; Wed, 27 Jul 2011 11:17:28 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6RIHIZj023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 20:17:23 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp>
To: matt@mattmccutchen.net (Matt McCutchen)
Date: Wed, 27 Jul 2011 20:17:17 +0200 (MEST)
In-Reply-To: <1311734551.7071.72.camel@localhost> from "Matt McCutchen" at Jul 26, 11 10:42:30 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: pgladstone@cisco.com, mcgrew@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
Reply-To: mrex@sap.com
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: Wed, 27 Jul 2011 18:17:29 -0000

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.

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.


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


-Martin