Subject: Re: explicitly authenticated proxy: new draft

From: "Martin Nilsson" <[email-masked]>
Date: Thu, 12 Jun 2014 16:31:22 +0200

On Mon, 05 May 2014 08:49:34 +0200, Salvatore Loreto  
<[email-masked]> 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/

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Jun 2014 19:49:55 +0000

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 <[email-masked]> wrote:

> On Mon, 05 May 2014 08:49:34 +0200, Salvatore Loreto <[email-masked]> 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.
>> 
>

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 13 Jun 2014 08:14:10 +0000

Hi Sal,

> I am for sure willing to continue to work on it together with Martin and anyone else is interested

+1.  This proxy certificate looks like a good building block.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Jun 2014 14:12:30 -0400

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,

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

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 15 Jun 2014 21:47:54 +0200

On Fri, 13 Jun 2014 20:12:30 +0200, Mark Nottingham <[email-masked]> wrote:

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

I agree that the direction this is taking is more suitable for TLS WG.

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

I think the major thing is to signal that the connection has an  
intermediary. I would probably prefer that the proxy certificate is sent  
to the TLS endpoint so that it is possible to use an authenticated proxy  
for anonymization while not hiding this from the endpoint (unless done so  
explicitly by withholding it). I don't think it is specified what happens  
if the client sends a certificate unrequested though. But that is a TLS  
discussion.

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

Continuing guessing the rationales behind the draft, I think "h2c" was  
used because the intent in ALPN as in alt-svc is the same: HTTP/2 without  
security. But we agree that a version neutral approach is better, and that  
would probably need another TLS extension.

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

True, but I would like to push it towards HTTP/2 with extensions so that  
it, if possible, is completely standards compliant. I know of about five  
different similar protocols in active use, so defining the framework they  
live in is of value. Possibly not (only) in this WG though.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 Jun 2014 17:01:38 -0700

On Sun, Jun 15, 2014 at 12:47 PM, Martin Nilsson <[email-masked]> wrote:

>> (or other appropriate venues); we don’t specify new key usages in this WG
>> (Section 3.1), for example.
>>
>

Note that the topic of explicitly authenticated proxies was raised in TLS a
while
back and there was not very much support.

That's not to say that opinion hasn't/won't change, but  it would require a
change.

-Ekr

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 16 Jun 2014 08:08:12 +0000

Hi Mark,

thanks for the comments.
more in line

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

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

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.

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

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Jun 2014 04:54:38 +1000

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

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

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Tue, 17 Jun 2014 00:55:24 +0000

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

As far as I can tell Stephen's objections were about a proxy acting as intermediary in a connection using HTTPS, where end-to-end peer authentication takes place. The draft deals with opportunistic TLS, and in this respect the explicit user consent proposed there is an advance with respect what could become a common practice of putting an intermediary the user is completely oblivious to. This can always be done when opportunistic encryption is intended, and proposals like draft-ietf-httpbis-http2-encryption do acknowledge they can only try to mitigate such behaviors.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jun 2014 02:23:53 +0100

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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Jun 2014 11:32:51 +1000

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,

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

---

From: lingli deng <[email-masked]>
Date: Tue, 17 Jun 2014 13:39:26 +0800

Hi Sal and Martin,

I am also interested in working on proxy certificate idea.

Lingli

2014-06-13 3:49 GMT+08:00 Salvatore Loreto <[email-masked]>:

> but at same time, as it is always the case, learned quite while
> implementing, putting together the different

-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]
tel: 15801696688-3367
mobile: 13810597148

---

From: Julian Reschke <[email-masked]>
Date: Tue, 17 Jun 2014 07:55:58 +0200

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

Well, this WG hasn't really worked on proxies at all, so picking on that 
specific aspect seems to be a bit far-fetched.

Best regards, Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 17 Jun 2014 09:45:56 +0000

> 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 *c…

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.

br
Salvatore

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Jun 2014 10:49:54 +1000

> not sure if OE/OS draft is the right place maybe it is, lets discuss it.

Yes; this is a good topic for Toronto (and on-list beforehand, of course).

> the consent request into the Browser and show to the end user.

It sounds a lot like you're talking about a "transparent" proxy -- i.e., one that's not explicitly configured by the user (or their administrator on their behalf). Is that the case, or do I misunderstand?

> and standardise the Proxy Certificate concept in the right wg.

Well, getting the venue right is certainly a concern, but just as important is making sure that both the browser implementer as well as the security and privacy communities are bought into the problem description as well as the outcome. 

> and request an explicit consent from the End User.

OK. I'll reiterate; sharing understanding about the use cases and goals will help move the discussion along much more effectively at this point.

Cheers,

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 18 Jun 2014 06:54:17 +0000

On Jun 18, 2014, at 3:49 AM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

