Re: [Doh] WGLC on draft-ietf-doh-dns-over-https

[Sara Dickinson <[e-mail]>]

Hi All, 

TL;DR but - I’ve read this version of the draft and have a few comments. I’ve listed them here for discussion but can create GitHub issues if that is the preferred mechanism (not sure?).


1)  Section 2: Terminology. The phrase ‘regular DNS protocol’ is used here but the terms ‘traditional DNS/traditional DNS clients/traditional DNS nameserver’ are used in Sections 1 and 9. It is not clear to me if these terms all mean the same thing, that being one of
a) only DNS over UDP/TCP 
b) DNS over any of UDP/TCP or (D)TLS with any usage profile?
c) DNS over any of UDP/TCP or (D)TLS with only an Opportunistic usage profile?
or are they are supposed to mean different things? 

Section 1: Suggest   s/transport suitable for both traditional DNS clients/transport suitable for both existing DNS clients/

Section 2: Suggest   s/differentiate it from a "DNS server" (one that uses the regular DNS protocol). /differentiate it from a "DNS server” (one that only provides DNS service over one or more of the other transport protocols standardised for DNS). /

I fear the definition of a client here is possibly too simplistic in the sense that it isn’t clear if it supports only DOH or other transports (also see later)…


2) Sections 3, 4.2 and 6 mention the presence of EDNS(0) options. Section 6 specifically says 
“DNS API clients using the DNS wire format MAY have one or more EDNS options [RFC6891] in the request.” 

In a similar manner to the problem with truncation of responses, there are 2 EDNS options I can think of that are transport specific, but how to handle them isn’t described in this draft i.e.
- EDNS(0) Padding (When RFC7830 was written only DNS-over-TLS was standardised, but the text doesn’t restrict it to that it simply says “Therefore, implementations MUST NOT use this option if the DNS transport is not encrypted.”).  Alexander Mayrhofer requested a note be added about this option in his review of the -04 draft.
- EDNS(0) Keepalive (RFC7828).

3) Section 8: I’d suggest this is re-written somewhat to be clearer that DOH and DNSSEC are independent mechanisms (by using similar language to RFC7858), and to remove any confusing overload of the word ‘trust’ in this document:

OLD:

“The HTTPS connection provides transport security for the interaction
   between the DNS API server and client, but does not inherently ensure
   the authenticity of DNS data.  A DNS API client may also perform full
   DNSSEC validation of answers received from a DNS API server or it may
   choose to trust answers from a particular DNS API server, much as a
   DNS client might choose to trust answers from its recursive DNS
   resolver.  This capability might be affected by the response media
   type.”

SUGGESTED:

“The HTTPS connection provides transport security for the interaction
   between the DNS API server and client, but does not provide the
   _response integrity_  of DNS data provided by DNSSEC.  DNSSEC and DOH 
   are independent and fully compatible protocols, each solving different problems.  
   The use of one does not diminish the need nor the usefulness of the other.
   The unique aspect of DOH is that the choice of a client to either perform full
   DNSSEC validation of answers or to treat answers from a DNS API server as 
   DNSSEC authenticated may be affected by the response media type."


4) Section 8: With regard to trusted/untrusted servers I would suggest at least a small restructure for clarity. At the moment the first discussion of the client trust model is in section 5.3 ‘Server Push’.

I would suggest adding a section before this (possibly after section 3) called something like ’Trust model for client queries’ with the following (combining text from section 5.3 and 8):

  “Before using DOH response data for DNS resolution, the client MUST
   establish that the HTTP request URI is a trusted service for the DOH
   query, in other words, a client MUST only trust a DNS API server
   that is configured as trustworthy. A client MUST NOT trust a DNS API 
   server simply because it was discovered, or
   because the client was told to trust the DNS API server by an
   untrusted party. 

   This specification does not extend DNS resolution privileges 
   to URIs that are not recognized by the client as trusted DNS API servers. 
   As such, use of untrusted servers is out of scope of this document 
   (however Section 8 discusses some of the security risks of using them).”


Section 5.3 then becomes simply:

“For HTTP requests initiated by the DNS API client trust in the DOH response 
data 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. “ 

And Section 8 can just say:

“A server that is acting both as a normal web server and a DNS API
   server is in a position to choose which DNS names it forces a client
   to resolve (through its web service) and also be the one to answer
   those queries (through its DNS API service). An untrusted DNS API 
   server can thus easily cause damage by poisoning a client's cache
   with names that the DNS API server chooses to poison.  As stated in section X, a client 
   MUST only trust a DNS API server that is configured as trustworthy.”


5) Section 8: 

   "If a client of this protocol encounters an HTTP
   error after sending a DNS query, and then falls back to a different
   DNS retrieval mechanism, doing so can weaken the privacy and
   authenticity expected by the user of the client.”

This text brings up the biggest issue I have with the document, which is that I would like to request that it replaces the above text with a section that clarifies how DOH can be used in the context of a privacy usage profile (see both RFC7858 and RFC8310 for descriptions of Strict vs Opportunistic usage profiles for DNS-over-(D)TLS).  To be clear: in these profiles only configured servers are used (no discovery is involved). I’m happy to help with text here if there is consensus that this is in scope and beneficial to the document. 

The big, big gain I see here is for applications such as Stubby which would like to have a standard way to add DOH as a transport option alongside the existing use of DNS-over-TLS when using those profiles.  In this scenario Stubby would be the ‘client’ in the text above which can use either a DNS API client or a ‘traditional' DNS client.  

(As an aside, I note that the above is the first and only mention of the word ‘privacy' in the document and this document does not currently describe the specific privacy benefits of this specification compared to ’other mechanisms’.)

Two ambiguities with the current text are:
- RFC8310 says a DNS client should only use a single privacy usage profile when resolving a specific query (precisely to avoid the problem mentioned above) but this text seems to contradict that. 
- while it is heavily implied the document isn’t actually crystal clear on whether a configured ‘trusted’ server can be used if authentication of the certificate fails. 


6) Section 9: 

“A DNS API client may face a similar bootstrapping problem when the
 HTTP request needs to resolve the hostname portion of the DNS URI."

“...or resolving the DNS API server's hostname via traditional DNS “

DNS-over(D)TLS using only a configured authentication domain name shares many of the discovery issues that DoH has. Paragraph 4 of Section 9 overlaps with the discussion of ‘meta-queries’ as already described in more detail in RFC8310 and it would be helpful if the language could be aligned or if RFC8310 was at least referenced here. One of the issues discussed in that document is the potential for denial-of-service if these meta-queries are subject to attack, which seems worthy of note. Again, happy to help with text here.

Regards

Sara. 




> Begin forwarded message:
> 
> From: Ben Schwartz <[e-mail] <mailto:[e-mail]>>
> Subject: [Doh] WGLC on draft-ietf-doh-dns-over-https
> Date: 18 April 2018 at 20:07:35 BST
> To: DoH WG <[e-mail] <mailto:[e-mail]>>
> 
> All,
> This message starts a two week WG Last Call on advancing:
> 
>   Title           : DNS Queries over HTTPS
>   Author          : Paul Hoffman, Patrick McManus
>   Filename        : draft-ietf-doh-dns-over-https-07
>   Pages           : 17
>   Date            : 2018-04-11
> 
> as a Standards Track document. The last call will end on May 2, 2018.
> All substantive comments are to be sent to the [e-mail] <mailto:[e-mail]> list for
> discussions. Editorial comments can be sent to the document editor.
> 
> You can find the latest version of the document here:
> https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 <https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07>
> 
> Regards,
> Ben & tale
> _______________________________________________
> Doh mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/doh