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

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Jul 2012 14:56:16 +0200

On 2012-06-27 17:00, Alexey Melnikov wrote:
> Dear WG participants,
>
> The Working Group Last Call for this document has ended and there were a
> couple of updates to it to address issues (-03 and -04). I believe all
> issues were addressed, but it would be good for the WG to check the
> latest version and confirm that. If one of your issues is not addressed
> (and especially if it wasn't replied to), please let me know.
>
> In the meantime, I've started working on the shepherding write-up before
> asking our AD Barry to review and initiate IETF Last Call for the document.
>
> Thank you,
> Alexey, as an APPSAWG co-chair.
> ...

I had a quick look at 
<http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-05>, and 
the only thing I noticed was in the ABNF in Section 4:

        Forwarded   = Forwarded-v
        Forwarded-v = 1#forwarded-element

This is probably an artefact of the changes we made, and isn't 
consistent with the style in HTTPbis; so I'd prefer to simplify that to:

        Forwarded   = 1#forwarded-element

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 01 Jul 2012 14:39:18 +0100

> asking our AD Barry to review and initiate IETF Last Call for the document.

I've only looked at 8.3, but I believe the privacy considerations
section is wrong when it says that standardising this has no new
privacy impact.

One argument given is that a direct connection would expose the
client IP anyway, but that's not comparing this proposal against
today's reality, which ought to be the point.

I also think the text in that section seems to be trying to sell
this as having no privacy impact, and I just don't think that is
the case.

S

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 02 Jul 2012 17:13:55 +0100

Hi Stephen,

> this as having no privacy impact, and I just don't think that is

Can you suggest some specific text or at least reraise this issue during 
IETF LC?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Jul 2012 17:18:53 +0100

> Can you suggest some specific text or at least reraise this issue during

Fair question.

I can raise it during IETF LC, sure. Not sure if I'll get a chance
to draft proposed text, but if I do, I will;-)

Cheers,
S.

---

From: SM <[email-masked]>
Date: Mon, 02 Jul 2012 13:54:38 -0700

Hi Alexey,
At 08:00 27-06-2012, Alexey Melnikov wrote:
>The Working Group Last Call for this document has ended and there 
>were a couple of updates to it to address issues (-03 and -04). I 
>believe all issues were addressed, but it would be good for the WG 
>to check the latest version and confirm that. If one of your issues 
>is not addressed (and especially if it wasn't replied to), please let me know.

I responded to a message from Alissa Cooper ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05908.html 
).  I should have mentioned that it is a comment about the draft.  I 
don't consider the issue as addressed in draft-ietf-appsawg-http-forwarded-05.

If I recall correctly, I did "send text" previously about this.

Regards,
-sm

---

From: Andreas Petersson <[email-masked]>
Date: Wed, 4 Jul 2012 14:01:26 +0200

On Sun, 01 Jul 2012 14:39:18 +0100
> today's reality, which ought to be the point.

If you, as a user, bother to find out whether the proxy is anonymizing
or not, you can not know that now either.
A proxy that is appending "Forwarded" do that because it do not want to
anonymize user. If that is the desire, the proxy may already append
X-Forwarded-For, which is really widespread.
Also, if the intention of the proxy isn't to anonymize, the owner may
also give out logfiles to untrusted parties as well.

Do you believe that "todays reality" is that you can go and seek up a
proxy, that you know nothing about, browse through it, and trust that
it will anonymize your requests? Even if the proxy owner doesn't call
the proxy "anonymizing"?

As said, X-Forwarded-For does already exists and is implemented in
all large proxy-servers, so this is nothing new, it is only a
standardization of that.

I don't think this document is the place for guidelines, neither for
how to set up an anonymizing proxy, nor how to browse the web in an
anonymous way.

> this as having no privacy impact, and I just don't think that is

I do not see what that impact would be really. Please explain when this
specification have an impact, compared to todays reality.

Do you suggest that we should advise people not use this at all? It may
be a nice thought, but I think it is far to idealistic. Unfortunately,
such a proxy-service would be abused for a lot of things. So most
people do not want to run such a service, and lots of network owners
wouldn't like to host it, etc.

> section is wrong when it says that standardising this has no new

I do not entirely agree with you here. But I notice that there are more
support for this opinion, so lets try to come up with something.

