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

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 Oct 2016 02:58:09 -0400

All,

This document has been in holding pattern while the dns-over-dtls 
document was addressed and moved forward.  Also, the authors were 
waiting to hear from one straggler author (dkg, the secure courtesy 
phone please).  The chairs feel we will use the WGLC as a forcing 
function the latter issue.

This starts a Working Group Last Call for:
    draft-ietf-dprive-dtls-and-tls-profile

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends on 20 
October 2016

thanks
tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 7 Oct 2016 11:48:40 +0200

On Thu, Oct 06, 2016 at 02:58:09AM -0400,
 Tim Wicinski <[email-masked]> wrote 

>    draft-ietf-dprive-dtls-and-tls-profile

Executive summary: OK for me,
draft-ietf-dprive-dtls-and-tls-profiles-03 can (and should) be
published. I find that touchy issues, such as the relationship with
the authentication mechanisms described in RFC 7858, or such as the
table 1 "DNS Privacy Protection by Usage Profile and type of attacker"
are nicely done.

The table 1 could use some details about the possibility of detection
for passive attacks (for active attacks, it is addressed in section
5). These details were promised in
<https://mailarchive.ietf.org/arch/msg/dns-privacy/8VMIuFKWZUAzP7UWivLn9fA_Ew4>
:-)

Technical question:

The document seems to use "X.509" and "PKIX" as synonyms. Is it really
the case?

Small legal detail:

> this application [extended to be used for recursive clients and
> authoritative servers] is out of scope for the DNS PRIVate Exchange
> (DPRIVE) Working Group per its current charter.

A bit exaggerated: the current charter says "it [the DPRIVE WG] may
also later consider mechanisms that provide confidentiality between
Iterative Resolvers and Authoritative Servers"

Editorial detail:

> but may be the subject of a future I-D.

Should probably be removed before it becomes a RFC.

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 07 Oct 2016 07:44:47 -0700

> The document seems to use "X.509" and "PKIX" as synonyms. Is it really

No. PKIX is an extension of X.509 (but almost no one uses unextended 
X.509 certs). Changing them all to PKIX is probably best.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 7 Oct 2016 18:32:21 +0100

> On 7 Oct 2016, at 10:48, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Good to know - thanks. 

> <https://mailarchive.ietf.org/arch/msg/dns-privacy/8VMIuFKWZUAzP7UWivLn9fA_Ew4>

Yes, thanks for catching (again)! I will add an example similar to the one in the mail thread into section 5 so that the discussion of detection of active and passive attacks are together. 

> The document seems to use "X.509" and "PKIX" as synonyms. Is it really

Paul’s suggestions of using PKIX throughout seems sensible.

> Iterative Resolvers and Authoritative Servers”

A reasonable point. I copied that text directly from RFC7858 (DNS-over-TLS) as that is how the scope is justified in that document….. 

> Should probably be removed before it becomes a RFC.

How about I change it to “may be the subject of future work”?  Unless such an ID is likely to appear in the very near future?  :-)

Sara.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 10 Oct 2016 16:28:10 +0200

On Fri, Oct 07, 2016 at 06:32:21PM +0100,
 Sara Dickinson <[email-masked]> wrote 
 a message of 67 lines which said:

> How about I change it to “may be the subject of future work”?

OK (and with the rest of your reply, too).

---

From: tjw ietf <[email-masked]>
Date: Wed, 19 Oct 2016 17:13:48 -0400

An update; The WGLC is scheduled to end tomorrow, but there has not been
enough discussion on the document is ready to move forward.  We will not
considered it passing WGLC unless there are more comments, pro or con.

thanks
tim

On Thu, Oct 6, 2016 at 2:58 AM, Tim Wicinski <[email-masked]> wrote:

> All,
>
> This document has been in holding pattern while the dns-over-dtls document
> was addressed and moved forward.  Also, the authors were waiting to hear
> from one straggler author (dkg, the secure courtesy phone please).  The
> chairs feel we will use the WGLC as a forcing function the latter issue.
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 22 Oct 2016 16:25:20 -0700

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.

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.

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".

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

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".

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.

Section 4.3.1: "Bootstrapping" is not a widely-understood term. 
Proposal: replace it with "Configuration".

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

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

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 26 Oct 2016 14:23:59 +0100

> On 23 Oct 2016, at 00:25, Paul Hoffman <[email-masked]> 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.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 26 Oct 2016 07:59:14 -0700

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 
>> 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".

>> 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:
> 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.

> 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

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Oct 2016 13:35:27 +0100

> On 26 Oct 2016, at 15:59, Paul Hoffman <[email-masked]> wrote:
> 
> 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”.

I’m fine with this re-wording. 

>>> 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 na…
<snip>
> 
> That would be good, yes. But "obtained" still sounds like it might come from the DNS itself, not from configuration or DHCP.

Well it could come from DNS via a SRV lookup. Do you prefer acquired/determine/derive?

>> 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).

OK - will change the title. 

Sara.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Oct 2016 07:06:54 -0700

On 27 Oct 2016, at 5:35, Sara Dickinson wrote:

>> That would be good, yes. But "obtained" still sounds like it might 
>> come from the DNS itself, not from configuration or DHCP.
>
> Well it could come from DNS via a SRV lookup.

How could it come from SRV? I am thinking (perhaps incorrectly) that it 
has to only come from configuration or DHCP.

> Do you prefer acquired/determine/derive?

No, because none of those sound like "gotten locally".

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 27 Oct 2016 07:37:45 -0700

On 27 Oct 2016, at 7:35, Sara Dickinson wrote:

>
>> On 27 Oct 2016, at 15:06, Paul Hoffman <[email-masked]> wrote:
>>
>> How could it come from SRV? I am thinking (perhaps incorrectly) that 
>> it has to only come from configuration or DHCP.
>
> Ah, in the case where the client only has the name configured I’m 
> thinking that there has to be a  look up to know which server the 
> domain name is valid for. So the name<-->IP mapping is what is 
> ‘obtained’ from the DNS. How about:
>
> * How a DNS client can obtain the combination of authentication domain 
> name and IP address for a DNS server.

Yes, that's good. "Obtain" makes more sense there. Thanks!

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Oct 2016 15:35:48 +0100

> How could it come from SRV? I am thinking (perhaps incorrectly) that it has to only come from configuration or DHCP.

Ah, in the case where the client only has the name configured I’m thinking that there has to be a  look up to know which server the domain name is valid for. So the name<-->IP mapping is what is ‘obtained’ from the DNS. How about: 

* How a DNS client can obtain the combination of authentication domain name and IP address for a DNS server.

Sara.