Subject: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02

From: SM <[email-masked]>
Date: Wed, 02 May 2012 08:25:05 -0700

Hello,

I have a few comments on draft-ietf-appsawg-http-forwarded-02.  I am 
ignoring the non-privacy angle for now.

In Section 5.5:

   "IANA MUST in such cases be notified, and parameters
    should be registered according to [RFC3864]."

Isn't the "MUST" a little too much?

Section 8.2 discusses about "Information leak".  There is a lack of 
discussion about privacy considerations.  Is the information provided 
by this header field considered as personal identifiable 
information?  Is the leakage only about revealing NAT information and 
proxy setup?  Is this header field only used by internal nodes?

Regards,
-sm

---

From: Andreas Petersson <[email-masked]>
Date: Sun, 13 May 2012 14:12:15 +0200

On 5/2/12 5:25 PM, SM wrote:
> In Section 5.5:
> 
> "IANA MUST in such cases be notified, and parameters should be
> registered according to [RFC3864]."
> 

If someone is writing a document specifying extensions to this
document, and they also want it as an RFC I don't think it is
that strange to demand that they are notifying IANA?

Maybe it however would be better to write something similar to what is
written in httpbis-p2/3.1?

"Extensions are registered using the procedures described in
 [RFC3864]."

> 
> Section 8.2 discusses about "Information leak".  There is a lack
> of discussion about privacy considerations.

Yes, it can be worth adding a note about that too.

> Is the information provided by this header field considered as
> personal identifiable information?

It depends.

> Is the leakage only about revealing NAT information and proxy
> setup?

What information you forward is up to you as the proxy owner. If that
information is "leakage" in matter of privacy, depends on the situation.

> Is this header field only used by internal nodes?

Well, I would see no huge difference between using a proxy that adds
this information and using no proxy at all.
The header field "for" is essentially for non-internal nodes, if you
by "internal nodes" mean nodes belonging to the same organization.

I believe it is hard to write something specific about privacy, but it
is worth mentioning.

regards,
 Andreas

---

From: SM <[email-masked]>
Date: Sun, 13 May 2012 10:07:20 -0700

Hi Andreas,
>that strange to demand that they are notifying IANA?

Requirement language tend to be overused in some documents.

>written in httpbis-p2/3.1?

Yes.

>"Extensions are registered using the procedures described in

That sounds better.

>information is "leakage" in matter of privacy, depends on the situation.

Agreed.

>I believe it is hard to write something specific about privacy, but it

It is generally difficult to come up with text as there isn't much in 
terms of previous work to borrow from.

Web proxies are used for various reasons, e.g. piracy, anonymity, 
etc.  Given that "hostile government" is being considered in threat 
scenarios in some IETF WG, it would be good to have some text about 
that from a privacy angle.

The X-Forwarded-For: header is used in existing implementations to 
pass on the client IP address.  This draft defines "Forwarded: for=" 
as a replacement.  There is already some discussion about information 
leak (Section 8.2) but it only takes into account use cases where the 
nodes belong to the same organization, e.g. there is a proxy in front of a NAT.

I suggest removing Section 6.3.  If you don't want to disclose 
information, don't add the "Forwarded: for" header field.  Adding 
random identifiers ends up providing information about:

  (i)  a proxy is in use (most people in this WG could easily figure 
that out anyway)

  (ii) another means to track down users even though the IP address 
is not being passed

As a starting point, here's some suggested text for Section 8.2:

   In recent years, there has been growing concerns about privacy.  There is a
   tradeoff between ensuring privacy for users versus disclosing information
   which is useful for debugging.  The Forwarded HTTP header field, by design,
   exposes information which affects the privacy of users.  This header field
   should not be used if the proxy is being operated as a privacy service.

If you use a privacy considerations section, the text may have to be 
expanded.  I'll send text if you decide to do that.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 May 2012 10:37:10 +0100

Hi,

Sorry if I'm missing some context here (and I've only
skimmed the document), but I've a couple of questions:

>   should not be used if the proxy is being operated as a privacy service.

- Is "privacy service" well-defined? (Or well enough defined?)

- In general, is a user supposed to know that headers like this
  are being added? If so, how? If not, doesn't that have privacy
  implications as well?

- Section 5.4 is also odd: when would we want a proxy to make it
  look to the UA that stuff the proxy got unprotected was protected?

