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

From: Sara Dickinson <[email-masked]>
Date: Tue, 6 Mar 2018 10:42:10 +0000

Hi All, 

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. 

Regards

Sara. 

From: [email-masked]
Subject: New Version Notification for draft-dickinson-bcp-op-00.txt
Date: 5 March 2018 at 19:57:06 GMT
To: "Sara Dickinson" <[email-masked]>, "Roland M. van Rijswijk-Deij" <[email-masked]>, "Allison Mankin" <[email-masked]>, "Roland van Rijswijk-Deij" <[email-masked]>

A new version of I-D, draft-dickinson-bcp-op-00.txt
has been successfully submitted by Sara Dickinson and posted to the
IETF repository.

Name:		draft-dickinson-bcp-op
Revision:	00
Title:		Recommendations for DNS Privacy Service Operators
Document date:	2018-03-05
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-dickinson-bcp-op-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dickinson-bcp-op/
Htmlized:       https://tools.ietf.org/html/draft-dickinson-bcp-op-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickinson-bcp-op-00

Abstract:
  This document presents operational, policy and security
  considerations for DNS operators who choose to offer DNS Privacy
  services including, but not limited to, DNS-over-TLS [RFC7858].

  This document also presents a framework to assist writers of DNS
  Privacy Policy and Practices Statements (analogous to DNS Security
  Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
  in [RFC6841]).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Mar 2018 11:31:15 +0100

On Tue, Mar 06, 2018 at 10:42:10AM +0000,
 Sara Dickinson <[email-masked]> 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?

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 12 Mar 2018 13:46:34 +0000

> On 12 Mar 2018, at 10:31, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Stephane, 

Many thanks for the review.

> make sense to mention it here.

Agreed. 

> probably misconfigured to be open”

Not sure, are you just suggesting we reference the terminology draft or we switch to using ‘public resolver’ (which strictly speaking isn’t defined there, just discussed)?

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

This section starts with “In addition to Sections 9 and 11.1 of [I-D.ietf-dprive-dtls-and-tls-profiles]"

and section 11.1 there says:

“DNS-over-(D)TLS clients and servers SHOULD implement the following
   relevant DNS extensions

   o  EDNS(0) padding [RFC7830],….

 Guidance on padding policies for EDNS(0) is provided in  [I-D.ietf-dprive-padding-policy] “

so I didn’t want to repeat it (also see below). 

> be a Tor entry node as well?

No, just a service offered via Tor. Maybe ‘endpoint’ is the confusion here and could be removed. 

> DNSSEC, or with NSEC3+optout).

Ack. 

> option "do not lie”).

Point taken on the mechanism. I’m also aware that there are points such as this in the document where there is overlap between what we might want _any_ DNS operator to do (on all transports and with all data) and what is specifically relevant to privacy servers. 

> publication ("operator MUST publish it on a HTTPS Web page")? Or both?

I was thinking specifically about publication and rollover policy.

> We should just reference here RFC 7671. 

Very possibly. 

> sharing, not even to claim "we don't share”).

Thanks for these suggestions, they look reasonable. I ran out of time before the submission deadline but was planning a table to compare these and any others if there are other suggestions of good or bad examples? 

> compliance, etc.”

dkg’s talk at the DNS Privacy workshop gave me food for thought on the whole topic of ‘trustworthiness’ which I think could be expanded on here (technical vs social vs third-party). 

> Otherwise, do we recommend or not things like TLS chain extension and

TLS raw key support is a MUST in section 9 of draft-ietf-dprive-dtls-and-tls-profiles, the Security Considerations section there also says 

“DNS Clients SHOULD implement support for the mechanisms described in
Section 8.2 and offering a configuration option which limits
authentication to using only those mechanisms (i.e., with no fallback
to pure PKIX based authentication) such that authenticating solely
via the PKIX infrastructure can be avoided."

Where section 8.2 is DANE (including TLS chain extension). 

I’m somewhat torn… I want to avoid duplication but maybe it is clearer start section 3 with a section purely to summarise the specific cases already covered in draft-ietf-dprive-dtls-and-tls-profiles? 

Sara.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Mar 2018 16:38:46 +0100

On Mon, Mar 12, 2018 at 01:46:34PM +0000,
 Sara Dickinson <[email-masked]> wrote 
 a message of 192 lines which said:

> Not sure, are you just suggesting we reference the terminology draft
> or we switch to using ‘public resolver’ (which strictly speaking
> isn’t defined there, just discussed)?

I suggest we use "public resolver", keeping "open resolver" for the
accidental ones. It seems well adopted.

> confusion here and could be removed.

I still don't understand exactly what the DNS-privacy public resolver
must offer here.