Subject: Fwd: Call for Adoption: draft-song-dns-wireformat-http

From: tjw ietf <[email-masked]>
Date: Tue, 2 Aug 2016 20:23:40 -0400

Happy HTTP folks

This draft came up in Buenos Aires and there was interest in the group from
contributing.  I was double booked in Berlin and wasn't able to attend, but
mnot politely reminded me about this.

The draft went through adoption and has been adopted by DNSOP.  It's still
can be worked on, and any and all comments on the ideas etc would be
happily accepted.

thanks
tim

---------- Forwarded message ----------
From: Tim Wicinski <[email-masked]>
Date: Mon, Jul 11, 2016 at 6:33 PM
Subject: Call for Adoption: draft-song-dns-wireformat-http
To: dnsop <[email-masked]>

This starts an official Call for Adoption for
         draft-song-dns-wireformat-http

The draft is available here:
https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

We wanted this Call to coincide with the Berlin meeting so if there is
opinions that needed to be voiced, they can do so.

This call for adoption ends: 25 July 2016

Thanks,
tim wicinski
DNSOP co-chair

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Aug 2016 10:39:50 +1000

It would be really awesome if someone could summarize the reasons that
the alternative proposals (those cited in the doc) were not adopted.
I see a few red flags in the doc:

"The protocol is intended to serve as a sort of DNS VPN" -- there's a
long history of abuse of HTTP of exactly this form; probably because
it's easier.  See the above question regarding potentially better
alternatives.

"in this approach wire-format data is wrapped with a HTTP header and
transmitted on port 80 or 443."  -- two things: the wire format seems
to go in the body; and using port 80 is a terrible idea.

I don't see any reason that this needs to use a .well-known resource.

What happens when you get a response where the ID doesn't match the request?

On 3 August 2016 at 10:23, tjw ietf <[email-masked]> wrote:
> can be worked on, and any and all comments on the ideas etc would be happily
> accepted.
>
> thanks
> tim
>

---

From: tjw ietf <[email-masked]>
Date: Tue, 2 Aug 2016 20:47:01 -0400

Martin,

I think one of the things which came up during the discussion was to drop
port 80 all together.

I'm circling back with the authors and I know we've covered this ground so
I'll work with them to summarize.

There was another draft which discussed various methods of DNS over HTTP
https://datatracker.ietf.org/doc/draft-shane-review-dns-over-http/

We didn't choose to put it up for adoption, but it may be worthy to merge
some of that into this document.

thanks
tim

On Tue, Aug 2, 2016 at 8:39 PM, Martin Thomson <[email-masked]>
wrote:

> happily

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Aug 2016 12:11:16 +1000

> some of that into this document.

The questions that that document asks are the right ones, namely: what
is the purpose of the protocol?  Avoiding network errors is - at least
in my view - a poor reason to move to HTTPS.  How HTTP is used is one
issue that needs to be considered when choosing an approach;
draft-song doesn't really do that very well.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Aug 2016 13:09:45 +0200

> On 3 Aug 2016, at 2:39 AM, Martin Thomson <[email-masked]> wrote:
> 

+1. 

Would DNSOP consider alternative approaches if they were submitted soonish, or are you committed to using this document as a starting point? 

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Aug 2016 11:21:59 +0000

--------

>mnot politely reminded me about this.

That reminds me:

I should really try to get my IP-over-HTTP draft adopted.

(Yes: That was my way of saying:  What a horrible idea!)

-- 
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: Tim Wicinski <[email-masked]>
Date: Wed, 3 Aug 2016 07:11:17 -0400

> Would DNSOP consider alternative approaches if they were submitted soonish, or are you committed to using this document as a starting point?

Alternative Approaches are always welcome.

tim

---

From: Patrick McManus <[email-masked]>
Date: Wed, 3 Aug 2016 10:12:19 -0400

On Wed, Aug 3, 2016 at 7:21 AM, Poul-Henning Kamp <[email-masked]>
wrote:

> should really try to get my IP-over-HTTP draft adopted.
>