- I also wondered how widely the X-Forwarded stuff is deployed and
  generally whether its really a good or bad idea to standardise
  this. I can't tell from (the quick read I had of) the document.

Ta,
S.

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 14 May 2012 12:29:54 +0200

On Mon, 14 May 2012 10:37:10 +0100
> - Is "privacy service" well-defined? (Or well enough defined?)

Maybe we can write something like "if the proxy is intended to
anonymize the user" ?

>   are being added? If so, how? If not, doesn't that have privacy

There are lots, and lots of different proxy types and the users needs
special education for each of them. However, this can not be done in
this document.

>   look to the UA that stuff the proxy got unprotected was protected?

It is not uncommon that you have a reverse proxy that do SSL-offload.
This should be of no concern for the user.

>   this. I can't tell from (the quick read I had of) the document.

It has a really wide spread usage in the world of proxying.

 Best regards, 
   Andreas

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 May 2012 12:10:32 +0100

> Maybe we can write something like "if the proxy is intended to

Maybe. Could be a rathole I guess so it may well be better
to say when its ok to use this, rather than when to not use
this, or perhaps some mixture of the two. I'm not sure myself.

> special education for each of them. However, this can not be done in

So you're saying that this is designed to be invisible
to the end user. That may be entirely reasonable but does
have privacy implications, especially if this gets used
in the wrong places or ways.

If this is designed to be invisible to the end-user then
I agree there's no issue for the draft related to educating
users, since the poor user can't ever tell when its happening.

> This should be of no concern for the user.

But that's only reasonable in some use-cases, and is
entirely unreasonable in others, right? (e.g. for
a corporate outbound proxy or an ISP's proxy) Where
does it specify those reasonable use-cases and say
not to do this in other cases?

> It has a really wide spread usage in the world of proxying.

I'd be interested in some references for that, if you have
'em. But assuming this is widely used, then yes, that is an
argument for figuring out how to document it better.

Whether that's a winning argument is another question maybe.
I guess that depends on how well its documented and whether
it'd improve or dis-improve the Internet.

S.

---

From: Andreas Petersson <[email-masked]>
Date: Mon, 14 May 2012 13:45:01 +0200

On Mon, 14 May 2012 12:10:32 +0100

> in the wrong places or ways.

This header field do not really add information but only preserve it. 

> users, since the poor user can't ever tell when its happening.

You complaint is only valid when the user thinks he is using an
anonymizing proxy when he isn't. 

> not to do this in other cases?

This document do not encourage someone to decrypt traffic with no
reason. We can not list all reasonable and non reasonable use cases. 

> it'd improve or dis-improve the Internet.

Well, X-Forwarded-For was introduced by squid. Squid has a significant
market share for proxy servers.
Also, the X-Forwarded-For is also used for Opera Mini, with almost 200M
users we have a significant market share for mobile users, and we
intend to start using the header field described in this document.

Best regards,
 Andreas

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 May 2012 23:22:15 +0100

Hiya,

On 05/14/2012 12:45 PM, Andreas Petersson wrote:
>>>>   implications as wel

Disagree. This adds to the information available one
or more hops away from where the headers are first
added. And doing so invisibly or transparently does have
privacy implications. I see you've proposed adding such
a section which is good. I'll look forward to reading
that carefully.

> You complaint 

Complaint? I was agreeing with you:-)

> is only valid when the user thinks he is using an

The point though is that there's no way for the user
to know that, hence there's no way for the user to
know if their "complaint" is valid or not is there?

IMO, if we standardise that kind of middlebox feature
then there's an onus on us to think about how it might
affect the endpoints, one of which in this case has
a warm body attached often enough to count.  (I think
there was an IAB RFC saying that some time back, can't
recall the number now though, and a quick look didn't
find it sorry.)

Anyway, your privacy considerations will hopefully help.

> reason. We can not list all reasonable and non reasonable use cases. 

You list none at all that I recall. And there are some
bad ways to use some of this, 5.4 in particular and arguably
some of the privacy unfriendly things one could do with this.

I think the draft would be better with at least guidance as to
when its features are reasonable to use and possibly in some
cases some MUST NOT statements. For example, 5.4 might benefit
from a statement that you MUST NOT do this except when you're an
SSL accelerator or equivalent - when else would it ever make
sense to do that? There may be more examples where similar
normative restrictions would make sense.

