Re: [TLS] TLS Proxy Server Extension

Martin Rex <> Fri, 29 July 2011 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C91E21F898E for <>; Fri, 29 Jul 2011 16:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.909
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F-Qay9BeOe9g for <>; Fri, 29 Jul 2011 16:27:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0690121F8AF7 for <>; Fri, 29 Jul 2011 16:27:01 -0700 (PDT)
Received: from by (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 <>
Message-Id: <>
To: (David McGrew)
Date: Sat, 30 Jul 2011 01:26:57 +0200 (MEST)
In-Reply-To: <> 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
Subject: Re: [TLS] TLS Proxy Server Extension
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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


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