Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

Tim Wicinski <> Fri, 09 October 2020 16:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C937A3A0A25; Fri, 9 Oct 2020 09:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NsI_6CnrHTFo; Fri, 9 Oct 2020 09:42:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB3D43A0A16; Fri, 9 Oct 2020 09:42:20 -0700 (PDT)
Received: by with SMTP id n61so9533092ota.10; Fri, 09 Oct 2020 09:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HjkhI+OQ1cKg0MAmfbE0wLRpPsVkm4euoz73tfISjEA=; b=HUDjdRZ9b5NJM5uT8oLc5pp+ZC6BURrZn2nWLjcUh0ja0luHmmMJXRnQMWCZB1I8T6 k9oj6ugGuZP7uZCutpqB9yGCN4gj64Yc9DQBkAi9AOIwFOT1PF+vtU8MYJnqi1WciqG0 Goja9w6Kd5a84kFQZKLuxB9wqsK0MeiqNTjNKFzc28BMweNHWx99ZYtfeLi90Lv4RY3Z HO3GG713GCgREpf624V8WqqI14M4lww8kkKkoQRVJFNxn5J+SHcLO+ZPBJpNeF3w5E9U mb3nqY7/R1MBOywgjnb3SOVf//lDNyrhNl3WMJk0nWtYlHqwEY9Xl17GAGYa8xjXP9hx +tkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HjkhI+OQ1cKg0MAmfbE0wLRpPsVkm4euoz73tfISjEA=; b=tPn27M/leVH4+Gd9Lg1i7bQ47M6sTfa4Fh2j+wb0qqYHNoX8ERAtrazS1IXfBlhLqg ip4rGSH8ZDQZM4O9tHUqpeEIdjcRzEpuJ0SoAJc1moEPtDs6GPAUa9vltg5ODPV7c/LJ Fkmyu+ytW8xCyzm60IxfESyCfQoTypLxA4ZHCzL1GnVx2cVzcW6Poe4Um6IhA1p9g3Z6 Zw+Yoz4MxAPMrIHpIgbWg7dvHugAS1KWgzpfQYZpbtBoX8Ndu4VYYDh+xUZe8wsdnp/f sXeXhbYYKicn/YgK7LAd0D9KU2CHsdiMriboJ2OECpHL2fJj1907Pku4RNDkiTY6PxDC G+sw==
X-Gm-Message-State: AOAM531+qCpgLJ9GwXfIqrfY1sWNEo+fYAPrFRVRDZC5NebfW2aL6jHu Vr8Olj4hTPPGM0LgOS1y8RHKggn1ytoi3T1wML8=
X-Google-Smtp-Source: ABdhPJx3/KL0tJ5gh9HU9+xXqpb4N15TH7UPv2ck1tgGvKIKUxgi+ogiwkRxvA5vQ8PQj7/J/B0pTj8BGFEmSI8EyT4=
X-Received: by 2002:a05:6830:400d:: with SMTP id h13mr9780756ots.371.1602261739911; Fri, 09 Oct 2020 09:42:19 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tim Wicinski <>
Date: Fri, 9 Oct 2020 12:42:08 -0400
Message-ID: <>
To: Benjamin Kaduk <>
Cc: The IESG <>,,, DNS Privacy Working Group <>, Brian Haberman <>
Content-Type: multipart/alternative; boundary="000000000000d8413805b13fa107"
Archived-At: <>
Subject: Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Oct 2020 16:42:24 -0000

On Wed, Oct 7, 2020 at 12:16 AM Benjamin Kaduk via Datatracker <> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Section 1
>    At the time of writing, almost all this DNS traffic is currently sent
>    in clear (i.e., unencrypted).  However there is increasing deployment
> nit: I think that "in the clear" is the term of art (add "the").

Another comment suggested changing "in clear (i.e., unencrypted)"
to just be "unencrypted."

Would this work for you?