> intend to start using the header field described in this document.

Thanks. Market share of course is not the same as usage, but
I'm convinced that the X- variant is used and I assume that
other browser/proxy folks would (or will) yell if they dislike
this.

So the remaining question is whether documenting it like this
is a good thing.

S.

PS: The above are just personal opinions, so I'm not talking as
an AD now, but having said that, the question as to whether this
is good or bad generally (not just for folks doing proxies) is
something that I'd be asking when/if this gets to the IESG.

---

From: SM <[email-masked]>
Date: Mon, 14 May 2012 15:51:29 -0700

Hi Stephen,
>- Is "privacy service" well-defined? (Or well enough defined?)

"privacy service" is not defined in the draft.  I could have 
suggested "providing an anonymous service" but that is not 
well-defined as well.  I suggest looking at this in terms of whether 
the wording can be easily understood or else a reference for "privacy 
service" will be needed.

>   are being added? If so, how? If not, doesn't that have privacy

In general, a user does not know that headers like this are being 
added.  They look for a proxy which they believe provides them 
anonymity.  The user relies on word of mouth or what the operators 
advertises on their web site.  I had a sentence (I didn't suggest it) 
about user trust to cover privacy implications.

Section 15.7 of RFC 2616 discusses about proxies and privacy.  It's 
written from a HTTP perspective.

>   look to the UA that stuff the proxy got unprotected was protected?

That's the reverse proxy scenario.  The information is exchanged 
between the user agent and the reverse proxy over SSL.  As the origin 
server is in a trusted environment, you can do away with the SSL 
overhead if it is expensive.

>   this. I can't tell from (the quick read I had of) the document.

Squid, a web known proxy which is widely deployed adds, an 
X-Forwarded-For: header.  There are configuration knobs to turn that off.

Whether it is a good or bad idea to standardize this header is a 
matter of religion. :-)  We could look at this in terms of consent model.

   (a) User -> web site

   (b) User -> proxy -> web site

In (a) the user communicates directly with the web site.  We cannot 
"hide" the IP address as that is needed for the communication 
protocol to work and there is indirect user consent.  In (b), the 
user consent is up to the proxy.  The User's IP address is not needed 
for communication between proxy and web site.  One can argue that the 
proposal violates that model.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 14 May 2012 16:07:31 -0700

Hi Stephen,
>recall the number now though, and a quick look didn't

It's related to the OPES work (RFC 3238).  That RFC introduced the 
notion of one-party consent.  Given existing legislation, e.g. EU 
directive about privacy, this is not simply a matter of adding a header.

Regards,
-sm

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 15 May 2012 01:20:46 +0100

> other browser/proxy folks would (or will) yell if they dislike

Our proxy implementation enables X-Forwarded-For by default, I believe every proxy implementation that has someone (semi-regularly) active in HTTPBIS implements it too.

> So the remaining question is whether documenting it like this

Depends on what you mean by good thing. Is it a good thing to have a written spec to aid implementation interoperability and clean up X-Fordwarded-For, IMO yes.

Is it a good thing for the Internet? That's a layer 9 discussion but the outcome won't prevent folks using this (or continuing to use X-Forwarded-*)

Ben

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 17 May 2012 17:29:02 -0400

Hi Andreas, 

I've included below a version of some privacy text that I provided in section 4 of draft-ietf-intarea-nat-reveal-analysis, adapted for the Forwarded header. Since the privacy implications are so similar, I thought it might make sense to re-use this in some form; feel free to use or tweak as you wish. I have some further notes below.

-----

