idnits 2.17.00 (12 Aug 2021) /tmp/idnits54238/draft-ietf-dnsop-server-cookies-05.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 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 date (13 January 2021) is 486 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. 'SipHash-2-4' -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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: 17 July 2021 D. Eastlake 3rd 7 Futurewei Technologies 8 M. Andrews 9 Internet Systems Consortium 10 13 January 2021 12 Interoperable Domain Name System (DNS) Server Cookies 13 draft-ietf-dnsop-server-cookies-05 15 Abstract 17 DNS Cookies, as specified in [RFC7873], are a lightweight DNS 18 transaction security mechanism that provide limited protection to DNS 19 servers and clients against a variety of amplification denial of 20 service, forgery, or cache poisoning attacks by off-path attackers. 22 This document updates [RFC7873] with precise directions for creating 23 Server Cookies so that an anycast server set including diverse 24 implementations will interoperate with standard clients, suggestions 25 for constructing Client Cookies in a privacy preserving fashion, and 26 suggestions on how to update a Server Secret. An IANA registry 27 listing the methods and associated pseudo random function suitable 28 for creating DNS Server Cookies is created, with the method described 29 in this document as the first and as of yet only entry. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 17 July 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 7 73 5. Updating the Server Secret . . . . . . . . . . . . . . . . . 8 74 6. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security and Privacy Considerations . . . . . . . . . . . . . 10 77 8.1. Client Cookie construction . . . . . . . . . . . . . . . 10 78 8.2. Server Cookie construction . . . . . . . . . . . . . . . 11 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 81 11. Informative References . . . . . . . . . . . . . . . . . . . 13 82 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 13 83 A.1. Learning a new Server Cookie . . . . . . . . . . . . . . 13 84 A.2. The same client learning a renewed (fresh) Server 85 Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 A.3. Another client learning a renewed Server Cookie . . . . . 15 87 A.4. IPv6 query with rolled over secret . . . . . . . . . . . 16 88 Appendix B. Implementation status . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 DNS Cookies, as specified in [RFC7873], are a lightweight DNS 94 transaction security mechanism that provide limited protection to DNS 95 servers and clients against a variety of denial of service 96 amplification, forgery, or cache poisoning attacks by off-path 97 attackers. This document specifies a means of producing 98 interoperable Cookies so that an anycast server set including diverse 99 implementations can be easily configured to interoperate with 100 standard clients. Also single implementation or non-anycast services 101 can benefit from a well-studied standardized algorithm for which the 102 behavioural and security characteristics are more widely known. 104 The threats considered for DNS Cookies and the properties of the DNS 105 Security features other than DNS Cookies are discussed in [RFC7873]. 107 In [RFC7873] in Section 6 it is "RECOMMENDED for simplicity that the 108 same Server Secret be used by each DNS server in a set of anycast 109 servers." However, how precisely a Server Cookie is calculated from 110 this Server Secret, is left to the implementation. 112 This guidance has led to a gallimaufry of DNS Cookie implementations, 113 calculating the Server Cookie in different ways. As a result, DNS 114 Cookies are impractical to deploy on multi-vendor anycast networks, 115 because even when all DNS Software share the same secret, as 116 RECOMMENDED in Section 6 of [RFC7873], the Server Cookie constructed 117 by one implementation cannot generally be validated by another. 119 There is no need for DNS client (resolver) Cookies to be 120 interoperable across different implementations. Each client need 121 only be able to recognize its own cookies. However, this document 122 does contain recommendations for constructing Client Cookies in a 123 client protecting fashion. 125 1.1. Terminology and Definitions 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 * "IP address" is used herein as a length independent term covering 134 both IPv4 and IPv6 addresses. 136 2. Changes to [RFC7873] 138 In its Appendices A.1 and B.1, [RFC7873] provides example "simple" 139 algorithms for computing Client and Server Cookies, respectively. 140 These algorithms MUST NOT be used as the resulting cookies are too 141 weak when evaluated against modern security standards. 143 In its Appendix B.2, [RFC7873] provides an example "more complex" 144 server algorithm. This algorithm is replaced by the interoperable 145 specification in Section 4 of this document, which MUST be used by 146 Server Cookie implementations. 148 This document has suggestions on Client Cookie construction in 149 Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT 150 RECOMMENDED. 152 3. Constructing a Client Cookie 154 The Client Cookie acts as an identifier for a given client and its IP 155 address, and needs to be unguessable. In order to provide minimal 156 authentication of the targeted server, a client MUST use a different 157 Client Cookie for each different Server IP address. This complicates 158 a server's ability to spoof answers for other DNS servers. The 159 Client Cookie SHOULD have 64-bits of entropy. 161 When a server does not support DNS Cookies, the client MUST NOT send 162 the same Client Cookie to that same server again. Instead, it is 163 recommended that the client does not send a Client Cookie to that 164 server for a certain period, for example five minutes, before it 165 retries with a new Client Cookie. 167 When a server does support DNS Cookies, the client should store the 168 Client Cookie alongside the Server Cookie it registered for that 169 server. 171 Except for when the Client IP address changes, there is no need to 172 change the Client Cookie often. It is reasonable to change the 173 Client Cookie then only if it has been compromised or after a 174 relatively long implementation-defined period of time. The time 175 period should be no longer than a year, and in any case Client 176 Cookies are not expected to survive a program restart. 178 Client-Cookie = 64 bits of entropy 179 Previously, the recommended algorithm to compute the Client Cookie 180 included Client IP address as an input to a hashing function. 181 However, when implementing the DNS Cookies, several DNS vendors found 182 impractical to include the Client IP as the Client Cookie is 183 typically computed before the Client IP address is known. Therefore, 184 the requirement to put Client IP address as input was removed. 186 However, for privacy reasons, in order to prevent tracking of devices 187 across links and to not circumvent IPv6 Privacy Extensions [RFC4941], 188 clients MUST NOT re-use a Client or Server Cookie after the Client IP 189 address has changed. 191 One way to satisfy this requirement for non-re-use is to register the 192 Client IP address alongside the Server Cookie when it receives the 193 Server Cookie. In subsequent queries to the server with that Server 194 Cookie, the socket MUST be bound to the Client IP address that was 195 also used (and registered) when it received the Server Cookie. 196 Failure to bind MUST then result in a new Client Cookie. 198 4. Constructing a Server Cookie 200 The Server Cookie is effectively a Message Authentication Code (MAC). 201 The Server Cookie, when it occurs in a COOKIE option in a request, is 202 intended to weakly assure the server that the request came from a 203 client that is both at the source IP address of the request and using 204 the Client Cookie included in the option. This assurance is provided 205 by the Server Cookie that the server (or any other server from the 206 anycast set) sent to that client in an earlier response appearing as 207 the Server Cookie field in the request (see Section 5.2 of 208 [RFC7873]). 210 DNS Cookies do not provide protection against "on-path" adversaries 211 (see Section 9 of [RFC7873]). An on path observer that has seen a 212 Server Cookie for a client, can abuse that Server Cookie to spoof 213 request for that client within the timespan a Server Cookie is valid 214 (see Section 4.3). 216 The Server Cookie is calculated from the Client Cookie, a series of 217 Sub-Fields specified below, the Client IP address, and a Server 218 Secret known only to the server, or servers responding on the same 219 address in an anycast set. 221 For calculation of the Server Cookie, a pseudorandom function is 222 RECOMMENDED with the property that an attacker that does not know the 223 Server Secret, cannot find (any information about) the Server Secret 224 and cannot create a Server Cookie for any combination of - the Client 225 Cookie, the series of Sub-Fields specified below and the client IP 226 address - for which it has not seen a Server Cookie before. Because 227 DNS servers need to calculate in order to verify Server Cookies, it 228 is RECOMMENDED for the pseudorandom function to be performant. The 229 [SipHash-2-4] pseudorandom function introduced in Section 4.4 fit 230 these recommendations. 232 Changing the Server Secret regularly is RECOMMENDED but, when a 233 secure pseudorandom function is used, it need not be changed too 234 frequently. For example once a month would be adequate. See 235 Section 5 on operator and implementation guidelines for updating a 236 Server Secret. 238 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 239 Sub-Field, a 3 octet Reserved Sub-Field, a 4 octet Timestamp Sub- 240 Field and an 8 octet Hash Sub-Field. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Version | Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Timestamp | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Hash | 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 4.1. The Version Sub-Field 255 The Version Sub-Field prescribes the structure and Hash calculation 256 formula. This document defines Version 1 to be the structure and way 257 to calculate the Hash Sub-Field as defined in this Section. 259 4.2. The Reserved Sub-Field 261 The value of the Reserved Sub-Field is reserved for future versions 262 of server side Cookie construction. On construction it MUST be set 263 to zero octets. On Server Cookie verification the server MUST NOT 264 enforce those fields to be zero and the Hash should be computed with 265 the received value as described in Section 4.4. 267 4.3. The Timestamp Sub-Field 269 The Timestamp value prevents Replay Attacks and MUST be checked by 270 the server to be within a defined period of time. The DNS server 271 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 272 into the future to allow operation of low volume clients and some 273 limited time skew between the DNS servers in the anycast set. 275 The Timestamp value specifies a date and time in the form of a 32-bit 276 *unsigned* number of seconds elapsed since 1 January 1970 00:00:00 277 UTC, ignoring leap seconds, in network byte order. All comparisons 278 involving these fields MUST use "Serial number arithmetic", as 279 defined in [RFC1982]. The [RFC1982] specifies how the differences 280 should be handled. This handles any relative time window less than 281 68 years, at any time in the future (2038 or 2106 or 2256 or 22209 or 282 later.) 284 The DNS server SHOULD generate a new Server Cookie at least if the 285 received Server Cookie from the client is more than half an hour old, 286 but MAY generate a new cookie more often than that. 288 4.4. The Hash Sub-Field 290 It's important that all the DNS servers use the same algorithm for 291 computing the Server Cookie. This document defines the Version 1 of 292 the server side algorithm to be: 294 Hash = SipHash-2-4( 295 Client Cookie | Version | Reserved | Timestamp | Client-IP, 296 Server Secret ) 298 where "|" indicates concatenation. 300 Notice that Client-IP is used for hash generation even though it is 301 not included in the cookie value itself. Client-IP can be either 4 302 bytes for IPv4 or 16 bytes for IPv6. The length of all the 303 concatenated elements (the input into [SipHash-2-4]) MUST be either 304 precisely 20 bytes in case of an IPv4 Client-IP or precisely 32 bytes 305 in case of an IPv6 Client-IP. 307 When a DNS server receives a Server Cookie version 1 for validation, 308 the length of the received COOKIE option MUST be precisely 24 bytes: 309 8 bytes for the Client Cookie plus 16 bytes for the Server Cookie. 310 Verification of the length of the received COOKIE option is REQUIRED 311 to guarantee the length of the input into [SipHash-2-4] to be 312 precisely 20 bytes in case of an IPv4 Client-IP and precisely 32 313 bytes in case of an IPv6 Client-IP. This ensures that the input into 314 [SipHash-2-4] is an injective function of the elements making up the 315 input, and thereby prevents data substitution attacks. More 316 specifically, this prevents a 36 byte COOKIE option coming from an 317 IPv4 Client-IP to be validated as if it were coming from an IPv6 318 Client-IP. 320 The Server Secret MUST be configurable to make sure that servers in 321 an anycast network return consistent results. 323 5. Updating the Server Secret 325 Changing the Server Secret regularly is RECOMMENDED. All servers in 326 an anycast set must be able to verify the Server Cookies constructed 327 by all other servers in that anycast set at all times. Therefore it 328 is vital that the Server Secret is shared among all servers before it 329 is used to generate Server Cookies on any server. 331 Also, to maximize maintaining established relationships between 332 clients and servers, an old Server Secret should be valid for 333 verification purposes for a specific period. 335 To facilitate this, deployment of a new Server Secret MUST be done in 336 three stages: 338 Stage 1 339 The new Server Secret is deployed on all the servers in an anycast 340 set by the operator. 342 Each server learns the new Server Secret, but keeps using the 343 previous Server Secret to generate Server Cookies. 345 Server Cookies constructed with the both the new Server Secret and 346 with the previous Server Secret are considered valid when 347 verifying. 349 After stage 1 completed, all the servers in the anycast set have 350 learned the new Server Secret, and can verify Server Cookies 351 constructed with it, but keep generating Server Cookies with the 352 old Server Secret. 354 Stage 2 355 This stage is initiated by the operator after the Server Cookie is 356 present on all members in the anycast set. 358 When entering Stage 2, servers start generating Server Cookies 359 with the new Server Secret. The previous Server Secret is not yet 360 removed/forgotten about. 362 Server Cookies constructed with the both the new Server Secret and 363 with the previous Server Secret are considered valid when 364 verifying. 366 Stage 3 367 This stage is initiated by the operator when it can be assumed 368 that most clients have obtained a Server Cookie derived from the 369 new Server Secret. 371 With this stage, the previous Server Secret can be removed and 372 MUST NOT be used anymore for verifying. 374 We RECOMMEND the operator to wait at least a period to be the 375 longest TTL in the zones served by the server plus 1 hour after it 376 initiated Stage 2, before initiating Stage 3. 378 The operator SHOULD wait at least longer than the period clients 379 are allowed to use the same Server Cookie, which SHOULD be 1 hour, 380 see Section 4.3. 382 6. Cookie Algorithms 384 [SipHash-2-4] is a pseudorandom function suitable as Message 385 Authentication Code. This document REQUIRES compliant DNS server to 386 use SipHash-2-4 as a mandatory and default algorithm for DNS Cookies 387 to ensure interoperability between the DNS Implementations. 389 The construction method and pseudorandom function used in calculating 390 and verifying the Server Cookies are determined by the initial 391 version byte and by the length of the Server Cookie. Additional 392 pseudorandom or construction algorithms for Server Cookies might be 393 added in the future. 395 7. IANA Considerations 397 IANA is requested to create a registry on the "Domain Name System 398 (DNS) Parameters" IANA web page as follows: 400 Registry Name: DNS Server Cookie Methods 401 Assignment Policy: Expert Review 402 Reference: [this document], [RFC7873] 403 Note: Server Cookie method (construction and pseudorandom algorithm) 404 are determined by the Version in the first byte of the Cookie and by 405 the Cookie size. Server Cookie size is limited to the inclusive 406 range of 8 to 32 bytes. 408 +=========+=======+=======================================+ 409 | Version | Size | Method | 410 +=========+=======+=======================================+ 411 | 0 | 8-32 | reserved | 412 +---------+-------+---------------------------------------+ 413 | 1 | 8-15 | unassigned | 414 +---------+-------+---------------------------------------+ 415 | 1 | 16 | SipHash-2-4 [this document] Section 4 | 416 +---------+-------+---------------------------------------+ 417 | 1 | 17-32 | unassigned | 418 +---------+-------+---------------------------------------+ 419 | 2-239 | 8-32 | unassigned | 420 +---------+-------+---------------------------------------+ 421 | 240-254 | 8-32 | private use | 422 +---------+-------+---------------------------------------+ 423 | 255 | 8-32 | reserved | 424 +---------+-------+---------------------------------------+ 426 Table 1 428 8. Security and Privacy Considerations 430 DNS Cookies provide limited protection to DNS servers and clients 431 against a variety of denial of service amplification, forgery or 432 cache poisoning attacks by off-path attackers. They provide no 433 protection against on-path adversaries that can observe the plaintext 434 DNS traffic. An on-path adversary that can observe a Server Cookie 435 for a client and server interaction, can use that Server Cookie for 436 denial of service amplification, forgery or cache poisoning attacks 437 directed at that client for the lifetime of the Server Cookie. 439 8.1. Client Cookie construction 441 In [RFC7873] it was RECOMMENDED to construct a Client Cookie by using 442 a pseudorandom function of the Client IP address, the Server IP 443 address, and a secret quantity known only to the client. The Client 444 IP address was included to ensure that a client could not be tracked 445 if its IP address changes due to privacy mechanisms or otherwise. 447 In this document, we changed Client Cookie construction to be just 64 448 bits of entropy newly created for each new upstream server the client 449 connects to. As a consequence additional care needs to be taken to 450 prevent tracking of clients. To prevent tracking, a new Client 451 Cookie for a server MUST be created whenever the Client IP address 452 changes. 454 Unfortunately, tracking Client IP address changes is impractical with 455 servers that do not support DNS Cookies. To prevent tracking of 456 clients with non DNS Cookie supporting servers, a client MUST NOT 457 send a previously sent Client Cookie to a server not known to support 458 DNS Cookies. To prevent the creation of a new Client Cookie for each 459 query to an non DNS Cookies supporting server, it is RECOMMENDED to 460 not send a Client Cookie to that server for a certain period, for 461 example five minutes. 463 Summarizing: 465 * In order to provide minimal authentication, a client MUST use a 466 different Client Cookie for each different Server IP address. 468 * To prevent tracking of clients, a new Client Cookie MUST be 469 created when the Client IP address changes. 471 * To prevent tracking of clients by a non DNS Cookie supporting 472 server, a client MUST NOT send a previously sent Client Cookie to 473 a server in the absence of an associated Server Cookie. 475 Note that it is infeasible for a client to detect change of the 476 public IP address when the client is behind a routing device 477 performing Network Address Translation (NAT). A server may track the 478 public IP address of that routing device performing the NAT. 479 Preventing tracking of the public IP of a NAT performing routing 480 device is beyond the scope of this document. 482 8.2. Server Cookie construction 484 [RFC7873] did not give a precise recipe for constructing Server 485 Cookies, but did recommend usage of a pseudorandom function strong 486 enough to prevent guessing of cookies. In this document SipHash-2-4 487 is assigned as the pseudorandom function to be used for version 1 488 Server Cookies. SipHash-2-4 is considered sufficiently strong for 489 the immediate future, but predictions about future development in 490 cryptography and cryptanalysis are beyond the scope of this document. 492 The precise structure of version 1 Server Cookies is defined in this 493 document. Portion of the structure is made up of unhashed data 494 elements which are exposed in clear text to an on-path observer. 495 These unhashed data elements are taken along as input to the SipHash- 496 2-4 function of which the result is the other portion of the Server 497 Cookie, so the unhashed portion of the Server Cookie can not by 498 changed by an on-path attacking without also recalculating the hashed 499 portion for which the Server Secret needs to be known. 501 One of the elements in the unhashed portion of version 1 Server 502 Cookies is a Timestamp used to prevent Replay Attacks. Servers 503 verifying version 1 Server Cookies need to have access to a reliable 504 time value to compare with the Timestamp value, that cannot be 505 altered by an attacker. Furthermore, all servers participating in an 506 anycast set that validate version 1 Server Cookies need to have their 507 clocks synchronized. 509 The cleartext Timestamp data element reveal to an on-path adversary 510 using an observed Server Cookie to attack the client for which the 511 Server Cookie was constructed (as shown in the first paragraph of 512 this Section), the lifetime the observed Server Cookie can be used 513 for the attack. 515 In addition to the Security Considerations in this section, the 516 Security Considerations section of [RFC7873] still apply. 518 9. Acknowledgements 520 Thanks to Witold Krecicki and Pieter Lexis for valuable input, 521 suggestions and text and above all for implementing a prototype of an 522 interoperable DNS Cookie in Bind9, Knot and PowerDNS during the 523 hackathon of IETF104 in Prague. Thanks for valuable input and 524 suggestions go to Ralph Dolmans, Bob Harold, Daniel Salzman, Martin 525 Hoffmann, Mukund Sivaraman, Petr Spacek, Loganaden Velvindron, Bob 526 Harold, Philip Homburg, Tim Wicinski and Brian Dickson. 528 10. Normative References 530 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 531 DOI 10.17487/RFC1982, August 1996, 532 . 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, 537 . 539 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 540 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 541 . 543 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 544 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 545 . 547 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 548 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 549 May 2017, . 551 [SipHash-2-4] 552 Aumasson, J. and D. J. Bernstein, "SipHash: a fast short- 553 input PRF", Progress in Cryptology - INDOCRYPT 554 2012. Lecture Notes in Computer Science, vol 7668. 555 Springer., 2012, 556 . 558 11. Informative References 560 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 561 Extensions for Stateless Address Autoconfiguration in 562 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 563 . 565 Appendix A. Test vectors 567 A.1. Learning a new Server Cookie 569 A resolver (client) sending from IPv4 address 198.51.100.100, sends a 570 query for "example.com" to an authoritative server listening on 571 192.0.2.53 from which it has not yet learned the server cookie. 573 The DNS requests and replies shown in this Appendix, are in a "dig" 574 like format. The content of the DNS COOKIE Option is shown in 575 hexadecimal format after "; COOKIE:". 577 ;; Sending: 578 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 579 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 581 ;; OPT PSEUDOSECTION: 582 ; EDNS: version: 0, flags:; udp: 4096 583 ; COOKIE: 2464c4abcf10c957 584 ;; QUESTION SECTION: 585 ;example.com. IN A 587 ;; QUERY SIZE: 52 589 The authoritative nameserver (server) is configured with the 590 following secret: e5e973e5a6b2a43f48e7dc849e37bfcf (as hex data). 592 It receives the query at Wed Jun 5 10:53:05 UTC 2019. 594 The content of the DNS COOKIE Option that the server will return is 595 shown below in hexadecimal format after "; COOKIE:". 597 The Timestamp field Section 4.3 in the returned Server Cookie has 598 value 1559731985. In [RFC3339] format this is 2019-06-05 599 10:53:05+00:00. 601 ;; Got answer: 602 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57406 603 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 605 ;; OPT PSEUDOSECTION: 606 ; EDNS: version: 0, flags:; udp: 4096 607 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 (good) 608 ;; QUESTION SECTION: 609 ;example.com. IN A 611 ;; ANSWER SECTION: 612 example.com. 86400 IN A 192.0.2.34 614 ;; Query time: 6 msec 615 ;; SERVER: 192.0.2.53#53(192.0.2.53) 616 ;; WHEN: Wed Jun 5 10:53:05 UTC 2019 617 ;; MSD SIZE rcvd: 84 619 A.2. The same client learning a renewed (fresh) Server Cookie 621 40 minutes later, the same resolver (client) queries the same server 622 for "example.org". It reuses the Server Cookie it learned in the 623 previous query. 625 The Timestamp field in that previously learned Server Cookie, which 626 is now send along in the request, was and is 1559731985. In 627 [RFC3339] format this is 2019-06-05 10:53:05+00:00. 629 ;; Sending: 630 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 631 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 633 ;; OPT PSEUDOSECTION: 634 ; EDNS: version: 0, flags:; udp: 4096 635 ; COOKIE: 2464c4abcf10c957010000005cf79f111f8130c3eee29480 636 ;; QUESTION SECTION: 637 ;example.org. IN A 639 ;; QUERY SIZE: 52 640 The authoritative nameserver (server) now generates a new Server 641 Cookie. The server SHOULD do this because it can see the Server 642 Cookie send by the client is older than half an hour Section 4.3, but 643 it is also fine for a server to generate a new Server Cookie sooner, 644 or even for every answer. 646 The Timestamp field in the returned new Server Cookie has value 647 1559734385, which in [RFC3339] format is 2019-06-05 11:33:05+00:00. 649 ;; Got answer: 650 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939 651 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 653 ;; OPT PSEUDOSECTION: 654 ; EDNS: version: 0, flags:; udp: 4096 655 ; COOKIE: 2464c4abcf10c957010000005cf7a871d4a564a1442aca77 (good) 656 ;; QUESTION SECTION: 657 ;example.org. IN A 659 ;; ANSWER SECTION: 660 example.org. 86400 IN A 192.0.2.34 662 ;; Query time: 6 msec 663 ;; SERVER: 192.0.2.53#53(192.0.2.53) 664 ;; WHEN: Wed Jun 5 11:33:05 UTC 2019 665 ;; MSD SIZE rcvd: 84 667 A.3. Another client learning a renewed Server Cookie 669 Another resolver (client) with IPv4 address 203.0.113.203 sends a 670 request to the same server with a valid Server Cookie that it learned 671 before (at Wed Jun 5 09:46:25 UTC 2019). 673 The Timestamp field in Server Cookie in the request has value 674 1559727985, which in [RFC3339] format is 2019-06-05 09:46:25+00:00. 676 Note that the Server Cookie has Reserved bytes set, but is still 677 valid with the configured secret; the Hash part is calculated taking 678 along the Reserved bytes. 680 ;; Sending: 681 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 682 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 684 ;; OPT PSEUDOSECTION: 685 ; EDNS: version: 0, flags:; udp: 4096 686 ; COOKIE: fc93fc62807ddb8601abcdef5cf78f71a314227b6679ebf5 687 ;; QUESTION SECTION: 688 ;example.com. IN A 690 ;; QUERY SIZE: 52 692 The authoritative nameserver (server) replies with a freshly 693 generated Server Cookie for this client conformant with this 694 specification; so with the Reserved bits set to zero. 696 The Timestamp field in the returned new Server Cookie has value 697 1559734700, which in [RFC3339] format is 2019-06-05 11:38:20+00:00. 699 ;; Got answer: 700 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34736 701 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 703 ;; OPT PSEUDOSECTION: 704 ; EDNS: version: 0, flags:; udp: 4096 705 ; COOKIE: fc93fc62807ddb86010000005cf7a9acf73a7810aca2381e (good) 706 ;; QUESTION SECTION: 707 ;example.com. IN A 709 ;; ANSWER SECTION: 710 example.com. 86400 IN A 192.0.2.34 712 ;; Query time: 6 msec 713 ;; SERVER: 192.0.2.53#53(192.0.2.53) 714 ;; WHEN: Wed Jun 5 11:38:20 UTC 2019 715 ;; MSD SIZE rcvd: 84 717 A.4. IPv6 query with rolled over secret 719 The query below is from a client with IPv6 address 720 2001:db8:220:1:59de:d0f4:8769:82b8 to a server with IPv6 address 721 2001:db8:8f::53. The client has learned a valid Server Cookie before 722 (at Wed Jun 5 13:36:57 UTC 2019) when the Server had the secret: 723 dd3bdf9344b678b185a6f5cb60fca715. The server now uses a new secret, 724 but it can still validate the Server Cookie provided by the client as 725 the old secret has not expired yet. 727 The Timestamp field in the Server Cookie in the request has value 728 1559741817, which in [RFC3339] format is 2019-06-05 13:36:57+00:00. 730 ;; Sending: 731 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 732 ;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 734 ;; OPT PSEUDOSECTION: 735 ; EDNS: version: 0, flags:; udp: 4096 736 ; COOKIE: 22681ab97d52c298010000005cf7c57926556bd0934c72f8 737 ;; QUESTION SECTION: 738 ;example.net. IN A 740 ;; QUERY SIZE: 52 742 The authoritative nameserver (server) replies with a freshly 743 generated server cookie for this client with its new secret: 744 445536bcd2513298075a5d379663c962 746 The Timestamp field in the returned new Server Cookie has value 747 1559741961, which in [RFC3339] format is . 749 ;; Got answer: 750 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6774 751 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 753 ;; OPT PSEUDOSECTION: 754 ; EDNS: version: 0, flags:; udp: 4096 755 ; COOKIE: 22681ab97d52c298010000005cf7c609a6bb79d16625507a (good) 756 ;; QUESTION SECTION: 757 ;example.net. IN A 759 ;; ANSWER SECTION: 760 example.net. 86400 IN A 192.0.2.34 762 ;; Query time: 6 msec 763 ;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53) 764 ;; WHEN: Wed Jun 5 13:36:57 UTC 2019 765 ;; MSD SIZE rcvd: 84 767 Appendix B. Implementation status 769 At the time of writing, BIND from version 9.16 and Knot DNS from 770 version 2.9.0 create Server Cookies according to the recipe described 771 in this draft. Unbound and NSD have an Proof of Concept 772 implementation that has been tested for interoperability during the 773 hackathon at the IETF104 in Prague. Construction of privacy 774 maintaining Client Cookies according to the directions in this draft 775 have been implemented in the getdns library and will be in the 776 upcoming getdns-1.6.1 release and in Stubby version 0.3.1. 778 Authors' Addresses 780 Ondrej Sury 781 Internet Systems Consortium 782 Czechia 784 Email: ondrej@isc.org 786 Willem Toorop 787 NLnet Labs 788 Science Park 400 789 1098 XH Amsterdam 790 Netherlands 792 Email: willem@nlnetlabs.nl 794 Donald E. Eastlake 3rd 795 Futurewei Technologies 796 1424 Pro Shop Court 797 Davenport, FL 33896 798 United States of America 800 Phone: +1-508-333-2270 801 Email: d3e3e3@gmail.com 803 Mark Andrews 804 Internet Systems Consortium 805 950 Charter Street 806 Redwood City, CA 94063 807 United States of America 809 Email: marka@isc.org