idnits 2.17.1 draft-mglt-dnsop-dnssec-validator-requirements-06.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 (October 30, 2017) is 2369 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) == Outdated reference: A later version (-13) exists of draft-ietf-dnsop-rfc5011-security-considerations-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. York 5 Expires: May 3, 2018 Internet Society 6 E. Lewis 7 ICANN 8 October 30, 2017 10 DNSSEC Validators Requirements 11 draft-mglt-dnsop-dnssec-validator-requirements-06 13 Abstract 15 DNSSEC provides data integrity and source authentication to a basic 16 DNS RReet. Given a RRset, a public key and a signature, a DNSSEC 17 validator checks the signature, time constraints, and other, local, 18 policies. In case of mismatch the RRSet is considered illegitimate 19 and is rejected. 21 Accuracy in DNSSEC validation, that is, avoiding false positives and 22 catching true negatives, requires that both the signing process and 23 validation process adhere to the protocol, which begins with external 24 configuration parameters. This document describes requirements for a 25 validator to be able to perform accurate validation. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. DNSSEC Validator Description . . . . . . . . . . . . . . . . 4 65 5. Time derivation and absence of Real Time Clock . . . . . . . 5 66 6. Trust Anchor . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Trust Anchor Bootstrapping . . . . . . . . . . . . . . . 6 68 6.2. Trust Anchor Data Store . . . . . . . . . . . . . . . . . 7 69 6.3. Interactions with the cached RRsets . . . . . . . . . . . 8 70 7. ZSK / KSK . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7.1. KSK/ZSK Data Store . . . . . . . . . . . . . . . . . . . 8 72 7.2. KSK/ZSK Data Store and Trust Anchor Data Store . . . . . 10 73 7.3. Interactions with cached RRsets . . . . . . . . . . . . . 11 74 8. DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 9. Cryptography Deprecation . . . . . . . . . . . . . . . . . . 12 76 10. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 13. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 14 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 14.2. Informational References . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 DNSSEC validation [RFC4033], [RFC4034] and [RFC4035] has two core 94 concepts. One is the matching of a RRSIG resource record's contents 95 to a RRset, making use of a DNSKEY resource record (named in the 96 RRSIG record). Two is the placing of trust in the DNSKEY resource 97 record. 99 Evaluation based on a RRSIG record involves a few steps. Most 100 visible is a cryptographic operation, matching the digital signature 101 in the RRSIG with the specified public key in the named DNSKEY record 102 and a properly prepared DNS RRset. This is meant to demonstrate that 103 the RRset came from an entity with the private component of the key 104 (source authenticity). 106 Not to be forgotten are the other matches to perform. To address the 107 threat of reply attacks, wall-clock (absolute) time is checked. To 108 address the authority of the source, the named DNSKEY record is 109 checked for appropriateness (i.e., owned by the same zone is the 110 default policy). 112 The RRSIG record also contains other information intended to help the 113 validator perform its work, in some cases "sane value" checks are 114 performed. For instance, the original TTL (needed to prepare the RR 115 set for validation) ought to be equal to or higher than the received 116 TTL. 118 Requirements related to validation exist in [RFC4033], [RFC4034] and 119 [RFC4035]. However, the specification of the validation is not 120 sufficient to enable a wide deployment of DNSSEC validators. In 121 fact, there are a number of situations where the necessary condition 122 are not met by the DNSSEC validator to perform DNSSEC validation. 123 When such conditions are not met, the DNSSEC validation may qualify 124 improperly a RRset as invalid. This document is focused on the 125 necessary mechanisms that DNSSEC validators should implement in order 126 to make DNSSEC validation output accurate. The mechanisms described 127 in this document include, provisioning mechanisms as well as 128 monitoring and management mechanisms that enables an administrator to 129 validate the validity of the DNSSEC validation output. 131 3. Terminology 133 This document uses the following terminology: 135 DNSSEC validator: the entity that performs DNSSEC resolution and 136 performs signature validation. 138 Accurate validation: validation that avoids false positives and 139 catches true negatives. (not sure if this is needed, but seems 140 appropriate) 142 Trust Anchor Data Store: 144 4. DNSSEC Validator Description 146 This is a conceptual block diagram of the elements involved with 147 DNSSEC validation. This is not meant to be an architecture for code, 148 this is meant to be a framework for discussion and explanation. 150 +-------------+ +---------------+ 151 | | | | 152 | Time Source | | Cryptographic | 153 | | | Libraries | 154 | | | | 155 +-------------+ +---------------+ 156 | | 157 v v 158 +--------------------------------+ +--------------+ 159 | | | | 160 | |<--| Trust Anchor | 161 | DNSSEC Validation Engine | | Manager & | 162 | |-->| Storage | 163 | | | | 164 +--------------------------------+ +--------------+ 165 ^ | ^ | 166 | v | | 167 +-------------+ +---------------+ | 168 | | | | | 169 | DNS Caches | | DNS Messages |<---------+ 170 | | | | 171 +-------------+ +---------------+ 173 Figure 1: DNSSEC Validator Description 175 Time Source : Wall clock time Cryptograhic Libraries: Code 176 performing mathematical functions. 178 DNS Message : Receiver of DNS responses DNS Caches: Positive and 179 negative caches. 181 Trust Anchor Manager : database of trust anchors, manages trust 182 DNSSEC Validation Engine: follows local policy to approve data. 184 a. Time Source -> DNSSEC Validation Engine Current time upon 185 request, in appropriate time zone setting 187 b. Cryptographic Libraries-> DNSSEC Validation Engine Supplies code 188 to perform math, the engine determines the DNSSEC Security 189 Algorithms supported 191 c. DNS Caches <- DNSSEC Validation Engine Enter the results of a 192 validation (positive data, negative failures) 194 d. DNS Caches -> DNSSEC Validation Engine Stored keys, etc., used in 195 building a chain of trust 197 e. DNS Messages -> DNSSEC Validation Engine DNS Responses needed 198 validation 200 f. Trust Anchor Management & Storage -> DNSSEC Validation Engine 201 Supplies trust anchor information when needed. 203 g. Trust Anchor Management & Storage <- DNSSEC Validation Engine 204 Information to update the trust anchor store, resulting from 205 automated update requests. 207 h. Trust Anchor Management & Storage -> DNS Messages Requests made 208 to manage trust anchors. 210 i. Not shown - Name Server Process Management interfaces to 211 elements, handling of Checking Disabled request, responses, as 212 well as all API requests made of the name server. 214 5. Time derivation and absence of Real Time Clock 216 With M2M communication some devices are not expecting to embed Real 217 Time Clock (Raspberry Pi is one example of such devices). When these 218 devices are re-plugged the initial time is set to January 1 1970. 219 Other devices that have clocks that may suffer from time derivation. 220 All these devices cannot rely on their time estimation to perform 221 DNSSEC validation. 223 REQ1: A DNSSEC validator MUST be provided means to update the time 224 without relying on DNSSEC. 226 Note that updating time in order to be able to perform DNSSEC 227 validation may easily come with a chicken-and-egg problem when the 228 NTP server is designated by its FQDN. The update mechanisms must 229 consider the DNSSEC validator may not able to validate the DNSSEC 230 queries. In other words, the mechanisms may have to update the time 231 over an unsecure DNSSEC resolution. 233 6. Trust Anchor 234 6.1. Trust Anchor Bootstrapping 236 A validator needs to have trust anchors or it will never be able to 237 construct a chain of trust. Trust anchors are defined by DNSSEC to 238 be keys that are inherently trusted, configured by authorized 239 parties, in the validator. The configuration can be via an automated 240 process, such as Automated Updates of DNSSEC Trust Anchors [RFC5011], 241 [I-D.ietf-dnsop-rfc5011-security-considerations], or via manual 242 process. 244 An implementation of a validator needs to allow an operator to choose 245 any automated process supported by the validator. (No requirements 246 are stated about what processes to support, only one is standardized 247 to date.) An implementation needs to also afford the operator the 248 ability to override or manage via a purely manual process, the 249 storage of managed keys. This includes adding, deleting, changing 250 and inspecting. 252 Beyond the scope of these requirements are the decision processes of 253 authorized parties in placing trust in keys. 255 REQ2: A DNSSEC validator MUST check the validity of its Trust 256 Anchors. When a Trust Anchor cannot be verified, the DNSSEC 257 validator MUST send a warning and SHOULD NOT start validating 258 traffic without manual validation. 260 REQ3: A DNSSEC validator SHOULD be able to retrieve a Trust Anchor 261 with bootstrapping mechanism. Such mechanism' security MUST 262 NOT be based on DNSSEC, but could instead include downloading 263 a XML file from a trusted URL, or a PKIX certificate. 265 Although some bootstrapping mechanisms to securely retrieve publish 266 [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor 267 have been defined, it is believed these mechanisms should be extended 268 to other KSKs or Trust Anchors. In fact it is not always possible to 269 build a trusted delegation between the Root Zone and any sub zone. 270 This may happen for example if one of the upper zones does not handle 271 the secure delegation or improperly implement it. A DS RRset may not 272 be properly filled or its associated signature cannot be validated. 273 As the chain of trust between a zone and the root zone may not be 274 validated, the DNSSEC validation for the zone requires a Trust 275 Anchor. Such DNS(SEC) resolutions may be critical for infrastructure 276 management. A company "Example" may, for example, address all its 277 devices under the domain example.com and may not want disruption to 278 happen if the .com delegation cannot be validated for any reason. 279 Such companies may provision there DNSSEC validator with the Trust 280 Anchor KSK for the zone example.com in addition to the regular DNSSEC 281 delegation. Similarly some some domains may present different views 282 such as a "private" view and a "public view". These zones may have 283 some different content, and may use a different KSK for each view. 285 6.2. Trust Anchor Data Store 287 When DNSSEC validator are running and a Trust Anchor KSK roll over is 288 ongoing, a network administrator or any trust party may be willing to 289 check whether the new published keys are being stored in a Trust 290 Anchor Data Store with an appropriated status. Such inspection aims 291 at detecting an non successful Trust Anchor roll over before traffic 292 is being rejected. When a new Trust Anchor has not been considered 293 by the DNSSEC validator, a trusted party may be able to provision the 294 DNSSEC validator with the new Trust Anchor, and eventually may remove 295 the revoked Trust Anchor. 297 While using a Trust Anchor that has been removed results in the 298 DNSSEC validator rejecting multiple legitimate responses, the 299 consequences associated to accepting a rogue Trust Anchor as a 300 legitimate Trust Anchor are even worst. Such attacks would result in 301 an attacker taking control of the entire naming space behind the 302 Trust Anchor. In the case of the Root Zone KSK, for example, almost 303 all name space would be under the control of the attacker. In 304 addition, to the name space, once the rogue Trust Anchor is 305 configured, there is little hope the DNSSEC validator be re- 306 configured with the legitimate Trust Anchor without manual 307 intervention. As a result, it is crucial to cautiously handle 308 operations related to the Trust Anchor provisioning. Means must be 309 provided so network administrator can clearly diagnose the reason a 310 Trust Anchor is not valid to avoid accepting a rogue Trust Anchor 311 inadvertently. 313 DNSSEC may also be used in some private environment. Corporate 314 networks and home networks, for example, may want to take advantage 315 of DNSSEC for a local scope network. Typically, a corporate network 316 may use a local scope Trust Anchor to validate DNS RRsets provided by 317 authoritative DNSSEC server in the corporate network. This use case 318 is also known as the "split-view" use case. These RRsets within the 319 corporate network may differ from those hosted on the public DNS 320 infrastructure. Note that using different Trust Anchor for a given 321 zone may expose a zone to signature invalidation. This is especially 322 the case for DNSSEC validators that are expected to flip-flop between 323 local and public scope. How validators have to handle the various 324 provisioned Trust Anchors is out of scope of the document. 326 Home network may use DNSSEC with TLDs or associated domain names that 327 are of local scope and not even registered in the public DNS 328 infrastructure. This requires the ability to manage the Trust Anchor 329 as well. 331 The necessity to interact with the Trust Anchors lead to the 332 following requirements: 334 REQ4: A DNSSEC validator MUST store its Trust Anchors in a dedicated 335 Trust Anchor Data Store. Such database MUST store 336 informations associated to each Trust Anchor status as well as 337 the time the status has been noticed by the DNSSEC validator. 338 Such database MUST be resilient to DNSSEC validator reboot. 340 REQ5: Trust Anchor states SHOULD at least consider those described 341 in [RFC5011] (Start, AddPend, Valid, Missing, Revoked, 342 Removed). Additional states SHOULD also be able to indicate 343 additional motivations for revoking the Trust Anchor such as a 344 Trust Anchor known to be corrupted, a Trust anchor miss 345 published, or part of a regular roll over procedure. 347 REQ6: A DNSSEC validator MUST provide access to the Trust Anchor 348 Data Sase to authorized user only. Access control is expected 349 to be based on a least privileged principles. 351 REQ7: A trusted party MUST be able to add, remove a Trust Anchor in 352 the Trust Anchor Data Store. 354 6.3. Interactions with the cached RRsets 356 In addition when a Trust Anchor is revoked, the DNSSEC validator may 357 behave differently if the revocation is motivated by a regular roll 358 over operation or instead by revoking a Trust Anchor that is known as 359 being corrupted. In the case the roll over procedure, is motivated 360 by revoking a Trust Anchor that is known to be corrupted, the DNSSEC 361 validator may be willing to flush all RRsets that depends on the 362 Trust Anchor. 364 REQ8: A DNSSEC validator MUST be able to flush the cached RRsets 365 that rely on a Trust Anchor. 367 7. ZSK / KSK 369 7.1. KSK/ZSK Data Store 371 A number of reasons may result in inconsistencies between the RRsets 372 stored in the cache and those published by the authoritative server. 374 An emergency KSK / ZSK rollover may result in a new KSK / ZSK with 375 associated new RRSIG published in the authoritative zone, while 376 DNSSEC validator may still cache the old value of the ZSK / KSK. For 377 a RRset not cached, the DNSSEC validator performs a DNSSEC query to 378 the authoritative server that returns the RRset signed with the new 379 KSK / ZSK. The DNSSEC validator may not be able to retrieve the new 380 KSK / ZSK while being unable to validate the signature with the old 381 KSK / ZSK. This either result in a bogus resolution or in an invalid 382 signature check. Note that by comparing the Key Tag Fields, the 383 DNSSEC validator is able to notice the new KSK / ZSK used for signing 384 differs from the one used to generate the received generated 385 signature. However, the DNSSEC validator is not expectected to 386 retrieve the new ZSK / KSK, as such behavior could be used by an 387 attacker. Intsead, ZSK / ZSK key roll ove rprocedure are expected to 388 avoid such inconsistencies. 390 Similarly, a KSK / ZSK roll over may be performed normally, that is 391 as described in [RFC6781] and [RFC7583]. While the KSK / ZSK roll 392 over is performed, there is no obligation to flush the RRsets in the 393 cache that have been associated with the old key. In fact, these 394 RRset may still be considered as trusted and be removed from the 395 cache as their TTL timeout. With very long TTL, these RRset may 396 remain in the cache while the ZSK / KSK with a shorter TTL is no 397 longer published nor in the cache. In such situations, the purpose 398 of the KSK / ZSK is to validate the data is considered trusted at the 399 time it enters the cache, and such trust may remain after the KSK / 400 ZSK is being rolled over. Note also that even though the data may 401 not be associated to the KSK / ZSK that has been used to valiadte the 402 data, the link between the KSK / ZSK and teh data is still stored in 403 teh cache using the RRSIG. Note also that inconsistencies between 404 the ZSK / KSK stored in the cache and those published on the 405 authoritative server, may lead to inconsistencies to downstream 406 DNSSEC validators that realy on multiple cache over time. Typically, 407 a request for the KSK / ZSK may have been provided by a cache that is 408 storing the new published value, while the data and associated 409 sigature may be associated to the old KSK / ZSK. 411 KSK and ZSK are associated with configuration parameters, and as such 412 are expected to be stored only in the cache. As a result, flushing 413 their value from the cache could constitute a way forward to refresh 414 them. On the other hand, their respective function is also to 415 prevent illegitimate RRsets to be validated and so more understanding 416 is need before taking any action associated to the KSK or ZSK. More 417 specifically, the network administrator SHOULD be provided the 418 appropriated information required to distinguish a misconfiguration 419 from an attack. 421 The following requirements are thus considered for the KSK / ZSK. 423 REQ9: A DNSSEC validator MUST store its KSK/ZSK in a dedicated KSK/ 424 ZSK Data Base. Such database MUST store informations 425 associated to each KSK/ZSK status as well as the time the 426 status has been noticed by the DNSSEC validator. Such 427 database MUST NOT be resilient to DNSSEC validator reboot, 428 that is the information stored in the Data Base MUST NOT be 429 used to populate the cache, while it MAY be used as second 430 factor verification, or audit for example. 432 REQ10: KSK/ZSK status and informaton SHOULD be monitored continuously 433 and associated with their respective state as well as verified 434 time. These states and time SHOULD be resilient to reboot. 436 REQ11: KSK/ZSK states SHOULD at least consider those described in 437 section 3.1 of [RFC7583] (Generated, Published, Ready, Active, 438 Retired, Dead, Removed, Revoked ). Additional states SHOULD 439 also be able to indicate additional motivations for revoking 440 the KSK/ZSK such as a KSK/ZSK known to be corrupted, a KSK/ZSK 441 miss published, or part of a regular roll over procedure. 443 REQ12: A DNSSEC validator MUST provide access to the KSK/ZSK data 444 base to authorized user only. Access control is expected to 445 be based on a least privileged principles. 447 REQ13: A trusted party MUST be able to add, remove a Trust Anchor in 448 the KSK/ZSK Database. 450 Similarly to its counter part the TA Data Store, the KSK/ZSK Data 451 Store is expected to be resilient to reboot. However the motivation 452 for having the KSK/ZSK Data Store resilient to reboot differs from 453 those for making the TA Data Store resilient to reboot. TA Data 454 Store needs to be resilient as the Trust Anchors are necessary to 455 perform the DNSSEC validation. KSK/ZSK are not expected to be 456 locally stored, but instead are expected to be resolved, validated by 457 the TA and stored in the cache. The reason for making the KSK/ZSK 458 Data Store resilient to reboot is mostly to enable audit of the 459 DNSSEC validator. 461 7.2. KSK/ZSK Data Store and Trust Anchor Data Store 463 A zone may have been badly signed, which means that the KSK or ZSK 464 cannot validate the RRSIG associated to the RRsets. This may not be 465 due to a key roll over, but to an incompatibility between the keys 466 (KSK or ZSK) and the signatures. 468 When such situation occurs, there is only a choice between not 469 validating the RRsets or invalidating their signature. This is a 470 policy design that needs to be taken by the network administrator. 471 In other ways, flushing the RRset are not expected to address this 472 issue. Such KSK/ZSK are known as Negative Trust Anchors [RFC7646]. 474 With Negative Trust Anchor, the zone for a given time will be known 475 as "known insecure". The DNSSEC Validator is not expected to perform 476 signature validation for this zone. It is expected that this 477 information is associated to a Time To Live (TTL). 479 Note that, this information may be used as an attack vector to 480 impersonate a zone, and must be provided in a trusted way, by a 481 trusted party. 483 If a zone has been badly signed, the administrator of the 484 authoritative DNS server may resign the zone with the same keys or 485 proceed to an emergency key rollover. If the signature is performed 486 with the same keys, the DNSSEC Validator may notice by itself that 487 RRSIG can be validated. On the other hand if a key rollover is 488 performed, the newly received RRSIG will carry a new key id. Upon 489 receiving a new key id in the RRSIG, the DNSSEC Validator is expected 490 to retrieve the new ZSK/KSK. If the RRSIG can be validated, the 491 DNSSEC Validator is expected to remove the "known insecure" flag. 493 However, if the KSK/ZSK are rolled over and RRSIG cannot be 494 validated, it remains hard for the DNSSEC validator to determine 495 whether the RRSIG cannot be validated or that RRSIG are invalid. As 496 a result: 498 REQ14: A trusted party MUST be able to indicate a DNSSEC validator 499 that a KSK or a ZSK as Negative Trust Anchor. Such Trust 500 Anchors MUST NOT be used for RRSIG validation and MUST be 501 moved to the Trust Anchor Data Store, so the information 502 become resilient to reboot. 504 REQ15: A trusted party MUST be able to indicate a DNSSEC validator 505 that a KSK/ZSK is known "back to secure". 507 7.3. Interactions with cached RRsets 509 The key roll over procedure intends to ensure that the published 510 RRsets can be validated with the KSK / ZSK stored in the various 511 cache of the DNSSEC validators. As a consequence, the key roll over 512 enables trusted data to be cached. However, the key roll over does 513 not necessarily prevents that cached be always validated with the 514 currenlty published key. In fact, a cached data may have been 515 validated by the former key and remain in the cache while the former 516 key has been rolled out. Such inconsistencies may be acceptable and 517 correspond to the following trust model: the KSK / ZSK validate the 518 cached data can be trusted at time T. There is no specific 519 information that leads to considers that trust at time T is subject 520 to doubts at current time, so the cached data remain trusted. 522 While such inconsistencies may have little impact on end host DNSSEC 523 validators, it may be different for large resolving platforms with 524 downstream DNSSEC validators, and a DNSSEC validator may be willing 525 to maintain its cached data consistent with the published KSK / ZSK. 526 A trusted third party may willing to remove all cached RRsets that 527 have been validated by the KSK/ZSK upon some specific states 528 (revoked, or Removed for example), of after some time after the state 529 is noticed. In this later case, only the RRset whose TTL has not 530 expired yet would be flushed. 532 On the other hand, when a KSK / ZSK is known to be corrupted, this 533 state may affect the trust that has been established at time T. In 534 such case, the DNSSEC validator may be willling to flush all cached 535 data that has been validated by the currently known corrupted KSK / 536 ZSK, including the KSK / ZSK itslef. 538 As a result, the following requirements are expected: 540 REQ16: A DNSSEC validator MUST be able to flush the cached KSK/ZSK. 542 REQ17: A DNSSEC validator MUST be able to flush the cached RRsets 543 associated to a KSK/ZSK. 545 8. DS 547 The DS RRset is stored in the parent zone to build a chain of trust 548 with the child zone. This DS RRset can be invalid because its RDATA 549 (KSK) is not anymore used in the child zone or because the DS is 550 badly signed and cannot be validated by the DNSSEC Validator. 552 In both cases the child zone is considered as bogus and the valid 553 child zone's KSK should become a Trust Anchor KSK. This requirements 554 is fulfilled by the requirement to add a Trust Anchor in Section 6. 556 9. Cryptography Deprecation 558 As mentioned in [RFC8247] and [RFC8221] cryptography used one day is 559 expected over the time to be replaced by new and more robust 560 cryptographic mechanisms. In the case of DNSSEC signature protocols 561 are likely to be updated over time. In order to anticipate the 562 sunset of one of the signature scheme, a DNSSEC validator may willing 563 to estimate the impact of deprecating one signature scheme. 565 Currently [RFC6975] provides the ability for a DNSSEC validator to 566 announce an authoritative server the supported signature schemes. 567 However, a DNSSEC validator is not able to determine other than by 568 trying whether a signature scheme is supported by the authoritative 569 server. 571 In order for a DNSSEC validator to safely deprecate one signature 572 scheme the following requirement should be fulfilled. 574 REQ18: A DNSSEC validator SHOULD be able to request the signature 575 scheme supported by an authoritative server. 577 10. Reporting 579 A DNSSEC validator receiving a DNS response cannot make the 580 difference between receiving an non-secure response versus an attack. 581 Dropping DNSSEC fields by a misconfigured middle boxes, such as DS, 582 RRRSIG is considered as an attack. 584 A DNSSEC validator is expected to perform secure DNS resolution and 585 as such protect its stub client. An invalid response may be the 586 result of an attack or a misconfiguration, and the DNSSEC validator 587 may play an important role in sharing this information. 589 REQ19: A DNSSEC validation SHOULD be able to report the 590 unavailability of the DNSSEC service. 592 REQ20: A DNSSEC validator SHOULD be able to report a invalid DNSSEC 593 validation. 595 11. IANA Considerations 597 There are no IANA consideration for this document. 599 12. Security Considerations 601 The requirements listed in this document aim at providing the DNSSEC 602 validator appropriated information so DNSSEC validation can be 603 performed. On the other hand, providing inappropriate information 604 can lead to misconfiguring the DNSSEC validator, and thus disrupting 605 the DNSSEC resolution service. As a result, enabling the setting of 606 configuration parameters by a third party may open a wide surface of 607 attacks. 609 As an appropriate time value is necessary to perform signature check 610 (cf. Section 5), an attacker may provide rogue time value to prevent 611 the DNSSEC validator to check signatures. 613 An attacker may also affect the resolution service by regularly 614 asking the DNSSEC validator to flush the KSK/ZSK from its cache (cf. 615 Section 7). All associated data will also be flushed. This 616 generates additional DNSSEC resolution and additional validations, as 617 RRSet that were cached require a DNSSEC resolution over the Internet. 619 This affects the resolution service by slowing down responses, and 620 increases the load on the DNSSEC validator. 622 An attacker may ask the DNSSEC validator to consider a rogue KSK/ZSK 623 ( cf. Invalid DS in Section 8 or Private KSK in Section 6), thus 624 hijacking the DNS zone. Similarly, (cf. Section 7) an attacker may 625 inform the DNSSEC validator not to trust a given KSK in order to 626 prevent DNSSEC validation to be performed. 628 An attacker (cf. Section 7) can advertise a "known insecure" KSK or 629 ZSK is "back to secure" to prevent signature check to be performed 630 correctly. 632 As a result, information considered by the DNSSEC validator should be 633 from a trusted party. This trust party should have been 634 authenticated, and the channel used to exchange the information 635 should also be protected and authenticated. 637 13. Acknowledgment 639 The need to address DNSSEC issues on the resolver side started in the 640 Home Networks mailing list and during the IETF87 in Berlin. Among 641 others, people involved in the discussion were Ted Lemon, Ralph 642 Weber, Normen Kowalewski, and Mikael Abrahamsson. People involved in 643 the email discussion initiated by Jim Gettys were, with among others, 644 Paul Wouters, Joe Abley and Michael Richardson. 646 The current document has been initiated after a discussion with Paul 647 Wouter and Evan Hunt. 649 14. References 651 14.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 659 Rose, "DNS Security Introduction and Requirements", 660 RFC 4033, DOI 10.17487/RFC4033, March 2005, 661 . 663 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 664 Rose, "Resource Records for the DNS Security Extensions", 665 RFC 4034, DOI 10.17487/RFC4034, March 2005, 666 . 668 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 669 Rose, "Protocol Modifications for the DNS Security 670 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 671 . 673 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 674 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 675 September 2007, . 677 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 678 Algorithm Understanding in DNS Security Extensions 679 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 680 . 682 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 683 Kivinen, "Cryptographic Algorithm Implementation 684 Requirements and Usage Guidance for Encapsulating Security 685 Payload (ESP) and Authentication Header (AH)", RFC 8221, 686 DOI 10.17487/RFC8221, October 2017, 687 . 689 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 690 "Algorithm Implementation Requirements and Usage Guidance 691 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 692 RFC 8247, DOI 10.17487/RFC8247, September 2017, 693 . 695 14.2. Informational References 697 [I-D.ietf-dnsop-rfc5011-security-considerations] 698 Hardaker, W. and W. Kumari, "Security Considerations for 699 RFC5011 Publishers", draft-ietf-dnsop-rfc5011-security- 700 considerations-07 (work in progress), October 2017. 702 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 703 Operational Practices, Version 2", RFC 6781, 704 DOI 10.17487/RFC6781, December 2012, 705 . 707 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 708 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 709 DOI 10.17487/RFC7583, October 2015, 710 . 712 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 713 and R. Weber, "Definition and Use of DNSSEC Negative Trust 714 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 715 . 717 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 718 "DNSSEC Trust Anchor Publication for the Root Zone", 719 RFC 7958, DOI 10.17487/RFC7958, August 2016, 720 . 722 [UNBOUND-ANCHOR] 723 "unbound-anchor.c File Reference", 724 . 727 Authors' Addresses 729 Daniel Migault 730 Ericsson 732 Email: daniel.migault@ericsson.com 734 Dan York 735 Internet Society 737 Email: york@isoc.org 739 Edward Lewis 740 ICANN 742 Email: edward.lewis@icann.org