Subject: Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 May 2016 05:14:31 +0000

Hi Davey

Some general comments:

I don't think you can claim that https provides data integrity or 
privacy any more, since MitM proxies are abundant.

I think some thought should be given to how a DNS stub might deal with a 
captive portal or http proxy authentication.

I think also that any HTTP server that receives such a request probably 
ought to be validating the encapsulated binary data before forwarding it 
to any DNS server.

I wonder why you'd want to keep truncation, as the request should be 
able to benefit from the fact that fundamentally it's made over TCP to 
the HTTP agent.

I would also suggest looking into how such requests might be best 
blocked by an http proxy, because this will be a requirement of proxy 
operators, and it would be good to consider user experience for when 
this happens, so that a consistent approach can be taken (rather than 
every different proxy blocking it some other way so that the user 
experience becomes awful).

Cheers
Adrien

------ Original Message ------
From: "Davey Song" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 27/04/2016 8:43:09 p.m.
Subject: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

>Hi Colleagues,
>
>We have update the dns-wireformat draft according to the advice we 
>gained from last IETF meeting, changing the well-known URI from 
>dns-over-http to dns-wireformat according to Paul Hoffman's suggestion. 
>Any further comments ? I would like to ask for WG to adopt it this 
>time.
>
>Best regards,
>Davey
>
>---------- Forwarded message ----------
>From: <[email-masked]>
>Date: 27 April 2016 at 16:03
>Subject: New Version Notification for 
>draft-song-dns-wireformat-http-03.txt
>To: "Paul A. Vixie" <[email-masked]>, Shane Kerr <[email-masked]>, 
>Runxia Wan <[email-masked]>, Linjian Song <[email-masked]>
>
>
>
>A new version of I-D, draft-song-dns-wireformat-http-03.txt
>has been successfully submitted by Linjian Song and posted to the
>IETF repository.
>
>Name:           draft-song-dns-wireformat-http
>Revision:       03
>Title:          DNS wire-format over HTTP
>Document date:  2016-04-27
>Group:          Individual Submission
>Pages:          10
>URL:            
>https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-03.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
>Htmlized:       
>https://tools.ietf.org/html/draft-song-dns-wireformat-http-03
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-03
>
>Abstract:
>    This memo introduces a way to tunnel DNS data over HTTP.  This may 
>be
>    useful in any situation where DNS is not working properly, such as
>    when there is middlebox misbehavior.
>
>
>
>
>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: "Adrien de Croy" <[email-masked]>
Date: Tue, 03 May 2016 05:25:03 +0000

One other thing... there are plenty of http proxies that will rightly or 
wrongly strip or reject unknown header fields.

Since you're proposing the use of POST to send the query, why not also 
include the Proxy-DNS-Transport value as POST data also.

either inside the application/dns-wireformat definition, or some other 
new meta format, or just base64 encode the message, and include both 
parts as form data (application/x-www-form-encoded).

The same applies to unknown response headers (may be stripped or 
blocked)

Regards

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Davey Song" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 3/05/2016 5:14:31 p.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

>I think some thought should be given to how a DNS stub might deal with 
>a captive portal or http proxy authentication.
>
>ought to be validating the encapsulated binary data before forwarding 
>it to any DNS server.
>
>>dns-over-http to dns-wireformat according to Paul Hoffman's 
>>suggestion. Any further comments ? I would like to ask for WG to adopt 
>>it this time.
>>
>>Best regards,
>>Davey
>>

---

From: Davey Song(宋林健) <[email-masked]>
Date: Wed, 4 May 2016 13:28:42 +0800

It’s interesting idea. We have not discuss that before. I’m not sure the impact of bad HTTP proxies to this protocol.  Anyway it is not free to register a new head filed. I will discuss with co-author about delivering the TCP/UDP massage via other meta format. Thanks for your interest and comments.

Davey

发件人: DNSOP [mailto:[email-masked]] 代表 Adrien de Croy
发送时间: 2016年5月3日 13:25
收件人: Adrien de Croy; Davey Song; [email-masked]
主题: Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

One other thing... there are plenty of http proxies that will rightly or wrongly strip or reject unknown header fields.

Since you're proposing the use of POST to send the query, why not also include the Proxy-DNS-Transport value as POST data also.

either inside the application/dns-wireformat definition, or some other new meta format, or just base64 encode the message, and include both parts as form data (application/x-www-form-encoded).

The same applies to unknown response headers (may be stripped or blocked)

Regards

Adrien

------ Original Message ------

To: "Davey Song" <[email-masked]>; "[email-masked]" <[email-masked]>

Subject: Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

Hi Davey

Some general comments:

I don't think you can claim that https provides data integrity or privacy any more, since MitM proxies are abundant.

I think some thought should be given to how a DNS stub might deal with a captive portal or http proxy authentication.

I think also that any HTTP server that receives such a request probably ought to be validating the encapsulated binary data before forwarding it to any DNS server.

I wonder why you'd want to keep truncation, as the request should be able to benefit from the fact that fundamentally it's made over TCP to the HTTP agent.

I would also suggest looking into how such requests might be best blocked by an http proxy, because this will be a requirement of proxy operators, and it would be good to consider user experience for when this happens, so that a consistent approach can be taken (rather than every different proxy blocking it some other way so that the user experience becomes awful).

Cheers

Adrien

 

------ Original Message ------

Subject: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

Hi Colleagues, 

