Subject: Fwd: New Version Notification for draft-nottingham-http-proxy-problem-01.txt

From: Mark Nottingham <[email-masked]>
Date: Fri, 4 Jul 2014 16:47:17 +1000

FYI.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http-proxy-problem-01.txt
> Date: 4 July 2014 4:37:12 pm AEST
> To: "Mark Nottingham" <[email-masked]>, Mark Nottingham <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-http-proxy-problem-01.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-http-proxy-problem
> Revision:	01
> Title:		Problems with Proxies in HTTP
> Document date:	2014-07-04
> Group:		Individual Submission
> Pages:		16
> URL:            http://www.ietf.org/internet-drafts/draft-nottingham-http-proxy-problem-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-http-proxy-problem/
> Htmlized:       http://tools.ietf.org/html/draft-nottingham-http-proxy-problem-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-nottingham-http-proxy-problem-01
> 
> Abstract:
>   This document discusses the use and configuration of proxies in HTTP,
>   pointing out problems in the currently deployed Web infrastructure
>   along the way.  It then offers a few principles to base further
>   discussion upon, and lists some potential avenues for further
>   exploration.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:53:48 +0000

I'm curious, why did you drop the MITM section?

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: 04 July 2014 07:47
To: HTTP Working Group
Subject: Fwd: New Version Notification for draft-nottingham-http-proxy-problem-01.txt

FYI.

Begin forwarded message:

> Subject: New Version Notification for 
> draft-nottingham-http-proxy-problem-01.txt
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 Jul 2014 11:40:11 -0700

Any reason why load-balancers aren’t in this discussion?  With more end-to-end security coming in place, load balancers are starting to have similar or even more complex challenges.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 11:54:13 -0700

> Any reason why load-balancers aren’t in this discussion?  With more end-to-end security coming in place, load balancers are starting to have similar or even more complex challenges.

The focus so far has been on the role of proxies on the client side.
The important issue being the role that an external third party (in
the figurative sense) has in what is - at it's core - a two-party
conversation.  Of course, that is a gross oversimplification of the
matter and doesn't do justice to the vast range of options possible in
this space.

Load-balancers (or gateways) are usually part of the first two
parties; they are able to assert an authenticated identity as a
server.  That means that the issues are quite different.

There are the TLS issues arising from this (key management,
interaction with the handshake, etc...), which have been the subject
of extensive discussion in TLS.  Those discussions are more
appropriate in that forum.

Then there are the intermediation concerns at the HTTP layer.  We have
had a lot of discussion about the details of the protocol design for
gateways.  It might even be said that the conversation - certainly
recently - has been dominated by these concerns.

Is there a specific aspect of the conversation that you would like to
see us cover more thoroughly?

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 Jul 2014 12:17:16 -0700

Martin,

The TLS issue is certainly a big part of the problem. The perception is that TLS now needs to terminate at the service provider cluster node rather than the load-balancer because end-to-end encryption, in-the-data-center-encryption requirements, and/or web proof-of-possession issues arising from the authentication header.

From the TLS perspective, if TLS must terminate at the service provider node than the load-balancer is now in the same position with the same challenges as any client side proxy.

It is not clear to me yet, whether this is something that is facilitated in HTTP/2 connection handling, or TLS or both.

It would be helpful to discuss the load-balancer scenario as it is a MITM proxy and from there we can figure out what elements of HTTP or TLS are in play.

At least on the surface, having read the proxy problem draft, I found many of the issues/patterns to be quite similar and thoughtful.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Jul 2014 12:33:53 -0700

> It would be helpful to discuss the load-balancer scenario as it is a MITM proxy and from there we can figure out what elements of HTTP or TLS are in play.

The term we use here is gateway.  And the different deployment options
alter where the discussion belongs.  Forwarding TCP is very different
from acting as a gateway.  Here we need only concern ourselves with
the latter.

I think that you may have missed my point though.  The important
distinction is first party vs. third.  A gateway is intrinsically a
first party in the conversation.

The discussion we're looking to have is: what is the role of third
parties in what is primarily a two party protocol?

---

From: Erik Nygren <[email-masked]>
Date: Fri, 11 Jul 2014 16:27:38 -0400

How is this significantly different for HTTP/2 than from HTTP/1.1 with TLS ?
Or are you just generally raising this as an issue?

In the former case, you're at least guaranteed to have the TLS SNI header
which helps load balancers substantially in this case.  (Quite a bit of the
TLS 1.3
discussion on client_hello encryption has been on how load balancers can
still
route traffic without needing to be able to obtain access to secrets only
on the service
provider node.)

         Erik

On Fri, Jul 11, 2014 at 3:17 PM, Phil Hunt <[email-masked]> wrote:

> Martin,
>
> The TLS issue is certainly a big part of the problem. The perception is
> that TLS now needs to terminate at the service provider cluster node rather
> than the load-balancer because end-to-end encryption,
> in-the-data-center-encryption requirements, and/or web proof-of-possession
> issues arising from the authentication header.
>
> From the TLS perspective, if TLS must terminate at the service provider
> node than the load-balancer is now in the same position with the same
> challenges as any client side proxy.
>
> It is not clear to me yet, whether this is something that is facilitated
> in HTTP/2 connection handling, or TLS or both.
>
> It would be helpful to discuss the load-balancer scenario as it is a MITM
> proxy and from there we can figure out what elements of HTTP or TLS are in
> play.
>
> At least on the surface, having read the proxy problem draft, I found many
> of the issues/patterns to be quite similar and thoughtful.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
> >> Any reason why load-balancers aren’t in this discussion?  With more
> end-to-end security coming in place, load balancers are starting to have
> similar or even more complex challenges.
> >

---

From: Phil Hunt <[email-masked]>
Date: Fri, 11 Jul 2014 14:07:01 -0700

Erik,

From my perspective this is neither HTTP/2 or 1.1.  I was just responding to Mark’s draft on proxies.

I commented because of the evolving issue with cloud hosting (where there are multi-tenants behind gateways) and new work happening in the app layer with proof-of-possesion confirmation (OAuth WG) and trying to understand how this will all fit together.

The “gateway” as Mark corrected me, seems to share some qualities and issues as Mark discussed.  

Thanks for the the TLS info. Will look further.

Phil

@independentid
www.independentid.com
[email-masked]

On Jul 11, 2014, at 1:27 PM, Erik Nygren <[email-masked]> wrote:

> which helps load balancers substantially in this case.  (Quite a bit of the TLS 1.3
> discussion on client_hello encryption has been on how load balancers can still
> route traffic without needing to be able to obtain access to secrets only on the service
> provider node.)
> 
>          Erik
> 
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Jul 2014 17:44:32 +1000

Hi Richard,

You mean "Living with Interception"?

I removed it because it's a two-front war; not only would we need to fight the "layer violation" issue, but also convince privacy, security and civil society stakeholders that it's legitimate to have an active protocol component between a HTTP UA and origin without the consent or knowledge of either party.

Not to say that we can't talk about it; just that it didn't seem like something useful to include at this point.

Regards,

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

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Tue, 15 Jul 2014 10:38:07 +0000

Yes. I think it should be included in any comprehensive description of the problems with proxies. What a solution would look like is an entirely different animal where I completely agree with the points you raise.

Richard

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: 15 July 2014 08:45
To: Richard Wheeldon (rwheeldo)
Cc: HTTP Working Group
Subject: Re: New Version Notification for draft-nottingham-http-proxy-problem-01.txt

Hi Richard,

Regards,

On 12 Jul 2014, at 2:53 am, Richard Wheeldon (rwheeldo) <[email-masked]> wrote:

> Subject: Fwd: New Version Notification for 
>>  This document discusses the use and configuration of proxies in 
>> HTTP,  pointing out problems in the currently deployed Web 
>> infrastructure  along the way.  It then offers a few principles to 
>> base further  discussion upon, and lists some potential avenues for 
>> further  exploration.
>> 
>> 
>> 
>>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 11:40:29 +0000

In message <[email-masked]>, Mark Nottingham wri

>> A new version of I-D, draft-nottingham-http-proxy-problem-01.txt

In 2.4 I think you should mention that content filtering is
explicitly mandated by law in various jurisdictions.

That doesn't make it any less controversial of course, quite the
contrary, but mentioning it would make it clear that there some
level of support will happen, no matter what.

Under 5.4 you should probably add "... unless made illegal by a
legitimate authority" to clarify the extent of our reach.

I think it is unwise to lump header-modifications with "2.4 Content
Modifications".  Modifying an Accept-Bla header, in order to make
filtering easier, is not nearly as controversial as tacking advertising
onto webpages.

Otherwise it's a good summary of the situation.

I would like to propose a section 6.8:

6.8  content-privacy with (some) visible meta-data

    A lot of filtering proxies care only about restricting access
    to particular sites or to particular paths under those sites.

    Today they handle privacy protected access one of two ways.

    Simpler proxies will resolve the CONNECT argument and compare
    it to a white- or black-list of IP numbers, and allow or deny
    access whole-sale to filtered IP numbers.   This causes rather
    dramatic over-reach when one user on a web portal posts content
    which causes the entire portal to be blacklisted.

    More comprehensive proxies deploy man-in-the-middle certificates
    to its clients (via out-of-band methods) and demasks all
    privacy protected transactions in order to be able to inspect them,
    gaining as a side effect also the ability to modify them.

    Very little actual privacy would be lost if a minimum of
    meta-data, specifically the URL less the query part, were
    transmitted in the clear.

    The IP numbers are already in the clear with TLS, and giving
    the quality of traffic fingerprinting already available, expanding
    this visibility to reveal the FQDN implies a very small loss
    of actual privacy.

    Revealing also the path component of the URL, but not the query
    part, likewise would amount to very little actual loss of privacy,
    but would allow filtering proxies to ban only example.com/user/evil
    rather than all of example.com.

    The proposed distinction between "envelope" and "contents" has
    been recognized in legislation for centuries and would therefore
    provide a well-known and -understood tool for tailoring legislation
    more narrowly, than the currently very broad strokes used with
    respect to privacy on the internet.

    (The proposed scheme would also have other benefits outside
    the scope of this document, mainly for incoming load-balancers
    and reverse proxies on the server side.)