This is the text SM sent:
( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05774.html
 SM, correct me if I'm wrong).

   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.

This header field is not only for debugging, so that should
probably be expanded. Something else that should be added?
I do think that the text should say something about the current use of
similar header fields though, otherwise it may look like everything is
fine unless you don't use this, which is not true.
Users should also be aware of all other different headers and cookies
that their browsers sends out, so they can be identified by those too,
but mentioning that here seems out of scope to me.

Best regards,
 Andreas

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jul 2012 14:37:09 +0100

Hi Andreas,

> or not, you can not know that now either.

I can't really parse the above sorry.

> X-Forwarded-For, which is really widespread.

I think that needs to be clear in 8.3.

> it will anonymize your requests? Even if the proxy owner doesn't call

No I don't. But direct connections are not today's reality
which is what's implied by the current 8.3.

> specification have an impact, compared to todays reality.

Presumably the reason to standardise this is so that more proxies
will do it this way. That reduces privacy to some extent unless
nobody adopts this.

> wouldn't like to host it, etc.

I didn't suggest that. I'm asking for truth in advertising.

> probably be expanded. Something else that should be added?

Depends on what else its used for I guess. If there are other
(non-obvious uses) with privacy implications then those should
I guess be mentioned. Not sure myself. (I'm assuming this
information is mostly fed into the marketing machine.)

> fine unless you don't use this, which is not true.

Right.

> but mentioning that here seems out of scope to me.

I agree that such things are out of scope.

Ok, Alexey asked for text, how about something like this
for 8.3:

"The existing X-Forwarded-* headers expose information that
some users (or regulators) consider privacy sensitive. This
header field standardises that practice and so decreases user
privacy. However, with the current widespread use of
X-Forwarded-*, that impact is considered acceptable as it
improves interoperability, which might also allow for
better privacy controls in future. Implementers and operators
deploying this header (or X-Forwarded-* equivalents) need to
consider whether and how doing so impacts on user privacy and
for example whether relevant regulations such as cross-border
controls might come into play. See [ref] for additional
guidance."

I don't have a good reference to hand, but referring to
something that tells implementers and/or operators how to
play nice would be useful I think, since it seems that
many don't know (or don't care, and claim not to know;-)

BTW - I still haven't had a chance to read the whole thing,
though, so might have more comments when I do.

Cheers,
S.

---

From: Andreas Petersson <[email-masked]>
Date: Wed, 4 Jul 2012 16:56:02 +0200

On Wed, 04 Jul 2012 14:37:09 +0100

> I can't really parse the above sorry.

Sorry, it should read:
"If you, as a user, don't bother to find out whether the proxy is
anonymizing or not, you can not know that* now either."

*) That the proxy is not giving away your IP-address.

> which is what's implied by the current 8.3.

Well, they do exist of course.
But also non-direct connections are discussed in the current version
of 8.3.

> will do it this way. That reduces privacy to some extent unless

The reason to standardize this is so that more proxies will do this
instead of X-Forwarded-* (e.g. For). I do not expect people to start
using this, who currently do not use X-Forwarded-For. XFF is so widely
spread so those who wants to disclose this information does it already.

If your concern is that more people will start using this just because
it exists, well, yes, that may have a privacy impact.
If this is you concern, I start to understand your point. I don't share
your concern but we can surely mention that this header field should not
be used for people that do not see an actual need for it.

> I didn't suggest that. I'm asking for truth in advertising.

Ok, just asking.

> information is mostly fed into the marketing machine.)

One use case which I believe is pretty big is to geo-locate the users
to localize the content in various ways.
I don't think that is an elegant solution, but it is part of the
reality. If this use is intrusive on privacy is probably a matter of
taste.

> Ok, Alexey asked for text, how about something like this

It's a start, but I have some concerns (see below).

> privacy. 

"... and so decreases ..."
I don't see how it decreases if people are following an
RFC-specification of the format, or just the de facto format that
everyone already uses.

> However, with the current widespread use of

What regulations and cross-border controls are you talking about here?
Can you elaborate?

> many don't know (or don't care, and claim not to know;-)

Anyone else who can point to some relevant document for this matter?
I would think that most parties to follow the laws in their respective
country, which may be part of the problem, of course, but also quite
expected.

> though, so might have more comments when I do.

