Re: comparing eproxy proposals

[Peter Lepeska <[e-mail]>]

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 <[e-mail]> wrote:
>
>
>
> On Sat, Jan 18, 2014 at 8:54 AM, Peter Lepeska <[e-mail]> wrote:
>>
>> 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.
>
>
> This is saying something very obvious, and thus potentially confusing :)
> Essentially, if you+endpoint believe it should be confidential, then it
> should be confidential.
>
>>
>>
>>    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.
>>
>
> 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
>
>>
>> Thanks,
>>
>> Peter
>>
>