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 protected]> 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 protected]> 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 <[email protected]> > 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 > > [email protected] mailing lists by 2020-01-02. Exceptionally, comments > may > > be sent to [email protected] 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy > > -- Roland M. van Rijswijk-Deij > -- NLnet Labs > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
