> On 6 Feb 2020, at 05:04, Adam Roach via Datatracker <[email protected]> wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-dprive-bcp-op-08: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dprive-bcp-op/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to the document authors, as well as everyone else who > contributed to this document for all the work that went into > its creation. I have a handful of editorial suggestions that > you may wish to take into account prior to publication. (I also > have one request and one question in the list below.) > > I also support the first point of Alissa's discuss, and have > elided several comments about Section 5.1.7 from my review > below with the expectation that it will be removed. > > --------------------------------------------------------------------------- > > §1: > >> Community insight [or judgment?] about operational practices can >> change quickly, and experience shows that a Best Current Practice >> (BCP) document about privacy and security is a point-in-time >> statement. Readers are advised to seek out any errata or updates >> that apply to this document. > > RFC Errata are intended only to correct documents to reflect what > the community believed they should have said at the time of publication > (e.g., typographic errors, omissions in state machines), and not to > provide updates to reflect later thinking. Please remove "errata or" > from this sentence.
Agreed. > > --------------------------------------------------------------------------- > > §5.1.1: > >> o DNS-over-TLS [RFC7858] and [RFC8310]. >> >> o DoH [RFC8484]. > > Nit: For the sake of consistency, I would recommend either contracting > both of these (e.g., "DoT" and "DoH"), or expanding them both. > > This same comment applies to the prose in section 5.1.2, as well > as the titles of 5.1.3.1 and 5.1.3.2. Picked up by others - will make consistent throughout. > > --------------------------------------------------------------------------- > > §5.1.2.1: > >> o Mis-identification of a server by a client e.g. typos in URLs or >> authentication domain names [RFC8310]. > > It's a bit unclear which kind of URLs this is referring to. Based on the > proposed mitigation, I suspect it's talking about the use of URLs to > configure a DNS server? Consider clarifying the URL's purpose in this > text. s/URLs/DoH URI templates/ ? > > --------------------------------------------------------------------------- > > §5.1.3.2: > > The use of EDNS(0) padding is conspicuous by its absence from this > section. Is this intentional? I think it arises because EDNS(0) padding wasn’t defined when RFC7858 (DoT) was published, it was defined in a later RFC. However RFC8484 (DoH) includes a discussion of HTTP padding and also includes the statement “ DoH servers can also add DNS padding [RFC7830] if the DoH client requests it in the DNS query. An experimental effort to offer guidance on choosing the padding length can be found in [RFC8467].” so this text was just calling out mitigations not directly mentioned in RFC8484. How about adding a bullet: * Use of HTTP/2 padding and/or EDNS(0) padding as described in Section 9 of RFC8484 > > --------------------------------------------------------------------------- > > §5.1.4: > >> DNS Privacy Threats: >> >> o Users may be directed to bogus IP addresses for e.g. websites >> where they might reveal personal information to attackers. > > You might want to consider a different example than websites here. 80% of > worldwide website traffic is secured by HTTPS, which means than any such > attempts will be prevented by WebPKI certificate mismatches. > > Notably, this means that the mitigation proposed is of diminished value > for DNS servers that are used primarily or exclusively for resolving > web server addresses, and the calculus of whether the overhead of > implementing DNSSEC in such servers is worth the value it provides may > vary radically from that which applies to general-purpose name resolvers. There were multiple follow ups to this comment on and off list (thanks to all who contributed), so am suggesting new text here that might be acceptable based on that: * Users may be directed to bogus IP addresses which, depending on the application, protocol and authentication method, might lead users to reveal personal information to attackers. One example is a website that doesn't use TLS or its TLS authentication can somehow be subverted." > Given the fairly absolute language in the current mitigation section > (only three mitigations use something as strong as "must"), it is > probably worthwhile adding some text that acknowledges that the value > of this mitigation varies depending on the applications that use the > DNS service. The intention of the first section of section 5 is to outline that all mitigations are roughly equal in importance. I’m happy to replace any instance of a lower case must to avoid the interpretation of more emphasis beyond that. I’ll switch this one to ’need to’ and check the others. > > --------------------------------------------------------------------------- > > §6.1.1: > >> 4. Associated entities. Declare any partners, third-party >> affiliations, or sources of funding. > > Having looked at a number of such disclosures recently, I've noticed > that it has become fashionable to make such disclosures in the form > of "<Corporation> may share information about our customers among > the <corporation> family of companies," while eliding information > that, for example, one such company is a user-tracking-based > advertising network. > > So, if we're making suggestions for ideal policies, I might suggest > something a bit more explicit, like: > > 4. Associated entities. Declare and explicitly enumerate any > partners, third-party affiliations, or sources of funding. WFM. > > --------------------------------------------------------------------------- > > §B.2: > >> Since 2006, PowerDNS have included a de-identification tool >> Appendix B.2 with their PowerDNS product. > > There appears to be a spurious "Appendix B.2" on the second line of > this paragraph. The tool is described in Appendix B.2 so this is actually a reference, will clarify. Best regards Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
