Subject: [dispatch] Working Group Proposal: DNS Over HTTPS

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Aug 2017 14:38:55 +0000

Greetings. Alexey asked Patrick and I to send this to DISPATCH to get discussion going.

--Paul Hoffman and Patrick McManus

Working Group: DNS Over HTTPS (DOH)

DNS queries sometimes experience problems with end-to-end connectivity at times and places where HTTPS flows freely. The use of HTTPS provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTP infrastructure and policy.

The WG will standardize how HTTP clients can encode DNS queries and interpret DNS responses.

The WG will use best-practice HTTP semantics.

Specification of how the DNS data may used for new use cases, and the discovery of the DOH servers, are out of scope for the WG.

The WG will begin its work based on draft-hoffman-dispatch-dns-over-https.

The WG will deliver a document describing how to obtain and interpret DNS information using the HTTP protocol, with an IETF Last Call expected in December 2017.

---

From: "John Levine" <[email-masked]>
Date: 10 Aug 2017 16:00:35 -0000

In article <[email-masked]> you write:
>DNS queries sometimes experience problems with end-to-end connectivity at times and places where HTTPS flows freely. The use of HTTPS
>provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTP infrastructure and policy.
>

In the discussions to date, the proposal has been to send wire format
queries encapsuated as an appropriate MIME type and get wire format
responses back, to be parsed by the https client.  The design is very
simple.

The main use case I see is that javascript running in browsers can
currently only do implicit A and AAAA queries by looking up URLs.  If
you want to do a SRV or NAPTR or URI lookup, you can't.  So with this
hack, the js application can now do those lookups.

There's also more exotic scenarios where you're trapped behind a
hostile firewall or maybe a captive portal or you want to do queries
that are harder to snoop, but I think that SRV/NAPTR/URI in js is
enough of a use case.

Someone asked what if the https server lies?  DNS caches have always
lied, that's nothing new.  If you don't trust it, you have DNSSEC.

Another suggestion was to turn the queries and responses into easier
to handle json, but that increases the complexity by orders of
magnitude, and would requires an update for every new rrtype or edns
flag.  (If someone wants to build a json proxy on top of this as an
experiment, sure, go ahead.)

As you might gather, I think this is a good idea, and should be
straightforward for us to handle.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2017 17:22:44 +0100

I'm not against this, pretty much for it in fact, but...

> lied, that's nothing new.  If you don't trust it, you have DNSSEC.

Changing the liar can be significant. If this is used with
some dedicated https server that only does dns and nothing
else, and the URL for that is configured into a dns/https
client, that's probably no big change vs. speaking the dns
protocol with a resolver.

If however, a random web site were to be able to get a http
client like a browser to believe lies about dns then that'd
be much worse than today, if those lies affect more than the
web pages that the fibbing web site can control anyway.

That's ack'd in the last para of the security considerations
but I suspect more will be needed there, first to analyse
possible bad behaviours and then to figure out what to say
about those. (I'd be surprised if that were doable by the
end of the year, but since ietf milestone date fiction
deserves it's own aisle in a bookstore, that's ok:-)

As an aside, I'm puzzled a bit by how CORS comes into this.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Aug 2017 09:27:56 -0700

> On 10 Aug 2017, at 9:00 am, John Levine <[email-masked]> wrote:
> 

Well said; +1 from me.

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 10 Aug 2017 12:58:10 -0500

> As an aside, I'm puzzled a bit by how CORS comes into this.

I would presume that a website offering this endpoint would need to make 
a policy decision regarding which script origins it wants to let use it 
(at least, in the context of a web browser that honors CORS). I *expect* 
that, operationally, most servers offering this service will set up CORS 
to allow anyone to ask (as, if this were simply a matter of providing 
information to their own scripts, it could be done in a much simpler and 
way without the need for standardization).

I believe this deserves a brief treatment in the Security Considerations 
section, but doesn't have an impact on the charter.

/a

---

From: "John R Levine" <[email-masked]>
Date: 10 Aug 2017 14:29:59 -0400

> web pages that the fibbing web site can control anyway.

I don't see what the problem is.  This is just a way to encapsulate DNS 
queries in http, typically from a javascript routine running in a browser. 
Unless browsers work very differently from the way I think they do, this 
is not a way to patch a browser's DNS lookup code.

> As an aside, I'm puzzled a bit by how CORS comes into this.

CORS?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Aug 2017 20:40:45 +0100

On 10/08/17 19:29, John R Levine wrote:
> queries in http, typically from a javascript routine running in a
> browser. Unless browsers work very differently from the way I think they
> do, this is not a way to patch a browser's DNS lookup code.

I don't know what you mean by that last tbh.

The problem I'm trying to describe is touched on in the
last para of the draft's security considerations.

>> As an aside, I'm puzzled a bit by how CORS comes into this.

Yes. The mention of that in the draft we're discussing is
a bit of a puzzle to me. Hopefully you didn't read some
other draft:-)

S.

---

From: "John R Levine" <[email-masked]>
Date: 10 Aug 2017 15:48:50 -0400

> I don't know what you mean by that last tbh.

Browsers do their own DNS lookups in the usual way.  This proposal does 
not change that in the least.

> last para of the draft's security considerations.

Oh, that.  The client is the javascript application, not the browser 
inside which it's running.

Re CORS, a normal javascript app can only call back to servers in the same 
domain, so any evil due to DNS over http will be coming from the equally 
evil server that provided the javascript code in the first place.  I 
suppose CORS lets it talk to other differently evil places, but this 
doesn't impress me as an interestingly new problem.

Regards,

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 10 Aug 2017 15:53:09 -0400

> last para of the draft's security considerations.

I agree that paragraph is a bit out of place in this draft, but I think the
text is just trying to agree with you.  It's implicitly describing a
hypothetical scenario (browsers flinging DNS queries to any web server they
bump into) in order to say DON'T DO THAT.

I think we can clarify the wording there, and also possibly write a charter
that explicitly excludes any change to how DNS clients choose recursive
resolvers.

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

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 11 Aug 2017 15:12:13 +0900

Just some minor wording tweak; otherwise, I think this proposal is fine.

> Specification of how the DNS data may used for new use cases, and the discovery of the DOH servers, are out of scope for the WG.

"may used" -> "may be used"