Subject: [DNSOP] Possible issues with DNS over HTTP wire format draft

From: Shane Kerr <[email-masked]>
Date: Mon, 8 Aug 2016 15:41:52 +0200

Hello,

There are a few suggestions about the DNS over HTTP draft made off-list,
which I will try to characterize here:

* We should expand the motivations to explain why DNS over HTTP makes
  sense at all. 

* We should restrict the protocol to TLS.

I am happy to expand the motivation section, although I am beginning to
wonder if it will ever be enough. :)

As for a requirement for TLS... the document currently says that
implementers SHOULD use TLS. My own feeling is that this should be
enough; apparently the recommendation to require TLS was made in the
HTTP/2 working group and rejected, so I am not sure that we need to
re-visit the entire discussion around the DNS over HTTP protocol.

https://http2.github.io/faq/#does-http2-require-encryption

Note that I do not have a strong preference here. This is a working
group document, so if there is consensus for requiring TLS then that's
how it is.

A final oversight that occurred to me is that there should be a privacy
section. This is because since the DNS over HTTP serves as a DNS
resolver that all of the privacy considerations of a normal DNS
resolver apply, and should be mentioned (probably referencing RFC 7626).

Cheers,

--
Shane

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 09:04:41 +1000

Thanks for starting the discussion Shane.

On 8 August 2016 at 23:41, Shane Kerr <[email-masked]> wrote:
> My own feeling is that this should be

That's the result of a fairly old discussion.  You will note that all
protocols that use HTTP developed since (a long time ago) all require
HTTPS.  The reasons that HTTP decided cleartext wasn't prohibited
don't apply to a new protocol.

Also note that HTTP/2 on the web is - at least to my knowledge -
exclusively HTTPS at the moment.  The RFC might not mandate
encryption, but no one has deployed the unencrypted variant at any
real scale.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 9 Aug 2016 16:54:16 +0100

> On 8 Aug 2016, at 14:41, Shane Kerr <[email-masked]> wrote:
> 
> Hello,
> 

I agree with this because one thing that hasn’t ever been clear to me with this mechanism is what the privacy expectations of the user should be. As I read the current draft a client should treat this from a privacy perspective with the same expectation as sending queries over UDP and TCP? I don’t think there is any intention to couple this to the Usage Profiles of Strict vs Opportunistic Privacy as described for DNS-over-(D)TLS, and no intention to re-use the authentication mechanisms described in draft-ietf-dprive-dtls-and-tls-profiles in Scenario 1? And the fact that TLS may be used is a separate consideration to any desire to explicitly provide privacy for the DNS client?

In some ways this feels like a missed opportunity for Scenario 1 but I appreciate wanting to limit the scope of this.

My main comment is that if my understanding is correct then I think the the distinction between encryption/authentication in the HTTP layer for the purposes of 'tunnelling’  and encrypting communication to provide privacy for the DNS client should be more clearly spelled out in the proposed Privacy section.

Sara.

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 9 Aug 2016 10:48:19 -0700

Hi,

> wonder if it will ever be enough. :)

There is enough motivation why someone would want DNS/HTTP, but not why does
it warrant a standard. The Section 1 in -00 said: "It simply serves as
a sort of DNS VPN" which is
quite accurate. We don't have a standard for DNS over IPSec or OpenVPN because
the carrier is not DNS agnostic (or doesn't have to be), like in this case.
While this draft solves a legitimate problem, it's still a blessed workaround.

> resolver apply, and should be mentioned (probably referencing RFC 7626).

Best,
Marek

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>