idnits 2.17.1 draft-fanf-dnsop-sha-ll-not-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 9, 2020) is 1507 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 (-09) exists of draft-ietf-dnsop-rfc2845bis-07 -- Obsolete informational reference (is this intentional?): RFC 6944 (Obsoleted by RFC 8624) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations T. Finch 3 Internet-Draft University of Cambridge 4 Updates: 8624 (if approved) March 9, 2020 5 Intended status: Standards Track 6 Expires: September 10, 2020 8 Hardening DNSSEC against collision weaknesses in SHA-1 and other 9 cryptographic hash algorithms 10 draft-fanf-dnsop-sha-ll-not-00 12 Abstract 14 DNSSEC deployments have often used the SHA-1 cryptographic hash 15 algorithm to provide authentication of DNS data. This document 16 explains why SHA-1 is no longer secure for this purpose, and 17 deprecates its use in DNSSEC signatures. This document updates RFC 18 8624. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 10, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Deprecating SHA-1 in DNSSEC . . . . . . . . . . . . . . . . . 3 57 2.1. DNSSEC signing software . . . . . . . . . . . . . . . . . 4 58 2.2. DNS hosting services . . . . . . . . . . . . . . . . . . 4 59 2.3. DNSSEC validating software . . . . . . . . . . . . . . . 4 60 2.4. DNS resolver services . . . . . . . . . . . . . . . . . . 5 61 3. Collision attacks against DNSSEC . . . . . . . . . . . . . . 5 62 3.1. Chosen-prefix collisions . . . . . . . . . . . . . . . . 5 63 3.2. Collision attacks and signatures . . . . . . . . . . . . 5 64 3.3. Breaking DNSSEC . . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Collision attacks and RRSIG records . . . . . . . . . . . 6 66 4. Hardening RRSIG records . . . . . . . . . . . . . . . . . . . 7 67 4.1. Predicting inception and expiration times . . . . . . . . 8 68 4.2. Unpredictable X.509 certificates . . . . . . . . . . . . 8 69 4.3. Less predictable RRSIG records . . . . . . . . . . . . . 9 70 5. Collision attacks and other DNS record types . . . . . . . . 9 71 5.1. TXT records . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.1.1. Syntax of TXT records . . . . . . . . . . . . . . . . 10 73 5.1.2. Mitigating TXT record attacks . . . . . . . . . . . . 10 74 5.2. CAA records . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.3. SSHFP records . . . . . . . . . . . . . . . . . . . . . . 11 76 5.4. DNSKEY records . . . . . . . . . . . . . . . . . . . . . 11 77 5.4.1. Shared keys . . . . . . . . . . . . . . . . . . . . . 11 78 5.4.2. Combined signing keys . . . . . . . . . . . . . . . . 11 79 5.5. DS records . . . . . . . . . . . . . . . . . . . . . . . 12 80 6. Other uses of SHA-1 in the DNS . . . . . . . . . . . . . . . 12 81 6.1. DS and CDS records . . . . . . . . . . . . . . . . . . . 12 82 6.2. NSEC3 records . . . . . . . . . . . . . . . . . . . . . . 13 83 6.3. SSHFP records . . . . . . . . . . . . . . . . . . . . . . 13 84 6.4. TSIG authentication . . . . . . . . . . . . . . . . . . . 13 85 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 86 7.1. Staying secure . . . . . . . . . . . . . . . . . . . . . 14 87 7.2. When to declare SHA-1 insecure . . . . . . . . . . . . . 14 88 7.3. Avoiding unwanted insecurity . . . . . . . . . . . . . . 14 89 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 9.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 94 Appendix B. Timeline . . . . . . . . . . . . . . . . . . . . . . 18 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 Since 2005, SHA-1 has been known to be much weaker than it was 100 designed to be. Over the last 5 years there has been a series of 101 increasingly powerful demonstrations that SHA-1's weaknesses can be 102 exploited in practice. In January 2020, Gaetan Leurent and Thomas 103 Peyrin announced a chosen-prefix collision for SHA-1 [SHA-mbles]. 104 This was the first practical break of SHA-1 as used in cryptographic 105 signatures. 107 DNSSEC uses cryptographic signatures to authenticate DNS data. Its 108 signature algorithms [DNSKEY-IANA] include RSASHA1 (5) and 109 RSASHA1-NSEC3-SHA1 (7) which are vulnerable to chosen-prefix 110 collisions in SHA-1, as described in Section 3. This document 111 deprecates these vulnerable algorithms (Section 2). 113 SHA-1 has been deprecated in other situations for several years (see 114 Appendix B). This document's timetable for deprecating SHA-1 in 115 DNSSEC (Section 2) is based on those examples, adapted for the 116 particulars of the DNS. Section 7 discusses the trade-offs between 117 speedy deprecation and security. 119 A collision attack can be used against DNSSEC in a number of ways, 120 some of which are explored in Section 5. Certain weaknesses in the 121 way DNSSEC is sometimes deployed can make collision attacks easier to 122 carry out, or make their consequences more severe. Although the only 123 sure way to protect against collision attacks is to use a secure 124 algorithm (Section 2), Section 4 and Section 5 outline some partial 125 mitigations. 127 The DNS uses SHA-1 for a number of other less vulnerable purposes, as 128 outlined in section Section 6. 130 1.1. Terminology 132 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 133 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 134 interpreted as described in [RFC2119]. 136 2. Deprecating SHA-1 in DNSSEC 138 The following table lists the implementation recommendations for 139 DNSKEY algorithms [DNSKEY-IANA]. The change from [RFC8624] section 140 3.1 is to deprecate algorithms 5 and 7. 142 +-----+--------------------+-----------------+---------------------+ 143 | No. | Mnemonic | DNSSEC Signing | DNSSEC Validation | 144 +-----+--------------------+-----------------+---------------------+ 145 | 1 | RSAMD5 | MUST NOT | MUST NOT | 146 | 3 | DSA | MUST NOT | MUST NOT | 147 | 5 | RSASHA1 | MUST NOT | MUST NOT after 2021 | 148 | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | 149 | 7 | RSASHA1-NSEC3-SHA1 | MUST NOT | MUST NOT after 2021 | 150 | 8 | RSASHA256 | MUST | MUST | 151 | 10 | RSASHA512 | NOT RECOMMENDED | MUST | 152 | 12 | ECC-GOST | MUST NOT | MAY | 153 | 13 | ECDSAP256SHA256 | MUST | MUST | 154 | 14 | ECDSAP384SHA384 | MAY | RECOMMENDED | 155 | 15 | ED25519 | RECOMMENDED | RECOMMENDED | 156 | 16 | ED448 | MAY | RECOMMENDED | 157 +-----+--------------------+-----------------+---------------------+ 159 The following subsections have recommended timelines for deprecating 160 algorithms 5 and 7 in specific situations. 162 2.1. DNSSEC signing software 164 DNSSEC key management and zone signing software MUST remove support 165 for algorithms 5 and 7 in their next feature release. 167 2.2. DNS hosting services 169 Authoritative DNS hosting services that include DNSSEC signing as 170 part of the service SHOULD NOT generate a new key with algorithms 5 171 or 7 for a zone that does not already have a key with the same 172 algorithm. They MUST NOT do so after the end of 2020. 174 Zones signed with algorithms 5 or 7 SHOULD be rolled over to a 175 mandatory algorithm (13 or 8) as soon as possible. The rollovers 176 MUST be complete before the end of 2021. 178 2.3. DNSSEC validating software 180 Validating resolvers SHOULD have a build-time or run-time option to 181 disable selected DNSKEY algorithms, that is, to treat them as unknown 182 or insecure. 184 Algorithms 5 and 7 MUST be disabled in 2022 at the latest. If SHA-1 185 becomes significantly weaker before then, Algorithms 5 and 7 MUST be 186 disabled in a security patch release. 188 2.4. DNS resolver services 190 Validating resolvers MUST treat algorithms 5 and 7 as unknown or 191 insecure after the start of 2022, or earlier if SHA-1 becomes 192 significantly weaker before then. 194 3. Collision attacks against DNSSEC 196 This section explains how collisions in cryptographic functions (such 197 as SHA-1) can be used to break DNSSEC data authentication. Section 5 198 has some more specific examples of how this break can be used to 199 mount attacks. 201 3.1. Chosen-prefix collisions 203 With hash functions like SHA-1, a chosen-prefix collision attack uses 204 two messages that have a structure like this: 206 +----------+-----------+--------+ 207 message-1: | prefix-1 | collide-1 | suffix | 208 +----------+-----------+--------+ 210 +----------+-----------+--------+ 211 message-2: | prefix-2 | collide-2 | suffix | 212 +----------+-----------+--------+ 214 The two prefixes are entirely under the attacker's control. 216 The collision blocks are calculated to make the hashes collide. They 217 look like binary junk and cannot be made to conform to any particular 218 syntax. The collision blocks are 588 bytes long in the best attack 219 on SHA-1 at the time of writing [SHA-mbles]. 221 The messages may need a suffix so that they are syntactically valid, 222 but this must be the same in both messages. 224 3.2. Collision attacks and signatures 226 A signature algorithm like RSASHA1 takes a cryptographic hash of the 227 message (using SHA-1 in this case) and uses an asymmetric algorithm 228 (RSA in this case) to turn the hash into a signature. 230 If the hash function is vulnerable, like SHA-1, then an attacker can: 232 o construct two prefixes, one innocuous and one malicious; 234 o calculate collision blocks so the two messages have the same hash; 235 o submit the innocuous message to be signed by some authority; 237 o copy the signature from the innocious message to the malicious 238 message; 240 o use the signed malicious message to perform attacks that would not 241 be possible without it. 243 The copied signature works on both the innocuous and malicious 244 messages because their hashes match. 246 It is usually less easy than this, because in most protocols part of 247 the innocuous message is chosen by the signer, so the attacker needs 248 to predict how the signer will work. 250 3.3. Breaking DNSSEC 252 To use a collision attack against DNSSEC, the innoccuous and 253 malicious messages are DNS RRsets. 255 DNSSEC provides strong authentication for DNS data. Within the DNS, 256 it prevents spoofing attacks and cache poisoning attacks. For 257 applications that use the DNS, DNSSEC can provide strong 258 authentication for application identifiers, such as a host name and 259 associated public key or challenge/response. Breaking DNSSEC means 260 subverting this authentication. 262 If an attacker has even very limited access to update a DNS zone that 263 uses SHA-1 (algorithm 5 or 7), the attacker can use a collision 264 attack to gain control over other names in the same zone. 266 Our attacker is able to update the DNS for certain innoccuous 267 records. The zone owner signs the updated innoccuous records and 268 publishes the new records and RRSIG in the zone. The attacker can 269 then make a DNS query for the updated records, and copy the signature 270 field from the innoccuous RRSIG into the signature field of the 271 attacker's malicious RRSIG. The attacker can use the signed 272 malicious RRset as part of a DNS spoofing or cache poisoning attack. 273 Section 5 has some examples. 275 3.4. Collision attacks and RRSIG records 277 When the attacker calculates the collision blocks, there is a bit 278 more to the innoccuous and malicious messages than just the RRsets. 279 They need to be in the format used for constructing RRSIG records 280 specified in [RFC4034] section 3.1.8.1 and sketched in the diagram 281 below: 283 +------------------------------------+ 284 | RRSIG RDATA | 285 +------------------------------------+ 286 | NAME TYPE CLASS TTL RDLENGTH RDATA | 287 +------------------------------------+ 288 | ... more records ... | 289 +------------------------------------+ 290 | NAME TYPE CLASS TTL RDLENGTH ( | 291 | collision blocks ) | 292 +------------------------------------+ 294 The RRSIG RDATA is controlled by the signer, and must be predicted by 295 the attacker. Section 4 discusses how easy it is to predict the 296 RRSIG RDATA fields. 298 The DNS records are under the attacker's control, with some 299 limitations: 301 o In the innoccuous records, the NAME and TYPE identify an RRset 302 that the attacker can update. 304 o In the malicious records, the NAME must be in a zone signed by the 305 same key as the innoccuous records. 307 o The innoccuous and malicious TYPEs do not need to be the same, but 308 they must both have RDATA fields that can accommodate the 309 collision blocks. 311 o The attacker needs to ensure the records containg the collision 312 blocks come last when the RRsets are sorted into canonical order. 314 o The innoccuous and malicious records do not have to be aligned 315 with each other, but they need to have the same total length. 317 4. Hardening RRSIG records 319 To perform a collision attack against DNSSEC, the attacker needs to 320 know the RRSIG RDATA fields that the zone owner will use when signing 321 the attacker's innoccuous records. 323 The RRSIG RDATA fields are specified in [RFC4034] section 3.1. They 324 are: 326 o Type covered: same as the TYPE of the innoccuous RRset. 328 o Algorithm: same as the algorithm of the zone's DNSKEY records, 329 which for a vulnerable zone will be 5 or 7. 331 o Labels: derived from the NAME of the innoccuous RRset. 333 o Original TTL: same as the TTL of the innoccuous RRset. 335 o Signature expiration: a time set by the signer. 337 o Signature inception: a time set by the signer. 339 o Key tag: obtained from one of the zone's DNSKEY records. 341 o Signer's name: the name of the zone's DNSKEY records. 343 We can see that all of these fields are known to the attacker, apart 344 from the inception and expiration times. 346 4.1. Predicting inception and expiration times 348 There are a number of common ways for DNSSEC signers to set signature 349 inception and expiration times: 351 o The times are known offsets from the moment a DNS update is 352 processed. 354 o The update time is rounded to a multiple of (for example) 24 hours 355 and the signature times are known offsets from that. 357 o The zone is signed on a known schedule and the times are derived 358 from that schedule. 360 So in many cases an attacker can predict all the RRSIG RDATA fields 361 with little difficulty. 363 4.2. Unpredictable X.509 certificates 365 (A brief diversion to provide some rationale for the next sub- 366 section.) 368 In 2008 a chosen-prefix collision attack against MD5 was used to 369 obtain an illegitimate CA certificate signed by a commercial CA 370 [ROGUE-CA]. A key part of this attack was to predict the serial 371 number and validity period assigned by the commercial CA to the 372 innocuous certificate so that its MD5 hash would collide with the 373 malicious rogue CA certificate. 375 Following this attack, certificate authorities started using random 376 serial numbers instead of sequential numbers. In 2016 the CA/Browser 377 forum baseline requirements were amended to increase the amount of 378 randomness required from 20 bits to 64 bits [CABforum2016]. This 379 extra hardening was in addition to deprecating SHA-1 [CABforum2014]. 381 4.3. Less predictable RRSIG records 383 In addition to upgrading to a secure algorithm (Section 2), DNSSEC 384 signers can provide extra protection against possible collision 385 attacks by adding entropy to make RRSIG inception and expiration 386 times less predictable. 388 The inception time SHOULD include at least 12 bits of output from a 389 CSPRNG. (2^12 seconds is slightly more than an hour.) For example, 390 set the inception time to the signing time minus an hour minus the 391 entropy. 393 The expiration time SHOULD include output from a CSPRNG equivalent to 394 about 25% of the nominal validity period. For instance, 19 bits (6 395 days) if the validity period is 1 month, or 17 bits (1.5 days) if the 396 validity period is 1 week. For example, set the expiration time to 397 the signing time plus 75% of the validity period plus the entropy. 399 A signer SHOULD change its signature validity times frequently, for 400 example, different times for each RRset, or different times each 401 second. This is so that an attacker cannot observe the signer's 402 current validity period and perform a collision attack before the 403 period changes. 405 5. Collision attacks and other DNS record types 407 This section discusses how a SHA-1 collision attack can be used with 408 various DNS record types. For an RRtype to be suitable it needs to 409 have a large RDATA with basically no internal structure, to 410 accommodate the collision blocks, which are 588 bytes long in the 411 best attack on SHA-1 at the time of writing [SHA-mbles]. 413 There are a number of weaknesses that make a collision attack easier 414 to carry out, or which make the consequences of an attack more 415 severe. This section describes some mitigations for these 416 weaknesses, but note that these mitigations do not prevent collision 417 attacks. The main defence is to upgrade zones to a secure algorithm 418 (Section 2) and in many cases that will be easier than the additional 419 mitigations outlined below. 421 5.1. TXT records 423 TXT records are an attractive vehicle for a collision attack. 425 Access to update TXT records might be granted to support things like 426 ACME dns-01 challenges [RFC8555], so they can be useful as an 427 attacker's innoccuous records. 429 As the target of an attacker's malicious records, TXT records have 430 several interesting functions that might be useful to an attacker, 431 including ACME [RFC8555], DKIM [RFC6376], SPF [RFC7208], 432 authorization to provision cloud services, etc. 434 5.1.1. Syntax of TXT records 436 A TXT record's RDATA contains a sequence of strings, each of which is 437 a length octet followed by up to 255 octets of data. A single string 438 is too small to accommodate SHA-1 collision blocks. 440 An attacker can cope with this difficulty by not worrying about how 441 the string lengths end up inside a collision block. At the end of 442 the block there will be some unpredictable length of string that 443 needs to be filled; the attacker can append 255 zero bytes, which 444 will fill the remainder of the unknown string. The excess zero bytes 445 will parse as a sequence of zero-length strings. Although the 446 unfilled string lengths may be different in the inoccuous and 447 malicious records, they are both fixed by an identical suffix of 255 448 zeroes. 450 5.1.2. Mitigating TXT record attacks 452 Some attacks might be prevented by imposing stricter requirements on 453 TXT records, since most practical uses do not put un-encoded binary 454 data in TXT records. 456 An authoritative server MAY reject TXT records in DNS UPDATEs and 457 zone files if the strings contain ASCII control characters or invalid 458 UTF-8. This strict checking SHOULD be configurable so that zone 459 owners can use unrestricted binary in TXT records if they wish. 461 5.2. CAA records 463 An attacker might want to spoof certificate authority authorization 464 records [RFC8659] in order to obtain an illegitimate X.509 465 certificate. 467 A CAA record contains tag and value strings. The length of the value 468 is unrestricted, which makes it easy to accommodate collision blocks. 470 To mitigate collision attacks on CAA records, the specifications for 471 CAA record syntax and how CAA records are processed by certificate 472 authorities could be tightened up to reject a CAA RRset unless it is 473 all printable ASCII. 475 5.3. SSHFP records 477 An SSHFP record contains a fingerprint of a server public key 478 [RFC4255]. They are attractive as the target of a spoofing attack. 480 Access to update SSHFP records might be granted so that servers can 481 register themselves in the DNS, so SSHFP records can be useful as an 482 attacker's innoccuous records. 484 The length of an SSHFP record is implied by its fingerprint type 485 field, but they can be used in collision attacks if the length is not 486 strictly checked, or if unknown fingerprint types are allowed. 488 Authoritative DNS servers MAY reject SSHFP records with unknown 489 fingerprint types or mismatched lengths in DNS UPDATEs and zone 490 files. SSH clients MAY reject an entire SSHFP RRset if any record 491 has a fingerprint longer than 64 bytes. (Assuming that fingerprints 492 longer than 512 bits do not make sense.) 494 5.4. DNSKEY records 496 There are a couple of DNSSEC key management models that can make the 497 consequences of a collision attack worse. 499 5.4.1. Shared keys 501 Normally each zone has its own DNSSEC keys, so a collision attack 502 only works when the attacker's inoccuous and malicious records are in 503 the same zone. 505 Some DNSSEC deployments share the same keys across multiple zones. 506 This allows an attacker to target names in any zone that uses the 507 same key. For example, if this is a multi-tenant hosting 508 environment, the attacker could sign up with their own domain and use 509 that to perform collision attacks against other customers on the same 510 platform. 512 DNS hosting services and DNSSEC signing software SHOULD NOT allow 513 keys to be shared between multiple zones. 515 5.4.2. Combined signing keys 517 The traditional DNSSEC setup has two keys for a zone: a key-signing 518 key (KSK) that is only used to sign the zone's DNSKEY RRset; and a 519 zone-signing key (ZSK) which signs the other records in the zone. 521 There is a simpler setup in which a zone has only one key: a combined 522 signing key (CSK) which signs all the records in the zone. 524 The DNSKEY RRset is a huge target in a zone that is vulnerable to 525 collision attacks: if the attacker can get their own public key into 526 a signed DNSKEY RRset then one successful collision attack can be 527 used to spoof any record in the zone. 529 In a zone with split ZSK/KSK, the DNSKEY RRset is only trusted if it 530 is signed by the KSK, but collision attacks can only obtain a RRset 531 signed by the ZSK. 533 In a zone with a CSK the attacker can obtain a malicious trusted 534 DNSKEY RRset using a collision attack. 536 DNS hosting services and DNSSEC signing software SHOULD encourage 537 split ZSK/KSK configurations. 539 5.5. DS records 541 Top-level domains are the most prominent example of zones that can be 542 updated by many different clients from mutually antagonistic 543 organizations. 545 TLDs are typically updated via EPP [RFC5730]. The only delegation 546 RRtype it might be possible to use for collision attacks are DS 547 records. (The other delegation records, NS and glue addresses, are 548 not signed and their syntax is too constrained.) 550 Collision attacks using DS records SHOULD be prevented as follows: 552 o Unknown DS digest types are rejected; 554 o DS records are required to have the correct length for their 555 digest type; 557 o Alternatively, instead of using client-generated DS records, the 558 registry accepts DNSKEY records and generates the DS records. 560 6. Other uses of SHA-1 in the DNS 562 6.1. DS and CDS records 564 A DS or CDS record securely identifies a DNSKEY record using a 565 cryptographic digest ([RFC4034] section 5). One of the digest types 566 is SHA-1. It is deprecated by [RFC8624]. 568 For this purpose, the digest needs preimage security, which SHA-1 569 still has, and collision attacks do not affect it. 571 6.2. NSEC3 records 573 NSEC3 is an alternative mechanism for authenticated denial of 574 existence in DNSSEC. It is based on SHA-1 hashes of domain names. 575 The NSEC3 specification [RFC5155] discusses collisions in some 576 detail. 578 NSEC3 can be attacked with an identical-prefix collision, which is 579 simpler than the chosen-prefix collisions that are the main subject 580 of this document. The best collision known at the time of writing 581 [SHAttered] uses two SHA-1 input blocks (128 bytes) so a collision 582 could in principle be made to fit into a domain name for an attack on 583 NSEC3. However it will be difficult to make the colliding domain 584 names conform to host name syntax, and the attack will be futile 585 because the signer can defeat it by changing its NSEC3 salt 586 ([RFC5155] section C.2.1). 588 6.3. SSHFP records 590 An SSHFP record securely identifies an SSH server public key using a 591 cryptographic digest [RFC4255]. Although SSHFP SHA-1 digests have 592 not yet been deprecated, SHA-256 is preferred [RFC6594]. 594 For SSHFP records the digest needs preimage security, which SHA-1 595 still has, and collision attacks do not affect it. 597 6.4. TSIG authentication 599 TSIG is a DNS extension for secret-key transaction authentication 600 [I-D.ietf-dnsop-rfc2845bis]. Its "hmac-sha1" algorithm is 601 deprecated. Collision attacks do not affect HMAC SHA-1. 603 7. Security considerations 605 We find ourselves in an awkward and embarrassing situation. As 606 Appendix B shows, there has been plenty of warning about the weakness 607 of SHA-1. Other parts of the industry started making efforts to 608 deprecate it years ago. But DNSSEC has been complacent. 610 At the time of writing, there are 1516 top-level domains, of which 611 1102 use secure DNSSEC algorithms, 274 use algorithms 5 or 7 (RSA 612 SHA-1), and 140 are insecure. In the reverse DNS, 3 RIRs use secure 613 DNSSEC algorithms, 2 RIRs use algorithm 5, and many of the non-RIR 614 legacy delegations are insecure. 616 7.1. Staying secure 618 There are still many domains that depend on SHA-1 to secure 619 applications that use DNSSEC, such as issuing TLS certificates 620 [RFC8659] [RFC8555], sending inter-domain email [RFC7672], and 621 authenticating SSH servers [RFC4255]. 623 Some applications use the "authenticated data" (AD bit) signal from 624 DNSSEC to make security decisions, and will fail if it unexpectedly 625 switches off. Other applications use DNSSEC passively and will 626 silently go insecure. In either case we would prefer them to 627 continue working as if secure, as long as SHA-1 is still 628 significantly better than insecure DNS. 630 7.2. When to declare SHA-1 insecure 632 At the time of writing, a SHA-1 chosen-prefix collision costs less 633 than US$100,000 in computer time, takes about a month, and requires 634 the attention of expert cryptanalysts. Attacks seem to be getting 635 better by a factor of 3 or 4 per year. 637 There is not much time before collisions become affordable, and 638 possible for non-experts to calculate. Section 2 hopes this will not 639 happen within the next 2 years. 641 This 2 year guess is likely to be too optimistic, so DNSSEC 642 validators need to be prepared to disable support for SHA-1 by 643 configuration change or security patch as soon as a significantly 644 improved attack on SHA-1 is announced. 646 7.3. Avoiding unwanted insecurity 648 The reason for not deprecating SHA-1 immediately is to allow time to 649 perform algorithm rollovers, so that zones will continue to be 650 secure. 652 Abruptly forcing SHA-1 zones to be treated as insecure may encourage 653 their operators to leave them insecure, instead of encouraging them 654 to upgrade to a secure algorithm. 656 8. IANA considerations 658 This document has no IANA actions. 660 9. References 662 9.1. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, 666 DOI 10.17487/RFC2119, March 1997, 667 . 669 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 670 Rose, "Resource Records for the DNS Security Extensions", 671 RFC 4034, DOI 10.17487/RFC4034, March 2005, 672 . 674 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 675 Requirements and Usage Guidance for DNSSEC", RFC 8624, 676 DOI 10.17487/RFC8624, June 2019, 677 . 679 9.2. Informative References 681 [CABforum2014] 682 CA/Browser Forum, "Ballot 118 - SHA-1 Sunset", October 683 2014, . 686 [CABforum2016] 687 CA/Browser Forum, "Ballot 164 - Certificate Serial Number 688 Entropy", September 2016, 689 . 691 [Cochran2007] 692 Cochran, M., "Notes on the Wang et al. 2^63 SHA-1 693 Differential Path", 2007, 694 . 696 [DNSKEY-IANA] 697 IANA, "Domain Name System Security (DNSSEC) Algorithm 698 Numbers", 2017, 699 . 701 [I-D.ietf-dnsop-rfc2845bis] 702 Dupont, F., Morris, S., Vixie, P., Eastlake, D., 703 Gudmundsson, O., and B. Wellington, "Secret Key 704 Transaction Authentication for DNS (TSIG)", draft-ietf- 705 dnsop-rfc2845bis-07 (work in progress), February 2020. 707 [NIST-SP800-131A] 708 National Institute of Standards and Technology, 709 "Recommendation for Transitioning the Use of 710 CryptographicAlgorithms and Key Lengths", January 2011, 711 . 714 [NIST2006] 715 National Institute of Standards and Technology, "NIST 716 Comments on Cryptanalytic Attacks on SHA-1", 2006, 717 . 720 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 721 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 722 DOI 10.17487/RFC4255, January 2006, 723 . 725 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 726 Security (DNSSEC) Hashed Authenticated Denial of 727 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 728 . 730 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 731 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 732 . 734 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 735 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 736 RFC 6376, DOI 10.17487/RFC6376, September 2011, 737 . 739 [RFC6594] Sury, O., "Use of the SHA-256 Algorithm with RSA, Digital 740 Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) 741 in SSHFP Resource Records", RFC 6594, 742 DOI 10.17487/RFC6594, April 2012, 743 . 745 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) 746 DNSKEY Algorithm Implementation Status", RFC 6944, 747 DOI 10.17487/RFC6944, April 2013, 748 . 750 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 751 Authorizing Use of Domains in Email, Version 1", RFC 7208, 752 DOI 10.17487/RFC7208, April 2014, 753 . 755 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 756 Opportunistic DNS-Based Authentication of Named Entities 757 (DANE) Transport Layer Security (TLS)", RFC 7672, 758 DOI 10.17487/RFC7672, October 2015, 759 . 761 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 762 Kasten, "Automatic Certificate Management Environment 763 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 764 . 766 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, 767 "DNS Certification Authority Authorization (CAA) Resource 768 Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, 769 . 771 [ROGUE-CA] 772 Sotirov, A., Stevens, M., Appelbaum, J., Lenstra, A., 773 Molnar, D., Osvik, D., and B. de Weger, "Creating a rogue 774 CA certificate", December 2008, 775 . 777 [ROOT-DNSSEC] 778 Internet Corporation For Assigned Names and Numbers and 779 VeriSign, Inc., "Information about DNSSEC for the Root 780 Zone", 2010, . 782 [SHA-mbles] 783 Leurent, G. and T. Peyrin, "SHA-1 is a Shambles: First 784 Chosen-Prefix Collision on SHA-1 and Application to the 785 PGP Web of Trust", January 2020, 786 . 788 [SHAppening] 789 Stevens, M., Karpman, P., and T. Peyrin, "Freestart 790 collision for full SHA-1", October 2015, 791 . 793 [SHAttered] 794 Stevens, M., Bursztein, E., Karpman, P., Albertini, A., 795 and Y. Markov, "The first collision for full SHA-1", 796 February 2017, . 798 [Wang2005] 799 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 800 Full SHA-1", 2005, 801 . 803 Appendix A. Acknowledgments 805 Thanks to Viktor Dukhovni for helpful discussions about the 806 implications of the SHA-1 chosen-prefix collision. 808 Appendix B. Timeline 810 o 2005: Theoretical 2^63 attack on SHA-1 [Wang2005] [Cochran2007] 812 o 2006: NIST starts to deprecate SHA-1 [NIST2006] 814 o 2010: DNS root zone signed with RSASHA256 [ROOT-DNSSEC] 816 o 2011: NIST formally deprecates SHA-1 for digital signatures, and 817 disallows it after 2013 [NIST-SP800-131A] (section 3) 819 o 2013: IETF recommends RSASHA1 for use in DNSSEC [RFC6944] 821 o 2014: CA/Browser forum sunsets SHA-1 in X.509 WebPKI certificates 822 after 2015 [CABforum2014] 824 o 2015: Free-start collision demonstrated in SHA-1 [SHAppening] 826 o 2017: Identical-prefix collision demonstrated in SHA-1 [SHAttered] 828 o 2019: IETF partially deprecates SHA-1 for use in DNSSEC [RFC8624] 830 o 2020: Chosen-prefix collision demonstrated in SHA-1 [SHA-mbles] 832 Author's Address 834 Tony Finch 835 University of Cambridge 836 University Information Services 837 Roger Needham Building 838 7 JJ Thomson Avenue 839 Cambridge CB3 0RB 840 England 842 Email: dot@dotat.at