> On 23 Oct 2016, at 00:25, Paul Hoffman <[email protected]> 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.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