weirdly, with h2 push the mapping is pretty straight forward. Still a bad
idea as you say ;)

of course, IP-over-DNS is a typical desperate tunnel of last result to run
https.. combined with dns over h2 that could give you
h2-over-tls-over-tcp-over-ip-over-dns-over-h2-over-tls-over-tcp-over-ip.
I'm sure that would be totally fine from a congestion and flow control pov
:(

Mostly, I jest. Like many others I would like to see some standardized
support for DNS transported in HTTP. There are a lot of different use cases
that have already been discussed in this thread, but one that has come up
in the past and is so far missing would be priming the local HTTP agent for
anticipated cross origin resolutions (obviously with appropriate
certificates attached). I'll send a different email.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Aug 2016 14:25:44 +0000

--------
In message <CAOdDvNqX438A48aWf8x=[email-masked]>, Patrick McManus writes:

>I'm sure that would be totally fine from a congestion and flow control pov :(

It would be *so* much more productive to try to tackle these problems
as the political human-rights issues they are, than stacking boxed higher
and higher trying to cross over the walls people erect.

The one sure result from tunnelling more and more through HTTPS is that
HTTPS will be MiTM'd and blocked more and more.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 3 Aug 2016 11:08:00 -0400

> Alternative Approaches are always welcome.

As an aside, I thought draft-shane was very interesting - thanks for
mentioning it here.

Here's what I have heard as "requirements" around dns in http in the past:

* a standard application developer api for lookup. Often expressed as
REST/JSON
* a standard application developer api for publishing changes. Often
expressed as REST/JSON
* a tunnel for the DNS protocol
* a push mechanism for broadcasting DNS info relevant to the http connection
* solid integration with HTTP caches

I know there have been a number of json-ification discussions in the past.
Maybe its time to roll those, the DNS expertise, and the HTTP expertise
into a unified effort? It seems this is an easy space to accidentally
partition out to its own domain experts and end up with something that
isn't satisfying to the whole. I would hope to avoid that. Tim, what are
your thoughts on that?

Doing that is certainly a more ambitious project than just tunneling an
existing protocol, but I think its potential impact is much bigger -
especially if it gets the right people in the room.

In addition to the differing sets of requirements, I think there are
different perspectives on eco-system and security impacts to be had.

-Patrick

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 03 Aug 2016 21:58:56 +0000

In our customer base, the biggest driver to deploy MitM is the refusal 
of browsers to display block pages from denied CONNECT requests.

------ Original Message ------
From: "Poul-Henning Kamp" <[email-masked]>
To: "Patrick McManus" <[email-masked]>
Cc: "tjw ietf" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 4/08/2016 2:25:44 AM
Subject: Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

>--------
>In message 
><CAOdDvNqX438A48aWf8x=[email-masked]>, 
>Patrick McManus writes:
>

---

From: Nicolas Mailhot <[email-masked]>
Date: Thu, 04 Aug 2016 15:06:46 +0000

Same here, no block pages -> MITM

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 6 Aug 2016 10:25:56 +1000

Would this help?

https://mnot.github.io/I-D/proxy-explanation/

Keep in mind that only helps for configured proxies. 

Sent from my iPhone

> On 5 Aug 2016, at 1:06 AM, Nicolas Mailhot <[email-masked]> wrote:
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 06 Aug 2016 21:45:50 +0000

Hi Mark

thanks for putting that together, it looks interesting.

My gut feel is that customers will continue to wish to present their own 
content/page to blocked users, containing things such as

* company and/or jurisdictional boilerplate / warnings etc
* branding
* organisation-specific links (e.g. to more info on policy, or request 
form to remove entry from block-list)

One other issue looming is that of the captive portal, which generally 
requires that the initial conversation use http/1.1 over port 80.  as 
more things move to https, this becomes more difficult.

So the ability to advertise a captive portal would be useful to add to 
this draft.

Then finally the issue around intercepted connections.  I really can't 
see these going away.

As far as the draft goes, I still don't really buy that browser vendors 
couldn't portray a block page in a way that is unambiguously NOT the 
target site - e.g. that cannot be made to look like or behave like the 
banking site (pop it in a dialog for example).  I think a little more 
commitment and imagination could have resolved this problem and not 
caused the large amount of pain that the chosen expedient path has ended 
up causing.

For a 30x response to CONNECT we need to decide whether such a thing 
makes any logical sense or even should be permitted.

You can't MitM from an unknown source without causing at least 
certificate warnings - with HSTS this is a show-stopper for an active 
network attacker, unless they intercept the very first request to that 
site.  Sanctioned MitM in an organization can currently only be 
distinguished from end-to-end encryption by inspecting the certificate 
chain, and this is a crime against users, it should be simple to make it 
obvious to users when their https is being inspected.  E.g. tie the 
proxy configuration to the root of the cert tree - again this would only 
work for non-intercepted.

So I'm a little on the fence on this proposal for browsers, but for 
other agents, I think the machine-readable information could be very 
useful, so overall I'm in favour of such an approach. It could however 
alternatively be transported in a header, leaving the body for 
customization by the organization.

One thing I would love to see more work done in is proxy discovery.  
Many many of our users want to use interception, so they can avoid the 
deployment issues.  WPAD goes some of the way, but there are still 
problems with that.

If we continue to just wish that connection interception and MitM will 
just go away, we won't improve things for users.  There should be a way 
for a intercepting proxy to safely (from a client POV) impose itself 
with full knowledge and assent of the client.

Cheers

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Nicolas Mailhot" <[email-masked]>
Cc: "Adrien de Croy" <[email-masked]>; "Poul-Henning Kamp" 
<[email-masked]>; "Patrick McManus" <[email-masked]>; "HTTP 
Working Group" <[email-masked]>
Sent: 6/08/2016 12:25:56 PM
Subject: MITM and proxy messages [was: Call for Adoption: 
draft-song-dns-wireformat-http]

---

From: [email-masked]
Date: Sun, 7 Aug 2016 09:00:09 +0200 (CEST)

----- Mail original -----
De: "Mark Nottingham" 
Objet: MITM and proxy messages [was: Call for Adoption: draft-song-dns-wireformat-http]

> Keep in mind that only helps for configured proxies. 

For private proxies it would help. Corps would probably be ok with dumping proxy page chrome as long as it is encrypted to avoid spoofing, the user agent warns if the cert changes, and browsers do not do the usual "end of the world" generic message

It's still missing a huge part however: proxy auth. There is no wish to allow a random attacker to drill through corp firewalls just by plugging a gadget on a free ethernet port

I don't see it work for public commercial captive portals (without necessary a proxy behind) such a the one I'm currently using. Those guys want to display their brand proheminently if only to tell people "look, if you was my customer, you could use the free-for-my-customers hotspot I deployed deep in this remote place" (which means auth again to prove you are a customer or paid a on-off fee, + reauth because reception of such hotspots is flacky and the connexion needs restablishing every time you move out of range).

As for the "but banks" objections it would be time for browsers people to realise banks do *not* design their sites any different than otherq, and all the efforts those past years to allow http mashups, third party adds, tracking cookies mean there is no way to check bank web sites anymore. They now call third-party js, add agency, just like the others. They may lag a little (on-two years) but the result is the same.

It is not possible to promote hoplessly insecure practices for some sites and hope they won't spread.

---

From: "Walter H." <[email-masked]>
Date: Sun, 07 Aug 2016 19:25:22 +0200

> Keep in mind that only helps for configured proxies.
configured proxies are not the bug; why not just simpy use plain HTML?

your sample chould then just be this simple:

HTTP/1.1 403 Forbidden
Content-Type: text/html
Cache-Control: no-cache

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<META  HTTP-EQUIV="Content-Type"CONTENT="text/html; charset=iso-8859-1">
<TITLE>Policy Violation</TITLE>
/HEAD>
<BODY>
<H1>Policy Violation</H1>
<UL>
<LI>This content is above your pay grade.<A HREF="https://acme.example.com/why?https://www.example.net">More Info</A>.
</LI>
</UL>
<HR>
<ADDRESS>Acme Networks Proxy</ADDRESS>
</BODY>
</HTML>

is this really a disadvantage doing it this way? and if yes, why?

without having the signing certificate used by the proxy installed in the certstore of the client
the "new way" have no advantages;

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 8 Aug 2016 03:39:45 +1200

> form to remove entry from block-list)

