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

["Paul Hoffman" <[e-mail]>]

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