Subject: [Gen-art] Genart last call review of draft-ietf-doh-dns-over-https-12

From: Stewart Bryant <[email-masked]>
Date: Sat, 04 Aug 2018 01:53:17 -0700

Reviewer: Stewart Bryant
Review result: On the Right Track

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-doh-dns-over-https-12
Reviewer: Stewart Bryant
Review Date: 2018-08-04
IETF LC End Date: 2018-08-08
IESG Telechat date: Not scheduled for a telechat

Summary:

ID-Nits picks up a downref, but the appropriate warning was included in the IETF LC email.

Major issues:

4.  Selection of DoH Server

SB> I am surprised that there is no discussion of the need to specify
SB> the raw IP address of the sever as part of the URI, and that there
SB> is no discussion of the server address IP address family in the document.
SB> I would have thought that there should at least be a reference to
SB> "happy eyeballs" and and discussion of an  optimization strategy of 
SB>  what to do if there was a response on Ipv4 and not IPv6 etc etc.

==========

  The same DNS query for www.example.com, using the POST method would
   be:

   :method = POST
   :scheme = https
   :authority = dnsserver.example.net
   :path = /dns-query
   accept = application/dns-message
   content-type = application/dns-message
   content-length = 33

   <33 bytes represented by the following hex encoding>
   00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
   07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
   01

SB> At this point in the text  am at a loss to understand the 33 bytes. 
SB> Having read to the end of the text, I assume that this is a binary encoded
SB> DNS query in "one the wire format" but this point needs to be made clear,
SB> as does the explicit encoding. It would be really useful if there was an
SB> example of both formats side by side.

=========
   The DNS query is 94 bytes represented by the following hex encoding
SB> Again in what format?

=========
   :method = GET
   :scheme = https
   :authority = dnsserver.example.net
   :path = /dns-query? (no space or CR)
           dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR)
           bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR)
           dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ
   accept = application/dns-message

SB> I am not a DNS or HTTP specialist, so please help me understand
SB> what the string starting "dns=" is.

==========

5.2.2.  HTTP Response Example

SB> Nits says:

  -- The document has examples using IPv4 documentation addresses according
     to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
     there should be IPv6 examples, too?

SB> I am not sure if there are any IPv4 vs IPv6 issues but it would be helpful to
SB> clarify the point.

=========

   <64 bytes represented by the following hex encoding>
   00 00 81 80 00 01 00 01  00 00 00 00 03 77 77 77
   07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
   01 03 77 77 77 07 65 78  61 6d 70 6c 65 03 63 6f
   6d 00 00 01 00 01 00 00  00 80 00 04 C0 00 02 01

SB> At this point in the text I am still wondering what this encoding means, I assume that
SB> it is a hex representation of the payload received
SB> back from a normal DNS query.

=========

7.  Definition of the application/dns-message media type

   The data payload for the application/dns-message media type is a
   single message of the DNS on-the-wire format defined in Section 4.2.1
   of [RFC1035]. 

SB> That would have been useful to have known earlier
SB> However 4.2.1 just talks about UDP and not the message syntax.
SB> Also presumably we are talking about the payload of the UDP
SB> message excluding the UDP header.

SB> "on-the-wire" is a potentially confusing term, since it gets us
SB> into network byte order etc.
SB> I think the whole thing  would be clearer is you said that your
SB> message was identical to the payload of the UDP payload of an
SB> RFC1035 as seen by a server (and then add some specification 
SB> about the payload to hex method you are using)
SB> It would also be helpful to the reader to note whether
SB> any of the 25 updates to RFC1035 impact any of the specification
SB> described in this memo.

=======

   The format was originally for DNS over UDP.  Although
   [RFC1035] says "Messages carried by UDP are restricted to 512 bytes",
   that was later updated by [RFC6891].  This media type restricts the
   maximum size of the DNS message to 65535 bytes.  Note that the wire
   format used in this media type is different than the wire format used
   in [RFC7858] (which uses the format defined in Section 4.2.2 of
   [RFC1035]).

