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

[Paul Hoffman <[e-mail]>]

Thanks, Sara! I have opened pull requests for #1, #3, and #4. Of the remaining:

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

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.


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

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

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

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

--Paul Hoffman