W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: explicitly authenticated proxy: new draft

From: Salvatore Loreto <salvatore.loreto@ericsson.com>
Date: Tue, 17 Jun 2014 09:45:56 +0000
To: Mark Nottingham <mnot@mnot.net>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Diego R. Lopez" <diego@tid.es>, Martin Nilsson <nilsson@opera.com>, "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Message-ID: <AE0E6DE4-AF4C-4420-9C37-93165B917F4A@ericsson.com>

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.

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

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.


> 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/
Received on Tuesday, 17 June 2014 09:46:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC