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