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

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 <
roland@nlnetlabs.nl> 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 <sayrer@GMAIL.COM> wrote:
> >
> > 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 <iesg-secretary@ietf.org>
> wrote:
> >
> > 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
> > last-call@ietf.org mailing lists by 2020-01-02. Exceptionally, comments
> may
> > be sent to iesg@ietf.org 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)
> >
> >
> >
> > _______________________________________________
> > dns-privacy mailing list
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> -- Roland M. van Rijswijk-Deij
> -- NLnet Labs
>
>