Re: [dns-privacy] Barry Leiba's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

Sara Dickinson <sara@sinodun.com> Wed, 04 March 2020 13:31 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 0BE3A3A0F17; Wed, 4 Mar 2020 05:31:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
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 icG2c7eJVw3V; Wed, 4 Mar 2020 05:31:07 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B28E3A0F2C; Wed, 4 Mar 2020 05:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=lAOEShNVkq2ky04aNuL0lQV0bPTVIOyFVvV+JqAiwi0=; b=NL2bgLCWQeqyzWBeCe5mq/INFn 9JUZ2qLXmKOPag9I+YSe80p+3QSIJyLx/zRpD7FBjzBBXfdFtZIwNmZjuHp9qFHB4vfiUxuuPzUJt sVx05LHsQbeCvngS3y5AYq7Nz1X2fT4VdCfoZEdWo3v5wrsbkdjECmpNWBOq8Vp3zXlLxmkSyLgUi Tpp0vDuoZUB4qR2CrXTP8mgS8Hob2FNGrphWK+xWCLnYLPHzU/NUR8tSQd1gr2YT0/MWwo0d57cVK XjFY82oro5SYM+yaJ4XDEo39jIue/j27Dq/N+msVbErXoB5zEgmZyT1nAXtFQEmF5fRzpY1jaenhT izNDQpEw==;
Received: from [2001:b98:204:102:fffa::2] (port=63226) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1j9U73-0001Dt-Bo; Wed, 04 Mar 2020 13:31:05 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <158089142938.12762.6290507656137173098.idtracker@ietfa.amsl.com>
Date: Wed, 4 Mar 2020 13:31:00 +0000
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-bcp-op@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA73322A-65AC-4D2B-AAAF-701BED3AB7CE@sinodun.com>
References: <158089142938.12762.6290507656137173098.idtracker@ietfa.amsl.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Nr15z_Vji-hkEOTQ47kPmkGop7Y>
Subject: Re: [dns-privacy] Barry Leiba's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 04 Mar 2020 13:31:18 -0000


> On 5 Feb 2020, at 08:30, Barry Leiba via Datatracker <noreply@ietf.org> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-dprive-bcp-op-08: No Objection
> 
> 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-bcp-op/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Ben’s DISCUSS.
> 
> Other comments:
> 
> Throughout, “privacy-related” needs the hyphen, as it’s a compound modifier.
> 

Ack. 

> 
> — Section 1 —
> 
>   For example the user has a clear expectation of which
>   resolvers have visibility of their query data however this resolver/
>   transport selection may provide an added mechanism to track them as
>   they move across network environments.
> 
> This sentence needs some punctuation: certainty, a comma after “for example”,
> and probably one before “however”.  Even with those, it’s an awkward sentence
> and you might consider rephrasing it.

Will do. 

> 
>   It is an untested area that simply using a DNS
>   resolution service constitutes consent from the user for the operator
>   to process their query data.
> 
> NEW
>   Whether simply using a DNS resolution service constitutes consent
>   from the user for the operator to process their query data is as yet
>   untested.
> END

WFM.

> 
>   o  To introduce the DNS Recursive Operator Privacy (DROP) statement
>      and present a framework to assist writers of this document.
> 
> When I read this, I thought you meant *this* document, and that didn’t make
> sense.  You mean “that document”, or, better, “writers of a DROP statement.”

I like the last one :-)

> 
>      DROP statement is a document that an operator can publish
>      outlining their operational practices and commitments with regard
>      to privacy thereby providing a means for clients to evaluate the
>      privacy properties of a given DNS privacy service.
> 
> This needs at least a comma before “thereby”.  I might also change to “publish,
> which outlines ... privacy, and thereby provides a means”.

Agreed.

> 
> (At this point I’m going to stop calling out all but the most hard-to-follow
> editorial issues.)
> 
> — Section 2 —
> 
>   Whilst the issues raised here are targeted at those operators who
>   choose to offer a DNS privacy service, considerations for areas 2 and
>   3 could equally apply to operators who only offer DNS over
>   unencrypted transports but who would like to align with privacy best
>   practice.
> 
> If we’re considering encryption to be part of the best practice, this seems
> odd.  Maybe say “but who would otherwise like to align…”?

yup.

> 
> — Section 5.1.1 —
> 
>   o  DNS-over-TLS [RFC7858] and [RFC8310].
>   o  DoH [RFC8484].
> 
> There’s no reason to hyphenate the former, and the latter should also be
> expanded here:
> 
> NEW
>   o  DNS over TLS [RFC7858] and [RFC8310].
>   o  DNS over HTTPS [RFC8484].
> END
> 
> Similarly, take the hyphens out of “DNS over DTLS” in the next paragraph, and
> out of “DNS over TLS” throughout the document.

Depends which draft you look at :-( 
RFC7858 uses DNS-over-TLS, RFC8484 uses DNS over HTTPS, other drafts also hyphenate….

I happen to find the hyphenated form improves readability but can live with removing it (or using only the acronyms throughout) for consistency…..

> 
> — Section 5.1.3.2 —
> It’s “forgo” (give up), not “forego” (go before).
> 
> — Section 8 —
> For a document such as this, the Security Considerations sectiin seems very
> meagre.  As the Sec ADs have not called this out, I’ll presume they think it’s
> OK, and I won’t press the issue.  Perhaps all relevant information is already
> elsewhere in the document.

Since this draft is really collecting together a set of existing techniques I think the feeling was that the reference for each technique should cover the security issues… If there were any new issues from combining specific techniques then they should be called out here but I don’t remember any being raised. 

Best regards

Sara.