idnits 2.17.00 (12 Aug 2021) /tmp/idnits46495/draft-osterweil-dane-ipsec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 179: '... record MUST get used with OE is bey...' RFC 2119 keyword, line 212: '...es a referral it SHOULD query name ser...' RFC 2119 keyword, line 215: '...olver, that resolver SHOULD follow its...' RFC 2119 keyword, line 221: '... the name server SHOULD be cross-check...' RFC 2119 keyword, line 224: '...rds to verify OE tunnels, clients MUST...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2015) is 2615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPSECA' is mentioned on line 238, but not defined == Missing Reference: 'IPsec' is mentioned on line 239, but not defined == Unused Reference: 'RFC3596' is defined on line 637, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE E. Osterweil 3 Internet-Draft G. Wiley 4 Intended status: Standards Track T. Okubo 5 Expires: September 25, 2015 R. Lavu 6 A. Mohaisen 7 VeriSign, Inc. 8 March 24, 2015 10 Opportunistic Encryption with DANE Semantics and IPsec: IPSECA 11 draft-osterweil-dane-ipsec-02 13 Abstract 15 The query/response transactions of the Domain Name System (DNS) can 16 disclose valuable meta-data about the online activities of DNS' 17 users. The DNS Security Extensions (DNSSEC) provide object-level 18 security, but do not attempt to secure the DNS transaction itself. 19 For example, DNSSEC does not protect against information leakage, and 20 only protects DNS data until the last validating recursive resolver. 21 Stub resolvers are vulnerable to adversaries in the network between 22 themselves and their validating resolver ("the last mile"). This 23 document details a new DANE-like DNS Resource Record (RR) type called 24 IPSECA, and explains how to use it to bootstrap DNS transactions 25 through informing entries in IPsec Security Policy Databases (SPDs) 26 and to subsequently verifying Security Associations (SAs) for OE 27 IPsec tunnels. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 25, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. What IPSECA Adds to DNSSEC Transactions . . . . . . . . . 4 65 1.2. IP-Centric IPsec Tunnel Discovery Using IPSECKEY . . . . . 4 66 1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA 67 and DANE . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. The IPSECA Resource Record . . . . . . . . . . . . . . . . . . 6 69 2.1. IPSECA RDATA Wire Format . . . . . . . . . . . . . . . . . 7 70 2.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 7 71 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 7 72 2.1.3. The Matching Field . . . . . . . . . . . . . . . . . . 8 73 2.1.4. The Certificate Assocation Data Field . . . . . . . . 8 74 2.2. IPSECA RR Presentation Format . . . . . . . . . . . . . . 9 75 2.3. Domain Names used for IPSEC Records . . . . . . . . . . . 9 76 2.4. IPSECA RR Examples . . . . . . . . . . . . . . . . . . . . 9 77 2.4.1. OE to a DNS Name Server Example . . . . . . . . . . . 9 78 3. Operational Considerations . . . . . . . . . . . . . . . . . . 11 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 5.1. Interactions . . . . . . . . . . . . . . . . . . . . . . . 12 82 5.2. Last Mile Security Analysis . . . . . . . . . . . . . . . 12 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Appendix A. Name Server OE Configuration Example . . . . . . . . 15 88 Appendix B. Recursive Resolver OE Configuration Example . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The query/response transactions of the Domain Name System (DNS) 94 [RFC1035] can disclose valuable meta-data about the online activities 95 of DNS' users. The DNS Security Extensions' (DNSSEC's) [RFC4033], 96 [RFC4034], [RFC4035] core services (integrity, source authenticity, 97 and secure denial of existence) are designed to secure data in DNS 98 transactions by providing object-level security, but do not attempt 99 to secure the DNS transaction itself. For example, DNSSEC does not 100 attempt to protect the confidentiality of DNS transactions, does not 101 protect data outside of the RRsets (including the DNS header, OPT 102 record, etc.), and its DNS-specific protections expose opportunities 103 for adversaries to identify DNS traffic, eavesdrop on DNS messages, 104 and target DNS and its meta-data for attacks. As a result, a clever 105 adversary may target just DNS traffic, discover the nature of a 106 user's online browsing (from fully qualified domain names), interfere 107 with the delivery of specific messages (though the DNS objects are 108 not forgeable), or even attack "the last mile," between a resolver 109 and a remote validating recursive resolver. 111 For example, the information leakage exposed by observing DNSSEC 112 transactions, could enable an adversary to not only learn what Second 113 Level Domains (SLDs) a user is querying (such as their bank, a 114 funding agency, a security contractor, etc.), but could also inspect 115 the fully qualified domain name(s) to learn the specific hosts 116 visited, or in the case of certain DNS-based chat programs, 117 information about ongoing conversations. 119 In addition, DNSSEC's design only protects DNS data until the last 120 validating recursive resolver. If a client issues DNS queries from a 121 stub resolver to a remote DNSSEC-aware resolver, then the network 122 between these two ("the last mile") can be leveraged by an adversary 123 to spoof responses, drop traffic, etc. 125 Clearly, these limitations do not invalidate the benefits of DNSSEC. 126 DNSSEC still protects the actual DNS objects, protects against cache 127 poisoning attacks, and more. Rather, these limitations simply 128 illustrate that there is more at stake than just valid DNS data. 130 This document details the motivation for, the synergy from, and a 131 protocol to advertise and verify security credentials that can be 132 used to verify Opportunistic Encryption (OE) IPsec [RFC4301], 133 [RFC6071] tunnels for DNS transactions. Securing DNS transactions in 134 this way is both necessary and sufficient for providing 135 confidentiality of many types of DNS-transaction meta data, which can 136 betray user privacy. This document details a new DANE-like [RFC6698] 137 DNS Resource Record (RR) type called IPSECA, and explains how to use 138 it to bootstrap entries in IPsec Security Policy Databases (SPDs) and 139 to subsequently verify Security Associations (SAs) for OE IPsec 140 tunnels. 142 1.1. What IPSECA Adds to DNSSEC Transactions 144 DNSSEC's focus on object level security leaves the types of 145 protections offered by IPsec unaddressed. Specifically, the way (or 146 ways) to associate certificate(s) used by IPsec with a DNSSEC-aware 147 name server need to be codified. This can be especially complicated 148 if different IPsec certificates need to be discovered for different 149 services that are running on the same IP address. This can become 150 complicated if certificates are learned solely by the IP addresses of 151 networked-services. This gap is inherently overcome during 152 certificate discovery in DANE protocols by the concept of "Service 153 Address Records," [I-D.draft-ogud-dane-vocabulary]. These Security 154 Associations are defined by, and discovered by, domain names rather 155 than just IP addresses. [RFC6698] standardizes a way for security 156 associations of certificates to be made with service domains for TLS, 157 rather than just IP addresses. As one of the underlying facilities 158 of DANE's approach to certificate verification, this adds a necessary 159 enhancement to IPsec certificate learning over approaches that are 160 based solely on IP addresses in DNS (such as described in [RFC4025] 161 and [RFC4322]). 163 The advantages of using DANE for IPsec OE also include other 164 simplifications that the DANE protocol inherently offers all of its 165 protocols. Such as, the automatic deauthorization of certificates 166 that happens when they are removed from a DNS zone, which may (under 167 many circumstances) obviate the need for extensive use of revocation 168 mechanisms (OCSP [RFC6960] or CRL [RFC5280]). Details of these 169 relative trade offs is described in more detail in [DANE_SATIN12]. 171 It is also noteworthy that DANE offers flexibility that is not 172 available in IP-centric certificate discovery and IP-centric OE 173 [RFC4322], while still being backwards compatible with them. That 174 is, while users can use IPSECA records to map OE IPsec tunnels to 175 service names, they can also use IPSECA records in their reverse DNS 176 zone in a similar fashion to the IPSECKEY [RFC4025] record used in 177 [RFC4322]. However, while this document illustrates an example usage 178 of DANE with IPsec OE, any specification for how the IPSECA resource 179 record MUST get used with OE is beyond the scope of this document. 181 1.2. IP-Centric IPsec Tunnel Discovery Using IPSECKEY 183 In contrast to a DANE-centric discovery, [RFC4025] specifies a DNS 184 resource record called IPSECKEY. The IPsec certificate learning 185 described therein prescribes that relying parties learn the intended 186 usage of IPsec certificates after they locate them in DNS and 187 retrieve them. The types of information that relying parties learn 188 from IPSECKEY responses include: precedence, gateway type, algorithm, 189 gateway, and possibly the public key. After learning the key and 190 creating the Security Association, the relying party can use 191 techniques like [RFC4322] to initialize an OE IPsec tunnel. 193 The inherent key learning and verification technique in [RFC4322] is 194 based on learning tunnels from IP addresses only (IP-centric). 195 Because of this technique's focus on IP-centric learning, operational 196 entities running services on a specific IP address may not have 197 access to annotate the reverse DNS zone for their services 198 (especially if they are shared environments). So, this type of OE 199 may often be a non-starter. One example would be when zones are 200 hosted and/or served by cloud service providers. In this case, 201 customers are almost certainly not allowed to annotate the reverse 202 DNS zone for their providers. 204 1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA and DANE 206 The suggested usage of this document is to aid in discovering where 207 OE IPsec tunnels exist, and to act as an out of band verification 208 substrate that can validate the certificates received during IPsec 209 key exchange. For example, if a DNS caching recursive resolver is 210 configured to attempt OE IPsec tunnels to DNS name servers (using a 211 specific key exchange protocol, like [RFC2409], [RFC5996], etc.), 212 then when it receives a referral it SHOULD query name servers for 213 corresponding IPSECA resource records. (we discuss the format of the 214 resource record and domain names below in Section 2). When an IPSECA 215 record is discovered by a resolver, that resolver SHOULD follow its 216 configurations and setup an SPD entry, in order to signal its IPsec 217 layer to attempt to attempt to establish an SA. Note, this document 218 does not specify a new, or any modifications to any existing, IPsec 219 key exchange protocols. Rather, after adding an SPD and after a 220 successful tunnel establishment, the credentials used for the 221 Security Association with the name server SHOULD be cross-checked 222 with the IPSECA resource record(s). 224 When using IPSECA resource records to verify OE tunnels, clients MUST 225 perform full DNSSEC validation of the DNSSEC chain of trust that 226 leads to IPSECA RRs. As specified in [RFC6698]: 228 "A [IPSECA] RRSet whose DNSSEC validation state is secure MUST be 229 used as a certificate association for [IPsec] unless a local 230 policy would prohibit the use of the specific certificate 231 association in the secure TLSA RRSet. 233 If the DNSSEC validation state on the response to the request for 234 the [IPSECA] RRSet is bogus, this MUST cause IPsec not to be 235 started or, if the IPsec negotiation is already in progress, MUST 236 cause the connection to be aborted. 238 A [IPSECA] RRSet whose DNSSEC validation state is indeterminate or 239 insecure cannot be used for [IPsec] and MUST be considered 240 unusable." 242 This is to ensure that the SPD entries and SA(s) used for tunnels are 243 fully verified. This verification MAY include local trust anchor 244 processing, such that local DNSKEY resource records can be used to 245 verify corresponding RRSIGs. Trust anchors (which may be distributed 246 during dynamic host configuration) may be useful for bootstrapping. 247 For example, consider the case where private address space [RFC1918] 248 is used for internal recursive resolvers. Here, the locally 249 provisioned DNS names for the private address space (in the reverse 250 tree) that are secured using DNSSEC MAY use local trust anchors. 251 That is, if an [RFC1918] address is used internally, the 252 corresponding domain name MUST also resolve and be verifiable through 253 DNS and DNSSEC, but a local trust anchor MAY be used to verify 254 covered RRSIGs. This shifts the onus of securing DNS transactions to 255 the initial configuration step. The intuition behind this reasons 256 that if the first (configuration) step was already where the local 257 resolver was configured, then the security of the DNS transactions 258 already hinged on learning the valid resolver this way. So, this 259 step is already used to convey trusted configurations 260 (bootstrapping). Adversaries attempting to subvert an end host have 261 only the narrow attack window that is associated with learning 262 configurations. In contrast, an insecure DNS resolver offers an 263 attack window every time it issues or responds to a query. We 264 discuss this further in Section 5.2. 266 2. The IPSECA Resource Record 268 The IPSECA resource record is modeled heavily off of the IPSECKEY RR 269 [RFC4025], but it differs in significant ways. The format of IPSECA 270 is harmonized with the architectural direction set by other DANE work 271 [RFC6698], [I-D.draft-ogud-dane-vocabulary]. 273 2.1. IPSECA RDATA Wire Format 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Usage | Selector | Matching | / 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 280 | / 281 / Certificate Association Data / 282 / / 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 285 Figure 1 287 2.1.1. The Usage Field 289 The meaning, semantics, and interpretation of the Usage field of the 290 IPSECA resource record follow the specification described in Section 291 2.1 of [I.D.draft-ietf-dane-registry-acronyms]: 293 +-------+----------+--------------------------------+-----------+ 294 | Value | Acronym | Short Description | Reference | 295 +-------+----------+--------------------------------+-----------+ 296 | 0 | PKIX-TA | CA constraint | [RFC6698] | 297 | 1 | PKIX-EE | Service certificate constraint | [RFC6698] | 298 | 2 | DANE-TA | Trust anchor assertion | [RFC6698] | 299 | 3 | DANE-EE | Domain-issued certificate | [RFC6698] | 300 | 4-254 | | Unassigned | | 301 | 255 | PrivCert | Reserved for Private Use | [RFC6698] | 302 +-------+----------+--------------------------------+-----------+ 304 Table 1: TLSA Certificate Usages 306 2.1.2. The Selector Field 308 The meaning, semantics, and interpretation of the Selector field of 309 the IPSECA resource record follow the specification described in 310 Section 2.2 of [I.D.draft-ietf-dane-registry-acronyms]: 312 +-------+---------+--------------------------+-----------+ 313 | Value | Acronym | Short Description | Reference | 314 +-------+---------+--------------------------+-----------+ 315 | 0 | Cert | Full certificate | [RFC6698] | 316 | 1 | SPKI | SubjectPublicKeyInfo | [RFC6698] | 317 | 2 | DANE-TA | Trust anchor assertion | [RFC6698] | 318 | 3-254 | | Unassigned | | 319 | 255 | PrivSel | Reserved for Private Use | [RFC6698] | 320 +-------+---------+--------------------------+-----------+ 322 Table 2: TLSA Selectors 324 2.1.3. The Matching Field 326 The meaning, semantics, and interpretation of the Matching field of 327 the IPSECA resource record follow the specification described in 328 Section 2.3 of [I.D.draft-ietf-dane-registry-acronyms]: 330 +-------+-----------+--------------------------+-----------+ 331 | Value | Acronym | Short Description | Reference | 332 +-------+-----------+--------------------------+-----------+ 333 | 0 | Full | No hash used | [RFC6698] | 334 | 1 | SHA2-256 | 256 bit hash by SHA2 | [RFC6698] | 335 | 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6698] | 336 | 3-254 | | Unassigned | | 337 | 255 | PrivMatch | Reserved for Private Use | [RFC6698] | 338 +-------+-----------+--------------------------+-----------+ 340 Table 3: TLSA Matching Types 342 2.1.4. The Certificate Assocation Data Field 344 The meaning, semantics, and interpretation of the Certificate 345 Association Data field of the IPSECA resource record follow the 346 specification of the same field in the TLSA resource record, 347 described in Section 2.1.4 of [RFC6698]: 349 "This field specifies the 'certificate association data' to be 350 matched. These bytes are either raw data (that is, the full 351 certificate or its SubjectPublicKeyInfo, depending on the 352 selector) for matching type 0, or the hash of the raw data for 353 matching types 1 and 2. The data refers to the certificate in 354 the association, not to the TLS ASN.1 Certificate object." 356 2.2. IPSECA RR Presentation Format 358 360 2.3. Domain Names used for IPSEC Records 362 The IPSECA resource record SHOULD be mapped to a domain name that is 363 intuitive when discovering OE IPsec tunnels for specific services. 364 The expected procedure for constructing the domain names for IPSECA 365 records that enable OE for DNS (port 53) are: 367 1. The left-most label begins with an underscore character (_), 368 followed by the decimal representation of the port number that 369 corresponds to the service that should be conducted over IPsec. 370 For example, the DNS transactions discussed in this document 371 would result in "_53". 373 2. Next, the fully qualified domain name [RFC1035] of the service is 374 appended to the right side. In the case of a DNS name server, 375 that is its domain name. In the case of a service that is locate 376 using an IP address, the service address records MUST be its full 377 reverse octet name (including the appropriate suffix, such as 378 .in-addr.arpa. for IPv4 addresses and .ip6.arpa for IPv6 379 addresses). 381 Any custom configured tunnels and port mappings may result local 382 policies that use their own domain name format. Such custom OE 383 tunnels are non-standard, and may not be discoverable by other 384 relying parties. 386 2.4. IPSECA RR Examples 388 Because the IPSECA record is intended to be associated with a Service 389 Address Records, it (implicitly) can also be associated with an IP 390 address (through the reverse DNS). A few illustrative mappings are 391 presented here as examples. These domain name / resource record 392 mappings are not necessarily intended to update the processing of 393 protocols like IKEv1 [RFC2409], IKEv2 [RFC5996], etc. or other OE 394 protocols [RFC4322]. Rather, these mappings are intended to serve as 395 examples of IPsec tunnels, and their proper configuration. They MAY 396 be used in verifying Security Associations, but a protocol to do this 397 is beyond the scope of this document. 399 2.4.1. OE to a DNS Name Server Example 401 Suppose a DNS zone example.com is served by the name servers 402 ns1.example.com and ns2.example.com. If the zone operators want to 403 advertise their willingness to offer OE to their name servers using 404 IKEv2 [RFC5996], then the following domain names MUST be placed under 405 the example.com zone (the contents of the resource records, below, 406 are exemplary only and MAY have whatever values a zone operator 407 chooses): 409 _53.ns1.example.com. IN IPSECA ( 410 0 1 1 edeff39034cd2ee83446633a9fba 411 d815a579134ecd7636e51af92ec7 412 207fd490 ) ; Verify IPsec for DNS txns 414 _53.ns2.example.com. IN IPSECA ( 415 0 1 1 edeff39034cd2ee83446633a9fba 416 d815a579134ecd7636e51af92ec7 417 207fd490 ) ; Verify IPsec for DNS txns 419 This example illustrates how a zone MAY indicate where an SPD entry 420 and SA establishment endpoints exist for its name servers (note, they 421 are not required to be the name servers themselves). Here, each name 422 server is a tunnel end point, and these two name servers are mapped 423 to service ports for DNS (port 53). The IPSECA records above 424 indicate that they verify the CA who must have issued the IPsec 425 certificate used and they represent a SHA256 hash of that 426 certificate's SPKI. 428 Alternately, suppose an enterprise wants to configure OE for DNS 429 transactions between its desktop clients and its recursive resolver. 430 In this case, if the enterprise has configured their desktop clients 431 (perhaps through DHCP) to forward their DNS queries to a caching 432 recursive resolver at the IP address 192.168.1.2, then the following 433 IPSECA mapping should be placed in an internally managed DNS reverse 434 zone: 436 _53.2.1.168.192.in-addr.arpa. IN IPSECA ( 437 3 0 2 8f6ea3c50b5c488bef74c7c4a17a 438 24e8b0f4777d13c211a29223b69a 439 ea7a89184ac4d272a2e3d9760966 440 fb3f220b39f7fdfb325998289e50 441 311ce0748f13c1ed ) ; Verify data in IKEv2 SA 443 This example illustrates how a caching recursive resolver MAY 444 indicate where it will accept IPsec tunnel establishment and what the 445 certificate used for a SA should be. Here the DNS service port and 446 the IPSECA records describe the nature of the authentic certificate 447 that SHOULD be used in an SA with this endpoint. In this example, 448 the IPSECA records both specify that a DANE-EE cert should be 449 expected in an SA with this resolver, and the SHA-512 hash of that 450 full certificate should match the encoded value in the IPSECA 451 resource record. 453 Of note here is that since SAs MAY be identified by domain names 454 (which map to IP addresses), some IP addresses may host services that 455 offer IPsec, and some that do not. The IPSECA record allows hosts to 456 advertise these nuanced configurations in the same way that these 457 services are discovered (through the DNS itself). 459 3. Operational Considerations 461 Scaling IPsec connections to the full capacity that large recursive 462 resolvers or large authoritative name servers operate at could be 463 cause for concern. The additional overhead required to establish and 464 maintain SAs could exceed the provisioning capacity of deployed 465 systems. However, there are several relevant observations: 467 1. If a resolver enables OE, but no (or relatively few) name servers 468 provision IPSECA records, then no IPsec tunnels will be 469 established, and the load will remain static (or marginally 470 increase). 472 2. If an authoritative name server provisions IPSECA record, it will 473 only result in additional load if querying resolvers are 474 configured to attempt OE. 476 3. Using white-listing techniques (such as those used during pilot 477 deployments of AAAA records) would allow authoritative name 478 servers to only return IPSECA responses to clients that have been 479 white-listed. This would allow name servers to control the 480 amount of IPsec overhead they incur. For the same reason, 481 resolvers can be configured to only query for IPSECA records from 482 white-listed name servers. 484 4. IANA Considerations 486 This document uses a new DNS resource record type, called IPSECA. 487 This resource record will need to have a new value assigned to it. 488 Current implementations are advised to use a type number TYPE65347. 490 This document uses the same semantics and values as the TLSA resource 491 record [RFC6698] for its Usage, Selector, and Matching fields. Any 492 future use or modification of an IANA registry for that resource 493 record will have similar effects on this resource record. 495 5. Security Considerations 497 This document details some of the benefits of using IPsec OE for DNS 498 transactions. Such a utility does not reduce the benefits of other 499 security protections. For example, the object-level security 500 assurances that are offered by DNSSEC are cooperative with the 501 session-level security of IPsec. Additional discussions are 502 available in [IPSEC_APPEAL]. Moreover, the protections described 503 herein also offer cooperative benefits with higher layer protocol 504 protections, like TLS [RFC5246]. Any combination of these types of 505 protections offer both defense-in-depth (securing transactions at 506 multiple levels) and offer security practitioners a larger mosaic of 507 security tools from which to construct and maintain their security 508 postures. 510 5.1. Interactions 512 This document requires that all fully qualified domain names 513 [RFC1035] must be secured by DNSSEC. This includes domains in the 514 reverse tree of DNS (which represent IP addresses). 516 The use of IPSECA resource records does not constitute a source of 517 information leakage. Rather, it provides a mechanism to help bolster 518 confidentiality, by obfuscating DNS transactions. 520 Expressing tunnel endpoints through DNS may allow adversaries a 521 vehicle to learn where OE is being offered by name servers. However, 522 OE tunnels to these name servers will only be attempted if querying 523 resolvers are configured to attempt IPsec. As a result, adversaries 524 may be able to learn of potential tunnel endpoints, but if they aim 525 to disrupt active IPsec traffic, they must still observe which 526 resolvers are trying to initiate IPsec communications. Therefore, 527 adversaries would have no greater opportunity to disrupt IPsec 528 traffic than they already do. They would still begin by (for 529 example) observing VPN tunnel setup on wireless LANs (such as at 530 public WiFi hot-spots). 532 5.2. Last Mile Security Analysis 534 For the last mile, we define one type of attack as the case where an 535 adversary intercepts messages that can be undetectably spoofed. For 536 example, if a zone (like example.com) has deployed DNSSEC, then if an 537 adversary responds to a DNS query for www.exmaple.com, a validating 538 DNS resolver should be able to detect the forgery. However, if an 539 adversary responds to a query that is sent for a non-DNSSEC zone, a 540 resolver cannot distinguish the spoofed response from an authentic 541 response. In addition to this, many bootstrapping protocols (such as 542 DHCP [RFC2131]) represent the first opportunity for an adversary to 543 disrupt DNS transactions (by subverting the bootstrapping of the 544 resolver itself on stub-resolvers). Under this model, a DNS stub- 545 resolver's security posture is enhanced by keeping an adversary's 546 attack window to the smallest value possible. 548 Therefore, the attack window offered by DNS clients in a given time 549 span T is comprised of the set of transactions that bootstrap 550 configurations W_cfg(T), plus any DNS transactions that are not 551 verifiable. Of note, however, is that the DNSSEC transactions 552 between stub-resolvers and recursive resolvers are not protected by 553 DNSSEC's cryptography. The only indication of protections is a 554 header bit (the AD bit), which is spoofable. As a result, the attack 555 window includes all DNS transactions W_rDNS(T). 557 From this, the attack window can be expressible as: 559 W(T) = W_cfg(T) + W_rDNS(T) 561 Of note is that under most circumstances, resolvers issue many more 562 queries than configuration requests. So, 564 W_cfg(T) = 1, and W_rDNS(T) >> W_cfg(T). 566 However, consider the attack window when using OE: {W(T)}. If the 567 initial configuration includes a DNSKEY trust anchor that can be used 568 to verify DNSSEC data that corresponds to a resolver's corresponding 569 reverse zone (i.e., the IPSECA RR under in-addr.arpa or ip6.arpa), 570 then {W_cfg(T)} = 1 and {W_rDNS(T)} = 0. Therefore, since W_rDNS(T) 571 >> W_cfg(T) and {W_rDNS(T)} = 0, then by the transitive property, 573 W(T) >> {W(T)}. 575 6. Acknowledgements 577 The editors would like to express their thanks for the early support 578 and insights given by Danny McPherson. 580 7. References 582 7.1. Normative References 584 [RFC1035] Mockapetris, P., "Domain names - implementation and 585 specification", STD 13, RFC 1035, November 1987. 587 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 588 E. Lear, "Address Allocation for Private Internets", 589 BCP 5, RFC 1918, February 1996. 591 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 592 Rose, "DNS Security Introduction and Requirements", 593 RFC 4033, March 2005. 595 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 596 Rose, "Resource Records for the DNS Security Extensions", 597 RFC 4034, March 2005. 599 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 600 Rose, "Protocol Modifications for the DNS Security 601 Extensions", RFC 4035, March 2005. 603 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 604 Internet Protocol", RFC 4301, December 2005. 606 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 607 of Named Entities (DANE) Transport Layer Security (TLS) 608 Protocol: TLSA", RFC 6698, August 2012. 610 7.2. Informative References 612 [DANE_SATIN12] 613 Osterweil, E., Kaliski, B., Larson, M., and D. McPherson, 614 "Reducing the X.509 Attack Surface with DNSSEC's DANE", 615 Proceedings of Securing and Trusting Internet Names, SATIN 616 '12, March 2012. 618 [I-D.draft-ogud-dane-vocabulary] 619 Gudmundsson, O., "Harmonizing how applications specify 620 DANE-like usage", October 2013. 622 [I.D.draft-ietf-dane-registry-acronyms] 623 Gudmundsson, O., "Adding acronyms to simplify DANE 624 conversations", January 2014. 626 [IPSEC_APPEAL] 627 Osterweil, E. and D. McPherson, "IPsec's Appeal: 628 Protecting DNS Under the Covers", Verisign Labs Technical 629 Report #1130006 Revision 1, January 2013. 631 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 632 RFC 2131, March 1997. 634 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 635 (IKE)", RFC 2409, November 1998. 637 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 638 "DNS Extensions to Support IP Version 6", RFC 3596, 639 October 2003. 641 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 642 Material in DNS", RFC 4025, March 2005. 644 [RFC4322] Richardson, M. and D. Redelmeier, "Opportunistic 645 Encryption using the Internet Key Exchange (IKE)", 646 RFC 4322, December 2005. 648 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 649 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 651 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 652 Housley, R., and W. Polk, "Internet X.509 Public Key 653 Infrastructure Certificate and Certificate Revocation List 654 (CRL) Profile", RFC 5280, May 2008. 656 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 657 "Internet Key Exchange Protocol Version 2 (IKEv2)", 658 RFC 5996, September 2010. 660 [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and 661 Internet Key Exchange (IKE) Document Roadmap", RFC 6071, 662 February 2011. 664 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 665 Galperin, S., and C. Adams, "X.509 Internet Public Key 666 Infrastructure Online Certificate Status Protocol - OCSP", 667 RFC 6960, June 2013. 669 Appendix A. Name Server OE Configuration Example 671 673 NAME SERVER SIDE 675 o Config SPD to accept connections from any on port 53 only 677 o Zones add IPSECA RRs for each NS domain name and configure DNSSEC: 678 680 RESOLVER SIDE 682 o resolver processing logic to intercept referrals and look for 683 IPSECA RR(s). 685 o When an IPSECA RR is found, create SPD for that IP and port 53. 687 689 Appendix B. Recursive Resolver OE Configuration Example 691 693 RESOLVER SIDE 695 o If public resolver, create SPD entry that only allows IPsec from 696 port 53. If internal resolver, limit to addresses serviced. 698 REVERSE DNS ZONE 700 o Add IPSECA RR(s) and configure DNSSEC 702 STUB SIDE 704 o Configure reverse zone DNSKEY (if 1918) as a local TA (such as 705 over DHCP). Then do onetime DNSSEC validation for fetching IPSECA 706 RR. 708 o Tools include dnskey-grab and/or NLnet Labs' xxxxx. 710 712 Authors' Addresses 714 Eric Osterweil 715 VeriSign, Inc. 716 Reston, VA 717 USA 719 Email: eosterweil@verisign.com 721 Glen Wiley 722 VeriSign, Inc. 723 Reston, VA 724 USA 726 Email: gwiley@verisign.com 727 Tomofumi Okubo 728 VeriSign, Inc. 729 Reston, VA 730 USA 732 Email: tomokubo@Verisign.com 734 Ramana Lavu 735 VeriSign, Inc. 736 Reston, VA 737 USA 739 Email: RLavu@verisign.com 741 Aziz Mohaisen 742 VeriSign, Inc. 743 Reston, VA 744 USA 746 Email: amohaisen@verisign.com