DNS Queries over HTTPS (DoH)
draft-ietf-doh-dns-over-https-14

[Ballot comment]
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 4.2.2.1) 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.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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)

[Ballot comment]
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.

[Ballot comment]
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 futher clarify this sentence in section 5.1:
"Using the GET method is friendlier to many HTTP cache implementations."
What does "friendler" mean...? Or at least maybe provide a forward reference to sec 6.1.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-doh-dns-over-https-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new Media Type will be registered as follows:

Name: dns-message
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-08):

From: The IESG
To: IETF-Announce
CC: doh@ietf.org, adam@nostrum.com, Benjamin Schwartz , bemasc@google.com, doh-chairs@ietf.org, draft-ietf-doh-dns-over-https@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNS Queries over HTTPS (DoH)) to Proposed Standard


The IESG has received a request from the DNS Over HTTPS WG (doh) to consider
the following document: - 'DNS Queries over HTTPS (DoH)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes how to make DNS queries over HTTPS.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7626: DNS Privacy Considerations (Informational - IETF stream)

Document Shepherd Writeup for “DNS Queries over HTTPS”

1. Summary

Document Shepherd: Benjamin Schwartz
Responsible Area Director: Adam Roach
Revision: 00
Date: 2018 June 27

This document defines a protocol for performing DNS Queries over an HTTPS connection.  This protocol offers similar security benefits to DNS-over-TLS (RFC 7858), and also allows integration with HTTP-based systems and services.  The working group requests publication as a Proposed Standard because there is wide interest and growing implementation of the protocol, and standardization is important to ensure interoperability between clients and servers.

2. Review and Consensus

The document has been reviewed thoroughly within the working group, including extensive commentary by noted standards experts and large-scale implementors in DNS and HTTP.

Implementation has begun, with a large-scale deployment by Cloudflare, experiments by Mozilla and Google, and many independent implementations: doh-proxy (an IETF hackathon output), Go DNS, dnscrypt-proxy, doh-php-client, jDnsProxy, rust-doh, and dns-over-https.  The maintainers of Stubby, CURL, and PowerDNS’s dnsdist have developed working prototypes.

The draft has received excellent, thorough review.  There has not been any vocal opposition to the draft as whole, and the points of contention largely appear to have been resolved through sound debate on the technical merits, to the satisfaction of most participants.

2a. Notable debates during standard development

== Binary vs. Human-readable ==

Early in the process, there was some debate on whether to use the existing DNS wire format directly or to define a more legible format (e.g. HTTP query syntax, JSON).

Conclusion: The draft defines the existing DNS wire format as Mandatory To Implement, and supports HTTP content-type negotiation to select other formats.

== Use of HTTP errors ==

There was initially some question of whether a DNS error response (e.g. SRVFAIL, NXDOMAIN) should be provided to the user as an HTTP success response (200) or an error response (500, 404).

Conclusion: Any DNS wire format message is an HTTP success response (200), even if the DNS message is intended to communicate an error.  HTTP error responses are also allowed, but they are not used to send DNS error responses.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00279.html

== TTL Interpretation ==

The working group quickly reached consensus that HTTP cache lifetimes should match the DNS expiration time indicated by the TTL.  However, finding language to specify this required extensive iteration.

Conclusion: HTTP experts contributed detailed language to a long section on Cache Interaction.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00526.html

== GET vs. POST ==

DNS queries do not mutate server state, so they have semantics similar to HTTP GET.  However, GET does not have a body, so transmitting a wire format DNS query in GET requires encoding it in Base64 in the URL, which seems unnatural.  Conversely, using POST allows a more natural encoding, but has a less natural semantic match, because it normally indicates a mutating operation.  Using POST is also incompatible with some other design goals, such as good HTTP cache support and HTTP/2 PUSH.

Conclusion: The draft requires servers to support queries over GET and POST.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00407.html
https://www.ietf.org/mail-archive/web/doh/current/msg00268.html

== Configuration and .well-known ==

The first several versions of the draft proposed a new, optional “.well-known” path for this protocol.  This would enable clients to select a server by its domain name, similar to DNS over TLS.  It would also open a logical path for potential standards work on opportunistic upgrade (given only an IP address) and for receiving DNS records via HTTP/2 PUSH from unexpected sources.  However, HTTP experts strongly advised against attempting to use .well-known for this purpose.

