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

Sara Dickinson <sara@sinodun.com> Thu, 11 May 2017 12:15 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DC112EB8C; Thu, 11 May 2017 05:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik_2zvYdFYL4; Thu, 11 May 2017 05:15:23 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC4512EBB3; Thu, 11 May 2017 05:12:44 -0700 (PDT)
Received: from [2a02:8010:6126:0:bc7d:946c:833c:205e] (port=57075) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <sara@sinodun.com>) id 1d8mxV-0004Gq-Qh; Thu, 11 May 2017 13:12:42 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <149445288162.16739.870078352991642154.idtracker@ietfa.amsl.com>
Date: Thu, 11 May 2017 13:12:37 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-dtls-and-tls-profiles@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1EFFE62A-A7A1-4A7E-B19C-88A400F0618D@sinodun.com>
References: <149445288162.16739.870078352991642154.idtracker@ietfa.amsl.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/LRrXDacTr6a7yRq-xhn9WxjeMeU>
Subject: Re: [dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dtls-and-tls-profiles-09: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 May 2017 12:15:26 -0000

> On 10 May 2017, at 22:48, Ben Campbell <ben@nostrum.com> 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.

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

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

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

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

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

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