Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and COMMENT)

Tim Wicinski <tjw.ietf@gmail.com> Fri, 09 October 2020 18:07 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 61A723A0B20; Fri, 9 Oct 2020 11:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.844
X-Spam-Level:
X-Spam-Status: No, score=-0.844 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Ob-KK_Nt6hfT; Fri, 9 Oct 2020 11:07:43 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 ABB943A0B02; Fri, 9 Oct 2020 11:07:43 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id u126so11028478oif.13; Fri, 09 Oct 2020 11:07:43 -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=KT9icnLJ7V/vlwtP14w3Hu+pkorz5hETsxwb3BNiCAA=; b=eCL4yW5gzMIfMnFgbdFK7AUpY8vcys6Pdc4ttpwSICb6fMmXL1GIf42sBwW+AoQsBN /WtBlleMPKoQp0VAnT7iEs4b3NP/vRd6LLYKQtjP1v7Heh3W+NAqUI/Kzyb9aUa6NCJg SIb11R6sHxAWKiYRiNyNQDPQ8qPky3FkeFueFnV40ZvKA7TZpCa1CrmwiYO37NZm0svQ bw32uHWu3JdPsBrapaCErfpFJLa49J8USPvIz4sG2m5uXAQ3dStCnW2dmwWbyNWzD/j7 w/0YmZSMhJxSCl0v4GQ/co7/3T04u9lT50VjCREe0sKqLZ5EjbfHTDeWzrCkjoqKV6Vr piRQ==
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=KT9icnLJ7V/vlwtP14w3Hu+pkorz5hETsxwb3BNiCAA=; b=plChFQLi4hSyBxfVRUOFa+V62RpuQu8/yShbZO3cfE2Yu+xjj/5icf02yEQMQM1BmJ CsnMmT5Y0cBF/VFHJwzSJTI1ZfdhAxw5n/+0Vrp+ZpMwHFVXisdKcjvdGXCo3AhMb33L vMP6MgDGTxJpnOl5uH7lCvULrRnv96gjSnBv5NpTzDM6r71NvKx7YPFiGgFu+mGgtm7W Gj+Z/RDSxQwaRJWOw85Rd4qSG5i6psoIKuPW9C1sg4Z3HgR71tIp/kU2/t65mPcJPhsi chfjvVwF60IBY0rcO5slM214R74LCQM7WhCks/qOMpNDu/agsJysYGjPlFPpLmYdC9it 4svw==
X-Gm-Message-State: AOAM532bUpsQh4CPXYFKUFjcCeuCZY2PP5+Lhr0XpVsuVZvb4fivKIOw TBL53Fxh/fUW+ZMhyvGtAQmkDibxtI2lR8F4LuU=
X-Google-Smtp-Source: ABdhPJxu5RT/HtV3AYJ9v8UHn2DBZsdUsg8pptOtXgn79F7oorUrTUYo/7xe3Fv4QeVieB/Qo7TQp/5haY3vP6AW+S4=
X-Received: by 2002:aca:484f:: with SMTP id v76mr3356352oia.45.1602266862776; Fri, 09 Oct 2020 11:07:42 -0700 (PDT)
MIME-Version: 1.0
References: <160212142076.12259.17590774442239950703@ietfa.amsl.com>
In-Reply-To: <160212142076.12259.17590774442239950703@ietfa.amsl.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Fri, 9 Oct 2020 14:07:31 -0400
Message-ID: <CADyWQ+EsbRGjRbMP8-Zq60f++NbMJiLKq9fX_qOZ81=dm1F5qg@mail.gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
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="00000000000030f69b05b140d393"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/SujXm5-zEIR6fZsR6R6tWNIDHrE>
Subject: Re: [dns-privacy] Alissa Cooper's Discuss on draft-ietf-dprive-rfc7626-bis-06: (with DISCUSS and 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 18:07:48 -0000

Alissa,

On Wed, Oct 7, 2020 at 9:43 PM Alissa Cooper via Datatracker <
noreply@ietf.org> wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: 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-rfc7626-bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> == 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
>    of DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484],
>    particularly in mobile devices, browsers, and by providers of anycast
>    recursive DNS resolution services.  There are a few cases where there
>    is some alternative channel encryption, for instance, in an IPsec VPN
>    tunnel, at least between the stub resolver and the resolver.
>
>    Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp].
>    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]."
>
> This text made me wonder about the value of publishing this bis document at
> this point in time. Things are evolving so rapidly that, with respect to
> several of the new parts of this document (e.g., the last few paragraphs of
> Sec. 6.1.1, Sec. 6.1.1.1, Sec. 6.1.1.2), an immutable summary designed to
> represent reality over the long term doesn't really seem feasible right
> now.
> Why not wait to see how QUIC, DOH, ADD, ODNS, etc. shake out in the next
> few
> years and take this up then?
>
>
The consensus of the WG was that enough changes have occurred since the
first document was published that it made sense to collect those details in
one place.  One could easily argue that this space is rapidly evolving, so
to say "let's just wait..." could be a never ending wait. Publishing this
document now allows the community to agree on the current state of affairs
that can help it focus on the critical next steps.

(Now saying that, we lack a summary narrative which lays all those out.
Which has been added).



== Section 6.1.1.2 ==
>
> "Users will only be aware of and have the ability to control such
>    settings if applications provide the following functions:
>
>    o communicate clearly the change in default to users
>
>    o provide configuration options to change the default
>
>    o provide configuration options to always use the system resolver"
>
> This doesn't seem true. If the third bullet isn't provided, users still
> have
> awareness and control. Also, the bullets seem redundant with the text
> above, as
> if this is saying "users only have awareness and control if they have
> awareness
> and control." As a result I'm not sure what this text is really meant to
> convey.


First. Another comment changed the first bullet to be:

  "communicate clearly the change to users when the default application

     resolver changes away from the system resolver"

Now these bullets are in relation to an application.   We could update the
second two bullet points to be something like this:

  o  provide configuration options to change the default application
resolver

  o  provide configuration options to allow the application to always use
the system resolver



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Please remove uses of "us" and "we," given that this is a consensus
> document.
>
>
Thanks. I believe I found them

"Privacy policies for these servers may or may not be available and users
> need
> to be aware that privacy guarantees will vary with network." --> This is
> unrealistic as almost no users understand any of this. I'd recommend
> removing
> this.
>
>
"user" in this case is an individual but is also meant to represent
"administrator

of computing resources" such as in an enterprise environment, etc.



> Section 6.1.3: The title says "Blocking of User Selected DNS Resolution
> Services" but the text is actually broader than that and applies to
> blocking of
> resolution services whether or not they are user-selected. I would suggest
> changing the title.
>
>
Would "Altering of User Selected DNS Resolution Services" work in this case?



> Section 6.1.4.2:
> "Privacy focused users should be aware of the potential for additional
> client
> identifiers in DoH compared to DoT and may want to only use DoH client
> implementations that provide clear guidance on what identifiers they add."
> Again this seems really unrealistic for the majority of users who have no
> idea
> what any of this means.
>
>
Once again, "user" here is a broad term to mean more than Joe Q. Public,
but someone who has administrative oversight on computing resources.

thanks
tim