Subject: [dns-privacy] Last Call: <draft-ietf-dprive-bcp-op-07.txt> (Recommendations for DNS Privacy Service Operators) to Best Current Practice

From: The IESG <[email-masked]>
Date: Thu, 19 Dec 2019 06:31:58 -0800

The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'Recommendations for DNS Privacy Service
Operators'
  <draft-ietf-dprive-bcp-op-07.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-01-02. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document presents operational, policy and security
   considerations for DNS recursive resolver operators who choose to
   offer DNS Privacy services.  With these recommendations, the operator
   can make deliberate decisions regarding which services to provide,
   and how the decisions and alternatives impact the privacy of users.

   This document also presents a framework to assist writers of a DNS
   Recursive Operator Privacy Statement (analogous to DNS Security
   Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
   in RFC6841).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc8404: Effects of Pervasive Encryption on Operators (Informational - IETF stream)
    rfc8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0)) (Experimental - IETF stream)
    rfc7828: The edns-tcp-keepalive EDNS0 Option (Proposed Standard - IETF stream)
    rfc8484: DNS Queries over HTTPS (DoH) (Proposed Standard - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
    rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - IETF stream)
    rfc6265: HTTP State Management Mechanism (Proposed Standard - IETF stream)
    rfc8310: Usage Profiles for DNS over TLS and DNS over DTLS (Proposed Standard - IETF stream)
    rfc7626: DNS Privacy Considerations (Informational - IETF stream)
    rfc7830: The EDNS(0) Padding Option (Proposed Standard - IETF stream)
    rfc7873: Domain Name System (DNS) Cookies (Proposed Standard - IETF stream)
    rfc7858: Specification for DNS over Transport Layer Security (TLS) (Proposed Standard - IETF stream)
    rfc7871: Client Subnet in DNS Queries (Informational - IETF stream)
    draft-ietf-dprive-rfc7626-bis: DNS Privacy Considerations (None - IETF stream)
    rfc7816: DNS Query Name Minimisation to Improve Privacy (Experimental - IETF stream)

---

From: Rob Sayre <[email-masked]>
Date: Thu, 19 Dec 2019 12:15:30 -0800

Hi,

I found two issues with draft-07. The document mentions unattributed
"concerns" in a few places. That doesn't seem like helpful content, but I
can't say that such "concerns" and rampant use of the passive voice are
uncommon in today's IETF.

Secondly, I found the entire section "3.5.1.5.2.  DoH Specific
Considerations" to be objectionable, and recommend removing it. It mentions
many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and
contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow
extension fields and metadata, so there's nothing unique to DoH here
(source: I've implemented DoH and ESNI clients). The entire section amounts
to a description of fields that privacy conscious DoH clients /might/ send
if they were poorly implemented. But it seems strange to stop there.
Implementation quality ratholes can go on for a while: for example, the
document doesn't mention the numerous problems with today's TLS, PKI, and
BGP infrastructure that apply to both DoT and DoH.

thanks,
Rob

On Thu, Dec 19, 2019 at 6:32 AM The IESG <[email-masked]> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 19 Dec 2019 22:19:04 -0800

Hello,
>[email-masked] mailing lists by 2020-01-02. Exceptionally, comments may

There is the following statement in Section 1: "These open resolvers 
have tended to   be at the forefront of adoption of privacy related 
enhancements but it is anticipated that operators of other resolver 
services will follow".

The title of the draft states that it is about recommendations for 
DNS privacy service.  On reading the draft I struggled to understand 
what is a DNS privacy service.

In Section 1, the draft states that the impact of recent legislative 
changes on data pertaining to the users of both Internet Service 
Providers and public DNS resolvers is not fully understood.  It does 
not make sense for the IETF to publish policy guidance when there 
isn't an adequate understanding of the data protection implications.

The draft states that a desired operational impact is that all 
operators (both those providing resolvers within networks and those 
operating large public services) can demonstrate their commitment to 
user privacy thereby driving all DNS resolution services to a more 
equitable footing."  The statement comes out as being 
aspirational.  Is that the case?

The draft states that choices for users would (in this ideal world) 
be driven by other factors e.g. differing security policies or minor 
difference in operator policy rather than gross disparities in 
privacy concerns.  It is unaligned with reality to formulate a 
statement on an ideal world.

In Section 5.2.1, legal requirements is listed as a threat.  Did the 
authors assess the laws in different jurisdictions to support that conclusion?

Regards,
S. Moonesamy

---

From: Rob Sayre <[email-masked]>
Date: Fri, 20 Dec 2019 11:09:53 -0800

Hi,

Right you are: my comments were intended for
draft-ietf-dprive-rfc7626-bis-03. (also in last call).

Sorry for the confusion.

thanks,
Rob

On Fri, Dec 20, 2019 at 10:59 AM Roland van Rijswijk-Deij <
[email-masked]> wrote:

> Hi Rob,
>
> I'm responding on behalf of the authors of <draft-ietf-dprive-bcp-op-07>;
> we believe that your comments refer to another draft,
> <draft-ietf-dprive-rfc7626-bis-03>, since <draft-ietf-dprive-bcp-op-07>
> does not have a section 3.5.1.5.2, nor does it list the concerns you are
> referring to, whereas the other draft does.
>
> If this is correct, would you please confirm and post the feedback to the
> thread relating to the appropriate draft?
>
> Thank you in advance.
>
> Best regards, also on behalf of Sara, Allison and Benno,
>
> Roland
>
> > On 19 Dec 2019, at 21:15, Rob Sayre <[email-masked]> wrote:
> >
> -- Roland M. van Rijswijk-Deij
> -- NLnet Labs
>
>

---

From: Roland van Rijswijk-Deij <[email-masked]>
Date: Fri, 20 Dec 2019 19:59:35 +0100

Hi Rob,

I'm responding on behalf of the authors of <draft-ietf-dprive-bcp-op-07>; we believe that your comments refer to another draft, <draft-ietf-dprive-rfc7626-bis-03>, since <draft-ietf-dprive-bcp-op-07> does not have a section 3.5.1.5.2, nor does it list the concerns you are referring to, whereas the other draft does.

If this is correct, would you please confirm and post the feedback to the thread relating to the appropriate draft?

Thank you in advance.

Roland

> I found two issues with draft-07. The document mentions unattributed "concerns" in a few places. That doesn't seem like helpful content, but I can't say that such "concerns" and rampant use of the passive voice are uncommon in today's IETF. 
> 
> Secondly, I found the entire section "3.5.1.5.2.  DoH Specific Considerations" to be objectionable, and recommend removing it. It mentions many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and contrasts DoH with DoT in ways that are specious. Both TLS and HTTP allow extension fields and metadata, so there's nothing unique to DoH here (source: I've implemented DoH and ESNI clients). The entire section amounts to a description of fields that privacy conscious DoH clients /might/ send if they were poorly implemented. But it seems strange to stop there. Implementation quality ratholes can go on for a while: for example, the document doesn't mention the numerous problems with today's TLS, PKI, and BGP infrastructure that apply to both DoT and DoH.
> 
> thanks,
> Rob
> 
> 
> 
>