| Internet-Draft | IKEv2 for Encrypted DNS | April 2023 |
| Boucadair, et al. | Expires 30 October 2023 | [Page] |
This document specifies new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ).¶
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 30 October 2023.¶
Copyright (c) 2023 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.¶
This document specifies a mechanism to assign encrypted DNS configurations to an Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator. Specifically, it assigns one or more Authentication Domain Names (ADNs) of DNS resolvers that support encrypted DNS protocols. The specific protocols supported are described using the Service Parameters format defined in [I-D.ietf-dnsop-svcb-https]; supported protocols include DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], and DNS-over-QUIC (DoQ) [RFC9250].¶
This document introduces three new IKEv2 Configuration Payload Attribute Types (Section 3) to add support for encrypted DNS resolvers. The ENCDNS_IP4 and ENCDNS_IP6 attribute types (Section 3.1) are used to provision ADNs, a list of IP addresses, and a set of service parameters. The ENCDNS_DIGEST_INFO attribute (Section 3.2) additionally allows a specific resolver certificate to be indicated by the IKEv2 responder.¶
The encrypted DNS resolver hosted by a Virtual Private Network (VPN) provider can get a domain-validate certificate from a public Certificate Authority (CA). The VPN client does not need to be provisioned with the root certificate of a private CA to authenticate the certificate of the encrypted DNS resolvers. The encrypted DNS resolver can run on private IP addresses and its access can be restricted to clients connected to the VPN.¶
Sample use cases are described in Appendix A. The Configuration Payload Attribute Types defined in this document are not specific to these deployments, but can also be used in other deployment contexts. It is out of the scope of this document to provide a comprehensive list of deployment contexts.¶
For many years, typical designs have often considered that the DNS resolver was usually located inside the protected domain, but could be located outside of it. With encrypted DNS, the latter option becomes plausible. Note that existing VPN client implementations might not expect that the discovered DNS resolver IP addresses to be outside of the covered IP address ranges of the VPN tunnel.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terms defined in [RFC8499].¶
Also, this document uses the terms defined in [RFC7296]. In particular, readers should be familiar with "initiator" and "responder" terms used in that document.¶
This document makes use of the following terms:¶
The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types, ENCDNS_IP4 and ENCDNS_IP6, are used to configure encrypted DNS resolvers to an initiator. Both attribute types share the format that is shown in Figure 1. The information included in these attributes adheres to the recommendation in Section 3.1.9 of [I-D.ietf-add-dnr].¶
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 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-----------------------------+---------------+---------------+ | Service Priority | Num Addresses | ADN Length | +-------------------------------+---------------+---------------+ ~ IP Addresses ~ +---------------------------------------------------------------+ ~ Authentication Domain Name ~ +---------------------------------------------------------------+ ~ Service Parameters (SvcParams) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The description of the fields of the attribute shown in Figure 1 is as follows:¶
Length (2 octets, unsigned integer) - Length of the enclosed data in octets. In particular, this field is set to:¶
Service Priority (2 octets) - The priority of this attribute compared to other ENCDNS_IP* instances. This 16-bit unsigned integer is interpreted following the rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https].¶
AliasMode (Section 2.4.2 of [I-D.ietf-dnsop-svcb-https]) is not supported because such a mode will trigger additional Do53 queries while the data can be supplied directly in the IKE response. As such, this field MUST NOT be set to 0.¶
Authentication Domain Name (variable) - A fully qualified domain name of the encrypted DNS resolver, in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label [RFC5890]. The name MUST NOT contain any terminators (e.g., NULL, CR).¶
An example of a valid ADN for DoH server is "doh1.example.com".¶
Service Parameters (SvcParams) (variable) - Specifies a set of service parameters that are encoded following the rules in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. Section 3.1.5 of [I-D.ietf-add-dnr] lists a set of service parameters that are recommended to be supported by implementations.¶
The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses.¶
If no "port" service parameter is included, this indicates that default port numbers should be used. As a reminder, the default port number is 853 for DoT (Section 6 of [RFC7858]), 443 for DoH (Section 8.1 of [RFC8484]), and 853 for DoQ (Section 8 of [RFC9250]).¶
The service parameters apply to all IP addresses in the ENCDNS_IP* Configuration Payload Attribute.¶
The ENCDNS_DIGEST_INFO configuration payload attribute allows IKEv2 responders to specify a certificate digest that initiators can use when validating TLS connections to encrypted resolvers. This attribute can also be sent by the initiator to request specific hash algorithms for such digests. The format of ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REQUEST is shown in Figure 2.¶
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 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-------------+---------------+-------------------------------+ | Num Hash Algs | ADN Length | | +---------------+---------------+ + ~ List of Hash Algorithm Identifiers ~ +---------------------------------------------------------------+
The description of the fields of the attribute shown in Figure 2 is as follows:¶
List of Hash Algorithm Identifiers (variable) - Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client. This list may be controlled by a local policy.¶
The values of this field are taken from the Hash Algorithm Identifiers of IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" registry [IANA-IKE-HASH].¶
There is no padding between the hash algorithm identifiers.¶
Note that SHA2-256 is mandatory to implement (see Section 5).¶
The format of ENCDNS_DIGEST_INFO attribute if the Configuration payload has types CFG_REPLY or CFG_SET is shown in Figure 3.¶
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 +-+-----------------------------+-------------------------------+ |R| Attribute Type | Length | +-+-----------------------------+---------------+---------------+ | Num Hash Algs | ADN Length | | +---------------+---------------+ + ~ Authentication Domain Name ~ +-------------------------------+-------------------------------+ | Hash Algorithm Identifier | ~ +-------------------------------+ + ~ Certificate Digest ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The description of the fields of the attribute shown in Figure 2 is as follows:¶
The ENCDNS_DIGEST_INFO attribute may be present in the Configuration payload of CFG_ACK. In such a case, the ENCDNS_DIGEST_INFO MUST be returned with zero-length data.¶
As discussed in Section 3.15.1 of [RFC7296], there are no defined uses for the CFG_SET/CFG_ACK exchange. The use of the ENCDNS_DIGEST_INFO attribute for these messages is provided for completeness.¶
This section describes how the attributes defined in Section 3 are used to configure an IKEv2 initiator with one or more encrypted DNS resolvers. As a reminder, badly formatted attributes or unacceptable fields are handled as per Section 2.21 of [RFC7296].¶
Initiators first indicate support for encrypted DNS by including ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply encrypted DNS configuration by including ENCDNS_IP* attributes in their CFG_REPLY payloads. Concretely:¶
The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS resolver certificate using the authentication domain name conveyed in ENCDNS_IP*.¶
If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client has to create an SPKI hash (Section 5) of the DNS resolver certificate received in the TLS handshake using the negotiated hash algorithm in the ENCDNS_DIGEST_INFO attribute. If the computed digest for an ADN matches the one sent in the ENCDNS_DIGEST_INFO attribute, the encrypted DNS resolver certificate is successfully validated. If so, the client continues with the TLS connection as normal. Otherwise, the client MUST treat the resolver certificate validation failure as a non-recoverable error. This approach is similar to certificate usage PKIX-EE(1) with selector SPKI(1) defined in [RFC7671] but without PKIX validation.¶
If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS client resolves the internal names using ENCDNS_IP* DNS resolvers.¶
The SPKI hash of the encrypted DNS resolver certificate is the output of a cryptographic hash algorithm whose input is the DER-encoded ASN.1 representation of the SPKI.¶
This document adheres to the security considerations defined in [RFC7296]. In particular, this document does not alter the trust on the DNS configuration provided by a responder.¶
Networks are susceptible to internal attacks as discussed in Section 3.2 of [I-D.arkko-farrell-arch-model-t]. Hosting encrypted DNS resolvers even in case of split-VPN configuration can minimize the attack vector (e.g., a compromised network device cannot monitor/modify DNS traffic). This specification describes a mechanism to restrict access to the DNS messages to only the parties that need to know.¶
The initiator may trust the encrypted DNS resolvers supplied by means of IKEv2 from a trusted responder more than the locally provided DNS resolvers, especially in the case of connecting to unknown or untrusted networks (e.g., coffee shops or hotel networks).¶
If the IKEv2 responder has used NULL Authentication method [RFC7619] to authenticate itself, the initiator MUST NOT use returned ENCDNS_IP* resolvers configuration unless it is pre-configured, e.g., in the operating system or the application.¶
This specification does not extend the scope of accepting DNSSEC trust anchors beyond the usage guidelines defined in Section 6 of [RFC8598].¶
As discussed in [RFC9076], the use of encrypted DNS does not reduce the data available in the DNS resolver. For example, the reader may refer to Section 8 of [RFC8484] or Section 7 of [RFC9250] for a discussion on specific privacy considerations to encrypted DNS.¶
This document requests IANA to assign the following new IKEv2 Configuration Payload Attribute Types from the "IKEv2 Configuration Payload Attribute Types" namespace available at [IANA-IKE-CFG].¶
Multi- Value Attribute Type Valued Length Reference ------ ------------------ ----- --------- --------- TBA1 ENCDNS_IP4 YES 0 or more RFC XXXX TBA2 ENCDNS_IP6 YES 0 or more RFC XXXX TBA3 ENCDNS_DIGEST_INFO YES 0 or more RFC XXXX¶
Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy Pauly for the review and comments.¶
Yoav and Paul suggested the use of one single attribute carrying both the name and an IP address instead of depending on the existing INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.¶
Thanks to Tero Kivinen for the Shepherd review and Roman Danyliw for the AD review.¶
Thanks to Stewart Bryant for the gen-art review, Dhruv Dhody for the ops-dir review, and Patrick Mevzek for the dns-dir review.¶
Thanks to Paul Wouters, Zaheduzzaman Sarker, Eric Vyncke, and Robert Wilton for the comments during the IESG review.¶
This section provides some sample cases for the use of the attributes defined in this document. This section does not intend to be comprehensive.¶
In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming user connects to the Enterprise network through an IPsec tunnel. The split-tunnel VPN configuration allows the endpoint to access hosts that reside in the Enterprise network [RFC8598] using that tunnel; other traffic not destined to the Enterprise does not traverse the tunnel. In contrast, a non-split-tunnel VPN configuration causes all traffic to traverse the tunnel into the Enterprise.¶
For both split- and non-split-tunnel configurations, the use of encrypted DNS instead of Do53 provides privacy and integrity protection along the entire path (rather than just to the VPN termination device) and can communicate the encrypted DNS resolver policies.¶
For split-tunnel VPN configurations, the endpoint uses the Enterprise-provided encrypted DNS resolver to resolve internal-only domain names. These names may be configured to the endpoints using Enterprise-specific provisioning mechanisms or the INTERNAL_DNS_DOMAIN attribute.¶
For non-split-tunnel VPN configurations, the endpoint uses the Enterprise-provided encrypted DNS resolver to resolve both internal and external domain names.¶
VPN service providers usually preserve end-users' data confidentiality by sending all communication traffic through an encrypted tunnel. A VPN service provider can also provide guarantees about the security of the VPN network by filtering malware and phishing domains.¶
Browsers and operating systems support DoH/DoT; VPN providers may no longer expect DNS clients to fall back to Do53 just because it is a closed network.¶
The encrypted DNS resolver hosted by the VPN service provider can be securely discovered by the endpoint using the IKEv2 attributes specified in Section 3.1.¶
VPN service providers typically allow split-tunnel VPN configuration in which users can choose applications that can be excluded from the tunnel. For example, users may exclude applications that restrict VPN access.¶
The encrypted DNS resolver hosted by the VPN service provider can be securely discovered by the endpoint using the IKEv2 attributes specified in Section 3.1.¶
Figure 4 depicts an example of a CFG_REQUEST to request the configuration of IPv6 DNS resolvers without providing any suggested values. In this example, the initiator uses the ENCDNS_DIGEST_INFO attribute to indicate that the encrypted DNS client supports SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash algorithms for certificate digests. The label of these algorithms is taken from [IANA-IKE-HASH]. The use of INTERNAL_IP6_ADDRESS is explained in [RFC7296]; it is thus not reiterated here.¶
CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
Figure 5 depicts an example of a CFG_REPLY that can be sent by a responder as a response the above CFG_REQUEST. This response indicates the following information to identify the encrypted DNS resolver:¶
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44),
"doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns}))
ENCDNS_DIGEST_INFO(0, SHA2-256,
8b6e7a5971cc6bb0b4db5a71...)
In the example depicted in Figure 5, no ADN is included in the ENCDNS_DIGEST_INFO attribute because only one ADN is provided in the ENCDNS_IP6 attribute. There is no ambiguity to identify the encrypted resolver associated with the supplied digest.¶
An initiator may provide suggested values in the CFG_REQUEST when requesting an encrypted DNS resolver. For example, the initiator may:¶
Indicate a preferred resolver that is identified by an IPv6 address (see Figure 6).¶
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 1, 0,
(2001:db8:99:88:77:66:55:44))
Indicate a preferred resolver that is identified by an ADN (see Figure 7).¶
CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 0, 15, "doh.example.com")
Indicate a preferred transport protocol (DoT, in the example depicted in Figure 8)¶
CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6(1, 0, 0, (alpn=dot))
An initiator may also indicate that it supports Split DNS by including the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST as shown in Figure 9. In this example, the initiator does not indicate any preference for the requested encrypted DNS server nor which DNS queries will be forwarded through the IPsec tunnel.¶
CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() INTERNAL_DNS_DOMAIN()
Figure 10 shows an example of a reply of the responder. Absent any prohibited local policy, the initiator uses the encrypted DNS server (doh.example.com) for any subsequent DNS queries for "example.com" and its subdomains.¶
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44),
"doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns}))
INTERNAL_DNS_DOMAIN(example.com)