Benjamin Kaduk has entered the following ballot position for draft-ietf-dprive-bcp-op-08: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [updated to add one discuss point and a comment section] This document is trying to make normative references to sections of draft-ietf-dprive-rfc7626-bis that have not existed since the -00 of that document, with the content having been removed for being too controversial. Do we need to delay processing this document until 7626bis has settled down and it is clear what content we can refer to in that vs. needing to incorporate into this document? (It's unclear that such content would be less controversial in this document than in that one.) Specifically, Section 5.1.2 of this document refers to Section 2.5.3 of that document ("Rogue Servers"). [new discuss point] This is perhaps more a flaw in RFC 8310 than in this document, but I'd still like to discuss it: in Section 5.1.2 we read that: When using DNS-over-TLS clients that select a 'Strict Privacy' usage profile [RFC8310] (to mitigate the threat of active attack on the client) require the ability to authenticate the DNS server. To enable this, DNS privacy services that offer DNS-over-TLS should provide credentials in the form of either X.509 certificates [RFC5280] or Subject Public Key Info (SPKI) pin sets [RFC8310]. Authenticating the DoT server via X.509 certificate as described here and in RFC 8310 seesm to involve looking for an ADN in the certificate; however, I could not find any discussion of how to know what CA(s) or trust anchors to trust to certify the ADN in a certificate. It's possible that RFC 8310's use of "PKIX Certificate" is supposed to imply that Web PKI trust anchors are used, but that's not immediately clear. It may be the case that we need to mention provisioning a trust anchor as well as the X.509 certificate information, here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The organizational structure of (the subsections of) Section 5 is pretty confusing to me -- though we talk about having the two classes of threats and the three classes of actions, those are used mostly for structure within a given section, and the ordering and headings of the (sub)sections themselves seem somewhat arbitrary. We don't seem to try to align with the organization of RFC 6973 or some other structure, so this ends up coming across to me as something of a jumbled list of scenarios and recommendations. I guess I'm not quite the target audience, though, so salt as needed. In general it's better to reference RFC 7525 as BCP 195 than just the RFC number. Section 1 In recent years there has also been an increase in the availability of "public resolvers" [RFC8499] which users may prefer to use instead of the default network resolver because they offer a specific feature (e.g. good reachability, encrypted transport, strong privacy policy, filtering (or lack of), etc.). These open resolvers have tended to be at the forefront of adoption of privacy related enhancements but it is anticipated that operators of other resolver services will follow. I'm wary of suggesting changes at this late stage, but it seems to me that users may also prefer a public resolver when there is not good information available about the local network-provided resolver. In some sense this is not exactly a "feature" of the public resolver but rather an "anti-feature" of the alternative. 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. (side note; this should have been a WGLC comment but is probably too late to make now: this conclusion seems a bit strained, and I might say instead "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".) It should also be noted that the choice of a user to configure a single resolver (or a fixed set of resolvers) and an encrypted transport to use in all network environments has both advantages and disadvantages. For example the user has a clear expectation of which resolvers have visibility of their query data however this resolver/ transport selection may provide an added mechanism to track them as they move across network environments. Commitments from operators to nits: comma after "For example" and some punctuation before and after "however". minimize such tracking are also likely to play a role in user selection of resolvers. I'm not entirely sure what this is intended to convey. If a user is to use a fixed resolver for *all* their network environments, wouldn't the user need such a commitment from *all* the corresponding network operators in order to feel comfortable with the selection of resolver? o To introduce the DNS Recursive Operator Privacy (DROP) statement and present a framework to assist writers of this document. A DROP statement is a document that an operator can publish (side note: I get that the acronym is cute, but it seems pretty clear that the binding is "(DNS Recursive Operator) (Privacy Statement)" so the acronym in a grammatical sense is misbound.) outlining their operational practices and commitments with regard to privacy thereby providing a means for clients to evaluate the privacy properties of a given DNS privacy service. In particular, nit: *claimed* privacy properties. (Absent an enforcement mechanism to ensure that the actual practices match the documentation, as Section 6.3 alludes to.) A desired operational impact is that all operators (both those providing resolvers within networks and those operating large public services) can demonstrate their commitment to user privacy thereby driving all DNS resolution services to a more equitable footing. side note: I'm having trouble explaining exactly why, but "more equitable" sticks out at me, here. It seems like maybe the intent is "to remove an unneeded axis of variation among DNS resolution services"? Choices for users would (in this ideal world) be driven by other factors e.g. differing security policies or minor difference in operator policy rather than gross disparities in privacy concerns. nit: commas before and after "e.g.", and comma before "rather". Section 3 I'm not even sure that classifying as "increase"/"decrease" is accruate; my take would be that the protocol changes present a different profile of privacy-related properties that can increase or decrease privacy on many different axes simultaneously. Section 4 DNS terminology is as described in [RFC8499] with one modification: we restate the clause in the original definition of Privacy-enabling DNS server in [RFC8310] to include the requirement that a DNS over (D)TLS server should also offer at least one of the credentials described in Section 8 of [RFC8310] and implement the (D)TLS profile described in Section 9 of [RFC8310]. Just to check: this text is saying that we use the 8310 definition and not the 8499 definition, right? (Not that we're adding on top of the 8310 definition?) Section 5 In general I would have appreciated a bit more exposition about what the threats entail and why they are threats -- the current formulation with one-liners basically assumes that the reader already knows why this is a threat. We describe two classes of threats: (side note: it might be an interesting exercise to analyze the "DNS Privacy Threats" to see which of them actually just reflect omissions in the 6973 prifacy model vs. DNS-specific threats) This document does not specify policy - only best practice, however for DNS Privacy services to be considered compliant with these best practice guidelines they SHOULD implement (where appropriate) all: This normative "SHOULD" feels weird, as it in some sense is giving me license to claim compliance when I do none of the listed things ("because it's only a 'SHOULD'"). Perhaps just saying that we define the three levels of compliance (with no normative language) is enough. Section 5.1.1 * Passive surveillance of traffic on the wire [I-D.ietf-dprive-rfc7626-bis] Section 2.4.2. nit: this is currently Section 3.4.2. It is also noted that DNS privacy service might be provided over IPSec, DNSCrypt, or VPNs. However, use of these transports for DNS are not standardized and any discussion of best practice for providing such a service is out of scope for this document. I don't think it's quite correct to say that usage of IPsec to provide transport for DNS is "not standardized": you merely configure IPsec to protect communications to the IP address(es) that you configure as your resolver, and gain the protection of IPsec. No DNS-layer protocol or configuration changes are needed, though you do tend to need some kind of prior configuration/agreement with the DNS server. Section 5.1.2.1 It is noted that SPKI pin set management is described in [RFC7858] but that key pinning mechanisms in general have fallen out of favor operationally for various reasons such as the logistical overhead of rolling keys. If SPKI pin sets have fallen out of favor, why do we still list it as an option in the previous section? DNS Privacy Threats: o Invalid certificates, resulting in an unavailable service. o Mis-identification of a server by a client e.g. typos in URLs or authentication domain names [RFC8310]. I'm not sure I understand how either of these is a "DNS Privacy threat". How does a certificate spontaneously become an "invalid certificate" other than by expiration or revocation? How does a user mistyping a domain name result in a privacy threat? Section 5.1.3.1 DNS Privacy Threats: o Known attacks on TLS such as those described in [RFC7457]. The RFC 7457 attacks are pretty well-known and -mitigated at this point, and they also don't particularly seem to be DNS-specific. I'm not sure how much value would be lost if we removed this bullet point. In the case of DNS-over-TLS, TLS profiles from Section 9 and the Countermeasures to DNS Traffic Analysis from section 11.1 of [RFC8310] provide strong mitigations. This includes but is not nit: I suggest adding the [RFC8310] reference for "Section 9" as well as "Section 11.1" to avoid confusion (especially by the htmlization script used by tools.ietf.org). Interestingly, Section 9 of RFC 8310 recomments using (at that point, TLS 1.2) stateless session tickets, which themselves have privacy flaws by virtue of allowing an attacker to correlate ticket issuance and use for TLS resumption. (TLS 1.3 tickets do not have this flaw in the recommended usage.) o A DNS-over-TLS privacy service on both port 853 and 443. This practice may not be possible if e.g. the operator deploys DoH on the same IP address. but is possible with the recently-allocated "dot" ALPN value: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids Section 5.1.3.2 [same comment about RFC 7457] o Potential for client tracking via transport identifiers. Just to check: this is a single (fixed) DoH server tracking a moveable client as the client contacts that server from multiple network addresses? Specifically, it is not claiming that transport identifiers allow the client to be tracked by an attacker "in the network"? Section 5.1.4 Do we need to say anything about algorithm support (e.g., staying up to date on them) or (root) key rolls, or refer to some other document thereto? DNS Privacy Threats: o Users may be directed to bogus IP addresses for e.g. websites where they might reveal personal information to attackers. This is just "if the clients get bogus DNS responses bad things happen", right? I'm not sure that this phrasing conveys the origin of the threat very well. Section 5.1.7 when traffic between clients and resolvers is encrypted. There are, however, legitimate reasons for DNS privacy service operators to inspect DNS traffic, e.g. to monitor for network security threats. "Legitimate" is basically a subjective assessment and that assessment may well change over time and depending on who you ask. As this is somewhat buried in the middle of the document it's hard to have high confidence that there is IETF consensus in this assessment. Would you be open to an alternate phrasing such as "Many DNS privacy service operators still have need to inspect DNS traffic" that is clear this is a thing commonly done, and done by operators aware of privacy considerations for DNS operation, without implying that it will be so indefinitely? Section 5.1.8 o Misconfiguration of the target server could lead to data leakage if the proxy to target server path is not encrypted. I'm not sure I understand the path from misconfiguration to leakage, here -- to be clear, we're talking about misconfiguration of the (stock) DNS server that's behind the TLS proxy? What path does the leakage occur on? Section 5.2.1 The following are common activities for DNS service operators and in all cases should be minimized or completely avoided if possible for DNS privacy services. If data is retained it should be encrypted and either aggregated, pseudonymized, or anonymized whenever possible. In general the principle of data minimization described in [RFC6973] should be applied. nit: the following list is a list of recommendations, not a list of common activities as the first sentence would have us believe. o DNS privacy services should not track users except for the particular purpose of detecting and remedying technically malicious (e.g. DoS) or anomalous use of the service. I have mixed feelings about endorsing the tracking of mere "anomalous use" (though I recognize that it's an operational reality for threat detection), given that a lot of what human researchers may be doing will end up classified as "anomalous". o Data access should be minimized to only those personnel who require access to perform operational duties. It should also be limited to anonymized or pseudonymized data were operationally feasible, with access to full logs (if any are held) only permitted when necessary. nit: "were" should be eiher "where" or "when". Section 5.2.3 I suggest adding the note "Legend of techniques:" to the caption of Table 1, to clarify that those are what are being compared, and the row names are the attributes in question. Section 5.2.4 o Fingerprinting of the client application or TLS library by e.g. TLS version/Cipher suite combinations or other connection parameters. (TLS Extensions are also a good fingerprinting mechanism, though there's not a particular need to mention them, specifically.) o HTTP headers (e.g., User-Agent, Accept, Accept-Encoding). nit: is there a reason to not classify these as "Fingerprinting" mechanisms akin to the first two bullet points? Section 5.3.1 Optimizations: o The server should either: * not use the ECS option in upstream queries at all, or * offer alternative services, one that sends ECS and one that does not. I'm not sure I understand the apparent recommendation to prefer no ECS at all to ECS with a limited prefix length. Is there a pointer handy to the WG discussions? If operators do offer a service that sends the ECS options upstream they should use the shortest prefix that is operationally feasible and ideally use a policy of whitelisting upstream servers to send ECS to in order to minimize data leakage. Operators should make clear in any policy statement what prefix length they actually send and the specific policy used. I'll note that whitelisting is still subject to attack in the face of an RFC 3552 attacker unless the recursive/authoritative path is also secured and the authoritative authenticated (whether by DNSSEC on the responses or a transport-layer mechanism); this is probably worth discussion a little bit. Section 5.3.3 Operators should consider including specific guidelines for the collection of aggregated and/or anonymized data for research nit: is this "including in a DROP statement"? Section 6.1.2 1. Deviations. Specify any temporary or permanent deviations from the policy for operational reasons. Is it common for the folks doing the actual operational decision-making to have to document it like this (versus this being a super-aspirational "requirement" that's unlikely to be achieved in practice)? 1. For DoT, specify the authentication domain name to be used (if any). Is it assumed that the client will already have (and know) a PKI trust anchor (set) to use to validate the ADN? Section 9 s/John Reed/Jon Reed/ ("for comments at the mic", I know, so spelling is ambiguous...) Section 12 One could argue that RFC 6265 is only informative (we basically say "you have to let people *not* use this"); likewise for 7873. Given the "must [...] perform DNSSEC validation" in Section 5.1.4 it seems that RFC 4033 (or perhaps a companion document from the 403x series) would be normative. I think probably RFCs 5280, and maybe 8499, should be normative as well. There are also a few references that are needed to meet the "additional options", and from the stance that these are required in order to be "maximally compliant" they would also be classified as normative, though I did not attempt to tabulate them. Section A.2 o [RFC8446] Appendix C.4 describes Client Tracking Prevention in TLS 1.3 "Client tracking prevention" sounds like an increase, not a decrease, in DNS privacy. Section C.2 1. Deviations from Policy. None currently in place. Would we expect some indication of what "currently" means? _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
