IETF Logo Mail Archive

Re: [apps-discuss] Last Call: <draft-ietf-appsawg-http-forwarded-06.txt> (Forwarded HTTP Extension) to Proposed Standard

Alissa Cooper <acooper@cdt.org> Tue, 10 July 2012 14:54 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 001C911E8088; Tue, 10 Jul 2012 07:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.373
X-Spam-Level:
X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 kyAz-EizSDH1; Tue, 10 Jul 2012 07:54:30 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 31B3111E807F; Tue, 10 Jul 2012 07:54:28 -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)); Tue, 10 Jul 2012 10:54:54 -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: <20120710132756.4dac582d@hetzer>
Date: Tue, 10 Jul 2012 10:54:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C023E9BE-5183-4A36-8470-B206FFBF1746@cdt.org>
References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com> <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org> <20120710132756.4dac582d@hetzer>
To: Andreas Petersson <andreas@sbin.se>
X-Mailer: Apple Mail (2.1084)
Cc: IETF Discussion Mailing List <ietf@ietf.org>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-http-forwarded-06.txt> (Forwarded HTTP Extension) to Proposed Standard
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: Tue, 10 Jul 2012 14:54:32 -0000

Hi Andreas,

On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
>> The first statement above gets at this, but it seems to me that the
>> middle ground between random generation per request and permanent
>> unique token is worth emphasizing if there will be proxies that want
>> to keep per-client identifiers around for some limited amount of time
>> that isn't forever.
>> 
>> It's also worth noting that the second statement above is equally true for statically provisioned client IP addresses.
>> 
>> Also, this statement in 8.3 is not really true and probably better left out:
>> 
>> "Proxies using this extension will preserve the information of a
>>   direct connection, which has an end-user privacy impact, if the end-
>>   user or deployer does not know or expect that this is the case."
>> 
>> There can certainly be a privacy impact whether the user or deployer has awareness/expectation or not. 
> 
> Can you give some proof or at least some arguments for this statement?
> 

If the deployer has awareness/expectation but users do not, then users' expectations that their client addresses will not be shared will be violated.

But even if users have awareness/expectation that their client addresses will be shared, the implications of that sharing may not be obvious, and there is nothing preventing remote servers that receive the information from abusing it. Examples: a user who doesn't know that his address is static and can be used by a remote server to track and correlate all of his activity; a user who doesn't know that his ISP maintains records of customer identity tied to client addresses that may become subject to law enforcement request; a service that combines static addresses or tokens received via the header with other collected identifiers and shares them with other servers to enable more pervasive tracking.

The first half of the statement is basically a refinement of the previous sentence in the section ("The Forwarded HTTP header field, by design, exposes information that some users consider privacy sensitive"), so I don't see what is lost by eliminating it.

Alissa    

> 
> Cheers,
> Andreas

v2.23.0 | Report a Bug | By Email