Re: [TLS] TLS Proxy Server Extension

Martin Rex <mrex@sap.com> Fri, 29 July 2011 06:21 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 8BA2921F8639 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 23:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.919
X-Spam-Level:
X-Spam-Status: No, score=-9.919 tagged_above=-999 required=5 tests=[AWL=0.330, 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 uCHgsk7lflRQ for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 23:21:43 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 947EE21F85AE for <tls@ietf.org>; Thu, 28 Jul 2011 23:21:43 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6T6Ld2e008777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 08:21:39 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107290621.p6T6Lckb004132@fs4113.wdf.sap.corp>
To: matt@mattmccutchen.net
Date: Fri, 29 Jul 2011 08:21:38 +0200
In-Reply-To: <1311915090.2035.36.camel@localhost> from "Matt McCutchen" at Jul 29, 11 00:51:30 am
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: Fri, 29 Jul 2011 06:21:44 -0000

Matt McCutchen wrote:
> 
> > and that also enables the clients
> > to clearly limit who is able to read the traffic.
> 
> Huh?  The proxy's ability to pass decrypted data to someone else is no
> different than if it were bridging two TLS connections.

No, that is entirely different.

Revealing the traffic **encryption** keys to the proxy requires cooperation
of the client, so a sensible client implementation can ask for consent
and the user may deny consent, whereas a proxy with a super-CA-cert
can subvert any connection for that client, no matter where that
client goes--and MitM all connections any time, including those that do
not traverse that proxy.


> 
> > No super-CA-equivalent
> > keys would need to be on the malware-scanning Proxy.
> 
> You speak as if that were in a whole different class of badness, but the
> actual effect is simply to give up integrity as well as confidentiality
> to the proxy.

You would not reveal the MAC keys, of course. only the encryption keys.

There is no need to allow the proxy to modify the traffic.  If the
proxy doesn't like some of the data, it should not pass it along and
terminate the connection.

-Martin