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

Tim Wicinski <tjw.ietf@gmail.com> Fri, 09 October 2020 16:42 UTC

Return-Path: <tjw.ietf@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C937A3A0A25; Fri, 9 Oct 2020 09:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsI_6CnrHTFo; Fri, 9 Oct 2020 09:42:20 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3D43A0A16; Fri, 9 Oct 2020 09:42:20 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id n61so9533092ota.10; Fri, 09 Oct 2020 09:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <160204419484.9519.7742091087612533203@ietfa.amsl.com>
In-Reply-To: <160204419484.9519.7742091087612533203@ietfa.amsl.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Fri, 9 Oct 2020 12:42:08 -0400
Message-ID: <CADyWQ+FwFXK-hcgfJXtWOAOX2fyMJqZddjKQ8MOCYwsYWFKRCg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dprive-rfc7626-bis@ietf.org, dprive-chairs@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, Brian Haberman <brian@innovationslab.net>
Content-Type: multipart/alternative; boundary="000000000000d8413805b13fa107"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/GedEL-dk5UWO78_lun3KZuWicP4>
Subject: Re: [dns-privacy] Benjamin Kaduk's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 09 Oct 2020 16:42:24 -0000

On Wed, Oct 7, 2020 at 12:16 AM Benjamin Kaduk via Datatracker <
noreply@ietf.org> 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 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-rfc7626-bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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
> (
> https://mailarchive.ietf.org/arch/msg/dns-privacy/1pZL1FA57hzE1e09mQ2HMg2aWYY/
> )
> 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 example.net?"
>    means he probably wants to send email to someone at example.net,
>    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 example.net does.
>
>    create more problems for the user.  Also, sometimes, the QNAME embeds
>    the software one uses, which could be a privacy issue.  For instance,
>    _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org.
>
> (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 6.1.1.2
>
>    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.
>

Fixed

>
> Section 6.1.4.2
>
>    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)".
>
>
Fixed

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

tim