Subject: what about Proxies in Toronto?

From: Salvatore Loreto <[email-masked]>
Date: Thu, 12 Jun 2014 20:28:20 +0000

thanks to the productive meeting in NewYork we are almost done with HTTP/2,
this is really great.

As currently we have almost no issues open on HTTP2, 
perhaps we can take the opportunity to spend some time during the IETF in Toronto
(in the case the wg decides to meet in Toronto) to start to talk more about proxies 
and how to accommodate them in the new reality.

during the last months there have been several drafts authored by several people
describing problems about proxies, listening requirements and some drafting possible solutions;
and also good discussions about proxies in this mailing list and during the non official day in London
so we should have already enough to discuss and maybe we might also make some good progress
at least on the draft describing the proxy problems.

br
/Salvatore

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2014 22:55:44 +0200

> at least on the draft describing the proxy problems.

+1 - that's one thing that keeps coming up and that we have parked due 
to HTTP/2 being the priority.

There are also other things to think about for future HTTP work, such 
as, in no particular order:

- how to handle RFC723? errata

- addressing the C-E/Range Request issue

- enhanced discover of C-E support

- common header field syntax (JSON?)

...essentially all HTTP related topic that have come up in the past but 
was but aside due to other priorities.

Best regards, Julian

---

From: Jeroen de Borst <[email-masked]>
Date: Thu, 12 Jun 2014 20:57:22 +0000

+1

-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: Thursday, June 12, 2014 1:28 PM
To: HTTP Working Group
Subject: what about Proxies in Toronto?

thanks to the productive meeting in NewYork we are almost done with HTTP/2, this is really great.

As currently we have almost no issues open on HTTP2, perhaps we can take the opportunity to spend some time during the IETF in Toronto (in the case the wg decides to meet in Toronto) to start to talk more about proxies and how to accommodate them in the new reality.

during the last months there have been several drafts authored by several people describing problems about proxies, listening requirements and some drafting possible solutions; and also good discussions about proxies in this mailing list and during the non official day in London so we should have already enough to discuss and maybe we might also make some good progress at least on the draft describing the proxy problems.

br
/Salvatore

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jun 2014 10:06:46 -0700

> perhaps we can take the opportunity to spend some time during the IETF in Toronto

Perhaps we can spend some time discussing the topic on the list
beforehand.  That would help me a great deal in determining what - if
anything - needs discussion at a face-to-face meeting.

The big hole in this discussion is the user consent question.  I find
the answers presented thus far unsatisfactory.  Is there some new
information that can be shared in this regard?  Or, are there new
technical proposals that don't suffer from a dependency on users
making correct decisions?

---

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

Hi Sal,

> and how to accommodate them in the new reality.

Absolutely. Now that HTTP/1 has shipped and HTTP/2 is moving towards a more quiet phase, we can indeed turn to other things (with the understanding that there’s still work to do on HTTP/2 that will take priority when necessary). 

> at least on the draft describing the proxy problems.

So far, the proxy-related work that seems to have some level of consensus to continue upon has been:

## HTTP Proxy Problems

IIRC Julian volunteered to edit this if we choose to adopt it. Julian, is that still the case?

Do people support adopting this as a WG Draft (with a target of Informational)? If not, please explain why.

## Autoproxy.pac format

There was also significant interest in standardising the autoproxy.pac format, possibly extending or refining it along the way. However, we haven’t seen any drafts or discussion of that. Is anyone planning to propose something here?

## UX

Another thing mentioned in the London DTM was the need for UX. We said there (and I still agree) that this is *not* the venue for that discussion, but it needs to happen somewhere, and it’s likely to block what we do. Is anyone aware of a place where that is happening (W3C seems like an obvious possibility, but I haven’t heard anything from them)?

Beyond that, I think we’re still in the discussion phase. Are there other proxy-related work items people have in mind?

Cheers,

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Jun 2014 15:00:23 -0400

Hi Julian,

On 12 Jun 2014, at 4:55 pm, Julian Reschke <[email-masked]> wrote:
> 
> There are also other things to think about for future HTTP work, such as, in no particular order:
> 

That’s an administrative issue; we don’t need to be in the same room to figure it out.

> - addressing the C-E/Range Request issue

That needs a draft and a serious amount of discussion on-list first; two hours in a room in Toronto are not going to move it significantly forward if we don’t have those first.

Is anyone writing a draft here?

> - enhanced discover of C-E support

Again, we need a draft. Is anyone writing?

> - common header field syntax (JSON?)

This is VERY speculative (although I have thought about it too). I-D?

> ...essentially all HTTP related topic that have come up in the past but was but aside due to other priorities.

Indeed, these things are in-scope for our WG. However, we don’t necessarily have to meet to make progress on them, especially when they haven’t yet been discussed on-list.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jun 2014 23:07:07 +0200

> That needs a draft and a serious amount of discussion on-list first; two hours in a room in Toronto are not going to move it significantly forward if we don’t have those first.

I'm not sure how you decide when face-to-face makes sense or not :-)

> Again, we need a draft. Is anyone writing?

I already did ;-)

> This is VERY speculative (although I have thought about it too). I-D?

Yes.

> Indeed, these things are in-scope for our WG. However, we don’t necessarily have to meet to make progress on them, especially when they haven’t yet been discussed on-list.

Well, most of this has been discussed before.

I just wanted to point out that just because we currently don't have 
HTTP/2 issues to discuss doesn't mean a WG meeting wouldn't make sense.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jun 2014 23:14:52 +0200

> IIRC Julian volunteered to edit this if we choose to adopt it. Julian, is that still the case?

Yes, for holding the pen. But I'll need to rely on the proxy experts to 
provide input.

> There was also significant interest in standardising the autoproxy.pac format, possibly extending or refining it along the way. However, we haven’t seen any drafts or discussion of that. Is anyone…

I think we should find out whether our browser friends (MS, Moz, Google, 
Opera) are interested in improving interop here. We also should mine the 
issue trackers for known issues.

> Another thing mentioned in the London DTM was the need for UX. We said there (and I still agree) that this is *not* the venue for that discussion, but it needs to happen somewhere, and it’s likely…

W3C sounds right to me, but in the end what's relevant is *who* is 
participating, not *where*.
Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Jun 2014 14:22:12 -0700

> I'm not sure how you decide when face-to-face makes sense or not :-)

In a short time frame, like what we get in plenary, there is barely
enough time to even get warmed up on a difficult issue.  It took
basically half the day to get through the preliminaries on the
extensibility discussion in New York.  If we meet, I'd like to have a
clear set of goals.  I'd also like those goals to be realistic.

If those goals can be achieved through mailing list discussion, then
I'd be reluctant to ask people to travel long distances for what will
be a very short meeting.

I think that we probably will need face-to-face time to resolve the
C-E/Range Request issue.  But it needs a little more groundwork, in my
opinion.  And in my estimation, lots more time than we will get.  On
the other hand, client side C-E might be addressed without
face-to-face time.  And those are issues that have had some discussion
already.

---

From: James M Snell <[email-masked]>
Date: Fri, 13 Jun 2014 14:38:12 -0700

On Fri, Jun 13, 2014 at 2:07 PM, Julian Reschke <[email-masked]> wrote:
>> [snip]

How about support for *alternative* header syntax for existing fields.
Dates, for instance.

We can return to that again later I suppose.

- James

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 14 Jun 2014 07:50:49 +1000

> as, in no particular order:
​[...]​

> That needs a draft and a serious amount of discussion on-list first; two
> hours in a room in Toronto are not going to move it significantly forward
> if we don’t have those first.
>
I'm thinking about it
, but I'm not​
​ sure what approach to take. I have the start of a h2 extension-based
draft here, but that's only the tip of the iceberg.

> [...]

> This is VERY speculative (although I have thought about it too). I-D?
Or perhaps revisiting draft-snell-httpbis-bohe.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

On 14 June 2014 05:00, Mark Nottingham <[email-masked]> wrote:

> That needs a draft and a serious amount of discussion on-list first; two
> hours in a room in Toronto are not going to move it significantly forward
> if we don’t have those first.
>
> Indeed, these things are in-scope for our WG. However, we don’t
> necessarily have to meet to make progress on them, especially when they
> haven’t yet been discussed on-list.
>
> Cheers,
>
> --

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Jun 2014 00:02:25 -0400

On 13 Jun 2014, at 5:07 pm, Julian Reschke <[email-masked]> wrote:

> I just wanted to point out that just because we currently don't have HTTP/2 issues to discuss doesn't mean a WG meeting wouldn't make sense.

Of course.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jun 2014 09:01:03 +0200

On 2014-06-13 23:50, Matthew Kerwin wrote:
>
> On 14 June 2014 05:00, Mark Nottingham <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Julian,
>
>     On 12 Jun 2014, at 4:55 pm, Julian Reschke <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     That needs a draft and a serious amount of discussion on-list first;
>     two hours in a room in Toronto are not going to move it
>     significantly forward if we don’t have those first.
>
> draft here, but that's only the tip of the iceberg.>

As this is a HTTP/1.1 problem as well, the right solution IMHO is define 
a new range unit (bytes-before-content-coding).

> Or perhaps revisiting draft-snell-httpbis-bohe.

Again, this was about HTTP in general.

> ...

Best regards, Julian

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 14 Jun 2014 18:35:28 +1000

On 14 June 2014 17:01, Julian Reschke <[email-masked]> wrote:

>> I'm thinking about it, but I'm not​​ sure what approach to take. I have
>> the start of a h2 extension-based
> As this is a HTTP/1.1 problem as well, the right solution IMHO is define a
> new range unit (bytes-before-content-coding).
>
>
Not really -- HTTP/1.1 has transfer encoding, which is applied after ranges
(it also has the advantage(?) of compressing the range metadata,
eliminating the cost of all those duplicate 'Content-Type' headers). A
before-content-coding range request doesn't really make sense, especially
if you're not applying C-E dynamically (assuming the server has an
unencoded representation handy, assuming that encoding the range is somehow
equivalent to encoding the whole, etc.).

I think the C-E/Range request issue is unique to HTTP/2, except that nobody
seems to have implemented T-E in HTTP/1.1.

> Again, this was about HTTP in general.
I see.  In that case, why not XML?  ;)

---

From: Julian Reschke <[email-masked]>
Date: Sat, 14 Jun 2014 11:10:12 +0200

On 2014-06-14 10:35, Matthew Kerwin wrote:
> On 14 June 2014 17:01, Julian Reschke <[email-masked]
> <mailto:[email-masked]>>wrote:
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              On 12 Jun 2014, at 4:55 pm, Julian Reschke
>         <[email-masked] <mailto:[email-masked]>
>              <mailto:[email-masked]
>         <mailto:[email-masked]>>__> wrote:
>
>         I'm thinking about it, but I'm not​​ sure what approach to take.
>         I have the start of a h2 extension-based
>     As this is a HTTP/1.1 problem as well, the right solution IMHO is
>     define a new range unit (bytes-before-content-coding).
>
>
> Not really -- HTTP/1.1 has transfer encoding, which is applied after
> ranges (it also has the advantage(?) of compressing the range metadata,

But it's not used. What's easier: deploying a new range unit, or getting 
TE: gzip deployed?

> before-content-coding range request doesn't really make sense,

Why not? Do you think it wouldn't work? Please be a bit more concrete.

> especially if you're not applying C-E dynamically (assuming the server
> has an unencoded representation handy, assuming that encoding the range
> is somehow equivalent to encoding the whole, etc.).
>
> I think the C-E/Range request issue is unique to HTTP/2, except that
> nobody seems to have implemented T-E in HTTP/1.1.

See.

> I see.  In that case, why not XML?  ;)

I'm one of those people left who actually prefer XML to JSON in many 
cases. However I believe this isn't one of these cases.

Best regards, Julian

---

From: [email-masked]
Date: Sat, 14 Jun 2014 20:02:18 -0400

