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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Aug 2018 04:39:31 -0700

Alexey Melnikov 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:
----------------------------------------------------------------------

This is an important piece of work, so thank you for doing this work. The
document is well written.

I am looking forward to seeing answers to Ben's questions/comments (I agree
with them).

I also have some comments of my own:

1) I think you should keep Section 3. Maybe make it an Appendix. It would be
important to have it if the document gets extended in incompatible ways and
some of the requirement/assumptions states in your document are violated.

2) Related to section 3: is there any desire in the WG to work on an extension
which would allow for cases when a single request might result in multiple
responses?

3) In 3.1:

o  Supporting other network-specific inferences from plaintext DNS
      queries

Can you please decode this for me, as I don't understand what this is trying to
say. Maybe provide an example?

4) In 5.1, next to the last para:

   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.

Not being that familiar with DNS (and not having read the whole document at
this point) I didn't know whether this was talking about some kind of DNS
specific thing or whether it was talking about something specific to DoH. At
some point I was wondering if DNS ID was supposed to be included in some kind
of URL. So maybe you should add a reference where you mention "DNS ID" for the
first time.

5) In Section 8.1:

   Security considerations:  The security considerations for carrying
   this data are the same for carrying DNS without encryption.

I think you should do much better then this. This field is supposed to give a
quick hint whether there is any active content(*) (e.g. executable code) in the
described media type, so that people implementing firewalls and antispam can
decide whether anything special needs to be done to process the media type. But
what you did is effectively sent me to read all DNS related RFCs on the topic.
So please also state whether active content is allowed here.

(*) - among other things

6) In Section 11, 3rd para:

   Some HTTPS client implementations perform real time third-party
   checks of the revocation status of the certificates being used by
   TLS.  If this check is done as part of the DoH server connection
   procedure and the check itself requires DNS resolution to connect to
   the third party a deadlock can occur.  The use of OCSP [RFC6960]
   servers or AIA for CRL fetching ([RFC5280] Section 4.2.2.1) are
   examples of how this deadlock can happen.  To mitigate the
   possibility of deadlock, DoH servers SHOULD NOT rely on DNS-based

I might be confused here, but I thought the most typical is for a DoH *client*
to validate DoH *server's* certificate for being revoked. So did you mean "DoH
client" instead of "DoH server" above? If not, then I think you lost me and
this text needs to be rewritten to be more specific about what the problem is.

   references to external resources in the TLS handshake.  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.  AIA deadlocks can be
   avoided by providing intermediate certificates that might otherwise
   be obtained through additional requests.  Note that these deadlocks
   also need to be considered for server that a DoH server might
   redirect to.