On 26 Oct 2016, at 6:23, Sara Dickinson wrote:
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.
Saying "The proposals here might be adapted or extended in future to be
used for recursive clients and authoritative servers" should be
sufficient to say "it's not like we didn't think about it". If people
really want to have the charter discussion in this long-lived RFC, at
least change the second clause to "but this application was out of scope
for the Working Group charter at the time this document was finished".
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?
That would be good, yes. But "obtained" still sounds like it might come
from the DNS itself, not from configuration or DHCP.
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.
"Pulling yourself up by your own bootstraps" is a difficult idiom for
people even if English is their first language.
It would be nice to keep it unless there are general objections as it
more accurately describes the specific issue addressed in that
section.
In this specific case, it's more "chicken or egg" than "bootstrap"
because you actually do first use the unsecured DNS. Maybe just
"Startup" for the title and leave bootstrap in the body text (which does
describe the problem quite well).
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