Martin on another thread: "The big hole in this discussion is the user consent question.  I find
the answers presented thus far unsatisfactory.  Is there some new
information that can be shared in this regard?  Or, are there new
technical proposals that don't suffer from a dependency on users
making correct decisions?"

I agree. Here's a straw man to get the discussion going: http://caffeinatetheweb.com/presentations/trusted_proxy.html.

Thanks,

Peter

---

From: Dan Wing <[email-masked]>
Date: Sun, 15 Jun 2014 11:18:30 -0700

>> perhaps we can take the opportunity to spend some time during the IETF in Toronto

Yes, please.   

> beforehand.  

Yes.

> That would help me a great deal in determining what - if

Yes for example see Peter Lepeska's post today, http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1281.html.  I think it could be implemented with a certificate that explained it is a proxy (in the certificate capabilities) without necessarily needing draft-mcgrew-tls-proxy-server by just seeing the presented certificate has capability=proxy.  draft-mcgrew-tls-proxy-server does provide some additional value.

-d

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Jun 2014 11:25:19 -0700

On 14 June 2014 17:02, <[email-masked]> wrote:
> I agree. Here's a straw man to get the discussion going:
> http://caffeinatetheweb.com/presentations/trusted_proxy.html.

I have a lot of questions, but I'll start with this one: is the decision to
accept the proxy a blocking one? That is, is the user able to use the Web
prior to making this decision? That makes a very big difference.

I also have a few things that you might like to think about:

https://bankofamerica.com/ might be a bad choice of example, though I'm
guessing that you chose a banking site intentionally. Personally, I find
the idea that there is a MitM on a connection to my bank to be almost as
disturbing as having my visit to a doctor monitored.

This sort of work might not be in scope here. I understand that we need to
have this discussion somewhere, but the IETF (and even the W3C) have so far
avoided dealing with these sorts of issues. That's probably not the right
answer, but I keep hearing that this is outside their area of expertise.

---

From: [email-masked]
Date: Sun, 15 Jun 2014 15:34:05 -0400

Hi Martin,

Thanks for taking a look.

"is the decision to accept the proxy a blocking one? That is, is the user able to use the Web prior to making this decision?"

Sorry if the presentation was not clear but the proxy is deployed inline so the user has no choice on whether or not the proxy will be able to process his/her bits. The question is whether or not the user wants to give the proxy consent to decrypt the TLS-encrypted bits. This is done by first importing the trusted proxy certificate, which is an identical process to importing a root certificate today. In fact I'd argue the proposed trusted proxy import dialog is more clear to the user that he/she is in fact allowing the proxy to decrypt and alter traffic than the root certificate import dialog is today.

"https://bankofamerica.com/ might be a bad choice of example, though I'm guessing that you chose a banking site intentionally. Personally, I find the idea that there is a MitM on a connection to my bank to be almost as disturbing as having my visit to a doctor monitored."

Yes. We intentionally showed a banking site because that might be one where many users decide to opt out of trusting the proxy, which is what is being demonstrated in that screenshot. Again, it's important to note that if the user had imported a root certificate he/she would see no notification when browsing to an https banking site and would not be prompted to opt out.

The whole idea of this proposal is to make it no different than today's MITM except for the fact that the user is made aware of the decryption and is able to opt out on a per site or on a global basis by either uninstalling the trusted proxy certificate or going to the browser settings and turning it off.

Thanks,

Peter

On Jun 15, 2014, at 2:25 PM, Martin Thomson <[email-masked]> wrote:

> I have a lot of questions, but I'll start with this one: is the decision to accept the proxy a blocking one? That is, is the user able to use the Web prior to making this decision? That makes a very big difference.
> 
> https://bankofamerica.com/ might be a bad choice of example, though I'm guessing that you chose a banking site intentionally. Personally, I find the idea that there is a MitM on a connection to my bank to be almost as disturbing as having my visit to a doctor monitored.
> 
> This sort of work might not be in scope here. I understand that we need to have this discussion somewhere, but the IETF (and even the W3C) have so far avoided dealing with these sorts of issues. That's probably not the right answer, but I keep hearing that this is outside their area of expertise.
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jun 2014 20:48:55 +0100

On 15/06/14 20:34, [email-masked] wrote:
> The whole idea of this proposal is to make it no different than
> today's MITM ...

I'm not sure that I'm exactly clear on what's proposed but in any case
the above is not at all attractive. I thought we had already had the
discussion here that ended up concluding that MITMing TLS is not the
way to try tackle an HTTP problem. The MITMing-TLS approach has been
proposed and rejected many times. If HTTP needs a proxy solution,
please aim to develop an HTTP solution and do not affect the many other
protocols and applications within and beyond the IETF that depend on
TLS and that do not need an MITM. And that might not have a user or
browser or equivalent.

I mean we could repeat all that debate, but it seems better not to do
that to me at least.

S.

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 15 Jun 2014 22:03:27 +0200

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

> Do people support adopting this as a WG Draft (with a target of  
> Informational)? If not, please explain why.

I approve of this, and when Julian and I spoke in New York I promised to  
support him with any information he needs from me.

> ## Autoproxy.pac format
>
> There was also significant interest in standardising the autoproxy.pac  
> format, possibly extending or refining it along the way. However, we  
> haven’t seen any drafts or discussion of that. Is anyone planning to  
> propose something here?

Richard Wheeldon and I discussed different methods to try to find out what  
the current use cases are, scanning existing autoproxy.pac files and  
looking over the code for the sandbox they are executed in. I would say  
that other aspects of proxies have higher priority, at least for me right  
now. On the other hand I fear that this will always be the case for  
everyone, which is probably why autoproxy.pac has such an open API right  
now.

> ## UX
>
> Another thing mentioned in the London DTM was the need for UX. We said  
> there (and I still agree) that this is *not* the venue for that  
> discussion, but it needs to happen somewhere, and it’s likely to block  
> what we do. Is anyone aware of a place where that is happening (W3C  
> seems like an obvious possibility, but I haven’t heard anything from  
> them)?

UX for what? We did have UX resources working on the explicit  
authenticated proxy prototype, but that is just one use case, that even  
might end up not being relevant for anyone.

/Martin Nilsson

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

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 15 Jun 2014 22:34:16 +0200

On Sun, 15 Jun 2014 21:48:55 +0200, Stephen Farrell  
<[email-masked]> wrote:

> proposed and rejected many times.

The problem is that it hasn't been rejected in practice. There are a lot  
of root certificates installed on the client side to facilitate  
MITM-TLS-proxies. This is not good.

The TLS aims to make communication with the highest degree of  
confidenitality and integrity possible. That is good. Unfortunately it is  
entirely binary, so if an intermediary wants to do anything with the  
traffic, block specific URLs or add additional headers, it has to drop the  
security to zero. That is not good.

/Martin Nilsson

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jun 2014 22:09:40 +0100

On 15/06/14 21:34, Martin Nilsson wrote:
> The problem is that it hasn't been rejected in practice. 

Please see the archives for earlier discussion. I'll try to
only make points I don't recall having been made on this
before.

> There are a lot

I would characterise the problem differently. There is no
HTTP proxy solution that has been adopted for the few (or
maybe even only one) real use-cases for policy checking of
TLS secured sessions.

> confidenitality and integrity possible. That is good. Unfortunately it
> is entirely binary, 

That is not correct. There are many independent parameters
affecting TLS and literally hundreds (unfortunately) of
ciphersuites with different properties, and in fact some of
which do offer NULL confidentiality.

> so if an intermediary wants to do anything with the
> traffic, block specific URLs or add additional headers, it has to drop
> the security to zero. 

See above. And "drop security to zero" is a meaningless
phrase.

Frankly, I think analysis such as yours above is very
obviously not a sound basis on which to propose significant
changes.

S.

> That is not good.

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 15 Jun 2014 23:48:24 +0200

> which do offer NULL confidentiality.

Having worked on a TLS implementation for the past year, I'm well aware of  
the richness of TLS parameters. They are however not available to the  
intermediary to modify, which is good. Even if they could modify them, it  
would essentially only be enable or disable encryption, which is too  
coarse control. Most policy enforcement doesn't need to see actual  
content, for example, or even URL. Well defined normalized URL hash is  
sufficient.

> See above. And "drop security to zero" is a meaningless

Underspecified at least. Block TLS traffic (or degrade it so users avoid  
TLS), doing MITM with private root certificate or explicitly MITM  
regardless of client certificates where the options I had in mind.

> obviously not a sound basis on which to propose significant

Calling it analysis is a bit of a stretch, so I think we agree. I aim to  
provide analysis in this direction though.

/Martin Nilsson

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 15 Jun 2014 22:16:45 +0000

On 15 Jun 2014, at 22:03 , Martin Nilsson <[email-masked]> wrote:

> I approve of this, and when Julian and I spoke in New York I promised to support him with any information he needs from me.

I support this.

And I miss in the list the draft on trusted proxies proposed by Salvatore. While it is probably not mature enough for WG adoption, I think it is worth continue discussion on it.

> Richard Wheeldon and I discussed different methods to try to find out what the current use cases are, scanning existing autoproxy.pac files and looking over the code for the sandbox they are executed in. I would say that other aspects of proxies have higher priority, at least for me right now. On the other hand I fear that this will always be the case for everyone, which is probably why autoproxy.pac has such an open API right now.

I exchanged some ideas on using JSON as the format for standardized PAC provision, that could be interesting as well for cases related with content delivery. But we certainly need here some degree of consensus from the browser makers.

> UX for what? We did have UX resources working on the explicit authenticated proxy prototype, but that is just one use case, that even might end up not being relevant for anyone.

I agree: It is hard to imagine how to make UX issues a matter for IETF...

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: [email-masked]
Date: Sun, 15 Jun 2014 23:01:47 -0400

Hi Stephen,

Our users want this so we are building it -- and we prefer to provide them with a mechanism to opt in and out on a per site basis as well as solve the problem of transitive trust introduced by standard MITM proxies. While changes to the TLS layer are not required, it is the most straightforward way to provide optimization for HTTPS web sites for a service provider that has already deployed web acceleration via proxies for HTTP-schemed web sites. Ideally the protocol changes we make to our proxy and our web browser, including users on commercial airlines like JetBlue and United, will be standardized so that our users will get optimization when using other browsers and also when they are using our browser when communicating with other proxies.

"If HTTP needs a proxy solution,please aim to develop an HTTP solution and do not affect the many other protocols and applications within and beyond the IETF that depend on TLS and that do not need an MITM."

What did you have in mind? I'm really interested in alternatives that do not involve modifying the TLS layer.

Thanks,

Peter

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 16 Jun 2014 03:07:30 +0000

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>

>If HTTP needs a proxy solution,

Is this a serious question?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jun 2014 11:34:43 +0100

Hiya,

On 16/06/14 04:01, [email-masked] wrote:
> Hi Stephen,
> 
> Our users want this so we are building it -- and we prefer to provide
> them with a mechanism to opt in and out on a per site basis as well
> as solve the problem of transitive trust introduced by standard MITM
> proxies. While changes to the TLS layer are not required, it is the
> most straightforward way to provide optimization for HTTPS web sites
> for a service provider that has already deployed web acceleration via
> proxies for HTTP-schemed web sites. Ideally the protocol changes we
> make to our proxy and our web browser, including users on commercial
> airlines like JetBlue and United, will be standardized so that our
> users will get optimization when using other browsers and also when
> they are using our browser when communicating with other proxies.

I think the word "user" in the above is conflating people (with a
browser), content authors and n/w operators, at least. I (as a
user visiting web sites) do not "want this," nor do I as a content
author, nor do I as a (very very tiny:-) web site admin. And I
definitely do not "want this" for my calendar nor IMAP etc.

