On Mon, Jun 29, 2020 at 05:47:18PM +0100, Sara Dickinson wrote: > > > > On 27 Jun 2020, at 00:08, Benjamin Kaduk <[email protected]> wrote: > > > > Hi Sara, > > > > My apologies as well that the response has taken so long. (As Éric noted, > > this landed right as the COVID-19 craziness started, and I haven't fully > > recovered yet.) > > Thanks Ben, yes the timing wasn’t great :-( > > Trimmed response below to address just the outstanding issues.
Thanks. > > > >>> > >>> [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. > >> > >> Yes - that was the intention. Nothing beyond that was proposed relating to > >> DoT authentication. > >> > >>> It may be the case that we need > >>> to mention provisioning a trust anchor as well as the X.509 certificate > >>> information, here. > >> > >> I don’t believe so. If you think some clarify text would help though, > >> please do suggest what you would like to see. > > > > Perhaps > > > > OLD: > > To enable this, > > DNS privacy services that offer DNS-over-TLS need to provide > > credentials in the form of either X.509 certificates [RFC5280] or > > Subject Public Key Info (SPKI) pin sets [RFC8310]. > > > > NEW: > > To enable this, > > DNS privacy services that offer DNS-over-TLS need to provide > > credentials that will be accepted by the client's trust model, in the > > form of either X.509 certificates [RFC5280] or Subject Public Key > > Info (SPKI) pin sets [RFC8310]. > > Agreed. > > > > > (Also, is use of DANE acceptable?) > > Yes it is - it is covered in Section 8.2 of RFC8310. Ah, thanks; I missed that. > > > >>> > >>> 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.) > >> > >> So, a few practices (mainly the protocol related ones) can be observed via > >> testing e.g. > >> https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/ > >> so suggest: > >> “evaluate the measurable and claimed privacy properties " > > > > Okay. If I try hard, I might convince myself that this "and" could be > > misread > > as an intersection, not a union, so maybe "evaluate both the measurable > > and the claimed”? > > Sure. > > >> > >>> > >>> 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. > >> > >> I do agree it is somewhat complex, but the contents of the Appendix are > >> split into those two rough categories, with the decreases related to > >> increased tracking and logging. Again, happy to add a reference to > >> draft-ietf-dprive-rfc7626-bis, which tries to provide the more nuanced > >> discussions. > > > > I think what bothers me is that even for a single individual change, > > whether it presents an increase or decrease in the privacy properties of > > the DNS can be a matter of debate, depending on which axis of privacy is > > weighted more strongly by the observer. So maybe adding "in various > > ways" at the end of the sentence would reflect the potential nuance? > > Agreed. > > >> > >>> > >>> 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. > >> > >> There were several discussions in the WG about this. The first version of > >> the document used normative language throughout which many though wasn’t > >> appropriate. A suggestion to remove normative language completely was felt > >> to leave the document somewhat toothless so this compromise of using the > >> single SHOULD and 3 levels of compliance was reached…. > > > > Replying here instead of the other AD ballot thread, for convenience... > > there is new text: > > > > In other words, these requirements are specified here as all being > > normative requirements, and are classified only by different levels > > of compliance in the rest of the document. > > > > which still leaves me a little confused. If they are all normative > > requirements, what makes the minimally/moderately/maximally compliant > > variations different? Would the meaning change if, instead of the last > > clause we had a standalone sentence "The rest of this document refers > > only to the "threat mitigations", "optimizations", and "additional > > options", which correspond to the named levels of compliance stated > > above, but compliance (to the indicated level) remains a normative > > requirement”? > > I think your proposed text is clearer than the current text. With a couple of > tweaks would having the end of that section read as below work? > > “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: > > * Threat mitigations to be minimally compliant. > * Optimizations to be moderately compliant. > * Additional options to be maximally compliant. > > The rest of this document does not use normative language but instead refers > only > to the three differing classes of action which correspond to the three named > levels of compliance stated above. However, compliance (to the indicated > level) > remains a normative requirement." I think that would work, thanks. > > >>> > >>> 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. > >> > >> s/are standadized/are standardized in DNS specific RFCs/? > > > > I'd consider avoiding the "standardized" word at all in favor of > > something like "there are not specific RFCs that cover use of these > > transports for DNS", though your proposal is an improvement over the > > previous state. > > Your proposed text is clearer - will use that. > > > > >>> > >>> 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? > >> > >> I think the main point here is that ideally the service should offer the > >> user the option to not use ECS at all because it does have recognised > >> issues (and to do so at the service level since not many clients support > >> the protocol defined opt-out). For example from Section 2 of that RFC7871: > >> > >> “We recommend that the feature be turned off by default in all > >> nameserver software, and that operators only enable it explicitly in > >> those circumstances where it provides a clear benefit for their > >> clients. We also encourage the deployment of means to allow users to > >> make use of the opt-out provided." > >> > >>> > >>> 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. > >> > >> The text does just say ‘minimizes data leakage’ so I think it is clear it > >> is only a partial solution and that any use of ECS carries a privacy risk? > > > > Sometimes people autocomplete "minimizes" to "minimizes to zero" :) > > I wonder if "reduce" would work. > > Yes - will replace. Thanks; all this sounds good. -Ben _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
