> On 28 Jun 2020, at 01:10, Benjamin Kaduk via Datatracker <[email protected]> > wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dprive-bcp-op-10: 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: > ---------------------------------------------------------------------- > > Thank you for the updates, including those that resolve my Discuss points. > I do have several new comments on the -10.
Many thanks for the detailed review of -10. > > [note that I did not attempt to repeat comments made at > https://mailarchive.ietf.org/arch/msg/dns-privacy/bOK3mcSn-79wrAsawRQONBOZGGI/ > ] > > Section 1 > > Whilst protocols that encrypt DNS messages on the wire provide > protection against certain attacks, the resolver operator still has > (in principle) full visibility of the query data and transport > identifiers for each user. Therefore, a trust relationship exists. > > I commented previously about the strained nature of this conclusion, and > part of the response to that comment included a statement that "this > text is from the original RFC 7626". However, I don't see any sign of > this statement in RFC 7626 (and, per google, any other RFC), so perhaps > the reluctance to update at this stage is misplaced. You are quite right - my apologies - this text was in the very first draft of the BCP and is not in RFC7626! You previously proposed “Therefore, a trust relationship (whether explicit or implicit) is assumed to exist between each user and the operator of the resolver(s) used by that user.” which seems reasonable. Will update. > > Section 5.1.3.2 > > Is (HTTP/2, EDNS(0)) padding a privacy threat or a mitigation? Good catch - bullet added to the wrong list in -10! Fixed. > > Section 5.2.1 > > The following are recommendations relating to common activities for > DNS service operators and in all cases such activities should be > minimized or completely avoided if possible for DNS privacy services. > > Are the "such activities" that should be avoided the "common activities" > that we're giving recommendations for? Suggest: “and in all cases data retention should be minimized or completely avoided “ > > Section 5.2.4 > > nit: comma before "e.g." (as well as after) > > Section 5.3.1 > > operator is happy with. However some operators consider allowlisting > to incur significant operational overhead compared to dynamic > detection of ECS on authoritative servers. > > nit(?): is this "detection of ECS support”? Both fixed. > > Section 6.1.2 > > Should we mention the DoH URI template (if any) here, as well as the > address+port combos, DoT authentication domain name/SPKI/etc.? > > 2. Client facing capabilities. With reference to Section 5 provide > specific details of which capabilities are provided on which > client facing addresses and ports: > Is perhaps Section 5.1 a better reference than all of Section 5 here? I see the ambiguity (and the outdated section reference after a renumber). I think this should read: "With reference to each subsection of Section 5.1 provide specific details of which capabilities (transport, DNSSEC, padding, etc.) are provided on which client facing address/port combination or DoH URI template. For Section 5.1.2, clearly state which specific authentication mechanisms are supported for each endpoint that offers DoT: * The authentication domain name to be used (if any). * The SPKI pin sets to be used (if any) and policy for rolling keys.” IIRC the bullets were added just for clarity as none, one or both mechanisms might be used by a particular end point. > > Section 8 > > We should probably link to the security considerations sections of > DoT+DoH as well as RFC 7766. Arguably, those for DNSSEC as well. Yes - I’ll add. > > Section 12.1 > > It's not immediately clear that RFC 8404 needs to be a normative > reference (it's cited for the DNS Privacy Threat that "increased use of > encryption can impact [...] operator ability to monitor traffic" but > that's just an informative notice and does not really give specific > implementation advice to adhere to. > > Section 12.2 > > The way in which we cite RFC 7457 seems to be incorporating it by > reference, which would arguably make it a normative reference. > > RFC 7706 should also be normative, since we have a recommended behavior > for running root on loopback. > > Likewise we mandate/recommend behavior from RFCs 7871, 8020, 8198, and > 8490, making them normative. Done. > > Appendix A.2 > > o Section 8 of [RFC8484] outlines the privacy considerations of DoH. > Note that depending on the specifics of a DoH implementation there > may be increased identification and tracking compared to other DNS > transports. > > I would suggest noting that this document recommends against the use of > these mechanisms that might lead to increased identification/tracking. Done. > > Appendix B > > nit: s/Pseudoanonymization/Pseudonymization/ > > use of a format-preserving technique is essential. This, though, is > not cost-free - several authors (e.g., [Brenker-and-Arnes] have > observed that, as the entropy in an IPv4 address is limited, given a > de-identified log from a target, if an attacker is capable of > ensuring packets are captured by the target and the attacker can send > forged traffic with arbitrary source and destination addresses to > that target, any format-preserving pseudonymization is vulnerable to > an attack along the lines of a cryptographic chosen plaintext attack. > > nit(?): the way this is written ("given a de-identified log from a > target") makes it sound like the log is obtained first, and then > afterward (new) traffic with known addresses is generated (i.e., not in > the initial log), and somehow this allows for the deanonymization. My > understanding was that the known traffic needed to be part of the log > being deanonymized, i.e., the causality reversed from my above > description. Suggest: "This, though, is not cost-free - several authors (e.g., [Brenker-and-Arnes] have observed that, as the entropy in an IPv4 address is limited, if an attacker can * ensure packets are captured by the target and * send forged traffic with arbitrary source and destination addresses to that target and * obtain a de-identified log of said traffic from that target any format-preserving pseudonymization is vulnerable to an attack along the lines of a cryptographic chosen plaintext attack. > > Appendix B.1 > > o Filtering. Removing (and thus truncating) or replacing data in a > field. Field data can be overwritten, often with zeros, either > partially (grey marking) or completely (black marking). > > Is there a reference for grey/black marking? If they are not in common > use, perhaps there is not additional value from mentioning these names. The term 'black-marker anonymization’ is used throughout RFC6235 (which is the basis of this categorisation) and in other sources but I don’t see grey-marker used there and I’m struggling to remember where it came from… Re-reading RFC6235 I think ’truncation’ is more correct: "* Filtering. Removing or replacing data in a field. Field data can be overwritten, often with zeros, either partially (truncation or reverse truncation) or completely (black-marker anonymization)." and later in the section s/grey marking/truncation/ > Section D.1 > > There may be some privacy relevance to the precision of timestamp used > for the various (logging) operations, relating to (e.g.) recorrelation > with external datasets. > Suggest: OLD: + Absolute arrival time NEW: + Absolute arrival time using a precision of ms Thanks Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