maybe its me or maybe a terminology problem here.

does the fact that the configuration parameters are not explicitly inserted by hand (by the user or their administrator on their behalf) make the proxy a transparent one?
IMO a lots depends on how the automatic configuration happens.
The auth-draft is proposing a mechanism where the proxy manifests itself and asks the consent to the user (thru a popup window showing the right info to make
a conscious decision) and then only if the user provides consent that proxy is "automatically" configured by the proxy.
So at the end the user is always made aware of the fact that there is a proxy (the one that has manifest itself) in between himself and the content.
this mechanism, as proposed, actually is per network access and limited in time.

I think this proposal make even more explicit compared to a proxy configured by the administrator on behalf of the user or even of one configured by
the user and then forgotten.

note that  with this proposal all the power is in the users and browsers side,
the proxy only manifests itself and provides the Proxy certificate to authenticate itself.
What to do with the Proxy certificate, how to show the consent request to the end user,
and how to configure the browser in the "right way" in the case user provide consent
it will up to the browser.

/Sal

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jun 2014 15:42:59 +1000

On 18 Jun 2014, at 4:54 pm, Salvatore Loreto <[email-masked]> wrote:

> 
> On Jun 18, 2014, at 3:49 AM, Mark Nottingham <[email-masked]> wrote:
> 

Right. That approach has been consistently rejected by most browser security people, because it's very similar to a cert error; the user will just click through it to get to the information they want.

> I think this proposal make even more explicit compared to a proxy configured by the administrator on behalf of the user or even of one configured by the user and then forgotten.

The difference, I think, is that when you insert a security decision in the middle of a user action, the user is much less likely to make an informed decision. While the proxy configuration is hidden away in most browsers, it's set up as a separate mechanism. 

Furthermore, experience with HTTP authentication shows that limited-content dialogues with no presentation control by the authenticating party often don't provide enough context to make an informed decision. I suspect that the same dynamic will evidence here; a cert extension has very limited ability to convey information...

These are just my impressions based upon past conversations. Let's discuss this in Toronto and get some wider input.

Cheers,

---

From: Chris Bentzel <[email-masked]>
Date: Thu, 19 Jun 2014 05:40:06 -0400

Some good background reading about the effectiveness of user security:
https://www.cs.berkeley.edu/~devdatta/papers/alice-in-warningland.pdf

Another interesting one:
http://www.andrew.cmu.edu/user/nicolasc/publications/CEVG-FC11.pdf

There are many non-browser clients which speak http, which it seems like
are not being heavily considered here. Many of them may not have UI
affordances to deal with user consent in cases like this. Even if there is
enough UI surface to provide a user prompt, the developers may not have
even considered this case since it only happens on certain networks - we've
certainly seen this happen with HTTP authenticating proxies in the past.
The networking libraries they use would probably want good default behavior
here - which would likely be the "opt-out" decision. This mechanism then
adds additional client complexity for limited change in behavior.

On Thu, Jun 19, 2014 at 1:42 AM, Mark Nottingham <[email-masked]> wrote:

> >>> The draft proposes to use the Proxy Certificate as a way for the Proxy
> to authenticate itself and at same time trigger
> >> It sounds a lot like you're talking about a "transparent" proxy --
> i.e., one that's not explicitly configured by the user (or their
> administrator on their behalf). Is that the case, or do I misunderstand?
> >
> > does the fact that the configuration parameters are not explicitly
> inserted by hand (by the user or their administrator on their behalf) make
> the proxy a transparent one?
> > The auth-draft is proposing a mechanism where the proxy manifests itself
> and asks the consent to the user (thru a popup window showing the right
> info to make
> > a conscious decision) and then only if the user provides consent that
> proxy is "automatically" configured by the proxy.
> >
> > So at the end the user is always made aware of the fact that there is a
> proxy (the one that has manifest itself) in between himself and the content.
> Right. That approach has been consistently rejected by most browser
> security people, because it's very similar to a cert error; the user will
> just click through it to get to the information they want.
>
> > I think this proposal make even more explicit compared to a proxy
> configured by the administrator on behalf of the user or even of one
> configured by the user and then forgotten.
>
> The difference, I think, is that when you insert a security decision in
> the middle of a user action, the user is much less likely to make an
> informed decision. While the proxy configuration is hidden away in most
> browsers, it's set up as a separate mechanism.
>
> Furthermore, experience with HTTP authentication shows that
> limited-content dialogues with no presentation control by the
> authenticating party often don't provide enough context to make an informed
> decision. I suspect that the same dynamic will evidence here; a cert
> extension has very limited ability to convey information...
>
> These are just my impressions based upon past conversations. Let's discuss
> this in Toronto and get some wider input.
>
> Cheers,
>
> --