We have update the dns-wireformat draft according to the advice we gained from last IETF meeting, changing the well-known URI from dns-over-http to dns-wireformat according to Paul Hoffman's suggestion. Any further comments ? I would like to ask for WG to adopt it this time.

Best regards,

Davey

---------- Forwarded message ----------
From: <[email-masked]>
Date: 27 April 2016 at 16:03
Subject: New Version Notification for draft-song-dns-wireformat-http-03.txt
To: "Paul A. Vixie" <[email-masked]>, Shane Kerr <[email-masked]>, Runxia Wan <[email-masked]>, Linjian Song <[email-masked]>

Name:           draft-song-dns-wireformat-http
Revision:       03
Title:          DNS wire-format over HTTP
Document date:  2016-04-27
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-03.txt
Status:         https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
Htmlized:       https://tools.ietf.org/html/draft-song-dns-wireformat-http-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-03

Abstract:
   This memo introduces a way to tunnel DNS data over HTTP.  This may be
   useful in any situation where DNS is not working properly, such as
   when there is middlebox misbehavior.

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 <http://tools.ietf.org/> .

The IETF Secretariat

---

From: Davey Song(宋林健) <[email-masked]>
Date: Wed, 4 May 2016 13:43:19 +0800

I think the major benefit from this proposal is to make the upper layer(http layer) unaware the DNS data inside. So we do not need to consider the checksum-like mechanism , special authentication for DNS stub, and do keep truncation logic.  I accept your idea that a new head filed Proxy-DNS-Transport may break that transparency.

-Davey

发件人: DNSOP [mailto:[email-masked]] 代表 Adrien de Croy
发送时间: 2016年5月3日 13:15
收件人: Davey Song; [email-masked]
主题: Re: [DNSOP] Fwd: New Version Notification for draft-song-dns-wireformat-http-03.txt

Hi Davey

Some general comments:

Cheers

Adrien

 

------ Original Message ------

Hi Colleagues, 

Best regards,

Davey

---------- Forwarded message ----------
From: <[email-masked]>
Date: 27 April 2016 at 16:03
Subject: New Version Notification for draft-song-dns-wireformat-http-03.txt
To: "Paul A. Vixie" <[email-masked]>, Shane Kerr <[email-masked]>, Runxia Wan <[email-masked]>, Linjian Song <[email-masked]>

Abstract:

The IETF Secretariat

---

From: Shane Kerr <[email-masked]>
Date: Wed, 4 May 2016 16:18:24 +0200

Adrien,

Thanks for your comments.

At 2016-05-03 05:14:31 +0000

> privacy any more, since MitM proxies are abundant.

Can you explain this further?

TLS is designed to provide data integrity and privacy, even in the face
of man-in-the-middle attacks.

> captive portal or http proxy authentication.

I guess this makes sense. I don't know that we can offer much help
though. Perhaps something like this:

    A captive portal or any other middlebox that interferes with HTTP
    may break this protocol, and DNS over HTTP will have to be disabled
    until HTTP is restored.

> ought to be validating the encapsulated binary data before forwarding it 

I rather think this will increase the attack surface area rather than
decreasing it, because now you have an additional place processing DNS
packets.
 
> able to benefit from the fact that fundamentally it's made over TCP to 

If the client side is acting as a DNS proxy then we need to look like
DNS. The stub resolvers will send UDP packets and expect normal
truncation behavior. While it may be possible for the client DNS proxy
to perform truncation and send responses back to the stub resolvers,
this is a significantly more complicated design.

> experience becomes awful).

In the case of unencrypted HTTP (not recommended), then the proxy can
look for the well-known URI, right?

In the case of TLS, then the proxy cannot block the traffic, can it? It
doesn't know the URI that the site is visiting, nor the contents of the
query or answer....

Cheers,

--
Shane

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 04 May 2016 22:13:09 +0000

I don't know if dnsop is the place to rehash old arguments about TLS 
everywhere.

There are a few places in the archives of the http WG where it was 
discussed heatedly (for IETF) at length, especially around the de facto 
implementation of mandatory TLS everywhere in the context of http/2.0.

TLS was designed to provide data integrity and security, but not in the 
face of MitM attacks.  The only way to prevent these is with cert 
pinning (so the client can recognise a spoofed cert) or client certs 
which the intermediary can't spoof in a way that the server will trust.

Google's push for https everywhere has in our experience provided 
significant incentive for MitM deployment.  We only added MitM features 
to WinGate because google and facebook went https-only.  Prior to that 
it was hard to morally justify deploying a MitM to spy on people's 
banking traffic.

The other significant driver we see of MitM deployment was the 
deplorable decision by browser vendors that they would no longer trust 
non-200 responses to tunneling (CONNECT) requests.  This meant the only 
way to not have an awful (support incident generating) user experience 
when blocking connections to https sites at a proxy, was to MitM it, 
receive the request and send back a block response masquerading as the 
server.

The irony of this is completely wasted on the people who made these 
decisions.  The perceived threat was some page coming back from a 
CONNECT request which could get a broken browser to follow a redirect, 
or display the body as if it came from the https server (thereby 
allowing through broken browser design a masquerade opportunity).  
Instead of actually fixing the browsers, they all (FF, Chrome and IE and 
probably others) chose instead to ignore the response, and show a 
generic connectivity failure "friendly" page, which sends IT support 
people into a frenzy looking for broken network equipment.  The MitM 
response to this requires the proxy to masquerade as the origin server, 
which was exactly the issue the browser authors were trying to avoid by 
deciding to ignore non-200 responses in the first place, meanwhile 
causing proxy vendors and users significant pain.

