]> VeriSign, Inc.

Reston VA USA eosterweil@verisign.com

VeriSign, Inc.

Reston VA USA gwiley@verisign.com

VeriSign, Inc.

Reston VA USA tomokubo@Verisign.com

VeriSign, Inc.

Reston VA USA RLavu@verisign.com

VeriSign, Inc.

Reston VA USA amohaisen@verisign.com

SEC DANE The query/response transactions of the Domain Name System (DNS) can disclose valuable meta-data about the online activities of DNS' users. The DNS Security Extensions (DNSSEC) provide object-level security, but do not attempt to secure the DNS transaction itself. For example, DNSSEC does not protect against information leakage, and only protects DNS data until the last validating recursive resolver. Stub resolvers are vulnerable to adversaries in the network between themselves and their validating resolver ("the last mile"). This document details a new DANE-like DNS Resource Record (RR) type called IPSECA, and explains how to use it to bootstrap DNS transactions through informing entries in IPsec Security Policy Databases (SPDs) and to subsequently verifying Security Associations (SAs) for OE IPsec tunnels.

The query/response transactions of the Domain Name System (DNS) can disclose valuable meta-data about the online activities of DNS' users. The DNS Security Extensions' (DNSSEC's) , , core services (integrity, source authenticity, and secure denial of existence) are designed to secure data in DNS transactions by providing object-level security, but do not attempt to secure the DNS transaction itself. For example, DNSSEC does not attempt to protect the confidentiality of DNS transactions, does not protect data outside of the RRsets (including the DNS header, OPT record, etc.), and its DNS-specific protections expose opportunities for adversaries to identify DNS traffic, eavesdrop on DNS messages, and target DNS and its meta-data for attacks. As a result, a clever adversary may target just DNS traffic, discover the nature of a user's online browsing (from fully qualified domain names), interfere with the delivery of specific messages (though the DNS objects are not forgeable), or even attack "the last mile," between a resolver and a remote validating recursive resolver. For example, the information leakage exposed by observing DNSSEC transactions, could enable an adversary to not only learn what Second Level Domains (SLDs) a user is querying (such as their bank, a funding agency, a security contractor, etc.), but could also inspect the fully qualified domain name(s) to learn the specific hosts visited, or in the case of certain DNS-based chat programs, information about ongoing conversations. In addition, DNSSEC's design only protects DNS data until the last validating recursive resolver. If a client issues DNS queries from a stub resolver to a remote DNSSEC-aware resolver, then the network between these two ("the last mile") can be leveraged by an adversary to spoof responses, drop traffic, etc. Clearly, these limitations do not invalidate the benefits of DNSSEC. DNSSEC still protects the actual DNS objects, protects against cache poisoning attacks, and more. Rather, these limitations simply illustrate that there is more at stake than just valid DNS data. This document details the motivation for, the synergy from, and a protocol to advertise and verify security credentials that can be used to verify Opportunistic Encryption (OE) IPsec , tunnels for DNS transactions. Securing DNS transactions in this way is both necessary and sufficient for providing confidentiality of many types of DNS-transaction meta data, which can betray user privacy. This document details a new DANE-like DNS Resource Record (RR) type called IPSECA, and explains how to use it to bootstrap entries in IPsec Security Policy Databases (SPDs) and to subsequently verify Security Associations (SAs) for OE IPsec tunnels.

DNSSEC's focus on object level security leaves the types of protections offered by IPsec unaddressed. Specifically, the way (or ways) to associate certificate(s) used by IPsec with a DNSSEC-aware name server need to be codified. This can be especially complicated if different IPsec certificates need to be discovered for different services that are running on the same IP address. This can become complicated if certificates are learned solely by the IP addresses of networked-services. This gap is inherently overcome during certificate discovery in DANE protocols by the concept of "Service Address Records," . These Security Associations are defined by, and discovered by, domain names rather than just IP addresses. standardizes a way for security associations of certificates to be made with service domains for TLS, rather than just IP addresses. As one of the underlying facilities of DANE's approach to certificate verification, this adds a necessary enhancement to IPsec certificate learning over approaches that are based solely on IP addresses in DNS (such as described in and ). The advantages of using DANE for IPsec OE also include other simplifications that the DANE protocol inherently offers all of its protocols. Such as, the automatic deauthorization of certificates that happens when they are removed from a DNS zone, which may (under many circumstances) obviate the need for extensive use of revocation mechanisms (OCSP or CRL ). Details of these relative trade offs is described in more detail in . It is also noteworthy that DANE offers flexibility that is not available in IP-centric certificate discovery and IP-centric OE , while still being backwards compatible with them. That is, while users can use IPSECA records to map OE IPsec tunnels to service names, they can also use IPSECA records in their reverse DNS zone in a similar fashion to the IPSECKEY record used in . However, while this document illustrates an example usage of DANE with IPsec OE, any specification for how the IPSECA resource record MUST get used with OE is beyond the scope of this document.

In contrast to a DANE-centric discovery, specifies a DNS resource record called IPSECKEY. The IPsec certificate learning described therein prescribes that relying parties learn the intended usage of IPsec certificates after they locate them in DNS and retrieve them. The types of information that relying parties learn from IPSECKEY responses include: precedence, gateway type, algorithm, gateway, and possibly the public key. After learning the key and creating the Security Association, the relying party can use techniques like to initialize an OE IPsec tunnel. The inherent key learning and verification technique in is based on learning tunnels from IP addresses only (IP-centric). Because of this technique's focus on IP-centric learning, operational entities running services on a specific IP address may not have access to annotate the reverse DNS zone for their services (especially if they are shared environments). So, this type of OE may often be a non-starter. One example would be when zones are hosted and/or served by cloud service providers. In this case, customers are almost certainly not allowed to annotate the reverse DNS zone for their providers.

The suggested usage of this document is to aid in discovering where OE IPsec tunnels exist, and to act as an out of band verification substrate that can validate the certificates received during IPsec key exchange. For example, if a DNS caching recursive resolver is configured to attempt OE IPsec tunnels to DNS name servers (using a specific key exchange protocol, like , , etc.), then when it receives a referral it SHOULD query name servers for corresponding IPSECA resource records. (we discuss the format of the resource record and domain names below in ). When an IPSECA record is discovered by a resolver, that resolver SHOULD follow its configurations and setup an SPD entry, in order to signal its IPsec layer to attempt to attempt to establish an SA. Note, this document does not specify a new, or any modifications to any existing, IPsec key exchange protocols. Rather, after adding an SPD and after a successful tunnel establishment, the credentials used for the Security Association with the name server SHOULD be cross-checked with the IPSECA resource record(s). When using IPSECA resource records to verify OE tunnels, clients MUST perform full DNSSEC validation of the DNSSEC chain of trust that leads to IPSECA RRs. As specified in : "A [IPSECA] RRSet whose DNSSEC validation state is secure MUST be used as a certificate association for [IPsec] unless a local policy would prohibit the use of the specific certificate association in the secure TLSA RRSet. If the DNSSEC validation state on the response to the request for the [IPSECA] RRSet is bogus, this MUST cause IPsec not to be started or, if the IPsec negotiation is already in progress, MUST cause the connection to be aborted. A [IPSECA] RRSet whose DNSSEC validation state is indeterminate or insecure cannot be used for [IPsec] and MUST be considered unusable." This is to ensure that the SPD entries and SA(s) used for tunnels are fully verified. This verification MAY include local trust anchor processing, such that local DNSKEY resource records can be used to verify corresponding RRSIGs. Trust anchors (which may be distributed during dynamic host configuration) may be useful for bootstrapping. For example, consider the case where private address space is used for internal recursive resolvers. Here, the locally provisioned DNS names for the private address space (in the reverse tree) that are secured using DNSSEC MAY use local trust anchors. That is, if an address is used internally, the corresponding domain name MUST also resolve and be verifiable through DNS and DNSSEC, but a local trust anchor MAY be used to verify covered RRSIGs. This shifts the onus of securing DNS transactions to the initial configuration step. The intuition behind this reasons that if the first (configuration) step was already where the local resolver was configured, then the security of the DNS transactions already hinged on learning the valid resolver this way. So, this step is already used to convey trusted configurations (bootstrapping). Adversaries attempting to subvert an end host have only the narrow attack window that is associated with learning configurations. In contrast, an insecure DNS resolver offers an attack window every time it issues or responds to a query. We discuss this further in .

The IPSECA resource record is modeled heavily off of the IPSECKEY RR , but it differs in significant ways. The format of IPSECA is harmonized with the architectural direction set by other DANE work , .

The meaning, semantics, and interpretation of the Usage field of the IPSECA resource record follow the specification described in Section 2.1 of : Value Acronym Short Description Reference 0 PKIX-TA CA constraint 1 PKIX-EE Service certificate constraint 2 DANE-TA Trust anchor assertion 3 DANE-EE Domain-issued certificate 4-254 Unassigned 255 PrivCert Reserved for Private Use

The meaning, semantics, and interpretation of the Selector field of the IPSECA resource record follow the specification described in Section 2.2 of : Value Acronym Short Description Reference 0 Cert Full certificate 1 SPKI SubjectPublicKeyInfo 2 DANE-TA Trust anchor assertion 3-254 Unassigned 255 PrivSel Reserved for Private Use

The meaning, semantics, and interpretation of the Matching field of the IPSECA resource record follow the specification described in Section 2.3 of : Value Acronym Short Description Reference 0 Full No hash used 1 SHA2-256 256 bit hash by SHA2 2 SHA2-512 512 bit hash by SHA2 3-254 Unassigned 255 PrivMatch Reserved for Private Use

The meaning, semantics, and interpretation of the Certificate Association Data field of the IPSECA resource record follow the specification of the same field in the TLSA resource record, described in Section 2.1.4 of : "This field specifies the 'certificate association data' to be matched. These bytes are either raw data (that is, the full certificate or its SubjectPublicKeyInfo, depending on the selector) for matching type 0, or the hash of the raw data for matching types 1 and 2. The data refers to the certificate in the association, not to the TLS ASN.1 Certificate object."

</STUBBED OUT SECTION>

The IPSECA resource record SHOULD be mapped to a domain name that is intuitive when discovering OE IPsec tunnels for specific services. The expected procedure for constructing the domain names for IPSECA records that enable OE for DNS (port 53) are: The left-most label begins with an underscore character (_), followed by the decimal representation of the port number that corresponds to the service that should be conducted over IPsec. For example, the DNS transactions discussed in this document would result in "_53". Next, the fully qualified domain name of the service is appended to the right side. In the case of a DNS name server, that is its domain name. In the case of a service that is locate using an IP address, the service address records MUST be its full reverse octet name (including the appropriate suffix, such as .in-addr.arpa. for IPv4 addresses and .ip6.arpa for IPv6 addresses). Any custom configured tunnels and port mappings may result local policies that use their own domain name format. Such custom OE tunnels are non-standard, and may not be discoverable by other relying parties.

Because the IPSECA record is intended to be associated with a Service Address Records, it (implicitly) can also be associated with an IP address (through the reverse DNS). A few illustrative mappings are presented here as examples. These domain name / resource record mappings are not necessarily intended to update the processing of protocols like IKEv1 , IKEv2 , etc. or other OE protocols . Rather, these mappings are intended to serve as examples of IPsec tunnels, and their proper configuration. They MAY be used in verifying Security Associations, but a protocol to do this is beyond the scope of this document.

Suppose a DNS zone example.com is served by the name servers ns1.example.com and ns2.example.com. If the zone operators want to advertise their willingness to offer OE to their name servers using IKEv2 , then the following domain names MUST be placed under the example.com zone (the contents of the resource records, below, are exemplary only and MAY have whatever values a zone operator chooses):

_53.ns1.example.com. IN IPSECA ( 0 1 1 edeff39034cd2ee83446633a9fba d815a579134ecd7636e51af92ec7 207fd490 ) ; Verify IPsec for DNS txns _53.ns2.example.com. IN IPSECA ( 0 1 1 edeff39034cd2ee83446633a9fba d815a579134ecd7636e51af92ec7 207fd490 ) ; Verify IPsec for DNS txns This example illustrates how a zone MAY indicate where an SPD entry and SA establishment endpoints exist for its name servers (note, they are not required to be the name servers themselves). Here, each name server is a tunnel end point, and these two name servers are mapped to service ports for DNS (port 53). The IPSECA records above indicate that they verify the CA who must have issued the IPsec certificate used and they represent a SHA256 hash of that certificate's SPKI.

Alternately, suppose an enterprise wants to configure OE for DNS transactions between its desktop clients and its recursive resolver. In this case, if the enterprise has configured their desktop clients (perhaps through DHCP) to forward their DNS queries to a caching recursive resolver at the IP address 192.168.1.2, then the following IPSECA mapping should be placed in an internally managed DNS reverse zone:

_53.2.1.168.192.in-addr.arpa. IN IPSECA ( 3 0 2 8f6ea3c50b5c488bef74c7c4a17a 24e8b0f4777d13c211a29223b69a ea7a89184ac4d272a2e3d9760966 fb3f220b39f7fdfb325998289e50 311ce0748f13c1ed ) ; Verify data in IKEv2 SA This example illustrates how a caching recursive resolver MAY indicate where it will accept IPsec tunnel establishment and what the certificate used for a SA should be. Here the DNS service port and the IPSECA records describe the nature of the authentic certificate that SHOULD be used in an SA with this endpoint. In this example, the IPSECA records both specify that a DANE-EE cert should be expected in an SA with this resolver, and the SHA-512 hash of that full certificate should match the encoded value in the IPSECA resource record.

Of note here is that since SAs MAY be identified by domain names (which map to IP addresses), some IP addresses may host services that offer IPsec, and some that do not. The IPSECA record allows hosts to advertise these nuanced configurations in the same way that these services are discovered (through the DNS itself).

Scaling IPsec connections to the full capacity that large recursive resolvers or large authoritative name servers operate at could be cause for concern. The additional overhead required to establish and maintain SAs could exceed the provisioning capacity of deployed systems. However, there are several relevant observations: If a resolver enables OE, but no (or relatively few) name servers provision IPSECA records, then no IPsec tunnels will be established, and the load will remain static (or marginally increase). If an authoritative name server provisions IPSECA record, it will only result in additional load if querying resolvers are configured to attempt OE. Using white-listing techniques (such as those used during pilot deployments of AAAA records) would allow authoritative name servers to only return IPSECA responses to clients that have been white-listed. This would allow name servers to control the amount of IPsec overhead they incur. For the same reason, resolvers can be configured to only query for IPSECA records from white-listed name servers.

This document uses a new DNS resource record type, called IPSECA. This resource record will need to have a new value assigned to it. Current implementations are advised to use a type number TYPE65347. This document uses the same semantics and values as the TLSA resource record for its Usage, Selector, and Matching fields. Any future use or modification of an IANA registry for that resource record will have similar effects on this resource record.

This document details some of the benefits of using IPsec OE for DNS transactions. Such a utility does not reduce the benefits of other security protections. For example, the object-level security assurances that are offered by DNSSEC are cooperative with the session-level security of IPsec. Additional discussions are available in . Moreover, the protections described herein also offer cooperative benefits with higher layer protocol protections, like TLS . Any combination of these types of protections offer both defense-in-depth (securing transactions at multiple levels) and offer security practitioners a larger mosaic of security tools from which to construct and maintain their security postures.

This document requires that all fully qualified domain names must be secured by DNSSEC. This includes domains in the reverse tree of DNS (which represent IP addresses). The use of IPSECA resource records does not constitute a source of information leakage. Rather, it provides a mechanism to help bolster confidentiality, by obfuscating DNS transactions. Expressing tunnel endpoints through DNS may allow adversaries a vehicle to learn where OE is being offered by name servers. However, OE tunnels to these name servers will only be attempted if querying resolvers are configured to attempt IPsec. As a result, adversaries may be able to learn of potential tunnel endpoints, but if they aim to disrupt active IPsec traffic, they must still observe which resolvers are trying to initiate IPsec communications. Therefore, adversaries would have no greater opportunity to disrupt IPsec traffic than they already do. They would still begin by (for example) observing VPN tunnel setup on wireless LANs (such as at public WiFi hot-spots).

For the last mile, we define one type of attack as the case where an adversary intercepts messages that can be undetectably spoofed. For example, if a zone (like example.com) has deployed DNSSEC, then if an adversary responds to a DNS query for www.exmaple.com, a validating DNS resolver should be able to detect the forgery. However, if an adversary responds to a query that is sent for a non-DNSSEC zone, a resolver cannot distinguish the spoofed response from an authentic response. In addition to this, many bootstrapping protocols (such as DHCP ) represent the first opportunity for an adversary to disrupt DNS transactions (by subverting the bootstrapping of the resolver itself on stub-resolvers). Under this model, a DNS stub-resolver's security posture is enhanced by keeping an adversary's attack window to the smallest value possible. Therefore, the attack window offered by DNS clients in a given time span T is comprised of the set of transactions that bootstrap configurations W_cfg(T), plus any DNS transactions that are not verifiable. Of note, however, is that the DNSSEC transactions between stub-resolvers and recursive resolvers are not protected by DNSSEC's cryptography. The only indication of protections is a header bit (the AD bit), which is spoofable. As a result, the attack window includes all DNS transactions W_rDNS(T). From this, the attack window can be expressible as: W(T) = W_cfg(T) + W_rDNS(T) Of note is that under most circumstances, resolvers issue many more queries than configuration requests. So, W_cfg(T) = 1, and W_rDNS(T) >> W_cfg(T). However, consider the attack window when using OE: {W(T)}. If the initial configuration includes a DNSKEY trust anchor that can be used to verify DNSSEC data that corresponds to a resolver's corresponding reverse zone (i.e., the IPSECA RR under in-addr.arpa or ip6.arpa), then {W_cfg(T)} = 1 and {W_rDNS(T)} = 0. Therefore, since W_rDNS(T) >> W_cfg(T) and {W_rDNS(T)} = 0, then by the transitive property, W(T) >> {W(T)}.

The editors would like to express their thanks for the early support and insights given by Danny McPherson.

&RFC1035; &RFC1918; &RFC4033; &RFC4034; &RFC4035; &RFC4301; &RFC6698; &RFC2131; &RFC2409; &RFC3596; &RFC4025; &RFC4322; &RFC5246; &RFC5280; &RFC5996; &RFC6071; &RFC6960;

<STUBBED OUT SECTION> NAME SERVER SIDE Config SPD to accept connections from any on port 53 only Zones add IPSECA RRs for each NS domain name and configure DNSSEC: <examples> RESOLVER SIDE resolver processing logic to intercept referrals and look for IPSECA RR(s). When an IPSECA RR is found, create SPD for that IP and port 53. </STUBBED OUT SECTION>

<STUBBED OUT SECTION> RESOLVER SIDE If public resolver, create SPD entry that only allows IPsec from port 53. If internal resolver, limit to addresses serviced. REVERSE DNS ZONE Add IPSECA RR(s) and configure DNSSEC STUB SIDE Configure reverse zone DNSKEY (if 1918) as a local TA (such as over DHCP). Then do onetime DNSSEC validation for fetching IPSECA RR. Tools include dnskey-grab and/or NLnet Labs' xxxxx. </STUBBED OUT SECTION>