Hi Ben, Thanks for both your responses and for updating the DISCUSS!
Best regards Sara. > On 29 Jun 2020, at 17:47, Sara Dickinson <[email protected]> wrote: > > > >> 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
