Adaptive DNS Discovery T. Reddy Internet-Draft Nokia Intended status: Informational M. Boucadair Expires: 27 December 2024 Orange D. Wing Cloud Software Group 25 June 2024 Hosting Encrypted DNS Forwarders on CPEs draft-rbw-add-encrypted-dns-forwarders-00 Abstract Typical connectivity service offerings based upon on Customer Premise Equipment (CPEs) involve DNS forwarders on the CPE for various reasons (offer local services, control the scope/content of information in DNS, ensure better dependability for local service, provide control to users, etc.). Upgrading DNS to use encrypted transports introduces deployment complications as to how to sustain current offerings with local services. Solutions are needed to ease operating DNS forwarders in CPEs while allowing to make use of encrypted DNS capabilities. This document describes the problem and why some existing solutions can't be used for these deployments. For example, Star certificates and name constraints extension suffer from the problem of deploying a new feature to CAs, TLS clients, and servers. The document also discusses adaptations to some other existing techniques to accomodate LAN specifics. The scope of this document is encrypted DNS servers deployed on managed CPEs. The document does not focus on generic considerations related to deploying DNS proxies. The reader may refer to [RFC5625] for such matters. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Adaptive DNS Discovery Working Group mailing list (add@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/add/. Reddy, et al. Expires 27 December 2024 [Page 1] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 Source for this draft and an issue tracker can be found at https://github.com/boucadair/encrypted-dns-forwarders. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Proxied DNS In Local Networks . . . . . . . . . . . . . . . . 4 4. Hosting Encrypted DNS Forwarder in Local Networks . . . . . . 5 4.1. Discovery Mechanisms and Naming Constraints . . . . . . . 5 4.1.1. Discovery of Designated Resolvers (DDR) . . . . . . . 5 4.1.2. Discovery of Network-designated Resolvers (DNR) . . . 6 5. Limitations of Existing Solutions . . . . . . . . . . . . . . 6 5.1. Certificate Issuance Issues . . . . . . . . . . . . . . . 6 5.2. Delegated Certificate Issuance . . . . . . . . . . . . . 7 5.3. Limitations of Name Constraints Extension . . . . . . . . 8 5.4. Limitations of Star certificates . . . . . . . . . . . . 8 Reddy, et al. Expires 27 December 2024 [Page 2] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Customer Premises Equipment (CPEs, also called Home Routers) are a critical component of the home network, and their security is essential to protecting the devices and data that are connected to them. For example, the prpl Foundation [prpl] has developed a number of initiatives to promote home router security and hardening. The prplWrt project [prplwrt] is an initiative in prpl Foundation that aims to improve the security and performance of open-source router firmware, such as OpenWrt [openwrt]. OpenWrt is an open-source operating system that is designed to run on a wide range of routers and embedded devices. It now includes support for containerization technology such as Docker, making it possible to run containerized applications on a home router. Further, DNS providers have optimized the encrypted DNS forwarder to run in a container in home routers. However, upgrading DNS to use encrypted transports (e.g., DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], and DNS over QUIC (DoQ) [RFC9250]) introduces deployment complications as to how to sustain current offerings with local services. This document describes the problem encountered to host encrypted DNS resolvers in managed CPEs. It also discusses limitations of existing solutions. 2. Conventions and Definitions This document makes use of the terms defined in [RFC9499]. The following additional terms are used: DHCP: refers to both DHCPv4 and DHCPv6. Do53: refers to unencrypted DNS. DNR: refers to the Discovery of Network-designated Resolvers procedure defined in [RFC9463]. DDR: refers to the Discovery of Designated Resolvers procedure defined in [RFC9462]. Reddy, et al. Expires 27 December 2024 [Page 3] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 Encrypted DNS: refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoH [RFC8484], DoT [RFC7858], and DoQ [RFC9250]. Managed CPE: refers to a CPE that is managed by an ISP or CPE vendor or Security Service Provider. 3. Proxied DNS In Local Networks Figure 1 shows various network setups where the CPE embeds a caching encrypted DNS forwarder. (a) ,--,--,--. ,--,--,--. ,-' `-. ,-' ISP `-. Host---( LAN CPE----( DNS Resolver) | `-. ,-'| `-. ,-' | `--'--'--' | | `--'--'--' | |<=DNR=>| | |<========DNR========>| | | | | | |<=====Encrypted=====>|<=Encrypted=>| | DNS | DNS | (b) ,--,--,--. ,--,--,--. ,-' `-. ,-' ISP `-. 3rd Party Host---( LAN CPE----( )--- DNS Resolver | `-. ,-'| `-. ,-' | | `--'--'--' | | `--'--'--' | | |<=DNR=>| | |<========DNR========>| | | | | | |<=====Encrypted=====>|<=========Encrypted DNS======>| | DNS | | Figure 1: Proxied Encrypted DNS Sessions For all the cases shown in Figure 1, the CPE advertises itself as the default DNS server to the hosts it serves in the LAN. The CPE relies upon DHCP or RA to advertise itself to internal hosts as the default encrypted DNS forwarder using DNR. When receiving a DNS request that a CPE cannot handle locally, the CPE forwards the request to an upstream encrypted DNS. The upstream encrypted DNS can be hosted by the ISP or provided by a third party. Reddy, et al. Expires 27 December 2024 [Page 4] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 Such a forwarder presence is required for (but not limuted to): * IPv4 service continuity purposes (e.g., Section 3.1 of [RFC8585]). * Supporting advanced services within a local network such as: - malware filtering, - parental control, - Manufacturer Usage Description (MUD) [RFC8520] to only allow intended communications to and from an IoT device, and - offer multicast DNS proxy service for the ".local" domain [RFC6762]. When the CPE behaves as a DNS forwarder, DNS communications can be decomposed into two legs to resolve queries: * The leg between an internal host and the CPE. * The leg between the CPE and an upstream DNS resolver. 4. Hosting Encrypted DNS Forwarder in Local Networks This section discusses some deployment challenges to host an encrypted DNS forwarder within a local network. 4.1. Discovery Mechanisms and Naming Constraints 4.1.1. Discovery of Designated Resolvers (DDR) DDR requires proving possession of an IP address, as the DDR certificate contains the server's IPv4 and IPv6 addresses and is signed by a certificate authority. DDR is constrained to public IP addresses because (WebPKI) certificate authorities will not sign special-purpose IP addresses [RFC6890], most notably IPv4 private-use [RFC1918], IPv4 shared address [RFC6598], or IPv6 Unique-Local [RFC8190] address space. A tempting solution for enabling an encrypted DNS forwarder with DDR is to use the CPE's WAN IP address for DDR and prove possession of that IP address. However, the CPE's WAN IPv4 address will not be a public IPv4 address if the CPE is behind another layer of NAT (either Carrier Grade NAT (CGN) or another on-premise NAT), reducing the success of this mechanism to CPE's WAN IPv6 address. Reddy, et al. Expires 27 December 2024 [Page 5] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 Also, if the ISP renumbers the subscriber's network suddenly (rather than slow IPv6 renumbering described in [RFC4192]), encrypted DNS service will be delayed until that new certificate is acquired. 4.1.2. Discovery of Network-designated Resolvers (DNR) DNR requires proving possession of a domain name as the encrypted resolver's certificate contains the FQDN. For example, the entity (e.g., ISP or network administrator) managing the CPE would assign a unique FQDN to the CPE. There are two mechanisms for the CPE to obtain the certificate for the FQDN: using one of its WAN IP addresses or requesting its signed certificate from an Internet- facing server used for remote CPE management (e.g., the Auto Configuration Server (ACS) in the CPE WAN Management Protocol [TR-069]). If the CPE's WAN IP address is used, the CPE needs a public IPv4 or a global unicast IPv6 address together with DNS A or AAAA records pointing to that CPE's WAN address to prove possession of the DNS name to obtain a (WebPKI) CA-signed certificate. That is, the CPE fulfills the DNS or HTTP challenge discussed in Automatic Certificate Management Environment (ACME) [RFC8555]. However, a CPE's WAN address will not be a public IPv4 address if the CPE is behind another layer of NAT (either a CGN or another on-premise NAT), reducing the success of this mechanism to a CPE's WAN IPv6 address. If the ISP renumbers the subscriber's network, the DNS record will also need to expire and changed to reflect the new IP address. 5. Limitations of Existing Solutions 5.1. Certificate Issuance Issues The following lists some limitations for certificate issuance: * In case of large scale of CPEs (e.g., millions of devices), issuing certificate request for a large number of subdomains could be treated as an attack by the certificate authorities to overwhelm it. * Dependency on the CA to issue a large number of certificates. * If the CPE uses one of its WAN IP addresses to obtain the certificate for the FQDN, the Internet-facing HTTP server or a DNS authoritative server on the CPE to complete the HTTP or DNS challenge can be subjected to DDoS attacks. Reddy, et al. Expires 27 December 2024 [Page 6] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 5.2. Delegated Certificate Issuance Let's consider that the encrypted DNS forwarder is hosted on a CPE and provisioned by a service (e.g., ACS) in the operator's network. Also, let's assume that each CPE is assigned a unique FQDN (e.g., "cpe-12345.example.com" where 12345 is a unique number). It is best to ensure that such an FQDN does not carry any Personally Identifiable Information (PII) or device identification details like the customer number or device's serial number. The CPE generates a public and private key-pair, builds a certificate signing request (CSR), and sends the CSR to a service in the operator managing the CPE. Upon receipt of the CSR, the operator's service can utilize certificate management protocols like ACME [RFC8555] to automate certificate management functions such as domain validation procedure, certificate issuance, and certificate revocation. The challenge with this technique is that the service will have to communicate with the CA to issue certificates for millions of CPEs. If an external CA is unable to issue a certificate in time or replace an expired certificate, the service would no longer be able to present a valid certificate to a CPE. When the service requests certificate issuance for a large number of subdomains (e.g., millions of CPEs), it may be treated as an attacker by the CA to overwhelm it. Furthermore, the short-lived certificates (e.g., certificates that expire after 90 days) issued by the CA will have to be renewed frequently. With short-lived certificates, there is a smaller time window to renew a certificate and, therefore, a higher risk that a CA outage will negatively affect the uptime of the encrypted DNS forwarders on CPEs (and the services offered via these CPEs). These challenges can be addressed by using protocols like ACME to automate the certificate renewal process, ensuring certificates are renewed well before expiration. Additionally, incorporating another CA as a backup can provide redundancy and further mitigate the risk of outages. By having a secondary CA, the service can switch to the backup CA in case the primary CA is unavailable, thus maintaining continuous service availability and reducing the risk of service disruption. It offers the additional advantage of improving the security of Browser and CPE interactions. This ensures that HTTPS access to the CPE is possible, allowing the device administrator to securely communicate with and manage the CPE. Reddy, et al. Expires 27 December 2024 [Page 7] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 5.3. Limitations of Name Constraints Extension A service managing the CPEs could get a CA certificate with name constraints extension (Section 4.2.1.10 of [RFC5280]) and the service would in-turn act as an ACME server to provision end-entity certificates on CPEs. * Con: - Name constraints extension is not yet supported by CAs, although [RFC5280] was standardized way back in 2008. * Pro: - Avoids changing TLS client and server (e.g., stunnel or openssl). 5.4. Limitations of Star certificates [RFC9115] defines a profile of the ACME protocol for generating Delegated certificates. It allows the CPEs to request from a service managing the CPEs, acting as a profiled ACME server, a certificate for a delegated identity, i.e., one belonging to the service. The service then uses the ACME protocol (with the extensions described in [RFC8739]) to request issuance of a short-term, Automatically Renewed (STAR) certificate for the same delegated identity. The generated short-term certificate is automatically renewed by the ACME CA, periodically fetched by the CPEs, and used to act as encrypted DNS forwarders. The service can end the delegation at any time by instructing the CA to stop the automatic renewal and letting the certificate expire shortly thereafter. Star certificates requires support by CAs but does not require changes to the deployed TLS ecosystem. * Cons: - Star certificates require support by CAs. - A primary use case of Star certificates is that of a Content Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The number of star certificates required for a CDN use case will be very much lower than the use case discussed in this draft. It is yet to be seen if CAs will agree to support star certificates at a scale of millions of CPEs. Reddy, et al. Expires 27 December 2024 [Page 8] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 * Pro: - Avoids changing TLS client and server. 6. Security Considerations DNR-related security considerations are discussed in Section 7 of [RFC9463]. Likewise, DDR-related security considerations are discussed in Section 7 of [RFC9462]. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T. Fossati, "An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates", RFC 9115, DOI 10.17487/RFC9115, September 2021, . [RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, "Discovery of Designated Resolvers", RFC 9462, DOI 10.17487/RFC9462, November 2023, . [RFC9463] Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", RFC 9463, DOI 10.17487/RFC9463, November 2023, . 8.2. Informative References Reddy, et al. Expires 27 December 2024 [Page 9] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 [I-D.reddy-add-delegated-credentials] Reddy.K, T., Boucadair, M., Wing, D., and S. Jain, "Delegated Credentials to Host Encrypted DNS Forwarders on CPEs", Work in Progress, Internet-Draft, draft-reddy-add- delegated-credentials-03, 1 December 2023, . [openwrt] OpenWrt, "OpenWrt Project", n.d., . [prpl] Prpl Foundation, "Prpl Foundation", n.d., . [prplwrt] Prpl Foundation, "Prpl WRT", n.d., . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, September 2005, . [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, . [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . Reddy, et al. Expires 27 December 2024 [Page 10] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima, "Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 2019, . [RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, March 2020, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . [TR-069] The Broadband Forum, "CPE WAN Management Protocol", n.d., . Reddy, et al. Expires 27 December 2024 [Page 11] Internet-Draft Encrypted DNS Forwarders on CPEs June 2024 Acknowledgments This draft is triggered by the discussion that occured at IETF#119 (Brisbane) about the need to frame the problem to be solved. Thanks to all the participants to that discussion. Acknowledgements from [I-D.reddy-add-delegated-credentials]: Thanks to Neil Cook, Martin Thomson, Tommy Pauly, Benjamin Schwartz, and Michael Richardson for the discussion and comments. Authors' Addresses Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: kondtir@gmail.com Mohamed Boucadair Orange 35000 Rennes France Email: mohamed.boucadair@orange.com Dan Wing Cloud Software Group Holdings, Inc. Email: danwing@gmail.com Reddy, et al. Expires 27 December 2024 [Page 12]