[dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-bcp-op-10: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Sun, 28 June 2020 00:10 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dns-privacy@ietf.org
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9053A087B; Sat, 27 Jun 2020 17:10:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dprive-bcp-op@ietf.org, dprive-chairs@ietf.org, dns-privacy@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159330300489.12320.18419359650411975029@ietfa.amsl.com>
Date: Sat, 27 Jun 2020 17:10:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/C3RjiO1qj1w5Mu1r2WZrXENTlV4>
Subject: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-bcp-op-10: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2020 00:10:06 -0000
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. [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. Section 5.1.3.2 Is (HTTP/2, EDNS(0)) padding a privacy threat or a mitigation? 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? 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"? 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? 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. 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. 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. 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. 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. 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.
- [dns-privacy] Benjamin Kaduk's No Objection on dr… Benjamin Kaduk via Datatracker
- Re: [dns-privacy] Benjamin Kaduk's No Objection o… Sara Dickinson
- Re: [dns-privacy] Benjamin Kaduk's No Objection o… Benjamin Kaduk
- Re: [dns-privacy] Benjamin Kaduk's No Objection o… Sara Dickinson