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

From: Sara Dickinson <[email-masked]>
Date: Mon, 30 Apr 2018 18:59:44 +0100

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 <[email-masked] <mailto:[email-masked]>>
> Subject: [Doh] WGLC on draft-ietf-doh-dns-over-https
> Date: 18 April 2018 at 20:07:35 BST
> To: DoH WG <[email-masked] <mailto:[email-masked]>>
> 
> 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 [email-masked] <mailto:[email-masked]> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/doh

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2018 03:22:40 +0000

> - EDNS(0) Keepalive (RFC7828).

I'm not sure why there are "problems" with these. For padding, the server can use it or not. For keepalive, it makes no sense for it to support it. Just like any traditional DNS server, a DOH server has to understand its context when deciding how to answer queries with EDNS options.

> - 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. 

Please, no. Or at least, not here. The complicated DNS-over-TLS usage policies are one of the reasons we have so little implementation of DNS-over-TLS. (Others may disagree with this statement.)

It would be lovely if Stubby could add DOH as a transport that is parallel to DNS-over-TLS, and for that there has to be some common understanding of privacy and trust levels. Duplicating to twisty mazes from DNS-over-TLS usage policies is not going to help. Instead, a new document that covers DNS-over-TLS, DOH, and the likely future DNS-over-QUIC needs to deal with this, and more clearly.

I'm about to propose a non-WG-forming BoF in Montréal for folks who want to talk about such work. But I don't think it should stop DOH; if it does, we're probably talking at least six months to hope for consensus. (And the consensus on policy in DPRIVE was more from exhaustion than agreement.)

> 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 alread…

The BoF would cover these as well. DOH has similar issues as DNS-over-TLS has here.

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Tue, 01 May 2018 05:04:41 +0000

> I'm not sure why there are "problems" with these. For padding, the server
can use it or not. For keepalive, it makes no sense for it to support it.
Just like any traditional DNS server, a DOH server has to understand its
context when deciding how to answer queries with EDNS options.

Sara's request for text regarding 7828 is reasonable.  Generic text might
suffice along the lines of "extensions to DNS that are specific to the
choice of transport, such as RFC 7828, are not applicable to DOH".  FWIW,
HTTP/2 has its own keepalive mechanisms.

I agree with Paul here regarding padding though.  Padding with EDNS(0)
seems like a reasonable choice especially if padding at the HTTP or TLS
layers is not used.  EDNS(0) padding might be more accessible.

> The complicated DNS-over-TLS usage policies are one of the reasons we
have so little implementation of DNS-over-TLS. (Others may disagree with
this statement.)

I agree with Paul - the profile in RFC 8310 overlaps considerably with text
in HTTP RFCs.  For instance, HTTP/2 already mandates TLS 1.2 or greater
without compression (it also goes further to require PFS).  8310 also
misses a few things that DOH covers, such as the OCSP/AIA deadlock.

The true advantage of DOH is that it just uses HTTP.  And that means
relying on HTTP mechanisms for ensuring integrity, confidentiality, and
authentication.  I think that those are broadly adequate.

Separately, I'd suggest that the 8310 profile requirements are
unrealistic.  I'm not aware of many implementations that do raw public keys
or cached info.  I also don't see any particular value in mandating tickets
and false start - they each provide ample motivation on their own without
needing a MUST.