Re: [TLS] TLS Proxy Server Extension

David McGrew <> Sat, 30 July 2011 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43AA021F858D for <>; Sat, 30 Jul 2011 06:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.777
X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7oVxjPSvxKx9 for <>; Sat, 30 Jul 2011 06:22:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6EF3B21F8513 for <>; Sat, 30 Jul 2011 06:22:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5773; q=dns/txt; s=iport; t=1312032145; x=1313241745; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=a+z4BinFHdRE5POJFBxeKQ2iF2CZKUelf6wiA6fTLJk=; b=H3TCGmcFplJMFR1hwxsiiYqwhOhN3xEkuHzEQZf46tDB2qNGrZgs3u+7 ObRI5cSiY3jFqxU7oszzonYn48tVAnjwqZvkXscTwu4CTjebF+ZVVoBnB vCfgjrS2JItW6TF02zv9ewSVlQdtc8Vj8f3D+08qIj9Odyi8oEzOqL/P9 g=;
X-IronPort-AV: E=Sophos;i="4.67,291,1309737600"; d="scan'208";a="8062725"
Received: from ([]) by with ESMTP; 30 Jul 2011 13:22:24 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p6UDMNb0012074; Sat, 30 Jul 2011 13:22:23 GMT
Message-Id: <>
From: David McGrew <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 30 Jul 2011 06:22:22 -0700
References: <>
X-Mailer: Apple Mail (2.936)
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: Sat, 30 Jul 2011 13:22:32 -0000

On Jul 29, 2011, at 4:26 PM, Martin Rex wrote:

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

I would be obliged if you could provide specifics.

> Cryptographic security of the TLS protocol is clearly unaffected
> from sharing the traffic encryption keys with the proxy.

It would be an exceedingly brittle solution to build a system that  
would be cryptographically insecure if proxies added or changed a  
single byte, then insist and hope that proxies never modify the data  

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

That property does not hold for any use of authenticated encryption,  
including that of RFC 5288 or the two drafts using CCM.

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

What I have been told is that there are proxies that don't work that  
way, and it is not realistic to expect them to work that way.   Rather  
than debate that point on the list, let's seek out some objective data.

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

Not using end-to-end message authentication is unconstitutional?   But  
decryption in the middle is OK?

If I rushed to conclusions on this topic, I might think that we are  
violating the constitution because we haven't signed our emails with  
SMIME or PGP.  That can't be right, so apparently a more detailed  
analysis is needed.


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