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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 06 February 2020 03:30 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 878DD120058; Wed, 5 Feb 2020 19:30:31 -0800 (PST)
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, Tim Wicinski <tjw.ietf@gmail.com>, dprive-chairs@ietf.org, tjw.ietf@gmail.com, dns-privacy@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158095983154.30505.9367680112201766264.idtracker@ietfa.amsl.com>
Date: Wed, 05 Feb 2020 19:30:31 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/2vUheiDTdAmdup9a175d712vULM>
Subject: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-bcp-op-08: (with DISCUSS and 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: Thu, 06 Feb 2020 03:30:32 -0000

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?