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

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Aug 2018 12:32:09 -0700

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)

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 13 Aug 2018 13:16:11 -0700

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

--Paul Hoffman

> You will need a cite for HTTPS.

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

> bulleted list, but alternately, "They were".

"They were" is good here.

> template, because you don't explain that till S 5. Perhaps in some

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.

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

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

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

> I think you mean "mapped"

Agree.

> You say "can" but the text below implies MUST.

Agree. s/can be/is/

> Is this a normative requirement or a statement of fact?

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

> As well as the other push security check

Yep, added.

> A citation to draft-ietf-dprive-padding-policy seems in order here, as

Agree.

> Do you want to say something about TSIG (and it maybe not being needed

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Aug 2018 13:27:26 -0700

On Mon, Aug 13, 2018 at 1:16 PM, Paul Hoffman <[email-masked]> wrote:

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

Sorry, this isn't an argument about templates but rather "why are templates
relevant here at all".

I think you want to say something like "The DOH client is configured with a
URI template [RFC6570] which describes how to construct the URL to use for
resolution."

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

How would you get a DoH request/response pair from that origin? Via push?

> JavaScript list and object declarations.

I don't think this is typically how Web programmers would think of it.

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

Well, it's not b64 of that that matters but rather 1/3 of the base64 of
that, because it's only the expansion that matters.

Back of the envelope: 40 * 1/3 ~= 13, and "application/dns-message" is 23
characters.

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

When those types of messages are defined, they can update this draft.

> Nothing. That's why it is a MAY.

This just seems like a confusing, non-interoperable, place holder.

> This should be on a different thread, I believe.

I don't think so. We're talking about the wisdom of this design choice.

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

Right, and what I'm saying is that this document should say that it
displaces TSIG.

-Ekr

---

From: Patrick McManus <[email-masked]>
Date: Mon, 13 Aug 2018 16:50:42 -0400

> content type. Normal answers will definitely be longer.

to clarify - the text is about requests, not responses.. which will be a
bit shorter that what Paul mentions in the dns-message part.

fwiw - the h2 hpack overhead here, which we expect is the common case - is
on the order of 4 bytes iirc.

I think we should resolve this just by hedging.. "are generally smaller
than their GET equivalents."

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

it is a statement of fact about http - its drawn out a bit here because its
particularly relevant to DNS (as similar algorithms are considered
elsewhere in the DNS world as well), and therefore DoH implementors, when
considering whether they want to make use of conditional validations.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 13 Aug 2018 17:44:17 -0400

> How would you get a DoH request/response pair from that origin? Via push?

The text primarily envisions push, but I believe a application/dns-message
response to a 'pull' request could create havoc if placed in a DNS cache
(not an HTTP cache) automagically because of the media type (independent of
the URI requested). Dns responses contain the dns question, so this isn't
impossible.