Re: explicitly authenticated proxy: new draft

On 16 Jun 2014, at 6:08 pm, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
> 
> the idea behind the proposal is that h2c could be meant as tag to indicate that the HTTP2 connection is used only to exchange http:// URI traffic 
> for both in plain text when used with upgrade or in ALPN when the http:// URI traffic is transported over authenticated TLS.
> 
> I am aware of the pushback but I am still convince that would be cleaner to keep a distinction at ALPN level between "http" and "https" URIs.
> However it would be possible also to change the proposal so that it works also when/if that distinction is not present.

Can you present both options in your draft?

> 
> The mechanism we are proposing is just a way for the Proxy to manifest itself to ask for consent the end user and consequently the browser 
> and then in the case the end user provides the consent for the proxy to stay in between,

Right, but as Stephen has pointed out separately, doing so has a huge potential affect on the TLS ecosystem. 

Also, how will this work with existing browsers who aren’t aware of your cert extensions? 


>> The only implementer that has so far expressed interest in using TLS for HTTP (via our upcoming Experimental draft) is Firefox, so I’d like to hear from them as to whether they’d support a proxy that terminates TLS for that use case, and whether they’d use such an identifier.
>> 
>> Finally, anything we do in this area is going to need to clear RFC6973, and I have significant concerns so far. To get this through, we’d need to show that using this approach doesn’t make privacy worse than it is, so again, it would be helpful if your draft discussed that explicitly.
> 
> as we are proposing to move http:// URIs traffic over TLS at least between the Browser and the authenticated Proxy 
> IMO this is something that improve the current situation and also reduce the passive monitoring

That’s *at best* speculative; are you really saying that it’s an improvement to the situation to insert a third party into people’s communication?


> and also standardise something that is already happening in a non standard way

As discussed extensively before, that is NOT a reason to push something through this WG; we do not standardise things just because they are already deployed. MITM is already widespread; that is not an excuse to standardise it. Instead, we should be looking for ways to minimise it.

In general, I’d like to discuss and agree upon what we’re trying to achieve before we go into the exact mechanism… there may be several other ways to get you what you want without doing this.


Regards,


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

Received on Monday, 16 June 2014 18:55:08 UTC