[Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-add-dnr-11: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-add-dnr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Internet AD comments for {draft-ietf-add-dnr-11}
CC @paulwouters

## Discuss

The overarching issue of the ADD WG in general is the concern that using
the local network's DNS server (encrypted or not) is a privacy concern.
With HTTP dying and HTTPS sealing the last plain-text with Encrypted Client
Hello (ECH), DNS is the last resort of getting to know the enduser's
intent of where they are trying to connect to.

There are many parties interested in seeing the DNS query content, but
the enduser is rarely able to determine whether the local network used
can be trusted. This is true for coffee shops, hotels, malls but also
their home ISP. The only clear case of trust is the enterprise user, who
is provisioned (forced) via their enterprise management to use specific
DNS resolvers.

There are a number of well-known public DNS services such as Google DNS
(8.8.8.8), Quad9 (9.9.9.9) and Cloudflare (1.1.1.1). Arguably, these
servers have a better reputation of protecting the enduser's privacy
than most local networks, as endusers cannot trust most local networks
they use.

The question all of this raises is, whether the user isn't better of
just never trusting or using the local network's DNS server, whether
encrypted or not. In that case, all of these ADD documents have little
value. For example, we see this already with Firefox and its TRR program
https://wiki.mozilla.org/Trusted_Recursive_Resolver and to some extend
with the Android phone "private DNS" feature
https://www.howtogeek.com/795644/how-to-enable-secure-private-dns-on-android/

On the other hand, we have the argument of, if the enduser is using
the local unencrypted DNS, it might as well use the local encrypted DNS.
While this is true if this decision is hidden from the enduser, if the
enduser believes they are using "encrypted DNS", they might not be aware
that this encrypted connection still reveals all privacy sensitive data
to the local network entity (or its trusted third party). An aware enduser
might also make different choices when they think their DNS is "safely
encrypted", such as visiting the website of an abortion provider. That is,
the ADD specifications might lure the enduser in a false sense of security.
To me this is one of the biggest issues while reviewing the ADD drafts. Are
these drafts potentially harmful to the enduser, or does it only offer
improvements to the status quo of the current common (non-encrypted) DNS
topologies? While the latter could be true, I do believe based on the
development seen at Google/Android and Mozilla/Firefox, I think we are
already far into the phase where the enduser only decides _which_ remote
trustworthy encrypted DNS service they are going to use and as such only
use the local network DNS to kickstart their internet connection (captive
portal, paywall) after which they switch to remote encrypted DNS service.

And that of course, raises an issue with DNS security providers, who
wish to monitor and firewall all their DNS clients' DNS requests to
improve enduser security. This includes government mandates to ISPs to
filter certain DNS requests for local legal reasons. Which again raises
the issues of where such filtering power can be abused by authoritative
regimes, restrictive cults (eg scientology netnanny).

To summarize, I am really on the fence with respect to all the ADD drafts.
While "encrypted DNS" is always better than "unencrypted DNS", the
overarching issue of "never use or trust the local DNS resolvers" trumps
the DNR /DDR protocols. For those who can dictate how their users MUST
use DNS (eg Enterprise usage, parental control, opt-in security software),
device provisioning/configuration options are available that require no
ADD protocols with the exception of draft-ietf-add-svcb-dns.

###

Encrypted DNS servers need a public FQDN because otherwise you cannot get
a certificate for all connecting clients that are not provisioned with a
private/enterprise CA. How do home users run their own without having a
public domain? And how do I authenticate the encrypted DNS on 10.1.1.1
that has no FQDN? (and really, has no verifiable identity at all)

###

     The DNS client verifies the connection based on PKIX validation

No CRLs, OneCRL updates, no OCSP, no Certificate Transparency is available
without functional DNS. So full PKIX validation as specified here is not
available.

###

     The DNS client uses Web PKI trust anchors by default unless
     configured otherwise.

CAB/Forum is currently, as far as I know, not taking encrypted DNS into account
for their BR's. Also, every OS and even some applications use their own "webpki"
root store that differs from each other. This can lead to interoperability issues.

###

Spoofing attacks are mentioned in the document. Obtain _any_ certificate from Let's
Encrypt via ACME, eg using "something.example.com", then spoof authentication-domain-name
on the wifi. While this attack might be blocked by the AP not allowing wifi clients to
send packets to each other, this is not true for all networks, and especially not for
home networks where the goal is for local clients to be able to connect to each other.
Is there a better way to lock the authentication-domain-name? One possible method might
be to bind it to the ESSID. eg if the ESSID is wifi.nohats.ca. one could only allow
authentication-domain-name to be a name within nohats.ca. Some method of reducing the
scope of this attack is needed I believe.

###

   authentication-domain-name (variable length):  A fully qualified
      domain name of the encrypted DNS resolver.  This field is
      formatted as specified in Section 10 of [RFC8415].

      An example of the authentication-domain-name encoding is shown in
      Figure 2.  This example conveys the FQDN "doh1.example.com.", and
      the resulting Option-length field is 18.

       +------+------+------+------+------+------+------+------+------+
       | 0x04 |   d  |   o  |   h  |  1   | 0x07 |   e  |   x  |   a  |
       +------+------+------+------+------+------+------+------+------+
       |   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  | 0x00 |
       +------+------+------+------+------+------+------+------+------+

The draft says "as specified in Section 10 of [RFC8415]" but that is just
a redirect to Section 3.1 of [RFC1035] which doesn't tell me how to
encode the NAME. For example, I do not understand why one "." is encoded
as 0x07 and another "." is 0x03 ?

###

      Addr Length:  Length of enclosed IPv6 addresses in octets.  When
      present, it MUST be a multiple of 16.

Why not just a one octet counter then? The number of IPv6 addresses that follow.
Then the length of the Addr field becomes counter times 16 octets. That seems
more constrained than "multiple of 16"

###

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                         ipv6-address                          |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The diagrams lack reference octets. What is the width ? or 4 rows ? or ?
I assume this is supposed to be 4 octets wide and 16 octets total? eg
I would write:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------------------------------------------------------+
      |                                                               |
      |                         ipv6-address                          |
      |                                                               |
      |                                                               |
      +---------------------------------------------------------------+
      |                              ...                              |
      +---------------------------------------------------------------+

(also my pet peeve is people using +-+-+-+ instead of -----)


###

       A value of zero means that this Authentication Domain Name MUST no
       longer be used.

Why not just omit the entry ? Are clients supposed to keep old entries for
their entire lifetime even if when asking a new list, those entries no longer
appear? That is not clear from this document. Either that should be made
explicit, or the values of 0 should not be allowed.

###

   By default, Encrypted DNS connections received from outside the local
   network MUST be discarded by the encrypted DNS forwarder in a CPE.

What is an "encrypted DNS forwarder in a CPE"? This is not defined in the
document and I am confused. I assume the CPE announces some encrypted DNS
server as either itself or to some external IP at the ISP network?

If itself, how can it get a real FQDN the client can verify with PKIX
using CAB/Forum ? If to an external IP, isn't it just acting as a NAT/router
forwarding packets and then what does it mean to be an "encrypted DNS forwarder" ?

###

   This recommendation is meant to isolate local network
   DNS resolver services from the public Internet and prevent external
   attacks against the local Encrypted DNS resolver.

   If the DHCP responses or RAs are dropped by the attacker, the client
   can fallback to use a preconfigured encrypted DNS resolver.

This raises the big question of why you think that strategy is a "fallback
strategy" and not the default behaviour of the client. Wouldn't it be more
secure if there is no DHCP/RA drop attacks possible? See my introduction text.

###

Multihoming is declared out of scope, but realistically most devices we are
talking about here are phones, and those are all multihomed. So I feel pretty
strongly that it should not be left out of scope.