As for the issue with captive portals.  Since the client needs to 
resolve names using DNS prior to making a connection, and since the 
captive portal will intercept port 80 and redirect it to a challenge 
page etc until the portal has been satisfied, you have a bit of a 
chicken and egg problem.  A browser won't try to connect if it gets a 
DNS lookup failure.  DNS lookups will fail until the browser attempts a 
connection and authenticates with the captive portal.  This is where the 
layering violation of DNS over HTTP is problematic.

It should be possible to detect that this is happening though, since the 
response won't contain an encapsulated DNS response in its message body. 
  One option then could be to return some fake A record to the DNS 
client, so that an attempt to connect will be made.

My main concern was that the HTTP <-> DNS gateway was likely behind the 
firewall that was otherwise protecting the DNS server from malicious DNS 
packets.  By putting in the gateway, you may be providing a back door 
for attacks on the DNS server.  Sure, DNS servers should be hardened, 
but they may not realise they can't trust requests from the gateway.

Adrien

------ Original Message ------
From: "Shane Kerr" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 5/05/2016 2:18:24 a.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for 

>>it

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 18:25:25 -0400

It's certainly a valid criticism of this proposal to say that it removes a
mechanism that is presently available for preventing attacks by filtering
malicious domains.   However, that capability is always available; the
difference here is that it's being described in a way that allows for
interop.   As for opportunistic security not solving all problems, that's
right.   It doesn't.   It just makes pervasive monitoring more expensive.
If you want to detect monitoring of a TLS connection, you need to use
additional mechanisms, e.g. TLSA, which can be validated in retrospect to
discover that a false key was presented.

On Wed, May 4, 2016 at 6:13 PM, Adrien de Croy <[email-masked]> wrote:

> face of MitM attacks.  The only way to prevent these is with cert pinning
> (so the client can recognise a spoofed cert) or client certs which the
> intermediary can't spoof in a way that the server will trust.
>
> significant incentive for MitM deployment.  We only added MitM features to
> WinGate because google and facebook went https-only.  Prior to that it was
> hard to morally justify deploying a MitM to spy on people's banking
> traffic.
>
> The other significant driver we see of MitM deployment was the deplorable
> decision by browser vendors that they would no longer trust non-200
> responses to tunneling (CONNECT) requests.  This meant the only way to not
> have an awful (support incident generating) user experience when blocking
> connections to https sites at a proxy, was to MitM it, receive the request
> and send back a block response masquerading as the server.
>
> decisions.  The perceived threat was some page coming back from a CONNECT
> request which could get a broken browser to follow a redirect, or display
> the body as if it came from the https server (thereby allowing through
> broken browser design a masquerade opportunity).  Instead of
> actually fixing the browsers, they all (FF, Chrome and IE and probably
> others) chose instead to ignore the response, and show a generic
> connectivity failure "friendly" page, which sends IT support people into a
> frenzy looking for broken network equipment.  The MitM response to this
> requires the proxy to masquerade as the origin server, which was exactly
> the issue the browser authors were trying to avoid by deciding to ignore
> non-200 responses in the first place, meanwhile causing proxy vendors
> and users significant pain.
>
> As for the issue with captive portals.  Since the client needs to resolve
> names using DNS prior to making a connection, and since the captive portal
> will intercept port 80 and redirect it to a challenge page etc until the
> portal has been satisfied, you have a bit of a chicken and egg problem.  A
> browser won't try to connect if it gets a DNS lookup failure.  DNS lookups
> will fail until the browser attempts a connection and authenticates with
> the captive portal.  This is where the layering violation of DNS over HTTP
> is problematic.
>
> One option then could be to return some fake A record to the DNS client, so
> that an attempt to connect will be made.
>
> packets.  By putting in the gateway, you may be providing a back door for
> attacks on the DNS server.  Sure, DNS servers should be hardened, but they
> may not realise they can't trust requests from the gateway.
>
>
> Adrien
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 May 2016 14:11:25 +1000

Adrien, subtle font changes do not make for good communications.

Try reading the text/plain and see you can work out what points you
are trying to make.

Mark