Well, the document is current under AD review. It would have been
better if you raised your comments during the WGLC. If you find new
issues, I guess the time to raise them is during the IETF LC, but I'm
unsure about the process here.

Best regards,
 Andreas

---

From: SM <[email-masked]>
Date: Wed, 04 Jul 2012 13:12:18 -0700

Hi Andreas,
>spread so those who wants to disclose this information does it already.

If the above was the rule, there are many things which the IETF would 
not be doing anymore.  For example, there was a time when security 
considerations were not given any thought.  Nowadays, you have to 
have some text about security considerations even if a protocol has 
been in wide use.

>to localize the content in various ways.

I thought that geolocation of users was about DNS tricks. :-)  It has 
been argued in the past that it is not optimal to do the geolocation 
at the HTTP level.

>reality. If this use is intrusive on privacy is probably a matter of

I beg to differ about privacy being a matter of taste.

>RFC-specification of the format, or just the de facto format that

I would look at this in terms of people instead of technical 
specifications.  The de-facto argument won't fly well in policy circles.

>What regulations and cross-border controls are you talking about here?

The privacy regulations in various countries differ significantly (as 
an unrelated example see 
http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf 
).

>country, which may be part of the problem, of course, but also quite

Yes.

>unsure about the process here.

If you are unsure about the process, you can ask the document shepherd.

BTW, as a quick comment, I like the text which Stephen Farrell 
provided at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06557.html

>probably be expanded. Something else that should be added?

Yes, the text needs some work.

>but mentioning that here seems out of scope to me.

What I was trying to express was: tell the user what to think about 
so that he or she can decide.  If you say "everyone does this, so why 
don't you do it", you might as well drop the privacy section altogether.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jul 2012 21:45:31 +0100

Hiya,

Basically agreeing with SM's latest below...

> *) That the proxy is not giving away your IP-address.

Ok, now I get what you said, but I don't get its relevance;-)

Are you assuming that most users would have any clue how
to figure out that a proxy is doing this spec? They won't. So
talking here about (or assuming) that a user could do this
is missing the point I think.

> But also non-direct connections are discussed in the current version

The problem I had was that the current text compared the situation
with these headers used vs. direct connections to argue that there's
no privacy impact. I think that's just not a good argument to make.

> spread so those who wants to disclose this information does it already.

This is an aside (maybe): the text above makes it sound like you
think this is entirely the proxy's choice and that that's fine.
I don't agree with that. The information concerned is about the
user and is identifying in various ways. Just because XFF does
this without asking doesn't make that right.

Right.

> be used for people that do not see an actual need for it.

The "people" you refer to above are who? I think you need to consider
the people whose information is being shared as well.

I think you need to make it clear to the reader that there are
privacy consequences. Its clear that many readers (and perhaps
writers:-) don't consider that aspect important, but they ought
to really IMO.

> reality. If this use is intrusive on privacy is probably a matter of

Ah. Then that does warrant a mention. And I think you also need
to say why you're not following the RFC 6280 way of handling
location information as well maybe (I'd need to read both docs).

In any case, location needs to be mentioned in this I'd say and
you ought look at RFC 6280 and see if parts of it apply here.

> RFC-specification of the format, or just the de facto format that

There will be more of them doing it, hence the decrease.

> What regulations and cross-border controls are you talking about here?

Its not an area in which I'm expert (maybe nobody is;-) but
for example a quick search shows a Canadian web page [1] that
says in part: "Organizations need to make it plain to individuals
that their information may be processed in a foreign country..."
Doing this, and making it "plain" to the user that the information
will cross a border (or even knowing that) might be considered
hard I guess.

I've no idea if that applies to what you're doing here or not,
but presumably someone writing code or deploying this (or the
existing X-Forwarded-*) should have checked that kind of thing
out.

   [1] http://www.priv.gc.ca/information/guide/2009/gl_dab_090127_e.asp

> unsure about the process here.

To be honest, I'm not sure about WGLCs in appsawg in general.

Maybe that's a process step that needs more thought for "area"
WGs since its a bit different in terms of people's focus. Or
maybe not. Anyway, sorry for not having gone through it all
properly. I read an earlier version and privacy was my main
comment then fwiw.

S

---

From: Andreas Petersson <[email-masked]>
Date: Thu, 5 Jul 2012 14:19:51 +0200

On Wed, 04 Jul 2012 21:45:31 +0100

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Jul 2012 13:35:13 +0100

Hi Andreas,

I think that needs more work. Will get back later on with
specific comments.

Cheers,
S.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 5 Jul 2012 09:38:24 -0400

Just a small comment for now; more when I'm at a real keyboard.

> unsure about the process here.

Earlier review and comment is always good, but:

1. Stephen isn't a regular appsawg participant, and I don't expect him to
get reviews in by WGLC.

2. Stephen is an Area Director, so he's busy reviewing a lot of things, and
it's good that we're getting his comments this early.  He can also give
comments and DISCUSS positions during IESG Evaluation, which comes after
the IETF Last Call.

Barry

---

From: Andreas Petersson <[email-masked]>
Date: Thu, 5 Jul 2012 15:45:22 +0200

On Thu, 5 Jul 2012 09:38:24 -0400

> 1. Stephen isn't a regular appsawg participant, and I don't expect him to

Ack, I did not now that.

> comments and DISCUSS positions during IESG Evaluation, which comes after

Ok. :)

