Forwarded HTTP Extension
draft-ietf-appsawg-http-forwarded-10

Supporting Stephen Farrell's position

I commented on the privacy aspects of this during IETF LC and while
the resulting text (in 8.3) is such that I can accept the outcome of
that discussion is as good as we can get, I still have to say this
isn't really something that I think we would have developed
from-scratch in a WG. With this document, we're standardising
something that is the opposite of privacy-friendly, basically just
because the existing X-Forwarded-* header fields exist and are used
already and anything we developed that was more privacy-friendly
wouldn't get deployed. 

I'm also not at all clear as to who benefits from standardising
this, e.g. see my comments on 7.2 & 8.1 below. That may have been
discussed on the apps-discuss list, but I don't recall that so am
concerned that we may just be standardising this because someone had
the energy to write and process the document.

I think the document would be better if it didn't present this as
being a good (or unconditionally "needed") thing, at least without
caveats. For example, I don't think this is "needed" by users, but
rather more by others. That's mostly a writing-style thing though.

What is a "trusted path" of proxies, or a "trusted proxy"? I think
that phrase could just be deleted since there are very few cases
where anyone knows of and (equally) trusts all the proxies on a
path. I don't think the document defines that well enough for the
phrase to be kept.

Encouraging addition and modification of header fields like this
means that any future HTTP e2e integrity mechanisms will have to be
more complex than otherwise, basically about as complex as DKIM (or
the DOSETA proposal derived from that). I'm not sure if that might
or might not have a bad effect on future work with HTTP. I don't
know if that was discussed on the httpbis list or on apps-discuss.

Section 4 says proxies MUST ensure the "correct" header field is
updated but doesn't seem to say exactly how to know which header
field is the correct one.

5.4 seems to be standardising a practice that amounts to trying to
fool the user-agent into believing that TLS was used end to end when
in fact it was not. While this is so widely deployed that its
probably pointless to try even discourage, I'm not convinced that a
WG would design a standard for a server-side crypto accellerator in
this way. I think we'd be more likely to make the middlebox at least
visible to the user-agent.

7.2 doesn't seem to me to specify when to preserve the header field
and when not to do so. I don't think "direct consequence" is
something that all implementers will understand in the same way.
(If doing whatever you like is fine here, then that calls into
question the basis for standardising this in the first place.)

8.1 says this cannot be relied upon. If that's the case then why is
it being standardised? Whitelisting proxies is (as the document
admits) not a credible mitigation.

8.2 says telling the client about the proxy chain is somehow a bad
thing but doesn't justify that. Since a client could find out anyway
if they wanted to bother, that seems wrong. 

8.2 says to disallow the TRACE request. Is that a change to HTTP?
If so, then where was that discussed?

Section 9 says only that the expert should ensure that the
specification "address the security and privacy implications of the
requested parameter." So if I defined a parameter that passed on the
precise location of the end-user or the most recent healthcare
related URL they've accessed then would that be ok? I think
additional instructions are needed as to the acceptable purposes to
which such parameters can be put or else perhaps IETF review would
in fact be better. Given the field of applicability I would not be
surprised if very privacy-invasive parameters were defined in
future.

The W3C have standardised the DoNotTrack header field. It
should be clear whether or not, and if so, how, this header 
field interacts with that one.


5.1 says "some other kind of identifier" which seems quite loose.

5.5 says widely deployed extensions SHOULD be standardized which is
an odd use of 2119.

What does "in a sensible way" mean in 7.4? That seems underspecified.