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

[Andreas Petersson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPtm6jAAoJEEaYRbQUWNle5SwP/A+8/d/oJc/wzkPv9hALb5Wb
zkNM9h9yK8+vhBr7ydmeEC/5cnrevPnNnJqhVKbebAVDBpibvwpSzLUTvgScJe+P
fQXlYj8p3rdfCFEKI70OcdijqMfca9VWjgSWrOhhErT16HsHVeGWhWYtwhXrZx1Q
zsGjmyCdahzCRUlCLL2Ya9q4ZX7FnvsvD5W0+AOXj8mXj8LwV6ZjRh4+2oSDGUuC
qa90vnje329xWcVRuQ6Gvy/xr6GmoN88KUfN8xb1kL9Kmcz3SUT2Za3Bcy5S5uUG
QdIR4xfq36RRRc5W5TnCYiaA+d872EhZQ/vWKbiUk1D0wTkQM/IDeB0WLc/vzulb
aRT7cWWTVJpRIHt1/UfKwh3gA6yahOnApC+spAzYjbrXi+Dj5M/xl9iJPtmeiHFl
g87dBo42DbwKIBzgdVixJrthBuscCNREVAnzMdZd4szC8fUY1GpHZBzWBe3KEEGf
SNv+vP0xWJDWIoob46L00iWsf9/1h9EjJAWqIyxxMEUF4GTRTUTl90L+o2JLvS/Q
0s5gVHl6Y3cJkIa99j+01G3st+z4ggVDStlWYnsSiloJBPb1ua+vcqwPktwygnLG
gHbqubv9bvxs95rxcBZfaJbo8HMQOHXfKtHGawWRYHqRJBKy4FEe9CBG5cF2XmsU
gWC9vg1ZgifHu97UouoI
=tl+U
-----END PGP SIGNATURE-----