Re: Trusting proxies (was Re: I revised the pro/contra document)

On Mon, Nov 25, 2013 at 10:05 PM, Amos Jeffries <squid3@treenet.co.nz>wrote:

> On 26/11/2013 1:55 p.m., Roberto Peon wrote:
> > Here is the GOALS section from:
> > http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00.
> > I do think breaking down the conversation in this way is interesting.
> >
> > 6.2 <
> http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00#section-6.2
> >.
> >  Goals
> >
> >    These are the goals of a solution aimed at making proxying explicit
> >    in HTTP.
> >
> >    o  In the presence of a proxy, users' communications SHOULD at least
> >       use a channel that is point-to-point encrypted.
> >
> >    o  Users MUST be able to opt-out of communicating sensitive
> >       information over a channel which is not end-to-end private.
> >
>
>
s/private/confidential



> I think this is partially wrong.
>
> It would be far better to give the client some guarantee of end-to-end
> confidentiality and/or non-transformation before it opts-in to sending
> private details.
>

That is the basic mechanism, so yea.


> Signing or encrypting the particular details using a shared secret
> arranged via mandatory out-of-band means with the origin server would be
> acceptible.
>


The client always decides what to send, and should always know if there is
an intermediary, assuming proxy use is explicit.
Mandatory out-of-band isn't necessary for this, in any case.


>
> >    o  Content-providers MAY serve certain content only in an end-to-end
> >       confidential fashion.
>
> This seems to be a waste of words in the spec. Content providers will
> make up their own decision about this. No need to use MAY, or even to
> state that IMHO.
>  Better to focus on the mechanisms provided by this spec for them to
> make that decision with.


Given that it is goals statement... it makes sense. I do prefer mechanism,
however, and that was my previous spec...
The base idea is that a content provider should have the ability to change
what it sends based on what is/isn't intercepting what.


> >
> >    o  Interception proxies MUST be precluded from intercepting secure
> >       communications between the user and the content-provider.
>
> This is a straw-man clause. Interception proxies will do what they want.
> The only way to avoid that is to provide better features through use of
> HTTP without interception.


I interpret this goal as: if you want it confidential, encrypt it and don't
provide the key to any intermediary.


>


> >
> >    o  User-agents and servers MUST know when a transforming proxy is
> >       interposed in the communications channel.
> >
>
>
> Via header is already mandatory. This has not gone down to well so far.
> Any similar replacement must jump the same hurdles which killed Via as a
> useful extension point for this ability.
>

MUST for non-required features are at best guidance, as was the case for
Via.
To make this goal a reality, you need a mechanism that requires it to be so.


>
> It reveals details of the path an protocol compatibility in both
> directions.
>
> The alternative is the Forwarded-For header. Which sadly is specified as
> a one-way Request header with a MUST NOT clause on use in responses.
> With stated grounds that it reveals details of the providers network
> which must be kept secret.
>
> ** Completely ignoring the privileged details revealed about the clients
> ISP being published to the origin. **
>
> Eliminating the client or their ISP from access to path/chain details
> necessary to form trust decisions about the origin is a terribly bad way
> to go about engendering a trust relationship.
>
>
> >    o  User-agents MUST be able to detect when content requested with an
> >       https scheme has been modified by any intermediate entity.
> >
>
> I don't see any reason to flag up https:// about this. For even a modest
> amount of security the requirement also goes for http:// and other
> schemes as well.
>

This is mentioned as a contrast to what happens when someone installs a
root cert onto your machine as a means to do proxying.


>
>
> >    o  Entities other than the server or user-agent SHOULD still be able
> >       to provide caching services.
> >
> >    o  User agents MUST be able to verify that the content is in fact
> >       served by the content provider.
>
> This is a vague cluause whih is either a straw-man or invalid depending
> on how you look at it.
>
> Firstly, does HTTP actually make that guarantee anywhere today? I dont
> think even HTTPS does that.
>
>
HTTPS does guarantee this today (up to the amount of trust we place in the
authentication trust chain) with TLS' integrity safeguards, though it is
channel-based, and not object-based.


> Secondly, what use is knowing the content is served by the content
> provider when it is not necessarily the content requested?
>  - the purpose of transforming proxies is to *generate* new or updated
> content based on the content providers content. Think ESI protocol or
> FTP->HTTP gateways.
>
> Thirdly, it directly violates the SHOULD on caching goal above. Content
> served out of a cache is by definition *not* served by the content
> provider.
>

Knowing about the transformation doesn't always imply rejection.
Some content transformations are understandable/can be verified, e.g.
truncation of a progressive jpg.


>
>
> >
> >    o  A set of signaling semantics should exist which allows the
> >       content-provider and the user to have the appropriate level of
> >       security or privacy signaled per resource.
> >
>
> See above comments about Via and Forwarded-For.
>

The signaling mechanism described a long time ago involves an end-to-end
channel over which the client signals to the server that it is connected to
an intermediary.


-=R