SB> 4.2.2 does not seem to describe a format, unless you are implicitly
SB> saying that 4.2.1 does not have a length 4.2.2 does and you
SB> are encoding the length another way and hence use 4.2.1 format.
SB> Either way neither of these sections of RFC1035 really specify the
SB> format, that is provided earlier in the RFC.

===========

   Encoding considerations: This is a binary format. The contents are a
   DNS message as defined in RFC 1035. The format used here is for DNS
   over UDP, which is the format defined in the diagrams in RFC 1035.

SB> With or without the UDP header?

==========

Minor issues:

Abstract

   This document describes how to make DNS queries over HTTPS.

SB> This is the shortest abstract I have seen in a long while, if
SB> not forever. It would be helpful to the undecided reader if
SB> a little more context from the Introduction was included in the
SB> abstract.

=========

Nits/editorial comments: 

These caches may exist beteen the
SB> s/beteen/between/

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Aug 2018 15:08:46 +0000

> SB> is no discussion of the server address IP address family in the document.

A URI can have either host names or IP addresses in the authority part.

> SB>  what to do if there was a response on Ipv4 and not IPv6 etc etc.

Happy eyeballs is orthogonal to the document. How the client turns a host name in the URI into an IP address is completely up to the client using whatever strategies it wants to use.

> SB> as does the explicit encoding.

Will do.

> SB> It would be really useful if there was an

Could you explain more what you want here? The two formats will look the same: a bunch of hex.

> SB> Again in what format?

Wire format. We'll add a note of that.

> SB> what the string starting "dns=" is.

The path is the last part of the HTTP query.

We are changing the example to be for IPv6 (based on the AD review).

>   <64 bytes represented by the following hex encoding>

Correct.

> SB> message excluding the UDP header.

We will make the contents of the payloads clearer earlier in the document. The reason the reference is to Section 4.2.1 of RFC 1035 is that the DNS wire format changes if it is over TCP.

> SB> RFC1035 as seen by a server

Agree.

