Subject: comparing eproxy proposals

From: Peter Lepeska <[email-masked]>
Date: Sat, 18 Jan 2014 17:54:10 +0100

As an exercise, I’ve attempted to define the 5 eproxy schemes that
have been proposed up until now. And then compared these schemes to
the eproxy GOALS section described here:
http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00.

Here are the five proposed HTTP2S eproxy schemes:

1. MITM -- This is the current way TLS is proxied that involves the
proxy generating certs to impersonate the content server.

2. Proxy Server TLS Extension -- Described here:
http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01. Using a
proposed extension to TLS, the proxy forwards the server cert to the
client so that it can authenticate the content server. I think of this
as MITM without impersonation, but I hope that doesn’t misrepresent
the proposal.

3. Shared decryption key material -- This idea is described in both
http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00 and
http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-00#section-4.1.
The core concept, in my understanding, is that the proxy is able to
see the end-to-end TLS traffic in plaintext b/c the UA exports the
session key and uploads it to the proxy.

4. Client forwards plaintext requests to secure proxy -- This idea is
also described in both the rpeon exproxy draft and the loreto trusted
proxy draft (links above). The concept is that two standard
point-to-point (P-t-P) TLS sessions are established between client and
proxy and proxy and server and then the browser simply forwards its
HTTP2 requests to the proxy over that secure link.

5. Any Node Refusal -- This is the proposal I posted to the mailing
list earlier and have re-posted here --
https://github.com/bizzbyster/AnyNodeRefusal/wiki/HTTP2S-Eproxy-with-Any-Node-Refusal
-- that leverages James’ intra-connection TLS negotiation to establish
an unencrypted end-to-end TLS session across two point-to-point
encrypted sessions. As the name implies, any node can refuse, data
integrity is guaranteed, and the proxy cannot operate in stealth mode.

Now to see which goals are met by each proposal...

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.

All meet this.

   o  Users MUST be able to opt-out of communicating sensitive

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

All but MITM meet this.

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

      confidential fashion.

Only Any Node Refusal meets this.

   o  Interception proxies MUST be precluded from intercepting secure

      communications between the user and the content-provider.

I don’t really understand this one. Isn’t this a question of how you
establish trust? That is not defined in any of these schemes.

   o  User-agents and servers MUST know when a transforming proxy is

      interposed in the communications channel.

Only Any Node Refusal meets this.

   o  User-agents MUST be able to detect when content requested with an

      https scheme has been modified by any intermediate entity.

Only Any Node Refusal meets this.

   o  Entities other than the server or user-agent SHOULD still be able

      to provide caching services.

I think all meet this except #3 above, Shared Decryption Key Material.
I can’t see how that scheme can provide caching services.

   o  User agents MUST be able to verify that the content is in fact

      served by the content provider.

Only Any Node Refusal and Shared Decryption Key Material meet this.

   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.

Only Any Node Refusal meets this.

   o  Ideally, HTTP URI semantics SHOULD NOT change, but if it does, it

      must remain backwards-compatible.

All meet this, I believe.

   o  Configuration and deployment of proxies should be as easy as

      currently used solutions.

I think this really depends on how trust is established, which isn’t
covered by these proposals.

   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.

I don’t think any require this.

Conclusion: I think the eproxy spec has to address three difficult
things: 1) discovery of proxies, 2) establishing trust, and 3) the
runtime requirements of UAs, proxies, and servers as defined by the
GOALS section above. All three are really hard problems but I think
ANR is a step towards solving #3.

Thanks,

Peter

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 18 Jan 2014 18:23:22 +0000

In message <CANmPAYFm=Vm-L=smSU8XVN6N4fjWWYr=[email-masked]>

>Now to see which goals are met by each proposal...

I'd suggest we also look at how the proposed schemes handle when
there are multiple proxies in the path between the client and server.

Some of the schemes, #4 for instance, fails that criteria.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Jan 2014 18:32:07 +0000

> Some of the schemes, #4 for instance, fails that criteria.

And also whether or not proposals have impact beyond HTTP
and if so are they accompanied by a full analysis of that
impact.

S.

---

From: Peter Lepeska <[email-masked]>
Date: Sat, 18 Jan 2014 21:49:32 +0100

Agreed. There are a lot of other criteria that we need to consider.
For instance, Any Node Refusal involves extra round trips between
proxy and server to setup the point-to-point TLS session, that none of
the other schemes suffer from. I arbitrarily used the GOALS section
from the Vidya draft since it seemed well thought out but we should
establish a more complete list of requirements/goals.

Peter

---

From: Roberto Peon <[email-masked]>
Date: Sat, 18 Jan 2014 14:28:26 -0800

> establish trust? That is not defined in any of these schemes.

This is saying something very obvious, and thus potentially confusing :)
Essentially, if you+endpoint believe it should be confidential, then it
should be confidential.

> ANR is a step towards solving #3.
I'm fairly certain that all of these goals are met with the eproxy draft I
submitted way back when, except for proxy discovery, and trust
establishment, which I didn't go into since the mechanisms for that were
likely separate from the mechanisms of the proxying itself.
I'm happy to go into individual points if you like, but I don't really
think it matters, All solutions in the space end up being roughly the same
thing with different bikeshed colors :)
-=R

---

From: Peter Lepeska <[email-masked]>
Date: Sun, 19 Jan 2014 03:34:08 +0100

Hi Roberto,

Sorry if I misrepresented your proposal. I was trying to bring clarity
and it sounds like I may have over-simplified proposals. Re-reading
your draft, it looks like #3 "shared decryption key material" is
described. #4 is only described in section 4.2 of Salvatore's draft.
And in general your doc touches on multiple different ways to do a
trusted proxy, covering some aspects of each of my 3-5 above,
including proposing a null cipher in an end-to-end tunnel. I can
repost without reference to prior drafts so as to avoid my own
misunderstandings of what was intended in them.

"I'm happy to go into individual points if you like, but I don't
really think it matters, All solutions in the space end up being
roughly the same thing with different bikeshed colors :)"

I agree with you only to the extent that the issue of how to establish
trust dwarfs these other considerations. But I think if we come up
with a protocol that allows each node (client, proxy, server) to
express its interest and requirements at runtime on a per object
basis, and to enable a dynamic negotiation, we might find the problem
of trust shrinks a little bit.

Thanks,

Peter

On Sat, Jan 18, 2014 at 11:28 PM, Roberto Peon <[email-masked]> wrote:
> I'm happy to go into individual points if you like, but I don't really think
> it matters, All solutions in the space end up being roughly the same thing
> with different bikeshed colors :)
> -=R
>
>>
>> Thanks,
>>
>> Peter
>>
>