Re: [TLS] TLS Proxy Server Extension

Martin Rex <> Sat, 30 July 2011 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6410921F8AEA for <>; Fri, 29 Jul 2011 19:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.913
X-Spam-Status: No, score=-9.913 tagged_above=-999 required=5 tests=[AWL=0.336, 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 drOoUz5hRZJq for <>; Fri, 29 Jul 2011 19:31:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D80621F8BA9 for <>; Fri, 29 Jul 2011 19:31:01 -0700 (PDT)
Received: from by (26) with ESMTP id p6U2UwJu003172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jul 2011 04:30:58 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
To: (David McGrew)
Date: Sat, 30 Jul 2011 04:30:57 +0200 (MEST)
In-Reply-To: <> from "David McGrew" at Jul 29, 11 03:24:09 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: Sat, 30 Jul 2011 02:31:03 -0000

David McGrew wrote:
> On Jul 29, 2011, at 1:44 PM, Martin Rex wrote:
> >
> > Matt McCutchen wrote:
> >>
> >> On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote:
> >>> 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"?
> >>>
> >>>
> >>>
> >>> Standardizing MITM attacks on TLS-protected communication
> >>> ("lawful intercept?") seems like an extremely bad idea to me.
> >>
> >> This is not wiretapping as defined in that policy.

On the contrary, it is EXACTLY wiretapping _as_meant_by_rfc2804_.

> Right, it's clearly not wiretapping as per RFC 2804: "Wiretapping is  
> what occurs when information passed across the Internet from one party  
> to one or more other parties is delivered to a third party: 1. Without  
> the sending party knowing about the third party ..."   The intent of  
> the work we are discussing is to ensure that the client knows about  
> the third party.

As Marsh Ray previously pointed out...

...the server might be sending a response, and due to the server
not knowing about the MitM on the communication link to the client
this falls within the description and intent of RFC2804.

In Germany such a TLS proxy will always and unconditionally fall under
the constitutional protection of telecommunications (Art 10 Abs. 1 GG),
unless **ALL** communication parties have consciously agreed.

(it would fall under the less stringent constitutional protection
 of informational self-determination of the sender of information
 when communication contents were leaked only at a rightful
 TLS endpoint as conceived by the information sender,
 which is _still_ a very serious legal problem where I live).

> >
> > I *STRONGLY* disagree.  That is very much about wiretapping and
> > even goes far beyond that, because it not only reveals the content
> > of the communication, it also allows the "TLS proxy" to arbitrarily
> > manipulate the communication in a fashion that might be entirely
> > concealed to the communication peers at the end.
> >
> >
> > I am strongly opposed to have any document describing such proxies
> > published as an RFC!
> And yet you would favor a protocol that propagates decryption keys  
> around the network?

That approach would ensure communication integrity and keep client
certificates functional.  Favour? No, but it is by a huge margin the
lesser evil and the lesser security problem when compared to a
TLS-terminating proxy with a super-CA-equivent keypair that can
fake every server cert and surreptitiously modify all
comunications, which completely precludes control and accountability
through technical/protocol safeguards.

> We don't have a choice about whether or not TLS proxying will be done  
> on the Internet; it is being done.  What we can choose is whether or  
> not the IETF improves how it is being done.

The IETF does not have a choice whether law enforcement does
wiretap, yet it refuses to work on and standarize technology
that provides or facilitates such activities.