In message <emaff75e18-2469-4abc-b7be-7456e3986423@bodybag>, "Adrien de Croy" writes:
> 
> --===============5443949507881977805==
> Content-Type: multipart/alternative;
>  boundary="------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44"
> 
> 
> --------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44
> Content-Type: text/plain; format=flowed; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
> I don't know if dnsop is the place to rehash old arguments about TLS=20
> everywhere.
> 
> There are a few places in the archives of the http WG where it was=20
> discussed heatedly (for IETF) at length, especially around the de facto=20
> TLS was designed to provide data integrity and security, but not in the=20
> face of MitM attacks.  The only way to prevent these is with cert=20
> pinning (so the client can recognise a spoofed cert) or client certs=20
> Google's push for https everywhere has in our experience provided=20
> significant incentive for MitM deployment.  We only added MitM features=20
> to WinGate because google and facebook went https-only.  Prior to that=20
> it was hard to morally justify deploying a MitM to spy on people's=20
> banking traffic.
> 
> The other significant driver we see of MitM deployment was the=20
> deplorable decision by browser vendors that they would no longer trust=20
> non-200 responses to tunneling (CONNECT) requests.  This meant the only=20
> way to not have an awful (support incident generating) user experience=20
> when blocking connections to https sites at a proxy, was to MitM it,=20
> receive the request and send back a block response masquerading as the=20
> server.
> 
> The irony of this is completely wasted on the people who made these=20
> decisions.  The perceived threat was some page coming back from a=20
> CONNECT request which could get a broken browser to follow a redirect,=20
> or display the body as if it came from the https server (thereby=20
> allowing through broken browser design a masquerade opportunity). =20
> Instead of actually fixing the browsers, they all (FF, Chrome and IE and=
> =20
> probably others) chose instead to ignore the response, and show a=20
> generic connectivity failure "friendly" page, which sends IT support=20
> people into a frenzy looking for broken network equipment.  The MitM=20
> response to this requires the proxy to masquerade as the origin server,=20
> which was exactly the issue the browser authors were trying to avoid by=20
> deciding to ignore non-200 responses in the first place, meanwhile=20
> As for the issue with captive portals.  Since the client needs to=20
> resolve names using DNS prior to making a connection, and since the=20
> captive portal will intercept port 80 and redirect it to a challenge=20
> page etc until the portal has been satisfied, you have a bit of a=20
> chicken and egg problem.  A browser won't try to connect if it gets a=20
> DNS lookup failure.  DNS lookups will fail until the browser attempts a=20
> connection and authenticates with the captive portal.  This is where the=
> =20
> It should be possible to detect that this is happening though, since the=
> =20
> response won't contain an encapsulated DNS response in its message body.=
> =20
>   One option then could be to return some fake A record to the DNS=20
> My main concern was that the HTTP <-> DNS gateway was likely behind the=20
> firewall that was otherwise protecting the DNS server from malicious DNS=
> =20
> packets.  By putting in the gateway, you may be providing a back door=20
> for attacks on the DNS server.  Sure, DNS servers should be hardened,=20
> Subject: Re: [DNSOP] Fwd: New Version Notification for=20
> >>  I think some thought should be given to how a DNS stub might deal=20
> >>with a
> >>  I think also that any HTTP server that receives such a request=20
> >>probably
> >>  ought to be validating the encapsulated binary data before forwarding=
> =20
> >>it
> >>  to any DNS server.
> >
> >>  able to benefit from the fact that fundamentally it's made over TCP=20
> >>to
> >>  the HTTP agent.
> >
> --------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44
> Content-Type: text/html; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
> 
> <html><head><style id=3D"eMClientCss">blockquote.cite { margin-left: 5px;=
>  margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: =
> 1px solid #cccccc }=0Ablockquote.cite2 {margin-left: 5px; margin-right: =
> 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc;=
>  margin-top: 3px; padding-top: 0px; }=0A.plain pre, .plain tt { font-family=
> : monospace; font-size: 100%; font-weight: normal; font-style: normal;}=0A=
> a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;}=0A.plain=
>  pre, .plain tt {font-family: Tahoma;font-size: 12pt;}=0A</style><style></s=
> tyle>=0A<meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3D=
> utf-8">=0A</head>=0A<body scroll=3D"auto" class=3D""><div>&nbsp;</div><div>=
> &nbsp;</div><div><span id=3D"xc0cf9ede73494b998358d57572c98064"><tt><div>Ca=
> n you explain this further?</div><div>&nbsp;</div><div>TLS is designed to=
>  provide data integrity and privacy, even in the face</div><div>of man-in-t=
> he-middle attacks.</div></tt></span></div><div>&nbsp;</div><div>I don't =
> know if dnsop is the place to rehash old arguments about TLS everywhere.</d=
> iv><div>&nbsp;</div><div>There are a few places in the archives of the http=
>  WG&nbsp;where it was discussed heatedly (for IETF) at length, especially=
>  around the de facto implementation of mandatory TLS everywhere in the cont=
> ext of http/2.0.</div><div>&nbsp;</div><div>TLS was designed to provide =
> data integrity and security, but not in the face of MitM attacks.&nbsp; =
> The only way to prevent these is with cert pinning (so the client can recog=
> nise a spoofed cert)&nbsp;or client certs which the intermediary can't spoo=
> f in a way that the server will trust.</div><div>&nbsp;</div><div>Google's=
>  push for https everywhere has in our experience provided significant incen=
> tive for MitM deployment.&nbsp; We only added MitM features to WinGate beca=
> use google and facebook went https-only.&nbsp; Prior to that it was hard=
>  to morally justify deploying a MitM to spy on people's banking traffic.&nb=
> sp; </div><div>&nbsp;</div><div>The other significant driver we see of MitM=
>  deployment was the deplorable decision by browser vendors that they would=
>  no longer trust non-200 responses to tunneling (CONNECT) requests.&nbsp;=
>  This meant the only way to not have an awful (support incident generating)=
>  user experience when blocking connections to https sites at a&nbsp;proxy,=
>  was to MitM it, receive the request and send back a block response masquer=
> ading as the server.&nbsp; </div><div>&nbsp;</div><div>The irony of this=
>  is completely wasted on the people who made these decisions.&nbsp; The =
> perceived threat was some page coming back from a CONNECT request which =
> could get a broken browser to follow a redirect, or display the body as =
> if it came from the https server (thereby allowing through broken browser=
>  design a masquerade opportunity).&nbsp; Instead of actually&nbsp;fixing=
>  the browsers, they all (FF, Chrome and IE and probably others) chose inste=
> ad to ignore the response, and show a generic connectivity failure "friendl=
> y" page, which sends IT support people into a frenzy looking for broken =
> network equipment.&nbsp; The MitM response to this requires the proxy to=
>  masquerade as the origin server, which was exactly the issue the browser=
>  authors&nbsp;were trying to avoid by deciding to ignore non-200 responses=
>  in the first place, meanwhile causing proxy vendors and&nbsp;users signifi=
> cant pain.</div><div>&nbsp;</div><div>As for the issue with captive portals=
> .&nbsp; Since the client needs to resolve names using DNS prior to making=
>  a connection, and since the captive portal will intercept port 80 and redi=
> rect it to a challenge page etc until the portal has been satisfied, you=
>  have a bit of a chicken and egg problem.&nbsp; A browser won't try to conn=
> ect if it gets a DNS lookup failure.&nbsp; DNS lookups will fail until the=
>  browser attempts a connection and authenticates with the captive portal.&n=
> bsp; This is where the layering violation of DNS over HTTP is problematic.<=
> /div><div>&nbsp;</div><div>It should be possible to detect that this is =
> happening though, since the response won't contain an encapsulated DNS resp=
> onse in its message body.&nbsp; One option then could be to return some =
> fake A record to the DNS client, so that an attempt to connect will be made=
> .</div><div>&nbsp;</div><div><span id=3D"xcb9999ba2d4841499709412d57cc6986"=
> ><tt><div>I rather think this will increase the attack surface area rather=
>  than</div><div>decreasing it, because now you have an additional place =
> processing DNS</div><div>packets.</div><div>&nbsp;</div></tt></span></div><=
> div>My main concern was that the HTTP &lt;-&gt; DNS gateway was likely behi=
> nd the firewall that was otherwise protecting the DNS server from malicious=
>  DNS packets.&nbsp; By putting in the gateway, you may be providing a back=
>  door for attacks on the DNS server.&nbsp; Sure, DNS servers should be hard=
> ened, but they may not realise they can't trust requests from the gateway.<=
> /div><div>&nbsp;</div><div>&nbsp;</div><div>Adrien</div><div>&nbsp;</div><d=
> iv>&nbsp;</div><div>&nbsp;</div><div>&nbsp;</div>=0A<div>------ Original=
>  Message ------</div>=0A<div>From: "Shane Kerr" &lt;<a href=3D"mailto:shane=
> @time-travellers.org">[email-masked]</a>&gt;</div>=0A<div>To:=
>  "Adrien de Croy" &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=
> >&gt;</div>=0A<div>Cc: "[email-masked]" &lt;<a href=3D"mailto:[email-masked]=
> g">[email-masked]</a>&gt;</div>=0A<div>Sent: 5/05/2016 2:18:24 a.m.</div>=
> =0A<div>Subject: Re: [DNSOP] Fwd: New Version Notification for draft-song-d=
> ns-wireformat-http-03.txt</div><div>&nbsp;</div>=0A<div class=3D"plain" =
> id=3D"x9b5db85066b1495a90de3c5461bbe4a3"><blockquote class=3D"cite2" cite=
> =3D"[email-masked]" type=3D"cite">=
> =0A<tt><div>Adrien,</div>=0A<div>&nbsp;</div>=0A<div>Thanks for your commen=
> ts.</div>=0A<div>&nbsp;</div>=0A<div>At 2016-05-03 05:14:31 +0000</div>=0A=
> <div>"Adrien de Croy" &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
> m</a>&gt; wrote:</div>=0A<div>&nbsp;</div>=0A<blockquote class=3D"cite2"=
>  type=3D"cite">=0A<div>&nbsp;Some general comments:</div>=0A<div>&nbsp;</di=
> v>=0A<div>&nbsp;I don't think you can claim that https provides data integr=
> ity or</div>=0A<div>&nbsp;privacy any more, since MitM proxies are abundant=
> .</div>=0A</blockquote>=0A<div>&nbsp;</div>=0A<div>Can you explain this =
> further?</div>=0A<div>&nbsp;</div>=0A<div>TLS is designed to provide data=
>  integrity and privacy, even in the face</div>=0A<div>of man-in-the-middle=
>  attacks.</div>=0A<div>&nbsp;</div>=0A<blockquote class=3D"cite2" type=3D=
> "cite">=0A<div>&nbsp;I think some thought should be given to how a DNS stub=
>  might deal with a</div>=0A<div>&nbsp;captive portal or http proxy authenti=
> cation.</div>=0A</blockquote>=0A<div>&nbsp;</div>=0A<div>I guess this makes=
>  sense. I don't know that we can offer much help</div>=0A<div>though. Perha=
> ps something like this:</div>=0A<div>&nbsp;</div>=0A<div>&nbsp;&nbsp;&nbsp;=
> &nbsp;A captive portal or any other middlebox that interferes with HTTP</di=
> v>=0A<div>&nbsp;&nbsp;&nbsp;&nbsp;may break this protocol, and DNS over =
> HTTP will have to be disabled</div>=0A<div>&nbsp;&nbsp;&nbsp;&nbsp;until=
>  HTTP is restored.</div>=0A<div>&nbsp;</div>=0A<blockquote class=3D"cite2"=
>  type=3D"cite">=0A<div>&nbsp;I think also that any HTTP server that receive=
> s such a request probably</div>=0A<div>&nbsp;ought to be validating the =
> encapsulated binary data before forwarding it</div>=0A<div>&nbsp;to any =
> DNS server.</div>=0A</blockquote>=0A<div>&nbsp;</div>=0A<div>I rather think=
>  this will increase the attack surface area rather than</div>=0A<div>decrea=
> sing it, because now you have an additional place processing DNS</div>=0A=
> <div>packets.</div>=0A<div>&nbsp;</div>=0A<blockquote class=3D"cite" type=
> =3D"cite">=0A<div>&nbsp;I wonder why you'd want to keep truncation, as the=
>  request should be</div>=0A<div>&nbsp;able to benefit from the fact that=
>  fundamentally it's made over TCP to</div>=0A<div>&nbsp;the HTTP agent.</di=
> v>=0A</blockquote>=0A<div>&nbsp;</div>=0A<div>If the client side is acting=
>  as a DNS proxy then we need to look like</div>=0A<div>DNS. The stub resolv=
> ers will send UDP packets and expect normal</div>=0A<div>truncation behavio=
> r. While it may be possible for the client DNS proxy</div>=0A<div>to perfor=
> m truncation and send responses back to the stub resolvers,</div>=0A<div>th=
> is is a significantly more complicated design.</div>=0A<div>&nbsp;</div>=
> =0A<blockquote class=3D"cite2" type=3D"cite">=0A<div>&nbsp;I would also =
> suggest looking into how such requests might be best</div>=0A<div>&nbsp;blo=
> cked by an http proxy, because this will be a requirement of proxy</div>=
> =0A<div>&nbsp;operators, and it would be good to consider user experience=
>  for when</div>=0A<div>&nbsp;this happens, so that a consistent approach=
>  can be taken (rather than</div>=0A<div>&nbsp;every different proxy blockin=
> g it some other way so that the user</div>=0A<div>&nbsp;experience becomes=
>  awful).</div>=0A</blockquote>=0A<div>&nbsp;</div>=0A<div>In the case of=
>  unencrypted HTTP (not recommended), then the proxy can</div>=0A<div>look=
>  for the well-known URI, right?</div>=0A<div>&nbsp;</div>=0A<div>In the =
> case of TLS, then the proxy cannot block the traffic, can it? It</div>=0A=
> <div>doesn't know the URI that the site is visiting, nor the contents of=
>  the</div>=0A<div>query or answer....</div>=0A<div>&nbsp;</div>=0A<div>Chee=
> rs,</div>=0A<div>&nbsp;</div>=0A<div>--</div>=0A<div>Shane</div>=0A</tt>=
> =0A=0A</blockquote></div>=0A</body></html>
> --------=_MB6D95EBBB-CA31-4278-834E-7A1D33BBAD44--
> 
> 
> --===============5443949507881977805==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============5443949507881977805==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 05 May 2016 05:30:57 +0000

