Re: [dns-privacy] Fwd: New Version Notification for draft-dickinson-bcp-op-00.txt

[Stephane Bortzmeyer <[e-mail]>]

On Tue, Mar 06, 2018 at 10:42:10AM +0000,
 Sara Dickinson <[e-mail]> wrote 
 a message of 198 lines which said:

> There is a new draft (very much a placeholder at the moment) that
> attempts to start the discussion around Best Practices for Operators
> of DNS Privacy Services. It is submitted here for initial review and
> for feedback on the best forum for future versions of this
> document.

I've read  draft-dickinson-bcp-op-00. No strong opinion on the best
forum to discuss it so, in the mean time:

> Other documents that provide further specifications related to DNS
> privacy include [I-D.ietf-dprive-dtls-and-tls-profiles], [RFC7830]
> and [I-D.ietf-dprive-padding-policy].

RFC 7816 is mentioned later but it comes out of the blue, it would
make sense to mention it here.

> In recent years there has been an increase in the availability of
> "open" resolvers.

"Public resolvers" draft-ietf-dnsop-terminology-bis-08: "the term
"public resolver" is used more with open resolvers that are meant to
be open, as compared to the vast majority of open resolvers that are
probably misconfigured to be open"

> 3.1.  General capabilities

Padding (RFC 7830) is not mentioned here (it should).

> A .onion [RFC7686] service endpoint

I don't understand. You mean a public privacy-wise DNS resolver should
be a Tor entry node as well?

>   o  Aggressive Use of DNSSEC-Validated Cache [RFC8198] to reduce the
>      number of queries to authoritative servers to increase privacy.

And NXDOMAIN cut (RFC 8020) as well (specially for the domains without
DNSSEC, or with NSEC3+optout).

> Should we say anything here about filtering responses or DNSSEC
> validation e.g. operators SHOULD provide an unfiltered service on an
> alternative IP address

I would rephrase it as "operators who filters responses SHOULD also
provide an unfiltered service", without mentioning "alternative IP
address", because other means are possible (such as a future EDNS
option "do not lie").

(There is also the possibility of whitelisting *client* IP addresses,
like Cisco OpenDNS does but it is obviously bad for privacy.)

> 3.4.2.  Management of SPKI pins

Is it about generation, security of the private part, or about
publication ("operator MUST publish it on a HTTPS Web page")? Or both?

> 3.4.3.  TLSA records

We should just reference here RFC 7671. 

> 4.2.  Anycast deployments

"Anycast deployments is possible and useful, but we draw the attention
of operators on the fact that it means that, sometimes, IP packets
will come in for an unknown TCP connection, or in an unknown DTLS
session. The service MUST reply with the appropriate message (RST for
TCP) and MUST NOT silently drop such IP packets. They are not
malicious, and are normal for an anycast service."

> 5.  Server data handling

After the paragraph on data retention. "One possibility is to have two
(or more) sets of data, one with a lot of data, but a very short
retention period, intended for daily operations, and one with a longer
retention period, but with less data (source IP addresses shortened,
for instance), intended for analytics."

> TODO: Compare main elements of Google vs Quad9 vs OpenDNS policies

Google <https://developers.google.com/speed/public-dns/privacy>

Quad9 <https://quad9.net/privacy/>

OpenDNS Cannot find. An URL? The link on their page is just to
<https://www.cisco.com/c/en/us/about/legal/privacy-full.html>, a
general Cisco privacy policy, nothing about DNS.

Google policy and Quad9 policy are very close, to the point where I
suspect copy-and-paste. Google is more detailed on the retention
duration (and they have a temporary/permanent split), Quad9 is more
detailed about the sharing (Google apparently does not talk about
sharing, not even to claim "we don't share").

> 8.  Security considerations

Add "There are no _technical_ means for the user of a privacy-enabled
DNS resolver to check if the operator follows its published
policy. The user must therefore perform his or her assessment, based
on knowledge of the operator, legal or social means to enforce
compliance, etc."




Otherwise, do we recommend or not things like TLS chain extension and
TLS raw keys?