Re: Comments on Explicit/Trusted Proxy

Werner Baumann <> Sun, 05 May 2013 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAA2C21F8FD6 for <>; Sun, 5 May 2013 01:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 23a5Y1-XuapY for <>; Sun, 5 May 2013 01:42:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 531C221F8FBE for <>; Sun, 5 May 2013 01:42:56 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UYuUa-00067o-Oq for; Sun, 05 May 2013 08:40:24 +0000
Resent-Date: Sun, 05 May 2013 08:40:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UYuUM-00064p-5k for; Sun, 05 May 2013 08:40:10 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UYuUK-0000zO-PG for; Sun, 05 May 2013 08:40:10 +0000
Received: from ( []) by (node=mrbap1) with ESMTP (Nemesis) id 0LbQ1i-1UAK2e21uc-00kr9W; Sun, 05 May 2013 10:39:42 +0200
Date: Sun, 5 May 2013 10:39:33 +0200
From: Werner Baumann <>
Message-ID: <>
In-Reply-To: <>
References: <em2a41028e-505a-4d9f-858e-341d3bf5e8d8@bombed> <> <> <>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:gDfARVJE6B0EM7kdU3TLs8OUbG4YohBpCTu6aHqNHH4 UlPl29mjqi2UloQdRXnuKZeMu/jDV5/VM59qTloaqifupQvu8o AsrDKsDhVB+79pkcfKbdYRjtImoXGxNvLoJDPRKa6vzj36sgEa sRYy1OE3hIp4ozWR+/isqTfDZjnwvuDQB62C2fQTJQlBovAxig dVOmaYsOEybD6YfcBRie3T4tyh/Jv+QROHdw8IO72RwvZlWyUR ZTHPgMfjiYVtELkYFreVnZkt0jn+/8+RlDiUBpc/6mls/O1SiK NMqUQ1OtQs7Ll/YyjaBxL19Z+iwKboXjn+vvhU4fe1wA2Wo02J gi2wdFdVqz7Eu3YUPcmMymoK5eihrw8FISzYOP0a4
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001
X-W3C-Scan-Sig: 1UYuUK-0000zO-PG 7bab788feb9e25c4654650f79544a784
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <>
X-Mailing-List: <> archive/latest/17839
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.