Hi, all,

I've reviewed this document as part of the Transport Area Review Team's (TSVART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC ​tsv-art@ietf.org if you reply to or forward this review.

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-doh-dns-over-https-13
Title: DNS Queries over HTTPS (DoH)
Reviewer: Fernando Gont
Review Date: August 11, 2018

Summary:

This document is almost ready, but requires some clarifications and, more importantly, an analysis of the impact of switching from a connection-less protocol (UDP) to a connection-oriented protocol (HTTPS/TCP) for DNS resolution.


** Technical comments **

* Page 5:
>  Using the GET method is friendlier to many HTTP cache
>  implementations.

Could the queries really be cached for the POST case?


* Page 15:
> It is the choice of a client to either
>    perform full DNSSEC validation of answers or to trust the DoH server
>    to do DNSSEC validation and inspect the AD (Authentic Data) bit in
>    the returned message to determine whether an answer was authentic or
>    not.  

Relying on the DoH server for DNSsec validation does not seem like a good idea. You want DNSsec to be end-to-end.


* Page 15 (Security Considerations):

DoH essentialy switches from a connection-less transport (UDP) to a connection-oriented one (TCP). This means that now the server should take care of all state-exhaustion attacks against TCP (e.g., take a look at: https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). Defending against such attacks maybe non-trivial. This should at least be mentioned in the security considerations.


* Page 16:> 
>    HTTP [RFC7230] is a stateless application-level protocol and
>    therefore DoH implementations do not provide stateful ordering
>    guarantees between different requests.

Are you meaning that requests that are pipelined could be responded in different order? Something else?


* Page 16:
>    A DoH server is allowed to answer queries with any valid DNS
>    response.  For example, a valid DNS response might have the TC
>    (truncation) bit set in the DNS header to indicate that the server
>    was not able to retrieve a full answer for the query but is providing
>    the best answer it could get.  A DoH server can reply to queries with
>    an HTTP error for queries that it cannot fulfill. 

Why should this happen? Why not encode this information in the encoded DNS response (in wire format)'


** Editorial comments **

Page 3:
>  Two primary uses cases were considered during this protocol's
>  development.

s/uses/use/


Page 3:
Please introduce and expand de acronym "DoH" the first time you employ it.


Page 7:

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

s/such as/such as for/ ?



* Page 16:> Note that these deadlocks
>    also need to be considered for server that a DoH server might
>    redirect to.

s/for server/for servers/ ?

Thanks!
Fernando