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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 14 Aug 2018 08:41:31 -0700

Benjamin Kaduk 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:
----------------------------------------------------------------------

I'll try to trim comments that were already mentioned, but will make an
exception for my surprise to see the (non-)requirements sections slated for
removal.  Would it be better to move them to an Appendix with disclaimer that
"the following goals were used by the WG during the design process but do not
represent an exhaustive list"?

It's a little unclear how much of the requirements on future work (e.g.,
media type/formats) needs to be done now vs. can be done when such work
appears.

[section-by-section comments follow]

Section 5.1

   Future specifications for new media types MUST define the variables
   used for URI Template processing with this protocol.

This is scoped to just future DNS-over-HTTP media types, right?

   In order to maximize cache friendliness, DoH clients using media
   formats that include DNS ID, such as application/dns-message, SHOULD
   use a DNS ID of 0 in every DNS request.  HTTP correlates the request
   and response, thus eliminating the need for the ID in a media type
   such as application/dns-message.  The use of a varying DNS ID can
   cause semantically equivalent DNS queries to be cached separately.

It's probably clear enough as implicit (especially given two paragraphs
prior), but do you want to mention that this HTTP-layer caching?

   DoH clients can use HTTP/2 padding and compression in the same way
   that other HTTP/2 clients use (or don't use) them.

Probably need the 7540 cite here as well.

Section 5.1.1

   In this example, the 33 bytes are the DNS message in DNS wire format.

Cite for "DNS wire format" (1035)?
Also, adding something like "starting with the DNS header" might forestall
questions about "is the UDP header or DNS/TCP length prefix included?".

Section 5.2.1

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

Is there a word or three missing here?

Section 6.1

   [...] (POST requests are not
   cacheable unless specific response header fields are sent; this is
   not widely implemented, and not advised for DoH).

I do not claim to be an HTTP expert, but are "request" and "response"
swapped in the above?

   [...] This requirement helps assure that
   none of the RRsets contained in a DNS response are served stale from
   an HTTP cache.

Is this better as "unintentionally served stale"?

   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.

Given that we're talking about the interaction between HTTP caching and DNS
caching, it seems reasonable to specify which layer of cache's cached entry
we're talking about.  (Probably other instances later in the section, too.)

   Other types of DNS data, such as zone transfers, may be larger and
   benefit more from revalidation.

Just to check my recollection: the current DoH document is incompatible
with zone transfers (by virtue of being single request/response)?

Section 8.1

It's unclear that the security considerations for application/dns-message
exactly match those of "pure" DNS.  For example, DNS messages expect to
interact with DNS-layer caching, and messages wrapped in an application/dns
media type may also have to interact with additional cache layers (e.g.,
all of Section 6.1 of this document's considerations), and mis-caching can
have security consequences.

Section 9.2

   DNS implementations that use one TCP connection for multiple DNS
   requests directly group those requests.  Long-lived connections have
   better performance behaviors than short-lived connections, but group
   more requests.  [...]

I think the consequence of "group more requests" should probably be spelled
out, e.g., "which exposes more information to correlation and
consolidation".

Section 11

   The HTTPS channel used by this specification establishes secure two-
   party communication between the DoH client and the DoH server.

What does "secure" mean?

   [...] For OCSP, the
   server can bundle the certificate status as part of the handshake
   using a mechanism appropriate to the version of TLS, such as using
   [RFC6066] Section 8 for TLS version 1.2. [...]

TLS 1.3 is final (RFC 8446) if you feel like using the most-current
reference.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Aug 2018 16:49:53 +0000

Thanks for the review!

> This is scoped to just future DNS-over-HTTP media types, right?

Yes, we'll clarify that.

> prior), but do you want to mention that this HTTP-layer caching?

Yep, will fix.

> Probably need the 7540 cite here as well.

Sure.

> Cite for "DNS wire format" (1035)?

Sure.

> questions about "is the UDP header or DNS/TCP length prefix included?".

OK.

> Is there a word or three missing here?

Yep; fixed.

> I do not claim to be an HTTP expert, but are "request" and "response"

Not swapped, but our current wording is not right either. Fixing.

> Is this better as "unintentionally served stale"?

Sure.

> we're talking about.  (Probably other instances later in the section, too.)

Agree, and added "HTTP" in a few other places near here.

> with zone transfers (by virtue of being single request/response)?

Not completely. Some AXFRs can be done in a single response. This document does not prohibit trying AXFR.

> have security consequences.

Good point. We'll just repoint the IANA registration security considerations to the more inclusive ones in this document.

> out, e.g., "which exposes more information to correlation and

Added.

>   party communication between the DoH client and the DoH server.

The same thing as the "S" in "TLS". Explaining this again at this point might not bring much understanding to the reader, however.
> TLS 1.3 is final (RFC 8446) if you feel like using the most-current

We do! 

--Paul Hoffman

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 14 Aug 2018 11:56:07 -0500

> Thanks for the review!

Thanks for the fixes!  Just one note inline...

> The same thing as the "S" in "TLS". Explaining this again at this point might not bring much understanding to the reader, however.

Could you say something like "due to the confidentiality and integrity
protection provided by TLS" at the end of the subsequent sentence?

-Benjamin

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 14 Aug 2018 10:00:07 -0700

On 14 Aug 2018, at 9:56, Benjamin Kaduk wrote:

>> The same thing as the "S" in "TLS". Explaining this again at this 
>> point might not bring much understanding to the reader, however.
>

Sure.

--Paul Hoffman

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Thu, 16 Aug 2018 09:26:05 +0200

>> protection provided by TLS" at the end of the subsequent sentence?

I suggest to use "encrypted" instead of "secure" as DoH lacks reliable authentication (e.g. forged TLS certificates).

Renne