>    Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
> It looks like
> (
> )
> Sara was going to follow up with the DITL authors to try and ascertain
> whether "almost all queries" is still accurate for the "UDP" aspect,
> though the IETF mailarchive search doesn't seem to find any more recent
> traffic on that topic.  Do we know if anyone actually heard back about
> this (or the "sent in [the] clear" a few lines previously)?
> I do not pretend to have the expertise needed to judge how the changes
> deployed by major browser affect the statistics for "all DNS traffic"
> (which presumably includes both stub-to-resolver and
> resolver-to-authoritative).

I  talked with Sara, who did reach out to the authors, and they informed us
that there  was no updates.

>    This has practical consequences when considering encryption of the
>    traffic as a possible privacy technique.  Some encryption solutions
>    are only designed for TCP, not UDP and new solutions are still
>    emerging [I-D.ietf-quic-transport] [I-D.huitema-quic-dnsoquic].
> [It looks like dnsoquic became draft-huitema-dprive-dnsoquic.]
Oh good catch - and in *our* WG!

> Section 3
>    multiple dynamic contexts of each device.  This document does not
>    attempt such a complex analysis, instead it presents an overview of
>    the various considerations that could form the basis of such an
>    analysis.
> nit: looks like a comma splice.

I changed "such a complex analysis, instead it" to
"such a complex analysis, but instead it"

