Usage Profiles for DNS over TLS and DNS over DTLS
draft-ietf-dprive-dtls-and-tls-profiles-11

The final paragraph of section 6.6 says "The system MUST alert by some means that the DNS is not private during such bootstrap." -- presumably, this means "client" where it says "system" (as opposed to any other part of the infrastructure) -- but I'm having a hard time envisioning how this gets practically implemented, given that the functionality described by this section is going to be implemented in DNS stub resolver libraries, which tend to be pretty far removed from any user interface. Given that this is a MUST-strength requirement, I think it would be very useful to describe what this alerting might look like for (a) interactive applications like a web browser; (b) commandline utilities like curl; and (c) background tasks like software update daemons. This would provide some context for the library implementors to provide the proper hooks to enable this "MUST" to be satisfied.

Section 11.1 mentions that it will describe techniques for thwarting DNS traffic analysis, including "monitoring of resolver-to-authoritative traffic". I see that there have been measures added to prevent authoritative servers from determining the identity of the client; but given the phrasing I cite above, I was expecting a description of how to prevent eavesdroppers who can see both incoming and outgoing traffic from the recursive resolver from correlating the encrypted packets I send to that resolver with the plaintext queries it emits for non-cached results. As far as I can tell, there are no described counter-measures against such an attack (aside from hoping that volume of traffic to the resolver is too great to perform such correlation with any real precision), right? If such measures have been defined, I imagine a citation would be warranted. If not, the above phrasing should probably be qualified; e.g., "monitoring of resolver-to-authoritative traffic alone."

Nits:
draft-ietf-dprive-dnsodtls has been published as RFC 8094
The draft header indicates that this document updates RFC7858, but the abstract doesn't seem to mention this, which it should.

Here is Eric Vyncke's OPS DIR review:

From the abstract: This document discusses Usage Profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS).  This document also specifies new authentication mechanisms. DPRIVE (DNS Private exchange) aims at enhancing DNS privacy by encrypting the DNS traffic (DNSsec only provides authentication/integrity).

There are two profiles: strict and opportunistic. The latter allows normal DNS operations as a fallback, which is key for successful deployment. 

This document in section 6  compares the SIX different authentication mechanisms and gives some guidelines with a lot of SHOULD and MAY and little MUST. Unsure whether it makes the implementers' task easy. Section 8 is more directive and more useful.

Section 7.3 is mainly about the legacy DHCP server for the legacy IPv4. No word about IPv6 and no word about RFC 8106 (DNS info for SLAAC).

Overall, there are no discussion about the performance (latency, load of clients/servers) of one authentication mechanism compared to the others, no discussion about resilience (i.e. if one server fails, for example in the PKIX cert chains) and I believe that performance and resilience to network error could be useful for the implementer/architect.

As a reader, I regret that this document combines two aspects: description of the profiles but also how to extend one TLS authentication method to DTLS... I would have preferred having two documents. But, this is mainly about readability.

My main comment is on this part related to profile selection I guess:

Section 5.1 says:
"A DNS client SHOULD select a particular Usage Profile when resolving
   a query."
but then section 6.5 says:
"This information can provide a basis for a DNS
   client to switch to (preferred) Strict Privacy where it is viable.“
I assume the later sentence is supposed to mean to switch for the next query to the same resolver? Actually regarding the sentence above in section 5.1., it is also not fully clear to me why you use profiles on a per query basis? However, to me the sentence in section 6.5 does not really make sense given that Opportunistic Privacy means that I want the best privacy possible but not fail if that not available. Why would I chance this policy? I guess you mean to says something like, if authentication worked once  to a certain resolver and it is therefore known that the server supports DNS-over-(D)TLS, one could consider to switch to Strict Privacy for future requests because the likelihood that an authentication failure is an attack is high. Not sure if that's true though. However, I think that this needs a separate discussion. In general it might be worth in this document to better distinguish the case where encryption or authentication is not even offered/available for any reason and where it fails (and therefore there might or might not be an (passive) attack).


Minor comments but related:
1) "A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to
   the use of clear text (no privacy)."
I'm not sure I understand this sentence. What are the implications here? Does this mean that if you have implemented DNS-over-(D)TLS, you have to use it? Not sure that this is something that can or should be specified in an RFC.

2) section 6.5:
"In this case, whilst a client
   cannot know the reason for an authentication failure, from a privacy
   standpoint the client should consider an active attack in progress
   and proceed under that assumption. "
What does this mean? Does this lead to any meaningful actions, like logging? More advise would be helpful here.

Thanks for addressing my DISCUSS.