Delegated Credentials to Host Encrypted DNS Forwarders on CPEs

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 has developed a number of initiatives to promote home router security and hardening. The prplWrt project is an initiative in prpl Foundation that aims to improve the security and performance of open-source router firmware, such as 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.

shows various network setups where the CPE embeds a caching encrypted DNS forwarder. discusses the applicability of DNR as a function of the address used by the CPE for the verification of ownership.

| | |<========DNR========>| | | | | | |<=====Encrypted=====>|<=Encrypted=>| | DNS | DNS | (b) ,--,--,--. ,--,--,--. ,-' `-. ,-' ISP `-. 3rd Party Host---( LAN CPE----( )--- DNS Resolver | `-. ,-'| `-. ,-' | | `--'--'--' | | `--'--'--' | | |<=DNR=>| | |<========DNR========>| | | | | | |<=====Encrypted=====>|<=========Encrypted DNS======>| | DNS | | ]]> For all the cases shown in , 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. When receiving a DNS request it 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. Such a forwarder presence is required for IPv4 service continuity purposes (e.g., Section 3.1 of ) or for supporting advanced services within a local network (e.g., malware filtering, parental control, Manufacturer Usage Description (MUD) to only allow intended communications to and from an IoT device, and multicast DNS proxy service for the ".local" domain ). 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.

This section discusses some deployment challenges to host an encrypted DNS forwarder within a local network.

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 , most notably IPv4 private-use , IPv4 shared address , or IPv6 Unique-Local address space. A tempting solution 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. If the ISP renumbers the subscriber's network suddenly (rather than slow IPv6 renumbering described in ) encrypted DNS service will be delayed until that new certificate is acquired. DNR requires proving possession of an FQDN as the encrypted resolver's certificate contains the FQDN. The entity (e.g., ISP, 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 ). If using a CPE's WAN IP address, 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 ACME ). 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. The mechanisms have the following 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 manage 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.

The encrypted DNS forwarder is hosted on a CPE and provisioned by a service (e.g., ACS) in the operator's network. Each CPE is assigned a unique FQDN (e.g., "cpe-12345.example.com" where 12345 is a unique number). It is NOT RECOMMENDED that such an FQDN carries 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 Automatic Certificate Management Environment (ACME) 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).

This document discusses the use of delegated credentials to host encrypted DNS resolvers, such as DoH , DNS-over-TLS (DoT) , or DNS-over-QUIC (DoQ) in managed CPEs by reducing the dependency on Certification Authority (CA). The advantage of using delegated credentials on CPEs is that it completely removes the dependency on the CAs to provide a PKI certificate for each CPE. The entity managing the CPE (e..g, ISP, CPE vendor, Security Service Provider) will provision it a with a delegated credential and renew the delegated credential before the expiry. Scope of this document is an encrypted DNS server deployed on a managed CPEs.

This document makes use of the terms defined in . The following additional terms are used: refers to both DHCPv4 and DHCPv6. refers to unencrypted DNS. refers to the Discovery of Network-designated Resolvers procedure defined in . refers to the Discovery of Designated Resolvers procedure defined in . refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoH , DNS-over-TLS (DoT) , and DNS-over-QUIC (DoQ) . refers to a CPE that is managed by an ISP or CPE vendor or Security Service Provider. refers to a CPE that is not managed by an ISP or CPE vendor or Security Service Provider. The certificate issued by the operator as described by .

To reduce the dependency on external CAs, this document RECOMMENDS the use of delegation credentials to be added to the TLS profile of encrypted DNS client and server implementations. A delegated credential (DC) is a digitally signed data structure with two semantic fields: a validity interval and a public key (along with its associated signature algorithm). The signature on the delegated credential indicates a delegation from the certificate that is issued to the peer. The delegation allows a service in the operator managing the CPE to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the CPE who is recipient of the delegation to terminate connections for names that the CA has authorized. Furthermore, this mechanism allows the encrypted DNS forwarder on a CPE to use modern signature algorithms, such as Ed25519 even if the CA does not support them. The signature on the delegated credential indicates a delegation from the certificate that is issued to a service in an infrastrcture owned by the CPE's operator. The private key used to sign a credential corresponds to the public key of the service's X.509 end-entity certificate . The delegated credential is cryptographically bound to the service's X.509 end-entity certificate with which the credential will be used. The X.509 end-entity certificate will have the KeyPurposeId set to id-kp-serverAuth for the client to identify that the certificate is issued for a server. The basic sequence of steps involved is shown in .