You can drop the first. Any variantions from the plain free-form text
paragraph offered by the template will invariably derive from branding
and PR marketing requirements.

You can drop the last. URL is already included. Variations might require
several (but wy when one can link to others?) or again tie back to some
branding PR marketing policy.

So, branding and marketing, branding, or marketing and branding. Take
your pick.

> So the ability to advertise a captive portal would be useful to add to

I was just thinking 511 status needs adding to the list of recommended
responses to use the template with, to promote it a bit more.

> makes any logical sense or even should be permitted.

I can imagine it possibly being useful in the WebSockets CONNECT
responses. Based on prior Alt-Svc knowledge.

In HTTP it makes little sense. Even a 4xx with Alt-Svc does a bit better
logically.

I have been encouraging people to use 511 instead of any 30x they may be
tempted by. Last I heard there was no noticable browser support, so both
work equally badly there. But at least they will be ready when 511
arrives and is working for some other client tools already.

> site.

I thought that too until last year. Without pinning and similar CA
restrictions HSTS can be blown away as easily as NAT'ing port 443. When
pinning is used, the flag which HSTS sets dynamically might as well be
part of the pinned data, not wasting space in each HTTP(S) message.

>  Sanctioned MitM in an organization can currently only be
> obvious to users when their https is being inspected.