yeah, my email client wasn't quoting properly due to something about the 
original message I was replying to... so I had to cut n paste. sorry 
bout that!

------ Original Message ------
From: "Mark Andrews" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 5/05/2016 4:11:25 p.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

>>  &nbsp;</div><div><span 
>>id=3D"xc0cf9ede73494b998358d57572c98064"><tt><div>Ca=
>>  f in a way that the server will 
>>trust.</div><div>&nbsp;</div><div>Google's=
>>  .</div><div>&nbsp;</div><div><span 
>>id=3D"xcb9999ba2d4841499709412d57cc6986"=
>>  processing 
>>DNS</div><div>packets.</div><div>&nbsp;</div></tt></span></div><=
>>   "Adrien de Croy" &lt;<a 
>>href=3D"mailto:[email-masked]">[email-masked]</a=
>>  <div>"Adrien de Croy" &lt;<a 
>>href=3D"mailto:[email-masked]">[email-masked]=
>>  ps something like 
>>this:</div>=0A<div>&nbsp;</div>=0A<div>&nbsp;&nbsp;&nbsp;=
>>  HTTP will have to be 
>>disabled</div>=0A<div>&nbsp;&nbsp;&nbsp;&nbsp;until=
>>   the</div>=0A<div>query or 
>>answer....</div>=0A<div>&nbsp;</div>=0A<div>Chee=
>>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 May 2016 10:59:45 +0200

On Wed, May 04, 2016 at 10:13:09PM +0000,
 Adrien de Croy <[email-masked]> wrote 
 a message of 316 lines which said:

> TLS was designed to provide data integrity and security, but not in
> the face of MitM attacks.

You're playing with words here. It all depends if you use TLS in the
strict sense (just the protocol) or the wider one (with
authentication; note that authentication is a official part of the
spec, in section 7 of RFC 5246, it is not delegated to some other
RFC).

> significant incentive for MitM deployment.

It seems an argument straight from the attackers: "we are forced to
improve our attacks because the users - the bastards, how do they
dare? - improved their defenses".

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 May 2016 08:53:26 -0400

Indeed, that was precisely the intended result.   MitM attacks are possible
to detect; passive listening attacks are not.

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 06 May 2016 19:14:29 +0000

It's not like that at all.

The original text makes a claim about security and privacy around TLS.  
This is not true in the real world, and is becoming less true with every 
MitM deployed.

Client authentication is very rarely used because of the significant 
challenges of managing client certificates.  I don' t see that improving 
any time soon.  None of my banks even issued me with a client cert or 
want me to use one.

We saw the increase in pressure to provide a MitM option, and it 
coincided with google and facebook moving to https only.  Ignore that if 
you like, but that's the honest experience of a proxy vendor.  I would 
much rather not have had to do this, but in the end we had to.

