Subject: #552: allow privacy proxies to be conformant

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 28 Jan 2014 17:47:10 -0800

In the IESG comments on p1 from Sean Turner:

> 1A) s5.7.2 and s2.3: s2.3 mentions privacy proxies and s5.7.2 says the
> following about proxies without qualifying the type of proxy:
> 
>   A proxy MUST NOT modify header fields that provide information about
>   the end points of the communication chain, the resource state, or the
>   selected representation.
> 
> So does that essentially mean privacy filters proxies are non-conformant?

http://trac.tools.ietf.org/wg/httpbis/trac/ticket/552

I think that the above text (which is broader than the specific header
field requirements in RFC2616) can be improved by replacing it with the
following text:

   A proxy MUST NOT modify header fields that provide information about
   the end points of the communication chain, the resource state, or the
   selected representation (other than those necessary to describe how
   the payload has been transformed). However, an exception to this
   requirement applies to proxies that are specifically configured to
   remove or filter header fields for the sake of privacy or security.
   The person or organization selecting the proxy is presumed to have
   control over its configuration.

Alternatively, we could go back to the list of specific header fields
that were specified in RFC2616 sec 13.5.2 and Allow.

....Roy

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 29 Jan 2014 18:31:20 +1300

> that were specified in RFC2616 sec 13.5.2 and Allow.

Why should it be okay if some network admin (IMPROTANT: *not* the
end-user or server operator being affected) explicitly asks for it but
not when the proxy authors who may very well understand the header
better think its a good idea to default-off on emitting something?

Either its okay to improve the traffic or its not. Whoever does it.
Surely the specification is not the right place to be forbidding
improvements.

The issue is that "end points of the communication chain" part. IMHO,
the downstream endpoint of the chain is not so important for the
transformation as the payload/content/resource, the proxy and the
downstream recipient of the message.
 We also have the possibility of a proxy adding/removing formats the
endpoint may be offering but which cause problems to the end-to-end
network. For example the Content-Encoding:sdch offered by a certain
browser can result in a response payload which is quite nasty to serve
up from cache, so caching proxy woudl prefer to drop it and let
gzip/deflate/identity encodings happen instead. It MAY do the sdch
conversion itself and generate the client response, but that has nothing
to do with the server.

On a side note;

 In the name of privacy it may be better to go back to the old list of
headers which are MUST NOT modify and a recommendation for new header
definitions to state whether or not proxy modification is also MUST NOT
/ MUST / whatever.

 Getting a header onto that list past a standards body with all the eyes
and minds is one of the fundamental checks-and-balances for user privacy
protection.

 Without that limitation any implementation could spread a new header
User-Home-Address or User-Bank-Login-Details (or something innocently
named with same field-values) and proxies are forced to violate the
specification simply to remove it.

 If the clause in question becomes a SHOULD NOT, then the proxies are
free to adjust headers if things get really problematic and the
standards body checking is replaced with more flexible and dynamic
industry moderation.

Amos

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 29 Jan 2014 10:49:08 -0800

> better think its a good idea to default-off on emitting something?

I don't think anything in that text prevents reasonable defaults
(or even unreasonable defaults).  It just has to be configurable
or it will not be interoperable.  In practice, proxy authors have
no idea what applications are intentionally being run on a network.
Their assumptions are always wrong when there is someone like me
using the network.

> Surely the specification is not the right place to be forbidding

The original requirements were added because proxy implementations
were interfering with deployment of Digest authentication.  Hence,
they are there to enable improvements.

> conversion itself and generate the client response, but that has nothing

Those are payload transformations, explicitly permitted by that section.

> standards body checking is replaced with more flexible and dynamic

Yes, that is what was in RFC2616: a general SHOULD NOT and a list of
MUST NOT fields.  I believe it was changed to categories because
proxies did not know what to do about etags, cache-control, and new
fields like authentication-info.  A category-based definition seemed
preferable to sprinkling proxy requirements in every header field.

I don't have a strong preference here other than a desire to minimize
the changes required to allow privacy/security filtering.  If you have
specific wording that would enable it better than mine above, please
propose that instead.  Reverting to the RFC2616 requirements is a much
larger edit.

....Roy

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 29 Jan 2014 20:08:24 +0100

>   control over its configuration.

This reads as though addition and manipulation of headers is not allowed
but it seems you mean to allow that; perhaps "remove, add, or modify"?

Editorially I think it would be better to have some qualifier at "proxy"
to hint at the exception, like "Ordinary proxies MUST NOT ... the only
exception ...".

Also, you say "an exception" suggesting there might be other exceptions.

Other than that, I think the text is okay.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/