So I don't agree that borking TLS is the most straightforward way
to do something that I want, for at least 3 or 4 definitions of
me as a user. And I'm pretty sure that I'm not at all alone in that.
(But wasn't a lot of the above said already on this list?)

> "If HTTP needs a proxy solution,please aim to develop an HTTP
> solution and do not affect the many other protocols and applications
> within and beyond the IETF that depend on TLS and that do not need an
> MITM."
> 

Mostly I have in mind not borking TLS;-)

I'm sorry to seem so negative here, but when there are such
conflicting requirements, I guess that's gonna be the case.
In my defence, I think I can fairly claim that "don't bork
TLS" is actually a positive statement overall.

Cheers,
S.

>> I'm not sure that I'm exactly clear on what's proposed but in any
>> case the above is not at all attractive. I thought we had already
>> had the discussion here that ended up concluding that MITMing TLS
>> is not the way to try tackle an HTTP problem. The MITMing-TLS
>> approach has been proposed and rejected many times. If HTTP needs a
>> proxy solution, please aim to develop an HTTP solution and do not
>> affect the many other protocols and applications within and beyond
>> the IETF that depend on TLS and that do not need an MITM. And that
>> might not have a user or browser or equivalent.
>> 
>> I mean we could repeat all that debate, but it seems better not to
>> do that to me at least.
>> 
>> S.
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 16 Jun 2014 04:33:31 -0700

Apologies for the slow reply. I'm still traveling around Iceland and you
can expect high latency on responses from me (I'll be hiking some mountain
summits / glaciers these next few days).

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

> "is the decision to accept the proxy a blocking one? That is, is the user
> able to use the Web prior to making this decision?"
>
> Sorry if the presentation was not clear but the proxy is deployed inline
> so the user has no choice on whether or not the proxy will be able to
> process his/her bits. The question is whether or not the user wants to give
> the proxy consent to decrypt the TLS-encrypted bits. This is done by first
> importing the trusted proxy certificate, which is an identical process to
> importing a root certificate today. In fact I'd argue the proposed trusted
> proxy import dialog is more clear to the user that he/she is in fact
> allowing the proxy to decrypt and alter traffic than the root certificate
> import dialog is today.
>

It's definitely offering more information, although the information may
mislead the user.

>
> "https://bankofamerica.com/ might be a bad choice of example, though I'm
> disturbing as having my visit to a doctor monitored."
>
> Yes. We intentionally showed a banking site because that might be one
> where many users decide to opt out of trusting the proxy, which is what is
> being demonstrated in that screenshot. Again, it's important to note that
> if the user had imported a root certificate he/she would see no
> notification when browsing to an https banking site and would not be
> prompted to opt out.
>

As shown in the presentation, the opt out happens after the fact. So the
proxy already was able to decrypt the first navigation, which is
problematic from a privacy/security perspective. Also, there needs to be
clarity around whether or not this applies on an origin granularity. Also,
there are security issues with regards to caching subresources (especially
active content like script) which may have been hosted on 3rd party
origins. The taint analysis here is very complicated and perhaps even
intractable.

Also, showing an infobar on every single new HTTPS website navigated to
sounds like it may lead to UI fatigue.

>
> The whole idea of this proposal is to make it no different than today's
> MITM except for the fact that the user is made aware of the decryption and
> is able to opt out on a per site or on a global basis by either
> uninstalling the trusted proxy certificate or going to the browser settings
> and turning it off.
>
> Thanks,
>
> Peter
>
>
> I have a lot of questions, but I'll start with this one: is the decision
> to accept the proxy a blocking one? That is, is the user able to use the
> Web prior to making this decision? That makes a very big difference.
>

---

From: [email-masked]
Date: Mon, 16 Jun 2014 10:05:15 -0400

Hi Stephen,

Since pinning is not enforced if the trust anchor is a user inserted CA, browsers support MITM today. Whether this is TLS being borked or HTTP being borked  I don't know. 

But by burying your head in the sand you are implicitly advocating:

MITM without user notification
Non-enforcement of pinned certs
Forgery of certificates and therefore transitive trust

As opposed to what I'm proposing (Mcgrew draft plus something like http://caffeinatetheweb.com/presentations/trusted_proxy.html) which in broad terms is:
User notification of the presence of trusted proxies
The ability for users to opt out on a per site basis or globally
Pinned cert enforcement
Ability for user and browser to examine the original certificate

Yes we have had this discussion previously. But I don't think we reached consensus. Also, the fact that my company is building a browser and looking for protocol design and security inputs on trusted proxy from the community is a new development. It'd be great to get your thoughts on how best to do it from a security perspective.

Thanks,

Peter

---

From: [email-masked]
Date: Mon, 16 Jun 2014 10:19:32 -0400

Hi Will,

Thanks for your inputs. Enjoy the trekking!

A few follow up comments inline -- no rush to reply.

Peter

On Jun 16, 2014, at 7:33 AM, William Chan (陈智昌) <[email-masked]> wrote:

> Apologies for the slow reply. I'm still traveling around Iceland and you can expect high latency on responses from me (I'll be hiking some mountain summits / glaciers these next few days).
> 
> It's definitely offering more information, although the information may mislead the user.
I find the current CA import dialog very misleading. Also it puts the burden of informing the user about what they are agreeing to on what is contained in the certificate. I'd like to be less misleading if at all possible so if you can think of improvements on what I have here let me know.

> As shown in the presentation, the opt out happens after the fact. So the proxy already was able to decrypt the first navigation, which is problematic from a privacy/security perspective. Also, there needs to be clarity around whether or not this applies on an origin granularity. Also, there are security issues with regards to caching subresources (especially active content like script) which may have been hosted on 3rd party origins. The taint analysis here is very complicated and perhaps even intractable.
I agree that this is a big problem. We have alternate treatments where we ask the user prior to going to visiting a page but these just seemed very clunky and would be even more annoying to the user than the info bar on every single new HTTPS web site. Also, since the user decided to import the trusted proxy certificate in the first place he/she is agreeing at some level to trust the proxy. But I agree that opt-out after the fact is a big weakness in the proposed model.

I don't follow what you are saying about security issues around caching sub resources for active content? How is it different from when trusted proxy is not active? 

> 
> Also, showing an infobar on every single new HTTPS website navigated to sounds like it may lead to UI fatigue.
Yes agreed. But is it worse than what Chrome supports today in allowing MITM without any notification all? It'd be great to come up with ways to improve this experience.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jun 2014 15:57:02 +0100

Hi Peter,

On 16/06/14 15:05, [email-masked] wrote:
> Hi Stephen,
> 
> Since pinning is not enforced if the trust anchor is a user inserted
> CA, browsers support MITM today. Whether this is TLS being borked or
> HTTP being borked  I don't know.
> 
> But by burying your head in the sand

I suspect my head is above at least one parapet:-)

The metaphor is also fairly unfair. I'm disagreeing with
your proposed solution, not ignoring it.

Were I to accuse the proponents of various ways of
borking TLS of burying their heads in the sand because
they have clearly not done the analysis of all the
impacts of such, that would be equally unfair. So I've
not:-)

But here's [1] the list of the 195 RFCs that cite RFC
5246 in case that helps. And here's [2] the list of
1785 publications that Google scholar lists that cite
RFC 5246. When someone has produced an analysis of the
impact of their favourite way to make the major change
of adding a 3rd party to TLS on those then I will be
interested in reading that. The corresponding numbers
for RFC 2246 are 167 RFCs and 3155 citations btw, and
those also need to be considered.

Yes, that is quite an ask. But a major change to a
very widely used protocol like TLS should be.

> you are implicitly advocating:
> 
> MITM without user notification Non-enforcement of pinned certs 

I am definitively not "advocating" for any such thing.

> As opposed to what I'm proposing (Mcgrew draft plus something like
> http://caffeinatetheweb.com/presentations/trusted_proxy.html) which
> in broad terms is: User notification of the presence of trusted
> proxies The ability for users to opt out on a per site basis or
> globally Pinned cert enforcement Ability for user and browser to
> examine the original certificate
> 
> Yes we have had this discussion previously. But I don't think we
> reached consensus. Also, the fact that my company is building a
> browser and looking for protocol design and security inputs on
> trusted proxy from the community is a new development. It'd be great
> to get your thoughts on how best to do it from a security
> perspective.

I think "trusted proxy" is a misnomer and misleading and
in general "trusted foo" is probably better not part of
any technical discussion on this topic since the question
of who is trusting whom for what is complex here and
ignoring that complexity IMO does a disservice to the
various interested parties.

And from a security perspective: the best way to not
bork TLS is just that.

Cheers,
S.

[1] http://www.arkko.com/tools/allstats/citations-rfc5246.html
[2]
http://scholar.google.com/scholar?q=http%3A%2F%2Fwww.hjp.at%2Fdoc%2Frfc%2Frfc5246.html&btnG=&hl=en&as_sdt=0%2C5

>>> Our users want this so we are building it -- and we prefer to
>>> provide them with a mechanism to opt in and out on a per site
>>> basis as well as solve the problem of transitive trust introduced
>>> by standard MITM proxies. While changes to the TLS layer are not
>>> required, it is the most straightforward way to provide
>>> optimization for HTTPS web sites for a service provider that has
>>> already deployed web acceleration via proxies for HTTP-schemed
>>> web sites. Ideally the protocol changes we make to our proxy and
>>> our web browser, including users on commercial airlines like
>>> JetBlue and United, will be standardized so that our users will
>>> get optimization when using other browsers and also when they are
>>> using our browser when communicating with other proxies.
>> 
>> browser), content authors and n/w operators, at least. I (as a user
>> visiting web sites) do not "want this," nor do I as a content 
>> to do something that I want, for at least 3 or 4 definitions of me
>> as a user. And I'm pretty sure that I'm not at all alone in that. 
>>> solution and do not affect the many other protocols and
>>> applications within and beyond the IETF that depend on TLS and
>>> that do not need an MITM."
>>> 
>>> What did you have in mind? I'm really interested in alternatives
>>> that do not involve modifying the TLS layer.
>> 
>> conflicting requirements, I guess that's gonna be the case. In my
>> defence, I think I can fairly claim that "don't bork TLS" is
>> actually a positive statement overall.
>> 
>> Cheers, S.
>> 
>> 
>>> 
>>> Thanks,
>>> 
>>> Peter
>>> 
>>> 
>>>>> The whole idea of this proposal is to make it no different
>>>>> than today's MITM ...
>>>> 
>>>> I'm not sure that I'm exactly clear on what's proposed but in
>>>> any case the above is not at all attractive. I thought we had
>>>> already had the discussion here that ended up concluding that
>>>> MITMing TLS is not the way to try tackle an HTTP problem. The
>>>> MITMing-TLS approach has been proposed and rejected many times.
>>>> If HTTP needs a proxy solution, please aim to develop an HTTP
>>>> solution and do not affect the many other protocols and
>>>> applications within and beyond the IETF that depend on TLS and
>>>> that do not need an MITM. And that might not have a user or
>>>> browser or equivalent.
>>>> 
>>>> I mean we could repeat all that debate, but it seems better not
>>>> to do that to me at least.
>>>> 
>>>> S.
>>> 
>>> 
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jun 2014 09:55:42 -0700

> various interested parties.

This is a point that I need to emphasize.  The labels "trusted proxy"
and "secure proxy" are misnomers in the very best Orwellian tradition.
Those labels need to be used less casually.  Here, I note that Sal
gets this right, concentrating on factual aspects - i.e., explicitly
authenticated - even if this point probably needs to be better
supported.

If we have a proxy for which its primary purpose is policy
enforcement, then we can label that a policy enforcement proxy.

---

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

I do agree having the right terminology helps  

the Explicit Authenticated Proxy (as proposed in the draft) is supposed to do a really narrow and limited job
that is to proxy http:// URI traffic transported over TLS
and it is something completely different from what is in the subject of this mail
and discussed in this thread;