This is the major reason I still like DANE. Anyone can check the domains
official CA certs tree and compare. Even if they have something saying
they have to trust this unexpected CA, clients can at least see that A != B.

>  E.g. tie the

Hmm. Can you elaborate please about how that tie would work?

For some reason I think you mean something other than DNS WPAD with DANE
to verify the hostname from which to send a secret client-key (encoded
to that hosts DANE provided public host-key) and fetch a
Content-Encoded:aesgcm PAC-like file encoded to the secret client-key.

> customization by the organization.

I expect that would lead to just as many complaints asking about why
their fancy body got ignored. If fancy body is possible, or even hinted
at being possible. It will be mandatory required somewhere for what turn
out to be marketing reasons.

> with full knowledge and assent of the client.

Aye. See above. The major parts are finally falling into place, but
there are still some holes to plug.

Amos

---

From: Kari hurtta <[email-masked]>
Date: Sun, 7 Aug 2016 20:50:28 +0300 (EEST)

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0390.html

> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

Major browsers do not show this when they get
that on response of CONNECT -request.

Bug 637619 - Display better error messages when HTTPS proxy servers return non-200 error codes 
https://bugzilla.mozilla.org/show_bug.cgi?id=637619

/ Kari Hurtta

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 7 Aug 2016 20:45:35 +0300

> configured proxies are not the bug; why not just simpy use plain HTML?
 
Except that if you try rejecting the CONNECT, the browsers just throw
up generic error about connection failed and will just plain discard
any payload the proxy sends.

(And pretty much the same for non-browsers, if those even support
CONNECT).

And for http://, yes, the page will be displayed in browsers,
but authority of response will be misinterpretted, creating other
problems. In non-browsers, this can really create a mess.

-Ilari

---

From: "Walter H." <[email-masked]>
Date: Sun, 07 Aug 2016 20:54:22 +0200

> that on response of CONNECT -request.
which in fact is caused by something different - my MITM proxy generates 
errors that are shown by my browser;
and these errors are simple HTML

a MITM proxy uses a certificate for signing sites ...

e.g. the proxy uses a certificate called  Proxy-CA, then for every site 
you want to go to there will be a created a SSL certificate which is 
signed by Proxy-CA;
if the Proxy-CA was signed by a CA that is a built in token in the 
certstore of your browser or you have installed the Proxy-CA certificate 
in the certstore yourself, then your browser will show this simple HTML 
error page the proxy is sending;