/andreas

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Jul 2012 17:08:02 -0400

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

---

From: Andreas Petersson <[email-masked]>
Date: Thu, 05 Jul 2012 23:43:03 +0200

On 7/4/12 10:12 PM, SM wrote:
> Hi Andreas, At 07:56 04-07-2012, Andreas Petersson wrote:
>> The reason to standardize this is so that more proxies will do
>> this instead of X-Forwarded-* (e.g. For). I do not expect people
>> to start using this, who currently do not use X-Forwarded-For.
>> XFF is so widely spread so those who wants to disclose this
>> information does it already.
> 
> If the above was the rule, there are many things which the IETF
> would not be doing anymore.  For example, there was a time when
> security considerations were not given any thought.  Nowadays, you
> have to have some text about security considerations even if a
> protocol has been in wide use.
> 
>> One use case which I believe is pretty big is to geo-locate the
>> users to localize the content in various ways.
> 
> I thought that geolocation of users was about DNS tricks. :-)  It
> has been argued in the past that it is not optimal to do the
> geolocation at the HTTP level.

The DNS tricks are for making the request end up in the "right"
datacenter. I was talking about localizing the content.
For example, serve the web page in a different language (yes, I know
that this is not a good way of doing it, but it exists in real life).

>> reality. If this use is intrusive on privacy is probably a matter
>> of taste.
> 

I did not say that. Please do not make up things that I haven't written.

>> "... and so decreases ..." I don't see how it decreases if people
>> are following an RFC-specification of the format, or just the de
>> facto format that everyone already uses.
> 

Well, yes, but if I write something that makes it look like privacy
stands or falls with this particular header field, those people will
get the wrong idea.
I think it is wrong to encourage people to believe they are anonymous,
just because of the absence of this header field.
Those people should not trust a proxy owner either.

And, as I have said many times, writing a guideline for anonymizing is
far more complex than anything that would fit in this document.

>> What regulations and cross-border controls are you talking about
>> here? Can you elaborate?
> 
> The privacy regulations in various countries differ significantly
> (as an unrelated example see 
).
> 
>> I would think that most parties to follow the laws in their
>> respective country, which may be part of the problem, of course,
>> but also quite expected.
> 
> Yes.
> 
>> Well, the document is current under AD review. It would have
>> been better if you raised your comments during the WGLC. If you
>> find new issues, I guess the time to raise them is during the
>> IETF LC, but I'm unsure about the process here.
> 

I
borrowed much of it into my new version.
But, I think the beginning was too much focused on the old,
non-standard header. The text in this document must be focused on that.

I also think that the cross-border control stuff was pretty vague.
Are ISP:s supposed to mask the src-field of a IP connection when a
border is crossed?

>> I do think that the text should say something about the current
>> use of similar header fields though, otherwise it may look like
>> everything is fine unless you don't use this, which is not true. 
>> Users should also be aware of all other different headers and
>> cookies that their browsers sends out, so they can be identified
>> by those too, but mentioning that here seems out of scope to me.
> 
> so that he or she can decide.  If you say "everyone does this, so
> why don't you do it", you might as well drop the privacy section
> altogether.

This is changed in the new version.

Best regards,
 andreas

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 06 Jul 2012 00:20:58 +0200