So many people seem to think (Google included) that the browser user 
should have all the power, and not be able to be stopped or scanned.  In 
a corporate network, the company is ENTIRELY justified in securing and 
restricting the use of its network.  That's what a proxy is for.  That 
need isn't going to go away just because everyone moves to https.  That 
need just becomes harder to meet, and you won't find people are thankful 
for being forced to do that extra work to secure and control their 
networks.  Putting https where it's not needed (and it's not needed 
everywhere) just worsens the user experience, and provides false signals 
to users (since all attempts at making a system where the user could 
know they were being MitMed were rejected by the people who would 
evidently rather just ignore the problem and hope it goes away).  This 
is all customer needs driven. Until those needs change, then vendors 
will try to meet those needs.

So your final comment is completely out of place.

Adrien

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 6/05/2016 8:59:45 p.m.
Subject: Re: Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 06 May 2016 12:24:46 -0700

On 6 May 2016, at 12:14, Adrien de Croy wrote:

>  This is not true in the real world, and is becoming less true with 
> every MitM deployed.

It is as true now as it has ever been. Saying that TLS is not secure 
because there are environments where users can be tricked into lower 
security is silly in that that same statement is true of every security 
protocol.

If you want to propose a document to the IETF that says "TLS (and all 
other security protocols) should not be considered secure because users 
can be tricked", do so in SAAG.* It's not appropriate for a foo-over-TLS 
protocol document.

--Paul

* I doubt that such a document will be well received, but I have been 
wrong about these types of predictions often.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 May 2016 21:40:17 +0200

On Fri, May 06, 2016 at 07:14:29PM +0000,
 Adrien de Croy <[email-masked]> wrote 
 a message of 72 lines which said:

> Putting https where it's not needed (and it's not needed everywhere)

It is. If you don't know why, read RFC 7258 (6973 is useful, too).

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 06 May 2016 19:45:23 +0000

------ Original Message ------
From: "Paul Hoffman" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 7/05/2016 7:24:46 a.m.
Subject: Re: [DNSOP] New Version Notification for 

>It is as true now as it has ever been.
no, that's incorrect.  when there were no MitMs, (discounting crytpo 
algorithm downgrade attacks against SSLv2) you could consider https to 
be secure (integrity and privacy).

Now you can expect in a corporate network to be surfing through a 
https-inspecting proxy where neither integrity nor privacy is guaranteed 
in any strict sense, and that's the only way the proxy can cache and 
scan for malware.

So over time anyone's expectations of integrity and privacy if they know 
what's going on is actually reducing.  Setting an expectation about 
security and privacy in an RFC is therefore IMO not justified.  I'd just 
propose removing the statement since this is about DNS over HTTP.

If you want to hear this argument from many major proxy vendors go look 
in the httpwg archives.

>Saying that TLS is not secure because there are environments where 
>users can be tricked into lower security is silly in that that same 
>statement is true of every security protocol.
I'm not talking about downgrade attacks, I'm talking about proxies 
spoofing certs.

Browsers still happily show their little green lock icon.  Sure they 
have to accept the signing cert first, and that tends not to happen 
unless you're in a corporate network, or some countries I believe have 
now mandated acceptance of a cert or are looking at that.

If the user knows the proper cert chain, they can look up the chain for 
the site they are on and determine it ends in their company's spoof cert 
signing cert, and then know they were intercepted. Extremely few users 
know or bother to do this.

Proposals were made to allow browsers to know when they were being 
intercepted (special attributes in certs or otherwise "trusted 
proxies"), but these were rejected by the TLS people and browser people. 
  So we are left in the situation where users don't really know if they 
have security or not, and the green lock icon is untrustworthy.  So 
we're currently following the ignore the problem strategy.

Anyway, I encourage people to look through the httpwg archives.  There 
you'll see these arguments also put by the authors of Squid, Varnish, 
NGinx, Checkpoint, and myself among others.

Adrien

>can be tricked", do so in SAAG.* It's not appropriate for a 
>foo-over-TLS protocol document.
>
>--Paul
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 06 May 2016 19:46:10 +0000

I think you and many others will continue to disagree on that point.

try using https for OCSP or CRL checking and see how you go.

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 7/05/2016 7:40:17 a.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 06 May 2016 19:53:50 +0000

Maybe you can explain why, if https is needed everywhere, that after 
significant and extended arguing, the httpwg decided to make it optional 
in http/2

I really don't see the point in making all those arguments again over 
here in dnsop, when they were done to death many times in httpwg.  Go 
take a look there.

As for Stephen Farrell's view on it, yes we know his point of view on 
the topic. I and many others disagree with his view on this.

There's also RFC 2804 which is much more sensible and less likely to pit 
engineers against governments.

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>; "[email-masked]" 
<[email-masked]>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 7 May 2016 12:10:35 +0200

On Fri, May 06, 2016 at 07:45:23PM +0000,
 Adrien de Croy <[email-masked]> wrote 
 a message of 84 lines which said:

> when there were no MitMs, (discounting crytpo algorithm downgrade
> attacks against SSLv2) you could consider https to be secure
> (integrity and privacy).

Apparently, you have an analysis of TLS which is quite at odd with
everyone else in the security world. TLS *is* secure against MitM
(otherwise, there would be little reason to use it). I agree with Paul
Hoffman: your objection against the current text is groundless.

> https-inspecting proxy where neither integrity nor privacy is
> guaranteed in any strict sense,

Because the end host is controlled by the same organisation as the
interceptor. Saying that TLS is vulnerable to MitM because of this
case is like saying TLS is vulnerable because, for instance, a program
did not bother check the certificate
<https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.

> unless you're in a corporate network, or some countries I believe
> have now mandated acceptance of a cert or are looking at that.

If someone (your company or other) can add a cert to your cert store,
it can do what it wants. This has been known from the beginning of
public-key cryptography. In a typical corporate environment, the IT
department install all the software, anyway, and can even install a
browser which does not check certs, as well.

> So we are left in the situation where users don't really know if
> they have security or not, and the green lock icon is untrustworthy.

If you don't control your machine (if someone is administrator and you
are not), all bets are off. Again, this is well-known for a very long
time and you add no new information.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 7 May 2016 12:13:37 +0200

