Re: Comments on Explicit/Trusted Proxy
Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 05 May 2013 09:08 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7921F8E59 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 5 May 2013 02:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9AIVxwjXQPg for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 5 May 2013 02:08:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6BB21F8D2C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 5 May 2013 02:08:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYuvH-0000Kv-CX for ietf-http-wg-dist@listhub.w3.org; Sun, 05 May 2013 09:07:59 +0000
Resent-Date: Sun, 05 May 2013 09:07:59 +0000
Resent-Message-Id: <E1UYuvH-0000Kv-CX@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1UYuv6-0000IZ-Bz for ietf-http-wg@listhub.w3.org; Sun, 05 May 2013 09:07:48 +0000
Received: from mercury.scss.tcd.ie ([134.226.56.6]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1UYuv5-0000dc-7r for ietf-http-wg@w3.org; Sun, 05 May 2013 09:07:48 +0000
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C1B83BE58; Sun, 5 May 2013 10:07:22 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15sw1vjDAh3C; Sun, 5 May 2013 10:07:21 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.44.72.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26ECDBE47; Sun, 5 May 2013 10:07:21 +0100 (IST)
Message-ID: <51862143.1000207@cs.tcd.ie>
Date: Sun, 05 May 2013 10:07:15 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <werner.baumann@onlinehome.de>
CC: ietf-http-wg@w3.org
References: <em2a41028e-505a-4d9f-858e-341d3bf5e8d8@bombed> <5184E317.6070903@cs.tcd.ie> <CAP+FsNffGxaD3L2Ra8b_vqObO9X-FqELLO5g0cYM=uHFL0_yhQ@mail.gmail.com> <518554D1.7020901@cs.tcd.ie> <20130505103933.4ccf0ef5@ginster.fritz.box>
In-Reply-To: <20130505103933.4ccf0ef5@ginster.fritz.box>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=134.226.56.6; envelope-from=stephen.farrell@cs.tcd.ie; helo=mercury.scss.tcd.ie
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: maggie.w3.org 1UYuv5-0000dc-7r b8eaccbd41eb63826f2dd898fbc5854a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <http://www.w3.org/mid/51862143.1000207@cs.tcd.ie>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17840
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=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. S. On 05/05/2013 09:39 AM, Werner Baumann wrote: > Am Sat, 04 May 2013 19:34:57 +0100 > schrieb Stephen Farrell <stephen.farrell@cs.tcd.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 >
- Reminder: Call for Proposals - HTTP/2.0 and HTTP … Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Willy Tarreau
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Willy Tarreau
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Re: Reminder: Call for Proposals - HTTP Authentic… Mark Nottingham
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP Authentic… Mark Nottingham
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- RE: Reminder: Call for Proposals - HTTP Authentic… Markus.Isomaki
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Fabian Keil
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Albert Lunde
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Benjamin Carlyle
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Werner Baumann
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy