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

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2013 14:13:34 -0800

On 25 November 2013 13:09, Peter Lepeska <[email-masked]> wrote:
> I think we need to come up with a protocol-supported way to solve the
> problems of trusted proxies without modifying TLS.

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 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.

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.

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 25 Nov 2013 18:02:14 -0500

"What set of capabilities can
be offered to an intermediary that would induce it to reduce the scope
of its powers?"

Martin,

I completely agree that this is the direction to go in and have a proposal
that I'm running by a smaller group off list. I'll post it as soon as I've
incorporated the group's feedback.

Thanks,

Peter

---

From: David Morris <[email-masked]>
Date: Mon, 25 Nov 2013 15:53:25 -0800 (PST)

> 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?

> 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.

> going on and prevent it if they choose.  Is that enough?  I've heard

Powers need to be negotiated and not an absolute feature of the protocol.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2013 16:10:17 -0800

> 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?

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Nov 2013 16:43:51 -0800

> 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

---

From: Roberto Peon <[email-masked]>
Date: Mon, 25 Nov 2013 16:55:22 -0800

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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 25 Nov 2013 17:04:16 -0800

> I do think breaking down the conversation in this way is interesting.

I just wanted to highlight the one piece: who gets to negotiate this
end-state, whatever that end state is.  (That's why the paste-dump is
somewhat distracting; there's a lot there that isn't particularly
well-motivated yet in my opinion and a lot that is not relevant to the
immediate discussion.)

I think that your first three points or so mean that you think that
there are three parties involved in this negotiation: user,
intermediary and server.  You use the word "user" instead of client,
which is telling, and probably a conscious choice.

I want to work out whether this is in fact true, in the sense that the
user is making an informed, empowered choice. I haven't been given
information so far that would allow me to say that this is a) an
agreed requirement (in the consensus sense), and b) possible.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 26 Nov 2013 01:12:27 +0000

from our POV, we have many customers (e.g. companies) who do not wish to 
give the user (e.g. employee) too much power.

the user always has choice whether to click a link or not, to go to the 
private site or not from company equipment using company resources.

Often, the company running the intermediary for employee use insists on 
the ability to scan content.  So it's not just up to the endpoints - 
they can't force an intermediary to grant any particular type or level 
of access.

In these cases, I think the best that can be done is that the user knows 
what is happening and can make an informed choice.  The server may also 
need to be able to make an informed choice as well.  But the choice 
comes down to proceeding or not.

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Roberto Peon" <[email-masked]>
Cc: "James M Snell" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 26/11/2013 2:04:16 p.m.
Subject: Re: Trusting proxies (was Re: I revised the pro/contra 
document)

---

From: Ted Hardie <[email-masked]>
Date: Mon, 25 Nov 2013 21:20:20 -0800

> agreed requirement (in the consensus sense), and b) possible.
I'm not sure that negotiation is the only option on the table.  If the user
and the server can each determine that a channel has an intermediary, then
they can make choices on that basis on what data to offer over the channel,
even if they have no negotiation with that intermediary.

At its very basic level, the most important point is to make it clear what
is going on.  At the moment, there is resistance to doing that because the
support costs of doing so are high; it's "cheaper" to put in something that
acts like a b2bua (for those not as SIP-terminology steeped as Martin, I
mean an interception proxy that terminates one TLS connection and starts
another, without either side aware of the proxy).

If we can make configured proxies easier and more effective for HTTP 2.0,
there's a chance things would get a bit better (using TLS to a proxy that
will then emit non-TLS, for example gets you a little something).  More
importantly, that ease of using configured proxies may also make it more
likely that other tools will get turned back on, where they are currently
turned off in the presence of the configured roots that enable interception
proxies.

None of this is a panacea, of course, but if I can at least tell when then
hop-by-hop protection I'm getting is to the proxy I intend and confirm that
I'm getting a connection to the middle and not the end, transparency about
how my use of the web is working goes up.  To me, that's a good thing, even
if I cannot negotiate what the intermediary is doing.

Sadly, I fear I'm not the UX designer you need to figure out how to show
this to an end user.  (Having spent too much time on airlines, I would have
a hub-and-spoke airline logo for one and a direct flight airline logo for
the other.  But that would just get me into trademark trouble to go with my
other, woefully poor UX design issues).  But I am convinced something is
possible here.

regards,

Ted

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 26 Nov 2013 19:05:27 +1300

>       information over a channel which is not end-to-end private.

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

>    o  Content-providers MAY serve certain content only in an end-to-end

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.

>       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.

>       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.

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.

>       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.

>       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.

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.

>       security or privacy signaled per resource.

See above comments about Via and Forwarded-For.

>> makes to either the request or response are detectable by the

How would you suggest signalling things like updating the
Cache-Control:max-age=N value? adding only-if-cached etc?
 or appending to the If-Match/If-None-Match  headers?
 or stripping Proxy-Connection and similar garbage headers?

These are all things Squid legitimately does to optimize the traffic.

... not to mention the problem of people stripping any header used to
signal these details simply because it is not known to them or appears
risky in some small way.

Micro-managing these details gets very difficult and can be verbose in
the traffic. Abstrac too far and you end up with an evil-bit.

>> manner not authorized by the requesting agent or responding origin.

"Says who"?

Seriously. This is not something that can be specified. Instead focus on
the mechanisms which make it impossible or impracticable to be bothered
doing.

>> Is breaking the conversation down this way helpful?

Amos

---

From: Roberto Peon <[email-masked]>
Date: Mon, 25 Nov 2013 22:33:12 -0800

On Mon, Nov 25, 2013 at 10:05 PM, Amos Jeffries <[email-masked]>wrote:

> > 6.2 <
> http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00#section-6.2
> >.
> >  Goals
> >
s/private/confidential

> confidentiality and/or non-transformation before it opts-in to sending

That is the basic mechanism, so yea.

> arranged via mandatory out-of-band means with the origin server would be

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.

>  Better to focus on the mechanisms provided by this spec for them to

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.

> HTTP without interception.

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

> 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.

> amount of security the requirement also goes for http:// and other

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

> 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.

> served out of a cache is by definition *not* served by the content

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

> 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

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 26 Nov 2013 11:19:53 +0100

Le Mar 26 novembre 2013 07:05, Amos Jeffries a écrit :
>> 6.2
>> <http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00#section-6.2>.
>>  Goals
>>

IMHO any way you look at it trust in a hop-by-hop world requires defining
what parts of the message constitutes the payload and should never be
modified, and then add a sender signature to it (if the payload is not
already 100% crypted)

I don't think anyone cares which of the intermediaries modified the
payload if the signature does not match

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 26 Nov 2013 10:32:32 +0000

On Nov 26, 2013, at 7:20 AM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Martin writes:

I'm not sure that negotiation is the only option on the table.  If the user and the server can each determine that a channel has an intermediary, then they can make choices on that basis on what data to offer over the channel, even if they have no negotiation with that intermediary.

yes
The first step is to let the client (I am not going in user consciousness issue at moment)  and the server become aware of the existence of an intermediary in between, so that the client and the server can decide how to behave (i.e. what content request/provide)
but they should be also able to opt out (i.e. using a mechanism like connect or a similar one) if they really do not want the proxy stay in between.

At its very basic level, the most important point is to make it clear what is going on.  At the moment, there is resistance to doing that because the support costs of doing so are high; it's "cheaper" to put in something that acts like a b2bua (for those not as SIP-terminology steeped as Martin, I mean an interception proxy that terminates one TLS connection and starts another, without either side aware of the proxy).

that is definitely an area we have to work on

there's a chance things would get a bit better (using TLS to a proxy that will then emit non-TLS, for example gets you a little something).  More importantly, that ease of using configured proxies may also make it more likely that other tools will get turned back on, where they are currently turned off in the presence of the configured roots that enable interception proxies.

None of this is a panacea, of course, but if I can at least tell when then hop-by-hop protection I'm getting is to the proxy I intend and confirm that I'm getting a connection to the middle and not the end, transparency about how my use of the web is working goes up.  To me, that's a good thing, even if I cannot negotiate what the intermediary is doing.

that is the main point, we have to improve the situation compared to what we have at moment.

Sadly, I fear I'm not the UX designer you need to figure out how to show this to an end user.  (Having spent too much time on airlines, I would have a hub-and-spoke airline logo for one and a direct flight airline logo for the other.  But that would just get me into trademark trouble to go with my other, woefully poor UX design issues).  But I am convinced something is possible here.

a big part of all the challenge will be on the UX designer.
I also think it would be possible to come up with something really great

/Sal

regards,

Ted