Privacy Considerations

   The use of web proxies is motivated by a number of different factors.
   While many individual users are unaware of and
   uninvolved in decisions about whether their HTTP traffic passes through one or more proxies, some users realize privacy
   benefits associated with proxy use, and some may even take
   steps to ensure that an anonymizing proxy sits between them and the
   public Internet.  Shared  or anonymizing proxies can make the actions of multiple users
   behind the proxy unattributable to any single host, creating
   room for abuse but also providing some identity protection for non-
   abusive users who wish to transmit data with reduced risk of being
   uniquely identified.

   The Forwarded extension potentially adds a measure of uniqueness
   back to hosts behind proxies.  The extent of that
   uniqueness depends on which information is included in the Forwarded header. [Insert further discussion of uniqueness here if any identifiers other than IP address and port are reasonably expected to be forwarded. See note 1 below.]

   When the Forwarded extension is used to forward a user agent's IP address, the volatility of the header information is the same as the volatility of the user agent's IP address: the information in the header may change when the user agent's IP address changes.  User agents with persistent IP addresses will be persistently trackable by any recipient of the Forwarded header.

   As a general matter, the Forwarded extention does not seek to make hosts
   any more identifiable than they would be if their traffic were not passing through a proxy. [Wondering if there are corner cases here. See note 2 below.]

   The trust placed in the information conveyed by the Forwarded extension is likely
   to be the same as for current practices with source IP addresses.  In
   that sense, a forwarded IP address can be spoofed.  Furthermore, users of anonymous proxies may be capable of stripping forwarded
   information before it reaches its destination.

-----

Notes:

1. Section 5.2 says that the typical value of the forwarded-for parameter is an IP address but that it MAY be some other kind of identifier. What other identifiers might it be? Are there any identifiers that should be taken off the table (e.g., subscriber IDs, MAC addresses, credit card numbers)? Obviously some of these are more likely to have value than others but I think it's important to scope this if possible. Just because a proxy may know some persistent host identifier doesn't mean it should be forwarded around in an HTTP header.

2. I'm wondering if, in addition to the information leak problem discussed in 8.2, there is also an issue of distinguishability of multiple users who are all behind the same NAT/proxy but may not all be behind the same chain of proxies. That is, suppose A and B are the only two hosts behind a particular NAT and A installed the NAT to help protect his identity. B's traffic passes through 2 further proxies that use Forwarded headers before arriving at C. A's traffic passes through no proxies to arrive at C. C can now effectively identify A. This is just one case -- I'm not sure how realistic it is, but I'm sure there are others. Seems like this is worth more thought/discussion in the text.

3. In general it seems like somewhere -- not sure if it should be here, or in the nat-reveal draft, or somewhere else -- the interactions between different mechanisms for IP address hiding and sharing need to be addressed. For example, if my request goes through multiple middleboxes that implement the TCP option for nat-reveal (http://tools.ietf.org/html/draft-wing-nat-reveal-option-03) and then hits an HTTP proxy, can I expect the proxy to take my IP address out of the TCP option and insert it into a Forwarded header? If I want to hide my IP address from the combination of these mechanisms, what do I need to do?

4. It might be helpful to take a look through <http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-5> -- I haven't had time to think through all the questions listed.

Cheers,
Alissa  

On May 14, 2012, at 7:07 PM, SM wrote:

> It's related to the OPES work (RFC 3238).  That RFC introduced the notion of one-party consent.  Given existing legislation, e.g. EU directive about privacy, this is not simply a matter of adding a header.
> 
> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Thu, 17 May 2012 15:39:24 -0700

Hi Alissa,
At 14:29 17-05-2012, Alissa Cooper wrote:
>    any more identifiable than they would be if their traffic were 
> not passing through a proxy. [Wondering if there are corner cases 
> here. See note 2 below.]
>
>    that sense, a forwarded IP address can be spoofed.  Furthermore, 
> users of anonymous proxies may be capable of stripping forwarded

With all due respect I beg to disagree about this.  There are cases 
when the proxy is selected by the user so that their host is not 
identifiable.  The user is intentionally trying not to have the 
client host identified.

The spoofing is an interesting point.  The user agent could add the 
relevant header.  That can be traced though.  User agents, by 
default, may not offer such functionality.

How can users of anonymous proxies strip forwarded information before 
it reaches its destination?

>2. I'm wondering if, in addition to the information leak problem 
>discussed in 8.2, there is also an issue of distinguishability of 
>multiple users who are all behind the same NAT/proxy but may not all 
>be behind the same chain of proxies. That is, suppose A and B are 
>the only two hosts behind a particular NAT and A installed the NAT 
>to help protect his identity. B's traffic passes through 2 further 
>proxies that use Forwarded headers before arriving at C. A's traffic 
>passes through no proxies to arrive at C. C can now effectively 
>identify A. This is just one case -- I'm not sure how realistic it 
>is, but I'm sure there are others. Seems like this is worth more 
>thought/discussion in the text.

The NAT case is different as the user cannot affect "chaining" unless 
he/she has control over the infrastructure.

Web Proxy chaining is used in an attempt to make it more difficult to 
"trace back" to the client.  There can be multiple proxy hops, which 
the user does not operate, before the destination is reached.

Regards,
-sm

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 18 May 2012 17:45:40 +0200

Hi.

Comments inlined.

On 5/17/12 11:29 PM, Alissa Cooper wrote:
> Hi Andreas,
> 
> I've included below a version of some privacy text that I provided
> in section 4 of draft-ietf-intarea-nat-reveal-analysis, adapted for
> the Forwarded header. Since the privacy implications are so
> similar, I thought it might make sense to re-use this in some form;
> feel free to use or tweak as you wish. I have some further notes
> below.
> 

Thanks for your text. We will consider this when we write our privacy
considerations section.

> 
> Notes:
> 
> 1. Section 5.2 says that the typical value of the forwarded-for
> parameter is an IP address but that it MAY be some other kind of
> identifier. What other identifiers might it be? Are there any
> identifiers that should be taken off the table (e.g., subscriber
> IDs, MAC addresses, credit card numbers)? Obviously some of these
> are more likely to have value than others but I think it's
> important to scope this if possible. Just because a proxy may know
> some persistent host identifier doesn't mean it should be forwarded
> around in an HTTP header.

Essentially, any token you like that fits in the obf-node. What this
translates depends highly on the environment.
Of course some things are more suitable than others to use as
identifier. Putting a credit card number there and send it around the
Internet seems stupid. I don't believe someone will do that, and if
they would, the would do it regardless of this header field.

> multiple users who are all behind the same NAT/proxy but may not
> all be behind the same chain of proxies. That is, suppose A and B
> are the only two hosts behind a particular NAT and A installed the
> NAT to help protect his identity. B's traffic passes through 2
> further proxies that use Forwarded headers before arriving at C.
> A's traffic passes through no proxies to arrive at C. C can now
> effectively identify A. This is just one case -- I'm not sure how
> realistic it is, but I'm sure there are others. Seems like this is
> worth more thought/discussion in the text.
> 

This sounds very confused.
C can probably also distinguish A from client headers. Installing a
NAT in order to protect his identity seems also very strange (with
that few users).

> 3. In general it seems like somewhere -- not sure if it should be
> here, or in the nat-reveal draft, or somewhere else -- the
> interactions between different mechanisms for IP address hiding and
> sharing need to be addressed. For example, if my request goes
> through multiple middleboxes that implement the TCP option for
> nat-reveal
> (http://tools.ietf.org/html/draft-wing-nat-reveal-option-03) and
> then hits an HTTP proxy, can I expect the proxy to take my IP
> address out of the TCP option and insert it into a Forwarded
> header? If I want to hide my IP address from the combination of
> these mechanisms, what do I need to do?
> 

I don't think you can expect anything. The fact is that a lot of
proxies are already adding X-Forwarded-For header field though. This
is only a formal specification of that, with extra features.

If you weren't using any proxy at all, you can't hide your address, of
course. So if you use a proxy, that is not under your control, it is
likely that the proxy administrator do not want to hide your real
address. If he hides your address it is more likely he gets more
abuse-cases etc.
However, if he is aware of that, and want to provide you an
anonymizing service, he can just choose not to add any Forwarded-header.

So, if you do not want your address to be revealed after a proxy, make
sure that you use a proxy that has the purpose of being anonymizing.
You must also make sure that you trust the administrator of that proxy
not to leak logs files etc in any other way.

> 4. It might be helpful to take a look through
> <http://tools.ietf.org/html/draft-iab-privacy-considerations-02#section-5>
> -- I haven't had time to think through all the questions listed.

I don't think that really apply here, since the intention is not to
add information that would be unknown if no proxy were used at all.

Cheers,
 Andreas

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 21 May 2012 09:42:49 -0400

Hi Andreas,

A few responses inline.

> they would, the would do it regardless of this header field.

So, is there some recommendation you can make to limit the scope of identifiers? Or to caution against the use of permanent, unique identifiers in public network environments?

> is only a formal specification of that, with extra features.

Obviously people will implement and use all kinds of features as they wish, but the formal specification phase is often a good time to assess the consequences of widespread implementation and use.  If discussing those consequences here causes some implementers and users to be more thoughtful about the privacy impact of what they do, that's an additional benefit of standardization.

Alissa