Re: explicitly authenticated proxy: new draft

On 17 Jun 2014, at 7:45 pm, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:

> 
> On Jun 17, 2014, at 4:32 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> Right. 
>> 
>> I think the most obvious way to attack this is to discuss whether the OE/OS (whatever we end up calling it) draft might specify how UAs MUST/SHOULD/MAY behave when sending a http:// request to a *configured* proxy (when the UA supports OE). 
> 
> not sure if OE/OS draft is the right place maybe it is, lets discuss it.

Yes; this is a good topic for Toronto (and on-list beforehand, of course).


> The main problem is really how dynamically configure and authenticate a proxy that is inline to the user
> (i.e. specific to the access network)
> 
> The draft proposes to use the Proxy Certificate as a way for the Proxy to authenticate itself and at same time trigger
> the consent request into the Browser and show to the end user.

It sounds a lot like you're talking about a "transparent" proxy -- i.e., one that's not explicitly configured by the user (or their administrator on their behalf). Is that the case, or do I misunderstand?


> I fully understand that httpbis is not the right place to standardise it, but at same time there is some interest to better define
> and standardise the Proxy Certificate concept in the right wg.

Well, getting the venue right is certainly a concern, but just as important is making sure that both the browser implementer as well as the security and privacy communities are bought into the problem description as well as the outcome. 


> After the proxy is configured and securely connected to the browser;
> the browser SHOULD/MAY (definitely not MUST) send the http:// request to the *configured* proxy 
> and the user has at any time the possibility to opt out
> 
>> 
>> I don't yet understand the need for different ALPN tokens, cert attributes, etc., unless people are also thinking about non-configured ("transparent") proxies -- which this WG have explicitly and deliberately *not* codified for a long, long time -- or expanding this scheme to also cover HTTPS URIs…
> 
> the different ALPN token is not thought to be used for non-configured ("transparent") proxies. 
> It is really used on the opposite way.
> The need of the ALPN tag is used only as part of the mechanism used by the inline proxy to authenticate itself with the Browser
> and request an explicit consent from the End User.

OK. I'll reiterate; sharing understanding about the use cases and goals will help move the discussion along much more effectively at this point.

Cheers,

> 
> br
> Salvatore
> 
> 
>> 
>> Cheers,
>> 
>> 
>> On 17 Jun 2014, at 11:23 am, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> 
>>> 
>>> Hiya,
>>> 
>>> On 17/06/14 01:55, Diego R. Lopez wrote:
>>>> As far as I can tell Stephen's objections were about a proxy acting
>>>> as intermediary in a connection using HTTPS
>>> 
>>> Not quite. I do object to modifying TLS to add a 3rd party
>>> with no real analysis of the significant impact of doing
>>> that. (Where a real analysis is a *lot* of work as stated
>>> earlier etc. etc.)
>>> 
>>> I'll be interested to see if a useful HTTP layer solution
>>> that does not modify TLS is practical, or not.
>>> 
>>> And since I am in favour of defining how to use HTTP URIs
>>> over TLS, and of more use of that, yes, there is maybe an
>>> interesting cross-over space between that and some possible
>>> HTTP proxy proposals. I'm not sure to be honest if a useful
>>> thing can be standardised in this space.
>>> 
>>> That said, I think after my concerns are handled, you may
>>> run straight into Will's browser UI and caching issues, which
>>> might be even trickier, so I am not by any means asserting
>>> that there is a good approach that's possible to standardise
>>> here.
>>> 
>>> Cheers,
>>> S.
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> 
>> 
>> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 18 June 2014 00:50:30 UTC