> Section 4.1
>    authentication or authorization of the client (resolver).  Due to the
>    lack of search capabilities, only a given QNAME will reveal the
>    resource records associated with that name (or that name's non-
>    existence).  In other words: one needs to know what to ask for, in
> I agree with Warren that this statement ("only [...] will reveal [...]
> or that name's non-existence") is overly strong.

> Section 4.2
>    The DNS request includes many fields, but two of them seem
>    particularly relevant for the privacy issues: the QNAME and the
>    source IP address. "source IP address" is used in a loose sense of
>    "source IP address + maybe source port number", because the port
> In other contexts I've seen this combination referred to as the
> "transport address".
>    The QNAME is the full name sent by the user.  It gives information
>    about what the user does ("What are the MX records of"
>    means he probably wants to send email to someone at,
>    which may be a domain used by only a few persons and is therefore
>    very revealing about communication relationships).  [...]
> (editorial) something like not-a-secret-cabal.example might make the
> example more visceral than does.
>    create more problems for the user.  Also, sometimes, the QNAME embeds
>    the software one uses, which could be a privacy issue.  For instance,
> (nit) I trust that this can be made into a complete sentence while
> addressing Warren's more-substantive comment.
>    There are also some BitTorrent clients that query an SRV record for
>    _bittorrent-tracker._tcp.domain.example.
> In a similar vein, I'm not sure what domain.example is supposed to
> represent here -- the domain of the author of the BitTorrent client?
>    Therefore, all the issues and warnings about collection of IP
>    addresses apply here.  For the communication between the recursive
> I mostly assume that this is intended to be a reference to the generic
> concerns about "IP addresses are PII", etc., that one is ambiently
> exposed to by reading enough about the Internet.  (There does not seem
> to be previous discussion of "collection of IP addresses" in this
> document, which would seem to indicate that it is not trying to refer
> back to previous text.)  If so, perhaps an extra word or two would help
> ("all the standard issues and warnings", "all the generic issues and
> warnings", etc.) clarify the intent of the reference.
I want to get back to this.

>    However, hiding does not always work.  Sometimes EDNS(0) Client
>    subnet [RFC7871] is used (see its privacy analysis in
>    [denis-edns-client-subnet]).  [...]
> (nit) The wording here ("its privacy analysis") suggests that the
> referenced document is an authoritative/official IETF position, but it
> seems to be a blog post by a single individual.  Using "one" or "a"
> rather than "its" would convey a less-authoritative connotation.
I replaced this with "one"

>                                        In both cases, the IP address
>    originating queries to the authoritative server is as sensitive as it
>    is for HTTP [sidn-entrada].
> I don't see how [sidn-entrada] supports the claim that end-user-adjacent
> DNS client IP addresses are equally sensitive as HTTP client IP
> Addresses; it mentions "sensitive" only twice (as "privacy-sensitive",
> admittedly, applying to such IP addresses, but as an assertion without
> justification) and "http" only in URLs (mostly in the references) and as
> an example request.  It would feel more natural to use an IETF reference
> here, as well -- e.g., RFC 7624 discusses correlating client IP
> addresses with end users, RFC 7239 clearly covers privacy considerations
> for sending client IP addresses in the "forwarded" header field, and
> there are no doubt others -- though I do note the contents of the
> paragraph after this one.
Skipping this for now.

>                      However, for both IPv4 and IPv6 addresses, it is
>    important to note that source addresses are propagated with queries
>    and comprise metadata about the host, user, or application that
>    originated them.
> (This "propagated with queries" is still contingent on EDNS(0) Client
> Subnet from the previous paragraph, right?)
Yes it is - do you think it needs to be re-mentioned?

> Section 4.2.1
>    cache poisoning attacks by off-path attackers.  It is noted, however,
>    that they are designed to just verify IP addresses (and should change
>    once a client's IP address changes), they are not designed to
>    actively track users (like HTTP cookies).
> nit: comma splice.

Would this change work for you:

update "IP address changes), they are not designed to"

with  "IP address changes), but they are not designed to"

> Section 5.1
>    not be.  When other protocols will become more and more privacy-aware
>    and secured against surveillance (e.g., [RFC8446],
>    [I-D.ietf-quic-transport]), the use of unencrypted transports for DNS
>    may become "the weakest link" in privacy.  It is noted that at the
>    time of writing there is on-going work attempting to encrypt the SNI
>    in the TLS handshake [I-D.ietf-tls-sni-encryption].
> This mention of encrypted "SNI" (now encrypted ClientHello) comes as a
> bit of a non sequitur.  I suggest a bit of transition such as an
> additional clause at the end of the sentences ", which is one of the
> last remaning non-DNS cleartext identifiers of a connection target".
> (While the actual work itself has progressed to encrypting the entire
> ClientHello, I think it's okay to focus the exposition here on the SNI,
> as the relevant attribute.)
You're suggesting adding your clause at the end of that sentence? Like so:

    It is noted that at the time of writing
   there is on-going work attempting to encrypt the SNI in the TLS handshake
   [@RFC8744], which is one of the
   last remaining non-DNS cleartext identifiers of a connection target.

                                                         It can be noted
>       that if the user selects a single resolver with a small client
>       population (even when using an encrypted transport) it can
>       actually serve to aid tracking of that user as they move across
>       network environment.
> I wonder if it is worth adding another clause at the end: ", and that an
> attacker in a position to observe the moving user is likely also able to
> observe the likely-unencrypted DNS queries from the resolver to the
> authoritative servers"
> Also, nit: "environments" plural.

Thanks fixed.

> Section 5.2
>    Traffic analysis of unpadded encrypted traffic is also possible
>    [pitfalls-of-dns-encryption] because the sizes and timing of
>    encrypted DNS requests and responses can be correlated to unencrypted
>    DNS requests upstream of a recursive resolver.
> We could (but don't have to) note that effective padding policies remain
> an open area of research.
> Section
>    o communicate clearly the change in default to users
> I think this is intending to say "when the default application resolver
> changes away from the system resolver", but the present text is perhaps
> a little unclear about what "the change" is referring to.
I see.  Is this better?

"communicate clearly the change to users when the default application
     resolver changes away from the system resolver"

> Section 6.1.2
>                                                                 Even if
>    encrypted DNS such as DoH or DoT is used, unless the client has been
>    configured in a secure way with the server identity, an active
>    attacker can impersonate the server.  [...]
> More than the server identity is needed -- the credentials or trust
> anchor needed to authenticate a peer as that identity are also needed.
> Section 6.1.3
>    User privacy can also be at risk if there is blocking (by local
>    network operators or more general mechanisms) of access to remote
>    recursive servers that offer encrypted transports when the local
>    resolver does not offer encryption and/or has very poor privacy
>    policies.  [...]
> I suggest adding "e.g." before "when the local resolver" to avoid giving
> the impression that this is an exhaustive list.

Good idea.  Added

>    This is a form of Rendezvous-Based Blocking as described in
>    Section 4.3 of [RFC7754].  Such blocklists often include servers know
>    to be used for malware, bots or other security risks.  In order to
>    prevent circumvention of their blocking policies, some networks also
>    block access to resolvers with incompatible policies.
> Perhaps this is touching too much on the controversial topic, but it
> seems to me that the networks in question "attempt to block access";
> whether or not they fully and reliably succeed at doing so is not clear.
> (See also the near-impossibility of closing covert channels in
> protocols.)
>    It is also noted that attacks on remote resolver services, e.g., DDoS
>    could force users to switch to other services that do not offer
>    encrypted transports for DNS.
> nit: comma after DDoS.


> Section
>    Some implementations have, in fact, chosen to restrict the use of the
>    'User-Agent' header so that resolver operators cannot identify the
>    specific application that is originating the DNS queries.
> With similar disclaimer as previously, perhaps "trivially identify"?
> There are other fingerprinting techniques possible even at, e.g., the TLS
> layer (that we discussed previously in this document!), which still
> apply to DoH.
> Section 6.2
>    This "protection", when using a large resolver with many clients, is
>    no longer present if ECS [RFC7871] is used because, in this case, the
>    authoritative name server sees the original IP address (or prefix,
>    depending on the setup).
> (side note) this has always been a bit confusing to me -- ECS is "client
> subnet", not "client address", and I don't really understand why someone
> would set the prefix length to the full 128 (or 32) bits of the address.
> Is there really a lot of non-truncated client addresses being sent
> around like this?  How did that happen?

I'm not sure how there are non-truncated client addresses, but I would
say if something can be done in the DNS, it is being done.

>                                                                     So,
>    requests to a given ccTLD may go to servers managed by organizations
>    outside of the ccTLD's country.  End users may not anticipate that,
>    when doing a security analysis.
> (Is this a "for example"?  It seems plausibly relevant for non-cc TLDs
> as well.)

yes, I changed "So" to "For example"

> Section 7.1
>    The IAB privacy and security program also have a work in progress
>    [RFC7624] that considers such inference-based attacks in a more
>    general framework.
> I do not really think the final RFC constitutes a "work in progress"
> anymore.

Correct - this is a good catch.

> Section 8
>    Passive DNS systems [passive-dns] allow reconstruction of the data of
>    sometimes an entire zone.  They are used for many reasons -- some
>    good, some bad.  Well-known passive DNS systems keep only the DNS
>    responses, and not the source IP address of the client, precisely for
>    privacy reasons.  Other passive DNS systems may not be so careful.
> Perhaps not so well-intentioned, either...
>    The revelations from the Edward Snowden documents, which were leaked
>    from the National Security Agency (NSA) provide evidence of the use
> nit: comma after "(NSA)".

> Section 9
>    To our knowledge, there are no specific privacy laws for DNS data, in
>    any country.  Interpreting general privacy laws like
>    [data-protection-directive] or GDPR [10] applicable in the European
>    Union in the context of DNS traffic data is not an easy task, and we
>    do not know a court precedent here.  See an interesting analysis in
>    [sidn-entrada].
> This text is essentially unchanged since RFC 7626; did we do much of a
> search for whether the past five years have brought about changes in the
> legal landscape?

I can speak from personal experience in my previous employer and I
worked with corporate legal to track anything useful.

I know I missed some of your comments, I am not blowing you off. I wanted
to capture the editorial fixes first while I think through a few of the