> SB> (and then add some specification 

Not sure what you mean here.

> SB> described in this memo.

None of them do.

> SB> saying that 4.2.1 does not have a length 4.2.2 does

That is exactly what we are saying because that is what RFC 1035 says.

> SB> and you

The DNS wire format for UDP does not encode the length, and so DoH does not either.

> SB> format, that is provided earlier in the RFC.

We will clear this up.

Without. RFC 1035 says nothing about the UDP header as part of the wire format.

Fixed (based on the AD review). It now says:

This document defines a protocol for sending DNS queries and
getting DNS responses over HTTPS. Each DNS query-response pair is
mapped into an HTTP exchange.

> These caches may exist beteen the

Good catch; will fix.

Thanks for the review!

--Paul Hoffman

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 4 Aug 2018 18:10:54 +0100

Sent from my iPad

> On 4 Aug 2018, at 16:08, Paul Hoffman <[email-masked]> wrote:
> 

I do not understand. How does a system that is using this as its DNS access mechanism find the IP address of the DNS service given only the name of the server?

> Happy eyeballs is orthogonal to the document. How the client turns a host name in the URI into an IP address is completely up to the client using whatever strategies it wants to use.

My assumption is that someone used to DNS would understand all the issues. But you have written this document so that web applications specialists can do a DNS lookup from within their web application. It would seem reasonable to give them some hints about the issues, even if only by reference.

> Could you explain more what you want here? The two formats will look the same: a bunch of hex.
How about showing the mapping of this to a 1035 message using the parameters the coder would use. So for example some of that ascii is presumably the Name of the address being looked up.

>> SB> back from a normal DNS query.

It would be helpful to the new reader to explain that.
> We will make the contents of the payloads clearer earlier in the document. The reason the reference is to Section 4.2.1 of RFC 1035 is that the DNS wire format changes if it is over TCP.

Yes, but rather than have the reader work out the minor difference in please tell them.

> That is exactly what we are saying because that is what RFC 1035 says.

One sentence will stop the reader having to work this out.
> Without. RFC 1035 says nothing about the UDP header as part of the wire format.

It might be better to talk about UDP payload do it is completely clear. 
> mapped into an HTTP exchange.

Better. Thanks.

>> These caches may exist beteen the

Thanks

- Stewart

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 4 Aug 2018 17:34:56 +0000

> I do not understand. How does a system that is using this as its DNS access mechanism find the IP address of the DNS service given only the name of the server?

If a client is using DoH as its only access to the DNS, then the URI clearly needs an IP address in it. However, most of the current expected applications of DoH are for getting better DNS service, not being the exclusive or first DNS service. For example, browsers are expected to use DoH in addition to the OS's stub resolver in order to get the benefits described in the draft's Introduction.

> My assumption is that someone used to DNS would understand all the issues. But you have written this document so that web applications specialists can do a DNS lookup from within their web applicat…

Those hints would be for the developer of the browser or other HTTP client stack, not to DoH. DoH requires (and should not require!) any changes to those.

> How about showing the mapping of this to a 1035 message using the parameters the coder would use. So for example some of that ascii is presumably the Name of the address being looked up.

I apologize for being dense, but I still don't see what you are asking for here. The DoH client marshals a DNS query just like a DNS client does by putting together all the bits from RFC 1035. The DNS name being looked up is not in ASCII: RFC 1035 says how you put together the labels of a name in a binary format.

> It would be helpful to the new reader to explain that.

Got it; will do.

> Yes, but rather than have the reader work out the minor difference in please tell them.

We did that in an earlier draft and was told by the WG to take it out because it was confusing. 

> One sentence will stop the reader having to work this out.

The fact that RFC 1035 is subtle on this point is not helpful to us. RFC 1035 talks about the format throughout as if it will always be used in UDP; it's only in Section 4.2.2 that it adds (without even a diagram) the two length bytes for TCP transport. We're kind of stuck with the history of the DNS RFCs here.

--Paul Hoffman

---

From: Star Brilliant <[email-masked]>
Date: Sat, 4 Aug 2018 20:10:35 +0000

Hi Stewart Bryant,

Just to declare that I am not the core author of the draft, but I want to give my personal opinions on your questions.

> I do not understand. How does a system that is using this as its DNS access mechanism find the IP address of the DNS service given only the name of the server?

Yes, bootstrap is truly a problem. Currently we have (at least) 3 different ways to solve this problem:

1) Use a traditional DNS server for bootstrapping the IP address of DoH server.
Firefox's TRR uses this method. In a common situation that DoH is run inside a browser, this is the mostly adopted solution.

2) Anchor the IP address but still uses the host name to refer the DoH server. A simple /etc/hosts will do.
This is friendly to SNI and many other stuff, but with the drawback of difficulty to do load-balancing except by using TCP Anycast, which is much trickier than UDP Anycast.

3) Issue a TLS certificate directly with the IP address, and use the IP address directly to refer the DoH server.
Cloudflare uses this method. But most CA does not issue certificates for IP address. And again TCP Anycast is difficult for most DNS providers. Also we lose the ability to dynamically update the address.

There must be some more and better methods to solve the bootstrap problem. Do we really need to force the client to use one of these methods?

> How about showing the mapping of this to a 1035 message using the parameters the coder would use. So for example some of that ascii is presumably the Name of the address being looked up.

Nope, DNS wire format is a compressed binary format. It splits the domain name into labels, and use a dictionary-based method to compress the message.
I don't think we need to explain how the message is encoded -- that was already described in RFC1035.
Neither does the reader need to understand each byte of the message -- it is just an ordinary DNS message that you can produce with any DNS utility library.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Aug 2018 12:06:27 -0400

Stewart, thanks for your reviews. Paul, thanks for your responses. I have entered a Yes ballot.

Alissa

> On Aug 4, 2018, at 4:53 AM, Stewart Bryant <[email-masked]> wrote:
> 
> Reviewer: Stewart Bryant
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art