idnits 2.17.1 draft-ietf-dnsop-multi-provider-dnssec-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 : ---------------------------------------------------------------------------- ** 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 235: '... It is RECOMMENDED that the provider...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2019) is 1935 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 394, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft P. Aras 4 Intended status: Informational Salesforce 5 Expires: July 11, 2019 J. Dickinson 6 Sinodun 7 J. Vcelak 8 NS1 9 D. Blacka 10 Verisign 11 January 7, 2019 13 Multi Provider DNSSEC models 14 draft-ietf-dnsop-multi-provider-dnssec-00 16 Abstract 18 Many enterprises today employ the service of multiple DNS providers 19 to distribute their authoritative DNS service. Deploying DNSSEC in 20 such an environment may present some challenges depending on the 21 configuration and feature set in use. This document will present 22 several deployment models that may be suitable. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 11, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 59 2. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Multiple Signer models . . . . . . . . . . . . . . . . . 3 61 2.1.1. Model 1: Common KSK, Unique ZSK per provider . . . . 4 62 2.1.2. Model 2: Unique KSK and ZSK per provider . . . . . . 4 63 3. Validating Resolver Behavior . . . . . . . . . . . . . . . . 4 64 4. Signing Algorithm Considerations . . . . . . . . . . . . . . 5 65 5. Authenticated Denial Considerations . . . . . . . . . . . . . 6 66 5.1. Single Method . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Mixing Methods . . . . . . . . . . . . . . . . . . . . . 7 68 6. Key Rollover Considerations . . . . . . . . . . . . . . . . . 7 69 6.1. Model 1: Common KSK, Unique ZSK per provider . . . . . . 8 70 6.2. Model 2: Unique KSK and ZSK per provider . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction and Motivation 81 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 82 The source for this draft is maintained in GitHub at: 83 https://github.com/shuque/multi-provider-dnssec 85 Many enterprises today employ the service of multiple DNS providers 86 to distribute their authoritative DNS service. This allows the DNS 87 service to survive a complete failure of any single provider. 88 Additionally, enterprises or providers occasionally have requirements 89 that preclude standard zone transfer techniques [RFC1995] [RFC5936] : 90 either non-standardized DNS features are in use that are incompatible 91 with zone transfer, or operationally a provider must be able to 92 (re)sign DNS records using their own keys. This document outlines 93 some possible models of DNSSEC [RFC4033] [RFC4034] [RFC4035] 94 deployment in such an environment. 96 2. Deployment Models 98 If a zone owner is able to use standard zone transfer techniques, 99 then the presence of multiple providers does not present any need to 100 substantially modify normal deployment models. In these deployments 101 there is a single signing entity (which may be the zone owner, one of 102 the providers, or a separate entity), while the providers act as 103 secondary authoritative servers for the zone. 105 Occasionally, however, standard zone transfer techniques cannot be 106 used. This could be due to the use of non-standard DNS features, or 107 due to operational requirements of a given provider (e.g., a provider 108 that only supports "online signing".) In these scenarios, the 109 multiple providers each act like primary servers, independently 110 signing data received from the zone owner and serving it to DNS 111 queriers. This configuration presents some novel challenges and 112 requirements. 114 2.1. Multiple Signer models 116 In this category of models, multiple providers each independently 117 sign and serve the same zone. The zone owner typically uses 118 provider-specific APIs to update zone content at each of the 119 providers, and relies on the provider to perform signing of the data. 120 A key requirement here is to manage the contents of the DNSKEY and DS 121 RRset in such a way that validating resolvers always have a viable 122 path to authenticate the DNSSEC signature chain no matter which 123 provider is queried. This requirement is achieved by having each 124 provider import the public Zone Signing Keys (ZSKs) of all other 125 providers into their DNSKEY RRsets. 127 These models can support DNSSEC even for the non-standard features 128 mentioned previously, if the DNS providers have the capability of 129 signing the response data generated by those features. Since these 130 responses are often generated dynamically at query time, one method 131 is for the provider to perform online signing (also known as online 132 or on-the-fly signing). However, another possible approach is to 133 pre-compute all the possible response sets and associated signatures 134 and then algorithmically determine at query time which response set 135 needs to be returned. 137 In the first two of these models, the function of coordinating the 138 DNSKEY or DS RRset does not involve the providers communicating 139 directly with each other, which they are unlikely to do since they 140 typically have a contractual relationship only with the zone owner. 142 The following descriptions consider the case of two DNS providers, 143 but the model is generalizable to any number. 145 2.1.1. Model 1: Common KSK, Unique ZSK per provider 147 o Zone owner holds the KSK, manages the DS record, and is 148 responsible for signing the DNSKEY RRset and distributing the 149 signed DNSKEY RRset to the providers. 151 o Each provider has their own ZSK which is used to sign data. 153 o Providers have an API that owner uses to query the ZSK public key, 154 and insert a combined DNSKEY RRset that includes both ZSKs and the 155 KSK, signed by the KSK. 157 o Key rollovers need coordinated participation of the zone owner to 158 update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for 159 KSK). 161 2.1.2. Model 2: Unique KSK and ZSK per provider 163 o Each provider has their own KSK and ZSK. 165 o Each provider offers an API that the Zone Owner uses to import the 166 ZSK of the other provider into their DNSKEY RRset. 168 o DNSKEY RRset is signed independently by each provider using their 169 own KSK. 171 o Zone Owner manages the DS RRset that includes both KSKs. 173 o Key rollovers need coordinated participation of the zone owner to 174 update the DS RRset (for KSK), and the DNSKEY RRset (for ZSK). 176 3. Validating Resolver Behavior 178 The central requirement for both of the Multiple Signer models 179 (Section 2.1) is to ensure that the ZSKs from all providers are 180 present in each provider's apex DNSEY RRset, and is vouched for by 181 either the single KSK (in model 1) or each provider's KSK (in model 182 2.) If this is not done, the following situation can arise (assuming 183 two providers A and B): 185 o The validating resolver follows a referral (delegation) to the 186 zone in question. 188 o It retrieves the zone's DNSKEY RRset from one of provider A's 189 nameservers. 191 o At some point in time, the resolver attempts to resolve a name in 192 the zone, while the DNSKEY RRset received from provider A is still 193 viable in its cache. 195 o It queries one of provider B's nameservers to resolve the name, 196 and obtains a response that is signed by provider B's ZSK, which 197 it cannot authenticate because this ZSK is not present in its 198 cached DNSKEY RRset for the zone that it received from provider A. 200 o The resolver will not accept this response. It may still be able 201 to ultimately authenticate the name by querying other nameservers 202 for the zone until it elicits a response from one of provider A's 203 nameservers. But it has incurred the penalty of additional 204 roundtrips with other nameservers, with the corresponding latency 205 and processing costs. The exact number of additional roundtrips 206 depends on details of the resolver's nameserver selection 207 algorithm and the number of nameservers configured at provider B. 209 o It may also be the case that a resolver is unable to provide an 210 authenticated response because it gave up after a certain number 211 of retries or a certain amount of delay. Or that downstream 212 clients of the resolver that originated the query timed out 213 waiting for a response. 215 Zone owners will want to deploy a DNS service that responds as 216 efficiently as possible with validatable answers only, and hence it 217 is important that the DNSKEY RRset at each provider is maintained 218 with the active ZSKs of all participating providers. This ensures 219 that resolvers can validate a response no matter which provider's 220 nameservers it came from. 222 Details of how the DNSKEY RRset itself is validated differs. In 223 model 1 (Section 2.1.1), one unique KSK managed by the Zone Owner 224 signs an identical DNSKEY RRset deployed at each provider, and the 225 signed DS record in the parent zone refers to this KSK. In model 2 226 (Section 2.1.2), each provider has a distinct KSK and signs the 227 DNSKEY RRset with it. The Zone Owner deploys a DS RRset at the 228 parent zone that contains multiple DS records, each referring to a 229 distinct provider's KSK. Hence it does not matter which provider's 230 nameservers the resolver obtains the DNSKEY RRset from, the signed DS 231 record in each model can authenticate the associated KSK. 233 4. Signing Algorithm Considerations 235 It is RECOMMENDED that the providers use a common signing algorithm 236 (and common keysizes for algorithms that support variable key sizes). 237 This ensures that the multiple providers have identical security 238 postures and no provider is more vulnerable to cryptanalytic attack 239 than the others. 241 It may however be possible to deploy a configuration where different 242 providers use different signing algorithms. The main impediment is 243 that current DNSSEC specifications require that if there are multiple 244 algorithms in the DNSKEY RRset, then RRsets in the zone need to be 245 signed with at least one DNSKEY of each algorithm, as described in 246 RFC 4035 [RFC4035], Section 2.2. However RFC 6781 [RFC6781], 247 Section 4.1.4, also describes both a conservative and liberal 248 interpretation of this requirement. When validating DNS resolvers 249 follow the liberal approach, they do not expect that zone RRsets are 250 signed by every signing algorithm in the DNSKEY RRset, and responses 251 with single algorithm signatures can be validated corectly assuming a 252 valid chain of trust exists. In fact, testing by the .BR Top Level 253 domain for their planned algorithm rollover [BR-ROLLOVER], 254 demonstrates that the liberal approach works. 256 5. Authenticated Denial Considerations 258 Authentiated denial of existence enables a resolver to validate that 259 a record does not exist. For this purpose, an authoritative server 260 presents in a response to the resolver special NSEC (Section 3.1.3 of 261 [RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3 262 method enhances NSEC by providing opt-out for signing insecure 263 delegations and also adds limited protection against zone enumeration 264 attacks. 266 An authoritative server response carrying records for authenticated 267 denial is always self-contained and the receiving resolver doesn't 268 need to send additional queries to complete the denial proof data. 269 For this reason, no rollover is needed when switching between NSEC 270 and NSEC3 for a signed zone. 272 Since authenticated denial responses are self-contained, NSEC and 273 NSEC3 can be used by different providers to serve the same zone. 274 Doing so however defeats the protection against zone enumeration 275 provided by NSEC3. A better configuration involves multiple 276 providers using different authenticated denial of existence 277 mechanisms that all provide zone enumeration defense, such as pre- 278 computed NSEC3, NSEC3 White Lies [RFC7129], NSEC Black Lies 279 [BLACKLIES], etc. Note however that having multiple providers 280 offering different authenticated denial mechanisms may impact how 281 effectively resolvers are able to make use of the caching of negative 282 responses. 284 5.1. Single Method 286 Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the 287 methods are not used at the same time by different servers). This 288 configuration is prefered because the behavior is well-defined and 289 it's closest to the current operational practice. 291 5.2. Mixing Methods 293 Compliant resolvers should be able to serve zones when different 294 authoritative servers for the same zone respond with different 295 authentiated denial methods because this is normally observed when 296 NSEC and NSEC3 are being switched or when NSEC3PARAM is updated. 298 Resolver software may be however designed to handle a single 299 transition between two authenticated denial configurations more 300 optimally than permanent setup with mixed authenticated denial 301 methods. This could make caching on the resolver side less efficient 302 and the authoritative servers may observe higher number of queries. 303 This aspect should be considered especially in context of Aggresive 304 Use of DNSSEC-Validated Cache [RFC8198]. 306 In case all providers cannot be configured for a matching 307 authentiated denial, it is advised to find lowest number of possible 308 configurations possible across all used providers. 310 Note that NSEC3 configuration on all providers with different 311 NSEC3PARAM values is considered a mixed setup. 313 6. Key Rollover Considerations 315 The Multiple Signer (Section 2.1) models introduce some new 316 requirements for DNSSEC key rollovers. Since this process 317 necessarily involves coordinated actions on the part of providers and 318 the Zone Owner, one reasonable strategy is for the Zone Owner to 319 initiate key rollover operations. But other operationally plausible 320 models may also suit, such as a DNS provider initiating a key 321 rollover and signaling their intent to the Zone Owner in some manner. 323 The descriptions in this section assume that KSK rollovers employ the 324 commonly used Double Signature KSK Rollover Method, and that ZSK 325 rollovers employ the Pre-Publish ZSK Rollover Method, as described in 326 detail in [RFC6781]. With minor modifications, they can also be 327 easily adapted to other models, such as Double DS KSK Rollover or 328 Double Signature ZSK rollover, if desired. 330 6.1. Model 1: Common KSK, Unique ZSK per provider 332 o Key Signing Key Rollover: In this model, the two managed DNS 333 providers share a common KSK which is held by the Zone Owner. To 334 initiate the rollover, the Zone Owner generates a new KSK and 335 obtains the DNSKEY RRset of each DNS provider using their 336 respective APIs. The new KSK is added to each provider's DNSKEY 337 RRset and the RRset is re-signed with both the new and the old 338 KSK. This new DNSKEY RRset is then transferred to each provider. 339 The Zone Owner then updates the DS RRset in the parent zone to 340 point to the new KSK, and after the necessary DS record TTL period 341 has expired, proceeds with updating the DNSKEY RRSet to remove the 342 old KSK. 344 o Zone Signing Key Rollover: In this model, each DNS provider has 345 separate Zone Signing Keys. Each provider can choose to roll 346 their ZSK independently by co-ordinating with the Zone Owner. 347 Provider A would generate a new ZSK and communicate their intent 348 to perform a rollover (note that Provider A cannot immediately 349 insert this new ZSK into their DNSKEY RRset because the RRset has 350 to be signed by the Zone Owner). The Zone Owner obtains the new 351 ZSK from Provider A. It then obtains the current DNSKEY RRset 352 from each provider (including Provider A), inserts the new ZSK 353 into each DNSKEY RRset, re-signs the DNSKEY RRset, and sends it 354 back to each provider for deployment via their respective key 355 management APIs. Once the necessary time period is elapsed (i.e. 356 all zone data has been re-signed by the new ZSK and propagated to 357 all authoritative servers for the zone, plus the maximum zone TTL 358 value of any of the data in the zone signed by the old ZSK), 359 Provider A and the zone owner can initiate the next phase of 360 removing the old ZSK. 362 6.2. Model 2: Unique KSK and ZSK per provider 364 o Key Signing Key Rollover: In Model 2, each managed DNS provider 365 has their own KSK. A KSK roll for provider A does not require any 366 change in the DNSKEY RRset of provider B, but does require co- 367 ordination with the Zone Owner in order to get the DS record set 368 in the parent zone updated. The KSK roll starts with Provider A 369 generating a new KSK and including it in their DNSKEY RRSet. The 370 DNSKey RRset would then be signed by both the new and old KSK. 371 The new KSK is communicated to the Zone Owner, after which the 372 Zone Owner updates the DS RRset to replace the DS record for the 373 old KSK with a DS record for the new KSK. After the necessary DS 374 RRset TTL period has elapsed, the old KSK can be removed from 375 provider A's DNSKEY RRset. 377 o Zone Signing Key Rollover: In Model 2, each managed DNS provider 378 has their own ZSK. The ZSK roll for provider A would start with 379 them generating new ZSK and including it in their DNSKEY RRset and 380 re-signing the new DNSKEY RRset with their KSK. The new ZSK of 381 provider A would then be communicated to the Zone Owner, who will 382 initiate the process of importing this ZSK into the DNSKEY RRsets 383 of the other providers, using their respective APIs. Once the 384 necessary Pre-Publish key rollover time periods have elapsed, 385 provider A and the Zone Owner can initiate the process of removing 386 the old ZSK from the DNSKEY RRset of all providers. 388 7. IANA Considerations 390 This document includes no request to IANA. 392 8. Security Considerations 394 [TBD] 396 9. Acknowledgments 398 The initial version of this document benefited from discussions with 399 and review from Duane Wessels. Additional helpful comments were 400 provided by Steve Crocker, Ulrich Wisser, Tony Finch, and Olafur 401 Gudmundsson. 403 10. References 405 10.1. Normative References 407 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 408 Rose, "DNS Security Introduction and Requirements", 409 RFC 4033, DOI 10.17487/RFC4033, March 2005, 410 . 412 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 413 Rose, "Resource Records for the DNS Security Extensions", 414 RFC 4034, DOI 10.17487/RFC4034, March 2005, 415 . 417 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 418 Rose, "Protocol Modifications for the DNS Security 419 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 420 . 422 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 423 Security (DNSSEC) Hashed Authenticated Denial of 424 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 425 . 427 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 428 Operational Practices, Version 2", RFC 6781, 429 DOI 10.17487/RFC6781, December 2012, 430 . 432 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 433 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 434 July 2017, . 436 10.2. Informative References 438 [BLACKLIES] 439 Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of 440 Existence or Black Lies", . 443 [BR-ROLLOVER] 444 Neves, F., ".br DNSSEC Algorithm Rollover Update", 445 in ICANN 62 DNSSEC Workshop, June 2018, 446 . 449 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 450 DOI 10.17487/RFC1995, August 1996, 451 . 453 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 454 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 455 . 457 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 458 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 459 February 2014, . 461 Authors' Addresses 463 Shumon Huque 464 Salesforce 466 Email: shuque@gmail.com 467 Pallavi Aras 468 Salesforce 470 Email: paras@salesforce.com 472 John Dickinson 473 Sinodun 475 Email: jad@sinodun.com 477 Jan Vcelak 478 NS1 480 Email: jvcelak@ns1.com 482 David Blacka 483 Verisign 485 Email: davidb@verisign.com