On Fri, May 06, 2016 at 07:53:50PM +0000,
 Adrien de Croy <[email-masked]> wrote 
 a message of 39 lines which said:

> There's also RFC 2804 which is much more sensible and less likely to
> pit engineers against governments.

Our priority is the users, not the governments, I think. RFC 3935,
section 2: "The IETF has found that the process works best when
focused around people, rather than around organizations, companies,
governments or interest groups."

And RFC 2804 was written a long time ago, when people were still able
to believe that there was little or no surveillance. We now know that
surveillance is *massive* and *persistent*.

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 07 May 2016 22:27:34 +0000

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "Paul Hoffman" 
<[email-masked]>
Sent: 7/05/2016 10:10:35 p.m.
Subject: Re: [DNSOP] New Version Notification for 
draft-song-dns-wireformat-http-03.txt

>Hoffman: your objection against the current text is groundless.

So I'm not sure what you're saying here - that there are no MitMs?  Or 
that they aren't a problem for integrity?

Or that theoretically if anyone actually implemented the full suite of 
options in TLS then it would not be able to be MitMed?

And it's not a problem of the protocol that nobody does the checks?

>interceptor

no, this virtually never happens.  We don't control google.com, but we 
intercept it.
>
>. Saying that TLS is vulnerable to MitM because of this

exactly. No mainstream browsers do.  Am I imagining this?

Just to be clear, client certificates will prevent this kind of thing, 
but they are also pretty much unworkable due to the prohibitive 
logistical deployment problems.. Which is why even banks don't use them 
for online banking.

To claim this as the thing which makes TLS secure against MitM is 
therefore disingenuous.  Or are you claiming something else?

>browser which does not check certs, as well.
sure.

>time and you add no new information.
If "adding new information" is a requirement, then definitely should 
strike the sentence from the RFC, because we don't need to be told again 
that TLS gives us integrity and privacy.  That's no new information 
either, regardless of whether it's true or not.

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 07 May 2016 22:44:44 +0000

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 7/05/2016 10:13:37 p.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

>Our priority is the users, not the governments, I think.

Making citizens criminals in their own country because they use software 
which implements protocols designed by us - how does that help them?

It's not clear cut.  We don't like surveillance so we make it extremely 
costly?  A regime can choose to simply block, so the consequences are to 
force political conflict, or cause users to lose service.  It's quite an 
arrogant position to take.  We are engineers, or are we political 
activists?

>RFC 3935,
That sounds like a generalization to me.

>surveillance is *massive* and *persistent*.
And many would argue "necessary".

I wouldn't personally argue that either way, but neither would I argue 
that there is not a single case ever where is it necessary and should be 
prohibited, because I know there are cases where it's necessary to not 
have TLS for http.

OCSP and CRL checking of certs, which if you did over https would create 
a circular validation paradox.

Then there's all the traffic which needs to be visible for whatever 
purpose, such as:

* phone home traffic from e.g. network infrastructure where it's 
necessary for it to be demonstrably benign.
* things like prisoner's web traffic, and other situations where there's 
a legal requirement to monitor.

Then you have all the products based on devices which have http stacks 
in them but not https (I use some of these, like SIM800 based systems). 
Millions upon millions of devices like these should not exist either?

I am a proponent of choice.  Making http use TLS everywhere is just 
removing choice.  We don't have the moral or any other authority to do 
that.

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 07 May 2016 22:49:30 +0000

and that even ignores the cost of obtaining and renewing certificates 
for your home router so you can web admin it.

https makes no sense in many cases where http is currently used for 
commercial and logistical reasons.

I guess nobody is going to bother looking at the httpwg arguments made, 
I really don't feel like making them again here.  I'm sure members of 
this list are already sick of me posting about this.

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Stephane Bortzmeyer" <[email-masked]>
Cc: "Shane Kerr" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 8/05/2016 10:44:44 a.m.
Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-song-dns-wireformat-http-03.txt

>Making citizens criminals in their own country because they use 
>software which implements protocols designed by us - how does that help 
>them?
>
>costly?  A regime can choose to simply block, so the consequences are 
>to force political conflict, or cause users to lose service.  It's 
>quite an arrogant position to take.  We are engineers, or are we 
>political activists?
>
>
>>RFC 3935,
>that there is not a single case ever where is it necessary and should 
>be prohibited, because I know there are cases where it's necessary to 
>not have TLS for http.
>
>OCSP and CRL checking of certs, which if you did over https would 
>create a circular validation paradox.
>
>* things like prisoner's web traffic, and other situations where 
>there's a legal requirement to monitor.
>

---

From: joel jaeggli <[email-masked]>
Date: Sun, 8 May 2016 08:53:51 -0700

> engineers against governments.

rfc 2804 says nothing about extending the security envelope of
protocols. it does state that we do not consider requirements for
wiretapping as part of protocol development.