1 Internet Engineering Task Force (IETF) F. Dupont
2 Request for Comments: 8945 ISC
3 STD: 93 S. Morris
4 Obsoletes: 2845, 4635 Unaffiliated
5 Category: Standards Track P. Vixie
6 ISSN: 2070-1721 Farsight
7 D. Eastlake 3rd
8 Futurewei
9 O. Gudmundsson
10 Cloudflare
11 B. Wellington
12 Akamai
13 November 2020
14
15
16 Secret Key Transaction Authentication for DNS (TSIG)
17
18 Abstract
19
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.
25
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.
29
30 This document obsoletes RFCs 2845 and 4635.
31
32 Status of This Memo
33
34 This is an Internet Standards Track document.
35
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Further information on
40 Internet Standards is available in Section 2 of RFC 7841.
41
42 Information about the current status of this document, any errata,
43 and how to provide feedback on it may be obtained at
44 https://www.rfc-editor.org/info/rfc8945.
45
46 Copyright Notice
47
48 Copyright (c) 2020 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
50
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (https://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
60
61 This document may contain material from IETF Documents or IETF
62 Contributions published or made publicly available before November
63 10, 2008. The person(s) controlling the copyright in some of this
64 material may not have granted the IETF Trust the right to allow
65 modifications of such material outside the IETF Standards Process.
66 Without obtaining an adequate license from the person(s) controlling
67 the copyright in such materials, this document may not be modified
68 outside the IETF Standards Process, and derivative works of it may
69 not be created outside the IETF Standards Process, except to format
70 it for publication as an RFC or to translate it into languages other
71 than English.
72
73 Table of Contents
74
75 1. Introduction
76 1.1. Background
77 1.2. Protocol Overview
78 1.3. Document History
79 2. Key Words
80 3. Assigned Numbers
81 4. TSIG RR Format
82 4.1. TSIG RR Type
83 4.2. TSIG Record Format
84 4.3. MAC Computation
85 4.3.1. Request MAC
86 4.3.2. DNS Message
87 4.3.3. TSIG Variables
88 5. Protocol Details
89 5.1. Generation of TSIG on Requests
90 5.2. Server Processing of Request
91 5.2.1. Key Check and Error Handling
92 5.2.2. MAC Check and Error Handling
93 5.2.3. Time Check and Error Handling
94 5.2.4. Truncation Check and Error Handling
95 5.3. Generation of TSIG on Answers
96 5.3.1. TSIG on TCP Connections
97 5.3.2. Generation of TSIG on Error Returns
98 5.4. Client Processing of Answer
99 5.4.1. Key Error Handling
100 5.4.2. MAC Error Handling
101 5.4.3. Time Error Handling
102 5.4.4. Truncation Error Handling
103 5.5. Special Considerations for Forwarding Servers
104 6. Algorithms and Identifiers
105 7. TSIG Truncation Policy
106 8. Shared Secrets
107 9. IANA Considerations
108 10. Security Considerations
109 10.1. Issue Fixed in This Document
110 10.2. Why Not DNSSEC?
111 11. References
112 11.1. Normative References
113 11.2. Informative References
114 Acknowledgements
115 Authors' Addresses
116
117 1. Introduction
118
119 1.1. Background
120
121 The Domain Name System (DNS) ([RFC1034] [RFC1035]) is a replicated
122 hierarchical distributed database system that provides information
123 fundamental to Internet operations, such as name-to-address
124 translation and mail-handling information.
125
126 This document specifies use of a message authentication code (MAC),
127 generated using certain keyed hash functions, to provide an efficient
128 means of point-to-point authentication and integrity checking for DNS
129 transactions. Such transactions include DNS update requests and
130 responses for which this can provide a lightweight alternative to the
131 secure DNS dynamic update protocol described by [RFC3007].
132
133 A further use of this mechanism is to protect zone transfers. In
134 this case, the data covered would be the whole zone transfer
135 including any glue records sent. The protocol described by DNSSEC
136 ([RFC4033], [RFC4034], [RFC4035]) does not protect glue records and
137 unsigned records.
138
139 The authentication mechanism proposed here provides a simple and
140 efficient authentication between clients and servers, by using shared
141 secret keys to establish a trust relationship between two entities.
142 Such keys must be protected in a manner similar to private keys, lest
143 a third party masquerade as one of the intended parties (by forging
144 the MAC). The proposal is unsuitable for general server-to-server
145 authentication and for servers that speak with many other servers,
146 since key management would become unwieldy with the number of shared
147 keys going up quadratically. But it is suitable for many resolvers
148 on hosts that only talk to a few recursive servers.
149
150 1.2. Protocol Overview
151
152 Secret Key Transaction Authentication makes use of signatures on
153 messages sent between the parties involved (e.g., resolver and
154 server). These are known as "transaction signatures", or TSIG. For
155 historical reasons, in this document, they are referred to as message
156 authentication codes (MACs).
157
158 Use of TSIG presumes prior agreement between the two parties involved
159 (e.g., resolver and server) as to any algorithm and key to be used.
160 The way that this agreement is reached is outside the scope of the
161 document.
162
163 A DNS message exchange involves the sending of a query and the
164 receipt of one of more DNS messages in response. For the query, the
165 MAC is calculated based on the hash of the contents and the agreed
166 TSIG key. The MAC for the response is similar but also includes the
167 MAC of the query as part of the calculation. Where a response
168 comprises multiple packets, the calculation of the MAC associated
169 with the second and subsequent packets includes in its inputs the MAC
170 for the preceding packet. In this way, it is possible to detect any
171 interruption in the packet sequence, although not its premature
172 termination.
173
174 The MAC is contained in a TSIG resource record included in the
175 additional section of the DNS message.
176
177 1.3. Document History
178
179 TSIG was originally specified by [RFC2845]. In 2017, two name server
180 implementations strictly following that document (and the related
181 [RFC4635]) were discovered to have security problems related to this
182 feature ([CVE-2017-3142], [CVE-2017-3143], [CVE-2017-11104]). The
183 implementations were fixed, but to avoid similar problems in the
184 future, the two documents were updated and merged, producing this
185 revised specification for TSIG.
186
187 While TSIG implemented according to this RFC provides for enhanced
188 security, there are no changes in interoperability. TSIG on the wire
189 is still the same mechanism described in [RFC2845]; only the checking
190 semantics have been changed. See Section 10.1 for further details.
191
192 2. Key Words
193
194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
196 "OPTIONAL" in this document are to be interpreted as described in
197 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
198 capitals, as shown here.
199
200 3. Assigned Numbers
201
202 This document defines the following Resource Record (RR) type and
203 associated value:
204
205 TSIG (250)
206
207 In addition, the document also defines the following DNS RCODEs and
208 associated names:
209
210 16 (BADSIG)
211 17 (BADKEY)
212 18 (BADTIME)
213 22 (BADTRUNC)
214
215 (See Section 2.3 of [RFC6895] concerning the assignment of the value
216 16 to BADSIG.)
217
218 These RCODES may appear within the "Error" field of a TSIG RR.
219
220 4. TSIG RR Format
221
222 4.1. TSIG RR Type
223
224 To provide secret key authentication, we use an RR type whose
225 mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and
226 MUST NOT be cached. TSIG RRs are used for authentication between DNS
227 entities that have established a shared secret key. TSIG RRs are
228 dynamically computed to cover a particular DNS transaction and are
229 not DNS RRs in the usual sense.
230
231 As the TSIG RRs are related to one DNS request/response, there is no
232 value in storing or retransmitting them; thus, the TSIG RR is
233 discarded once it has been used to authenticate a DNS message.
234
235 4.2. TSIG Record Format
236
237 The fields of the TSIG RR are described below. All multi-octet
238 integers in the record are sent in network byte order (see
239 Section 2.3.2 of [RFC1035]).
240
241 NAME: The name of the key used, in domain name syntax. The name
242 should reflect the names of the hosts and uniquely identify the
243 key among a set of keys these two hosts may share at any given
244 time. For example, if hosts A.site.example and B.example.net
245 share a key, possibilities for the key name include
246 <id>.A.site.example, <id>.B.example.net, and
247 <id>.A.site.example.B.example.net. It should be possible for more
248 than one key to be in simultaneous use among a set of interacting
249 hosts. This allows for periodic key rotation as per best
250 operational practices, as well as algorithm agility as indicated
251 by [RFC7696].
252
253 The name may be used as a local index to the key involved, but it
254 is recommended that it be globally unique. Where a key is just
255 shared between two hosts, its name actually need only be
256 meaningful to them, but it is recommended that the key name be
257 mnemonic and incorporate the names of participating agents or
258 resources as suggested above.
259
260 TYPE: This MUST be TSIG (250: Transaction SIGnature).
261
262 CLASS: This MUST be ANY.
263
264 TTL: This MUST be 0.
265
266 RDLENGTH: (variable)
267
268 RDATA: The RDATA for a TSIG RR consists of a number of fields,
269 described below:
270
271 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
272 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
273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
274 / Algorithm Name /
275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
276 | |
277 | Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
278 | | Fudge |
279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
280 | MAC Size | /
281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC /
282 / /
283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
284 | Original ID | Error |
285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
286 | Other Len | /
287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data /
288 / /
289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
290
291 The contents of the RDATA fields are:
292
293 Algorithm Name:
294 an octet sequence identifying the TSIG algorithm in the domain
295 name syntax. (Allowed names are listed in Table 3.) The name is
296 stored in the DNS name wire format as described in [RFC1034]. As
297 per [RFC3597], this name MUST NOT be compressed.
298
299 Time Signed:
300 an unsigned 48-bit integer containing the time the message was
301 signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap
302 seconds.
303
304 Fudge:
305 an unsigned 16-bit integer specifying the allowed time difference
306 in seconds permitted in the Time Signed field.
307
308 MAC Size:
309 an unsigned 16-bit integer giving the length of the MAC field in
310 octets. Truncation is indicated by a MAC Size less than the size
311 of the keyed hash produced by the algorithm specified by the
312 Algorithm Name.
313
314 MAC:
315 a sequence of octets whose contents are defined by the TSIG
316 algorithm used, possibly truncated as specified by the MAC Size.
317 The length of this field is given by the MAC Size. Calculation of
318 the MAC is detailed in Section 4.3.
319
320 Original ID:
321 an unsigned 16-bit integer holding the message ID of the original
322 request message. For a TSIG RR on a request, it is set equal to
323 the DNS message ID. In a TSIG attached to a response -- or in
324 cases such as the forwarding of a dynamic update request -- the
325 field contains the ID of the original DNS request.
326
327 Error:
328 in responses, an unsigned 16-bit integer containing the extended
329 RCODE covering TSIG processing. In requests, this MUST be zero.
330
331 Other Len:
332 an unsigned 16-bit integer specifying the length of the Other Data
333 field in octets.
334
335 Other Data:
336 additional data relevant to the TSIG record. In responses, this
337 will be empty (i.e., Other Len will be zero) unless the content of
338 the Error field is BADTIME, in which case it will be a 48-bit
339 unsigned integer containing the server's current time as the
340 number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap
341 seconds (see Section 5.2.3). This document assigns no meaning to
342 its contents in requests.
343
344 4.3. MAC Computation
345
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 interfield
351 separator or padding.
352
353 4.3.1. Request MAC
354
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).
360
361 The request's MAC, comprising the following fields, is digested in
362 wire format:
363
364 +==========+=========================+========================+
365 | Field | Type | Description |
366 +==========+=========================+========================+
367 | MAC Size | Unsigned 16-bit integer | in network byte order |
368 +----------+-------------------------+------------------------+
369 | MAC Data | octet sequence | exactly as transmitted |
370 +----------+-------------------------+------------------------+
371
372 Table 1: Request's MAC
373
374 Special considerations apply to the TSIG calculation for the second
375 and subsequent messages in a response that consists of multiple DNS
376 messages (e.g., a zone transfer). These are described in
377 Section 5.3.1.
378
379 4.3.2. DNS Message
380
381 In the MAC computation, the whole/complete DNS message in wire format
382 is used.
383
384 When creating an outgoing message, the TSIG is based on the message
385 content before the TSIG RR has been added to the additional section
386 and before the DNS Message Header's ARCOUNT has been incremented to
387 include the TSIG RR.
388
389 When verifying an incoming message, the TSIG is checked against the
390 message after the TSIG RR has been removed, the ARCOUNT decremented,
391 and the message ID replaced by the original message ID from the TSIG
392 if those IDs differ. (This could happen, for example, when
393 forwarding a dynamic update request.)
394
395 4.3.3. TSIG Variables
396
397 Also included in the digest is certain information present in the
398 TSIG RR. Adding this data provides further protection against an
399 attempt to interfere with the message.
400
401 +============+================+====================================+
402 | Source | Field Name | Notes |
403 +============+================+====================================+
404 | TSIG RR | NAME | Key name, in canonical wire format |
405 +------------+----------------+------------------------------------+
406 | TSIG RR | CLASS | MUST be ANY |
407 +------------+----------------+------------------------------------+
408 | TSIG RR | TTL | MUST be 0 |
409 +------------+----------------+------------------------------------+
410 | TSIG RDATA | Algorithm Name | in canonical wire format |
411 +------------+----------------+------------------------------------+
412 | TSIG RDATA | Time Signed | in network byte order |
413 +------------+----------------+------------------------------------+
414 | TSIG RDATA | Fudge | in network byte order |
415 +------------+----------------+------------------------------------+
416 | TSIG RDATA | Error | in network byte order |
417 +------------+----------------+------------------------------------+
418 | TSIG RDATA | Other Len | in network byte order |
419 +------------+----------------+------------------------------------+
420 | TSIG RDATA | Other Data | exactly as transmitted |
421 +------------+----------------+------------------------------------+
422
423 Table 2: TSIG Variables
424
425 The RR RDLENGTH and RDATA MAC Size are not included in the input to
426 MAC computation, since they are not guaranteed to be knowable before
427 the MAC is generated.
428
429 The Original ID field is not included in this section, as it has
430 already been substituted for the message ID in the DNS header and
431 hashed.
432
433 For each label type, there must be a defined "Canonical wire format"
434 that specifies how to express a label in an unambiguous way. For
435 label type 00, this is defined in Section 6.2 of [RFC4034]. The use
436 of label types other than 00 is not defined for this specification.
437
438 4.3.3.1. Time Values Used in TSIG Calculations
439
440 The data digested includes the two timer values in the TSIG header in
441 order to defend against replay attacks. If this were not done, an
442 attacker could replay old messages but update the Time Signed and
443 Fudge fields to make the message look new. The two fields are
444 collectively named "TSIG Timers", and for the purpose of MAC
445 calculation, they are hashed in their wire format, in the following
446 order: first Time Signed, then Fudge.
447
448 5. Protocol Details
449
450 5.1. Generation of TSIG on Requests
451
452 Once the outgoing record has been constructed, the client performs
453 the keyed hash (Hashed Message Authentication Code (HMAC))
454 computation, appends a TSIG record with the calculated MAC to the
455 additional section (incrementing the ARCOUNT to reflect the
456 additional RR), and transmits the request to the server. This TSIG
457 record MUST be the only TSIG RR in the message and MUST be the last
458 record in the additional data section. The client MUST store the MAC
459 and the key name from the request while awaiting an answer.
460
461 The digest components for a request are:
462
463 DNS Message (request)
464 TSIG Variables (request)
465
466 5.2. Server Processing of Request
467
468 If an incoming message contains a TSIG record, it MUST be the last
469 record in the additional section. Multiple TSIG records are not
470 allowed. If multiple TSIG records are detected or a TSIG record is
471 present in any other position, the DNS message is dropped and a
472 response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a
473 message with exactly one correctly placed TSIG RR, a copy of the TSIG
474 RR is stored and the TSIG RR is removed from the DNS message and
475 decremented out of the DNS message header's ARCOUNT.
476
477 If the TSIG RR cannot be interpreted, the server MUST regard the
478 message as corrupt and return a FORMERR to the server. Otherwise,
479 the server is REQUIRED to return a TSIG RR in the response.
480
481 To validate the received TSIG RR, the server MUST perform the
482 following checks in the following order:
483
484 1. Check key
485
486 2. Check MAC
487
488 3. Check time values
489
490 4. Check truncation policy
491
492 5.2.1. Key Check and Error Handling
493
494 If a non-forwarding server does not recognize the key or algorithm
495 used by the client (or recognizes the algorithm but does not
496 implement it), the server MUST generate an error response with RCODE
497 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be
498 unsigned as specified in Section 5.3.2. The server SHOULD log the
499 error. (Special considerations apply to forwarding servers; see
500 Section 5.5.)
501
502 5.2.2. MAC Check and Error Handling
503
504 Using the information in the TSIG, the server MUST verify the MAC by
505 doing its own calculation and comparing the result with the MAC
506 received. If the MAC fails to verify, the server MUST generate an
507 error response as specified in Section 5.3.2 with RCODE 9 (NOTAUTH)
508 and TSIG ERROR 16 (BADSIG). This response MUST be unsigned, as
509 specified in Section 5.3.2. The server SHOULD log the error.
510
511 5.2.2.1. MAC Truncation
512
513 When space is at a premium and the strength of the full length of a
514 MAC is not needed, it is reasonable to truncate the keyed hash and
515 use the truncated value for authentication. HMAC SHA-1 truncated to
516 96 bits is an option available in several IETF protocols, including
517 IPsec and TLS. However, while this option is kept for backwards
518 compatibility, it may not provide a security level appropriate for
519 all cases in the modern environment. In these cases, it is
520 preferable to use a hashing algorithm such as SHA-256-128, SHA-
521 384-192, or SHA-512-256 [RFC4868].
522
523 Processing of a truncated MAC follows these rules:
524
525 If the MAC Size field is greater than the keyed hash output
526 length: This case MUST NOT be generated and, if received, MUST cause
527 the DNS message to be dropped and RCODE 1 (FORMERR) to be
528 returned.
529
530 If the MAC Size field equals the keyed hash output length: The
531 entire keyed hash output is present and used.
532
533 If the MAC Size field is less than the larger of 10 (octets) and
534 half the length of the hash function in use: With the exception of
535 certain TSIG error messages described in Section 5.3.2, where it
536 is permitted that the MAC Size be zero, this case MUST NOT be
537 generated and, if received, MUST cause the DNS message to be
538 dropped and RCODE 1 (FORMERR) to be returned.
539
540 Otherwise: This is sent when the signer has truncated the keyed hash
541 output to an allowable length, as described in [RFC2104], taking
542 initial octets and discarding trailing octets. TSIG truncation
543 can only be to an integral number of octets. On receipt of a DNS
544 message with truncation thus indicated, the locally calculated MAC
545 is similarly truncated, and only the truncated values are compared
546 for authentication. The request MAC used when calculating the
547 TSIG MAC for a reply is the truncated request MAC.
548
549 5.2.3. Time Check and Error Handling
550
551 If the server time is outside the time interval specified by the
552 request (which is the Time Signed value plus/minus the Fudge value),
553 the server MUST generate an error response with RCODE 9 (NOTAUTH) and
554 TSIG ERROR 18 (BADTIME). The server SHOULD also cache the most
555 recent Time Signed value in a message generated by a key and SHOULD
556 return BADTIME if a message received later has an earlier Time Signed
557 value. A response indicating a BADTIME error MUST be signed by the
558 same key as the request. It MUST include the client's current time
559 in the Time Signed field, the server's current time (an unsigned
560 48-bit integer) in the Other Data field, and 6 in the Other Len
561 field. This is done so that the client can verify a message with a
562 BADTIME error without the verification failing due to another BADTIME
563 error. In addition, the Fudge field MUST be set to the fudge value
564 received from the client. The data signed is specified in
565 Section 5.3.2. The server SHOULD log the error.
566
567 Caching the most recent Time Signed value and rejecting requests with
568 an earlier one could lead to valid messages being rejected if transit
569 through the network led to UDP packets arriving in a different order
570 to the one in which they were sent. Implementations should be aware
571 of this possibility and be prepared to deal with it, e.g., by
572 retransmitting the rejected request with a new TSIG once outstanding
573 requests have completed or the time given by their Time Signed value
574 plus the Fudge value has passed. If implementations do retry
575 requests in these cases, a limit SHOULD be placed on the maximum
576 number of retries.
577
578 5.2.4. Truncation Check and Error Handling
579
580 If a TSIG is received with truncation that is permitted per
581 Section 5.2.2.1 but the MAC is too short for the local policy in
582 force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be
583 returned. The server SHOULD log the error.
584
585 5.3. Generation of TSIG on Answers
586
587 When a server has generated a response to a signed request, it signs
588 the response using the same algorithm and key. The server MUST NOT
589 generate a signed response to a request if either the key is invalid
590 (e.g., key name or algorithm name are unknown) or the MAC fails
591 validation; see Section 5.3.2 for details of responding in these
592 cases.
593
594 It also MUST NOT generate a signed response to an unsigned request,
595 except in the case of a response to a client's unsigned TKEY request
596 if the secret key is established on the server side after the server
597 processed the client's request. Signing responses to unsigned TKEY
598 requests MUST be explicitly specified in the description of an
599 individual secret key establishment algorithm [RFC3645].
600
601 The digest components used to generate a TSIG on a response are:
602
603 Request MAC
604 DNS Message (response)
605 TSIG Variables (response)
606
607 (This calculation is different for the second and subsequent message
608 in a multi-message answer; see below.)
609
610 If addition of the TSIG record will cause the message to be
611 truncated, the server MUST alter the response so that a TSIG can be
612 included. This response contains only the question and a TSIG
613 record, has the TC bit set, and has an RCODE of 0 (NOERROR). At this
614 point, the client SHOULD retry the request using TCP (as per
615 Section 4.2.2 of [RFC1035]).
616
617 5.3.1. TSIG on TCP Connections
618
619 A DNS TCP session, such as a zone transfer, can include multiple DNS
620 messages. Using TSIG on such a connection can protect the connection
621 from an attack and provide data integrity. The TSIG MUST be included
622 on all DNS messages in the response. For backward compatibility, a
623 client that receives DNS messages and verifies TSIG MUST accept up to
624 99 intermediary messages without a TSIG and MUST verify that both the
625 first and last message contain a TSIG.
626
627 The first message is processed as a standard answer (see
628 Section 5.3), but subsequent messages have the following digest
629 components:
630
631 Prior MAC (running)
632 DNS Messages (any unsigned messages since the last TSIG)
633 TSIG Timers (current message)
634
635 The "Prior MAC" is the MAC from the TSIG attached to the last message
636 containing a TSIG. "DNS Messages" comprises the concatenation (in
637 message order) of all messages after the last message that included a
638 TSIG and includes the current message. "TSIG Timers" comprises the
639 Time Signed and Fudge fields (in that order) pertaining to the
640 message for which the TSIG was created; this means that the
641 successive TSIG records in the stream will have non-decreasing Time
642 Signed values. Note that only the timers are included in the second
643 and subsequent messages, not all the TSIG variables.
644
645 This allows the client to rapidly detect when the session has been
646 altered; at which point, it can close the connection and retry. If a
647 client TSIG verification fails, the client MUST close the connection.
648 If the client does not receive TSIG records frequently enough (as
649 specified above), it SHOULD assume the connection has been hijacked,
650 and it SHOULD close the connection. The client SHOULD treat this the
651 same way as they would any other interrupted transfer (although the
652 exact behavior is not specified).
653
654 5.3.2. Generation of TSIG on Error Returns
655
656 When a server detects an error relating to the key or MAC in the
657 incoming request, the server SHOULD send back an unsigned error
658 message (MAC Size == 0 and empty MAC). It MUST NOT send back a
659 signed error message.
660
661 If an error is detected relating to the TSIG validity period or the
662 MAC is too short for the local policy, the server SHOULD send back a
663 signed error message. The digest components are:
664
665 Request MAC (if the request MAC validated)
666 DNS Message (response)
667 TSIG Variables (response)
668
669 The reason that the request MAC is not included in this MAC in some
670 cases is to make it possible for the client to verify the error. If
671 the error is not a TSIG error, the response MUST be generated as
672 specified in Section 5.3.
673
674 5.4. Client Processing of Answer
675
676 When a client receives a response from a server and expects to see a
677 TSIG, it first checks if the TSIG RR is present in the response. If
678 not, the response is treated as having a format error and is
679 discarded.
680
681 If the TSIG RR is present, the client performs the same checks as
682 described in Section 5.2. If the TSIG RR is unsigned as specified in
683 Section 5.3.2 or does not validate, the message MUST be discarded
684 unless the RCODE is 9 (NOAUTH). In this case, the client SHOULD
685 attempt to verify the response as if it were a TSIG error, as
686 described in the following subsections.
687
688 Regardless of the RCODE, a message containing a TSIG RR that is
689 unsigned as specified in Section 5.3.2 or that fails verification
690 SHOULD NOT be considered an acceptable response, as it may have been
691 spoofed or manipulated. Instead, the client SHOULD log an error and
692 continue to wait for a signed response until the request times out.
693
694 5.4.1. Key Error Handling
695
696 If an RCODE on a response is 9 (NOTAUTH), but the response TSIG
697 validates and the TSIG key is recognized by the client but is
698 different from that used on the request, then this is a key-related
699 error. The client MAY retry the request using the key specified by
700 the server. However, this should never occur, as a server MUST NOT
701 sign a response with a different key to that used to sign the
702 request.
703
704 5.4.2. MAC Error Handling
705
706 If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
707 this is a MAC-related error, and clients MAY retry the request with a
708 new request ID, but it would be better to try a different shared key
709 if one is available. Clients SHOULD keep track of how many MAC
710 errors are associated with each key. Clients SHOULD log this event.
711
712 5.4.3. Time Error Handling
713
714 If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
715 (BADTIME) or the current time does not fall in the range specified in
716 the TSIG record, then this is a time-related error. This is an
717 indication that the client and server clocks are not synchronized.
718 In this case, the client SHOULD log the event. DNS resolvers MUST
719 NOT adjust any clocks in the client based on BADTIME errors, but the
720 server's time in the Other Data field SHOULD be logged.
721
722 5.4.4. Truncation Error Handling
723
724 If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 22
725 (BADTRUNC), then this is a truncation-related error. The client MAY
726 retry with a lesser truncation up to the full HMAC output (no
727 truncation), using the truncation used in the response as a hint for
728 what the server policy allowed (Section 7). Clients SHOULD log this
729 event.
730
731 5.5. Special Considerations for Forwarding Servers
732
733 A server acting as a forwarding server of a DNS message SHOULD check
734 for the existence of a TSIG record. If the name on the TSIG is not
735 of a secret that the server shares with the originator, the server
736 MUST forward the message unchanged including the TSIG. If the name
737 of the TSIG is of a key this server shares with the originator, it
738 MUST process the TSIG. If the TSIG passes all checks, the forwarding
739 server MUST, if possible, include a TSIG of its own to the
740 destination or the next forwarder. If no transaction security is
741 available to the destination and the message is a query, and if the
742 corresponding response has the AD flag (see [RFC4035]) set, the
743 forwarder MUST clear the AD flag before adding the TSIG to the
744 response and returning the result to the system from which it
745 received the query.
746
747 6. Algorithms and Identifiers
748
749 The only message digest algorithm specified in the first version of
750 these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321] and
751 [RFC2104]). Although a review of its security some years ago
752 [RFC6151] concluded that "it may not be urgent to remove HMAC-MD5
753 from the existing protocols", with the availability of more secure
754 alternatives, the opportunity has been taken to make the
755 implementation of this algorithm optional.
756
757 [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4]
758 [RFC3174]. SHA-1 collisions have been demonstrated [SHA1SHAMBLES],
759 so the MD5 security considerations described in Section 2 of
760 [RFC6151] apply to SHA-1 in a similar manner. Although support for
761 hmac-sha1 in TSIG is still mandatory for compatibility reasons,
762 existing uses SHOULD be replaced with hmac-sha256 or other SHA-2
763 digest algorithms ([FIPS180-4], [RFC3874], [RFC6234]).
764
765 Use of TSIG between two DNS agents is by mutual agreement. That
766 agreement can include the support of additional algorithms and
767 criteria as to which algorithms and truncations are acceptable,
768 subject to the restriction and guidelines in Section 5.2.2.1. Key
769 agreement can be by the TKEY mechanism [RFC2930] or some other
770 mutually agreeable method.
771
772 Implementations that support TSIG MUST also implement HMAC SHA1 and
773 HMAC SHA256 and MAY implement gss-tsig and the other algorithms
774 listed below. SHA-1 truncated to 96 bits (12 octets) SHOULD be
775 implemented.
776
777 +==========================+================+=================+
778 | Algorithm Name | Implementation | Use |
779 +==========================+================+=================+
780 | HMAC-MD5.SIG-ALG.REG.INT | MAY | MUST NOT |
781 +--------------------------+----------------+-----------------+
782 | gss-tsig | MAY | MAY |
783 +--------------------------+----------------+-----------------+
784 | hmac-sha1 | MUST | NOT RECOMMENDED |
785 +--------------------------+----------------+-----------------+
786 | hmac-sha224 | MAY | MAY |
787 +--------------------------+----------------+-----------------+
788 | hmac-sha256 | MUST | RECOMMENDED |
789 +--------------------------+----------------+-----------------+
790 | hmac-sha256-128 | MAY | MAY |
791 +--------------------------+----------------+-----------------+
792 | hmac-sha384 | MAY | MAY |
793 +--------------------------+----------------+-----------------+
794 | hmac-sha384-192 | MAY | MAY |
795 +--------------------------+----------------+-----------------+
796 | hmac-sha512 | MAY | MAY |
797 +--------------------------+----------------+-----------------+
798 | hmac-sha512-256 | MAY | MAY |
799 +--------------------------+----------------+-----------------+
800
801 Table 3: Algorithms for Implementations Supporting TSIG
802
803 7. TSIG Truncation Policy
804
805 As noted above, two DNS agents (e.g., resolver and server) must
806 mutually agree to use TSIG. Implicit in such an "agreement" are
807 criteria as to acceptable keys, algorithms, and (with the extensions
808 in this document) truncations. Local policies MAY require the
809 rejection of TSIGs, even though they use an algorithm for which
810 implementation is mandatory.
811
812 When a local policy permits acceptance of a TSIG with a particular
813 algorithm and a particular non-zero amount of truncation, it SHOULD
814 also permit the use of that algorithm with lesser truncation (a
815 longer MAC) up to the full keyed hash output.
816
817 Regardless of a lower acceptable truncated MAC length specified by
818 local policy, a reply SHOULD be sent with a MAC at least as long as
819 that in the corresponding request. Note, if the request specified a
820 MAC length longer than the keyed hash output, it will be rejected by
821 processing rules (Section 5.2.2.1, case 1).
822
823 Implementations permitting multiple acceptable algorithms and/or
824 truncations SHOULD permit this list to be ordered by presumed
825 strength and SHOULD allow different truncations for the same
826 algorithm to be treated as separate entities in this list. When so
827 implemented, policies SHOULD accept a presumed stronger algorithm and
828 truncation than the minimum strength required by the policy.
829
830 8. Shared Secrets
831
832 Secret keys are very sensitive information and all available steps
833 should be taken to protect them on every host on which they are
834 stored. Generally, such hosts need to be physically protected. If
835 they are multi-user machines, great care should be taken so that
836 unprivileged users have no access to keying material. Resolvers
837 often run unprivileged, which means all users of a host would be able
838 to see whatever configuration data are used by the resolver.
839
840 A name server usually runs privileged, which means its configuration
841 data need not be visible to all users of the host. For this reason,
842 a host that implements transaction-based authentication should
843 probably be configured with a "stub resolver" and a local caching and
844 forwarding name server. This presents a special problem for
845 [RFC2136], which otherwise depends on clients to communicate only
846 with a zone's authoritative name servers.
847
848 Use of strong, random shared secrets is essential to the security of
849 TSIG. See [RFC4086] for a discussion of this issue. The secret
850 SHOULD be at least as long as the keyed hash output [RFC2104].
851
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
852 9. IANA Considerations
853
854 IANA maintains a registry of algorithm names to be used as "Algorithm
855 Names", as defined in Section 4.2 [IANA-TSIG]. Algorithm names are
856 text strings encoded using the syntax of a domain name. There is no
857 structure to the names, and algorithm names are compared as if they
858 were DNS names, i.e., comparison is case insensitive. Previous
859 specifications ([RFC2845] and [RFC4635]) defined values for the HMAC-
860 MD5 and some HMAC-SHA algorithms. IANA has also registered "gss-
861 tsig" as an identifier for TSIG authentication where the
862 cryptographic operations are delegated to the Generic Security
863 Service (GSS) [RFC3645]. This document adds to the allowed
864 algorithms, and the registry has been updated with the names listed
865 in Table 3.
866
867 New algorithms are assigned using the IETF Review policy defined in
868 [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like a
869 fully qualified domain name for historical reasons; other algorithm
870 names are simple, single-component names.
871
872 IANA maintains a registry of RCODEs (error codes) (see [IANA-RCODEs],
873 including "TSIG Error values" to be used for "Error" values, as
874 defined in Section 4.2. This document defines the RCODEs as
875 described in Section 3. New error codes are assigned and specified
876 as in [RFC6895].
877
878 10. Security Considerations
879
880 The approach specified here is computationally much less expensive
881 than the signatures specified in DNSSEC. As long as the shared
882 secret key is not compromised, strong authentication is provided
883 between two DNS systems, e.g., for the last hop from a local name
884 server to the user resolver or between primary and secondary name
885 servers.
886
887 Recommendations for choosing and maintaining secret keys can be found
888 in [RFC2104]. If the client host has been compromised, the server
889 should suspend the use of all secrets known to that client. If
890 possible, secrets should be stored in an encrypted form. Secrets
891 should never be transmitted in the clear over any network. This
892 document does not address the issue on how to distribute secrets
893 except that it mentions the possibilities of manual configuration and
894 the use of TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than
895 two entities; any such additional sharing would allow any party
896 knowing the key to impersonate any other such party to members of the
897 group.
898
899 This mechanism does not authenticate source data, only its
900 transmission between two parties who share some secret. The original
901 source data can come from a compromised zone master or can be
902 corrupted during transit from an authentic zone master to some
903 "caching forwarder". However, if the server is faithfully performing
904 the full DNSSEC security checks, then only security-checked data will
905 be available to the client.
906
907 A Fudge value that is too large may leave the server open to replay
908 attacks. A Fudge value that is too small may cause failures if
909 machines are not time synchronized or there are unexpected network
910 delays. The RECOMMENDED value in most situations is 300 seconds.
911
912 To prevent cross-algorithm attacks, there SHOULD only be one
913 algorithm associated with any given key name.
914
915 In several cases where errors are detected, an unsigned error message
916 must be returned. This can allow for an attacker to spoof or
917 manipulate these responses. Section 5.4 recommends logging these as
918 errors and continuing to wait for a signed response until the request
919 times out.
920
921 Although the strength of an algorithm determines its security, there
922 have been some arguments that mild truncation can strengthen a MAC by
923 reducing the information available to an attacker. However,
924 excessive truncation clearly weakens authentication by reducing the
925 number of bits an attacker has to try to break the authentication by
926 brute force [RFC2104].
927
928 Significant progress has been made recently in cryptanalysis of hash
929 functions of the types used here. While the results so far should
930 not affect HMAC, the stronger SHA-256 algorithm is being made
931 mandatory as a precaution.
932
933 See also the Security Considerations section of [RFC2104] from which
934 the limits on truncation in this RFC were taken.
935
936 10.1. Issue Fixed in This Document
937
938 When signing a DNS reply message using TSIG, the MAC computation uses
939 the request message's MAC as an input to cryptographically relate the
940 reply to the request. The original TSIG specification [RFC2845]
941 required that the time values be checked before the request's MAC.
942 If the time was invalid, some implementations failed to carry out
943 further checks and could use an invalid request MAC in the signed
944 reply.
945
946 This document makes it mandatory that the request MAC is considered
947 to be invalid until it has been validated; until then, any answer
948 must be unsigned. For this reason, the request MAC is now checked
949 before the time values.
950
951 10.2. Why Not DNSSEC?
952
953 DNS has been extended by DNSSEC ([RFC4033], [RFC4034], and [RFC4035])
954 to provide for data origin authentication, and public key
955 distribution, all based on public key cryptography and public key
956 based digital signatures. To be practical, this form of security
957 generally requires extensive local caching of keys and tracing of
958 authentication through multiple keys and signatures to a pre-trusted
959 locally configured key.
960
961 One difficulty with the DNSSEC scheme is that common DNS
962 implementations include simple "stub" resolvers which do not have
963 caches. Such resolvers typically rely on a caching DNS server on
964 another host. It is impractical for these stub resolvers to perform
965 general DNSSEC authentication and they would naturally depend on
966 their caching DNS server to perform such services for them. To do so
967 securely requires secure communication of queries and responses.
968 DNSSEC provides public key transaction signatures to support this,
969 but such signatures are very expensive computationally to generate.
970 In general, these require the same complex public key logic that is
971 impractical for stubs.
972
973 A second area where use of straight DNSSEC public key based
974 mechanisms may be impractical is authenticating dynamic update
975 [RFC2136] requests. DNSSEC provides for request signatures but with
976 DNSSEC they, like transaction signatures, require computationally
977 expensive public key cryptography and complex authentication logic.
978 Secure Domain Name System Dynamic Update ([RFC3007]) describes how
979 different keys are used in dynamically updated zones.
980
981 11. References
982
983 11.1. Normative References
984
985 [FIPS180-4]
986 National Institute of Standards and Technology, "Secure
987 Hash Standard (SHS)", FIPS PUB 180-4,
988 DOI 10.6028/NIST.FIPS.180-4, August 2015,
989 <https://doi.org/10.6028/NIST.FIPS.180-4>.
990
991 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
992 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
993 <https://www.rfc-editor.org/info/rfc1034>.
994
995 [RFC1035] Mockapetris, P., "Domain names - implementation and
996 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
997 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
998
999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1000 Requirement Levels", BCP 14, RFC 2119,
1001 DOI 10.17487/RFC2119, March 1997,
1002 <https://www.rfc-editor.org/info/rfc2119>.
1003
1004 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
1005 Wellington, "Secret Key Transaction Authentication for DNS
1006 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
1007 <https://www.rfc-editor.org/info/rfc2845>.
1008
1009 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1010 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
1011 2003, <https://www.rfc-editor.org/info/rfc3597>.
1012
1013 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
1014 Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
1015 RFC 4635, DOI 10.17487/RFC4635, August 2006,
1016 <https://www.rfc-editor.org/info/rfc4635>.
1017
1018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1019 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1020 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1021
1022 11.2. Informative References
1023
1024 [CVE-2017-11104]
1025 Common Vulnerabilities and Exposures, "CVE-2017-11104:
1026 Improper TSIG validity period check can allow TSIG
1027 forgery", June 2017, <https://cve.mitre.org/cgi-bin/
1028 cvename.cgi?name=CVE-2017-11104>.
1029
1030 [CVE-2017-3142]
1031 Common Vulnerabilities and Exposures, "CVE-2017-3142: An
1032 error in TSIG authentication can permit unauthorized zone
1033 transfers", June 2017, <https://cve.mitre.org/cgi-bin/
1034 cvename.cgi?name=CVE-2017-3142>.
1035
1036 [CVE-2017-3143]
1037 Common Vulnerabilities and Exposures, "CVE-2017-3143: An
1038 error in TSIG authentication can permit unauthorized
1039 dynamic updates", June 2017, <https://cve.mitre.org/cgi-
1040 bin/cvename.cgi?name=CVE-2017-3143>.
1041
1042 [IANA-RCODEs]
1043 IANA, "DNS RCODEs",
1044 <https://www.iana.org/assignments/dns-parameters/>.
1045
1046 [IANA-TSIG]
1047 IANA, "TSIG Algorithm Names",
1048 <https://www.iana.org/assignments/tsig-algorithm-names/>.
1049
1050 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1051 DOI 10.17487/RFC1321, April 1992,
1052 <https://www.rfc-editor.org/info/rfc1321>.
1053
1054 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
1055 Hashing for Message Authentication", RFC 2104,
1056 DOI 10.17487/RFC2104, February 1997,
1057 <https://www.rfc-editor.org/info/rfc2104>.
1058
1059 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
1060 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1061 RFC 2136, DOI 10.17487/RFC2136, April 1997,
1062 <https://www.rfc-editor.org/info/rfc2136>.
1063
1064 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
1065 RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
1066 <https://www.rfc-editor.org/info/rfc2930>.
1067
1068 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
1069 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
1070 <https://www.rfc-editor.org/info/rfc3007>.
1071
1072 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
1073 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
1074 <https://www.rfc-editor.org/info/rfc3174>.
1075
1076 [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
1077 and R. Hall, "Generic Security Service Algorithm for
1078 Secret Key Transaction Authentication for DNS (GSS-TSIG)",
1079 RFC 3645, DOI 10.17487/RFC3645, October 2003,
1080 <https://www.rfc-editor.org/info/rfc3645>.
1081
1082 [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
1083 RFC 3874, DOI 10.17487/RFC3874, September 2004,
1084 <https://www.rfc-editor.org/info/rfc3874>.
1085
1086 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1087 Rose, "DNS Security Introduction and Requirements",
1088 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1089 <https://www.rfc-editor.org/info/rfc4033>.
1090
1091 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1092 Rose, "Resource Records for the DNS Security Extensions",
1093 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1094 <https://www.rfc-editor.org/info/rfc4034>.
1095
1096 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1097 Rose, "Protocol Modifications for the DNS Security
1098 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1099 <https://www.rfc-editor.org/info/rfc4035>.
1100
1101 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
1102 "Randomness Requirements for Security", BCP 106, RFC 4086,
1103 DOI 10.17487/RFC4086, June 2005,
1104 <https://www.rfc-editor.org/info/rfc4086>.
1105
1106 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
1107 384, and HMAC-SHA-512 with IPsec", RFC 4868,
1108 DOI 10.17487/RFC4868, May 2007,
1109 <https://www.rfc-editor.org/info/rfc4868>.
1110
1111 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
1112 for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
1113 RFC 6151, DOI 10.17487/RFC6151, March 2011,
1114 <https://www.rfc-editor.org/info/rfc6151>.
1115
1116 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
1117 (SHA and SHA-based HMAC and HKDF)", RFC 6234,
1118 DOI 10.17487/RFC6234, May 2011,
1119 <https://www.rfc-editor.org/info/rfc6234>.
1120
1121 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
1122 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
1123 April 2013, <https://www.rfc-editor.org/info/rfc6895>.
1124
1125 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
1126 Agility and Selecting Mandatory-to-Implement Algorithms",
1127 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
1128 <https://www.rfc-editor.org/info/rfc7696>.
1129
1130 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
1131 Writing an IANA Considerations Section in RFCs", BCP 26,
1132 RFC 8126, DOI 10.17487/RFC8126, June 2017,
1133 <https://www.rfc-editor.org/info/rfc8126>.
1134
1135 [SHA1SHAMBLES]
1136 Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January
1137 2020, <https://eprint.iacr.org/2020/014.pdf>.
1138
1139 Acknowledgements
1140
1141 The security problem addressed by this document was reported by
1142 Clément Berthaux from Synacktiv.
1143
1144 Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund
1145 Sivaraman, and Ralph Dolmans participated in the discussions that
1146 prompted this document. Mukund Sivaraman, Martin Hoffman, and Tony
1147 Finch made extremely helpful suggestions concerning the structure and
1148 wording of the updated document.
1149
1150 Stephen Morris would like to thank Internet Systems Consortium for
1151 its support of his participation in the creation of this document.
1152
1153 Authors' Addresses
1154
1155 Francis Dupont
1156 Internet Systems Consortium, Inc.
1157 PO Box 360
1158 Newmarket, NH 03857
1159 United States of America
1160
1161 Email: Francis.Dupont@fdupont.fr
1162
1163
1164 Stephen Morris
1165 Unaffiliated
1166 United Kingdom
1167
1168 Email: sa.morris8@gmail.com
1169
1170
1171 Paul Vixie
1172 Farsight Security Inc
1173 Suite 180
1174 177 Bovet Road
1175 San Mateo, CA 94402
1176 United States of America
1177
1178 Email: paul@redbarn.org
1179
1180
1181 Donald E. Eastlake 3rd
1182 Futurewei Technologies
1183 2386 Panoramic Circle
1184 Apopka, FL 32703
1185 United States of America
1186
1187 Email: d3e3e3@gmail.com
1188
1189
1190 Olafur Gudmundsson
1191 Cloudflare
1192 United States of America
1193
1194 Email: olafur+ietf@cloudflare.com
1195
1196
1197 Brian Wellington
1198 Akamai
1199 United States of America
1200
1201 Email: bwelling@akamai.com
1202
The IANA registry is at https://www.iana.org/assignments/tsig-algorithm-names/tsig-algorithm-names.xhtml