/Sal

---

From: [email-masked]
Date: Mon, 16 Jun 2014 14:42:01 -0400

Right. I think of "trusted proxy" as a thing that decrypts HTTPS URIs. We can come up with other names if that doesn't work.

Peter

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 16 Jun 2014 12:47:05 -0700

>>> "is the decision to accept the proxy a blocking one? That is, is the
user able to use the Web prior to making this decision?"
>>>
>>> Sorry if the presentation was not clear but the proxy is deployed
inline so the user has no choice on whether or not the proxy will be able
to process his/her bits. The question is whether or not the user wants to
give the proxy consent to decrypt the TLS-encrypted bits. This is done by
first importing the trusted proxy certificate, which is an identical
process to importing a root certificate today. In fact I'd argue the
proposed trusted proxy import dialog is more clear to the user that he/she
is in fact allowing the proxy to decrypt and alter traffic than the root
certificate import dialog is today.
mislead the user.
>
> I find the current CA import dialog very misleading. Also it puts the
burden of informing the user about what they are agreeing to on what is
contained in the certificate. I'd like to be less misleading if at all
possible so if you can think of improvements on what I have here let me
know.
>
>>
>>>
>>>
>>> "https://bankofamerica.com/ might be a bad choice of example, though
I'm guessing that you chose a banking site intentionally. Personally, I
find the idea that there is a MitM on a connection to my bank to be almost
as disturbing as having my visit to a doctor monitored."
>
> I agree that this is a big problem. We have alternate treatments where we
ask the user prior to going to visiting a page but these just seemed very
clunky and would be even more annoying to the user than the info bar on
every single new HTTPS web site. Also, since the user decided to import the
trusted proxy certificate in the first place he/she is agreeing at some
level to trust the proxy. But I agree that opt-out after the fact is a big
weakness in the proposed model.
>
> I don't follow what you are saying about security issues around caching
sub resources for active content? How is it different from when trusted
proxy is not active?

Let's say I visit https://foo.com which uses a jQuery URL (perhaps hosted
by a CDN like Google's). A MITM proxy can cause a non-canonical version of
jQuery to be cached. Now I visit https://bar.com which also references the
same jQuery URL, but I want to opt out of https://bar.com getting MITM'd.
In the fallback, does it load the tainted jQuery resource from cache? Even
if not, it's important to note that once tainted active web content is
loaded once, it can spread virally to other web storage beyond the cache,
like localStorage, IndexedDB, etc and acquire web permissions (Geolocation,
webcam, etc).

For more details, please refer to
https://code.google.com/p/chromium/issues/detail?id=81623#c15 and other
comments on that bug thread.

>
> Yes agreed. But is it worse than what Chrome supports today in allowing
MITM without any notification all? It'd be great to come up with ways to
improve this experience.

It's probably worse. It's risky to take the approach of "better to show
something than nothing at all" if the something just trains users to ignore
your signals. Maybe later we will come up with a better heuristic, but
we've already trained people to ignore our UI warnings. A better way would
perhaps be something like suggested in
https://code.google.com/p/chromium/issues/detail?id=81623. But
unfortunately, due to the technical issue I referenced earlier with
tainting web resources that were MITM'd, we can't provide a meaningful UI
indicator.

>>>> I have a lot of questions, but I'll start with this one: is the
decision to accept the proxy a blocking one? That is, is the user able to
use the Web prior to making this decision? That makes a very big difference.
>>>> https://bankofamerica.com/ might be a bad choice of example, though
I'm guessing that you chose a banking site intentionally. Personally, I
find the idea that there is a MitM on a connection to my bank to be almost
as disturbing as having my visit to a doctor monitored.
>>>>
>>>> This sort of work might not be in scope here. I understand that we
need to have this discussion somewhere, but the IETF (and even the W3C)
have so far avoided dealing with these sorts of issues. That's probably not
the right answer, but I keep hearing that this is outside their area of
expertise.

---

From: [email-masked]
Date: Mon, 16 Jun 2014 22:57:32 -0400

From your MITM cache tainting issue: https://code.google.com/p/chromium/issues/detail?id=81623#c15

"Trying to do better than that seems very difficult. We could split the cache, but then we don't know which cache to use until we make an SSL connection and see whether it's a MITM connection. That completely twists the HTTP stack around and I don't think we would do that for a feature this minor."

The more important question is whether or not tainted content is being served, not whether or not the user has been informed. I'm surprised this is considered a minor feature. Since chrome can detect the difference between MITM'd content and non-MITM'd content, I would expect it to keep those in different cache partitions. In any case, this seems like one of many implementation details that will need to be sorted out with the addition of trusted proxy support that no doubt should have been sorted out with the implicit support for MITMs long ago.

Thanks,

Peter

On Jun 16, 2014, at 3:47 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Let's say I visit https://foo.com which uses a jQuery URL (perhaps hosted by a CDN like Google's). A MITM proxy can cause a non-canonical version of jQuery to be cached. Now I visit https://bar.com which also references the same jQuery URL, but I want to opt out of https://bar.com getting MITM'd. In the fallback, does it load the tainted jQuery resource from cache? Even if not, it's important to note that once tainted active web content is loaded once, it can spread virally to other web storage beyond the cache, like localStorage, IndexedDB, etc and acquire web permissions (Geolocation, webcam, etc).
> 
> For more details, please refer to https://code.google.com/p/chromium/issues/detail?id=81623#c15 and other comments on that bug thread.
> 
> >
> >>
> It's probably worse. It's risky to take the approach of "better to show something than nothing at all" if the something just trains users to ignore your signals. Maybe later we will come up with a better heuristic, but we've already trained people to ignore our UI warnings. A better way would perhaps be something like suggested in https://code.google.com/p/chromium/issues/detail?id=81623. But unfortunately, due to the technical issue I referenced earlier with tainting web resources that were MITM'd, we can't provide a meaningful UI indicator.
> 
> >
> >>  
> >>>
> >>>

---

From: [email-masked]
Date: Mon, 16 Jun 2014 23:12:57 -0400

Thinking about this some more. In particular this:

"It's probably worse. It's risky to take the approach of "better to show something than nothing at all" if the something just trains users to ignore your signals. Maybe later we will come up with a better heuristic, but we've already trained people to ignore our UI warnings. A better way would perhaps be something like suggested in https://code.google.com/p/chromium/issues/detail?id=81623. But unfortunately, due to the technical issue I referenced earlier with tainting web resources that were MITM'd, we can't provide a meaningful UI indicator."

To avoid warning fatigue, maybe it's better to not do the UI warning via the infobar but just show the user the trusted proxy logo to the left of the lock. This is a constant reminder that the trusted proxy is seeing the encrypted traffic without presenting as a warning to learn to be ignored.

Peter

---

From: "Martin Nilsson" <[email-masked]>
Date: Wed, 18 Jun 2014 10:15:53 +0200

On Tue, 17 Jun 2014 05:12:57 +0200, <[email-masked]> wrote:

>
> To avoid warning fatigue, maybe it's better to not do the UI warning via  
> the infobar but just show the user the trusted proxy logo to the left of  
> the >lock. This is a constant reminder that the trusted proxy is seeing  
> the encrypted traffic without presenting as a warning to learn to be  
> ignored.
>

For many use cases a per domain opt-in may be more appropriate.

/Martin Nilsson

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

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 18 Jun 2014 13:48:43 +0200

> jQuery to be cached.

This seems a strawman for me – if you've gone to the length of checking
external code is safe from a security POW it is *idiotic* not to host the
checked version on your own site instead of relying on an external
reference.

OTOH if you're referencing something from a third party, you've already
delegated your security and adding a proxy to the mix is not going to
change a lot to the situation. And don't tell me the people who do this
monitor the reference to check for changes and audit those changes.

And you can argue you trust the third party more than the proxy, but
that's *your* opinion not necessarily the opinion of your users so the
transitive trust issue was opened up the moment js hosting was delegated
to a third party. Current browser UI does not inform users that when they
visit nicecite.com they're really executing monitoring.js from
bigbrother.com.

The nice thing about proxying is that is exposes all the trust issues
caused by mashing up resources without thinking about the security
aspects, instead of burying them in the browser cache where no one thinks
to look before it's too late.

-- 
Nicolas Mailhot

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Jun 2014 13:59:37 -0400

The biggest problem with all of this is that you're making an
unreasonable assumption at the start: that users can reasonably "opt
out" of a <strike>privacy-invading</strike> "trusted" proxy.  (And,
yes, we have to call it something else: the *user* certainly does not
trust the proxy.)

1. If such a thing were to be deployed, it would immediately be
deployed in a way where the option to accept the proxy's intervention
becomes a Hobson's choice: either you accept the proxy or you don't
get to the web site you're trying to get to.  What do you think a user
(see below) will do in that situation?

2. It's simply unreasonable to imagine that users -- real users out
there, not "users" that really means operators, or content providers,
or browser makers, or whatever -- will have the first idea what
they're really giving up by accepting the proxy, nor that they will
have any understanding of what your UI markers (a "trusted proxy logo"
or any such thing) mean.  They will not have a clue, and they will not
be making an informed decision to put themselves in a position where,
for example, this proxy that they don't really trust now has their
username and password for their bank.

To believe otherwise is to ignore all research that's been done on this stuff.

Barry

On Mon, Jun 16, 2014 at 11:12 PM,  <[email-masked]> wrote:
> "It's probably worse. It's risky to take the approach of "better to show
> your signals. Maybe later we will come up with a better heuristic, but we've
> already trained people to ignore our UI warnings. A better way would perhaps
> be something like suggested in
> unfortunately, due to the technical issue I referenced earlier with tainting
> web resources that were MITM'd, we can't provide a meaningful UI indicator."
>
> To avoid warning fatigue, maybe it's better to not do the UI warning via the
> infobar but just show the user the trusted proxy logo to the left of the
> lock. This is a constant reminder that the trusted proxy is seeing the
> encrypted traffic without presenting as a warning to learn to be ignored.
>
> Peter

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jun 2014 12:30:52 -0700

> To believe otherwise is to ignore all research that's been done on this stuff.

Yes, and I'd point out that the sort of things that Will refers to
undermine the integrity of the user-site contract from the perspective
of the site operator too.

---

From: [email-masked]
Date: Wed, 18 Jun 2014 16:24:21 -0400

> It's simply unreasonable to imagine that users -- real users out
> they're really giving up by accepting the proxy

But the situation is much worse today! Look at the dialog on the left: http://caffeinatetheweb.com/presentations/trusted_proxy.html#/3

At least what I am proposing involves telling the user explicitly that the certificate enables the proxy to decrypt and alter traffic. And then provides an indication that it is active and a means to disable it. You don't see this as an improvement over the current MITM functionality supported in all the mainstream browsers?

Again, because pinning is not enforced if the trust anchor is a user installed CA, browser manufacturers are in fact choosing to support MITM proxies. But they are doing it without informing the user when it is being enabled and without any indication to the user when it's active.  I don't understand why anyone would defend the status quo on this.

Stephen doesn't like my metaphor, but I still see not improving this as burying our heads in the sand.

Thanks,

Peter

---

From: Jason Greene <[email-masked]>
Date: Wed, 18 Jun 2014 15:28:29 -0500

> of the site operator too.

IMO this topic points at a general need for the web to have finer grained encryption. Some content on a connection should be unreadable to intermediaries (perhaps using session based encryption based on out of channel negotiated keys). Other content simply needs to be signed (i.e. address the cache poisoning example Will mentions). The remaining presentation oriented content is freely cacheable without concern.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Roland Zink <[email-masked]>
Date: Wed, 18 Jun 2014 23:00:01 +0200

I think the user will not have an idea on what they give up by accepting 
a proxy. However I see also a problem in companies, criminals and 
intelligence agencies taking over my devices and home, find out who 
comes to visit, who shares a bed and send whatever they want over TLS. 
Enforcing a decrypting proxy in between would allow to get some privacy 
back. However in both directions if there is something which needs to be 
really secured there will be a second level of encryption.