Conclusion: The .well-known proposal was dropped, and configuration is specified to require a full URL.  Bootstrapping from a domain is not defined in this document, but could be defined in a future document.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00244.html
https://www.ietf.org/mail-archive/web/doh/current/msg00208.html

== Forward compatibility and URL structure ==

Early versions of the draft proposed that a DOH endpoint is specified by a URL, with a standardized format for query parameters.  This makes clients simple, and also enables forward compatibility by defining new query parameters (which older servers will ignore).  However, some group members felt that a fixed URL structure was inflexible, and suggested URI Templates instead.  Configuration using URI Templates allows a wide range of URL structures but would require reconfiguration of each client instance to use any parameters that might be added in a future version of DOH.

Conclusion: The draft adopted URI Templates as the sole configuration mechanism.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00393.html

== Truncation behavior ==

Depending on the transport, DNS servers sometimes truncate their responses based on size limits configured in the server or signalled in the query.  There was some discussion of whether clients should be able to request truncation behavior from a DOH server, or whether we should forbid DOH servers from returning truncated answers.

Conclusion: The draft has no normative requirements related to truncation, but there is text indicating that returning a truncated response is similar to returning an HTTP error response.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00371.html
https://www.ietf.org/mail-archive/web/doh/current/msg00472.html

== Size limits ==

In UDP, DNS messages are limited to 65535 bytes in length.  DNS over TCP has an identical limit due to its two-byte length field, and similarly DNS over TLS.  However, HTTPS has no such limit, nor does the DNS format itself (as specified in RFC 1035, etc.).  Some working group members requested that DOH impose a 65535-byte limit to ensure reliable convertibility of messages, and a few proposed applying a “gateway” requirement to all future media types as well.  Others suggested allowing messages of unlimited size, letting implementors choose their own tradeoff between capacity and compatibility.

Conclusion: The mandatory to implement media type is limited to 65535 bytes, but future media types might not impose an equivalent limit.  This message size limit was imposed out of an abundance of caution, not technical necessity.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00650.html
https://www.ietf.org/mail-archive/web/doh/current/msg00619.html

== Zone transfers ==

The DNS protocol is used not only for common queries (AAAA, TXT) by stub and recursive resolvers, but also for zone transfers (AXFR) initiated by authoritative DNS servers.  These queries use the DNS protocol, but the response is often larger than 65535 bytes.  DNS enables these responses with “continuation messages”, i.e. sequences of DNS response messages that are in response to a single query.  Some WG members suggested banning AXFR queries in DOH, while others suggested defining a mechanism for transferring multiple response messages to a single query (e.g. multipart/related).

Conclusion: The draft does not ban AXFR queries, and it does not define a mechanism for receiving multiple or combined responses.  Response sizes in future media types or protocol versions are not constrained.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00657.html

== Privacy language ==

Compared to previous DNS transports, DOH introduces new ways for servers to link queries from a single client over time (e.g. HTTP cookies, locale headers).  Some WG members suggested normative requirements not to use some of these features (e.g. User-Agent), while others viewed them as useful features worth preserving.  There was also some debate about how strongly to warn implementors about linkability.

Conclusion: An extensive Privacy Considerations section was added, with comparisons to other DNS transports and some advice but no normative requirements.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00835.html
https://www.ietf.org/mail-archive/web/doh/current/msg00803.html
https://www.ietf.org/mail-archive/web/doh/current/msg00777.html

== Trust language ==

The working group has clear consensus that a client should not send a query to a server unless it trusts that server to receive the query, and should not use an unsigned response unless it trusts the server to answer truthfully.  However, finding language to describe this proved challenging.

Conclusion: A section was added on “Selection of a DoH Server” to emphasize that queries must only be sent to a server on purpose.

Threads:
https://www.ietf.org/mail-archive/web/doh/current/msg00492.html
https://www.ietf.org/mail-archive/web/doh/current/msg00590.html

3. Intellectual Property

The authors have confirmed that they are not aware of any relevant IPR.  There have been no disclosures filed and little or no discussion of IPR in the working group beyond the Note Well.

4. Other points

This draft normatively references RFC 7626, which has Informational status and is not in the DOWNREF registry.

This draft has a single IANA consideration (defining the “application/dns-message” media type).  There has been extensive review of this media type, including several name changes.