On 7/5/12 11:08 PM, Alissa Cooper wrote:
> 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.

So the end users intention is not relevant at all? If the end user
wants to be anonymous, the user must Make Sure to be anonymous.
But if that is not the intention, the end user shoud NEVER assume he
is anonymous, and can NEVER count on that.

All other IP-based protocols (that are not forwarded), is sending the
source address, in every IP packet. But you know that of course, so I
guess I am misunderstanding you. Can you please express this in a more
clear way?

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

A static assigned token is of course no good for anonymizing a user,
and in the new version of the "Privacy considerations", it is
explicitly written that an anonymizing proxy should not use this
extension (I guess there may be situation where you could feed false
information in this header for whatever purpose, but I'm not gonna
figure out such schemes).
Back to the tokens, of course there is data that is really bad to put
in this header field. Your example of credit card number was far
beyond my imagination. I can add some sentence warning about not
placing sensitive data there, and also being careful about using a
static identifier.
A static identifier (containing a random string) is however at worst
about on the same level as a statically assigned IP address.

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

I understand the underlying ideas, but I can't agree with everything
there.

  "some users realize privacy
   benefits associated with IP address sharing, and some may even take
   steps to ensure that NAT functionality sits between them and the
   public Internet.  IP address sharing makes the actions of all users
   behind the NAT function 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."

I think this is to give a false feeling of privacy. A user must now
that the one controlling this NAT will be able to do a lot of things
with the end users data. And can also, at any time give out
information about the user.
Using NAT is a very, very weak way of gaining almost no anonymization.
A user Must actively seek to be anonymous, to truly be so.
Besides that, I think NAT is causing enough pain on its own, and
should not be encouraged. :-)

Taking the discussion under consideration, a modified version (I'm a
bit tired, but something like this):

- 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, but can still have
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.

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. When generating such tokens care must be taken not to include
private or in other way sensitive information in the token. When using
such tokens, it should also be considered not to use static tokens per
user, as that will increase the possibility for external organizations
to track separate users."

Best regards,
 Andreas

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 06 Jul 2012 00:26:40 +0200

On 7/5/12 2:35 PM, Stephen Farrell wrote:
> 
> Hi Andreas,
> 
> I think that needs more work. Will get back later on with specific
> comments.
> 

Thanks for this invaluable piece of information. ;-)

When you do get back, please comment on the version I wrote for the
reply to Alissa Cooper.

Best regards,
 Andreas

---

From: SM <[email-masked]>
Date: Thu, 05 Jul 2012 16:14:41 -0700

Hi Andreas,
>I did not say that. Please do not make up things that I haven't written.

Sorry about that.  It was a quick comment as the comments in this message.

>stands or falls with this particular header field, those people will

I see your point.

>Those people should not trust a proxy owner either.

Yes.  I don't really know how to put the following in words.  The 
argument is not about encouraging people to believe that they are 
anonymous.  It is also not about conveying the wrong idea.  I would 
describe it as "there are the pros, these are the cons, and the 
reader gets to make an informed descision".

Yes.

>Are ISP:s supposed to mask the src-field of a IP connection when a

A similar argument was raised during a discussion about DNS providing 
the client IP address to authoritative DNS servers.  The notion of 
consent is sometimes used in privacy discussions.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Fri, 06 Jul 2012 02:41:19 -0700

Hello,

I'll start with comments about draft-ietf-appsawg-http-forwarded-05 
for context.

In the Introduction section:

   "In today's HTTP landscape, there are a multitude of different
    applications acting as a proxy for the user agent and effectively
    anonymizing the requests to look as if they originated from the proxy
    IP address or in other ways changing the information in the original
    request."

This anonymous "feature" is created at the reverse proxy (load 
balancing, etc.).   It occurs nearer to the user for when content 
filtering.  In both cases the average user may not be aware of this 
"feature".  Let's assume that we are customizing the HTTP response 
based on the source IP address.  There is a problem in the two cases 
mentioned about.  The "fix" is to have the information forwarded 
through a header, e.g. X-Forwarded-For.

I don't know whether everyone agrees or disagrees that this 
unintended feature should be kept as it enhances privacy.  I'll 
assume that everyone disagrees as it is about the same as saying that 
NAT is a security feature.

The draft introduces forwarding and reverse proxies in Section 4:

   "This applies to forwarding proxies, as well as reverse proxies."

