Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt

Alissa Cooper <acooper@cdt.org> Thu, 05 July 2012 21:07 UTC

Return-Path: <acooper@cdt.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9B21F854A for <apps-discuss@ietfa.amsl.com>; Thu, 5 Jul 2012 14:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.356
X-Spam-Level:
X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 UdrVcpsnFNRv for <apps-discuss@ietfa.amsl.com>; Thu, 5 Jul 2012 14:07:49 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1236D21F8541 for <apps-discuss@ietf.org>; Thu, 5 Jul 2012 14:07:48 -0700 (PDT)
X-Footer: Y2R0Lm9yZw==
Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 5 Jul 2012 17:08:02 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Alissa Cooper <acooper@cdt.org>
In-Reply-To: <20120705141951.3ef8eec7@hetzer>
Date: Thu, 05 Jul 2012 17:08:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FDC74E3-FB58-4D88-B847-53E9576D14EC@cdt.org>
References: <4FEB2003.9000508@isode.com> <4FF05306.2010301@cs.tcd.ie> <20120704140126.794bf4e2@hetzer> <4FF44705.2000707@cs.tcd.ie> <20120704165602.61d722a9@hetzer> <4FF4AB6B.6090803@cs.tcd.ie> <20120705141951.3ef8eec7@hetzer>
To: Andreas Petersson <andreas@sbin.se>
X-Mailer: Apple Mail (2.1084)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-http-forwarded-04.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2012 21:07:50 -0000

Hi Andreas,

I tend to agree with Stephen that there is no value in saying that hidden proxies' use of this field has "no end-user privacy impact." In fact, it's not even true. Every IP address that gets conveyed has a potential privacy impact, not least because they can be used as the basis for legal information requests. Conveyance of identifiers is obviously not unique to this spec, but that doesn't mean this spec can claim some high ground that all other IP-based protocols cannot.

Also, as far as I can tell my question about the limits on which identifiers can be carried in the header <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05938.html> was not addressed in the text. At the least I would expect caution against the use of permanent, unique identifiers in public network environments. If it's not even possible to say that, then the fact that absolutely any identifier might show up here needs to be called out explicitly.

I still think http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02#section-4 is worth a look, as there are topics in there that deserve a mention here too (e.g., the fact that Forwarded identifiers contribute to end host fingerprinting, certainly more so than direct connections).

Alissa 

On Jul 5, 2012, at 8:19 AM, Andreas Petersson wrote:

> On Wed, 04 Jul 2012 21:45:31 +0100
> Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
>> 
>> Hiya,
>> 
>> Basically agreeing with SM's latest below...
>> ... 
>> 
> 
> Hi,
> 
> I have rewritten the "Privacy Considerations", using parts of your
> suggestions.
> 
> 
> My proposal:
> 
> "In recent years, there has been growing concerns about privacy.
> There is a tradeoff beteween ensuring privacy for users versus
> disclosing information which is useful for debugging and statistics.
> The Forwarded HTTP header field, by design, exposes information that
> some users consider privacy sensitive.
> 
> From an end-user perspective, intermediate proxies in the request path
> are either known or unknown. Hidden proxies using this extension will
> preserve the information of a direct connection, and thus it has no
> end-user privacy impact. Proxies that are known to the end-user,
> such as explicitly configured proxies, using this extention may not
> anonymize the end-user IP address. The possessor of such proxy need
> to consider whether, and how, deploying this extension impacts on
> user privacy.
> 
> An end-user must also be aware of that the users IP address may already
> be forwarded by proxies using the header field X-Forwarded-For, which is
> already wideley used.
> An end-user who want to be anonymus must be aware of these extensions.
> Such end-users must also ensure that the used proxy server, thought
> being anonymizing, in reality is.
> 
> A proxy server that is intended to anonymize the request should not use
> this header field. In cases where the possessor of the proxy want to be
> able to trace where requests came from, but do not want to leak the
> information further, can use the possibility of obfuscating the client
> address."
> 
> 
> Let me know what you think.
> 
> Best regards,
> Andreas
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>