Re: explicitly authenticated proxy: new draft

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

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

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 01:33:23 UTC