Roland

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Jun 2014 17:02:05 -0400

> But the situation is much worse today! Look at the dialog on the left:
> http://caffeinatetheweb.com/presentations/trusted_proxy.html#/3

I don't see any sense in which the dialogue on the right is better.
They're both useless, and neither should be presented to my mother.

> At least what I am proposing involves telling the user explicitly that the
> certificate enables the proxy to decrypt and alter traffic. And then
> provides an indication that it is active and a means to disable it. You
> don't see this as an improvement over the current MITM functionality
> supported in all the mainstream browsers?

I don't see it as an improvement because it's nothing that most users
will understand.  To most users, there will be no difference.

The problem isn't that we're not telling users that our proxies can
snoop and modify.  The problem is that we're allowing a situation
where our proxies can snoop and modify.

> Again, because pinning is not enforced if the trust anchor is a user
> installed CA, browser manufacturers are in fact choosing to support MITM
> proxies. But they are doing it without informing the user when it is being
> enabled and without any indication to the user when it's active.  I don't
> understand why anyone would defend the status quo on this.

It's not a question of defending the status quo.  If we're going to
fix this, we need to fix it correctly: we need to tighten up the
protocols and how they're used so that we shut down men in the middle.
And then we have to teach users to use only browsers that do it right
and don't expose them.  We'd do that through major media campaigns
with understandable explanations, not with incomprehensible popup
messages that users won't understand.

Barry

---

From: "Martin Nilsson" <[email-masked]>
Date: Thu, 19 Jun 2014 04:11:26 +0200

> where our proxies can snoop and modify.

The problem is also that since it has been possible for 20 years a lot of  
systems depend on it. TLS has been widely implemented and deployed, but  
not widely adopted until recently, which is causing consternation. While  
it is mostly services that just stops working (mobile payment, top up  
interstitials, etc), some are more subtle, like indiscriminate throttling  
of TLS traffic during congestion, since correct QoS can't be assigned  
based on DPI.

/Martin Nilsson

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 19 Jun 2014 02:46:12 +0000

I think any efforts to block out the possibility for intermediaries to 
inspect and modify traffic in HTTP would be wasted.

You're unlikely to be able to convince the operators of every corporate 
network in the world that they no longer need to do this to their users' 
traffic.

Putting that sort of thing into http/2.0 would simply result in the 
failure of that protocol to be adopted / allowed in these networks.

Not all https traffic is desirable (e.g. malware downloads, uploading 
company secrets to file sharing sites etc).  The user is not always the 
one with all the rights, sometimes network operators must assert their 
rights and terms of use for their networks.

---

From: [email-masked]
Date: Thu, 19 Jun 2014 11:39:35 -0400

Right.

Barry is introducing a third option, which is to disable all mechanisms for HTTPS decryption by proxies. 

So to summarize:

A) Trusted proxy with notification and user control
B) Today's MITM with user installed CAs
C) Disable all mechanisms for HTTPS decryption by proxies.

A test of the viability of C is the way that pinned certs are handled. If a given browser were to enforce them then that browser would immediately stop working completely within a large number of corporate networks. Which browser manufacturer is going to make this change?

In my opinion, our choices are between doing nothing and improving on the status quo without introducing any new vulnerabilities.

Thanks,

Peter

On Jun 18, 2014, at 10:46 PM, Adrien de Croy <[email-masked]> wrote:

> 
> I think any efforts to block out the possibility for intermediaries to inspect and modify traffic in HTTP would be wasted.
> 
> You're unlikely to be able to convince the operators of every corporate network in the world that they no longer need to do this to their users' traffic.
> 
> Putting that sort of thing into http/2.0 would simply result in the failure of that protocol to be adopted / allowed in these networks.
> 
> Not all https traffic is desirable (e.g. malware downloads, uploading company secrets to file sharing sites etc).  The user is not always the one with all the rights, sometimes network operators must assert their rights and terms of use for their networks.
> 
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 19 Jun 2014 12:33:34 -0700

> monitor the reference to check for changes and audit those changes.

The need to trust a third party is definitely a problem for content authors
today. This is one use case for the Subresource Integrity proposal:
http://www.w3.org/TR/2014/WD-SRI-20140318/#resource-integrity-1.

That said, I do not agree with your assertion that referencing content from
a third party is equivalent to being willing to trust a proxy. I am frankly
surprised to hear such a statement. Does anyone else agree with this?

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 19 Jun 2014 22:25:37 +0000

My own view is that C is unviable.

Until such time as you can prevent malware authors from using HTTPS, 
there will remain significant pressure to decrypt or block https.

Putting all the power in the hands of the browser user is misguided.

The user can always choose not to proceed, and the proxy operator can 
always block.  Those things won't change.  I think the best way forward 
is to provide a framework where the user can make the best decisions, 
and the proxy operator can be the most permissive.

Adrien

------ Original Message ------
From: "[email-masked]" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Barry Leiba" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 20/06/2014 3:39:35 a.m.
Subject: Re: Trusted proxy UI strawman

>A test of the viability of C is the way that pinned certs are handled. 
>If a given browser were to enforce them then that browser would 
>immediately stop working completely within a large number of corporate 
>networks. Which browser manufacturer is going to make this change?
>
>In my opinion, our choices are between doing nothing and improving on 
>the status quo without introducing any new vulnerabilities.
>
>Thanks,
>
>Peter
>
>
>>  I think any efforts to block out the possibility for intermediaries 
>>to inspect and modify traffic in HTTP would be wasted.
>>
>>  You're unlikely to be able to convince the operators of every 
>>corporate network in the world that they no longer need to do this to 
>>their users' traffic.
>>

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Fri, 20 Jun 2014 00:46:53 +0000

> I think any efforts to block out the possibility for intermediaries to inspect and modify traffic in HTTP would be wasted.

Nor is it desirable, IMHO. There's an implicit assumption in the idea that proxies shouldn't interfere that the that
endpoints (hosts or servers) are themselves trustworthy. Whilst this might be the majority case, it's certainly
not universally true by a long way.

Take for example the Microsoft stats on infected hosts:
	http://www.microsoft.com/eu/on-the-issues/article/windows-xp-losing-pace-in-the-eu.aspx
or those which are running with limited protection:
	http://www.microsoft.com/security/sir/story/default.aspx#!why_upgrade
or any amount of evidence into the volumes of Windows and Android malware. 

In many cases the network is going to be in a better state than the endpoint,

Richard

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Fri, 20 Jun 2014 00:52:01 +0000

From: Jason Greene [mailto:[email-masked]] 
 > IMO this topic points at a general need for the web to have finer grained encryption.

Yup. Couldn't agree more. I don't care if the NSA knows I'm pulling down the Google logo - it's not interesting to me or them.

I see an opportunity with the framing work in HTTP/2 to introduce crypto at the frame / stream layer. I think it'll be a long road though,

Richard

---

From: Roland Zink <[email-masked]>
Date: Fri, 20 Jun 2014 11:26:44 +0200

On 18.06.2014 23:02, Barry Leiba wrote:
> will understand. To most users, there will be no difference. The 
> problem isn't that we're not telling users that our proxies can snoop 
> and modify. The problem is that we're allowing a situation where our 
> proxies can snoop and modify. 
 From the users perspective TLS is most often not end-to-end (like for 
this email). A user can't even deduce the country where the content will 
be decrypted and therefore which laws will be applied to the sent data.

> protocols and how they're used so that we shut down men in the middle.
Would be nice if you could ensure that my messages will not be seen by 
intermediaries like Facebook, Google.
In addition users can't trust a web site just because the web site 
presents a certificate. The user may have a need to inspect the traffic 
to defend against attacks and maybe just to prevent ad spam.

Roland

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Jun 2014 11:42:23 +0200

> corporate network in the world that they no longer need to do this to

We have to have better solutions available over the longer term.  There
needs to be some confidence that the bits hitting a device won't break
it.  Many devices are not in a position to make this determination
themselves.  Others are.  That does NOT necessarily translate into
snooping all the bits, however.  Let's cast a wider net.

Eliot

---

From: Roland Zink <[email-masked]>
Date: Fri, 20 Jun 2014 11:48:38 +0200

On 19.06.2014 21:33, William Chan (陈智昌) wrote:
>
> The need to trust a third party is definitely a problem for content 
> authors today. This is one use case for the Subresource Integrity 
> proposal: http://www.w3.org/TR/2014/WD-SRI-20140318/#resource-integrity-1.
>
> That said, I do not agree with your assertion that referencing content 
> from a third party is equivalent to being willing to trust a proxy. I 
> am frankly surprised to hear such a statement. Does anyone else agree 
> with this?
>
  Don't think you can be sure what active content will do and it has 
access to decrypted content.

>     visit nicecite.com <http://nicecite.com> they're really executing
>     monitoring.js from
>     bigbrother.com <http://bigbrother.com>. 
>
>
+1

---

From: Roland Zink <[email-masked]>
Date: Fri, 20 Jun 2014 12:29:24 +0200

