idnits 2.17.1 draft-mglt-dnsop-dnssec-validator-requirements-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2015) is 3347 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP D. Migault (Ed) 3 Internet-Draft Ericsson 4 Intended status: Standards Track February 16, 2015 5 Expires: August 20, 2015 7 DNSSEC Validators Requirements 8 draft-mglt-dnsop-dnssec-validator-requirements-02.txt 10 Abstract 12 DNSSEC provides data integrity and authentication for DNSSEC 13 validators. However, without valid trust anchor(s) and an acceptable 14 value for the current time, DNSSEC validation cannot be performed. 15 This document lists the requirements to be addressed so resolvers can 16 have DNSSEC validation can be always-on. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 20, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Time derivation and absence of Real Time Clock . . . . . . . 3 56 5. Unplugged devices during Trust Anchor KSKs roll over . . . . 3 57 6. Emergency Key rollover . . . . . . . . . . . . . . . . . . . 4 58 6.1. Invalid cached ZSK . . . . . . . . . . . . . . . . . . . 5 59 6.2. Invalid cached RRSIG . . . . . . . . . . . . . . . . . . 5 60 6.3. Invalid cached KSK . . . . . . . . . . . . . . . . . . . 6 61 6.4. Invalid DS . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Invalid RRSIG . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Private KSK/ZSK . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 13.2. Informational References . . . . . . . . . . . . . . . . 10 71 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 DNSSEC [RFC4033], [RFC4034], [RFC4035] adds data authentication and 83 integrity checks to DNS [RFC1034], [RFC1035]. For signature 84 validation, DNSSEC requires a valid trust anchor such as the Key 85 Signing Key (KSK) (the Root Zone KSK for example) and an appropriated 86 time. 88 Currently few efforts have been made to describe mechanisms that 89 guarantee how a DNSSEC validator can be provisioned with the 90 appropriated KSKs and time so that DNSSEC validation can always be 91 activated. A device that is badly configured or badly provisioned 92 that performs DNSSEC validation may result in disabling the DNS 93 service of the device, and then most of its communications. As a 94 result, non administrated devices that implement DNSSEC validation 95 always need heuristics to disable the DNSSEC validation. This 96 results in an implicit rule that can be stated as: "if DNSSEC 97 validation is performed correctly then do DNSSEC otherwise disable 98 validation and switch to DNS". In a security point of view, this is 99 unacceptable. 101 This document considers unmanaged devices performing DNSSEC 102 validation and details scenarios where DNSSEC validation cannot be 103 performed properly by the device. In other words, this means that 104 FQDN properly signed are rejected. From these scenarios, this 105 document derives requirements so DNSSEC Validators can have DNSSEC 106 always activated. 108 3. Terminology 110 This document uses the following terminology: 112 - DNSSEC Validator: the entity that performs DNSSEC resolution and 113 performs signature validation. 115 4. Time derivation and absence of Real Time Clock 117 With M2M communication some devices are not expecting to embed Real 118 Time Clock (Rasberry Pi is one example of such devices). When these 119 devices are re-plugged the initial time is set to January 1 1970. 120 Other devices that have clocks that may suffer from time derivation. 121 All these devices cannot rely on their time estimation to perform 122 DNSSEC validation. 124 Requirement 1: DNSSEC validator MUST be provided means to 125 appropriately update their time. 127 5. Unplugged devices during Trust Anchor KSKs roll over 129 In this section we consider a regular Trust Anchor KSK roll over as 130 described in [RFC6781] and [RFC5011]. Unlike regular KSKs, Trust 131 Anchor KSK does not have to update the DS RRset in the parent zone. 132 According to [RFC6781], if TTL_K is the TTL associated to the Trust 133 Anchor KSK and associated RRSIGs, the time of key roll over is around 134 TTL_K with double signed KSKs, and 2 x TTL_K in the case of single 135 singed KSK. 137 The Root Zone KSK is an example of Trust Anchor KSK and at the time 138 of writing the KSK has a TTL of 172800 seconds which means 2 days. 139 This means that 2 days would be sufficient to perform a Trust Anchor 140 KSK roll over. [RFC5011] recommends to advertise the new / old key 141 for 30 days. This means that a device unplugged for two months may 142 not be aware of a regular Trust Anchor KSK rollover. 144 A DNSSEC validation may be properly configured by the manufacturer to 145 perform DNSSEC validation. The device may for example be configured 146 by the manufacturer shipped to resellers that store the device for a 147 few months, years before selling the devices to the final end user. 148 Similarly, an operational device may remain unplugged for a while for 149 maintenance reason, or held in reserve when a crash occurs. This 150 fall back is never expected to happen and may happen years after. 152 Suppose a KSK complete key roll-over occurs (for example at the Root 153 Zone) while the device is offline. Once plugged again, the device 154 will attempt to validate DNSSEC signature with the old Trust Anchor 155 KSK. 157 The key point in this example is that the device is boot and does not 158 rely on cached information. 160 Requirement 2: DNSSEC Validator MUST be able to check the validity of 161 their Trust Anchor KSKs. 163 Requirement 3: DNSSEC Validator MUST be able to retrieve their Trust 164 Anchor KSKs. 166 We think these requirements are not restrictive to the Root Zone KSK, 167 but to any KSK. In fact it is not always possible to build a trusted 168 delegation between the Root Zone and any sub zone. This may happen 169 for example if one of the upper zones does not handle the secure 170 delegation or improperly implement it. A DS RRset may not be 171 properly filled or its associated signature cannot be validated. As 172 the chain of trust between a zone and the root zone may not be 173 validated, the DNSSEC validation for the zone requires a Trust 174 Anchor. Such DNS(SEC) resolutions may be critical for infrastructure 175 management. A company "Example" may for address all its devices 176 under the domain example.com and may not want disruption to happen if 177 the .com delegation cannot be validated for any reason. Such 178 companies may provision there DNSSEC Validator with the Trust Anchor 179 KSK for the zone example.com in addition to the regular DNSSEC 180 delegation. 182 Note that providing Trust Anchor KSKs is a crucial operation and can 183 be used a vector of attack. As a result, this operation MUST be 184 performed cautiously. 186 6. Emergency Key rollover 188 By emergency key roll over, this paper designates any rollover that 189 are not performed as described in Section 4.1 of [RFC6781] and that 190 result in differences between data stored in the cache of the DNSSEC 191 Validators and the authoritative servers (see section 4.2 in 192 [RFC6781]) 193 Emergency key roll over can be intentionally performed or result from 194 an unexpected behavior in the publishing/validation chain. This is 195 out of scope of this document to understand the reasons/motivations 196 for such key roll over. This document assumes such situation are 197 likely to happen and lists the requirement so DNSSEC Validator can 198 recover from such situations. 200 6.1. Invalid cached ZSK 202 An emergency ZSK rollover may result in a new ZSK with associated new 203 RRSIG published in the authoritative zone, while DNSSEC Validator may 204 still cache the old value of the ZSK. For a RRset not cached, the 205 DNSSEC Validator performs a DNSSEC query to the authoritative server 206 that returns the RRset signed with the new ZSK. The DNSSEC Validator 207 validates the signature with the old ZSK which results in an invalid 208 signature check. 210 Suppose that the old ZSK has been corrupted and that old RRsets have 211 been spoofed. Until the ZSK TTL expires, the DNSSEC Validator 212 considers the spoofed RRsets as valid and the newly signed RRsets as 213 invalid. 215 Requirement 4: DNSSEC Validator MUST be able to be informed a ZSK 216 MUST be flushed from cache. 218 Note that if the DNSSEC Validator receives an indication that a ZSK 219 is not valid anymore, it is expected to flush its cache entries of 220 the old ZSK as well as all entries that have been validated by the 221 old ZSK. This does not lead to impersonation of ZSK, at most it 222 generates some additional DNSSEC resolutions and validations. 224 Note also, that constantly inform the DNSSEC Validator of flushing a 225 specific ZSK may lead to service disruption. In order to prevent 226 such attacks, the DNSSEC is expected to have mechanisms to limit the 227 frequency a zone ZSK can be flushed. Similarly, informing the DNSSEC 228 Validator of flushing randomly chosen ZSK may be associate to 229 resource exhaustion attacks, and also affect the resolution service. 230 As a result, mechanisms are expected to limit the overall number of 231 flushing actions. These case are detailed in Section 11 233 6.2. Invalid cached RRSIG 235 This would mean the DNSSEC Validator caches a new ZSK, but still has 236 a RRset with a RRSIG signed with the old ZSK. 238 This situation should not happen as when a ZSK is renewed all RRsets 239 validated by the old ZSK are flushed from the cache. 241 6.3. Invalid cached KSK 243 Consequences of invalid KSK are similar to ZSK. None of the RRSIG 244 can be validated even the one signing the ZSK. (cf. Section 6.1) 246 Requirement 5: DNSSEC Validator MUST be able to be informed a KSK 247 MUST be flushed from cache. 249 6.4. Invalid DS 251 The DS RRset is stored in the parent zone to build a chain of trust 252 with the child zone. This DS RRset can be invalid because its RDATA 253 (KSK) is not anymore used in the child zone or because the DS is 254 badly signed and cannot be validated by the DNSSEC Validator. 256 In both cases the child zone is considered as insecure and the valid 257 child zone's KSK should become a Trust Anchor KSK. 259 Requirement 6: DNSSEC Validator MUST be able to be informed a KSK 260 SHOULD be trusted as a Trust Anchor KSK. 262 7. Invalid RRSIG 264 A zone may have been badly signed, which means that the KSK or ZSK 265 cannot validate the RRSIG associated to the RRsets. This may not be 266 due to a key roll over, but to an incompatibility between the keys 267 (KSK or ZSK) and the signatures. 269 Requirement 7: DNSSEC Validator MUST be able to be informed that a 270 KSK or a ZSK MUST NOT be used for RRSIG validation. Unlike 271 "flushing", "MUST NOT be used" means the issue is not a 272 synchronization issue, but that legitimate keys are invalid. Such 273 Keys are known as Negative Trust Anchors 274 [I-D.livingood-negative-trust-anchors]. 276 This means that the zone for a given time will be known as "known 277 insecure". The DNSSEC Validator is not expected to perform signature 278 validation for this zone. It is expected that this information is 279 associated to a Time To Live (TTL). 281 Note that, this information may be used as an attack vector to 282 impersonate a zone, and must be provided in a trusted way, by a 283 trusted party. 285 If a zone has been badly signed, the administrator of the 286 authoritative DNS server may resign the zone with the same keys or 287 proceed to an emergency key rollover. If the signature is performed 288 with the same keys, the DNSSEC Validator may notice by itself that 289 RRSIG can be validated. On the other hand if a key rollover is 290 performed, the newly received RRSIG will carry a new key id. Upon 291 receiving a new key id in the RRSIG, the DNSSEC Validator is expected 292 to retrieve the new ZSK/KSK. If the RRSIG can be validated, the 293 DNSSEC Validator is expected to remove the "known insecure" flag. 295 However, if the KSK/ZSK are rolledover and RRSIG cannot be validated, 296 it remains hard for the DNSSEC Validator to determine whether the 297 RRSIG cannot be validated or that RRSIG are invalid. As a result: 299 Requirement 8: The DNSSEC Validator MUST be able to be informed that 300 a KSK or a ZSK is known "back to secure". 302 8. Private KSK/ZSK 304 DNSSEC may also be used in some private environment. Corporate 305 networks and home networks, for example, may want to take advantage 306 of DNSSEC for a local scope network. Typically, a corporate network 307 may use a local scope KSK / ZSK to validate DNS RRsets provided by 308 authoritative DNSSEC server in the corporate network. This use case 309 is also known as the "split-zone" use case. These RRsets within the 310 corporate network may differ from those hosted on the public DNS 311 infrastructure. Note that using different KSK/ZSK for a given zone 312 may expose a zone to signature invalidation. This is especially the 313 case for DNSSEC validators that are expected to flip-flop between 314 local and public scope. How validators have to handle the various 315 provisioned KSK/ZSKs is out of scope of the document. 317 Homenet work may use DNSSEC with TLDs or associated domain names that 318 are of local scope and not even registered in the public DNS 319 infrastructure. 321 Requirement 9: DNSSEC Validator MAY be able to be provided KSK for 322 private use. 324 Requirement 10: DNSSEC Validator MAY be able to be provided ZSK for 325 private use. 327 9. Requirements 329 The document lists the following requirements: 331 - Requirement 1: DNSSEC validator MUST be provided means to 332 appropriately update their time. 334 - Requirement 2: DNSSEC Validator MUST be able to check the validity 335 of their Trust Anchor KSKs. 337 - Requirement 3: DNSSEC Validator MUST be able to retrieve their 338 Trust Anchor KSKs. 340 - Requirement 4: DNSSEC Validator MUST be able to be informed a ZSK 341 MUST be flushed from cache. 343 - Requirement 5: DNSSEC Validator MUST be able to be informed a KSK 344 MUST be flushed from cache. 346 - Requirement 6: DNSSEC Validator MUST be able to be informed a KSK 347 SHOULD be trusted as a Trust Anchor KSK. 349 - Requirement 7: DNSSEC Validator MUST be able to be informed that a 350 KSK or a ZSK MUST NOT be used for RRSIG validation. 352 - Requirement 8: The DNSSEC Validator MUST be able to be informed 353 that a KSK or a ZSK is known "back to secure". 355 - Requirement 9: DNSSEC Validator MUST be able to be provided KSK 356 for private use. 358 - Requirement 10: DNSSEC Validator MUST be able to be provided ZSK 359 for private use. 361 10. IANA Considerations 363 There are no IANA consideration for this document. 365 11. Security Considerations 367 The requirements listed in this document aim at providing the DNSSEC 368 Validator appropriated information so DNSSEC validation can be 369 performed. On the other hand, providing inappropriate information 370 can lead to misconfiguring the DNSSEC Validator, and thus disrupting 371 the DNSSEC resolution service. As a result, enabling the setting of 372 configuration parameters by a third party may open a wide surface of 373 attacks. 375 As an appropriate time value is necessary to perform signature check 376 (cf. Section 4), an attacker may provide rogue time value to prevent 377 the DNSSEC Validator to check signatures. 379 An attacker may also affect the resolution service by regularly 380 asking the DNSSEC Validator to flush the KSK/ZSK from its cache (cf. 381 Section 6.1 Section 6.3). All associated data will also be flushed. 382 This generates additional DNSSEC resolution and additional 383 validations, as RRSet that were cached require a DNSSEC resolution 384 over the Internet. This affects the resolution service by slowing 385 down responses, and increases the load on the DNSSEC Validator. 387 An attacker may ask the DNSSEC Validator to consider a rogue KSK/ZSK 388 ( cf. Section 6.4, Section 8), thus hijacking the DNS zone. 389 Similarly, (cf. Section 7) an attacker may inform the DNSSEC 390 Validator not to trust a given KSK in order to prevent DNSSEC 391 validation to be performed. 393 An attacker (cf. Section 7) can advertise a "known insecure" KSK or 394 ZSK is "back to secure" to prevent signature check to be performed 395 correctly. 397 As a result, information considered by the DNSSEC Validator should be 398 from a trusted party. This trust party should have been 399 authenticated, and the channel used to exchange the information 400 should also be protected and authenticated. 402 12. Acknowledgment 404 The need to address DNSSEC issues on the resolver side started in the 405 Home Networks mailing list and during the IETF87 in Berlin. Among 406 others, people involved in the discussion were Ted Lemon, Ralph 407 Weber, Normen Kowalewski, and Mikael Abrahamsson. People involved in 408 the email discussion initiated by Jim Gettys were, with among others, 409 Paul Wouters, Joe Abley and Michael Richardson. 411 The current document has been initiated after a discussion with Paul 412 Wouter and Evan Hunt. 414 13. References 416 13.1. Normative References 418 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 419 STD 13, RFC 1034, November 1987. 421 [RFC1035] Mockapetris, P., "Domain names - implementation and 422 specification", STD 13, RFC 1035, November 1987. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 428 Rose, "DNS Security Introduction and Requirements", RFC 429 4033, March 2005. 431 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 432 Rose, "Resource Records for the DNS Security Extensions", 433 RFC 4034, March 2005. 435 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 436 Rose, "Protocol Modifications for the DNS Security 437 Extensions", RFC 4035, March 2005. 439 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 440 Trust Anchors", STD 74, RFC 5011, September 2007. 442 13.2. Informational References 444 [I-D.livingood-negative-trust-anchors] 445 Livingood, J. and C. Griffiths, "Definition and Use of 446 DNSSEC Negative Trust Anchors", draft-livingood-negative- 447 trust-anchors-07 (work in progress), September 2014. 449 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 450 Operational Practices, Version 2", RFC 6781, December 451 2012. 453 Appendix A. Document Change Log 455 [RFC Editor: This section is to be removed before publication] 457 -02: Clarification for private ZSK/KSK. 459 -01: minor editings. 461 -00: First version published. 463 Author's Address 465 Daniel Migault 466 Ericsson 467 8400 boulevard Decarie 468 Montreal, QC H4P 2N2 469 Canada 471 Email: mglt.ietf@gmail.com