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

[tirumal reddy <[e-mail]>]

On Thu, 14 Jul 2022 at 01:16, Paul Wouters via Datatracker <[e-mail]>
wrote:

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

The policy of a client to select the discovered network-signalled encrypted
resolver is out of scope of the ADD WG charter. The client may have a
policy to select the discovered resolver only if it has sufficient
reputation (e.g.,  Comcast provided encrypted resolver added to the TRR of
Firefox, see
https://blog.mozilla.org/products/firefox/firefox-news/comcasts-xfinity-internet-service-joins-firefoxs-trusted-recursive-resolver-program/).
In deployments like home/mobile networks offering network security
services, Enterprise networks allowing the use of BYOD (without MDM) can
only rely on DNR/DDR to signal the network-designated encrypted resolver.
The end-user may opt to use the network-signalled encrypted resolver in
trusted networks and use an external resolver in untrusted networks.
Further, DNR prevents on-path attack and pervasive monitoring of DNS
messages in the local network by allowing local DNS to upgrade from
plaintext to encrypted. In addition, it helps UX by using DNS names for the
DNS servers (rather than IP addresses).



>
> ###
>
> 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 FQDN can be provisioned by the ISP managing the CPE or the security
service vendor offering network security service can provision the CPE with
a real FQDN (please see section 4 in
https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00
for
more details).


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

Yes, the operational considerations discussed in
https://datatracker.ietf.org/doc/html/rfc8484#section-10 are applicable, we
will update the draft.


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

We fixed text, please see
https://www.ietf.org/rfcdiff?url1=draft-ietf-add-dnr&url2=https://raw.githubusercontent.com/boucadair/draft-btw-add-home-network/master/draft-ietf-add-dnr.txt.
Applications like browsers use their own trust store and can possibly be
configured to use the OS trust store (see
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox)
but only for IT-managed devices. This is the state of the industry and this
draft cannot resolve the dilemma. Please let us know if you have any
specific text recommendation to update the draft.



> ###
>
> 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?


DHCP shield can defend against the attack and it is enabled by default in
modern home routers.


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 ?
>

It is following the name space definition discussed in
https://datatracker.ietf.org/doc/html/rfc1035#section-3.1, 0x07 is the
length of the label ("example") and 0x03 is the length of last label
("com").



> ###
>
>       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"


Med will follow-up on this comment and rest of the ones related to packet
layout.


>
> ###
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                         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?
>

Yes, encrypted DNS forwarder is co-located on the CPE.


>
> If itself, how can it get a real FQDN the client can verify with PKIX
> using CAB/Forum ?


Please see my above reply for provisioning a real FQDN on the CPE and using
ACME to get a PKIX certificate.



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

It is upto the client policy to give higher precedence to preconfigured
encrypted DNS resolver over the discovered resolver or vice versa.

Cheers,
-Tiru


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