> https://bugzilla.mozilla.org/show_bug.cgi?id=637619
this is not really bug - it was filed at the times the browser (firefox) 
starts warning for invalid or self signed certificates ...
with mnot's "solution" ths would be same;

so where is the advantage of this?

---

From: "Walter H." <[email-masked]>
Date: Sun, 07 Aug 2016 21:00:55 +0200

On 07.08.2016 19:45, Ilari Liusvaara wrote:
> Except that if you try rejecting the CONNECT,
then my browser shows the correct message

e.g.

While trying to retrieve the URL: https://www.xxx.ru/*

The following error was encountered:

  * *Top-Level-Domain Blocked. *

Access control configuration prevents your request from being allowed at 
this time.
Please contact your service provider if you feel this is incorrect.

in this case it has no relevance if the host www.xxx.ru really exists or 
not, because the whole TLD .ru is blocked and this check is done much 
before;

I'm using squid as my MITM-proxy

> the browsers just throw
yes, because these apps warn you that there is a certificate in use they 
don't  know; install the signing certificate of the proxy and it works 
as I've shown above ...

---

From: Kari hurtta <[email-masked]>
Date: Sun, 7 Aug 2016 22:07:44 +0300 (EEST)

Walter H. <[email-masked]>: (Sun Aug  7 21:54:22 2016)
[ Charset ISO-8859-1 converted... ]
> a MITM proxy uses a certificate for signing sites ...

So that is on TLS which is tunneled via CONNECT.

> error page the proxy is sending;

Yes, content was

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0367.html

| In our customer base, the biggest driver to deploy MitM is the refusal 
| of browsers to display block pages from denied CONNECT requests.

does not require MITM.

That can be show when CONNECT fails and tunneled TLS
is not established.

/ Kari Hurtta

---

From: "Walter H." <[email-masked]>
Date: Sun, 07 Aug 2016 22:03:55 +0200

> https://mnot.github.io/I-D/proxy-explanation/
of course not; and the result will be the same ...
> That can be show when CONNECT fails and tunneled TLS
not really; when the proxy refuse connections without MITM, then the 
result the proxy replies is nearly the same
and the result the browser does also ...

when the agent is too stupid to present this

HTTP/1.1 403 Forbidden
Content-Type: text/html
Cache-Control: no-cache

<LI>This content is above your pay grade.<A HREF="https://acme.example.com/why?https://www.example.net"  <https://acme.example.com/why?https://www.example.net>>More Info</A>.

it won't present this:

     HTTP/1.1 403 Forbidden
     Content-Type: application/proxy-explanation+json
     Cache-Control: no-cache

     {
       "name": "Acme Networks"
       "title": "Policy Violation"
       "description": "This content is above your pay grade."
       "moreinfo": "https://acme.example.com/why?https://www.example.net"
     }

too;

no difference;

the error the proxy replies could also be the following:

     HTTP/1.1 403 Forbidden
     Content-Type: text/plain
     Cache-Control: no-cache

     Acme Networks Proxy says: "Policy Violation"
     Because: This content is above your pay grade.
     For more informations see: https://acme.example.com/why?https://www.example.net

Walter

---

From: Kari hurtta <[email-masked]>
Date: Sun, 7 Aug 2016 21:58:05 +0300 (EEST)

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0393.html

| And for http://, yes, the page will be displayed in browsers,
| but authority of response will be misinterpretted, creating other
| problems. In non-browsers, this can really create a mess.

application/proxy-explanation+json does not necessary work for
http://

https://mnot.github.io/I-D/proxy-explanation/#rfc.section.4

| They can be mitigated in a few ways:
| 
| ∙    Not displaying the moreinfo member in situations 
|      when this is possible (i.e., on any response other 
|      than that to a CONNECT on an encrypted connection).
| 
| ∙    Not supporting the 
|      application/proxy-connection+json media type when the 
|      method is not CONNECT and the connection is not 
|      encrypted.
| 
| ∙    Cautioning the user that the content might not be 
|      trustworthy.

