Re: explicitly authenticated proxy: new draft

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.

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

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.

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.

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 Friday, 13 June 2014 18:12:56 UTC