Re: explicitly authenticated proxy: new draft

Hi Mark,

thanks for the comments.
more in line

On Jun 13, 2014, at 9:12 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Sal,
> 
> Thanks for the update, and sorry for the belated response.
> 
> Easy things first - yes, the draft should be HTTP version-neutral. 
> 
> The parts that are specific to TLS and PKI need to be done in the TLS WG (or other appropriate venues); we don’t specify new key usages in this WG (Section 3.1), for example.

yes as I was saying, we are working to move the Proxy Certificate part on a standalone draft.
Note this is the only part PKI "specific" and it is not really TLS.
Indeed we are not really requesting any specific modification to TLS protocol, only the possibility for the Proxy
to present its own proxy certificate.

> 
> Requiring Forwarded (Section 5) is likely to be controversial, both from the standpoint of making optional features MTI, and privacy. Is that really integral to this proposal?

what we are proposing with Section 5 is to signal to both the end that the connection has an intermediary.
That is a attempt to address one of the requirement in the Vidya draft 

   o  User-agents and servers MUST know when a transforming proxy is
      interposed in the communications channel.

but it is not really an integral part of the proposal.

> 
> What’s left is (mostly) the “h2c” protocol identifier; however, that identifier is already defined by the WG to mean “HTTP/2 over cleartext” <http://http2.github.io/http2-spec/#versioning>. In light of that, what would you like to see? This came up in a couple of reviews, but I haven’t seen an answer yet.
> 
> Note that the WG has previously discussed having a distinction between “http” and “https” URIs in the ALPN protocol identifier; we can revisit this, but there was significant pushback at the time. It might be helpful if you were to focus your draft on just this issue (perhaps noting non-http changes, use cases, etc. in appendices).

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.

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,
in any case it will still up to the Browser if/when/how to send http:// URIs traffic thru the authenticated proxy.


> 
> However, the bigger issue is getting implementation; AIUI Opera Turbo is *not* HTTP; it’s a proprietary protocol with HTTP semantics, and therefore out-of-scope for this WG.

not entering in the specific product of others.
The prototype we have developed together with Opera is a standard Opera Browser that speaks standard HTTP with the proxy Ericsson Research has built
specifically for the demo.
The demo is to show how a standard browser can interact with a 3rd part authenticated proxy.

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

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

best regards
Salvatore


> 
> Cheers,
> 
> 
> On 12 Jun 2014, at 3:49 pm, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
> 
>> 
>> as Martin N. stated below Opera and Ericsson have spent some time to implement the auth-proxy draft
>> but at same time, as it is always the case, learned quite while implementing, putting together the different
>> part and testing them all together 
>> (the prototype is a modified browser running on Android and a proxy running on Linux)
>> 
>> I would summarise the main parts of the proposal in the following three:
>> - the pro-active attitude of the client to send http:// traffic over TLS
>> - the possibility for an end user to become aware of a proxy presence and the freedom
>> for the user to provide or not consent to it to "proxy" the http:// traffic over TLS and eventually
>> to revoke the consent. As you can imagine this part is mainly about how to modify the UI to do that.
>> - the ability of a proxy to identify itself thru a Proxy certificate
>> 
>> Martin N. is right when he says that at moment there is no other HTTP2 clients that pro-actively
>> sends any http traffic over TLS… and at moment it applies to Opera Turbo
>> but we have start from somewhere, isn't it?
>> I also agree that it is a scenario that is largely used in different products for HTTP/1.1
>> and would be also worth to discuss from that angle,
>> so in the next version I will try to generalise it for both HTTP/1.1 and HTTP/2
>> 
>> About the Proxy Certificate, for sure it needs more work to get it right from all the aspects.
>> However I have talked with several people that seem to like the idea 
>> and maybe are willing to put some cycles on it or on some aspect of it.
>> Unfortunately I haven't seen anyone yet sending those comments and suggestions publicly on 
>> the mailing list… so if you have please do that.
>> 
>> Yes I do think is a good idea to move the Proxy Certificate idea in a separate as it is
>> a concept that if well defined can be defined in several scenarios.
>> I am for sure willing to continue to work on it together with Martin and anyone else is interested
>> to work on it.
>> 
>> br
>> Salvatore
>> 
>> On Jun 12, 2014, at 5:31 PM, Martin Nilsson <nilsson@opera.com> wrote:
>> 
>>> On Mon, 05 May 2014 08:49:34 +0200, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
>>> 
>>>> 
>>>> we have produced a new draft that proposes the definition of an Explicitly Authenticated
>>>> Proxy as intermediary of normally unprotected "http://" URI scheme requests and responses of HTTP2 traffic.
>>>> 
>>> 
>>> We've spent some time at Opera implementing this to try see how it holds
>>> together. Given that it assumes that the client pro-actively sends http
>>> traffic over TLS it doesn't appear to apply cleanly on normal browsing,
>>> but it is applicable to Opera Turbo, where all http traffic is tunneled
>>> through our proxies. I fear it might be a bit too narrow use case as is to
>>> standardize. Some suggestions
>>> 
>>> - Given how the negotiation mechanism works this is locked to HTTP/2.
>>> There are still a lot of HTTP/1 use cases around for something like this.
>>> 
>>> - There are many places where root certificates are added to silently
>>> force proxies into TLS streams. I think those should be considered here as
>>> well (e.g. intercepting all TLS, but instead give the user the choice to
>>> abort the request). If we can move to a place where no one has a
>>> legitimate reason to modify the client root store, that would be an
>>> overall win.
>>> 
>>> - The client certificates needs work. Some of these fields are
>>> underspecified, like logo and presentation name. The certificates also
>>> need to be locked to a network, with that network information (APN,
>>> MCC/MNC etc) signed in the certificate. When the proxyFunctions are
>>> defined we should make them verifiable, and decide if they should describe
>>> effects (faster, smaller), functions (compression, caching) and/or
>>> privileges (modify content, inspect headers).
>>> 
>>> I think the proxy certificates is a nice idea that might even work outside
>>> of TLS connections to verify that you are using the expected proxy. I'll
>>> take a stab at defining it a bit more, possibly in a separate draft.
>>> 
>>> /Martin Nilsson
>>> 
>>> -- 
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>> 
>> 
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
>

Received on Monday, 16 June 2014 08:08:43 UTC