[Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-doh-dns-over-https-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/



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