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

From: The IESG <[email-masked]>
Date: Mon, 09 Jul 2012 09:28:48 -0700

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
[email-masked] mailing lists by 2012-07-23. Exceptionally, comments may be
sent to [email-masked] 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.
====================================

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 9 Jul 2012 14:27:49 -0400

(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

---

From: SM <[email-masked]>
Date: Mon, 09 Jul 2012 13:59:43 -0700

At 11:27 09-07-2012, Alissa Cooper wrote:
>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.

Yes.

>It's also worth noting that the second statement above is equally 
>true for statically provisioned client IP addresses.
>

I suggest removing that statement.  The wording is not entirely 
clear.  I read it as diluting end-user privacy impact.

In Section 6.3:

   'To distinguish the obfuscated identifier from other identifiers,
    it MUST have a leading underscore "_".'

I suggest removing the requirement and using "can".  The implementer 
can decide what to put in that field.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jul 2012 22:48:59 +0100

So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.

With geopriv, we've gone to a lot of trouble to
support end-users having some control over their
location privacy.

This HTTP header will be used by proxies to forward
on the IP address of a client, and that will be used
via geo-ip services to locate the HTTP client.

But in this case, there's no control whatsoever
for the end user, nor are they even told that
its happened.

That seems to me to be quite a disconnect, but
I'm not sure what if anything ought be done about
it, since in this case, there's a non-standard
header that's widely deployed that does this.

So if we did try encourage taking the geopriv
approach we'd presumably just be ignored.

Any ideas?

Ta,
S.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 10 Jul 2012 08:09:12 +0200

> via geo-ip services to locate the HTTP client.

In practice, the real use for the header is in the reverse-proxy chain,
as many people already disable x-forwarded-for on outgoing proxies for
privacy concerns. And server-side generally ignores the untrustable
x-forwarded-for provided by clients anyway. In the abstract, the draft
says it's for use between trusted proxies, which generally means either
the client-side proxy chain for logging purposes, where the last one
will remove the info, or more generally the server side where everyone
appends itself.

Maybe a small paragraph on this might emphasize the intended purpose
and suggest use cases as well as software options to add/ignore/remove
the header depending on the proxy location in the chain.

Regards,
Willy

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 10 Jul 2012 13:27:56 +0200

On Mon, 9 Jul 2012 14:27:49 -0400

>    possibility for external organizations to track separate users."

Well, I think it gives a good hint to use dynamically assigned tokens.

> Is it possible to recommend that generated tokens have limited lifetimes (per-request or otherwise), and make the static case the exception?

I guess so.

> 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.
> 

Can you give some proof or at least some arguments for this statement?

Cheers,
 Andreas

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 10 Jul 2012 13:28:25 +0200

On Mon, 09 Jul 2012 13:59:43 -0700
> clear.  I read it as diluting end-user privacy impact.

I interpret it the other way around. 
It makes a deployer aware that there is also end user expectations
to take into considerations.
Removing it may work as well, but I think that less well reflects the
discussion on the apps-list.

> can decide what to put in that field.

I think that will make parsing harder, and give no benefit at all.

Cheers,
 Andreas

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 10 Jul 2012 13:28:33 +0200

On Mon, 09 Jul 2012 22:48:59 +0100

> support end-users having some control over their

 "Location Object (LO):   An object used to convey location
 information together with Privacy Rules.  Geopriv supports both
 geodetic location data (latitude, longitude, altitude, etc.) and civic
 location data (street, city, state, etc.).  Either or both types
 of location information may be present in a single LO (see the
 considerations in [5] for LOs containing multiple locations).
 Location Objects typically include some sort of identifier of the
 Target."

I'm not really sure that an IP address fits into that description.
If the geopriv thought that an IP address is a LO, they should have
written so in the document.

But more important; I think it would be really unfortunate if the
IETF would encourage people to use IP addresses as location objects, it
is done already, and it works bad and breaks lot of stuff.

> via geo-ip services to locate the HTTP client.

IP addresses are also forwarded by ISP's routers, I am not
convinced about the big difference here.
It may also be relevant to note that a proxy may not proxy
HTTPS-requests, so in those cases it would be enough to
inline an element served over HTTPS to get the client IP address.
Is that also a privacy issue?

> for the end user, nor are they even told that

Since it is non-trivial for end users to protect their privacy, I think
education of the end users are the only way to go.
This education is, however, not within the scope of this document.

My point is: privacy and anonymization is hard and hairy, and an
uneducated end user will "never" get this right.

Yes.

Cheers,
 Andreas

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 10 Jul 2012 14:08:24 +0200

On Mon, 09 Jul 2012 09:28:48 -0700

> Comments and proposed text for this are encouraged.

After some discussion with Barry, he suggested the following text:

"To keep the registration process uncomplicated and to encourage
parameters that are in use to be registered, the designated expert
should set a low bar for new registrations, confirming mostly that the
specification is reasonably stable, readily available, and sufficient
to create interoperable implementations.  The parameter name ought to
make sense for the requested usage, being short but sufficiently
specific.  The specification needs to comply with this document and
the general HTTP specifications, and should address security and
privacy implications of the requested parameter."

I think that sounds good so that is what I suggest that we go with.

Cheers,
 Andreas

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 10 Jul 2012 10:54:53 -0400

Hi Andreas,

> 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

---

From: Andreas Petersson <[email-masked]>
Date: Tue, 10 Jul 2012 18:07:29 +0200

On Tue, 10 Jul 2012 10:54:53 -0400

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

I interpret the statement "which has an end-user privacy impact" to be
true if any of "end user" or "deployer" does not know about it.
So that should cover the case when the deployer knows, but not the end
user.

> 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 rec…

Thanks for explaining.

Yes, I can agree on this.
I do not think that this header changes real life affect on end users
privacy very much, though.
The big issue here is that there is quite a lot of things that the end
user are aware of.

> 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…

See my answer to SM. I think it better explains that the expectations
of the end user are important to consider, even if these expectations
are wrong.

I don't think that text will have much impact on how the header field
is used in practice though, or any technical impact, so removing it is
fine with me.

It would be interesting to hear what Stephen Farrell thinks about it,
since he wrote that text.

Cheers,
 Andreas

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 10 Jul 2012 12:32:08 -0400

> of the end user are important to consider, even if these expectations

Right, I'm not saying that user expectations are unimportant. I think characterizing their role accurately should be the goal. If there is a desire to leave this in, I would suggest something more along the lines of:

Proxies using this extension will preserve the information of a direct connection. In some cases, the user's and/or deployer's knowledge or expectation that this will occur can help to mitigate the associated privacy impact.

> is used in practice though, or any technical impact, so removing it is

Even if that's the case having accurate documentation of the privacy implications can't hurt.

Alissa

---

From: SM <[email-masked]>
Date: Tue, 10 Jul 2012 08:43:43 -0700

Hi Andreas,
>discussion on the apps-list.

There is a thread at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06592.html 
of the working group discussions.  There were views from three 
persons.  I am in agreement with Alissa on that text.  I'll "+1" her 
message at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06664.html

>I think that will make parsing harder, and give no benefit at all.

It allows for more random bits of information.

Regards,
-sm

---

From: Andreas Petersson <[email-masked]>
Date: Wed, 11 Jul 2012 15:41:58 +0200

On Tue, 10 Jul 2012 08:43:43 -0700

> It allows for more random bits of information.

(adding context again)

Hi,

Can you substantiate a bit on this statement?
How is it "random bits of information" when the specifications says
that it MUST be underscore?

As far as I can think of, the only thing that it will tell is that the
implementation is following this specification.
So, on the contrary; the more "degrees of freedom" that is given to the
implementation, the easier it would be to do fingerprinting.

Cheers,
 Andreas

---

From: Andreas Petersson <[email-masked]>
Date: Wed, 11 Jul 2012 16:41:11 +0200

On Tue, 10 Jul 2012 12:32:08 -0400

> Proxies using this extension will preserve the information of a direct connection. In some cases, the user's and/or deployer's knowledge or expectation that this will occur can help to mitigate the…

Off-list discussion with Alissa resulted in this suggestion:

"Proxies using this extension will preserve the information of a direct
connection. This has an end-user privacy impact regardless of whether
the end-user or deployer knows or expects that this is the case."

Cheers,
 Andreas

---

From: SM <[email-masked]>
Date: Wed, 11 Jul 2012 16:48:19 -0700

Hi Andreas,
>implementation, the easier it would be to do fingerprinting.

I could use a hash.  If the hash has to begin with an underscore, I 
have to reserve storage space for it.  The ease for fingerprinting 
depends on how Section 6.3 is implemented (see reference I posted on 
WG mailing list about browser identification).  I am ok if you want 
to keep the requirement.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Sat, 28 Jul 2012 02:15:37 -0400

The last call for this document is over, but we still need comments on
one thing.

I put the following in the last call announcement:

We had last call comments about other things, but nothing on this.  We
shouldn't just be picking a registration policy arbitrarily, without
discussion in the working group of what the *right* policy is.  Let's
have a bit of discussion on this point before the document moves
ahead.  I'm leaving it in "Waiting for AD Go-Ahead" state for now.

Barry

---

From: Andreas Petersson <[email-masked]>
Date: Sun, 29 Jul 2012 01:51:15 +0200

On 7/28/12 8:15 AM, Barry Leiba wrote:
> The last call for this document is over, but we still need
> comments on one thing.
> 
> 
> [...]
> 
> We had last call comments about other things, but nothing on this. 
> We shouldn't just be picking a registration policy arbitrarily, 
> without discussion in the working group of what the *right* policy 
> is.  Let's have a bit of discussion on this point before the 
> document moves ahead.  I'm leaving it in "Waiting for AD Go-Ahead" 
> state for now.
> 

Just a reminder, I did send this during the LC:
http://www.ietf.org/mail-archive/web/ietf/current/msg73929.html

Cheers,
 Andreas

---

From: Barry Leiba <[email-masked]>
Date: Sat, 28 Jul 2012 19:54:16 -0400

> http://www.ietf.org/mail-archive/web/ietf/current/msg73929.html

Indeed you did, Andreas; sorry: I meant that no one else commented pro
or con about it.  I'd like to get some sense that someone other than
us is happy with this (or is not).

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Jul 2012 07:33:10 -0700

> I put the following in the last call announcement:

I think Specification Required would be better here, so I support this change.