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

[Ben Campbell <[e-mail]>]

> On May 11, 2017, at 7:12 AM, Sara Dickinson <[e-mail]> wrote:
> 
> 
>> On 10 May 2017, at 22:48, Ben Campbell <[e-mail]> wrote:
>> 
>> ----------------------------------------------------------------------
>> 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)? 
> 
> 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.

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

> 
>> 
>> 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.
> 
> 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”?

I think that would help.

> 
>> 
>> 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.)
> 
> You’re right it does seem inconsistent. It seems better to switch the MAY here to SHOULD?

That seems reasonable to me.

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

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


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. 

> 
>> 
>> 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?”
> 
> 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.”

Looks good to me.


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

Okay.

>> 
>> 11: Is "SHOULD consider implementing" different than "SHOULD implement”?
> 
> No, I don’t think so :-) Propose it is changed to “SHOULD implement”.

Looks good to me.

Thanks!

Ben.