> definitely do not "want this" for my calendar nor IMAP etc.
I as a father don't want my kids (as users) to see inappropriate 
content. I as a user often don't want web sites sending me tracking 
cookies, ads, viruses and many other things. I as a (very very tiny:-) 
web site admin (http://home.zinks.de/) can't guarantee that nobody will 
hack my site and misuse it. I as a user don't want my calendar be hosted 
by anybody in the Internet. Question is how this can be achieved? Maybe 
an intercepting HTTP proxy in the home router or a service of a mobile 
network operator can be part of the solution. Better solutions always 
welcome.

+1
> TLS" is actually a positive statement overall.
Up to now TLS was independent from HTTP but this was broken with ALPN. 
An extension tied to HTTP through ALPN should not break any non HTTP use 
of TLS.

Roland

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jun 2014 13:37:56 +0100

On 20/06/14 01:52, Richard Wheeldon (rwheeldo) wrote:
> Yup. Couldn't agree more. I don't care if the NSA knows I'm pulling
> down the Google logo - it's not interesting to me or them.

I don't think that last bit is correct. [1] I've no idea
if that cookie is sent for the logo though, but I'd be
surprised if they were not interested.

> I see an opportunity with the framing work in HTTP/2 to introduce
> crypto at the frame / stream layer. I think it'll be a long road
> though,

It probably would be a long road. Selective field confidentiality
is also hard to do well without lots of complexity.

S.

[1]
http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Jun 2014 17:06:31 +0200

> support him with any information he needs from me.

One thing we have discussed already is that we should have some text 
that covers proxies that are essentially proprietary and hard-wired, and 
might not even talk proper HTTP. For instance, Google's Data Compression 
Proxy (using SPDY between UA and proxy), or Opera Turbo.

There's the deployment aspect (does this fall under "3.4 Configuration 
As Side Effect"?), and also the fact that the protocol spoken between UA 
and proxy might not even be HTTP (does this merit a new section somewhere?).

Finally, there are cases where part of the UA functionality is moved 
into the network, such as in Opera mini - do we consider that as 
"proxying" as well (methinks yes, because it shares most of the 
considerations of classical proxies).

*If* we want to adopt this as a WG document (which I support) then we 
have two weeks left to submit it as 00.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Jun 2014 09:59:05 -0700

On 20 June 2014 08:06, Julian Reschke <[email-masked]> wrote:
> Finally, there are cases where part of the UA functionality is moved into
> the network, such as in Opera mini - do we consider that as "proxying" as
> well (methinks yes, because it shares most of the considerations of
> classical proxies).

I don't tend to think of this as a proxy at all.  Split UA is the term
I've used casually with respect to Opera mini, Silk and others.
Really, this is just a software deployment choice.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 20 Jun 2014 18:26:47 +0000

Would not any proxy fall in this split UA category then? What differentiates a proxy from a split UA?

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2014 11:37:09 -0700

I generally think of a split UA as being one where both sides are controlled
by the software vendor. E.g., Amazon sells you the Kindle Fire and they
also run the server side. That's different from having the enterprise impose
a proxy on a piece of software which someone else wrote and deployed.

-Ekr

On Fri, Jun 20, 2014 at 11:26 AM, Diego R. Lopez <[email-masked]> wrote:

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 20 Jun 2014 18:44:59 +0000

Hi,

On 20 Jun 2014, at 05:29 , Roland Zink <[email-masked]> wrote:

> I as a father don't want my kids (as users) to see inappropriate content. I as a user often don't want web sites sending me tracking cookies, ads, viruses and many other things. I as a (very very tiny:-) web site admin (http://home.zinks.de/) can't guarantee that nobody will hack my site and misuse it. I as a user don't want my calendar be hosted by anybody in the Internet. Question is how this can be achieved? Maybe an intercepting HTTP proxy in the home router or a service of a mobile network operator can be part of the solution. Better solutions always welcome.

I made very similar statements in a (somehow) heated discussion on the general principles of opportunistic encryption in London. An encrypted channel, authenticated or not, is just that: it can only protect you from unnoticed eavesdroppers without direct access to the source (was it no the case in much of PRISM surveillance?). And it can come at a price worse than the problem you want to solve. There are no one-size-fits-all solution. A controlled/trusted/acknowledged/... intermediary can be part of the solution in many use cases.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 20 Jun 2014 19:08:42 +0000

So the SPDY proxy and Chrome are a split UA as well? A general proxy run by Microsoft for all IEs would be a split UA?
It is not the software vendor "imposing" something to the user here as well?

On 20 Jun 2014, at 13:37 , Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

On Fri, Jun 20, 2014 at 11:26 AM, Diego R. Lopez <[email-masked]<mailto:[email-masked]>> wrote:
Would not any proxy fall in this split UA category then? What differentiates a proxy from a split UA?

On 20 Jun 2014, at 11:59 , Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

> On 20 June 2014 08:06, Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
-----------------------------------------

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Roland Zink <[email-masked]>
Date: Fri, 20 Jun 2014 21:19:06 +0200

I think at least the SPDY proxy is not a split UA as it is possible to 
use a different proxy here. It is possible to downgrade to an HTTP/1.1 
proxy or configure a SPDY proxy of a different vendor into Chrome.

There are some general proxies which do some rendering in the proxy. Are 
those then split UA?

Roland

On 20.06.2014 21:08, Diego R. Lopez wrote:
> So the SPDY proxy and Chrome are a split UA as well? A general proxy 
> run by Microsoft for all IEs would be a split UA?
>>     On 20 Jun 2014, at 11:59 , Martin Thomson
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     e-mail: [email-masked] <mailto:[email-masked]>
>>     Tel: +34 913 129 041 <tel:%2B34%20913%20129%20041>
>>     Mobile: +34 682 051 091 <tel:%2B34%20682%20051%20091>
>>     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:
> ------------------------------------------------------------------------
>
> 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:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2014 12:25:39 -0700

On Fri, Jun 20, 2014 at 12:08 PM, Diego R. Lopez <[email-masked]> wrote:

>  So the SPDY proxy and Chrome are a split UA as well? A general proxy run
> by Microsoft for all IEs would be a split UA?
>

I don't know the details of how these work, but it seems likely that that's
the
case.

> It is not the software vendor "imposing" something to the user here as

Of course, but the software vendor imposes all kinds of choices on the user
all the time, and of course the user can use some other kind of software.
If your enterprise/ISP requires you to use a proxy, now you have two
entities
in control of your experience rather than one.

-Ekr

>  On 20 Jun 2014, at 13:37 , Eric Rescorla <[email-masked]> wrote:
>
> ------------------------------
>

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Fri, 20 Jun 2014 19:53:40 +0000

From: Stephen Farrell [mailto:[email-masked]] 

 > I don't think that last bit is correct. [1] I've no idea if that cookie is sent for the logo though, but I'd be surprised if they were not interested.

Fair point. The data is not interesting to them / sensitive to me. Metadata sent in the request (but probably not needed either) may be.

Richard

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Sat, 21 Jun 2014 19:25:18 +0000

> and also the fact that the protocol spoken between UA and proxy might not even be HTTP (does this merit a new section somewhere?).

This is also true for communication between UA and server (e.g. Webex, Skype, Goto-meeting) which are often tunnelled over 443 to
look like HTTPS but aren't. The security implications of such protocols aren't pretty.

I think we put a brief statement in that mentions these issues, but limits the scope of the rest of the doc to just HTTP. Otherwise
the scope creep is likely to get silly,

Richard

---

From: "Martin Nilsson" <[email-masked]>
Date: Sat, 21 Jun 2014 23:18:09 +0200

> considerations of classical proxies).

I would like to hear why you think it shares considerations with classical  
proxies. My gut response would be that it isn't in scope.

/Martin Nilsson

---

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Jun 2014 09:44:33 +0200

On 2014-06-21 23:18, Martin Nilsson wrote:
> I would like to hear why you think it shares considerations with
> classical proxies. My gut response would be that it isn't in scope.

Terminating TLS "somewhere else" would be one consideration. (Like it or 
not)

Best regards, Julian

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 22 Jun 2014 10:53:54 +0000

On 20 Jun 2014, at 21:25 , Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
It is not the software vendor "imposing" something to the user here as well?

Of course, but the software vendor imposes all kinds of choices on the user
all the time, and of course the user can use some other kind of software.
If your enterprise/ISP requires you to use a proxy, now you have two entities
in control of your experience rather than one.

What I am concerned here is about the differentiation between the term "proxy" (i.e., an imposed MITM) and "split UA" (i.e., a design decision of the browser producer) May be we should try to coin a more neutral term, like "intermediary" or "forwarder" or... Perceptions have a very important role to play here.

Be goode,

-Ekr

-Ekr

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 22 Jun 2014 16:59:20 +0200

> Terminating TLS "somewhere else" would be one consideration. (Like it or  

Opera Mini doesn't use TLS though, and the data inside the encrypted layer  
isn't standardized. We could of course move to use TLS, and how that would  
work could be documented. E.g. private protocols could have a name space  
in ALPN.

/Martin Nilsson

---

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Jun 2014 17:34:25 +0200

On 2014-06-22 16:59, Martin Nilsson wrote:
> On Sun, 22 Jun 2014 09:44:33 +0200, Julian Reschke
> <[email-masked]> wrote:
>
>> Terminating TLS "somewhere else" would be one consideration. (Like it
>> or not)
>>
>
> Opera Mini doesn't use TLS though, and the data inside the encrypted
> layer isn't standardized. We could of course move to use TLS, and how
> that would work could be documented. E.g. private protocols could have a
> name space in ALPN.

What I meant is that if I access a HTTPS URI from Opera Mini, the TLS 
connection will not be terminated on the UA but on an Opera server.

Right?

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Jun 2014 09:39:58 -0700

On Sun, Jun 22, 2014 at 3:53 AM, Diego R. Lopez <[email-masked]> wrote:

>
>  On 20 Jun 2014, at 21:25 , Eric Rescorla <[email-masked]> wrote:
>
>  What I am concerned here is about the differentiation between the term
> "proxy" (i.e., an imposed MITM) and "split UA" (i.e., a design decision of
> the browser producer) May be we should try to coin a more neutral term,
> like "intermediary" or "forwarder" or... Perceptions have a very important
> role to play here.
>

Hmm... But the point is that these aren't the same thing from the user's
perspective. In one case, you have to trust one set of people (the vendor)
and in the other case you need to trust two (the vendor and the proxy
operator). The use of two terms thus preserves that distinction and
discussion of MITM devices needs to acknowledge that distinction
or it's not going to get very far.

-Ekr

---

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

> connection will not be terminated on the UA but on an Opera server.

I disagree on how you define UA, but TLS is terminated on the server,  
where the browser core is, yes.

/Martin Nilsson

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 22 Jun 2014 21:35:53 +0200

On Sun, 22 Jun 2014 18:39:58 +0200, Eric Rescorla <[email-masked]> wrote:

>> "proxy" (i.e., an imposed MITM) and "split UA" (i.e., a design decision  
>> >>of the browser producer) May be we should try to coin a more neutral  
>> term, like "intermediary" or "forwarder" or... Perceptions have a very  
>> >>important role to play here.
>

I think we are talking about two different things, which is confusing  
things. There is the organizational aspect that you discuss. Then there is  
the technical aspect of if the server component is needed for the client  
to work (as opposed to merely hard coded to make the appearance of it  
being needed). These can combine in four different permutations, and all  
four are represented in practice.

In addition you can of course bundle these together in a single client in  
any combination.

/Martin Nilsson

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Jun 2014 12:48:26 -0700

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

> the technical aspect of if the server component is needed for the client to
> work (as opposed to merely hard coded to make the appearance of it being
> needed). These can combine in four different permutations, and all four are
> represented in practice.
>
> any combination

Sure, that's true.

However, I think the main *technical* issue here is what, if any, support
browsers
ought to have for allowing network operators to install credentials which
allow
them to act as a proxy for connections which would otherwise be end-to-end
secured between the client and the server. This may use the same technical
mechanisms once that's done (and in fact it currently mostly does), but from
a policy perspective it's totally different.

-Ekr

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 22 Jun 2014 20:48:53 +0000

On 22 Jun 2014, at 21:48 , Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

However, I think the main *technical* issue here is what, if any, support browsers
ought to have for allowing network operators to install credentials which allow
them to act as a proxy for connections which would otherwise be end-to-end
secured between the client and the server. This may use the same technical
mechanisms once that's done (and in fact it currently mostly does), but from
a policy perspective it's totally different.

I disagree: I see the split UA policy-wise equivalent to the proxy once you install your browser: you put your trust on the browser developers *and* on the the proxy operator: when you install the browser you take a single leap of faith, from that moment on you (implicitly) putting your trust on the proxy operator: whether it is the same or a different organization that develop the browser is immaterial.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Jun 2014 15:26:25 -0700

On Sun, Jun 22, 2014 at 1:48 PM, Diego R. Lopez <[email-masked]> wrote:

>
>  On 22 Jun 2014, at 21:48 , Eric Rescorla <[email-masked]> wrote:
>
>  I disagree: I see the split UA policy-wise equivalent to the proxy once
> you install your browser: you put your trust on the browser developers
> *and* on the the proxy operator: when you install the browser you take a
> single leap of faith, from that moment on you (implicitly) putting your
> trust on the proxy operator: whether it is the same or a different
> organization that develop the browser is immaterial.
>

I'm not sure what to tell you. It doesn't seem like a very complicated
piece of
security analysis that trusting two people is a bigger deal than trusting
one.
And this is before we get to the fact that in many cases the MITM proxies
are in place specifically to ensure that the user uses the browser in
accordance
with the network's policies rather than his own, a situation that does not
apply
in a typical split browser scenario.

-Ekr

---

From: "Martin Nilsson" <[email-masked]>
Date: Mon, 23 Jun 2014 00:48:52 +0200

On Mon, 23 Jun 2014 00:26:25 +0200, Eric Rescorla <[email-masked]> wrote:

>> >>*and* on the the proxy operator: when you install the browser you  
>> take a single leap of faith, from that moment on you (implicitly)  
>> putting your >>trust on the proxy operator: whether it is the same or a  
>> different organization that develop the browser is immaterial.
>
> security analysis that trusting two people is a bigger deal than  
> trusting one.
> with the network's policies rather than his own, a situation that does  
> not apply

Well, it's clear that the answer to the question if this needs to be  
discussed in a proxy document is yes.

/Martin Nilsson

---

From: Albert Lunde <[email-masked]>
Date: Sun, 22 Jun 2014 20:34:29 -0500

On 6/22/2014 3:48 PM, Diego R. Lopez wrote:
> On 22 Jun 2014, at 21:48 , Eric Rescorla <[email-masked]

It seems like there's an important distinction between (1) all 
intermediaries that look like a "proxy" when viewed as a black box, and 
(2) intermediaries that follow some protocols on the wire standardized 
in IETF specs.

(1) can follow any protocol internally by private agreement (or just be 
a unilateral intercept by corruption of protocols, like CA and/or DNS 
spoofing.) But it still may speak standard HTTP on the outer interfaces.

One motive for trying to standardize more about proxies is to surface 
and specify legitimate use cases. ("Legitimate" as defined by the people 
owning the systems and networks involved.)

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 23 Jun 2014 07:48:46 +0000

On 23 Jun 2014, at 00:26 , Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Jun 22, 2014 at 1:48 PM, Diego R. Lopez <[email-masked]<mailto:[email-masked]>> wrote:

I'm not sure what to tell you. It doesn't seem like a very complicated piece of
security analysis that trusting two people is a bigger deal than trusting one.
And this is before we get to the fact that in many cases the MITM proxies
are in place specifically to ensure that the user uses the browser in accordance
with the network's policies rather than his own, a situation that does not apply
in a typical split browser scenario.

My point is that you need to trust those people at different moments (one for installation, another one when using it) and that makes that you always have to trust two different set of people. Unless I am missing something and you assume that a split browser scenario implies full control of both parts by the user.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Diego R. Lopez" <[email-masked]>
Date: Mon, 23 Jun 2014 07:58:09 +0000

On 23 Jun 2014, at 03:34 , Albert Lunde <[email-masked]> wrote:

> It seems like there's an important distinction between (1) all intermediaries that look like a "proxy" when viewed as a black box, and (2) intermediaries that follow some protocols on the wire standardized in IETF specs.
>
> (1) can follow any protocol internally by private agreement (or just be a unilateral intercept by corruption of protocols, like CA and/or DNS spoofing.) But it still may speak standard HTTP on the outer interfaces.
>
> One motive for trying to standardize more about proxies is to surface and specify legitimate use cases. ("Legitimate" as defined by the people owning the systems and networks involved.)

Fully agree. I think this is the kind of distinction that we should make, and addressing and characterizing (2) into those legitimate use cases a goal I certainly support to pursue.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

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

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 23 Jun 2014 10:31:20 +0200

Le Jeu 19 juin 2014 21:33, William Chan (陈智昌) a écrit :

> from

I think you need to step back a little and get some perspective:

1. first, trust is not a mathematical concept it's a human evaluation of
the behaviour of other humans (trust does not apply to dead matter or
automatons, it applies to the people that use them for a particular
purpose). Since humans are not perfect, trust is fundamentally not
transitive. You can try to limit the scope of the trust to the maximum to
limit trust loss during delegation but that's all you can do: limit loss.

That is why any serious security policy will use MAC and not DAC.

That is why despite iron-clad contracts Boeing had to reinternalise
production to rein in the effects of chain subcontracting (and it was
*not* a new discovery every decade beancounters manage to convince a big
organisation that the sanity rules again deep subcontracting can be
lifted).

That is why even with perfect poll processes, if you let your elected
representatives elect another layer or representatives and so on it does
not take many steps before the resulting assembly makes decisions contrary
to the original electing population (some will say even one level of
subdelegation is too much).

This is why ponzi schemes are so effective.

Trust is not transitive and the more delegations you accept the less trust
remains irrespective of technical measures

2. second, you've still not internalized that on the Internet trust is a
three-way concept (site, network and user) and you're still evaluating
trust from the site owner perspective ignoring totally other actors. This
is why you consider a checksum (!) an appropriate trust safegard when you
would never admit it as sufficient for other forms of trust.

>From a user point of view a clearly identified local operator they can
easily reach physically and which operates on local laws will often be
more trustable than a random difficult-to identify site on the other side
of the world (that, as shown again and again, will decline any obligation
under local laws when put to trial).

3. third, cdns and especially js cdns are the ultimate scammer dream:
they're more anonymous than PO boxes (usually computer-generated ids on
shared platforms you have to trust as a whole with no way to identify any
responsible party), they're outside any effective juridiction, they
execute on the marks' systems with direct access to the marks' info using
the marks' computing power. (and no one cares: not the delegator – it's no
on his site, nor the delegatee – it's not his users)

cdns have a long way to go before being remotely trustable from a user
point of view and they have zero incentive to try especially in a http2
world where all power is delegated to the calling site.

Frankly, if you forget the quick money angle, a delegating web site is
about as (or usually less) trusted as a mixed content web site. And if you
accept to use a site that delegates anything to 666.cloud.com for taxes or
banking you deserve what you will get.

If browsers were serious about their user interests they would severely
restrict the number and depth of delegations on any given page, and show
an untrusted warning any time the delegation complexity went over a very
low level, instead of trying to enable more delegation.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 23 Jun 2014 12:22:59 +0200

Le Dim 22 juin 2014 18:39, Eric Rescorla a écrit :

> operator).

Nope. In the first case you need to trust the vendor as cloud operator in
addition to software writer. That's not the same level of trust.

The only entity for which split ui is not a proxy is the vendor and that
only because it implicitly trusts itself (and the same vendor will
vehemently fight user-deployed proxies because "the user may have been
tricked" and "the user can not be trusted". But really proxies are a way
to exert power and you only feel this power when you're not the one
exerting it. In the same ways cdns are not proxies from the site operator
POW because he's the one that chose them)

Any balanced proxy document will void those distinctions and not
discriminate intermediaries in the protocol based on who deployed them.
Because if you add those distinctions you're not designing a protocol
you're doing your little private Yalta. Human actors (site, network
operator and user) must be given information to make trust decisions based
on their real-world situation, making those decisions in the protocol is
hardcoding a particular balance of power.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 23 Jun 2014 12:28:20 +0200

Le Lun 23 juin 2014 00:26, Eric Rescorla a écrit :
lysis that trusting two people is a bigger deal than trusting
> in a typical split browser scenario.

I think Snowden pretty conclusively proved that split browsers that
repatriate all user browsing in a foreign country are in place
specifically to ensure that the user uses the browser in accordance with
this country's policies rather than his own

-- 
Nicolas Mailhot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 23 Jun 2014 07:22:53 -0400

Hahaha, the tone of this email is amazing :) Excuse me while I step back to
get some perspective, internalize different actors in internet trust, and
forget about the quick money angle.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 23 Jun 2014 14:19:34 +0200

> forget about the quick money angle.

I'm glad you find my expression amusing but more sorry than I can express
that months of workgroup exchanges did not manage to temper your
certitudes.

-- 
Nicolas Mailhot

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jun 2014 15:04:30 +0200

On 2014-06-20 21:25, Eric Rescorla wrote:
>
> On Fri, Jun 20, 2014 at 12:08 PM, Diego R. Lopez <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> I don't know the details of how these work, but it seems likely that
> that's the
> case.

Looking at <https://developer.chrome.com/multidevice/data-compression>, 
Google calls this thingy a proxy themselves.

In any case, whether or not we call the Google Data Compression Proxy or 
Opera Turbo a proxy -- they are put into the communications path in 
order to address problems that *could* be addressed by a "real" proxy as 
well. Thus, I believe we should

- mention them, giving them a name,

and

- think about why browser developers deploy non-standards-based proxies.

Some obvious reasons are:

1) so that they can optimize the protocol (performance, security),

2) to simplify configuration (a check box is simpler to explain than a 
proper proxy config UI).

What else?

With respect to 1) - it would be good to understand whether people using 
custom protocols today would be willing to switch to something standard 
if compares well to their custom approach.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 23 Jun 2014 15:45:27 +0200

> 2) to simplify configuration (a check box is simpler to explain than a

3. they found like everyone else the current standard does not permit
deployment of effective proxies without cheating (lack of reliable way to
express trust, lack of reliable way to convey errors, lack of any decent
browser UI, browser refusal of TLS termination)

4. it's easier not to ask permission of anyone least of all the user

5. natural developer bias for internal coding instead of something else

-- 
Nicolas Mailhot

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jun 2014 10:13:30 -0700

On 23 June 2014 00:48, Diego R. Lopez <[email-masked]> wrote:
> My point is that you need to trust those people at different moments (one
> for installation, another one when using it) and that makes that you always
> have to trust two different set of people. Unless I am missing something and
> you assume that a split browser scenario implies full control of both parts
> by the user.

That's not right.  You don't need to trust your network provider at
all.  That's a core tenet of Internet security: "you give your packets
to the attacker to deliver."

You might trust them to deliver some packets.  But to say that is the
same as trusting them with the details of a banking session would be a
gross oversimplification of the concept of trust.

p.s., When I said split UA, there are two things: one is the line that
ekr has been following, which is that you are trusting a single
vendor, which is the most important from a security analysis
perspective.  The other is pure functionality: your browser is not
complete without the network side component.  In some of these cases,
the code that sits on the device is potentially unable to function
without the server piece.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 23 Jun 2014 16:44:05 -0400

> remains irrespective of technical measures

Yeah, I more or less agree with you here. There are some ambiguities that
I'd quibble over, but yes, I think I agree with what you've written here. I
think the key point is that, given the web composition model of sourcing
scripts and other active content, trusting example.com will require
trusting whoever example.com delegates to via active content, and it's
often the case that the end user doesn't trust those third parties.

> would never admit it as sufficient for other forms of trust.

I suspect you are confused here about my referencing the SRI proposal? In
my earlier statement, I simply acknowledged the problem of site owners
needing to fully trust 3rd parties in order to source script from them and
noted that there are proposals to address that. You seem to being jumping
to conclusions about my stance on said proposals. If you have feelings
about that proposal, perhaps you should raise them in the appropriate W3C
forum?

> under local laws when put to trial).

Comparing to a random http://browse.here.for.a.good.time.com website sounds
like a straw man. Isn't the discussion about giving the proxy a privileged
position in the network to examine/modify traffic to all websites, not just
the random ones?

> world where all power is delegated to the calling site.

I'm not sure I follow this. Don't you think CDNs have an incentive not to
be completely evil here? Usually the way this works is the content owner
pays a CDN to host its content, with the expectation that the CDN won't be
evil. If the CDN maliciously transformed content, then the content owner
would probably stop paying the CDN and use a competitor. Isn't that how it
works? Or are you talking about free CDN hosting for certain content, like
Google Hosted Libraries for stuff like jQuery?

In any case, I won't defend CDNs any more. There are plenty of CDNs here on
this mailing list that can defend themselves just fine against these sorts
of claims.

> banking you deserve what you will get.

I'm not sure what you're referring to by the quick money angle here =/

And yeah, delegating to dodgy origins is a terrible idea. But lots of third
party content is hosted by ostensibly reputable origins. For example,
social widgets are hosted by Facebook, Twitter, Google, Pinterest, etc. If
you're able to MITM and replace those social widgets, you can subvert large
chunks of the Web. You seem to assert that if a website sources content
from a third party like Facebook for the Like button, then it should be OK
for a local operator's proxy to MITM that. I find this very surprising.

> low level, instead of trying to enable more delegation.

This seems to be tangential, so I will ignore it. If you are serious about
this, please re-raise in a separate discussion thread.

---

From: [email-masked]
Date: Mon, 23 Jun 2014 17:17:08 -0400

I agree that those two aspects 1) trusting a single vendor and 2) functional incompleteness on the client make Split UA proxies different from traditional web proxies like squid.

But if a split UA proxy were to decrypt my TLS traffic on the server side, I'd want to know about it and be able to say no. You could argue that the certificate installation step is no longer meaningful -- http://caffeinatetheweb.com/presentations/trusted_proxy.html#/3. But the notification and user control piece is exactly the same as non split UA proxies -- http://caffeinatetheweb.com/presentations/trusted_proxy.html#/4.

