Usage Profiles for DNS over TLS and DNS over DTLS
RFC 8310

Note: This ballot was opened for revision 09 and is now closed.

(Ben Campbell) Yes

Comment (2017-05-10 for -09)
No email
send info
I'm balloting "yes", but I do have some comments:

Substantive:

5: "Clients using Opportunistic Privacy SHOULD try for the best case..."
When might it be reasonable _not_ to try for the best case? (That is, why not MUST)? 

5.1: What's a reasonable granularity for the profile selection? The text suggests that decision is on a per-query basis; is that the intent? I assume you don't expect a user to make a decision for each query.

6.5: The statement that a client using OP "MAY" try to authenticate seems inconsistent with the "SHOULD try for the best case" statement in S5. (But seem my comment above about that.)

13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, so it should be a normative reference. (Note that this would be a downref.)

Editorial:

2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- over-DTLS [I-D.ietf-dprive-dnsodtls]."
Unless these are new-to-this-draft requirements, please use descriptive (non-2119) language. (Especially in a definition).

5: "Strict Privacy provides the strongest privacy guarantees and
   therefore SHOULD always be implemented in DNS clients along with
   Opportunistic Privacy."

Does that mean "SHOULD implement both strict and opportunistic privacy" or "If you implement opportunistic you SHOULD also implement strict?"

 6.2: Should list item "2" be "ADN+IP", like in the table?

11: Is "SHOULD consider implementing" different than "SHOULD implement"? If so, please consider dropping the 2119 "SHOULD" when talking about what people think about.

Alissa Cooper Yes

Comment (2017-05-10 for -09)
No email
send info

(Terry Manderson) Yes

Alexey Melnikov (was Discuss) Yes

Comment (2017-05-11 for -09)
No email
send info
Please make RFC 7918 and RFC 7924 Normative references, as they are mentioned in SHOULD level requirements.

I am agreeing with Ekr comments. I am also agreeing on first and last Mirja's comment.

Section on future DHCP extension is a bit "hand-wavy". Is any work on this planned? I see that Suresh raised a DISCUSS on this point, so I am happy for him to hold it.

(Kathleen Moriarty) Yes

Comment (2017-05-09 for -09)
No email
send info
I agree with EKRs and Mirja's comments and see they are being addressed.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2017-05-11 for -09)
No email
send info
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.

(Spencer Dawkins) No Objection

Suresh Krishnan (was Discuss) No Objection

Comment (2017-07-31 for -10)
No email
send info
Thanks for addressing my DISCUSS.

Mirja Kühlewind No Objection

Comment (2017-05-08 for -09)
No email
send info
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.

(Eric Rescorla) (was Discuss) No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2017-05-09 for -09)
No email
send info
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.

Warren Kumari Recuse

Comment (2017-05-10 for -09)
No email
send info
As a current WG chair I am recusing myself from this ballot.