Re: new version trusted-proxy20 draft

On Feb 24, 2014, at 12:56 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Mon, 24 Feb 2014, Ilari Liusvaara wrote:
> 
>> 5) Regarding to usescases, protocol conforming to principle of
>> least priviledge and accomodiating all or even most of those (goes
>> up to "Tom's Rural broadband" right now) would likely be hideously
>> complicated mess of crypto.
>> 
>> 6) Because of the last, one is pretty much limited to no trust (CONNECT)
>> or full trust (GET/POST/PUT).
> 
> So I am new to this discussion, but I'll give it a go anyway.
> 
> The "mess of crypto" mentioned above, does that relate to an "onion style" kind of crypto, where the web server would first encrypt/sign the object with its own cert, and then use another one to send traffic to the proxy?
> 
> I was thinking if it was possible to keep confidentiality of the communication between web browser and web server, but still give the proxy enough information to do its job which would be caching and/or doing content access control.

just to be clear 
the draft proposes to separate streams (i.e. two TLS associations) one for https URIs resources and one for http URIs resources
in the proposal the draft won't do anything for the TLS association used to transport https URIs resources
and it will only ask consent to be in the loop for the TLS association for the http URIs resources (when transported over TLS)

so it will still be possible to keep confidentiality of the communication between web browser and web server

> 
> I guess the use-cases that are being adressed by this draft are two-fold:
> 
> 1. Proxy that wants to know what URLs are being used so it can record/limit access.
> 
> 2. Proxy that contains malware detection and so on to inspect all contents before it's delivered to the end systems.

yes but again only limited on "http" URLs … when transported over TLS on HTTP2

if the user (i.e. the WebBrowser) is trying to reach an "https" URLs then it will work exactly as today
with no possibility for the proxy to see anything.


> 
> With 1, if the content could be encrypted by one layer of crypto and a second layer for the session to/from the proxy, this would solve that problem. The end system could still verify the contents and that it hadn't been tampered with.
> 
> With 2, I don't see any other solution than the one suggested in the discussed draft with the proxy having full MITM capability.
> 
> If people were in the technical plenary session in Vancouver at IETF88, I was the one requesting more work on usability when it comes to crypto. How the user should be informed of current network security situation (if proxy can inspect the traffic or not) is also a tricky one. We also need settings on the devices saying what apps are allowed to communicate under what circumstances etc. I do not want my bank app to allow MITM,

neither we want, really!
and we are not proposing it.

> whereas I might be ok sometimes with my web browser when I use certain web sites with no important content to me.

and we are proposing only for the "http://" resources

so it will up to the content provider to decide if they think that there will be a benefit for their content from having a proxy in between
(i.e. providing the content as an "http://" URI resource over TLS) or they think that there should not be any proxy (and in this case they will 
provide the content as an "https://" URI resource over TLS)

moreover even if the content provider will provide the content as an "http://" URI resource
we are proposing that the user should be able to opt out and decide not to have any proxy in the middle

br
Salvatore

> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
>

Received on Monday, 24 February 2014 12:36:35 UTC