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

Tim Wicinski <tjw.ietf@gmail.com> Mon, 12 October 2020 03:50 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 EE4CD3A09F2; Sun, 11 Oct 2020 20:50:16 -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 ov2-LXfOlSRq; Sun, 11 Oct 2020 20:50:14 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 DC2B03A08C3; Sun, 11 Oct 2020 20:50:13 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id 32so1462300otm.3; Sun, 11 Oct 2020 20:50:13 -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=CbQ181+K+cxiEAmpF+QE1As5CL9G+LYuzDX+gZ/TErM=; b=CL+kZCY8ut1le2B2KKcgk4dtV8FP7DbSoBitYPvimu78YFnBj7SwBe4rIc9pa3eAdn CORyPlMhCtxwIL2ktefu0twmbj9FD+7rPot9tzKuAiE1uPXiJuAze3Cs26ayvDA9g3LS 3NbdlcDmKEWLWfA4T+8cii7XqtgfQZlQpJRMDFkJZjo9fH3qOTDIG7VtoMAi0xIv7eg7 B74iZFSaVon9B20WRxi1Zs3No75YtnxuZwxqsFdS9CdTrO0uWSXXzFxN2GStXBfX/Yam pjEUg7KE9bQa/ja6ZbOE9QxKDpy696dthJ10i90xzIW8RHMZC9/dvEBM8smrVXcjG5kO R7OQ==
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=CbQ181+K+cxiEAmpF+QE1As5CL9G+LYuzDX+gZ/TErM=; b=ZsMXmhYeoj8IJ9a0QQmCUtRd8maiQluPYMVdCXWnVd+IYsWXADNGwdWgsJq11LPjQ9 bx+Ce+g3ckLcFrxF5YmT7vSfxw23JrL6LEMViDCAXGPwnWM6wBMCdqp6c6dJcleGuaxR H6F7EeD0vF3ykpXHY6VifnNDNQZlpg+o5+ON0J/pCzf6sYfhrzY2PkLuZVAB2qZ79vjH 8KENXsB1FXtcg0Bf1KLy95OBjW9dL2ejAj4ujZFkjXyKEfXsmUVz0/LYbJpKP9oAvbi0 tHmQLiWRngfD6Qgvim0dWYFIb55UtL0oQQ6Y8goPjzKTnW9eg/KTrsph84xVfQjBW+pU jbKA==
X-Gm-Message-State: AOAM531WvdNZPJJmSmz3T8A+1BQkMe0paWWGvRoqmPF4YNmmnck+3R/W 4Vyt/3vR/kh9P4m5lRxsDFweX/siHUyLni7nS6A=
X-Google-Smtp-Source: ABdhPJw/apMH1bNlielf+eXBJrNLva2c2j9+HHCHepCEVKUPlGX5JQT61anN4ir6vAWiVHWjs1Z7uUgWKHLfJIywwAg=
X-Received: by 2002:a9d:da7:: with SMTP id 36mr17566889ots.288.1602474613005; Sun, 11 Oct 2020 20:50:13 -0700 (PDT)
MIME-Version: 1.0
References: <160204419484.9519.7742091087612533203@ietfa.amsl.com> <CADyWQ+FwFXK-hcgfJXtWOAOX2fyMJqZddjKQ8MOCYwsYWFKRCg@mail.gmail.com> <20201012030432.GE83747@kduck.mit.edu>
In-Reply-To: <20201012030432.GE83747@kduck.mit.edu>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Sun, 11 Oct 2020 23:50:01 -0400
Message-ID: <CADyWQ+EfTU0ouYUWF1MPA3SRt+DyC99P44pzpugB9h6=_qSuFQ@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="00000000000011e31e05b17132e8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/DYpubVOHlrKcqFtDVrKVega-B0Y>
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: Mon, 12 Oct 2020 03:50:17 -0000

On Sun, Oct 11, 2020 at 11:04 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

>
> > >    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.
>
> It's good that we heard back, though I guess this still doesn't match with
> my intuition (and I guess Alissa made this into a discuss point).  But, I
> don't trust my intuition here without data to back it up :)
>
>
They presented that paper in the fall of 2019 at DNS-OARC
(https://indico.dns-oarc.net/event/32/contributions/728/ though oddly,
it was not recorded).  At the last OARC in September,
(https://indico.dns-oarc.net/event/34/contributions/speakers)
there was a talk about QNAME minimisation, but not on encryption.




> > > 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.
>
> Okay.
>
>
> > >                                        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.
>
> Okay.
>
> > >                      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?
>
> I'd prefer if it was, perhaps "are propagated with queries via EDNS(0)
> Client subnet"
>

Ok, changed.

>
>
> > > 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.
>
> Right, that's the suggestion.  (You don't have to use it, of course.)
>

I've made the change, and have a note for Brian to go over as well.


>
> > >
> > > 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"
>
> Better, yes.  Though maybe "communicate clearly to users the change when
> [...]" is better still?
>

Yes - that is clearer. fixed.
Brian (co-chair), Eric our AD and I were going to chat about the
outstanding items to make sure we're all
in some agreement.

tim