I has some suggestions with that

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0303.html
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0306.html

But because Connection: seems not be implemented, this does not really
work.

/ Kari Hurtta

-------------------------------------------------------------------------
Date: Wed, 2 Mar 2016 07:08:46 +0200 (EET)
From: Kari Hurtta <[email-masked]>

Thomas Mangin <[email-masked]>: (Tue Mar  1 17:32:22 2016)
>>> Otherwise when browser is configured to use proxy and
>>> URL is http, browser do not use CONNECT but original
>>> http -method (GET and so on). Given url just is
>>> absolute.
> 
> Client implementations are able to use CONNECT when requesting HTTP 
> through a proxy but the major implementations choose not to do so.
> Changing this behaviour is probably inadvisable as current proxies will 
> most likely simply drop the connection when getting a CONNECT message 
> for HTTP page.
> 
> And while the feature is most useful for CONNECT with HTTPS, and while 
> it is likely that some proxies will continue to prefer ‘branded’ 
> HTML pages, allowing the use of this answer on non CONNECT request may 
> also hold value as promoting homogeneity to the user experience between 
> HTTP and HTTPS.
> 
> Thomas

| This approach does not preclude an origin server presenting itself as a 
| the proxy, in cases where the client supports the 
| media type on requests other than CONNECT.

If homogeneity of the user experience is desired (as I suggested)
and there is need for avoid origin server presenting itself
as a proxy (for example when request method was GET), there
is possibility to use nonce.

This is perhaps overengineering here:

Register new header field for that nonce.

Browser may include that on request when it is using proxy:

New-header-field: nonce-value
Connection: new-header-field

Connection header field prevents origin server seeing
this (if proxy follows HTTP/1.1 -- I do not know how 
this play with HTTP/2, but HTTP/2 is likely to be used 
only  with encrypted connections / with CONNECT method. )

Given nonce-value can be included to application/proxy-explanation+json
as own member.

( Header field name should be something short like
  'proxy-nonce', I think. )

| Clients SHOULD indicate that they support this media type by including it 
| in the field-value of the Accept request header 
| field [RFC7231] of all supported requests.

