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

[Sara Dickinson <[e-mail]>]

> On 5 Feb 2020, at 08:30, Barry Leiba via Datatracker <[e-mail]> 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.