Re: [dns-privacy] Working Group Last Call draft-ietf-dprive-dtls-and-tls-profile

[Sara Dickinson <[e-mail]>]

> On 23 Oct 2016, at 00:25, Paul Hoffman <[e-mail]> wrote:
> 
> Greetings. I apologize for this being late, but I kinda wanted to see what topics other reviewers focused on. However, other than Stéphane's review, nothing has been said.

Paul, 

Many thanks for the detailed review. This feedback is much appreciated.

> 
> There are some big topics for the document that I have split out into other messages. Some may be considered rehashing of earlier discussions, and I'm totally open to "nope, that's not what the WG wants", but I think it is worth making sure we all still feel that way. The rest of this message are nits.
> 
> Section 1: "The proposals here might be adapted or extended in future to be used for recursive clients and authoritative servers, but this application is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter." This document will long outlive the WG, so everything after the first comma should be removed.

So…. this got added after multiple comments of ‘why is recursive to auth not in scope?”. It is also lifted directly from RFC7858 (DNS-over-TLS) as it was the wording used to justify the scope at the time of publication of that document. But there have been several comments on this sentence and that is the response I have given every time :-)  If the charter is changed before this document is published I agree this should be updated but I happen to think this gives useful context for future readers. But would like to hear what others think.

> 
> Section 1: "How a DNS client can verify that any given credential matches the domain name obtained for a DNS server." "obtained" is somewhat difficult here because there are many ways that the name is determined. Proposal: "matches the domain name of the DNS server”.

We used the word ‘obtained' here as in the early discussions there was confusion about what domain name (or names) a DNS server serves, and what the domain name that is used for authentication is. We wanted to be clear there is no correlation between the two.  Hence the rather clumsy wording that is at least consistent between the first and third bullet points. 

OLD:
   o  How a DNS client can obtain a domain name for a DNS server to use
      for (D)TLS authentication.

   o  What are the acceptable credentials a DNS server can present to
      prove its identity for (D)TLS authentication based on a given
      domain name.

   o  How a DNS client can verify that any given credential matches the
      domain name obtained for a DNS server.

NEW:
   o  How a DNS client can obtain an ‘authentication domain name' for a DNS server to use
      for (D)TLS authentication.

   o  What are the acceptable credentials a DNS server can present to
      prove its identity for (D)TLS authentication based on a given
      domain name.

   o  How a DNS client can verify that any given credential matches the
      ‘authentication domain name' for a DNS server.

In fact maybe it would be better to define ‘authentication domain name’ in the terminology an use it throughout?

> 
> Section 1: "DNS-over-TLS draft" should be [RFC7858].

Fixed.

> 
> Section 2: "forwarder/proxy" (used twice) The rest of the sentence talks only about forwarder, and it's not clear how a proxy differs from a forward, so maybe just change these to "forwarder”.

Done. 

> 
> Section 4: In Table 1, change "N (D)" to "ND". I cannot figure out what the parentheses mean, and all three N situations are ND.

Parenthesis removed. 

> 
> Section 4.3.1: "Bootstrapping" is not a widely-understood term.

Really? A quick Google finds RFC4173 from 2005 which has Bootstrapping in the title. It would be nice to keep it unless there are general objections as it more accurately describes the specific issue addressed in that section.

> 
> Section 8.3: The "[NOTE:" is not really a note, it is a full statement. Proposal: remove "[NOTE:" and "]”.

Done. 

> 
> Section 11: The first paragraph covers multiple topics; it could be broken after second sentence.

Done.

Thanks - working my way through your other emails!

Sara.