This covers a wider range of proxies than the examples mentioned in Section 1.

An obfuscated identifier is proposed in Section 6.3:

   "A generated identifier may be used where there is a wish to keep the
    internal IP addresses secret while still allowing the Forwarded
    header field to be used for tracing."

Section 8.2 discusses about information leakage:

   "The Forwarded HTTP header field can reveal internal structures of the
    network setup behind the NAT or proxy setup, which may be undesired.
    This can be addressed either by using obfuscated elements, preventing
    the internal nodes from updating the HTTP header field, or by having
    an egress proxy removing entries that reveals internal network
    This header field should never be copied into response messages by
    origin servers or intermediaries, as it can reveal the whole proxy
    chain to the client."

The way this is argued is that in the two cases mentioned above (see 
comment about Introduction) there is information leakage together 
with a proposal on how to address the problem.

Section 8.3 is about privacy considerations, i.e. what is a concern 
to the user instead of a concern about disclosing information about 
infrastructure (Section 8.2).  In non-technical discussions, this is 
where the argument is about consent (and intent).  Although the 
proposal ends up with privacy concerns, these concerns are somewhat 
of an indirect effect of what has been discussed up to this 
subsection as the "forward proxies" cover other cases too.

>some users consider privacy sensitive.

The argument here is that this technology exposes information which 
the user considers as having an impact on his/her privacy.  it's 
unrelated to the two cases mentioned above, i.e. the user does not 
necessary know about the proxy between him/her and the web 
server.  Assuming that the user knows, the privacy "feature" is still 
a side effect.

>to consider whether, and how, deploying this extension impacts on

I suggest looking at this in terms of forward proxies and from a user 
perspective.

>be forwarded by proxies using the header field X-Forwarded-For, which is

A similar argument is not being used for Section 8.2.

>information further, can use the possibility of obfuscating the client

The one before it needs some work.  I'll try and explain the 
point.  If the user explicitly chooses a proxy so that the client IP 
address is not disclosed and the proxy  reveals this information 
through the Forwarded HTTP header field, it is a problem.  This is 
where it can be said that a proxy where such behavior is undesired 
should not include the Forwarded HTTP header field.  Add a note that 
the if the information can also be revealed through the 
X-Forwarded-For header field and care must be taken not to include 
that header field.

I hope that the above comments provide a way forward to address the 
privacy considerations issue.

Regards,
-sm

---

From: Andreas Petersson <[email-masked]>
Date: Fri, 6 Jul 2012 13:24:54 +0200

On Fri, 06 Jul 2012 02:41:19 -0700

>     IP address or in other ways changing the information in the original

This section is somewhat rewritten after comments from AD Barry Leiba.
The updated version reads:

   In today's HTTP landscape, there are a multitude of different
   applications that act as proxies for the user agents, providing
   features such as caching, content filtering, content compression,
   crypto offload, and load balancing.  But these proxies make the
   requests appear as if they originated from the proxy's IP address, or
   in other ways changing the information in the original request.

I don't know if you think this is better or worse, but this based on
the suggestion from Barry.
For further discussion, please use that version.

> NAT is a security feature.

I do not really see your point here.
In a reverse proxy environment, I have really hard to see how this 
would impact on privacy, as both the reverse proxy and the web server
are within the same organization.

> This covers a wider range of proxies than the examples mentioned in Section 1.

So your suggestion is that I should also include "reverse proxies" in
Section 1? (or is there some other point that I miss here?)

> subsection as the "forward proxies" cover other cases too.

Is this only an informative sort of digest, or is there some critique
here, that I fail to understand? :)

> server.  Assuming that the user knows, the privacy "feature" is still 

This text is more or less the same as the one you proposed:

Except for the last sentence, which I include later.

> I suggest looking at this in terms of forward proxies and from a user 

Can you be more concrete?
Also notice, that this section is slightly updated, see:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06594.html

> A similar argument is not being used for Section 8.2.

That can be added.

> through the Forwarded HTTP header field, it is a problem.

Then the user made the wrong decision. How can a user choose a proxy,
with the intention to be anonymized, in some way, without making sure
that the proxy has that feature?
If the proxy owner adds these fields he will probably also reveal the
source IP-address in a legal case or for abuse issues.

So:
1. The user U are looking for a proxy server.
2. The constraint is that the proxy server should not disclose the
   users IP address.
