Subject: Fwd: New Version Notification for draft-nottingham-proxy-explanation-00.txt

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Feb 2016 12:59:23 +1100

FYI - would be interested in what people thought, as I know some folks have this problem.

Pretty (and slightly updated) version at:
  https://mnot.github.io/I-D/proxy-explanation/

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-proxy-explanation-00.txt
> Date: 17 February 2016 at 11:38:12 AM AEDT
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-proxy-explanation-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-proxy-explanation
> Revision:	00
> Title:		The application/proxy-explanation+json media type
> Document date:	2016-02-17
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-nottingham-proxy-explanation-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-proxy-explanation/
> Htmlized:       https://tools.ietf.org/html/draft-nottingham-proxy-explanation-00
> 
> 
> Abstract:
>   This specification defines the application/proxy-explanation+json
>   media type, to allow HTTP proxies to explain to clients why a request
>   is unsuccessful.
> 
> Note to Readers
> 
>   The issues list for this draft can be found at
>   https://github.com/mnot/I-D/labels/proxy-explanation .
> 
>   The most recent (often, unpublished) draft is at
>   https://mnot.github.io/I-D/proxy-explanation/ .
> 
>   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
>   pages/proxy-explanation .
> 
> 
> 
> 
> 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   https://www.mnot.net/

---

From: "Thomas Mangin" <[email-masked]>
Date: Mon, 29 Feb 2016 19:32:00 +0000

> FYI - would be interested in what people thought, as I know some folks 

Hi Mark,

I am interested. To explain our predicament:

My business provides content filtering for schools. In the UK, Schools 
have a legal obligation to protect children from ‘harmful’ content, 
so content filtering is not going to go away.

Historically DNAT’ing port 80 to a filtering proxy farm and blocking 
port 443 was enough: the primary concern of schools is to stop children 
to accessing adult material, games and social media sites. Nowadays most 
of the educational content is under HTTPS and the main worry is 
radicalisation.

In order to do so, a school can decide to perform SSL decapsulation. We 
offer this solution through the installation of a local firewall/proxy 
which is fine for secondary schools but quite expensive for primaries 
who prefer to use ‘cloud’ services ( primary teachers are not very 
IT literate and do not have an IT department ).

Therefore many schools do block port 80/443 and only allow traffic to 
our our proxies servers or use AD to force the use of the proxy. While 
it does not allow some of the most advanced feature we provide (like for 
example, checking search queries for self-harm terms as the full URL is 
not available), we can still block pages on a per host basis.

( I am happy to debate elsewhere why we decided to not offer SSL 
decapsulation ‘in the cloud’ at this point, and therefore why we 
rely on a ‘CONNECT’ based solution - just bring your lawyer to it :p 
)

So currently when a site is identified as ‘not for educational use’ 
(what is or is not deemed educational is under the control of the 
school), our only way to prevent the page to load is to completely kill 
the TCP connection after the inspection of the Host field in the CONNECT 
message.

However, on a regular basis a site will be blocked due to an 
over-zealous policy or simply a wrong categorisation for a site. 
Currently, our customers have no way to know if the ‘network error’ 
the browser is reporting is due to a genuine issue or a policy 
enforcement. Browser implementation of this draft would end this user 
confusion.

Our own proxy (you could call it a ‘software defined http gateway’) 
is already capable of using it.
A modified version of our code (which is open source) implements the 
draft (returning new response). You can have a look :-)

# git clone [email-masked]:thomas-mangin/exaproxy.git
# cd exaproxy
# env exaproxy.http.connections=100 exaproxy.tls.enable=false 
exaproxy.security.connect=80 exaproxy.redirector.enable=true 
exaproxy.redirector.program=etc/exaproxy/redirector/icap-deny-proxy-explanation 
exaproxy.redirector.protocol='icap://' ./sbin/exaproxy

This instance will refuse ANY connection to any site returning a 403 
page with an application/proxy-explanation+json payload. You can test it 
running the following test script

# ./QA/test/connect-http-google-proxy-explanation

Sincerely,

Thomas

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 12:01:31 -0800

