W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: David Morris <dwm@xpasc.com>
Date: Mon, 25 Nov 2013 15:53:25 -0800 (PST)
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <alpine.LRH.2.01.1311251543010.5816@egate.xpasc.com>


On Mon, 25 Nov 2013, Martin Thomson wrote:

> Isn't it the case that we want to limit the amount of trust that we
> bestow upon our favourite intermediary?
> 
> If this truly were a 100% trusted intermediary, then we'd already be
> done here.  TLS hop-by-hop is enough for that.  I don't think that is
> where all this time is going.

I think part of a trusted intermediary is that it must defer certain
decisions to the primary client. In particular, how to deal with
certificate issues. Does TLS supsport that level of interaction
with the intermediary? For example allowing the end-user (person) to
determine that an expired or self-signed certificate should be allowed?

> I think that all this discussion is getting all knotted over is what
> we want to allow intermediaries to do.  What set of capabilities can
> be offered to an intermediary that would induce it to reduce the scope
> of its powers?
> 
> It has been suggested that the powers of stealth be denied.  That
> sounds reasonable, but I always stumble at the UX story there.
> 
> The power of content modification - with some fuzziness around whether
> that includes "metadata" - has also been suggested as another
> potential power to strip.

Content modification may be the point of the intermediary. It can't be
precluded. Web acceleration for speed and/or data payload reduction is
an important interest to a significant user population.

> I think that leaves intermediaries with the ability to see what is
> going on and prevent it if they choose.  Is that enough?  I've heard
> it said that it is not.

Powers need to be negotiated and not an absolute feature of the protocol.
Received on Monday, 25 November 2013 23:53:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC