idnits 2.17.1 draft-mglt-dnsop-dnssec-validator-requirements-07.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 == Line 149 has weird spacing: '...lidator the e...' == Line 152 has weird spacing: '...idation valid...' == Line 155 has weird spacing: '...a Store a mod...' == Line 233 has weird spacing: '... Engine follo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 28, 2018) is 1948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 6 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: Informational E. Lewis 5 Expires: June 1, 2019 ICANN 6 D. York 7 ISOC 8 November 28, 2018 10 DNSSEC Validator Requirements 11 draft-mglt-dnsop-dnssec-validator-requirements-07 13 Abstract 15 The DNS Security Extensions define a process for validating received 16 data and assert them authentic and complete as opposed to forged. 18 This document describes what is needed in implementations to make the 19 validation process manageable Considerations for accurate time as 20 well as management of the trust anchor store. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 1, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. DNSSEC Validator Description . . . . . . . . . . . . . . . . 4 60 5. Time deviation and absence of Real Time Clock . . . . . . . . 6 61 6. Trust Anchor . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Trust Anchor Bootstrapping . . . . . . . . . . . . . . . 6 63 6.1.1. The IANA managed root zone KSK . . . . . . . . . . . 7 64 6.2. Trust Anchor Data Store . . . . . . . . . . . . . . . . . 8 65 6.3. Interactions with the cached RRsets . . . . . . . . . . . 9 66 7. ZSK / KSK . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. KSK/ZSK Data Store . . . . . . . . . . . . . . . . . . . 10 68 7.2. KSK ZSK Data Store and Trust Anchor Data Store . . . . . 12 69 7.3. Interactions with cached RRsets . . . . . . . . . . . . . 13 70 8. Cryptography Deprecation . . . . . . . . . . . . . . . . . . 13 71 9. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 13.2. Informative References . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Requirements Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described BCP 14 85 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 86 as shown here. 88 2. Introduction 90 The act of DNSSEC validation [RFC4033][RFC4035] can be broken into 91 two part: 93 o Signature Validation: which consists in checking the cryptographic 94 signature of a Resource Record Set (RRset). The signature 95 validation involves among other parameters a DNSKEY Resource 96 Record (RR) and RRSIG RR and the RRset itself. The signature 97 validation process results in assertion that the owner of the 98 private part of the public key contained in the DNSKEY RR has 99 effectively published the RRset. The binding between the private 100 key and the RRset is provided by the trust in the cryptographic 101 algorithm. 103 o Trust: Signature Validation results in asserting a RRset is 104 accurately validated if there is sufficient trust that the owner 105 of the private key associated to the DNSKEY RR is the owner of the 106 RRset - i.e. that is to say is the legitimate owner. Such trust 107 is provided by a Trust Anchor (TA), and the chain of trust 108 established between the TA and the DNSKEY RR. The chain of trust 109 is obtained by recursively validating the DNSKEY RRs. As a 110 result, such trust results from the trust placed in the TA as well 111 as the delegation mechanism provided by DNSSEC and the Signature 112 Validation. As TAs need to be managed over time, the trust also 113 concerns the management procedure of the TA. This is the main 114 concern of this document. 116 Once accurately validated the RRset is assumed to be accurately 117 validated and trusted trusted during the time indicated by its TTL. 119 A threat associated to the Signature Validation could consist in a 120 RRSet maliciously forged to be validated by a trusted DNSKEY RR. 121 Such threat mostly rely on the use of weak cryptography by the 122 authoritative server, and the DNSSEC validator has little means to 123 prevent such threats. 125 The document considers instead the threat associated to the 126 establishment of the trust where a DNSKEY RR is maliciously 127 established. This may be through a weakness in the authentication of 128 changes to the zone administration database, allowing a malicious key 129 to be added and then signed according to the DNSSEC process. Once 130 this is discovered to have happened, other data validated via such a 131 key should be called into question. 133 This document is focused on the necessary mechanisms that DNSSEC 134 validators should implement in order to implement sufficient Trust 135 that makes DNSSEC validation output accurate. The mechanisms 136 described in this document include, provisioning mechanisms as well 137 as monitoring and management mechanisms that enables an administrator 138 to validate the validity of the DNSSEC validation output. 140 The mechanisms provided are designed in accordance of the DNSSEC 141 trust model as to meet the current operations of DNSSEC. Such trust 142 model is briefly recapped in Section 4 so operators understand the 143 limits and motivations for such mechanisms. 145 3. Terminology 147 This document uses the following terminology: 149 DNSSEC validator the entity that performs DNSSEC resolution and 150 performs signature validation. 152 Accurate validation validation that avoids false positives and 153 catches true negatives. 155 Trust Anchor Data Store a module (of code) implementing functions 156 related to the trust anchors used by the validator. This is 157 essentially a database allowing access, monitoring of, and changes 158 to trust anchors. 160 4. DNSSEC Validator Description 162 This is a conceptual block diagram of the elements involved with 163 DNSSEC validation. This is not meant to be an architecture for code, 164 this is meant to be a framework for discussion and explanation. 166 +-------------+ +---------------+ 167 | | | | 168 | Time Source | | Cryptographic | 169 | | | Libraries | 170 | | | | 171 +-------------+ +---------------+ 172 | | 173 v v 174 +--------------------------------+ +--------------+ 175 | | | | 176 | |<--| Trust Anchor | 177 | DNSSEC Validation Engine | | Manager & | 178 | |-->| Storage | 179 | | | | 180 +--------------------------------+ +--------------+ 181 ^ | ^ | 182 | v | | 183 +-------------+ +---------------+ | 184 | | | | | 185 | DNS Caches | | DNS Messages |<---------+ 186 | | | | 187 +-------------+ +---------------+ 189 Figure 1: DNSSEC Validator Description 191 Time Source The wall clock time provides the DNSSEC Validation 192 Engine the current time. Time is among other used to validate the 193 RRSIG Signature and Inception Fields to provide some protection 194 against replay attacks. 196 Cryptograhic Libraries The code performing mathematical functions 197 provides the DNSSEC Validation Engine the ability to check the 198 Signature Field that contains the cryptographic signature covering 199 the RRSIG RDATA. 201 DNS Message DNS responses are used to carry the information from the 202 DNS system. The receiver of the DNS message can be any kind of 203 application including DNS-related application such as in the case 204 of automated Trust Anchor update performed by the Trust Anchor 205 Manager & Storage. The DNSSEC Validator Engine accurately 206 validates the DNS responses before caching them in the DNS Cache 207 and forwarding them to the DNS receiver. In case of validation 208 failure, an error is returned and the information may be 209 negatively cached. 211 DNS Caches Include positive and negative caches. The DNSSEC 212 Validation Engine fills DNS Caches with the results of a 213 validation (positive data, negative failures). The DNSSEC trust 214 model considers that once a RRset has been accurately validated by 215 the DNSSEC Validator Engine, the RRset is considered trusted (or 216 untrusted) for its associated TTL. DNS Caches contain RRsets that 217 may contain information requested by the application (RRset of 218 type AAAA for example) as well as RRset necessary to accurately 219 validate the RRsets (RRsets of type DNSKET or RRSIG for example). 220 It also worth noticing that RRset validated with DNSSEC or RRset 221 that are not validated with DNSSEC fill the DNS Cache with the 222 same level of trust. 224 Trust Anchor Manager The database of trust anchors associated to 225 database management processes. This function provides the DNSSEC 226 Validation Engine Trust Anchor information when needed. When TA 227 needs to be updated, the Trust Anchor Manager is also responsible 228 to handle the updating procedure. This includes sending DNS 229 Messages as well as treating appropriately the DNS responses that 230 have been accurately validated by the DNSSEC Validator Engine. 231 This will end up in the DNSSEC Validator Engine pushing new TAs. 233 DNSSEC Validation Engine follows local policy to approve data. The 234 approved data is returned to the requesting application as well as 235 in the DNS Caches. While the cryptographic computation of the 236 RRSIG signature may be the most visible step, the RRSIG record 237 also contains other information intended to help the validator 238 perform its work, in some cases "sane value" checks are performed. 239 For instance, the original TTL (needed to prepare the RR set for 240 validation) ought to be equal to or higher than the received TTL. 242 Not shown - Name Server Process Management interfaces to elements, 243 handling of Checking Disabled request, responses, as well as all API 244 requests made of the name server. 246 5. Time deviation and absence of Real Time Clock 248 With M2M communication some devices are not expecting to embed Real 249 Time Clock (Raspberry Pi is one example of such devices). When these 250 devices are re-plugged the initial time is set to January 1 1970. 251 Other devices that have clocks that may suffer from time deviation. 252 These devices cannot rely on their time estimation to perform DNSSEC 253 validation. 255 REQ1 A DNSSEC validator MUST be provided means to update the time 256 without relying on DNSSEC. 258 Note that updating time in order to be able to perform DNSSEC 259 validation may become a form of a chicken-and-egg problem when the 260 NTP server is designated by its FQDN. The update mechanisms must 261 consider the DNSSEC validator may not able to validate the DNSSEC 262 queries. In other words, the mechanisms may have to update the time 263 over an unsecure DNSSEC resolution. 265 6. Trust Anchor 267 6.1. Trust Anchor Bootstrapping 269 A validator needs to have trust anchors or it will never be able to 270 construct a chain of trust. Trust anchors are defined by DNSSEC to 271 be keys that are inherently trusted, configured by authorized 272 parties, in the validator. The configuration can be via an automated 273 process, such as Automated Updates of DNSSEC Trust Anchors [RFC5011], 274 [I-D.ietf-dnsop-rfc5011-security-considerations], or via manual 275 process. 277 An implementation of a validator needs to allow an operator to choose 278 any automated process supported by the validator. (No requirements 279 are stated about what processes to support, only one is standardized 280 to date.) An implementation needs to also afford the operator the 281 ability to override or manage via a purely manual process, the 282 storage of managed keys. This includes adding, deleting, changing 283 and inspecting. 285 Beyond the scope of these requirements are the decision processes of 286 authorized parties in placing trust in keys. 288 REQ2 A DNSSEC validator MUST check the validity of its Trust 289 Anchors. When a Trust Anchor cannot be verified, the DNSSEC 290 validator MUST send a warning and SHOULD NOT start validating 291 traffic without manual validation. 293 REQ3 A DNSSEC validator SHOULD be able to retrieve a Trust Anchor 294 with bootstrapping mechanism. Such mechanism' security MUST NOT 295 be based on DNSSEC, but could instead include downloading a XML 296 file from a trusted URL, or a PKIX certificate. 298 Although some bootstrapping mechanisms to securely retrieve publish 299 [RFC7958] and retrieve [UNBOUND-ANCHOR] the Root Zone Trust Anchor 300 have been defined, it is believed these mechanisms should be extended 301 to other KSKs or Trust Anchors. In fact it is not always possible to 302 build a trusted delegation between the Root Zone and any sub zone. 303 This may happen for example if one of the upper zones does not handle 304 the secure delegation or improperly implement it. A DS RRset may not 305 be properly filled or its associated signature cannot be validated. 306 As the chain of trust between a zone and the root zone may not be 307 validated, the DNSSEC validation for the zone requires a Trust 308 Anchor. Such DNS(SEC) resolutions may be critical for infrastructure 309 management. A company "Example" may, for example, address all its 310 devices under the domain example.com and may not want disruption to 311 happen if the .com delegation cannot be validated for any reason. 312 Such companies may provision there DNSSEC validator with the Trust 313 Anchor KSK for the zone example.com in addition to the regular DNSSEC 314 delegation. Similarly some some domains may present different views 315 such as a "private" view and a "public view". These zones may have 316 some different content, and may use a different KSK for each view. 318 6.1.1. The IANA managed root zone KSK 320 The IANA managed root zone KSK is an operationally significant trust 321 point in the global public Internet. Attention to the trust anchor 322 for this point is paramount. Trust anchor management ought to 323 recognize that the majority of operators deploying DNSSEC validators 324 will need to explicitly or implicitly rely on this trust anchor. 325 Trust anchor management needs to recognize that there may be other 326 trust anchors of interest to operators. Besides deployments in 327 networks other than the global public Internet (hence a different 328 root), operators may want to configure other trust points. 330 The IANA managed root zone KSK is managed and published as described 331 in "DNSSEC Trust Anchor Publication for the Root Zone" [RFC7598]. 332 That document is written as specific to that trust point. Other 333 trust points may adopt the technique describe (or may use other 334 approaches). 336 This represents a consideration for implementations. On one hand, 337 operators will place special emphasis on how the root zone DNSSEC KSK 338 is managed. On the other hand, implementations ought to accommodate 339 trust anchors in a general manner, despite the odds that other trust 340 anchors will not be configured in a specific deployment. 342 Because of this, it is recommended that implementations make the root 343 zone trust anchor obvious to the operator while still enabling 344 configuration of general trust points. 346 6.2. Trust Anchor Data Store 348 When DNSSEC validator are running and a Trust Anchor KSK roll over is 349 ongoing, a network administrator or any trust party may be willing to 350 check whether the new published keys are being stored in a Trust 351 Anchor Data Store with an appropriated status. Such inspection aims 352 at detecting an non successful Trust Anchor roll over before traffic 353 is being rejected. When a new Trust Anchor has not been considered 354 by the DNSSEC validator, a trusted party may be able to provision the 355 DNSSEC validator with the new Trust Anchor, and eventually may remove 356 the revoked Trust Anchor. 358 While using a Trust Anchor that has been removed results in the 359 DNSSEC validator rejecting multiple legitimate responses, the 360 consequences associated to accepting a rogue Trust Anchor as a 361 legitimate Trust Anchor are even worst. Such attacks would result in 362 an attacker taking control of the entire naming space behind the 363 Trust Anchor. In the case of the Root Zone KSK, for example, almost 364 all name space would be under the control of the attacker. In 365 addition, to the name space, once the rogue Trust Anchor is 366 configured, there is little hope the DNSSEC validator be re- 367 configured with the legitimate Trust Anchor without manual 368 intervention. As a result, it is crucial to cautiously handle 369 operations related to the Trust Anchor provisioning. Means must be 370 provided so network administrator can clearly diagnose the reason a 371 Trust Anchor is not valid to avoid accepting a rogue Trust Anchor 372 inadvertently. 374 DNSSEC may also be used in some private environment. Corporate 375 networks and home networks, for example, may want to take advantage 376 of DNSSEC for a local scope network. Typically, a corporate network 377 may use a local scope Trust Anchor to validate DNS RRsets provided by 378 authoritative DNSSEC server in the corporate network. This use case 379 is also known as the "split-view" use case. These RRsets within the 380 corporate network may differ from those hosted on the public DNS 381 infrastructure. Note that using different Trust Anchor for a given 382 zone may expose a zone to signature invalidation. This is especially 383 the case for DNSSEC validators that are expected to flip-flop between 384 local and public scope. How validators have to handle the various 385 provisioned Trust Anchors is out of scope of the document. 387 Home network may use DNSSEC with TLDs or associated domain names that 388 are of local scope and not even registered in the public DNS 389 infrastructure. This requires the ability to manage the Trust Anchor 390 as well. 392 The necessity to interact with the Trust Anchors lead to the 393 following requirements: 395 REQ4 A DNSSEC validator MUST store its Trust Anchors in a dedicated 396 Trust Anchor Data Store. Such database MUST store information 397 associated to each Trust Anchor status as well as the time the 398 status has been noticed by the DNSSEC validator. Such database 399 MUST be resilient to DNSSEC validator reboot. 401 REQ5 Trust Anchor states SHOULD at least consider those described in 402 [RFC5011] (Start, AddPend, Valid, Missing, Revoked, Removed). 403 Additional states SHOULD also be able to indicate additional 404 motivations for revoking the Trust Anchor such as a Trust Anchor 405 known to be corrupted, a Trust anchor miss published, or part of a 406 regular roll over procedure. 408 REQ6 A DNSSEC validator MUST provide access to the Trust Anchor Data 409 Base to authorized user only. Access control is expected to be 410 based on a least privileged principles. 412 REQ7 A trusted party MUST be able to add, remove a Trust Anchor in 413 the Trust Anchor Data Store. 415 6.3. Interactions with the cached RRsets 417 In addition when a Trust Anchor is revoked, the DNSSEC validator may 418 behave differently if the revocation is motivated by a regular roll 419 over operation or instead by revoking a Trust Anchor that is known as 420 being corrupted. In the case the roll over procedure, is motivated 421 by revoking a Trust Anchor that is known to be corrupted, the DNSSEC 422 validator may be willing to flush all RRsets that depends on the 423 Trust Anchor. 425 REQ8 A DNSSEC validator MUST be able to flush the cached RRsets that 426 rely on a Trust Anchor. 428 7. ZSK / KSK 430 KSK / ZSK are not part of the DNSSEC validator configuration. Their 431 values in the DNS Caches may not reflect those published by the 432 authoritative servers or may be incoherent with the RRset in the DNS 433 Cache they are validating. However, such incoherence primary results 434 from error in the management of the authoritative servers. As a 435 result, it is not expected that the DNSSEC validator provides complex 436 management facilities to address these issues as this will modify the 437 DNS architecture and add complexity that is not proved to be 438 beneficial. 440 7.1. KSK/ZSK Data Store 442 A number of reasons may result in inconsistencies between the RRsets 443 stored in the cache and those published by the authoritative server. 445 An emergency KSK / ZSK rollover may result in a new KSK / ZSK with 446 associated new RRSIG published in the authoritative zone, while 447 DNSSEC validator may still cache the old value of the ZSK / KSK. For 448 a RRset not cached, the DNSSEC validator performs a DNSSEC query to 449 the authoritative server that returns the RRset signed with the new 450 KSK / ZSK. The DNSSEC validator may not be able to retrieve the new 451 KSK / ZSK while being unable to validate the signature with the old 452 KSK / ZSK. This either result in a bogus resolution or in an invalid 453 signature check. Note that by comparing the Key Tag Fields, the 454 DNSSEC validator is able to notice the new KSK / ZSK used for signing 455 differs from the one used to generate the received generated 456 signature. However, the DNSSEC validator is not expected to retrieve 457 the new ZSK / KSK, as such behavior could be used by an attacker. 458 Instead, ZSK / ZSK key roll over procedure are expected to avoid such 459 inconsistencies. 461 Similarly, a KSK / ZSK roll over may be performed normally, that is 462 as described in [RFC6781] and [RFC7583]. While the KSK / ZSK roll 463 over is performed, there is no obligation to flush the RRsets in the 464 cache that have been associated with the old key. In fact, these 465 RRset may still be considered as trusted and be removed from the 466 cache as their TTL timeout. With very long TTL, these RRset may 467 remain in the cache while the ZSK / KSK with a shorter TTL is no 468 longer published nor in the cache. In such situations, the purpose 469 of the KSK / ZSK is to validate the data is considered trusted at the 470 time it enters the cache, and such trust may remain after the KSK / 471 ZSK is being rolled over. Note also that even though the data may 472 not be associated to the KSK / ZSK that has been used to validate the 473 data, the link between the KSK / ZSK and the data is still stored in 474 the cache using the RRSIG. Note also that inconsistencies between 475 the ZSK / KSK stored in the cache and those published on the 476 authoritative server, may lead to inconsistencies to downstream 477 DNSSEC validators that rely on multiple cache over time. Typically, 478 a request for the KSK / ZSK may have been provided by a cache that is 479 storing the new published value, while the data and associated 480 signatures may be associated to the old KSK / ZSK. 482 Incoherence between RRsets and DNSKEYs may be limited by configuring 483 the DNSSEC validator with generic rules that applies to the 484 validation process. Typically, the TTL associate to the DNSKEY is an 485 engagement from the authoritative server that the DNSKEY will remain 486 valid over this period. As this engagement supersedes the validation 487 of any RRSIG and by extension to any RRset in the zone, this TTL 488 value may be used as the maximum value for the TTL associated to 489 FQDNs in the zone. This would at least reduce inconsistencies during 490 regular KSK roll over. In addition, the DNSSEC validator should also 491 be able to provide a maximum values for TTLs. 493 REQ DNSSEC Validator MUST be able to enforce TTL policies of RRsets 494 based on the TTL of the KSK/ZSK. RRsets TTL SHOULD NOT exceed the 495 KSK / ZSK initial TTL value. 497 The detection of a misbehaving KSK / ZSK mostly results from 498 publication misconfigurations or an attack at the publication level. 499 As a result, a primary focus is put on DNSSEC Validators monitoring 500 KSK / ZSK with sufficient care to enable the network administrator to 501 take the appropriated actions. Such actions could include out-of- 502 band exchanges as well as specific actions details in section 503 Section 7.2 and section Section 7.3. The monitoring requirements on 504 KSK / ZSK are as follows: 506 REQ9 A DNSSEC validator MUST log its KSK/ZSK in a dedicated KSK/ ZSK 507 Data Base. Such database MUST store information associated to 508 each KSK/ZSK status as well as the time the status has been 509 noticed by the DNSSEC validator. Such database SHOULD be 510 resilient to DNSSEC validator reboot, that is the information 511 stored in the Data Base MUST NOT be used to populate the cache, 512 while it MAY be used as second factor verification, or audit for 513 example. 515 REQ10 KSK/ZSK status and information SHOULD be monitored 516 continuously and associated with their respective state as well as 517 verified time. These states and time SHOULD be resilient to 518 reboot. 520 REQ11 KSK/ZSK states SHOULD at least consider those described in 521 section 3.1 of [RFC7583] (Generated, Published, Ready, Active, 522 Retired, Dead, Removed, Revoked ). Additional states SHOULD also 523 be able to indicate additional motivations for revoking the KSK/ 524 ZSK such as a KSK/ZSK known to be corrupted, a KSK/ZSK miss 525 published, or part of a regular roll over procedure. 527 7.2. KSK ZSK Data Store and Trust Anchor Data Store 529 A zone may have been badly signed, which means that the KSK or ZSK 530 cannot validate the RRSIG associated to the RRsets. This may not be 531 due to a key roll over, but to an incompatibility between the keys 532 (KSK or ZSK) and the signatures. 534 When such situation occurs, there is only a choice between not 535 validating the RRsets or invalidating their signature. This is a 536 policy design that needs to be taken by the network administrator. 537 In other ways, flushing the RRset are not expected to address this 538 issue. Such KSK/ZSK are known as Negative Trust Anchors [RFC7646]. 540 With Negative Trust Anchor, the zone for a given time will be known 541 as "known insecure". The DNSSEC Validator is not expected to perform 542 signature validation for this zone. It is expected that this 543 information is associated to a Time To Live (TTL). Note that, this 544 information may be used as an attack vector to impersonate a zone, 545 and must be provided in a trusted way, by a trusted party. 547 If a zone has been badly signed, the administrator of the 548 authoritative DNS server may resign the zone with the same keys or 549 proceed to an emergency key rollover. If the signature is performed 550 with the same keys, the DNSSEC Validator may notice by itself that 551 RRSIG can be validated. On the other hand if a key rollover is 552 performed, the newly received RRSIG will carry a new key id. Upon 553 receiving a new key id in the RRSIG, the DNSSEC Validator is expected 554 to retrieve the new ZSK/KSK. If the RRSIG can be validated, the 555 DNSSEC validator is expected to remove the "known insecure" flag. 557 However, if the KSK/ZSK are rolled over and RRSIG cannot be 558 validated, it remains hard for the DNSSEC validator to determine 559 whether the RRSIG cannot be validated or that RRSIG are invalid. As 560 a result: 562 REQ14 A trusted party MUST be able to indicate a DNSSEC validator 563 that a KSK or a ZSK as Negative Trust Anchor. Such Trust Anchors 564 MUST NOT be used for RRSIG validation and MUST be moved to the 565 Trust Anchor Data Store, so the information become resilient to 566 reboot. 568 REQ15 A trusted party MUST be able to indicate a DNSSEC validator 569 that a KSK/ZSK is known "back to secure". 571 7.3. Interactions with cached RRsets 573 The key roll over procedure intends to ensure that the published 574 RRsets can be validated with the KSK / ZSK stored in the various 575 cache of the DNSSEC validators. As a consequence, the key roll over 576 enables trusted data to be cached. However, the key roll over does 577 not necessarily prevents that cached be always validated with the 578 currently published key. In fact, a cached data may have been 579 validated by the former key and remain in the cache while the former 580 key has been rolled out. Such inconsistencies may be acceptable and 581 correspond to the following trust model: the KSK / ZSK validate the 582 cached data can be trusted at time T. There is no specific 583 information that leads to considers that trust at time T is subject 584 to doubts at current time, so the cached data remain trusted. 586 While such inconsistencies may have little impact on end host DNSSEC 587 validators, it may be different for large resolving platforms with 588 downstream DNSSEC validators, and a DNSSEC validator may be willing 589 to maintain its cached data consistent with the published KSK / ZSK. 590 A trusted third party may willing to remove all cached RRsets that 591 have been validated by the KSK/ZSK upon some specific states 592 (revoked, or Removed for example), of after some time after the state 593 is noticed. In this later case, only the RRset whose TTL has not 594 expired yet would be flushed. 596 On the other hand, when a KSK / ZSK is known to be corrupted, this 597 state may affect the trust that has been established at time T. In 598 such case, the DNSSEC validator may be willing to flush all cached 599 data that has been validated by the currently known corrupted KSK / 600 ZSK, including the KSK / ZSK itself. 602 As a result, the following requirements are expected: 604 REQ16 A DNSSEC validator MUST be able to flush the cached KSK/ZSK. 606 REQ17 A DNSSEC validator SHOULD be able to flush the cached RRsets 607 associated to a KSK/ZSK. 609 8. Cryptography Deprecation 611 As mentioned in [RFC8247] and [RFC8221] cryptography used one day is 612 expected over the time to be replaced by new and more robust 613 cryptographic mechanisms. In the case of DNSSEC signature protocols 614 are likely to be updated over time. In order to anticipate the 615 sunset of one of the signature scheme, a DNSSEC validator may willing 616 to estimate the impact of deprecating one signature scheme. 618 Currently [RFC6975] provides the ability for a DNSSEC validator to 619 announce an authoritative server the supported signature schemes. 620 However, a DNSSEC validator is not able to determine other than by 621 trying whether a signature scheme is supported by the authoritative 622 server. 624 In order for a DNSSEC validator to safely deprecate one signature 625 scheme the following requirement should be fulfilled. 627 REQ18 A DNSSEC validator SHOULD be able to request the signature 628 scheme supported by an authoritative server. 630 9. Reporting 632 A DNSSEC validator receiving a DNS response cannot make the 633 difference between receiving an non-secure response versus an attack. 634 Dropping DNSSEC fields by a misconfigured middle boxes, such as DS, 635 RRRSIG is considered as an attack. A DNSSEC validator is expected to 636 perform secure DNS resolution and as such protect its stub client. 637 An invalid response may be the result of an attack or a 638 misconfiguration, and the DNSSEC validator may play an important role 639 in sharing this information. 641 REQ19 A DNSSEC validation SHOULD be able to report the 642 unavailability of the DNSSEC service. 644 REQ20 A DNSSEC validator SHOULD be able to report a invalid DNSSEC 645 validation. 647 10. IANA Considerations 649 There are no IANA consideration for this document. 651 11. Security Considerations 653 The requirements listed in this document aim at providing the DNSSEC 654 validator appropriated information so DNSSEC validation can be 655 performed. On the other hand, providing inappropriate information 656 can lead to misconfiguring the DNSSEC validator, and thus disrupting 657 the DNSSEC resolution service. As a result, enabling the setting of 658 configuration parameters by a third party may open a wide surface of 659 attacks. 661 As an appropriate time value is necessary to perform signature check, 662 an attacker may provide rogue time value to prevent the DNSSEC 663 validator to check signatures. 665 An attacker may also affect the resolution service by regularly 666 asking the DNSSEC validator to flush the KSK/ZSK from its cache. All 667 associated data will also be flushed. This generates additional 668 DNSSEC resolution and additional validations, as RRSet that were 669 cached require a DNSSEC resolution over the Internet. This affects 670 the resolution service by slowing down responses, and increases the 671 load on the DNSSEC validator. 673 An attacker may ask the DNSSEC validator to consider a rogue KSK/ZSK, 674 thus hijacking the DNS zone. Similarly, an attacker may inform the 675 DNSSEC validator not to trust a given KSK in order to prevent DNSSEC 676 validation to be performed. 678 An attacker (cf. Section 7) can advertise a "known insecure" KSK or 679 ZSK is "back to secure" to prevent signature check to be performed 680 correctly. 682 As a result, information considered by the DNSSEC validator should be 683 from a trusted party. This trust party should have been 684 authenticated, and the channel used to exchange the information 685 should also be protected and authenticated. 687 12. Acknowledgment 689 The need to address DNSSEC issues on the resolver side started in the 690 Home Networks mailing list and during the IETF87 in Berlin. Among 691 others, people involved in the discussion were Ted Lemon, Ralph 692 Weber, Normen Kowalewski, and Mikael Abrahamsson. People involved in 693 the email discussion initiated by Jim Gettys were, with among others, 694 Paul Wouters, Joe Abley and Michael Richardson. 696 The current document has been initiated after a discussion with Paul 697 Wouter and Evan Hunt. 699 13. References 701 13.1. Normative References 703 [I-D.ietf-dnsop-rfc5011-security-considerations] 704 Hardaker, W. and W. Kumari, "Security Considerations for 705 RFC5011 Publishers", draft-ietf-dnsop-rfc5011-security- 706 considerations-13 (work in progress), July 2018. 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 714 Rose, "DNS Security Introduction and Requirements", 715 RFC 4033, DOI 10.17487/RFC4033, March 2005, 716 . 718 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 719 Rose, "Protocol Modifications for the DNS Security 720 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 721 . 723 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 724 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 725 September 2007, . 727 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 728 Operational Practices, Version 2", RFC 6781, 729 DOI 10.17487/RFC6781, December 2012, 730 . 732 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 733 Algorithm Understanding in DNS Security Extensions 734 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 735 . 737 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 738 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 739 DOI 10.17487/RFC7583, October 2015, 740 . 742 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 743 and R. Weber, "Definition and Use of DNSSEC Negative Trust 744 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 745 . 747 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 748 "DNSSEC Trust Anchor Publication for the Root Zone", 749 RFC 7958, DOI 10.17487/RFC7958, August 2016, 750 . 752 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 753 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 754 May 2017, . 756 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 757 Kivinen, "Cryptographic Algorithm Implementation 758 Requirements and Usage Guidance for Encapsulating Security 759 Payload (ESP) and Authentication Header (AH)", RFC 8221, 760 DOI 10.17487/RFC8221, October 2017, 761 . 763 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 764 "Algorithm Implementation Requirements and Usage Guidance 765 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 766 RFC 8247, DOI 10.17487/RFC8247, September 2017, 767 . 769 13.2. Informative References 771 [RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 772 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 773 Configuration of Softwire Address and Port-Mapped 774 Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, 775 . 777 [UNBOUND-ANCHOR] 778 "unbound-anchor - Unbound anchor utility", n.d., 779 . 782 Authors' Addresses 784 Daniel Migault 785 Ericsson 786 8275 Trans Canada Route 787 Saint Laurent, QC 4S 0B6 788 Canada 790 EMail: daniel.migault@ericsson.com 792 Edward Lewis 793 ICANN 795 EMail: edward.lewis@icann.org 797 Dan York 798 ISOC 800 EMail: york@isoc.org