Howdy,

On Sun, Feb 28, 2016 at 5:59 PM, Mark Nottingham <[email-masked]> wrote:

> The document says about the HTML content in a 403 "but browsers are
unwilling to show this to end users, since doing so would subject them to a
potential man-in-the-middle attack."; this same reluctance seems to me
likely to apply to the URL in the proposed JSON structure.  You note the
issue considerations section, but seem to come down on the side of
including it anyway.  Can you explain more about why? What's the other side
of this trade-off look like, in your thinking?

I found it odd that the document talked about forbidding origin servers
from generating the media type, rather than returning it a response.  Below
you say it MUST NOT be used with 2xx or 3xx responses; it seems like you
could also use similar language for origin server/CDN use.

The document says that "Clients MAY selectively support this media type.
For example, an implementation might deem it only useful (or safe) in
CONNECT requests."  Given the other restrictions, I don't use case outside
of CONNECT, and I would normally say that you shouldn't send an accept
header where you're not willing to receive the type; am I missing some of
your thinking here?

regards,

Ted

> > Subject: New Version Notification for
> draft-nottingham-proxy-explanation-00.txt
> > URL:
> https://www.ietf.org/internet-drafts/draft-nottingham-proxy-explanation-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-nottingham-proxy-explanation/
> > Htmlized:
> https://tools.ietf.org/html/draft-nottingham-proxy-explanation-00
> >
> >
> > Abstract:

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Mar 2016 10:49:27 +1100

> On 1 Mar 2016, at 7:01 AM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> The document says about the HTML content in a 403 "but browsers are unwilling to show this to end users, since doing so would subject them to a potential man-in-the-middle attack."; this same reluctance seems to me likely to apply to the URL in the proposed JSON structure.  You note the issue considerations section, but seem to come down on the side of including it anyway.  Can you explain more about why? What's the other side of this trade-off look like, in your thinking?

Browsers are unwilling to show HTML because it has the ability to masquerade as the origin; displaying a raw link doesn't, and there's significantly less chance that the user will be confused about that.

Still, it'd be good to have a discussion about whether / when the URL should be displayed. I included it to have that discussion, mostly :)

If we don't include it, I *suspect* it's going to be more difficult to meet some use cases (e.g., get support HERE, complain HERE), and I *suspect* proxies will just put links in the text anyway, to cut-and-paste.

> I found it odd that the document talked about forbidding origin servers from generating the media type, rather than returning it a response.  Below you say it MUST NOT be used with 2xx or 3xx responses; it seems like you could also use similar language for origin server/CDN use.

What's the use case for origin servers generating it?

> The document says that "Clients MAY selectively support this media type. For example, an implementation might deem it only useful (or safe) in CONNECT requests."  Given the other restrictions, I don't use case outside of CONNECT, and I would normally say that you shouldn't send an accept header where you're not willing to receive the type; am I missing some of your thinking here?

Interception proxies.

Cheers,

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 16:00:40 -0800

On Mon, Feb 29, 2016 at 3:49 PM, Mark Nottingham <[email-masked]> wrote:

> Browsers are unwilling to show HTML because it has the ability to
> masquerade as the origin; displaying a raw link doesn't, and there's
> significantly less chance that the user will be confused about that.
>
> Still, it'd be good to have a discussion about whether / when the URL
> should be displayed. I included it to have that discussion, mostly :)
>
> If we don't include it, I *suspect* it's going to be more difficult to
> meet some use cases (e.g., get support HERE, complain HERE), and I
> *suspect* proxies will just put links in the text anyway, to cut-and-paste.
>
> That kind of indicates that there may be a need for more than one URI, so
having a single "moreinfo" URI may not help avoid the cut-and-paste.  I
kind of suspect that the best thing to do is to provide the facility for
bare URIs in text, and ruthlessly suppress any ability to use anchor text
to hide what's in the URI.   That remains a bit of risk, but might be the
best balance.