To reduce fingerprinting and request size, browser probably use just */* as 
Accept -header value. 

( I notice that also this new nonce header field ('proxy-nonce' for example) 
  may work as indicator that application/proxy-explanation+json is supported 
  by browser. )

/ Kari Hurtta

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 08 Aug 2016 02:05:36 +0000

>Hmm. Can you elaborate please about how that tie would work?

Basically the client browser would be configured to

a) use a proxy and
b) understand that https via that proxy will have a specific cert at the 
root of the cert hierarchy

Kinda like cert pinning for a proxy.

How this is configured / bootstrapped is another matter.

But say we solve that problem, then the client can know nothing else is 
between it and the proxy for https.

>out to be marketing reasons.

fair enough.

It may even be possible to allow for an image in the json.  As long as 
it can't be an anchor, you can't present a fake site with it.

>there are still some holes to plug.

It's kinda crazy that browsers, which are supposedly so 
security-conscious are still happy to download and evaluate javascript 
from some source they don't really verify (e.g. result of DNS lookup for 
WPAD or DHCP option 252).

An active attacker could very easily get themselves set up as the proxy 
by spoofing DHCP INFORM responses, or intercept requests to the WPAD 
server.

I wonder what restrictions there are on the code that may be evaluated 
in FindProxyForURL(...)

Adrien

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 12:17:26 +1000

On 8 August 2016 at 12:05, Adrien de Croy <[email-masked]> wrote:
> It's kinda crazy that browsers, which are supposedly so security-conscious
> are still happy to download and evaluate javascript from some source they
> don't really verify (e.g. result of DNS lookup for WPAD or DHCP option 252).

I'm fairly sure that no browser wants to do that.  The alternative
must be worse though.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 08 Aug 2016 02:49:01 +0000

looks like there were a few presentations on it at black hat USA 2016.

Fundamentally the PAC file comes down in the clear, from an unverified 
source.

Can use the DNS lookup facility to effectively log any URL that is 
presented to the function, thereby leaking querystrings and URLs for 
https URIs.

Proxy auto detect is enabled by default in pretty much all browsers at 
the moment it seems.

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 8/08/2016 2:17:26 PM
Subject: Re: MITM and proxy messages [was: Call for Adoption: 
draft-song-dns-wireformat-http]

>>security-conscious

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 12:09:48 +1000

> configured proxies are not the bug; why not just simpy use plain HTML?

Because the problem we're trying to avoid is spoofing.  The browser
needs to own the UX for the page that appears or we risk showing
something that could be mistaken for the real thing.  A link and some
text is maybe manageable.

To Amos' point, branding is likely a step too far.  Yielding that much
control over pixels is probably not going to happen.  And yes, this
implies that we don't trust the proxy.  If the user wanted
bank.example.com and they got proxy.example then that looks like an
attack.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 13:34:52 +1000

I'm familiar with the attack; I assumed that you were referring to it.
And yes, it's not great that we're leaking URLs.  I expect that to be
corrected (at least partially).

But I'm not sure what your point here is.

On 8 August 2016 at 12:49, Adrien de Croy <[email-masked]> wrote:
> Can use the DNS lookup facility to effectively log any URL that is presented
> to the function, thereby leaking querystrings and URLs for https URIs.
>
> Proxy auto detect is enabled by default in pretty much all browsers at the
> moment it seems.
>
> Adrien
>
>

---

From: [email-masked]
Date: Mon, 8 Aug 2016 08:30:58 +0200 (CEST)

Hi Martin,

Yes branding sucks but users want branding so at least define an embedded data: logo with strict limits on size and format.

Sure that can be abused via image parsing bugs but real life is a compromise. Browsers routinely accept much worse via wab fonts urls

Regards,

-- 
Nicolas Mailhot

---

From: [email-masked]
Date: Mon, 8 Aug 2016 08:35:54 +0200 (CEST)

----- Mail original -----
De: "Adrien de Croy" 

Hi,

> presented to the function, thereby leaking querystrings and URLs for 

And that's a direct result of forcing proxy communication to piggy-back instead af specifying dedicated gateway frames in HTTP/2

When you piggy back you leak unrelated trafic. That's how piggy backing works.

Regards,

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 08 Aug 2016 07:57:44 +0000

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

>https://mnot.github.io/I-D/proxy-explanation/

I doubt it.

It might work if it was in a HTTP header, so that the proxy-owner
still can plaster logos all over the browser, but then we get
into the do we need a "418 Proxy says no" status etc. etc.

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 8 Aug 2016 23:25:24 +1200

> don't  know; install the signing certificate of the proxy and it works
This is squid working aroudn al the problems we are discussing here.

When you install the proxy CA cert Squid accepts the CONNNECT, MITM's
the TLS session, accepts the first HTTPS message from the browser - and
produces that error page that you see as if it were the response from
the HTTPS www.xxx.ru origin for that page.

It does all this nasty and complicated activity because the browser will
not show the error in response to the original CONNECT.

Amos

---

From: "Walter H." <[email-masked]>
Date: Mon, 08 Aug 2016 18:50:39 +0200

On 08.08.2016 04:09, Martin Thomson wrote:
> On 8 August 2016 at 03:25, Walter H.<[email-masked]>  wrote:
> needs to own the UX for the page that appears
need to own what?
UX = ?

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 9 Aug 2016 00:32:57 +1200

> https://bugzilla.mozilla.org/show_bug.cgi?id=637619

The more relevant and core issue here is #479880 (aka CVE-2009-1835).

Adams quick solution:
 <https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c2>

Henriks solution:
 <https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c75>

So would anyone authoring a browser care to explain why Adams quick-fix
is still being used today by all browsers and Henriks solution is
discarded out of hand on grounds of being "unsafe". For values of
"unsafe" which under close inspection turn out to be straw-man arguments
about this CVE existing when _neither_ soution is used.

If you notice the logic in comment #8 of that bug will also mean that
*any* payload on any type of response will be discarded on CONNECT. That
includes the Draft proposed JSON message body.

Amos

---

From: Mike Bishop <[email-masked]>
Date: Mon, 8 Aug 2016 20:14:16 +0000

See https://msdn.microsoft.com/en-us/library/dd358571.aspx:  IP over HTTPS Tunneling Protocol, in-box in Windows since Win7 and still there.

-----Original Message-----
From: Poul-Henning Kamp [mailto:[email-masked]] 
Sent: Wednesday, August 3, 2016 4:22 AM
To: tjw ietf <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Fwd: Call for Adoption: draft-song-dns-wireformat-http

--------
In message <[email-masked]>, tjw ietf writes:

>Happy HTTP folks
>
>This draft came up in Buenos Aires and there was interest in the group 
>from contributing.  I was double booked in Berlin and wasn't able to 
>attend, but mnot politely reminded me about this.

That reminds me:

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 16:39:09 +1000

> Yes branding sucks but users want branding so at least define an embedded data: logo with strict limits on size and format.

I have no problem with an image being defined.  I can't promise that
it will be disabled (or where), because I don't do our security UX,
but it's a reasonable request.

As for image parsing bugs, yeah I agree.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 08 Aug 2016 22:22:43 +0000

+1 on the image.

Users want to see something so they know the response is coming from 
someone/something they have heard of, and the logo is the most effective 
way to do this, since people don't read text.

Otherwise if there's any question about the source of the message, it 
becomes ineffective.

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Nicolas Mailhot" <[email-masked]>
Cc: "Walter H." <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 8/08/2016 6:39:09 PM
Subject: Re: MITM and proxy messages [was: Call for Adoption: 
draft-song-dns-wireformat-http]

>>  Yes branding sucks but users want branding so at least define an 
>>embedded data: logo with strict limits on size and format.
>

---

From: Patrick McManus <[email-masked]>
Date: Mon, 8 Aug 2016 19:37:57 -0400

source.
> Can use the DNS lookup facility to effectively log any URL that is
presented to the function, thereby leaking querystrings and URLs for https
URIs.
the moment it seems.

Firefox hat.

Wpad is not enabled by default in firefox.. especially from use system
settings in windows which is default there.. because of wpads security
problems you need to opt in to it.

Sorry for resend.. phone replied from a addr not subscribed 1st time

> Cc: "Amos Jeffries" <[email-masked]>; "[email-masked]" <
[email-masked]>
security-conscious

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 17 Aug 2016 11:18:04 +1000

> On 4 Aug 2016, at 1:08 AM, Patrick McManus <[email-masked]> wrote:
> 
> 
> As an aside, I thought draft-shane was very interesting - thanks for mentioning it here.
> 
> * a standard application developer api for lookup. Often expressed as REST/JSON
> * a standard application developer api for publishing changes. Often expressed as REST/JSON
> I know there have been a number of json-ification discussions in the past. Maybe its time to roll those, the DNS expertise, and the HTTP expertise into a unified effort? It seems this is an easy space to accidentally partition out to its own domain experts and end up with something that isn't satisfying to the whole. I would hope to avoid that. Tim, what are your thoughts on that?
> 
> Doing that is certainly a more ambitious project than just tunneling an existing protocol, but I think its potential impact is much bigger - especially if it gets the right people in the room.
> 
> In addition to the differing sets of requirements, I think there are different perspectives on eco-system and security impacts to be had.

+1 to that. Who'd be interested in a side meeting (Bar BoF, separate session, whatever) in Seoul? 

Cheers,

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 16 Aug 2016 21:27:06 -0400

Sign me up

Tim

From my high tech gadget

> On Aug 16, 2016, at 21:18, Mark Nottingham <[email-masked]> wrote:
> 
>