Subject: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 10 May 2017 14:48:01 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dprive-dtls-and-tls-profiles-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting "yes", but I do have some comments:

Substantive:

5: "Clients using Opportunistic Privacy SHOULD try for the best
case..."
When might it be reasonable _not_ to try for the best case? (That is, why
not MUST)? 

5.1: What's a reasonable granularity for the profile selection? The text
suggests that decision is on a per-query basis; is that the intent? I
assume you don't expect a user to make a decision for each query.

6.5: The statement that a client using OP "MAY" try to authenticate seems
inconsistent with the "SHOULD try for the best case" statement in S5.
(But seem my comment above about that.)

13.2: [I-D.ietf-dprive-dnsodtls] is referenced using 2119 keywords, so it
should be a normative reference. (Note that this would be a downref.)

Editorial:

2: "MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS-
over-DTLS [I-D.ietf-dprive-dnsodtls]."
Unless these are new-to-this-draft requirements, please use descriptive
(non-2119) language. (Especially in a definition).

5: "Strict Privacy provides the strongest privacy guarantees and
   therefore SHOULD always be implemented in DNS clients along with
   Opportunistic Privacy."

Does that mean "SHOULD implement both strict and opportunistic privacy"
or "If you implement opportunistic you SHOULD also implement strict?"

 6.2: Should list item "2" be "ADN+IP", like in the table?

11: Is "SHOULD consider implementing" different than "SHOULD implement"?
If so, please consider dropping the 2119 "SHOULD" when talking about what
people think about.

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 11 May 2017 13:12:37 +0100

> On 10 May 2017, at 22:48, Ben Campbell <[email-masked]> wrote:
> 

If latency is a greater concern than privacy. For example if a client has 5 Privacy servers configured a MUST would require it to attempt to obtain an authenticated, encrypted connection to all 5 before falling back to using an unauthenticated, encrypted connection to the first one. There is some text on this in Appendix A.

> assume you don't expect a user to make a decision for each query.

No, it is expected that the client sets the desired Profile and uses it for all queries until that setting is changed.  The intent of this text was to clarify that the granularity should not be less than query level.  Maybe it would help to add some text “It is anticipated that clients will use a particular Usage Profile for all queries until an operational issue or policy update dictates a change in the profile used”?

> (But seem my comment above about that.)

You’re right it does seem inconsistent. It seems better to switch the MAY here to SHOULD?

> should be a normative reference. (Note that this would be a downref.)

It was caught in another review that this document is now an RFC.

> (non-2119) language. (Especially in a definition).

The definition of a Privacy-enabling DNS Server is new to this draft which is why it seemed correct to use those terms. Do you think it would be better to move that description/definition to the introduction?

> or "If you implement opportunistic you SHOULD also implement strict?”

Good question. The second one. Replace with:

“ Strict Privacy provides the strongest privacy guarantees and
   therefore SHOULD always be implemented in DNS clients that implement
   Opportunistic Privacy."

> 6.2: Should list item "2" be "ADN+IP", like in the table?

 The 'Short name’ in used in the listing, the one given in the last column of the table. 

> 
> 11: Is "SHOULD consider implementing" different than "SHOULD implement”?

No, I don’t think so :-) Propose it is changed to “SHOULD implement”.

Regards

Sara.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 May 2017 09:05:34 -0500

> On May 11, 2017, at 7:12 AM, Sara Dickinson <[email-masked]> wrote:
> 
> 

Thanks, that helps. A few words about that near the SHOULD would be helpful.

> No, it is expected that the client sets the desired Profile and uses it for all queries until that setting is changed.  The intent of this text was to clarify that the granularity should not be les…

I think that would help.

> You’re right it does seem inconsistent. It seems better to switch the MAY here to SHOULD?

That seems reasonable to me.

> It was caught in another review that this document is now an RFC.

I’m not sure that changes my comment. It still needs to be a normative reference, and I assume the RFC is still experimental?

> The definition of a Privacy-enabling DNS Server is new to this draft which is why it seemed correct to use those terms. Do you think it would be better to move that description/definition to the in…

I would suggest leaving it where it is, but making a change along the following lines “A DNS server that implements DNS-over-TLS and may optionally implement DNS-over-DTLS.”, and state the normative bits elsewhere. 

>   Opportunistic Privacy.”

Looks good to me.

> The 'Short name’ in used in the listing, the one given in the last column of the table. 

Okay.

> No, I don’t think so :-) Propose it is changed to “SHOULD implement”.

Looks good to me.

Thanks!

Ben.