idnits 2.17.1 draft-eastlake-dnsop-server-cookies-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2019) is 1712 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended Status: Proposed Standard Futurewei 3 Updates: 7873 M. Andrews 4 ISC 5 Expires: January 20, 2020 July 21, 2019 7 Interoperable Domain Name System (DNS) Server Cookies 8 10 Abstract 12 DNS cookies, as specified in RFC 7873, are a lightweight DNS 13 transaction security mechanism that provides limited protection to 14 DNS servers and clients against a variety of denial-of-service and 15 amplification, forgery, or cache poisoning attacks by off-path 16 attackers. This document specifies a means of producing interoperable 17 strong cookies so that an anycast server set including diverse 18 implementations will interoperate with standard clients. This 19 document updates RFC 7873. 21 Status of This Document 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the author or the DNSOP mailing list . 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................3 47 1.2 Definitions............................................3 49 2. Changes to [RFC7873]....................................4 50 3. Interoperable Server Cookie Configuration...............5 52 4. Server Cookie Calculations..............................6 53 4.1 Individual Server Cookie Calculation...................6 54 4.2 ServerSecret Calculation Schedule......................7 55 4.3 Initialization.........................................8 57 5. IANA Considerations.....................................9 58 6. Security Considerations.................................9 60 Normative References......................................10 61 Informative References....................................10 63 Acknowledgements..........................................11 65 Author's Address..........................................12 67 1. Introduction 69 DNS cookies, as specified in [RFC7873], are a lightweight DNS 70 transaction security mechanism that provides limited protection to 71 DNS servers and clients against a variety of denial-of-service and 72 amplification, forgery, or cache poisoning attacks by off-path 73 attackers. This document specifies a means of producing interoperable 74 strong cookies so that an anycast server set including diverse 75 implementations can be easily configured to interoperate with 76 standard clients. 78 The threats considered for DNS Cookies and the properties of the DNS 79 Security features other than DNS Cookies are discussed in [RFC7873]. 81 In the case of an anycast set of DNS servers, it is desirable for any 82 server in the set to be able to validate a server cookie recently 83 provided to a client by a different server in the set. If such a 84 server cookie is not recognized, it will typically result in one or 85 more additional roundtrips increasing volume of traffic and final 86 response latency. 88 There is no need for DNS client (resolver) Cookies to be 89 interoperable across different implementations. Each client need only 90 be able to recognize its own cookies. 92 1.2 Definitions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 "Floor" is the function returning the integer part of its argument. 101 That is, Floor(x) is the largest integer not greater than x. 103 "HMAC-SHA265-xx" is the HMAC [RFC2104] hash function using SHA-256 104 [RFC6234] truncated to xx bits. 106 "Off-path attacker", for a particular DNS client and server, is 107 defined as an attacker who cannot observe the DNS request and 108 response messages between that client and server. 110 "IP Address" is used herein as a length independent term covering 111 both IPv4 and IPv6 addresses. 113 2. Changes to [RFC7873] 115 In its Appendices A.1 and B.1 [RFC7873] provides example "simple" 116 algorithms for computing Client and Server Cookies, respectively. 117 These algorithms are NOT RECOMMENDED as the cookies produces are too 118 weak when evaluated against modern security standards. 120 In its Appendix B.2 [RFC7873] provides an example "more complex" 121 server algorithm. This algorithm is replaced by the interoperable 122 specification in Section 4 of this document, which is RECOMMENDED. 124 There is no reason for client cookies to be interoperable as clients 125 need only recognize their own cookies, which are returned in the 126 response to their queries. Thus, Appendix A.2 of [RFC7873] is 127 unchanged. 129 3. Interoperable Server Cookie Configuration 131 The calculation of interoperable server cookies is determined by two 132 configuration parameters: CookieMaster and SecretDuration. Methods 133 of distributing these two parameters to the DNS servers in an anycast 134 set are beyond the scope of this document but such methods MUST NOT 135 reveal CookieMaster to adversaries who might try to forge server 136 Cookies and SHOULD NOT reveal SecretDuration to such adversaries. 138 CookieMaster is the master secret used in deriving the 139 interoperable server cookies. It is a byte string not longer 140 than 255 bytes. It SHOULD NOT be shorter than 12 bytes and 141 SHOULD have at least 96 bits of entropy [RFC4086]. 143 SecretDuration is a parameter that determines when, on average, 144 the server rolls over the derived secret used in calculating 145 server cookies. It is a 16-bit quantity giving the average 146 seconds between rollovers as an unsigned integer. Values 147 less than 16 are Interpreted as being equal to 16. The 148 maximum time that can be represented is 18 hours 12 minutes 149 and 15 seconds. 151 4. Server Cookie Calculations 153 The calculations and internal variables specified in this section are 154 logical. Any other calculations and variables yielding the same 155 Server Cookies may be used. 157 Particular Server Cookies are calculated as specified in Section 4.1. 158 How and when the derived ServerSecret, used in calculating Server 159 Cookies, is calculated is specified in Section 4.2. And 160 initialization considerations are covered in Section 4.3. 162 State variables needed by the DNS server for this purpose, in 163 addition to the configuration quantities give in Section 3, are as 164 follows: 166 ServerSecret is a 128-bit quantity periodically derived from 167 CookieMaster as specified in Section 4.2. 169 Time is 64 bits and gives the time since the beginning of January 1, 170 1900, in seconds ignoring leap seconds, as an unsigned 171 integer in network byte order. 173 K is a 32-bit unsigned integer representing the ServerSecret epoch. 175 4.1 Individual Server Cookie Calculation 177 The value of an interoperable server cookie is a 128-bit quantity 178 structured as follows: 180 <--- 4 bytes ---> 181 +-------------------+ 182 | Nonce | 32 bits 183 +-------------------+ 184 | Time | 32 bits 185 +-------------------+ 186 | | 187 +- Hash -+ 64 bits 188 | | 189 +-------------------+ 191 Nonce = a 32-bit locally generated random number [RFC4086] which 192 SHOULD have 32 bits of entropy. The presence of the nonce 193 field assures a very low probability that there would be 194 duplicate cookies. 196 Time = the Time state variable defined above. The presence of 197 this field makes it easy to reject old cookies (unless they 198 are very old (close to some exact multiple of 2**32 seconds 199 (a little over 136 years) ago and you are still using the 200 same CookieMaster secret). 202 Hash = The Hash part of the Server Cookie is the hard-to-guess 203 part. (The Nonce and the Time appear in plain text.) It is 204 calculated in a two-stage process. First, the ServerSecret 205 is occasionally calculated at the times and by the method 206 specified in Section 4.2. Then the Hash is calculated using 207 the ServerSecret as show further below. 209 Whenever a server needs a Server Cookie to include in a 210 reply, it calculates the Hash field of that Server Cookie 211 as follows: 213 Hash = 214 HMAC-SHA256-64( ServerSecret, 215 ( Client Cookie | Nonce | Time | Client IP Address) ) 217 where "|" represents concatenation and the "Client Cookie" 218 is as specified in [RFC7873]. 220 With this method, a server sends a new 128-bit cookie back with every 221 request. 223 4.2 ServerSecret Calculation Schedule 225 A different Server Secret is used for each time epoch. Epoch k covers 226 the seconds numbered (see definition of Time above) from 227 EpochStart(k) to EpochStart(k+1)-1. 229 The ServerSecret used during epoch K is 231 ServerSecret = 232 HMAC-SHA256-128( "DNSCookie", 233 ( EpochStart(K) | CookieMaster | EpochStart(K) ) ) 235 where "|" represents concatenation and "DNSCookie" is that 9 byte 236 ASCII [RFC20] string without any zero termination byte. 238 As describe in Section 7.1 of [RFC7873], it is desirable for jitter 239 to be applied to the time of updating the key being used by the 240 servers in an anycast group. Including pseudo random jitter, the 241 start time of epoch K is as follows: 243 EpochStart( K ) = 244 K*SecretDuration + 245 Floor((HMAC-SHA256-32("DNSjitter", 246 K | CookieMaster)%SecretDuration)*8/10) 248 where "|" is concatenation, "%" is the modulus operator (x%y is the 249 remainder of x divided by y), and the output of HMAC-SHA256-32 is 250 considered a 32-bit unsigned integer. 252 If Time < EpochStart(K+1), then ServerSecret is up to date. If Time 253 >= EpochStart(K+1), then ServerSecret needs to be updated as 254 specified at the beginning of this section and K is incremented. 255 There are various strategies for keeping ServerSecret up do date. The 256 test at the beginning of this paragraph and conditional update of 257 ServerSecret could be done once a second. However, it would be more 258 efficient, when that test is done, to save EpochStart(K+1) as the 259 next time the test and conditional updates should be performed. 261 4.3 Initialization 263 Whenever the value of SecretDuration or CookieMaster or both is set 264 of if a significant change is made to Time, the steps in this section 265 MUST run before any Server Cookies are generated. (A change to Time 266 is significant if the first two steps below would result in a value 267 for K different from the current value.) 269 o K is set to Floor(Time/SecretDuration). 271 o If Time < EpochStart(K), then set K to K-1. 273 o Calculate and set ServerSecret as specified at the beginning of 274 Section 4.2. 276 5. IANA Considerations 278 This document requires no IANA actions. 280 6. Security Considerations 282 The minor adjustments to the Server Cookie calculation algorithm made 283 by this document do not affect the security considerations provided 284 in [RFC7873]. 286 Normative References 288 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 289 RFC 20, DOI 10.17487/RFC0020, October 1969, . 292 [RFC2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 293 Hashing for Message Authentication", RFC 2104, DOI 294 10.17487/RFC2104, February 1997, . 297 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 299 March 1997, . 301 [RFC4086] - Eastlake 3rd, D., Schiller, J., and S. Crocker, 302 "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 303 10.17487/RFC4086, June 2005, . 306 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 307 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 308 10.17487/RFC6234, May 2011, . 311 [RFC7873] - Eastlake 3rd, D. and M. Andrews, "Domain Name System 312 (DNS) Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 313 . 315 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 317 2017, . 319 Informative References 321 None. 323 Acknowledgements 325 The suggestions and contributions of the following are gratefully 326 acknowledged: 328 Petr Spacek 330 Author's Address 332 Donald E. Eastlake 3rd 333 Futurewei Technologies 334 1424 Pro Shop Court 335 Davenport, FL 33896 USA 337 Telephone: +1-508-333-2270 338 EMail: d3e3e3@gmail.com 340 Mark Andrews 341 Internet Systems Consortium 342 950 Charter Street 343 Redwood City, CA 94063 USA 345 Email: marka@isc.org 347 Copyright, Disclaimer, and Additional IPR Provisions 349 Copyright (c) 2019 IETF Trust and the persons identified as the 350 document authors. All rights reserved. 352 This document is subject to BCP 78 and the IETF Trust's Legal 353 Provisions Relating to IETF Documents 354 (http://trustee.ietf.org/license-info) in effect on the date of 355 publication of this document. Please review these documents 356 carefully, as they describe your rights and restrictions with respect 357 to this document. Code Components extracted from this document must 358 include Simplified BSD License text as described in Section 4.e of 359 the Trust Legal Provisions and are provided without warranty as 360 described in the Simplified BSD License.