-- 
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: Eric Rescorla <[email-masked]>
Date: Tue, 15 Jul 2014 06:42:53 -0700

>     rather than all of example.com.

Mark can of course do as he likes with his document, but I would
not support adding this text to a WG document as I do not believe
that it is accurate.

It is quite common to have sensitive information in the path part of
URLs (for instance, Amazon item numbers appear here), and in
many cases, this is the only sensitive information required to
reconstruct the user's browsing history. I don't consider this to
be "very little actual privacy" loss.

-Ekr

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jul 2014 16:00:59 +0200

On 2014-07-15 15:42, Eric Rescorla wrote:
>  ...

Agreed. We shouldn't rely on a perceived difference that neither is 
backed up by the specs, nor is there in practice.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Jul 2014 07:28:15 -0700

+1.
On Jul 15, 2014 7:05 AM, "Julian Reschke" <[email-masked]> wrote:

> Agreed. We shouldn't rely on a perceived difference that neither is backed
> up by the specs, nor is there in practice.
>
> Best regards, Julian
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 15:52:03 +0000

In message <CABcZeBOf62xCfnrtoqXMzGTW=[email-masked]>, Eric Rescorla wr

>be "very little actual privacy" loss.

And nothing prevents these apps from demanding full privacy (ie: TLS).

But with a view to the future, all they need to do is shift the
sensitive part of the data to the :query side, and they'll fine.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 15:55:24 +0000

>backed up by the specs, nor is there in practice.

You're welcome to your uncompromising attitudes with respect to
privacy, but people with more nuance in their lives will recognize
that this may be the shilling we have to pay the king, if we want
to hold on to the pound.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jul 2014 18:38:27 +0200

> sensitive part of the data to the :query side, and they'll fine.

Making this depend on path vs query is artificial and doesn't reflect 
how people use URIs.

If the sole purpose of splitting out :query is to make a privacy 
distinction then we should think about doing this in a way that's 
agnostic on how queries are used or not.

Best regards, Julian

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Jul 2014 09:41:14 -0700

On Tue, Jul 15, 2014 at 8:52 AM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CABcZeBOf62xCfnrtoqXMzGTW=
> [email-masked]>, Eric Rescorla wr
> ites:
>

This seems like a forward-looking statement. I'm addressing it's current
truth value, and as I said, I believe that's not currently accurate.

-Ekr

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 16:42:45 +0000

>Making this depend on path vs query is artificial and doesn't reflect 

Now ?

Well, sort of...

But if we start to educate them about this split now, maybe we can do something
which will really improve privacy when we get to HTTP/3.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 17:08:41 +0000

In message <[email-masked]>

>truth value, and as I said, I believe that's not currently accurate.

Standardization is a forward-looking activity.

If we want to implement something like what I outlined in the future,
we should start to pave the road for it now.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Jul 2014 10:19:17 -0700

On Tue, Jul 15, 2014 at 10:08 AM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <
> [email-masked]>
> , Eric Rescorla writes:
>

I'm not sure what you are arguing. It's certainly true that one could invent
some division of data in HTTP requests into "sensitive" and "non-sensitive"
and allow proxies to see/touch the latter but not the former. However, as
Julian has observed, this doesn't map to any division that we currently
observe in the URL, so from descriptive perspective your proposed text
is problematic. And if in the future we are going to invent something
new, it's not clear to me why we would wish to do so by splitting the
URL between path and query params.

-Ekr

--

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Jul 2014 10:24:54 -0700

Cutting a trail is not the same as paving it over. Let's not get ahead
of ourselves. The fact is: in today's applications, there is very
little (if any) real separation between the path and the query, and
application developers put stuff all over the place. If you want
developers to start separating those, you need to educate before you
can standardize. Regarding the privacy claims specifically, there's
are a ton of things someone can learn given nothing but the method and
routing information. Let's not fool ourselves into thinking that even
the most rudimentary activity information is somehow "safe" from
disclosure.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jul 2014 19:26:33 +0200

> we should start to pave the road for it now.

What I'm saying is that yes, pave the road, but do not make this depend 
on query or not.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 17:56:24 +0000

In message <[email-masked]>, James M Snell wr
ites:

>Regarding the privacy claims specifically, there's

My point is that a lot of that information is already leaked by TLS
and by carefully choosing to leak a little more, we may be able to
protect the rest a lot better.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 15 Jul 2014 18:16:52 +0000

>What I'm saying is that yes, pave the road, but do not make this depend 

The reason I'm pointing to :query is that it is already treated as
more sensitive than the path, for instance NCSA logformat doesn't
record it by default etc.

It's an abstraction people know, and some people already think about
it as "the private part", so it makes for a good stepping stone.