Re: [apps-discuss] Last Call: <draft-ietf-appsawg-http-forwarded-06.txt> (Forwarded HTTP Extension) to Proposed Standard
Alissa Cooper <acooper@cdt.org> Mon, 09 July 2012 18:27 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 2681811E811E; Mon, 9 Jul 2012 11:27:29 -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 g1tAXrdxrOcO; Mon, 9 Jul 2012 11:27:28 -0700 (PDT)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CE11E8119; Mon, 9 Jul 2012 11:27: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)); Mon, 9 Jul 2012 14:27:51 -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: <20120709162848.23418.51856.idtracker@ietfa.amsl.com>
Date: Mon, 09 Jul 2012 14:27:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <22B6DCC8-3BBF-4C64-876E-13ABFBE6CB2F@cdt.org>
References: <20120709162848.23418.51856.idtracker@ietfa.amsl.com>
To: IETF Discussion Mailing List <ietf@ietf.org>
X-Mailer: Apple Mail (2.1084)
Cc: 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: Mon, 09 Jul 2012 18:27:29 -0000
(incorporating some responses to http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html as a LC comment) It would be helpful if this document could further motivate the need for proxies to generate static obfuscated tokens. These two lines in particular, from 6.3 and 8.3, respectively, seem a bit weak: "The identifiers can be randomly generated for each request and do not need to be statically assigned to resources." "When using such tokens, a static token per user would increase the possibility for external organizations to track separate users." Is it possible to recommend that generated tokens have limited lifetimes (per-request or otherwise), and make the static case the exception? 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. Alissa On Jul 9, 2012, at 12:28 PM, The IESG wrote: > > The IESG has received a request from the Applications Area Working Group > WG (appsawg) to consider the following document: > - 'Forwarded HTTP Extension' > <draft-ietf-appsawg-http-forwarded-06.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-07-23. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document standardizes an HTTP extension header field that allows > proxy components to disclose information lost in the proxying > process, for example, the originating IP address of a request or IP > address of the proxy on the user-agent-facing interface. Given a > trusted path of proxying components, this makes it possible to > arrange it so that each subsequent component will have access to, for > example, all IP addresses used in the chain of proxied HTTP requests. > > This document also specifies guidelines for a proxy administrator to > anonymize the origin of a request. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > ==================================== > A specific point for Last Call discussion, please: > During AD Evaluation, the registration policy for the new "HTTP > Forwarded parameters" registry (see Section 9) was changed to > "Specification Required" from "RFC Required". This needs further > review during Last Call, for two reasons: > > 1. While RFC Required forces new registrations through the IETF RFC > process, and might discourage registrations from individuals or > organizations that are unfamiliar with or averse to that process, > Specification Required necessitates the appointment of a Designated > Expert to review the requests and associated specifications. Each of > these policies comes with baggage, and we have to make sure we're > weighing it down with the *right* baggage. > > 2. If we stay with Specification Required we should include a short > paragraph with rough guidelines for the Designated Expert: what to > consider when approving registration requests. If we want the DE to > approve most requests, just checking the associated specifications for > sanity, we need to say that. If we want the DE to put some judgment > into deciding whether the requested parameters make sense and fit into > the usage model, or whatever, we should say something about that. > Comments and proposed text for this are encouraged. > ==================================== >
- [apps-discuss] Last Call: <draft-ietf-appsawg-htt… The IESG
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Alissa Cooper
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… SM
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Stephen Farrell
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Willy Tarreau
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Alissa Cooper
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Alissa Cooper
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… SM
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… SM
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Andreas Petersson
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Alexey Melnikov
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Murray S. Kucherawy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Barry Leiba
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Mark Nottingham