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

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.

   o  Content-providers MAY serve certain content only in an end-to-end
      confidential fashion.

   o  Interception proxies MUST be precluded from intercepting secure
      communications between the user and the content-provider.

   o  User-agents and servers MUST know when a transforming proxy is
      interposed in the communications channel.

   o  User-agents MUST be able to detect when content requested with an
      https scheme has been modified by any intermediate entity.

   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.

   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.

   o  Ideally, HTTP URI semantics SHOULD NOT change, but if it does, it
      must remain backwards-compatible.

   o  Configuration and deployment of proxies should be as easy as
      currently used solutions.

   o  Introduction of explicit proxying MUST NOT require a flag day
      upgrade - in other words, it should work with existing client and
      content provider implementations during the transition.




On Mon, Nov 25, 2013 at 4:43 PM, James M Snell <jasnell@gmail.com> wrote:

> On Mon, Nov 25, 2013 at 4:10 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > On 25 November 2013 15:53, David Morris <dwm@xpasc.com> wrote:
> >> Powers need to be negotiated and not an absolute feature of the
> protocol.
> >
> > That's a nice blanket statement.  Let's assume that this is true for
> > all combinations of powers (a point that seems suspect); who are the
> > parties at the negotiation table?
> >
>
> Great question that does not have a great answer. Part of the problem
> with this conversation is that we don't really have a great vocabulary
> developed yet to really discuss it.. we just keep saying "trusted
> proxy" and "untrusted proxy" without really breaking down what those
> really are. We need to if we're going to make any progress in this
> discussion. Also, without any clear shared notion about what kind of
> good behaviors a "trusted" intermediary ought to implement, it's going
> to be very difficult to really nail this down.
>
> So let's take a first stab at this:
>
> 1. A Trusted Intermediary exists in the path for the benefit of either
> the requesting agent, responding origin, or both.
> 2. A Trusted Intermediary ALWAYS makes it's presence on the path known
> to both the requesting agent and the origin.
> 3. A Trusted Intermediary ALWAYS ensures that any modification it
> makes to either the request or response are detectable by the
> receiving peer.
> 4. A Trusted Intermediary NEVER utilizes request or response data in a
> manner not authorized by the requesting agent or responding origin.
> 5. A Trusted Intermediary that exists for the benefit of the
> requesting agent ALWAYS provides proof to the responding origin that
> it has been authorized and trusted by the requesting agent.
> 6. A Trusted Intermediary that exists for the benefit of the
> responding agent ALWAYS provides proof to the requesting agent that it
> has been authorized and trusted by the responding origin.
> 7. A Trusted Intermediary NEVER attempts to subvert or compromise the
> integrity communication between the requesting agent and responding
> origin.
> 8. A Trusted Intermediary ALWAYS limits it's actions to those
> explicitly granted to it by the requesting agent or responding origin
> or both.
> 9. A Trusted Intermediary ALWAYS asks for permission before it
> performs any action (see #2)
>
> I'm sure these could use some massaging and refinement, but what this
> basically describes in a delegation model: A trusted intermediary is
> one that has been delegated some form of verifiable permission to act
> by either the origin or the agent. The key questions, then, become how
> exactly do we reliably enable this kind of delegated authorization
> model.
>
> Is breaking the conversation down this way helpful?
>
> - James
>
>