idnits 2.17.1 draft-ietf-dnsop-rfc2845bis-09.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC4635, but the abstract doesn't seem to directly say this. It does mention RFC4635 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 367 has weird spacing: '...AC Data octe...' == Line 401 has weird spacing: '... Signed in ...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2020) is 1386 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-4' ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4635 (Obsoleted by RFC 8945) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Dupont 3 Internet-Draft S. Morris 4 Obsoletes: 2845, 4635 (if approved) ISC 5 Intended status: Standards Track P. Vixie 6 Expires: January 11, 2021 Farsight 7 D. Eastlake 3rd 8 Futurewei 9 O. Gudmundsson 10 Cloudflare 11 B. Wellington 12 Akamai 13 July 10, 2020 15 Secret Key Transaction Authentication for DNS (TSIG) 16 draft-ietf-dnsop-rfc2845bis-09 18 Abstract 20 This document describes a protocol for transaction level 21 authentication using shared secrets and one way hashing. It can be 22 used to authenticate dynamic updates to a DNS zone as coming from an 23 approved client, or to authenticate responses as coming from an 24 approved name server. 26 No recommendation is made here for distributing the shared secrets: 27 it is expected that a network administrator will statically configure 28 name servers and clients using some out of band mechanism. 30 This document obsoletes RFC2845 and RFC4635. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 11, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 81 1.3. Document History . . . . . . . . . . . . . . . . . . . . 4 82 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 5 84 4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5 85 4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5 86 4.2. TSIG Record Format . . . . . . . . . . . . . . . . . . . 6 87 4.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 8 88 4.3.1. Request MAC . . . . . . . . . . . . . . . . . . . . . 8 89 4.3.2. DNS Message . . . . . . . . . . . . . . . . . . . . . 9 90 4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 9 91 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 92 5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 10 93 5.2. Server Processing of Request . . . . . . . . . . . . . . 10 94 5.2.1. Key Check and Error Handling . . . . . . . . . . . . 11 95 5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11 96 5.2.3. Time Check and Error Handling . . . . . . . . . . . . 12 97 5.2.4. Truncation Check and Error Handling . . . . . . . . . 13 98 5.3. Generation of TSIG on Answers . . . . . . . . . . . . . . 13 99 5.3.1. TSIG on TCP Connections . . . . . . . . . . . . . . . 13 100 5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 14 101 5.4. Client Processing of Answer . . . . . . . . . . . . . . . 15 102 5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 15 103 5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 15 104 5.4.3. Time Error Handling . . . . . . . . . . . . . . . . . 15 105 5.4.4. Truncation Error Handling . . . . . . . . . . . . . . 16 106 5.5. Special Considerations for Forwarding Servers . . . . . . 16 107 6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 16 108 7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 17 109 8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 18 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 112 10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 20 113 10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 20 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 115 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 116 11.2. Informative References . . . . . . . . . . . . . . . . . 22 117 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24 118 Appendix B. Change History (to be removed before publication) . 24 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 121 1. Introduction 123 1.1. Background 125 The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated 126 hierarchical distributed database system that provides information 127 fundamental to Internet operations, such as name to address 128 translation and mail handling information. 130 This document specifies use of a message authentication code (MAC), 131 generated using certain keyed hash functions, to provide an efficient 132 means of point-to-point authentication and integrity checking for DNS 133 transactions. Such transactions include DNS update requests and 134 responses for which this can provide a lightweight alternative to the 135 secure DNS dynamic update protocol described by [RFC3007]. 137 A further use of this mechanism is to protect zone transfers. In 138 this case the data covered would be the whole zone transfer including 139 any glue records sent. The protocol described by DNSSEC ([RFC4033], 140 [RFC4034], [RFC4035]) does not protect glue records and unsigned 141 records. 143 The authentication mechanism proposed here provides a simple and 144 efficient authentication between clients and servers, by using shared 145 secret keys to establish a trust relationship between two entities. 146 Such keys must be protected in a manner similar to private keys, lest 147 a third party masquerade as one of the intended parties (by forging 148 the MAC). The proposal is unsuitable for general server to server 149 authentication and for servers which speak with many other servers, 150 since key management would become unwieldy with the number of shared 151 keys going up quadratically. But it is suitable for many resolvers 152 on hosts that only talk to a few recursive servers. 154 1.2. Protocol Overview 156 Secret Key Transaction Authentication makes use of signatures on 157 messages sent between the parties involved (e.g. resolver and 158 server). These are known as "transaction signatures", or TSIG. For 159 historical reasons, in this document they are referred to as message 160 authentication codes (MAC). 162 Use of TSIG presumes prior agreement between the two parties involved 163 (e.g., resolver and server) as to any algorithm and key to be used. 164 The way that this agreement is reached is outside the scope of the 165 document. 167 A DNS message exchange involves the sending of a query and the 168 receipt of one of more DNS messages in response. For the query, the 169 MAC is calculated based on the hash of the contents and the agreed 170 TSIG key. The MAC for the response is similar, but also includes the 171 MAC of the query as part of the calculation. Where a response 172 comprises multiple packets, the calculation of the MAC associated 173 with the second and subsequent packets includes in its inputs the MAC 174 for the preceding packet. In this way it is possible to detect any 175 interruption in the packet sequence, although not its premature 176 termination. 178 The MAC is contained in a TSIG resource record included in the 179 Additional Section of the DNS message. 181 1.3. Document History 183 TSIG was originally specified by [RFC2845]. In 2017, two nameserver 184 implementations strictly following that document (and the related 185 [RFC4635]) were discovered to have security problems related to this 186 feature ([CVE-2017-3142], [CVE-2017-3143], [CVE-2017-11104]). The 187 implementations were fixed but, to avoid similar problems in the 188 future, the two documents were updated and merged, producing this 189 revised specification for TSIG. 191 While TSIG implemented according to this RFC provides for enhanced 192 security, there are no changes in interoperability. TSIG is on the 193 wire still the same mechanism described in [RFC2845]; only the 194 checking semantics have been changed. See Section 10.1 for further 195 details. 197 2. Key Words 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 3. Assigned Numbers 207 This document defines the following RR type and associated value: 209 TSIG (250) 211 In addition, the document also defines the following DNS RCODEs and 212 associated names: 214 16 (BADSIG) 215 17 (BADKEY) 216 18 (BADTIME) 217 22 (BADTRUNC) 219 (See [RFC6895] Section 2.3 concerning the assignment of the value 16 220 to BADSIG.) 222 These RCODES may appear within the "Error" field of a TSIG RR. 224 4. TSIG RR Format 226 4.1. TSIG RR Type 228 To provide secret key authentication, we use an RR type whose 229 mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and 230 MUST NOT be cached. TSIG RRs are used for authentication between DNS 231 entities that have established a shared secret key. TSIG RRs are 232 dynamically computed to cover a particular DNS transaction and are 233 not DNS RRs in the usual sense. 235 As the TSIG RRs are related to one DNS request/response, there is no 236 value in storing or retransmitting them, thus the TSIG RR is 237 discarded once it has been used to authenticate a DNS message. 239 4.2. TSIG Record Format 241 The fields of the TSIG RR are described below. As is usual, all 242 multi-octet integers in the record are sent in network byte order 243 (see [RFC1035] 2.3.2). 245 NAME The name of the key used, in domain name syntax. The name 246 should reflect the names of the hosts and uniquely identify the 247 key among a set of keys these two hosts may share at any given 248 time. For example, if hosts A.site.example and B.example.net 249 share a key, possibilities for the key name include 250 .A.site.example, .B.example.net, and 251 .A.site.example.B.example.net. It should be possible for 252 more than one key to be in simultaneous use among a set of 253 interacting hosts. This allows for periodic key rotation as 254 per best operational practices, as well as algorithm agility as 255 indicated by [BCP201]. 257 The name may be used as a local index to the key involved but 258 it is recommended that it be globally unique. Where a key is 259 just shared between two hosts, its name actually need only be 260 meaningful to them but it is recommended that the key name be 261 mnemonic and incorporates the names of participating agents or 262 resources as suggested above. 264 TYPE This MUST be TSIG (250: Transaction SIGnature) 266 CLASS This MUST be ANY 268 TTL This MUST be 0 270 RdLen (variable) 272 RDATA The RDATA for a TSIG RR consists of a number of fields, 273 described below: 275 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 / Algorithm Name / 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 | Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | Fudge | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | MAC Size | / 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC / 286 / / 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Original ID | Error | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Other Len | / 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data / 292 / / 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 The contents of the RDATA fields are: 297 * Algorithm Name - a octet sequence identifying the TSIG 298 algorithm name in the domain name syntax. (Allowed names 299 are listed in Table 2.) The name is stored in the DNS name 300 wire format as described in [RFC1034]. As per [RFC3597], 301 this name MUST NOT be compressed. 303 * Time Signed - an unsigned 48-bit integer containing the time 304 the message was signed as seconds since 00:00 on 1970-01-01 305 UTC, ignoring leap seconds. 307 * Fudge - an unsigned 16-bit integer specifying the allowed 308 time difference in seconds permitted in the Time Signed 309 field. 311 * MAC Size - an unsigned 16-bit integer giving the length of 312 MAC field in octets. Truncation is indicated by a MAC size 313 less than the size of the keyed hash produced by the 314 algorithm specified by the Algorithm Name. 316 * MAC - a sequence of octets whose contents are defined by the 317 TSIG algorithm used, possibly truncated as specified by MAC 318 Size. The length of this field is given by the Mac Size. 319 Calculation of the MAC is detailed in Section 4.3. 321 * Original ID - An unsigned 16-bit integer holding the message 322 ID of the original request message. For a TSIG RR on a 323 request, it is set equal to the DNS message ID. In a TSIG 324 attached to a response - or in cases such as the forwarding 325 of a dynamic update request - the field contains the ID of 326 the original DNS request. 328 * Error - in responses, an unsigned 16-bit integer containing 329 the extended RCODE covering TSIG processing. In requests, 330 this MUST be zero. 332 * Other Len - an unsigned 16-bit integer specifying the length 333 of the "Other Data" field in octets. 335 * Other Data - additional data relevant to the TSIG record. 336 In responses, this will be empty (i.e. "Other Len" will be 337 zero) unless the content of the Error field is BADTIME, in 338 which case it will be a 48-bit unsigned integer containing 339 the server's current time as the number of seconds since 340 00:00 on 1970-01-01 UTC, ignoring leap seconds (see 341 Section 5.2.3). This document assigns no meaning to its 342 contents in requests. 344 4.3. MAC Computation 346 When generating or verifying the contents of a TSIG record, the data 347 listed in the rest of this section are passed, in the order listed 348 below, as input to MAC computation. The data are passed in network 349 byte order or wire format, as appropriate, and are fed into the 350 hashing function as a continuous octet sequence with no inter-field 351 separator or padding. 353 4.3.1. Request MAC 355 Only included in the computation of a MAC for a response message (or 356 the first message in a multi-message response), the validated request 357 MAC MUST be included in the MAC computation. If the request MAC 358 failed to validate, an unsigned error message MUST be returned 359 instead. (Section 5.3.2). 361 The request's MAC, comprising the following fields, is digested in 362 wire format: 364 Field Type Description 365 ---------- ----------------------- ---------------------- 366 MAC Length Unsigned 16-bit integer in network byte order 367 MAC Data octet sequence exactly as transmitted 369 Special considerations apply to the TSIG calculation for the second 370 and subsequent messages a response that consists of multiple DNS 371 messages (e.g. a zone transfer). These are described in 372 Section 5.3.1. 374 4.3.2. DNS Message 376 The DNS message used in the MAC computation is a whole and complete 377 DNS message in wire format. 379 When creating a TSIG, it is the message before the TSIG RR has been 380 added to the additional data section and before the DNS Message 381 Header's ARCOUNT field has been incremented to contain the TSIG RR. 383 When verifying an incoming message, it is the message after the TSIG 384 RR has been removed and the ARCOUNT field decremented. If the 385 message ID differs from the original message ID, the original message 386 ID is substituted for the message ID. (This could happen, for 387 example, when forwarding a dynamic update request.) 389 4.3.3. TSIG Variables 391 Also included in the digest is certain information present in the 392 TSIG RR. Adding this data provides further protection against an 393 attempt to interfere with the message. 395 Source Field Name Notes 396 ---------- -------------- ----------------------------------------- 397 TSIG RR NAME Key name, in canonical wire format 398 TSIG RR CLASS (Always ANY in the current specification) 399 TSIG RR TTL (Always 0 in the current specification) 400 TSIG RDATA Algorithm Name in canonical wire format 401 TSIG RDATA Time Signed in network byte order 402 TSIG RDATA Fudge in network byte order 403 TSIG RDATA Error in network byte order 404 TSIG RDATA Other Len in network byte order 405 TSIG RDATA Other Data exactly as transmitted 407 Table 1 409 The RR RDLEN and RDATA MAC Length are not included in the input to 410 MAC computation since they are not guaranteed to be knowable before 411 the MAC is generated. 413 The Original ID field is not included in this section, as it has 414 already been substituted for the message ID in the DNS header and 415 hashed. 417 For each label type, there must be a defined "Canonical wire format" 418 that specifies how to express a label in an unambiguous way. For 419 label type 00, this is defined in [RFC4034] Section 6.2. The use of 420 label types other than 00 is not defined for this specification. 422 4.3.3.1. Time Values Used in TSIG Calculations 424 The data digested includes the two timer values in the TSIG header in 425 order to defend against replay attacks. If this were not done, an 426 attacker could replay old messages but update the "Time Signed" and 427 "Fudge" fields to make the message look new. This data is named 428 "TSIG Timers", and for the purpose of MAC calculation, they are 429 hashed in their "on the wire" format, in the following order: first 430 Time Signed, then Fudge. 432 5. Protocol Details 434 5.1. Generation of TSIG on Requests 436 Once the outgoing record has been constructed, the client performs 437 the keyed hash (HMAC) computation, appends a TSIG record with the 438 calculated MAC to the Additional Data section (incrementing the 439 ARCOUNT to reflect the additional RR), and transmits the request to 440 the server. This TSIG record MUST be the only TSIG RR in the message 441 and MUST be last record in the Additional Data section. The client 442 MUST store the MAC and the key name from the request while awaiting 443 an answer. 445 The digest components for a request are: 447 DNS Message (request) 448 TSIG Variables (request) 450 5.2. Server Processing of Request 452 If an incoming message contains a TSIG record, it MUST be the last 453 record in the additional section. Multiple TSIG records are not 454 allowed. If multiple TSIG records are detected or a TSIG record is 455 present in any other position, the DNS message is dropped and a 456 response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a 457 message with exactly one correctly placed TSIG RR, a copy of the TSIG 458 RR is stored, and the TSIG RR is removed from the DNS Message, and 459 decremented out of the DNS message header's ARCOUNT. 461 If the TSIG RR cannot be interpreted, the server MUST regard the 462 message as corrupt and return a FORMERR to the server. Otherwise the 463 server is REQUIRED to return a TSIG RR in the response. 465 To validate the received TSIG RR, the server MUST perform the 466 following checks in the following order: 468 1. Check KEY 469 2. Check MAC 470 3. Check TIME values 471 4. Check Truncation policy 473 5.2.1. Key Check and Error Handling 475 If a non-forwarding server does not recognize the key or algorithm 476 used by the client (or recognizes the algorithm but does not 477 implement it), the server MUST generate an error response with RCODE 478 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be 479 unsigned as specified in Section 5.3.2. The server SHOULD log the 480 error. (Special considerations apply to forwarding servers, see 481 Section 5.5.) 483 5.2.2. MAC Check and Error Handling 485 Using the information in the TSIG, the server MUST verify the MAC by 486 doing its own calculation and comparing the result with the MAC 487 received. If the MAC fails to verify, the server MUST generate an 488 error response as specified in Section 5.3.2 with RCODE 9 (NOTAUTH) 489 and TSIG ERROR 16 (BADSIG). This response MUST be unsigned as 490 specified in Section 5.3.2. The server SHOULD log the error. 492 5.2.2.1. MAC Truncation 494 When space is at a premium and the strength of the full length of a 495 MAC is not needed, it is reasonable to truncate the keyed hash and 496 use the truncated value for authentication. HMAC SHA-1 truncated to 497 96 bits is an option available in several IETF protocols, including 498 IPsec and TLS. However, while this option is kept for backwards 499 compatibility, it may not provide a security level appropriate for 500 all cases in the modern environment. In these cases, it is 501 preferable to use a hashing algorithm such as SHA-256-128, SHA- 502 384-192 or SHA-512-256 [RFC4868]. 504 Processing of a truncated MAC follows these rules: 506 1. If "MAC size" field is greater than keyed hash output length: 508 This case MUST NOT be generated and, if received, MUST cause the 509 DNS message to be dropped and RCODE 1 (FORMERR) to be returned. 511 2. If "MAC size" field equals keyed hash output length: 513 The entire output keyed hash output is present and used. 515 3. "MAC size" field is less than the larger of 10 (octets) and half 516 the length of the hash function in use: 518 With the exception of certain TSIG error messages described in 519 Section 5.3.2, where it is permitted that the MAC size be zero, 520 this case MUST NOT be generated and, if received, MUST cause the 521 DNS message to be dropped and RCODE 1 (FORMERR) to be returned. 523 4. Otherwise: 525 This is sent when the signer has truncated the keyed hash output 526 to an allowable length, as described in [RFC2104], taking initial 527 octets and discarding trailing octets. TSIG truncation can only 528 be to an integral number of octets. On receipt of a DNS message 529 with truncation thus indicated, the locally calculated MAC is 530 similarly truncated and only the truncated values are compared 531 for authentication. The request MAC used when calculating the 532 TSIG MAC for a reply is the truncated request MAC. 534 5.2.3. Time Check and Error Handling 536 If the server time is outside the time interval specified by the 537 request (which is: Time Signed, plus/minus Fudge), the server MUST 538 generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 539 (BADTIME). The server SHOULD also cache the most recent Time Signed 540 value in a message generated by a key, and SHOULD return BADTIME if a 541 message received later has an earlier Time Signed value. A response 542 indicating a BADTIME error MUST be signed by the same key as the 543 request. It MUST include the client's current time in the Time 544 Signed field, the server's current time (an unsigned 48-bit integer) 545 in the Other Data field, and 6 in the Other Len field. This is done 546 so that the client can verify a message with a BADTIME error without 547 the verification failing due to another BADTIME error. In addition, 548 the Fudge field MUST be set to the fudge value received from the 549 client. The data signed is specified in Section 5.3.2. The server 550 SHOULD log the error. 552 Caching the most recent Time Signed value and rejecting requests with 553 an earlier one could lead to valid messages being rejected if transit 554 through the network led to UDP packets arriving in a different order 555 to the one in which they were sent. Implementations should be aware 556 of this possibility and be prepared to deal with it, e.g. by 557 retransmitting the rejected request with a new TSIG once outstanding 558 requests have completed or the time given by their Time Signed plus 559 fudge value has passed. If implementations do retry requests in 560 these cases, a limit SHOULD be placed on the maximum number of 561 retries. 563 5.2.4. Truncation Check and Error Handling 565 If a TSIG is received with truncation that is permitted under 566 Section 5.2.2.1 above but the MAC is too short for the local policy 567 in force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be 568 returned. The server SHOULD log the error. 570 5.3. Generation of TSIG on Answers 572 When a server has generated a response to a signed request, it signs 573 the response using the same algorithm and key. The server MUST NOT 574 generate a signed response to a request if either the KEY is invalid 575 (e.g. key name or algorithm name are unknown), or the MAC fails 576 validation: see Section 5.3.2 for details of responding in these 577 cases. 579 It also MUST NOT not generate a signed response to an unsigned 580 request, except in the case of a response to a client's unsigned TKEY 581 request if the secret key is established on the server side after the 582 server processed the client's request. Signing responses to unsigned 583 TKEY requests MUST be explicitly specified in the description of an 584 individual secret key establishment algorithm [RFC3645]. 586 The digest components used to generate a TSIG on a response are: 588 Request MAC 589 DNS Message (response) 590 TSIG Variables (response) 592 (This calculation is different for the second and subsequent message 593 in a multi-message answer, see below.) 595 If addition of the TSIG record will cause the message to be 596 truncated, the server MUST alter the response so that a TSIG can be 597 included. This response consists of only the question and a TSIG 598 record, and has the TC bit set and an RCODE of 0 (NOERROR). The 599 client SHOULD at this point retry the request using TCP (as per 600 [RFC1035] 4.2.2). 602 5.3.1. TSIG on TCP Connections 604 A DNS TCP session such as a zone transfer can include multiple DNS 605 messages. Using TSIG on such a connection can protect the connection 606 from attack and provide data integrity. The TSIG MUST be included on 607 all DNS messages in the response. For backward compatibility, a 608 client which receives DNS messages and verifies TSIG MUST accept up 609 to 99 intermediary messages without a TSIG and MUST verify that both 610 the first and last message contain a TSIG. 612 The first message is processed as a standard answer (see Section 5.3) 613 but subsequent messages have the following digest components: 615 Prior MAC (running) 616 DNS Messages (any unsigned messages since the last TSIG) 617 TSIG Timers (current message) 619 The "Prior MAC" is the MAC from the TSIG attached to the last message 620 containing a TSIG. "DNS Messages" comprises the concatenation (in 621 message order) of all messages after the last message that included a 622 TSIG and includes the current message. "TSIG timers" comprises the 623 "Time Signed" and "Fudge" fields (in that order) pertaining to the 624 message for which the TSIG is being created: this means that the 625 successive TSIG records in the stream will have non-decreasing "Time 626 Signed" fields. Note that only the timers are included in the second 627 and subsequent messages, not all the TSIG variables. 629 This allows the client to rapidly detect when the session has been 630 altered; at which point it can close the connection and retry. If a 631 client TSIG verification fails, the client MUST close the connection. 632 If the client does not receive TSIG records frequently enough (as 633 specified above) it SHOULD assume the connection has been hijacked 634 and it SHOULD close the connection. The client SHOULD treat this the 635 same way as they would any other interrupted transfer (although the 636 exact behavior is not specified). 638 5.3.2. Generation of TSIG on Error Returns 640 When a server detects an error relating to the key or MAC in the 641 incoming request, the server SHOULD send back an unsigned error 642 message (MAC size == 0 and empty MAC). It MUST NOT send back a 643 signed error message. 645 If an error is detected relating to the TSIG validity period or the 646 MAC is too short for the local policy, the server SHOULD send back a 647 signed error message. The digest components are: 649 Request MAC (if the request MAC validated) 650 DNS Message (response) 651 TSIG Variables (response) 653 The reason that the request MAC is not included in this MAC in some 654 cases is to make it possible for the client to verify the error. If 655 the error is not a TSIG error the response MUST be generated as 656 specified in Section 5.3. 658 5.4. Client Processing of Answer 660 When a client receives a response from a server and expects to see a 661 TSIG, it first checks if the TSIG RR is present in the response. If 662 not, the response is treated as having a format error and is 663 discarded. 665 If the TSIG RR is present, the client performs the same checks as 666 described in Section 5.2. If the TSIG RR is unsigned as specified in 667 Section 5.3.2 or does not validate, the message MUST be discarded 668 unless the RCODE is 9 (NOAUTH). In this case, the client SHOULD 669 attempt to verify the response as if it were a TSIG error, as 670 described in the following subsections. 672 Regardless of the RCODE, a message containing a TSIG RR that is 673 unsigned as specified in Section 5.3.2 or which fails verification 674 SHOULD NOT be considered an acceptable response as it may have been 675 spoofed or manipulated. Instead, the client SHOULD log an error and 676 continue to wait for a signed response until the request times out. 678 5.4.1. Key Error Handling 680 If an RCODE on a response is 9 (NOTAUTH), but the response TSIG 681 validates and the TSIG key is recognized by the client but different 682 from that used on the request, then this is a Key Error. The client 683 MAY retry the request using the key specified by the server. 684 However, this should never occur, as a server MUST NOT sign a 685 response with a different key to that used to sign the request. 687 5.4.2. MAC Error Handling 689 If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), 690 this is a MAC error, and client MAY retry the request with a new 691 request ID but it would be better to try a different shared key if 692 one is available. Clients SHOULD keep track of how many MAC errors 693 are associated with each key. Clients SHOULD log this event. 695 5.4.3. Time Error Handling 697 If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 698 (BADTIME), or the current time does not fall in the range specified 699 in the TSIG record, then this is a Time error. This is an indication 700 that the client and server clocks are not synchronized. In this case 701 the client SHOULD log the event. DNS resolvers MUST NOT adjust any 702 clocks in the client based on BADTIME errors, but the server's time 703 in the Other Data field SHOULD be logged. 705 5.4.4. Truncation Error Handling 707 If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 22 708 (BADTRUNC) then this is a Truncation error. The client MAY retry 709 with a lesser truncation up to the full HMAC output (no truncation), 710 using the truncation used in the response as a hint for what the 711 server policy allowed (Section 7). Clients SHOULD log this event. 713 5.5. Special Considerations for Forwarding Servers 715 A server acting as a forwarding server of a DNS message SHOULD check 716 for the existence of a TSIG record. If the name on the TSIG is not 717 of a secret that the server shares with the originator the server 718 MUST forward the message unchanged including the TSIG. If the name 719 of the TSIG is of a key this server shares with the originator, it 720 MUST process the TSIG. If the TSIG passes all checks, the forwarding 721 server MUST, if possible, include a TSIG of its own, to the 722 destination or the next forwarder. If no transaction security is 723 available to the destination and the message is a query then, if the 724 corresponding response has the AD flag (see [RFC4035]) set, the 725 forwarder MUST clear the AD flag before adding the TSIG to the 726 response and returning the result to the system from which it 727 received the query. 729 6. Algorithms and Identifiers 731 The only message digest algorithm specified in the first version of 732 these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], 733 [RFC2104]). Although a review of its security some years ago 734 [RFC6151] concluded that "it may not be urgent to remove HMAC-MD5 735 from the existing protocols", with the availability of more secure 736 alternatives the opportunity has been taken to make the 737 implementation of this algorithm optional. 739 [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], 740 [RFC3174]. SHA-1 collisions have been demonstrated [SHA1SHAMBLES] so 741 the MD5 security considerations described in section 2 of [RFC6151] 742 apply to SHA-1 in a similar manner. Although support for hmac-sha1 743 in TSIG is still mandatory for compatibility reasons, existing uses 744 SHOULD be replaced with hmac-sha256 or other SHA-2 digest algorithms 745 [FIPS180-4], [RFC3874], [RFC6234]. 747 Use of TSIG between two DNS agents is by mutual agreement. That 748 agreement can include the support of additional algorithms and 749 criteria as to which algorithms and truncations are acceptable, 750 subject to the restriction and guidelines in Section 5.2.2.1 above. 751 Key agreement can be by the TKEY mechanism [RFC2930] or some other 752 mutually agreeable method. 754 Implementations that support TSIG MUST also implement HMAC SHA1 and 755 HMAC SHA256 and MAY implement gss-tsig and the other algorithms 756 listed below. SHA-1 truncated to 96 bits (12 octets) SHOULD be 757 implemented. 759 Name Implementation Use 760 ------------------------ -------------- --------------- 761 HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT 762 gss-tsig MAY MAY 763 hmac-sha1 MUST NOT RECOMMENDED 764 hmac-sha224 MAY MAY 765 hmac-sha256 MUST RECOMMENDED 766 hmac-sha256-128 MAY MAY 767 hmac-sha384 MAY MAY 768 hmac-sha384-192 MAY MAY 769 hmac-sha512 MAY MAY 770 hmac-sha512-256 MAY MAY 772 Table 2 774 7. TSIG Truncation Policy 776 As noted above, two DNS agents (e.g., resolver and server) must 777 mutually agree to use TSIG. Implicit in such an "agreement" are 778 criteria as to acceptable keys and algorithms and, with the 779 extensions in this document, truncations. Local policies MAY require 780 the rejection of TSIGs, even though they use an algorithm for which 781 implementation is mandatory. 783 When a local policy permits acceptance of a TSIG with a particular 784 algorithm and a particular non-zero amount of truncation, it SHOULD 785 also permit the use of that algorithm with lesser truncation (a 786 longer MAC) up to the full keyed hash output. 788 Regardless of a lower acceptable truncated MAC length specified by 789 local policy, a reply SHOULD be sent with a MAC at least as long as 790 that in the corresponding request. Note if the request specified a 791 MAC length longer than the keyed hash output it will be rejected by 792 processing rules Section 5.2.2.1 case 1. 794 Implementations permitting multiple acceptable algorithms and/or 795 truncations SHOULD permit this list to be ordered by presumed 796 strength and SHOULD allow different truncations for the same 797 algorithm to be treated as separate entities in this list. When so 798 implemented, policies SHOULD accept a presumed stronger algorithm and 799 truncation than the minimum strength required by the policy. 801 8. Shared Secrets 803 Secret keys are very sensitive information and all available steps 804 should be taken to protect them on every host on which they are 805 stored. Generally such hosts need to be physically protected. If 806 they are multi-user machines, great care should be taken that 807 unprivileged users have no access to keying material. Resolvers 808 often run unprivileged, which means all users of a host would be able 809 to see whatever configuration data is used by the resolver. 811 A name server usually runs privileged, which means its configuration 812 data need not be visible to all users of the host. For this reason, 813 a host that implements transaction-based authentication should 814 probably be configured with a "stub resolver" and a local caching and 815 forwarding name server. This presents a special problem for 816 [RFC2136] which otherwise depends on clients to communicate only with 817 a zone's authoritative name servers. 819 Use of strong random shared secrets is essential to the security of 820 TSIG. See [RFC4086] for a discussion of this issue. The secret 821 SHOULD be at least as long as the keyed hash output [RFC2104]. 823 9. IANA Considerations 825 IANA maintains a registry of algorithm names to be used as "Algorithm 826 Names" as defined in Section 4.2. Algorithm names are text strings 827 encoded using the syntax of a domain name. There is no structure to 828 the names, and algorithm names are compared as if they were DNS 829 names, i.e., comparison is case insensitive. Previous specifications 830 [RFC2845] and [RFC4635] defined values for the HMAC-MD5 and some 831 HMAC-SHA algorithms. IANA has also registered "gss-tsig" as an 832 identifier for TSIG authentication where the cryptographic operations 833 are delegated to the Generic Security Service (GSS) [RFC3645]. This 834 document adds to allowed algorithms, and the registry should be 835 updated with the names listed in Table 2. 837 New algorithms are assigned using the IETF Review policy defined in 838 [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like a 839 fully-qualified domain name for historical reasons; other algorithm 840 names are simple, single-component names. 842 IANA maintains a registry of RCODES (error codes), including "TSIG 843 Error values" to be used for "Error" values as defined in 844 Section 4.2. New error codes are assigned and specified as in 845 [RFC6895]. 847 10. Security Considerations 849 The approach specified here is computationally much less expensive 850 than the signatures specified in DNSSEC. As long as the shared 851 secret key is not compromised, strong authentication is provided 852 between two DNS systems, e.g., for the last hop from a local name 853 server to the user resolver, or between primary and secondary 854 nameservers. 856 Recommendations for choosing and maintaining secret keys can be found 857 in [RFC2104]. If the client host has been compromised, the server 858 should suspend the use of all secrets known to that client. If 859 possible, secrets should be stored in encrypted form. Secrets should 860 never be transmitted in the clear over any network. This document 861 does not address the issue on how to distribute secrets except that 862 it mentions the possibilities of manual configuration and the use of 863 TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two 864 entities; any such additional sharing would allow any party knowing 865 the key to impersonate any other such party to members of the group. 867 This mechanism does not authenticate source data, only its 868 transmission between two parties who share some secret. The original 869 source data can come from a compromised zone master or can be 870 corrupted during transit from an authentic zone master to some 871 "caching forwarder." However, if the server is faithfully performing 872 the full DNSSEC security checks, then only security checked data will 873 be available to the client. 875 A fudge value that is too large may leave the server open to replay 876 attacks. A fudge value that is too small may cause failures if 877 machines are not time synchronized or there are unexpected network 878 delays. The RECOMMENDED value in most situations is 300 seconds. 880 To prevent cross-algorithm attacks, there SHOULD only be one 881 algorithm associated with any given key name. 883 In several cases where errors are detected, an unsigned error message 884 must be returned. This can allow for an attacker to spoof or 885 manipulate these responses. Section 5.4 recommends logging these as 886 errors and continuing to wait for a signed response until the request 887 times out. 889 Although the strength of an algorithm determines its security, there 890 have been some arguments that mild truncation can strengthen a MAC by 891 reducing the information available to an attacker. However, 892 excessive truncation clearly weakens authentication by reducing the 893 number of bits an attacker has to try to break the authentication by 894 brute force [RFC2104]. 896 Significant progress has been made recently in cryptanalysis of hash 897 functions of the types used here. While the results so far should 898 not affect HMAC, the stronger SHA-256 algorithm is being made 899 mandatory as a precaution. 901 See also the Security Considerations section of [RFC2104] from which 902 the limits on truncation in this RFC were taken. 904 10.1. Issue Fixed in this Document 906 When signing a DNS reply message using TSIG, the MAC computation uses 907 the request message's MAC as an input to cryptographically relate the 908 reply to the request. The original TSIG specification [RFC2845] 909 required that the TIME values be checked before the request's MAC. 910 If the TIME was invalid, some implementations failed to carry out 911 further checks and could use an invalid request MAC in the signed 912 reply. 914 This document makes it a mandatory that the request MAC is considered 915 to be invalid until it has been validated: until then, any answer 916 must be unsigned. For this reason, the request MAC is now checked 917 before the TIME value. 919 10.2. Why not DNSSEC? 921 These extracts from the original document [RFC2845] (updated to 922 reference current standards) analyze DNSSEC in order to justify the 923 introduction of TSIG. 925 DNS has recently been extended by DNSSEC ([RFC4033], [RFC4034] and 926 [RFC4035]) to provide for data origin authentication, and public 927 key distribution, all based on public key cryptography and public 928 key based digital signatures. To be practical, this form of 929 security generally requires extensive local caching of keys and 930 tracing of authentication through multiple keys and signatures to 931 a pre-trusted locally configured key. 933 One difficulty with the DNSSEC scheme is that common DNS 934 implementations include simple "stub" resolvers which do not have 935 caches. Such resolvers typically rely on a caching DNS server on 936 another host. It is impractical for these stub resolvers to 937 perform general DNSSEC authentication and they would naturally 938 depend on their caching DNS server to perform such services for 939 them. To do so securely requires secure communication of queries 940 and responses. DNSSEC provides public key transaction signatures 941 to support this, but such signatures are very expensive 942 computationally to generate. In general, these require the same 943 complex public key logic that is impractical for stubs. 945 and 947 A second area where use of straight DNSSEC public key based 948 mechanisms may be impractical is authenticating dynamic update 949 [RFC2136] requests. DNSSEC provides for request signatures but 950 with DNSSEC they, like transaction signatures, require 951 computationally expensive public key cryptography and complex 952 authentication logic. Secure Domain Name System Dynamic Update 953 ([RFC3007]) describes how different keys are used in dynamically 954 updated zones. 956 11. References 958 11.1. Normative References 960 [FIPS180-4] 961 National Institute of Standards and Technology, "Secure 962 Hash Standard (SHS)", FIPS PUB 180-4, August 2015. 964 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 965 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 966 . 968 [RFC1035] Mockapetris, P., "Domain names - implementation and 969 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 970 November 1987, . 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, 974 DOI 10.17487/RFC2119, March 1997, 975 . 977 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 978 Wellington, "Secret Key Transaction Authentication for DNS 979 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 980 . 982 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 983 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 984 2003, . 986 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication 987 Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", 988 RFC 4635, DOI 10.17487/RFC4635, August 2006, 989 . 991 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 992 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 993 May 2017, . 995 11.2. Informative References 997 [BCP201] Housley, R., "Guidelines for Cryptographic Algorithm 998 Agility and Selecting Mandatory-to-Implement Algorithms", 999 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1000 . 1002 [CVE-2017-11104] 1003 Common Vulnerabilities and Exposures, "CVE-2017-11104: 1004 Improper TSIG validity period check can allow TSIG 1005 forgery", June 2017, . 1008 [CVE-2017-3142] 1009 Common Vulnerabilities and Exposures, "CVE-2017-3142: An 1010 error in TSIG authentication can permit unauthorized zone 1011 transfers", June 2017, . 1014 [CVE-2017-3143] 1015 Common Vulnerabilities and Exposures, "CVE-2017-3143: An 1016 error in TSIG authentication can permit unauthorized 1017 dynamic updates", June 2017, . 1020 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1021 DOI 10.17487/RFC1321, April 1992, 1022 . 1024 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1025 Hashing for Message Authentication", RFC 2104, 1026 DOI 10.17487/RFC2104, February 1997, 1027 . 1029 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1030 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1031 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1032 . 1034 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 1035 RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, 1036 . 1038 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1039 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 1040 . 1042 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 1043 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 1044 . 1046 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., 1047 and R. Hall, "Generic Security Service Algorithm for 1048 Secret Key Transaction Authentication for DNS (GSS-TSIG)", 1049 RFC 3645, DOI 10.17487/RFC3645, October 2003, 1050 . 1052 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", 1053 RFC 3874, DOI 10.17487/RFC3874, September 2004, 1054 . 1056 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1057 Rose, "DNS Security Introduction and Requirements", 1058 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1059 . 1061 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1062 Rose, "Resource Records for the DNS Security Extensions", 1063 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1064 . 1066 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1067 Rose, "Protocol Modifications for the DNS Security 1068 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1069 . 1071 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1072 "Randomness Requirements for Security", BCP 106, RFC 4086, 1073 DOI 10.17487/RFC4086, June 2005, 1074 . 1076 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1077 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1078 DOI 10.17487/RFC4868, May 2007, 1079 . 1081 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1082 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1083 RFC 6151, DOI 10.17487/RFC6151, March 2011, 1084 . 1086 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1087 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1088 DOI 10.17487/RFC6234, May 2011, 1089 . 1091 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1092 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1093 April 2013, . 1095 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1096 Writing an IANA Considerations Section in RFCs", BCP 26, 1097 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1098 . 1100 [SHA1SHAMBLES] 1101 Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January 1102 2020, . 1104 Appendix A. Acknowledgments 1106 This document consolidates and updates the earlier documents by the 1107 authors of [RFC2845] (Paul Vixie, Olafur Gudmundsson, Donald E. 1108 Eastlake 3rd and Brian Wellington) and [RFC4635] (Donald E. Eastlake 1109 3rd). 1111 The security problem addressed by this document was reported by 1112 Clement Berthaux from Synacktiv. 1114 Note for the RFC Editor (to be removed before publication): the first 1115 'e' in Clement is a fact a small 'e' with acute, unicode code U+00E9. 1116 I do not know if xml2rfc supports non ASCII characters so I prefer to 1117 not experiment with it. BTW I am French too so I can help if you 1118 have questions like correct spelling... 1120 Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund 1121 Sivaraman and Ralph Dolmans participated in the discussions that 1122 prompted this document. Mukund Sivaraman, Martin Hoffman and Tony 1123 Finch made extremely helpful suggestions concerning the structure and 1124 wording of the updated document. 1126 Appendix B. Change History (to be removed before publication) 1128 RFC EDITOR: Please remove this appendix before publication. 1130 draft-dupont-dnsop-rfc2845bis-00 1132 [RFC4635] was merged. 1134 Authors of original documents were moved to Acknowledgments 1135 (Appendix A). 1137 Section 2 was updated to [RFC8174] style. 1139 Spit references into normative and informative references and 1140 updated them. 1142 Added a text explaining why this document was written in the 1143 Abstract and at the beginning of the introduction. 1145 Clarified the layout of TSIG RDATA. 1147 Moved the text about using DNSSEC from the Introduction to the end 1148 of Security Considerations. 1150 Added the security clarifications: 1152 1. Emphasized that MAC is invalid until it is successfully 1153 validated. 1155 2. Added requirement that a request MAC that has not been 1156 successfully validated MUST NOT be included into a response. 1158 3. Added requirement that a request that has not been validated 1159 MUST NOT generate a signed response. 1161 4. Added note about MAC too short for the local policy to 1162 Section 5.3.2. 1164 5. Changed the order of server checks and swapped corresponding 1165 sections. 1167 6. Removed the truncation size limit "also case" as it does not 1168 apply and added confusion. 1170 7. Relocated the error provision for TSIG truncation to the new 1171 Section 5.2.4. Moved from RCODE 22 to RCODE 9 and TSIG ERROR 1172 22, i.e., aligned with other TSIG error cases. 1174 8. Added Section 5.4.4 about truncation error handling by 1175 clients. 1177 9. Removed the limit to HMAC output in replies as a request 1178 which specified a MAC length longer than the HMAC output is 1179 invalid according to the first processing rule in 1180 Section 5.2.2.1. 1182 10. Promoted the requirement that a secret length should be at 1183 least as long as the HMAC output to a SHOULD [RFC2119] key 1184 word. 1186 11. Added a short text to explain the security issue. 1188 draft-dupont-dnsop-rfc2845bis-01 1190 Improved wording (post-publication comments). 1192 Specialized and renamed the "TSIG on TCP connection" 1193 (Section 5.3.1) to "TSIG on zone transfer over a TCP connection". 1194 Added a SHOULD for a TSIG in each message (was envelope) for new 1195 implementations. 1197 draft-ietf-dnsop-rfc2845bis-00 1199 Adopted by the IETF DNSOP working group: title updated and version 1200 counter reset to 00. 1202 draft-ietf-dnsop-rfc2845bis-01 1204 Relationship between protocol change and principle of assuming the 1205 request MAC is invalid until validated clarified. (Jinmei Tatuya) 1207 Cross reference to considerations for forwarding servers added. 1208 (Bob Harold) 1210 Added text from [RFC3645] concerning the signing behavior if a 1211 secret key is added during a multi-message exchange. 1213 Added reference to [RFC6895]. 1215 Many improvements in the wording. 1217 Added RFC 2845 authors as co-authors of this document. 1219 draft-ietf-dnsop-rfc2845bis-02 1221 Added a recommendation to copy time fields in BADKEY errors. 1222 (Mark Andrews) 1224 draft-ietf-dnsop-rfc2845bis-03 1226 Further changes as a result of comments by Mukund Sivaraman. 1228 Miscellaneous changes to wording. 1230 Major restructuring as a result of comprehensive review by Martin 1231 Hoffman. Amongst the more significant changes: 1233 * More comprehensive introduction. 1235 * Merged "Protocol Description" and "Protocol Details" sections. 1237 * Reordered sections so as to follow message exchange through 1238 "client "sending", "server receipt", "server sending", "client 1239 receipt". 1241 * Added miscellaneous clarifications. 1243 draft-ietf-dnsop-rfc2845bis-05 1245 Make implementation of HMAC-MD5 optional. 1247 Require that the Fudge field in BADTIME response be equal to the 1248 Fudge field received from the client. 1250 Added comment concerning the handling of BADTIME messages due to 1251 out of order packet reception. 1253 draft-ietf-dnsop-rfc2845bis-06 1255 Wording changes and minor corrections after feedback. 1257 draft-ietf-dnsop-rfc2845bis-07 1259 Updated text about use of hmac-sha1 using suggestion from Tony 1260 Finch. 1262 Corrected name of review policy used for new algorithms. 1264 draft-ietf-dnsop-rfc2845bis-08 1266 Addressed comments from IESG review. These can be found at 1267 https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ 1268 ballot. Significant changes are: 1270 * Added references to CVEs that initiated this draft. 1272 * Added reference to paper describing SHA1 collisions. 1274 * Modified some paragraphs to remove language that has not "aged 1275 well". 1277 * Mentioned that multiple keys allows for periodic key rotation. 1279 * Noted that TSIG detects interruption of packet sequence but not 1280 premature termination. 1282 * Added new algorithms to the algorithm list. 1284 * Marked hmac-sha224 as NOT RECOMMENDED. 1286 * Added recommendation that there should only be one algorithm 1287 for each key. 1289 * Added some paragraphs to the security recommendations section. 1291 Other changes: 1293 * Explicitly define contents Error field in requests. State that 1294 "Other Data" currently has no meaning in requests. 1296 * Reworked the section on client processing of response to remove 1297 ambiguity. 1299 * Section on TSIG over TCP now mentions zone transfer as an 1300 example, rather than the entire section being about zone 1301 transfers. 1303 * Note that quote from RFC2845 in "What is DNSSEC?" section has 1304 been edited to refer to the latest standards. 1306 draft-ietf-dnsop-rfc2845bis-09 1308 Change use of hmac-224 from NOT RECOMMENDED to MAY. 1310 Authors' Addresses 1312 Francis Dupont 1313 Internet Systems Consortium, Inc. 1314 PO Box 360 1315 Newmarket, NH 03857 1316 United States of America 1318 Email: Francis.Dupont@fdupont.fr 1319 Stephen Morris 1320 Internet Systems Consortium, Inc. 1321 PO Box 360 1322 Newmarket, NH 03857 1323 United States of America 1325 Email: sa.morris8@gmail.com 1327 Paul Vixie 1328 Farsight Security Inc 1329 177 Bovet Road, Suite 180 1330 San Mateo, CA 94402 1331 United States of America 1333 Email: paul@redbarn.org 1335 Donald E. Eastlake 3rd 1336 Futurewei Technologies 1337 2386 Panoramic Circle 1338 Apopka, FL 32703 1339 United States of America 1341 Email: d3e3e3@gmail.com 1343 Olafur Gudmundsson 1344 Cloudflare 1345 San Francisco, CA 94107 1346 United States of America 1348 Email: olafur+ietf@cloudflare.com 1350 Brian Wellington 1351 Akamai 1352 United States of America 1354 Email: bwelling@akamai.com