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

["Paul Hoffman" <[e-mail]>]

Thanks for the thorough review. We have a new PR for the changes below.

--Paul Hoffman

On 13 Aug 2018, at 12:32, Eric Rescorla wrote:

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

We'll copy the {{RFC2818}} reference here as well.

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

"They were" is good here.

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

Saying "URI Templates were used because that's the new way to do things 
in the web world" would be honest, but maybe not that helpful in the 
document. Others might have a better way to say this.

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

I send an query to https://www.ekrexample.com/ over HTTP/2. During that 
HTTP/2 session, I get a DoH request/response pair from that origin. 
https://www.ekrexample.com/ is not in the list of configured URIs 
allowed for DoH for this client. I MUST NOT do anything with that DoH 
request/response.

> Also, "configured" is an odd term if you are talking about web apps

Even web apps appear to have configuration in them, although usually as 
JavaScript list and object declarations.

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

All DoH responses are at least about 17 bytes long (the 12-byte DNS 
message header plus the shortest possible domain name plus the type and 
class), much more typically at least 40 bytes with typical names and 
even a short answer. Base64 of that will be longer than the content 
length and content type. Normal answers will definitely be longer.

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

To allow other future types of messages that encode DNS information.

> What would I do with like image/jpeg.

Nothing. That's why it is a MAY.

> I tend to think of draft-thomson-postel-was-wrong here.

This should be on a different thread, I believe.

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

Agree.

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

Agree. s/can be/is/

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

Not sure. Input from the HTTP crowd is welcome here.

> 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

Yep, added.

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

Agree.

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

Not really. The WG discussed TSIG and decided it was not needed here.