3. Proxy server P discloses users IP addresses.
4. U choses P.
5. Above shows that the user failed to fill his own constraints.

I understand your point, and I simply think you are wrong here.

> This is 

It may be undesired by the end user (some of them), but desired by
the proxy owner. But for some reason the user did chose to use the
proxy. If the intent was to be anonymous, the end user must choose an
anonymizing proxy, if the intent was something else, well, then he must
weight the benefits and the drawback of that proxy server.

My text says:
"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."

I think this text is saying what you are discussing?

*) I do not intend this "may" to be interpreted as as suggestion to
the proxy owner. I want this to simply inform the end user that
such behavior exists. Can that be expressed better?

> privacy considerations issue.

Yes and no. :-)

BR,
 Andreas

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Jul 2012 17:59:10 +0100

So in some offlist mail Andreas and I (with a bit of help
from Barry) arrived at the text below, modulo a couple of issues
that I think still need list discussion. (I believe Andreas
doesn't think any further changes are needed.)

Issue#1: since this header can and will be used for figuring out
the user's location (via a geo-ip database), the question
arises as to whether the kind of handling of location that
geopriv arrived at (see RFC 6280) is required here or not. There
are arguments on both sides, so what's right here?

Issue#2: Using a static token per user to obfuscate the address
allows correlation of all of each user's activities, and that's
been shown to be a significantexposure with respect to
de-anonymizing the user.  On the other hand, changing one user's
token from instance to instance removes a significant amount
of usefulness from the function, by NOT allowing that sort
of correlation.  Would it be worth mentioning that so that
it's clear why a proxy would *want* the static token, and
should an example way to generate such tokens be included in
the draft?

Cheers,
S.

8.3.  Privacy considerations

   In recent years, there have been growing concerns about privacy.
   There is a trade off between ensuring privacy for users versus
   disclosing information which is useful for example for debugging,
   statistics and generating location-dependent content.

   The Forwarded HTTP header field, by design, exposes information that
   some users consider privacy sensitive, in order to allow for such
   uses.

   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 doesn't know or expect that this is the case.

   Implementers and deployers of such proxies need to consider whether,
   and how, deploying this extension affects user privacy.

   Note that users' IP addresses may already be forwarded by proxies
   using the header field X-Forwarded-For, which is widely used.

   A proxy that needs to be able to trace the source of requests, but
   that does not want to leak the information further, can obfuscate the
   client address.  When generating such tokens care must be taken not
   to include potentially sensitive information in the token.  When
   using such tokens, a static token per user would increase the
   possibility for external organizations to track separate users.

---

From: SM <[email-masked]>
Date: Fri, 06 Jul 2012 11:45:36 -0700

Hi Andreas,
>For further discussion, please use that version.

I used that section to provide context instead of arguing for it to 
be changed.  The above text is better than what's in 
draft-ietf-appsawg-http-forwarded-05.

>are within the same organization.

Again, the text I quoted and commented on was for context.  It was 
actually to explain that it does not impact on privacy as they are 
generally run by the same organization.

>Section 1? (or is there some other point that I miss here?)

No.  The point was to provide context.

>here, that I fail to understand? :)

Think of it as some informative sort of digest.  There is a critique 
in the RFC Series from the illustrious MAPS.  I view it as positive; 
the IETF will disagree with me as it favors discussions which could 
be qualified as tweeteresque.  There is no such thing as failure. :-)

>This text is more or less the same as the one you proposed:

Yes, I remember proposing that text.

>Can you be more concrete?

As in "send text"? :-)

>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06594.html

I read the message.  I'll comment below.

> > A similar argument is not being used for Section 8.2.

In my opinion, it may be better not to.  That part of the draft is 
stable.  It's easier to work on the part being discussed.

>Then the user made the wrong decision. How can a user choose a proxy,

If the user made the wrong decision it's not a problem once 
appropriate guidance has been provided.

>that the proxy has that feature?