Peter

---

From: Frode Kileng <[email-masked]>
Date: Mon, 23 Jun 2014 23:40:56 +0200

>     under local laws when put to trial).

IMHO, care should be taken when generalizing who to trust. I've seen 
studies indicating large variations between regions and countries. 
Regretfully, the studies are not publicly available. The data doesn't 
clarify the reasons for variations but it's easy to come up with 
explanations. So although citizens in Canada trusts their ISP more than 
your-favorite-browsing-vendor, citizens of North-Korea may have a 
different point of view.

There's also large individual variations.

A challenge with the "trusted proxy" is that if I don't trust my ISP and 
this is an enforced policy, I'm out of options. If I don't trust a 
specific browser-vendor, I have many options.

Frode Kileng

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 23 Jun 2014 21:49:17 +0000

the concept of forced proxy is mostly I believe being discussed in the 
context of a corporate network.

if your ISP forces you to use a proxy, you may be able to choose another 
ISP that doesn't if you care enough.

Adrien

------ Original Message ------
From: "Frode Kileng" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 24/06/2014 9:40:56 a.m.
Subject: Who to trust?

><[email-masked]> wrote:
>>
>A challenge with the "trusted proxy" is that if I don't trust my ISP 
>and this is an enforced policy, I'm out of options. If I don't trust a

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 24 Jun 2014 00:14:31 +0200

> I

Unfortunately users are not informed of the extent of those delegations by
their tools so there is no pushback and delegations are proliferating to
worrying levels

> position in the network to examine/modify traffic to all websites, not

The discussion is on how to enable users to identify and accept (or not)
their processing. Regardless of the conclusion of this discussion, other
third parties are getting pervasive enough they are already getting the
level of access people object of proxies.

> be completely evil here?

I like the completely here

> Usually the way this works is the content owner
> evil.

Or the content owner is paid to include some cdn content (ads, sometimes
malware-infested) or the cdn is made freely available for other reasons…

The user is not informed in any way of who hosts what and why, has little
legal recourse even if he acquired this information, what little trust
infrastructure exists in browsers or tls is dns-based but cloud cdns blow
it appart by hosting unrelated content on the same common domains

Trust can only exist if there is someone clearly accountable in case of
misbehaviour and the clearly part is missing here for anyone but the root
site owner (and sometimes not even then)

> I'm not sure what you're referring to by the quick money angle here =/

I think news web sites will include pretty much any delegation nowadays to
scrap a little money. They'll soon refer to more third party sites than a
search result page.

> You seem to assert that if a website sources content
> for a local operator's proxy to MITM that.

I assert that when a significant proportion of the web requires executing
scripts directly sourced from Facebook or Google or whatever, those
operators are de facto given the same power a proxy would have with less
room to wiggle away and less accountancy (avoiding a proxy only requires
changing networks). Delegation would not be so worrisome if network
effects were not concentrating it on a handful of platforms.

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 23 Jun 2014 22:27:52 +0000

>There's also large individual variations.

Not to mention legally mandated variations.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Frode Kileng <[email-masked]>
Date: Tue, 24 Jun 2014 00:27:51 +0200

On 23.06.2014 23:49, Adrien de Croy wrote:
> if your ISP forces you to use a proxy, you may be able to choose 
> another ISP that doesn't if you care enough.

In the regions and countries I'm thinking of, the level of trust applies 
to all the alternative ISPs  (if there's an alternative available at 
all...).

Frode Kileng

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jun 2014 16:17:23 -0700

On 23 June 2014 14:17,  <[email-masked]> wrote:
>
> But if a split UA proxy were to decrypt my TLS traffic on the server side,
> I'd want to know about it and be able to say no.

This is simply a technical limitation of this particular deployment
choice.  You can't see the actual connection that your UA makes
because it makes it somewhere remote.  It also means that the security
UI it shows needs to account for that remoteness somehow.  I'd also
want to ensure that these mechanisms are resilient against server
compromise, but that's tricky and probably not going to happen.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jun 2014 16:42:55 -0700

On 23 June 2014 14:40, Frode Kileng <[email-masked]> wrote:
> this is an enforced policy, I'm out of options. If I don't trust a specific
> browser-vendor, I have many options.

This is true, but it's also true that trust isn't one-dimensional either.

I trust my bank with my money.  That's a big deal, but I wouldn't
trust them to mind my child for even 5 minutes, or to even make an
appointment on time.  Part of the trust there derives from the checks
and balances that are in place.

When it comes to network providers, the need for trust is actually
fairly low.  That's a design feature of the Internet.  Instead, I
place my trust in things like TLS, which in turn places trust in the
cryptography community, etc...  That's more than risky enough for me.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 24 Jun 2014 12:23:48 +0200

On 24 June 2014 01:42, Martin Thomson <[email-masked]> wrote:

> Instead, I place my trust in things like TLS, which in turn places trust
> in the

I think we too often make the error of representing that encryption ==
security && encryption == privacy.

Users trust the little lock symbol in their browsers so they do their
online banking and other financial translations.

The recent attacks on TLS+gzip and the whole NSA snooping thing shows the
value of meta-data and encryption of HTTP does not well hide very much meta
data.    Observers of encrypted traffic still know to whom, when and how
much traffic is sent.    In many cases that is sufficient to work out what
content has been downloaded (ie with encryption your employer will still
know you are watching youtube videos, and size will probably give them a
reasonable guess at which ones!)

User do extend trust to sites like google to not abuse content they can
decrypt.

I don't think it is a huge leap to consider having trusted proxies in the
web of trust that we create - I just think that we have to be cautious to
not over- represent any of our connections as truly secure.  I think true
security is outside the scope of http WG and we need to find language that
describes what level of protection we can offer.

For example, if we do have trusted proxies, it would be good to still have
some end to end encryption so your employer can't see your online banking
password.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: [email-masked]
Date: Tue, 24 Jun 2014 10:43:31 -0400

I wonder if the browser guys can weigh in on this. Martin, Patrick, Will, Rob? Others? Do you agree that our choices are as follows?

1) Do nothing. This is today's MITM with user installed CAs.
2) Some type of trusted proxy UI support that gives the user notification and control. Something similar to this: http://caffeinatetheweb.com/presentations/trusted_proxy.html#/.
3) Disable all mechanisms for HTTPS decryption by proxies (for instance, enforce pinned certs)

Do you agree that #3 is not an option b/c browsers will immediately stop working for a large number of corporate users? And that #2 is an improvement over #1 since it does not increase security vulnerability but gives user some visibility and control?

As others have pointed out,  this may not actually be an HTTPbis protocol issue. But I think if we can come to an agreement that something should be done then we can figure out where that work should take place.

Thoughts?

Thanks,

Peter

---

From: Patrick McManus <[email-masked]>
Date: Tue, 24 Jun 2014 11:35:17 -0400

On Tue, Jun 24, 2014 at 10:43 AM, <[email-masked]> wrote:

> I wonder if the browser guys can weigh in on this. Martin, Patrick, Will,
> Rob? Others? Do you agree that our choices are as follows?
>
> 2) Some type of trusted proxy UI support that gives the user notification
> and control. Something similar to this:
> http://caffeinatetheweb.com/presentations/trusted_proxy.html#/.
I think its inevitable that different parties will make different choices
and some of those choices won't be on your list. This is because there
isn't a critical mass of people that have come together in order to agree
to a path for this problem in this forum.

> Do you agree that #3 is not an option b/c browsers will immediately stop
> working for a large number of corporate users?
>

Some variation of #3 is definitely an option. They all have ups and downs.

> And that #2 is an improvement over #1 since it does not increase security
> vulnerability but gives user some visibility and control?
>
>
in some aspects its better - but its not strictly better. #1 is generally
done with administrative control of the OS which is a protection #2 does
not have.

I'm not convinced that a "make my internet work" button qualifies as
visibility or control or that consent can be meaningful in this context. I
don't have an alternative.

As others have pointed out,  this may not actually be an HTTPbis protocol
> issue.

I agree that it is fruitless to be talking about it in this space which is
why I haven't expended a lot of energy on it right now and don't intend to
fill my days replying to the various threads.

This discussion will boil down to "I want my MITM model to do something
noble vs I want two-party privacy" and each side sees massive potential for
misuse of the other side's position (one side has spying/secret
theft/tracking/big-data/security injection concerns, the other DLP,
viruses, the detection of bit patterns prohibited by law, etc.. both have
clear precedent in practice.). This isn't to say there is or isn't trust
among the players in this discussion but they of course won't be the only
implementers at the end of the day.

-P

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jun 2014 10:04:37 +1000

Not speaking for anyone but myself (but somewhat informed by speaking to lots of people):

> 3) Disable all mechanisms for HTTPS decryption by proxies (for instance, enforce pinned certs)

See also:
  https://datatracker.ietf.org/wg/trans/charter/
  http://www.certificate-transparency.org

> Do you agree that #3 is not an option b/c browsers will immediately stop working for a large number of corporate users?

Corporate users are indeed the hard part. It may be that people simply won't access their banks through corporate networks, because they can't, and maybe that's a good outcome -- especially when they're easily able to use a mobile device and get a "clean" connection.

Harder are the sites that users need to legitimately access on an "owned" network (whether it be corporate, school, prison, etc.). 

As things sit now, it may be that we see greater differentiation emerge in the market, where some browsers are easier for corporations to modify / configure in this manner than others. After all, we already see wider deployment of some browsers in corporate settings, whereas other browsers are focusing on individual users and their need for privacy and security.

CT also comes into it; I'm not sure what the current story is around certs that fail CT but match a user-added CA in the trust store, but it seems relevant.

What would be nice is better UX around the trust store, but so far nothing has congealed here or elsewhere (and that sounds very much like an "elsewhere"). One problem is that trust stores are often part of the OS, and as a result both move more slowly and have less-than-ideal integration with browser UX.

Whether or not a standard is required here is a very separate question. It's important to understand that anything that legitimises intercepting traffic is going to encounter a *lot* of friction in the IETF (as well as the W3C, I imagine); while we all know that this happens in some networks (sometimes often), calling it an Internet Standard puts the imprimatur of the organisation on this practice.

That's not to say that we can't have this discussion, or that it won't lead to anything; just that arguments that "look, it's already happening" (which come up once in a while) aren't going to move things forward. My impression is that the browser folks are still figuring out the implications of all of this now, and running their experiments. Forcing them to the table to discuss standards at this stage may not be productive.

> And that #2 is an improvement over #1 since it does not increase security vulnerability but gives user some visibility and control?

See above. Arguably, users already have some visibility and control, if they have an understanding of how their trust store works. 

Granted, the visibility and control afforded generally sucks, but so far the efforts the IETF community has agreed to are about tightening that up (see CT), not providing another (legitimised) avenue for reducing the requirement for end-to-end security.

Also, realise that one of the key differentiating factors is whether the intermediary's cert gets installed separately or automatically. Automatic acceptance of a MITM cert (e.g., perhaps with a click-through dialogue) is asking for attacks; most people will click through that. OTOH if a cert has to be deliberately added to the trust store by the user before they can access a site, that's a very different thing.

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

---

From: John Mattsson <[email-masked]>
Date: Wed, 25 Jun 2014 10:48:47 +0000

Given the huge privacy implications alone, I would say that either:

- the protocols need to be standardised
- or the cloud part of the browser needs to be downloadable and deployable
by the user and third-party cloud providers.

A data center implementing the proprietary cloud part of the browser will
be an excellent information source for organizations doing pervasive
monitoring.

Just being transparent and letting the user (whether it is an person or an
enterprise) be able to turn off the feature is not enough. Just as the
user of the browser can choose which device to run the browser on, the
user must be able to choose which cloud to run the browser in.

Cheers
John Mattsson