> I don't have a use case for that, I was commenting on the oddity of
preventing them from generating it, rather than saying that MUST NOT return
it in a response (or even use it, as you say for 2xx and 3xx responses).  I
am perfectly willing to save my paint for other bikesheds, though.

> So, a client should send this accept request with all queries in case
there is a friendly enough man in the middle to tell them that the traffic
is being prevented and why?  I can't picture that being the right
trade-off, personally, but I'd be interested in whether this sounds
plausible to other folk.

regards,

Ted

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Mar 2016 11:38:59 +1100

> On 1 Mar 2016, at 11:00 AM, Ted Hardie <[email-masked]> wrote:
> 
> That kind of indicates that there may be a need for more than one URI, so having a single "moreinfo" URI may not help avoid the cut-and-paste.  I kind of suspect that the best thing to do is to provide the facility for bare URIs in text, and ruthlessly suppress any ability to use anchor text to hide what's in the URI.   That remains a bit of risk, but might be the best balance.

I think one link is good -- any additional information including other links can be found at the other end of it. The important thing is to give the user a solid clue that this communication is NOT from the origin they were making the request to; once they know that and follow a link -- which has a different origin -- the context is relatively clear.

> I don't have a use case for that, I was commenting on the oddity of preventing them from generating it, rather than saying that MUST NOT return it in a response (or even use it, as you say for 2xx and 3xx responses).  I am perfectly willing to save my paint for other bikesheds, though.

"generate" is specific terminology for HTTP -- see <http://httpwg.org/specs/rfc7230.html#conformance>. I may not have used it consistently here (or indeed, even generated it consistently).

> So, a client should send this accept request with all queries in case there is a friendly enough man in the middle to tell them that the traffic is being prevented and why?  I can't picture that being the right trade-off, personally, but I'd be interested in whether this sounds plausible to other folk.

Yeah, I doubt it too. It could be that we end up specifying it just for CONNECT.

I wanted to get an indication of implementer interest before I went too far into tweaking it, though...

Cheers,

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 1 Mar 2016 15:52:24 +1300

On 1/03/2016 1:38 p.m., Mark Nottingham wrote:
> 
>> On 1 Mar 2016, at 11:00 AM, Ted Hardie wrote:
>> 
>> On Mon, Feb 29, 2016 at 3:49 PM, Mark Nottingham wrote:
>> 
>>> The document says that "Clients MAY selectively support this
>>> media type. For example, an implementation might deem it only
>>> useful (or safe) in CONNECT requests."  Given the other
>>> restrictions, I don't use case outside of CONNECT, and I would
>>> normally say that you shouldn't send an accept header where
>>> you're not willing to receive the type; am I missing some of your
>>> thinking here?
>> 
>> Interception proxies.
>> 
>> So, a client should send this accept request with all queries in
>> case there is a friendly enough man in the middle to tell them that
>> the traffic is being prevented and why?  I can't picture that being
>> the right trade-off, personally, but I'd be interested in whether
>> this sounds plausible to other folk.
> 

FWIW; The "Accept: */*" header which is already very popular covers all
mime types including this one.

If we are intending this to be used to expose MITM in a clean way. Then
it does need to be spec'd for use on any method even if doing the IETF
thing of 'ignoring' MITM existence in the texts.

Also the worst display related issues are with browsers. Their current
behaviour is to not show anything at all from a CONNECT response
regardle of whether its an error or not.  So backward compatibility
there is already a non-issue - the JSON payload will be silently dropped
by the most problematic clients.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Mar 2016 14:10:43 +1100

> On 1 Mar 2016, at 1:52 PM, Amos Jeffries <[email-masked]> wrote:
> 

At the end of the day, an intercepting proxy can already inject anything into an unencrypted payload anyway, so I'm not sure this use case is going to be interesting. 

I'm sure some intercepting proxy folks would like to show something like this to the user for an encrypted stream, but that seems well out of scope for this spec. Anyway, having a mechanism for the proxy to talk to the user when it's legitimately configured instead of intercepting might encourage more people to deploy non-intercepting proxies :)

So, I think I'll adjust the language in the draft to make this specific to CONNECT.

Cheers and thanks for the feedback,