I avoided using the word "anonymized" in my previous message.  If I 
recall correctly my argument was that the client IP address is not 
being disclosed (the following test may be informative 
https://panopticlick.eff.org )

>I understand your point, and I simply think you are wrong here.

If some parts of the world there is a risk to the user U if he or she 
does not carefully assess Item 3.  This draft cannot make proxy 
server P not disclose the user's IP address in a HTTP header 
field.  It cannot protect user U.  I may be wrong; I can only point 
out what I think is a risk.

Yes.

>I think this text is saying what you are discussing?

No, it was the "An end-user who want to be anonymous" paragraph.

>such behavior exists. Can that be expressed better?

Stephen Farrell suggested some text at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html 
I have been informed through the mailing list that he is an Area 
Director.  It has been said that Area Directors are like Greek 
gods.  I don't have have any inclination to doubt that. :-)  The text 
proposed is better.

>are arguments on both sides, so what's right here?

The begs the question of whether the issue should be addressed on 
this draft or in GEOPRIV.  RFC 6280 discusses about the architecture 
for Location-based services.  I suggest some wording along the lines 
of "if this header field is to collect location information about the 
user it affects Geopriv" together with an informative reference to RFC 6280.

>should an example way to generate such tokens be included in

In simple terms, by trying to fix one problem the proposal created a 
new problem.  It's worth discussing about correlation as that static 
token creates another piece of identifying information.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Jul 2012 22:28:25 +0100

On 07/06/2012 07:45 PM, SM wrote:
> Director.  It has been said that Area Directors are like Greek gods.  I
> don't have have any inclination to doubt that. :-)  The text proposed is
> better.

s/Greek god/Irish atheist/ :-)

> The begs the question of whether the issue should be addressed on this
> draft or in GEOPRIV.  RFC 6280 discusses about the architecture for
> Location-based services.  I suggest some wording along the lines of "if
> this header field is to collect location information about the user it
> affects Geopriv" together with an informative reference to RFC 6280.

I don't think an informative reference solves this. It might
be useful, but I think it ought be unnecessary to refer to 6280
or else normative, depending on where the consensus ends up.

The question for me boils down to whether an IP address
as used here is a location object in geopriv terms or not.
Personally, I'm not sure.

> In simple terms, by trying to fix one problem the proposal created a new
> problem.  It's worth discussing about correlation as that static token
> creates another piece of identifying information.

Right. I can understand the authors preferring to say
less on this rather than more. But maybe more is needed?

S.

---

From: SM <[email-masked]>
Date: Fri, 06 Jul 2012 19:26:21 -0700

Hi Stephen,
>s/Greek god/Irish atheist/ :-)

:-)

>Personally, I'm not sure.

RFC 6280 defines a location object as:

   "A data unit that conveys location information together with
    Privacy Rules within the Geopriv architecture.  A Location Object
    may convey geodetic location data (latitude, longitude, altitude),
    civic location data (street, city, state, etc.), or both."

Section 3.1 of RFC 6155 mentions IP Address as an identifier.  It's 
not clear how to equate IP address as used in this draft and the 
usage in Geopriv.  I suggest not considering Geopriv unless someone 
wants to make a case for it.

>less on this rather than more. But maybe more is needed?

As starting text (borrowed from RFC 4941):

    One of the requirements for correlating seemingly unrelated
    activities is the use (and reuse) of an identifier that is
    recognizable over time within different contexts.  Using the
    generated identifier (Section 6.3) has implications for
    privacy if it is not randomly generated for each request.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 07 Jul 2012 13:45:48 +0100

On 07/07/2012 03:26 AM, SM wrote:

> Section 3.1 of RFC 6155 mentions IP Address as an identifier.  It's not
> clear how to equate IP address as used in this draft and the usage in
> Geopriv.  I suggest not considering Geopriv unless someone wants to make
> a case for it.

I agree that its not clear.

However, it seems to me very odd to go to a lot of trouble
to control location privacy when using SIP but blithely have
middleboxes forward the required information when using HTTP.

>    privacy if it is not randomly generated for each request.

Sorry, not sure what point you're making there.

Actually, I (finally:-) had a look at the rest of the document
last night and turns out this is less of an issue than I
thought as 6.3 already discusses random identifiers.

S.

---

From: SM <[email-masked]>
Date: Sat, 07 Jul 2012 10:34:44 -0700

Hi Stephen,

Yes.

>Sorry, not sure what point you're making there.

The point is that if you are not using a randomly generated 
identifier per request, you end up creating yet another identifier 
for tracking [1].

>thought as 6.3 already discusses random identifiers.

Ok.

Regards,
-sm

1. http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html