Note: This ballot was opened for revision 13 and is now closed.
I'm balloting "yes", but have some minor comments: §4: I'd like to see a bit more clarity on what it means for the URL to be selected based on "configuration". Does this mean "local" configuration? In particular, the client does _not_ select a DoH server based on something in the HTML or JS served by a web server? §5.1: Would it make sense to offer some more explicit guidance on when to choose GET vs POST? I see comments that GET is more cache friendly but that POST might be more efficient. Is there any reasonable guidance on how to apply when making implementation decisions? §6.2, first sentence: That's a slightly odd use of the RECOMMENDED keyword. Does it mean the same thing as "SHOULD NOT" use earlier versions?
Thanks for your work on this protocol and for the comprehensive privacy considerations. COMMENTS S 5.1. > The DoH client SHOULD include an HTTP "Accept" request header field > to indicate what type of content can be understood in response. > Irrespective of the value of the Accept request header field, the > client MUST be prepared to process "application/dns-message" (as > described in Section 7) responses but MAY also process any other type > it receives. I read this before seeing the other email discussion about it and thought it meant that the client might be processing other types for non-DNS HTTP requests, which obviously was the wrong interpretation. I think this text requires some clarification.
I'll try to trim comments that were already mentioned, but will make an exception for my surprise to see the (non-)requirements sections slated for removal. Would it be better to move them to an Appendix with disclaimer that "the following goals were used by the WG during the design process but do not represent an exhaustive list"? It's a little unclear how much of the requirements on future work (e.g., media type/formats) needs to be done now vs. can be done when such work appears. [section-by-section comments follow] Section 5.1 Future specifications for new media types MUST define the variables used for URI Template processing with this protocol. This is scoped to just future DNS-over-HTTP media types, right? In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message. The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. It's probably clear enough as implicit (especially given two paragraphs prior), but do you want to mention that this HTTP-layer caching? DoH clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them. Probably need the 7540 cite here as well. Section 5.1.1 In this example, the 33 bytes are the DNS message in DNS wire format. Cite for "DNS wire format" (1035)? Also, adding something like "starting with the DNS header" might forestall questions about "is the UDP header or DNS/TCP length prefix included?". Section 5.2.1 [...] This might mean that the DoH client retries the query with the same DoH server, such as authorization failures (HTTP status code 401 [RFC7235] Section 3.1). Is there a word or three missing here? Section 6.1 [...] (POST requests are not cacheable unless specific response header fields are sent; this is not widely implemented, and not advised for DoH). I do not claim to be an HTTP expert, but are "request" and "response" swapped in the above? [...] This requirement helps assure that none of the RRsets contained in a DNS response are served stale from an HTTP cache. Is this better as "unintentionally served stale"? The stale-while-revalidate and stale-if-error Cache-Control directives ([RFC5861]) could be well-suited to a DoH implementation when allowed by server policy. Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer fresh. In such a case, the client reuses all of a cached entry, or none of it. Given that we're talking about the interaction between HTTP caching and DNS caching, it seems reasonable to specify which layer of cache's cached entry we're talking about. (Probably other instances later in the section, too.) Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation. Just to check my recollection: the current DoH document is incompatible with zone transfers (by virtue of being single request/response)? Section 8.1 It's unclear that the security considerations for application/dns-message exactly match those of "pure" DNS. For example, DNS messages expect to interact with DNS-layer caching, and messages wrapped in an application/dns media type may also have to interact with additional cache layers (e.g., all of Section 6.1 of this document's considerations), and mis-caching can have security consequences. Section 9.2 DNS implementations that use one TCP connection for multiple DNS requests directly group those requests. Long-lived connections have better performance behaviors than short-lived connections, but group more requests. [...] I think the consequence of "group more requests" should probably be spelled out, e.g., "which exposes more information to correlation and consolidation". Section 11 The HTTPS channel used by this specification establishes secure two- party communication between the DoH client and the DoH server. What does "secure" mean? [...] For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using [RFC6066] Section 8 for TLS version 1.2. [...] TLS 1.3 is final (RFC 8446) if you feel like using the most-current reference.
Thank you -- I've been following this work, and so only have a few minor comments at this point... Section 3. Protocol Requirements I really think that this section should remain - it is helpful to people new to the technology to understand how and why design decisions were made. If you are not comfortable with it in the body of the document, perhaps it could be made an Appendix. Section 5.1. The HTTP Request " In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request." While this should be obvious, as this document is talking about both DNS and HTTP it would be helpful to clarify **which** cache. Section 6.1. Cache Interaction "This requirement helps assure that none of the RRsets contained in a DNS response are served stale from an HTTP cache." The wording of this feels a little "clunky", but I don't really have a suggested fix. I also think that it would be helpful if the "served stale" term could be changed, but this might just be because I think of draft-ietf-dnsop-serve-stale when I see that. General: You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure.
One question: In case DoH doesn't work for some reason, is this supposed to fallback to DNS over TLS? I guess if the selected host name would allow detection of DNS and SNI is used, it wouldn't be too hard to block DoH requests....? Is that a concern? Also one smallish comment: As already brought up in the TSV-ART review (Thanks Ferando!) I would recommend to further clarify this sentence in section 5.1: "Using the GET method is friendlier to many HTTP cache implementations." What does "friendlier" mean...? Or at least maybe provide a forward reference to sec 6.1.
This is an important piece of work, so thank you for doing this work. The document is well written. I am looking forward to seeing answers to Ben's questions/comments (I agree with them). I also have some comments of my own: 1) I think you should keep Section 3. Maybe make it an Appendix. It would be important to have it if the document gets extended in incompatible ways and some of the requirement/assumptions states in your document are violated. 2) Related to section 3: is there any desire in the WG to work on an extension which would allow for cases when a single request might result in multiple responses? 3) In 3.1: o Supporting other network-specific inferences from plaintext DNS queries Can you please decode this for me, as I don't understand what this is trying to say. Maybe provide an example? 4) In 5.1, next to the last para: In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message. The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. Not being that familiar with DNS (and not having read the whole document at this point) I didn't know whether this was talking about some kind of DNS specific thing or whether it was talking about something specific to DoH. At some point I was wondering if DNS ID was supposed to be included in some kind of URL. So maybe you should add a reference where you mention "DNS ID" for the first time. 5) In Section 8.1: Security considerations: The security considerations for carrying this data are the same for carrying DNS without encryption. I think you should do much better then this. This field is supposed to give a quick hint whether there is any active content(*) (e.g. executable code) in the described media type, so that people implementing firewalls and antispam can decide whether anything special needs to be done to process the media type. But what you did is effectively sent me to read all DNS related RFCs on the topic. So please also state whether active content is allowed here. (*) - among other things 6) In Section 11, 3rd para: Some HTTPS client implementations perform real time third-party checks of the revocation status of the certificates being used by TLS. If this check is done as part of the DoH server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur. The use of OCSP [RFC6960] servers or AIA for CRL fetching ([RFC5280] Section 188.8.131.52) are examples of how this deadlock can happen. To mitigate the possibility of deadlock, DoH servers SHOULD NOT rely on DNS-based I might be confused here, but I thought the most typical is for a DoH *client* to validate DoH *server's* certificate for being revoked. So did you mean "DoH client" instead of "DoH server" above? If not, then I think you lost me and this text needs to be rewritten to be more specific about what the problem is. references to external resources in the TLS handshake. For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using [RFC6066] Section 8 for TLS version 1.2. AIA deadlocks can be avoided by providing intermediate certificates that might otherwise be obtained through additional requests. Note that these deadlocks also need to be considered for server that a DoH server might redirect to.
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4890 COMMENTS S 1. > > 1. Introduction > > This document defines a specific protocol for sending DNS [RFC1035] > queries and getting DNS responses over HTTP [RFC7540] using https > URIs (and therefore TLS [RFC5246] security for integrity and You will need a cite for HTTPS. S 1. > > Two primary uses cases were considered during this protocol's > development. They included preventing on-path devices from > interfering with DNS operations and allowing web applications to > access DNS information via existing browser APIs in a safe way > consistent with Cross Origin Resource Sharing (CORS) [CORS]. No "considered"..."include" is odd. I would probably just make this a bulleted list, but alternately, "They were". S 4. > > o Supporting insecure HTTP > > 4. Selection of DoH Server > > Configuration, discovery, and updating of the URI Template [RFC6570] At this point in the document, it is not clear why I would need a URI template, because you don't explain that till S 5. Perhaps in some overview above. S 4. > offers an unsolicited response that appears to be a valid answer to a > DNS query. This specification does not extend DNS resolution > privileges to URIs that are not recognized by the DoH client as > configured URIs. Such scenarios may create additional operational, > tracking, and security hazards that require limitations for safe > usage. A future specification may support this use case. I am having some trouble understanding what you are prohibiting here. Also, "configured" is an odd term if you are talking about web apps S 5.1. > DoH servers MUST implement both the POST and GET methods. > > When using the POST method the DNS query is included as the message > body of the HTTP request and the Content-Type request header field > indicates the media type of the message. POST-ed requests are > smaller than their GET equivalents. Because? I assume b/c no encoding. With that said, it is not obvious that this is true because (as shown below) you have to put content- length and content-type in the POST version, so if you had a smallish request, you might gt more expansion that way, S 5.1. > The DoH client SHOULD include an HTTP "Accept" request header field > to indicate what type of content can be understood in response. > Irrespective of the value of the Accept request header field, the > client MUST be prepared to process "application/dns-message" (as > described in Section 7) responses but MAY also process any other type > it receives. Why is this good? What would I do with like image/jpeg. I tend to think of draft-thomson-postel-was-wrong here. S 5.2. > from a DNS response. For example, one response type might include > information from the DNS header bytes while another might omit it. > The amount and type of information that a media type gives is solely > up to the format, and not defined in this protocol. > > Each DNS request-response pair is matched to one HTTP exchange. The I think you mean "mapped" S 5.2.1. > DNS response codes indicate either success or failure for the DNS > query. A successful HTTP response with a 2xx status code ([RFC7231] > Section 6.3) can be used for any valid DNS response, regardless of > the DNS response code. For example, a successful 2xx HTTP status > code is used even with a DNS message whose DNS response code > indicates failure, such as SERVFAIL or NXDOMAIN. You say "can" but the text below implies MUST. S 6.1. > The stale-while-revalidate and stale-if-error Cache-Control > directives ([RFC5861]) could be well-suited to a DoH implementation > when allowed by server policy. Those mechanisms allow a client, at > the server's discretion, to reuse a cache entry that is no longer > fresh. In such a case, the client reuses all of a cached entry, or > none of it. Is this a normative requirement or a statement of fact? S 6.3. > establish that the HTTP request URI can be used for the DoH query. > For HTTP requests initiated by the DoH client, this is implicit in > the selection of URI. For HTTP server push ([RFC7540] Section 8.2) > extra care must be taken to ensure that the pushed URI is one that > the client would have directed the same query to if the client had > initiated the request. As well as the other push security check S 9.1. > DoH encrypts DNS traffic and requires authentication of the server. > This mitigates both passive surveillance [RFC7258] and active attacks > that attempt to divert DNS traffic to rogue servers ([RFC7626] > Section 2.5.1). DNS over TLS [RFC7858] provides similar protections, > while direct UDP and TCP based transports are vulnerable to this > class of attack. A citation to draft-ietf-dprive-padding-policy seems in order here, as well as later. S 10. > > In the absence of DNSSEC information, a DoH server can give a client > invalid data in response to a DNS query. Section 4 disallows the use > of DoH DNS responses that do not originate from configured servers. > This prohibition does not guarantee protection against invalid data, > but it does reduce the risk. Do you want to say something about TSIG (and it maybe not being needed here)
Why is there a request to remove §3 (Protocol Requirements)? I think it provides good background. [BTW, excellent Shepherd writeup!!]