Last Call Review of draft-ietf-dprive-bcp-op-07
review-ietf-dprive-bcp-op-07-genart-lc-sethi-2019-12-29-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dprive-bcp-op-07
Reviewer: Mohit Sethi
Review Date: 2019-12-29
IETF LC End Date: 2020-01-02
IESG Telechat date: Not scheduled for a telechat

Summary:
This draft discusses privacy challenges for recursive DNS resolvers. It then
describes policy and security considerations that DNS service providers can use
for enhanced user privacy. The draft is 'On the Right Track' but not yet ready.

Major issues:

I wonder if section 5.1.2.1/5.1.3.1 should also talk about recommending OCSP
stapling (RFC 6066)? I looked at RFC 8310 and it mentions RFC 7525. Do you want
to mention it here in section 5.1.2.1/5.1.3.1?

In section 5.1.2.1, what is meant by 'authentication domain names'? Later, the
text says 'authentication name for the service'. I guess you are implying the
authentic domain name of the DNS resolver service that the client software
should verify through the common name (CN) in the certificate? Some more
explanation here would be beneficial.

In section 5.1.4, should 'DNS Roadblock avoidance' be 'DNSSEC Roadblock
avoidance'? And please add a reference to RFC 8027 here if that is the case.

Section 5.1.7 says "discussion on the use of Bloom Filters in Appendix A". It
is pointing to the wrong appendix. Also, this section talks about implementing
traffic monitoring by the DNS service provider. I would argue that in most
deployments, the traffic monitoring is required (and implemented) by a
different entity. Think of a home network router that has a parental control.
Or an enterprise restricting employees from visiting certain sites (to prevent
insider attacks)? The impact of encryption is more serious for them and less so
for a DNS service provider. What is the BCP advice for them? Also, is it fair
to say that this is a best current practice? It feels that we need more
experience before we start recommending it as an optimization.

This comment applies to all 5.1.1-5.1.8. Each subsection starts rather abruptly
by discussing threats. It would be nice if you add a sentence at the beginning
of each sub-section telling the reader what are they heading into. This is
probably most obvious from section 5.1.8. Without even telling the reader what
is a pure TLS proxy, you start listing the DNS privacy threats. Only later on
you mention option that operators may implement DNS-over-TLS using a TLS proxy.

In section 5.3.2 'way and OUGHT obfuscate'. OUGHT is not part of RFC 2119/8174.
Why is it capitalized? And, 'ought' ought to be followed by a 'to'.

At the beginning of section 5, you describe three classes of actions. However,
none of the subsections contain clear "Additional options" that operators need
to follow for "maximal compliance"?

The document seems focused on TLS 1.2 (and does not talk about TLS 1.3). In
fact, RFC 8446 is not even in the list of references even though section
5.1.3.1 mentions it. Similarly, Appendix A.2 mentions TLS session resumption
without server-side state. How about servers using TLS 1.3 and PSK resumption?
RFC 8446 has text on client tracking in appendix C.4:
https://tools.ietf.org/html/rfc8446#appendix-C.4.

There is something wrong about the last sentence of Appendix A.2 'Note that
depending on the specifics of the implementation [RFC8484] may also provide
increased tracking'. You already mention RFC 8484 in Appendix A.1 as a means to
increase privacy. Perhaps you wanted to cite a different RFC here?

Minor issues:

Nits/editorial comments:

There is mixed usage of Anonymisation (in Table 1) vs Anonymization. The same
with Pseudoanonymisation (in Table 1) vs pseudonymization in text. Please check
with the RFC editor on what is expected and use that consistently. Also noticed
optimisation.

In Table 1, Crytpographic should be Cryptographic.

Maybe you could use an Oxford comma when using lists of items.

In section 5.1.2.1, there is stray space character at the end of the bullet on
"Follow the guidance in Section 6.5 of [RFC7525] with regards to certificate
revocation ."

Perhaps expand DNSSEC on first usage: Domain Name System Security Extensions
(DNSSEC).

In section 5.1.6 'in terms of such options as filtering' should instead be 'in
terms of options such as filtering'.

In section 5.1.8 'a DNS aware proxy such as [dnsdist] which offer custom
(similar to that proposed in'. Consider using 'offers' instead of 'offer' and
'similar to those proposed in' instead of 'similar to that proposed in'.

In section 5.2.2 'presents and overview' should be 'presents an overview'.
Consider rephrasing 'the better to resist brute force'. Also, in 'agreed
solution or any Standards to inform', why is standards capitalized?

In section 5.2.4 'queries on multiple TCP session' should be 'queries on
multiple TCP sessions'. Please expand CPE on first usage.

In section 6.3 'This is by analogy with e.g. several TLS or website' could
instead be 'This is analogous to several TLS or website'.

In Appendix A.1 'documents apply to recursive to authoritative DNS' shouldn't
there be an 'and'?

In Appendix C.1, consider changing the format for the sub bullets of '2.  Data
collection and sharing.'. Instead of numbering them with 1/2/3, perhaps use
a/b/c.

In Appendix C.1 'of use of system' could be 'of system use'. Also why is there
a line break between 'items that are' and 'included'? There is an extraneous
'the' in 'available with the our threat intelligence'. Consider re-wording
parts of paragraph '3. Sharing of data. '. At one place you say 'with our
threat intelligence partners' and a few words later you say 'with its threat
intelligence partners'.

In Appendix C.1 'In the event of events or observed behaviors' is a bit hard to
parse. Consider rephrasing the 'event of events' part.