Re: [TLS] TLS Proxy Server Extension
Martin Rex <mrex@sap.com> Fri, 29 July 2011 23:27 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 3C91E21F898E for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 16:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.909
X-Spam-Level:
X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=0.340, 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 F-Qay9BeOe9g for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 16:27:02 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0690121F8AF7 for <tls@ietf.org>; Fri, 29 Jul 2011 16:27:01 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6TNQwHg020359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jul 2011 01:26:58 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107292326.p6TNQvGT001711@fs4113.wdf.sap.corp>
To: mcgrew@cisco.com
Date: Sat, 30 Jul 2011 01:26:57 +0200
In-Reply-To: <A67FAF78-F8FA-41BA-8CC1-B26CB8509155@cisco.com> from "David McGrew" at Jul 29, 11 12:33:31 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
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 23:27:03 -0000
David McGrew wrote: > > Martin Rex wrote: > > > > 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. > > No, this undermines the cryptographic security. > Please see Section 6 of the draft. I'm having some difficulties understanding Section 6, but some of what is described is clearly bogus and some clearly wrong. Cryptographic security of the TLS protocol is clearly unaffected from sharing the traffic encryption keys with the proxy. What happens is that the proxy may remove confidentiality of the data and look at the data before passing along the original, encrypted data the the rightful communication peer. It is a design property of the TLS protocol that having access to the traffic encryption keys does not allow _you_ to subvert other characteristics of the protocol beyond the confidentiality. > > A malware-screening proxy needs to be able to modify the traffic > flowing through it. It would be pointless for it to detect malware, > and then pass it on to the client! Huh? The peer does not get anything that the proxy does not forward. And if there is something goofy. the proxy simply terminates the connection (both connection. that to the real server and that to the real client). Proxies MUST NOT change a single bit of the data stream, any capability to modify the communication without the receiver aborting the connection because of a data integrity violation would mean that you have _completely_ subvert the security of the whole system, and there would exist no technical limits to arbitrary and fully covert modifications. > > 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. > > It sounds like you misunderstand the proposal. The approach we are > going for is one in which the client is fully informed about both the > proxy and the server, and the client is free to choose to trust them > or not. "The client (should) know(s) about it" is not a legally valid escape from the obligations for data privacy and data integrity guaranteed by the our constitution and the data protection laws, at least not here in Germany. For the purpose of malware screening, the proxy having only the traffic encryption keys is perfectly sufficient. And because it is perfectly sufficient, the MAC keys fall under constitutional protection and requesting them would be unlawful. A little more than three years ago our constitutional court described the concept of a "fundamental right to the guarantee of the confidentiality and integrity of information technology systems" based on the abstract gurantees of fundamental rights by our constitution specifically applied to modern information technology. e.g. http://www.bundesverfassungsgericht.de/pressemitteilungen/bvg08-022en.html (the original german-language decision is elaborate, crystal clear and perfectly fits with 4-5 earlier decisions about telecommunication and informational self-determination that I knew before this decision. The german press release seems just slighty inaccurate in some details (secretarial sloppiness), but I'm having significant difficulties understanding the official english-language press release...) Given the clear and consistent history of decisions by our constitutional court on the "fundamental right for informational self-determination" with respect to telecommunication and protection of data transported by or stored on information technology systems, there are a number of current practices in german companies that are very probably un-constitutional by that measure, and it is only a matter of time when the attitude of lower courts and lawyer, that even today frequently fail to properly account for the requirements published by our constitutional court, get challenged and overturned, with the result that a number of popular current practices encroaching on integrity and privacy of telecommunication, will have to be discontinued in Germany. -Martin
- [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yngve N. Pettersen
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Adam Langley
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Adam Langley
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- [TLS] Certificate pins vs. MITM proxies Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Anders Rundgren
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Ken Peirce
- Re: [TLS] TLS Proxy Server Extension Peter Gutmann
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Joshua Davies
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Ken Peirce
- Re: [TLS] TLS Proxy Server Extension Philip Gladstone
- Re: [TLS] TLS Proxy Server Extension Kemp, David P.
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Ralph Holz