Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and COMMENT)

[Sara Dickinson <[e-mail]>]

Hi, 

(To the IESG) Firstly, apologies that these responses have taken so long. Secondly since it had been a while I wanted to walk through all the reviews to try to take care of overlap and follow up discussions as directly as possible so there will be a small flood of emails following this one :-) 

I hope I caught all the other comments correctly - please ping me if I missed something!

> On 6 Feb 2020, at 03:30, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 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:
> ———————————————————————————————————

Ben, 

Thanks for the detailed review!

> 
> [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”).

Thanks for picking up on this - my bad for letting things get out of sync...

Erik correctly identified that the section you mention is just renamed and renumbered (is now Section 3.5.1.2.  'Active Attacks on Resolver Configuration’ in the -04 version)

There is only one other specific reference to a section in draft-ietf-dprive-rfc7626-bis which is to Section 2.4.2 (this is now Section 3.4.2 'Encrypted Transports' in the -04 version of that draft). It seems highly unlikely that this particular section will be removed completely from the draft in future versions. 

Also, the most recent comments (from the second IETF LC) on draft-ietf-dprive-rfc7626-bis did suggest a further renumbering but there are no requests to remove entire sections. 

In other words I believe the problem with references to specific sections in draft-ietf-dprive-rfc7626-bis is small and manageable - I’ll take an action to ensure that the references are kept in sync in future versions. 

> 
> [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.

> 
> 
> ----------------------------------------------------------------------
> 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.

IIRC there was originally a rough stab at aligning with RFC7626-bis but I suspect that is no longer true.... Certainly the the ‘on the wire’, ‘data at rest’ and ‘data sent onwards’ division is based on that document. Within 5.1 and 5.3 the topics start with protocol related issues them move to more general ones but that is about the extent of the organisation….

> 
> In general it's better to reference RFC 7525 as BCP 195 than just the RFC
> number.

Will do.

> 
> 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.

I wonder if a reference to Section 3.5.1.1. ‘Resolver Selection’ of draft-ietf-dprive-rfc7626-bis would be helpful here? That section discusses this choice in a bit more detail.

> 
>   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”.)

You are not wrong but this is text from the original RFC7626 so a bit reluctant to update at this stage...

> 
>   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”.

Ack.

> 
>   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?

It was intended to relate to the single resolver operator committing to not tracking the users of the service, since only they have visibility of the user as they move between networks. Could do the following:

s/Commitments from operators/Commitments from resolver operators to minimize such tracking as users move between networks/

> 
>   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.)

There was some bike shedding on this which landed here… I did think about using DROPS but it felt a bit awkward when used in text:

'The following section outlines the recommended contents of a DROPS an operator might choose to publish.'

I guess DPS is another option but seems a bit abbreviated…?

> 
>      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 "

> 
>   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”?

I think the range of DNS resolution services will always mean there are good reasons (size, client population, local laws/regulation, etc.) for variations so I’m not sure this is intended to remove those, just reduce them and make them transparent...

> 
>   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”.

Ack.

> 
> 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. 


> 
> 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?)

Correct. RFC8499 re-used the same definition from RFC8310 but truncated it to remove the credentials element (I believe just for brevity, not for any technical reason). So this just clarifies the full definition is used here. 

> 
> 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.

That was one of the reasons for the bis of RFC7626, so that it contains expanded explanations of most of the risks. For others, I guess we are expecting the audience of DNS Privacy operators to understand the 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.

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….

> 
> 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.

As noted, reference will be updated. 

> 
>   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/?


> 
> 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?

The previous section just says they _can_ be used and several smaller operators do still use then. Is it the lower case ’should’ in Section 5.1.2 that is confusing? I can change this to ’need to’. 


> 
>   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?  

Those are the mechanisms expected here. If the user can’t use a particular privacy service because of this then they may be forced to fall back to clear text.

> How does a user mistyping a domain name
> result in a privacy threat?

Because if they try to specify a specific resolver in an OS or application configuration dialogue they could be using an attacker controlled resolver without realising it e.g. someone sets one up on 
https://cloudflar-dns.com/dns-query

> 
> 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.

I guess it is useful to retain for completeness for a DNS audience?


> 
>   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).

Ack.

> 
> 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

Good point - I’ll add the reference.

> 
> 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”?

Correct. 

> 
> 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?

I’m not sure that is useful, and I can’t think of a document targeted specifically at recursive operators (rather than authoritative)…. The best advice is really to keep the software up to date because the default configs of most major open source recursives handle DNSSEC perfectly well, but I think that applies in general here. 

> 
>   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.

Alternative text suggested in response to Adam’s comment on this.

> 
> 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?

I can live with that. 

> 
> 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?

Ah, this means misconfiguration of the target server address in the proxy configuration… Will clarify. 

> 
> 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.

“The following are recommendations relating to common activities for DNS service operators" ?

> 
>   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”.

Indeed - with DNS anomalous use covers a multitude of things that may or may not be malicious, often that can’t be understood without the detailed analysis so forbidding this seems overly restrictive….

> 
>   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”.

the first one

> 
> 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.

Yes - thanks.

> 
> 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?

No - a historic artefact I imagine. Will merge bullet 2 and 5. 

> 
> 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?

> 
> 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”?

Not explicitly because *all* sharing activities should be listed in either section 2 or 3 of the Policy part of a DROP. 

> 
> 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)?

I think if is a significant deviation likely to be in place for more than a very brief period of time then it should be documented for the users. Are you suggesting we remove this clause?


> 
>       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?

As discussed above a normal validation process applies not requiring a specific trust anchor. 

> 
> Section 9
> 
> s/John Reed/Jon Reed/ ("for comments at the mic", I know, so spelling is
> ambiguous…)

He already pinged me about that :-)

> 
> 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.

Reasonable - I can move them

> 
> 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.

Agree with  promoting the two references you mention. IIRC the original approach was that anything referenced from a threat description or a Mitigation should be normative (i.e. the minimal compliance level), everything else was informative (hopefully I clarified the use of keywords in this document above). I’m not sure this still applies but reviewing them on this kind of basis now certainly makes sense so I’ll do that. Would this seem a reasonable split or do you still think anything mentioned in an optimisation/additional option should still be normative? 
 

> 
> 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.

Hum...it is a mitigation for a something that would decrease privacy without that mitigation...

> 
> Section C.2
> 
>   1.  Deviations from Policy.  None currently in place.
> 
> Would we expect some indication of what "currently" means?

From the date of the policy publication? Would you prefer “None in place since <insert date>.”?

Best regards

Sara.