Re: Comments on Explicit/Trusted Proxy

Stephen Farrell <> Sun, 05 May 2013 09:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04B7921F8E59 for <>; Sun, 5 May 2013 02:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a9AIVxwjXQPg for <>; Sun, 5 May 2013 02:08:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B6BB21F8D2C for <>; Sun, 5 May 2013 02:08:34 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UYuvH-0000Kv-CX for; Sun, 05 May 2013 09:07:59 +0000
Resent-Date: Sun, 05 May 2013 09:07:59 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UYuv6-0000IZ-Bz for; Sun, 05 May 2013 09:07:48 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UYuv5-0000dc-7r for; Sun, 05 May 2013 09:07:48 +0000
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1B83BE58; Sun, 5 May 2013 10:07:22 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 15sw1vjDAh3C; Sun, 5 May 2013 10:07:21 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 26ECDBE47; Sun, 5 May 2013 10:07:21 +0100 (IST)
Message-ID: <>
Date: Sun, 05 May 2013 10:07:15 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: Werner Baumann <>
References: <em2a41028e-505a-4d9f-858e-341d3bf5e8d8@bombed> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-2.878, RP_MATCHES_RCVD=-1.154
X-W3C-Scan-Sig: 1UYuv5-0000dc-7r b8eaccbd41eb63826f2dd898fbc5854a
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <>
X-Mailing-List: <> archive/latest/17840
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Briefly, this thread's going on too long...

Corporate MITM'ing may well not amount to wiretap ala
2804. Standardising MTIM'ing does however make 2804
relevant IMO because the standard MITM attack would
be used in that way. The original clipper proposals
had the LEAF field that the client was supposed to (have
to) send, so the fact that something has to happen on
the client doesn't by itself mean the client is aware
of what's going on.

And yes MITM does happen and one could debate where
blame for that ought lie if one wanted (I don't.) The
point is that standardising that makes the Internet
worse, for all approaches I've seen proposed. We're
not in the business of denying reality but nor are we
in the business of rubberstamping all misbehaviours.


On 05/05/2013 09:39 AM, Werner Baumann wrote:
> Am Sat, 04 May 2013 19:34:57 +0100
> schrieb Stephen Farrell <>ie>:
>> No, I'm not insulting anyone nor trying to. I am describing
>> the purported requirements here as mainly-bogus which is
>> pejorative but entirely different and is IMO justified. I
>> think emphasis on the bogosity of the purported requirements
>> is deserved.
>> ...
>> - Possible government mandated MITM attacks on IETF protocols
>> were a major factor in why we ended up with RFC2804. I suggest
>> that's required reading for people proposing work on this
>> topic.
> Definition of Wiretapping from RFC2804:
>    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
>    2. Without any of the recipient parties knowing about the delivery to
>       the third party
>    3. When the normal expectation of the sender is that the transmitted
>       information will only be seen by the recipient parties or parties
>       obliged to keep the information in confidence
>    4. When the third party acts deliberately to target the transmission
>       of the first party, either because he is of interest, or because
>       the second party's reception is of interest.
> An explicit trusted proxy does not meet this definition of wiretapping
> because of condition 1. Whether information is delivered to a third
> party at all depends on the administration of that proxy. End users will
> have to decide whether to trust it or not (which is much more easy done
> than to decide whether to trust some CA or not).
> All participants in this discussion that argued in favor of explicit
> trusted proxies did it to stop a situation where this is done without
> the end user knowing of the interception. The whole point of these
> proposals is to make the user aware of the proxy and to allow the user
> to either agree or deny.
> Start of not trying to insult section:
> Repeating the mantra "Don't open TLS to MITM attacks" is bogus in face
> of the well known fact that TLS is susceptible to MITM attacks
> (mostly due to not trustworthy CAs) and that this weakness is already
> widely exploited.
> Werner