+ | | | | | Credential(Public Key, | | time, signature) | | +--------------------->+ | | | | | Delegated credential | | | (signed using public | | | key) | | +<---------------------+ | | | | ClientHello and | | | delegated_credential extn | | +--------------------------->+ | | | | | Certificate and delegated | | | credential | | |<---------------------------+ | | .------------------------. | | +-|CertVerify (Validate the| | | | | delegated credential) | | | | '------------------------' | | | | | ]]> The DNS client provides an extension in its ClientHello that indicates support for delegated credentials. The DNS forwarder sends the Certificate message providing both the certificate of the service as well as the delegated credential. The DNS client uses information from the certificate to verify the delegated credential and that the DNS forwarder is asserting an expected identity. For example, the operator managing the CPEs has a X.509 end-entity certificate for a domain "dnsserver.example.net" and issues each managed CPE managed a distinct delegated credential signed by the private key which orresponds to the public key of the X.509 end-entity certificate. If the operator is managing a large number of CPEs, different X.509 end-entity certificates can be used to manage a group of CPEs (e.g., "dnsserver.group1.example.net", "dnsserver.group2.example.net" etc.). When one of the X.509 end-entity certificate is revoked, only the group of CPEs associated with that certificate need renewed delegated credentials signed by the private key which corresponds to the public key of the the replaced certificate and it reduces the burden on the operator to sign the credentails for only a subset of the CPEs.

In order to also cover DNS clients that do not support delegation credentials or TLS 1.3 or later, server-side mechanisms that do not require changes to the client behavior are required (e.g., a PKCS#11 interface or a remote signing mechanism, being examples) as discussed in Section 3.2 of . As depicted in , a DNS forwarder may use delegated credentials for DNS clients that support them, while using a server-side mechanism to service local legacy DNS clients.

| | |<---ServerHello----| | |<---Certificate----| | | |<---remote sign---->| |<---CertVerify-----| | | ... | | ]]>

For the "dns" scheme, as defined in , the "tlsdelegation" SvcParamKey is used to indicate that a DNS server can be authenticated using delegation credentials. The DNS server must include the "tlsdelegation" parameter in the mandatory parameter list if the server is only accessible using delegation credentials. Marking the "tlsdelegation" parameter as mandatory will cause DNS clients that do not understand the parameter to ignore that SVCB record and they will not try to establish an authenticated secure connection with the DNS server. Including the "tlsdelegation" parameter without marking it mandatory advertises a DNS server that can be optionally authenticated using delegation credentials. Both the presentation and wire format values for the "tlsdelegation" parameter MUST be empty. For example, a DoH service advertised over DNR can be annotated as only supporting delegation credentials using the following record:

Alternate solutions and their limitations are discussed below: A service managing the CPEs could get a CA certificate with name constraints extension (Section 4.2.1.10 of ) 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 was standardized way back in 2008. Pro: Avoids changing TLS client and server (e.g., stunnel or openssl). 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 ) 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, is periodically fetched by the CPEs, and is 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. Con: Star certificates require support by CAs. Con: 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. Pro: Avoids changing TLS client and server. In summary, Star certificates, name constraints extension, and Delegated credentials suffer from the problem of deploying a new feature to CAs, TLS clients, and servers.

DNR-related security considerations are discussed in . Likewise, DDR-related security considerations are discussed in . The security considerations in are to be taken into account. The delegated credentials should be used to send a delegation only to a trusted CPE. It is meant to be used between parties that have a trust relationship with each other, for example, a managed CPE and a service managing it. The secrecy of the delegated credential's private key is thus important, and access control mechanisms must be used to protect it, including Hardware Security Modules, Trusted Execution Environment, and private key isolation (e.g., using containerization technologies or sandboxes). If the DNS SVCB response is not DNSSEC protected, or if the client does not perform DNSSEC validation, an attacker can spoof the 'tlsdelegation' SvcParamKey in the DNS SVCB response. For instance, an attacker can spoof the DNS SVCB response to indicate that the server does not support delegate credentials. To mitigate this attack, the client can provide the extension in its ClientHello indicating support for delegated credentials, irrespective of whether the 'tlsdelegation' SvcParamKey is sent in the DNS SVCB response or not.

This document adds the following entry to the SVCB Service Parameters registry ().

Thanks to Neil Cook, Martin Thomson, Tommy Pauly, Benjamin Schwartz and Michael Richardson for the discussion and comments. .