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

[Sara Dickinson]

> On 12 Mar 2018, at 10:31, Stephane Bortzmeyer  wrote:
> 
> On Tue, Mar 06, 2018 at 10:42:10AM +,
> Sara Dickinson  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:

Stephane, 

Many thanks for the review.

> 
>> 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.

Agreed. 

> 
>> 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”

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)?

> 
>> 3.1.  General capabilities
> 
> 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). 

> 
>> 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?

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

> 
>>  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).

Ack. 

> 
>> 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”).

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. 

> 
> (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?

I was thinking specifically about publication and rollover policy.

> 
>> 3.4.3.  TLSA records
> 
> We should just reference here RFC 7671. 

Very possibly. 

> 
>> 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 
> 
> Quad9 
> 
> OpenDNS Cannot find. An URL? The link on their page is just to
> , 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 

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

[Stephane Bortzmeyer]

On Tue, Mar 06, 2018 at 10:42:10AM +,
 Sara Dickinson  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 

Quad9 

OpenDNS Cannot find. An URL? The link on their page is just to
, 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?

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy