idnits 2.17.00 (12 Aug 2021) /tmp/idnits23550/draft-ietf-dnsop-server-cookies-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC7873]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 20, 2020) is 730 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) == Missing Reference: 'RFC4941' is mentioned on line 207, but not defined ** Obsolete undefined reference: RFC 4941 (Obsoleted by RFC 8981) == Missing Reference: 'DNSCOOKIE-IANA' is mentioned on line 380, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group O. Sury 3 Internet-Draft Internet Systems Consortium 4 Updates: 7873 (if approved) W. Toorop 5 Intended status: Standards Track NLnet Labs 6 Expires: November 21, 2020 D. Eastlake 3rd 7 Futurewei Technologies 8 M. Andrews 9 Internet Systems Consortium 10 May 20, 2020 12 Interoperable Domain Name System (DNS) Server Cookies 13 draft-ietf-dnsop-server-cookies-03 15 Abstract 17 DNS cookies, as specified in RFC 7873, are a lightweight DNS 18 transaction security mechanism that provides limited protection to 19 DNS servers and clients against a variety of denial-of-service and 20 amplification, forgery, or cache poisoning attacks by off-path 21 attackers. 23 This document provides precise directions for creating Server Cookies 24 so that an anycast server set including diverse implementations will 25 interoperate with standard clients. 27 This document updates [RFC7873] 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 21, 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 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. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Contents of this document . . . . . . . . . . . . . . . . 3 65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Changes to [RFC7873] . . . . . . . . . . . . . . . . . . . . 4 67 3. Constructing a Client Cookie . . . . . . . . . . . . . . . . 4 68 4. Constructing a Server Cookie . . . . . . . . . . . . . . . . 5 69 4.1. The Version Sub-Field . . . . . . . . . . . . . . . . . . 6 70 4.2. The Reserved Sub-Field . . . . . . . . . . . . . . . . . 6 71 4.3. The Timestamp Sub-Field . . . . . . . . . . . . . . . . . 6 72 4.4. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 6 73 5. Updating the Server Secret . . . . . . . . . . . . . . . . . 7 74 6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Security and Privacy Considerations . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 81 Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11 82 B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11 83 B.2. The same client learning a renewed (fresh) Server Cookie 12 84 B.3. Another client learning a renewed Server Cookie . . . . . 13 85 B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14 86 Appendix C. Implementation status . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 DNS cookies, as specified in [RFC7873], are a lightweight DNS 92 transaction security mechanism that provides limited protection to 93 DNS servers and clients against a variety of denial-of-service and 94 amplification, forgery, or cache poisoning attacks by off-path 95 attackers. This document specifies a means of producing 96 interoperable strong cookies so that an anycast server set including 97 diverse implementations can be easily configured to interoperate with 98 standard clients. 100 The threats considered for DNS Cookies and the properties of the DNS 101 Security features other than DNS Cookies are discussed in [RFC7873]. 103 In [RFC7873] in Section 6 it is "RECOMMENDED for simplicity that the 104 same Server Secret be used by each DNS server in a set of anycast 105 servers." However, how precisely a Server Cookie is calculated from 106 this Server Secret, is left to the implementation. 108 This guidance has led to a gallimaufry of DNS Cookie implementations, 109 calculating the Server Cookie in different ways. As a result, DNS 110 Cookies are impractical to deploy on multi-vendor anycast networks, 111 because even when all DNS Software share the same secret, as 112 RECOMMENDED in Section 6 of [RFC7873], the Server Cookie constructed 113 by one implementation cannot generally be validated by another. 115 There is no need for DNS client (resolver) Cookies to be 116 interoperable across different implementations. Each client need 117 only be able to recognize its own cookies. However, this document 118 does contain recommendations for constructing Client Cookies in a 119 Client protecting fashion. 121 1.1. Contents of this document 123 Section Section 2 summarises the changes to [RFC7873]. 125 In Section Section 3 suggestions for constructing a Client Cookie are 126 given. 128 In Section Section 4 instructions for constructing a Server Cookie 129 are given. 131 In Section Section 5 instructions on updating Server Secrets are 132 given. 134 In Section Section 6 the different hash functions usable for DNS 135 Cookie construction are listed. [FNV] and HMAC-SHA-256-64 [RFC6234] 136 are deprecated and [SipHash-2.4] is introduced as a REQUIRED hash 137 function for server side DNS Cookie implementations. 139 IANA considerations are in Section 7. 141 Privacy and Security Considerations in Section 8. 143 Acknowledgements are in Appendix A. 145 Test vectors are in Appendix B. 147 1.2. Definitions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY", 151 and "OPTIONAL" in this document are to be interpreted as described in 152 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 o "IP Address" is used herein as a length independent term covering 156 both IPv4 and IPv6 addresses. 158 2. Changes to [RFC7873] 160 In its Appendices A.1 and B.1, [RFC7873] provides example "simple" 161 algorithms for computing Client and Server Cookies, respectively. 162 These algorithms MUST NOT be used as the resulting cookies are too 163 weak when evaluated against modern security standards. 165 In its Appendix B.2, [RFC7873] provides an example "more complex" 166 server algorithm. This algorithm is replaced by the interoperable 167 specification in Section 4 of this document, which MUST be used by 168 Server Cookie implementations. 170 This document has suggestions on Client Cookie construction in 171 Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT 172 RECOMMENDED. 174 3. Constructing a Client Cookie 176 The Client Cookie is a cryptographic nonce and should be treated as 177 such. It is RECOMMENDED to create a new Client Cookie for each new 178 upstream server a Client connects to. The Client Cookie SHOULD have 179 64-bits of entropy. 181 When a Server does not support DNS Cookies, the Client MUST NOT send 182 the same Client Cookie to that same Server again. Instead, it is 183 recommended that the Client does not send a Client Cookie to that 184 Server for a certain period, like for example five minutes, before it 185 retries with a new Client Cookie. 187 When a Server does support DNS Cookies, the Client should store the 188 Client Cookie alongside the Server Cookie it registered for that 189 Server. 191 Except for when the Client IP address changes, there is no need to 192 change the Client Cookie often. It is reasonable to change the 193 Client Cookie then only if it has been compromised or after a 194 relatively long period of time such as no longer than a year. Client 195 Cookies are not expected to survive a program restart. 197 Client-Cookie = 64 bits of entropy 199 Previously, the recommended algorithm to compute the Client Cookie 200 included Client IP Address as an input to a hashing function. 201 However, when implementing the DNS Cookies, several DNS vendors found 202 impractical to include the Client IP as the Client Cookie is 203 typically computed before the Client IP address is known. Therefore, 204 the requirement to put Client IP address as input was removed. 206 However, for privacy reasons, in order to prevent tracking of devices 207 across links and to not circumvent IPv6 Privacy Extensions [RFC4941], 208 Clients MUST NOT re-use a Client or Server Cookie after the Client IP 209 address has changed. 211 One way to track Client IP addresses, is to register the Client IP 212 address alongside the Server Cookie when it receives the Server 213 Cookie. In subsequent queries to the Server with that Server Cookie, 214 the socket MAY be bound to the Client IP address that was also used 215 (and registered) when it received the Server Cookie. Failure to bind 216 MUST then result in a new Client Cookie. 218 4. Constructing a Server Cookie 220 The Server Cookie is effectively a Message Authentication Code (MAC) 221 and should be treated as such. The Server Cookie is calculated from 222 the Client Cookie, a series of Sub-Fields specified below, the Client 223 IP address, and a Server Secret known only to the servers responding 224 on the same address in an anycast set. 226 Changing the Server Secret regularly is RECOMMENDED but, when a 227 secure pseudorandom function is used, it need not be changed too 228 frequent. For example once a month would be adequate. See Section 5 229 on operator and implementation guidelines for updating a Server 230 Secret. 232 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 233 Sub-Field, a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub- 234 Field and an 8 octet Hash Sub-Field. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Version | Reserved | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Timestamp | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Hash | 244 | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 4.1. The Version Sub-Field 249 The Version Sub-Field prescribes the structure and Hash calculation 250 formula. This document defines Version 1 to be the structure and way 251 to calculate the Hash Sub-Field as defined in this Section. 253 4.2. The Reserved Sub-Field 255 The value of the Reserved Sub-Field is reserved for future versions 256 of Server Side Cookie construction. On construction it SHOULD be set 257 to zero octets. On Server Cookie verification the server MUST NOT 258 enforce those fields to be zero and the Hash should be computed with 259 the received value as described in Section 4.4. 261 4.3. The Timestamp Sub-Field 263 The Timestamp value prevents Replay Attacks and MUST be checked by 264 the server to be within a defined period of time. The DNS Server 265 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 266 into the future to allow operation of low volume clients and some 267 limited time skew between the DNS servers in the anycast. 269 The Timestamp value specifies a date and time in the form of a 32-bit 270 unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, 271 ignoring leap seconds, in network byte order. All comparisons 272 involving these fields MUST use "Serial number arithmetic", as 273 defined in [RFC1982] 275 The DNS Server SHOULD generate a new Server Cookie at least if the 276 received Server Cookie from the Client is more than half an hour old. 278 4.4. The Hash Sub-Field 280 It's important that all the DNS servers use the same algorithm for 281 computing the Server Cookie. This document defines the Version 1 of 282 the Server Side algorithm to be: 284 Hash = SipHash2.4( 285 Client Cookie | Version | Reserved | Timestamp | Client-IP, 286 Server Secret ) 288 where "|" indicates concatenation. 290 Notice that Client-IP is used for hash generation even though it's 291 not included in the cookie value itself. Client-IP can be either 4 292 bytes for IPv4 or 16 bytes for IPv6. 294 The Server Secret MUST be configurable to make sure that servers in 295 an anycast network return consistent results. 297 5. Updating the Server Secret 299 All servers in an anycast group must be able to verify the Server 300 Cookies constructed by all other servers in that anycast set at all 301 times. Therefore it is vital that the Server Secret is shared among 302 all servers before it us used to generate Server Cookies. 304 Also, to maximize maintaining established relationships between 305 clients and servers, an old Server Secret should be valid for 306 verification purposes for a specific period. 308 To facilitate this, deployment of a new Server Secret MUST be done in 309 three stages: 311 Stage 1 312 The new Server Secret is deployed on all the servers in an anycast 313 set by the operator. 315 Each server learns the new Server Secret, but keeps using the 316 previous Server Secret to generate Server Cookies. 318 Server Cookies constructed with the both the new Server Secret and 319 with the previous Server Secret are considered valid when 320 verifying. 322 After stage 1 completed, all the servers in the anycast set have 323 learned the new Server Secret, and can verify Server Cookies 324 constructed with it, but keep generating Server Cookies with the 325 old Server Secret. 327 Stage 2 328 This stage is initiated by the operator after the Server Cookie is 329 present on all members in the anycast set. 331 When entering Stage 2, servers start generating Server Cookies 332 with the new Server Secret. The previous Server Secret is not yet 333 removed/forgotten about. 335 Server Cookies constructed with the both the new Server Secret and 336 with the previous Server Secret are considered valid when 337 verifying. 339 Stage 3 340 This stage is initiated by the operator when it can be assumed 341 that most clients have learned the new Server Secret. 343 With this stage, the previous Server Secret can be removed and 344 MUST NOT be used anymore for verifying. 346 We RECOMMEND the operator to wait at least a period to be the 347 longest TTL in the zones served by the server plus half an hour 348 after it initiated Stage 2, before initiating Stage 3. 350 The operator SHOULD wait at least longer than the period clients 351 are allowed to use the same Server Cookie, which SHOULD be half an 352 hour, see Section 4.3. 354 6. Cookie Algorithms 356 [SipHash-2.4] is a pseudorandom function suitable as Message 357 Authentication Code. This document REQUIRES compliant DNS Server to 358 use SipHash-2.4 as a mandatory and default algorithm for DNS Cookies 359 to ensure interoperability between the DNS Implementations. 361 The construction method and pseudorandom function used in calculating 362 and verifying the Server Cookies are determined by the initial 363 version byte and by the length of the Server Cookie. Additional 364 pseudorandom or construction algorithms for Server Cookies might be 365 added in the future. 367 7. IANA Considerations 369 IANA is requested to create a registry on the "Domain Name System 370 (DNS) Parameters" IANA web page as follows: 372 Registry Name: DNS Server Cookie Methods 373 Assignment Policy: Expert Review 374 Reference: [this document], [RFC7873] 375 Note: Server Cookie method (construction and pseudorandom algorithm) 376 are determined by the Version in the first byte of the Cookie and by 377 the Cookie size. Server Cookie size is limited to the inclusive 378 range of 8 to 32 bytes. 380 Implementation recommendations for Cookie Algorithms [DNSCOOKIE- 381 IANA]: 383 +---------+-------+---------------------------------------+ 384 | Version | Size | Method | 385 +---------+-------+---------------------------------------+ 386 | 0 | 8-32 | reserved | 387 | 1 | 8-15 | unassiged | 388 | 1 | 16 | SipHash-2.4 [this document] Section 4 | 389 | 1 | 17-32 | unassigned | 390 | 2-239 | 8-32 | unassigned | 391 | 240-254 | 8-32 | private use | 392 | 255 | 8-32 | reserved | 393 +---------+-------+---------------------------------------+ 395 8. Security and Privacy Considerations 397 DNS Cookies provides limited protection to DNS servers and clients 398 against a variety of denial-of-service and amplification/forgery or 399 cache poisoning attacks by off-path attackers. They provide no 400 protection against on-path adversaries that can observe the plaintext 401 DNS traffic. An on-path adversary that can observe a Server Cookie 402 for a client and server interaction, can use that Server Cookie for 403 amplification and denial-of-service forgery attacks for the lifetime 404 of the Server Cookie. 406 In [RFC7873] it was RECOMMENDED to construct a Client Cookie by using 407 a pseudorandom function of the Client IP Address, the Server IP 408 Address, and a secret quantity known only to the client. The Client 409 IP Address was included to ensure that a client could not be tracked 410 if its IP Address changes due to privacy mechanisms or otherwise. 412 In this document, we changed Client Cookie construction to be just 64 413 bits of entropy newly created for each new upstream server the client 414 connects to. As a consequence additional care needs to be taken to 415 prevent tracking of clients. To prevent tracking, a new Client 416 Cookie for a server MUST be created whenever the Client IP Address 417 changes. 419 Unfortunately, tracking Client IP Address Changes is impractical with 420 servers that do not support DNS Cookies. To prevent tracking of 421 clients with non DNS Cookie supporting servers, a client MUST NOT 422 send a previously sent Client Cookie. To prevent the creation of a 423 new Client Cookie for each query to an non DNS Cookies supporting 424 server, it is RECOMMENDED to not send a Client Cookie to that server 425 for a certain period, like for example five minute. 427 Summarizing: 429 o In order to provide minimal authentication, a client MUST use a 430 different Client Cookie for each different Server IP Address. 432 o To prevent tracking of clients, a new Client Cookie MUST be 433 created when the Client IP Address changes. 435 o To prevent tracking of clients for a non DNS Cookie supporting 436 server, a client MUST NOT send a previously sent Client Cookie to 437 that server, unless it can track Client IP Address changes for 438 those servers too. 440 Besides the Client Cookie construction, this update on [RFC7873] does 441 not introduce any new characteristics to DNS Cookies operations and 442 the Security Considerations section of [RFC7873] still applies. 444 9. References 446 9.1. Normative References 448 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 449 DOI 10.17487/RFC1982, August 1996, 450 . 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 458 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 459 . 461 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 462 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 463 May 2017, . 465 [SipHash-2.4] 466 Aumasson, J. and D. Bernstein, "SipHash: a fast short- 467 input PRF", 2012, . 469 9.2. Informative References 471 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 472 "The FNV Non-Cryptographic Hash Algorithm", 473 . 475 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 476 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 477 DOI 10.17487/RFC6234, May 2011, 478 . 480 Appendix A. Acknowledgements 482 Thanks to Witold Krecicki and Pieter Lexis for valuable input, 483 suggestions and text and above all for implementing a prototype of an 484 interoperable DNS Cookie in Bind9, Knot and PowerDNS during the 485 hackathon of IETF104 in Prague. Thanks for valuable input and 486 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin 487 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob 488 Harold and Philip Homburg 490 Appendix B. Test vectors 492 B.1. Learning a new Server Cookie 494 A resolver (client) sending from IPv4 address 198.51.100.100, sends a 495 query for "example.com" to an authoritative server listening on 496 192.0.2.53 from which it has not yet learned the server cookie. 498 The DNS requests and replies shown in this Appendix, are in a "dig" 499 like format. The content of the DNS COOKIE Option is shown in 500 hexadecimal format after "; COOKIE:". 502 ;; Sending: 503 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 504 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 506 ;; OPT PSEUDOSECTION: 507 ; EDNS: version: 0, flags:; udp: 4096 508 ; COOKIE: 2464c4abcf10c957 509 ;; QUESTION SECTION: 510 ;example.com. IN A 512 ;; QUERY SIZE: 52 514 The authoritative nameserver (server) is configured with the 515 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data). 517 It receives the query at Wed Jun 5 10:53:05 UTC 2019. 519 The content of the DNS COOKIE Option that the server will return is 520 shown below in hexadecimal format after "; COOKIE:" 521 ;; Got answer: 522 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 523 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 525 ;; OPT PSEUDOSECTION: 526 ; EDNS: version: 0, flags:; udp: 4096 527 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good) 528 ;; QUESTION SECTION: 529 ;example.com. IN A 531 ;; ANSWER SECTION: 532 example.com. 86400 IN A 192.0.2.34 534 ;; Query time: 6 msec 535 ;; SERVER: 192.0.2.53#53(192.0.2.53) 536 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019 537 ;; MSD SIZE rcvd: 84 539 B.2. The same client learning a renewed (fresh) Server Cookie 541 40 minutes later, the same resolver (client) queries the same server 542 for for "example.org" : 544 ;; Sending: 545 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 546 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 548 ;; OPT PSEUDOSECTION: 549 ; EDNS: version: 0, flags:; udp: 4096 550 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 551 ;; QUESTION SECTION: 552 ;example.org. IN A 554 ;; QUERY SIZE: 52 556 The authoritative nameserver (server) now generates a new Server 557 Cookie. The server SHOULD do this because it can see the Server 558 Cookie send by the client is older than half an hour Section 4.3, but 559 it is also fine for a server to generate a new Server Cookie sooner, 560 or even for every answer. 562 ;; Got answer: 563 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 564 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 566 ;; OPT PSEUDOSECTION: 567 ; EDNS: version: 0, flags:; udp: 4096 568 ; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good) 569 ;; QUESTION SECTION: 570 ;example.org. IN A 572 ;; ANSWER SECTION: 573 example.org. 86400 IN A 192.0.2.34 575 ;; Query time: 6 msec 576 ;; SERVER: 192.0.2.53#53(192.0.2.53) 577 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019 578 ;; MSD SIZE rcvd: 84 580 B.3. Another client learning a renewed Server Cookie 582 Another resolver (client) with IPv4 address 203.0.113.203 sends a 583 request to the same server with a valid Server Cookie that it learned 584 before (at Wed Jun 5 09:46:25 UTC 2019). Note that the Server Cookie 585 has Reserved bytes set, but is still valid with the configured 586 secret; the Hash part is calculated taking along the Reserved bytes. 588 ;; Sending: 589 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 590 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 592 ;; OPT PSEUDOSECTION: 593 ; EDNS: version: 0, flags:; udp: 4096 594 ; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5 595 ;; QUESTION SECTION: 596 ;example.com. IN A 598 ;; QUERY SIZE: 52 600 The authoritative nameserver (server) replies with a freshly 601 generated Server Cookie for this client conformant with this 602 specification; so with the Reserved bits set to zero. 604 ;; Got answer: 605 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 606 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 608 ;; OPT PSEUDOSECTION: 609 ; EDNS: version: 0, flags:; udp: 4096 610 ; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good) 611 ;; QUESTION SECTION: 612 ;example.com. IN A 614 ;; ANSWER SECTION: 615 example.com. 86400 IN A 192.0.2.34 617 ;; Query time: 6 msec 618 ;; SERVER: 192.0.2.53#53(192.0.2.53) 619 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019 620 ;; MSD SIZE rcvd: 84 622 B.4. IPv6 query with rolled over secret 624 The query below is from a client with IPv6 address 625 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address 626 2001:db8:8f::53. The client has learned a valid Server Cookie before 627 when the Server had secret: dd3bdf9344b678b185a6f5cb60fca715. The 628 server now uses a new secret, but it can still validate the Server 629 Cookie provided by the client as the old secret has not expired yet. 631 ;; Sending: 632 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 633 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 635 ;; OPT PSEUDOSECTION: 636 ; EDNS: version: 0, flags:; udp: 4096 637 ; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8 638 ;; QUESTION SECTION: 639 ;example.net. IN A 641 ;; QUERY SIZE: 52 643 The authoritative nameserver (server) replies with a freshly 644 generated server cookie for this client with its new secret: 645 445536bcd2513298075a5d379663c962 646 ;; Got answer: 647 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 648 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 650 ;; OPT PSEUDOSECTION: 651 ; EDNS: version: 0, flags:; udp: 4096 652 ; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good) 653 ;; QUESTION SECTION: 654 ;example.net. IN A 656 ;; ANSWER SECTION: 657 example.net. 86400 IN A 192.0.2.34 659 ;; Query time: 6 msec 660 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) 661 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 662 ;; MSD SIZE rcvd: 84 664 Appendix C. Implementation status 666 At the time of writing, BIND from version 9.16 and Knot DNS from 667 version 2.9.0 create Server Cookies according to the recipe described 668 in this draft. Unbound and NSD have an Proof of Concept 669 implementation that has been tested for interoperability during the 670 hackathon at the IETF104 in Prague. Construction of privacy 671 maintaining Client Cookies according to the directions in this draft 672 have been implemented in the getdns library and will be in the 673 upcoming getdns-1.6.1 release and in Stubby version 0.3.1. 675 Authors' Addresses 677 Ondrej Sury 678 Internet Systems Consortium 679 CZ 681 Email: ondrej@isc.org 683 Willem Toorop 684 NLnet Labs 685 Science Park 400 686 Amsterdam 1098 XH 687 Netherlands 689 Email: willem@nlnetlabs.nl 690 Donald E. Eastlake 3rd 691 Futurewei Technologies 692 1424 Pro Shop Court 693 Davenport FL 33896 694 USA 696 Phone: +1-508-333-2270 697 Email: d3e3e3@gmail.com 699 Mark Andrews 700 Internet Systems Consortium 701 950 Charter Street 702 Redwood City CA 94063 703 USA 705 Email: marka@isc.org