idnits 2.17.1 draft-sury-toorop-dns-cookies-algorithms-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC7873], [FNV]), 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 (March 11, 2019) is 1872 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: 'DNSCOOKIE-IANA' is mentioned on line 199, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5649 ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 4 errors (**), 0 flaws (~~), 3 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: September 12, 2019 March 11, 2019 8 Algorithms for Domain Name System (DNS) Cookies construction 9 draft-sury-toorop-dns-cookies-algorithms-00 11 Abstract 13 [RFC7873] left the construction of Server Cookies to the discretion 14 of the DNS Server (implementer) which has resulted in a gallimaufry 15 of different implementations. As a result, DNS Cookies are 16 impractical to deploy on multi-vendor anycast networks, because the 17 Server Cookie constructed by one implementation cannot be validated 18 by another. 20 This document provides precise directions for creating Server Cookies 21 to address this issue. Furthermore, [FNV] is obsoleted as a suitable 22 Hash function for calculating DNS Cookies. [SipHash-2.4] is 23 introduced as a new REQUIRED Hash function for calculating DNS 24 Cookies. 26 This document updates [RFC7873] 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Contents of this document . . . . . . . . . . . . . . . . 3 64 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Constructing a Client Cookie . . . . . . . . . . . . . . . . 3 66 3. Constructing a Server Cookie . . . . . . . . . . . . . . . . 3 67 3.1. The Version Sub-Field . . . . . . . . . . . . . . . . . . 4 68 3.2. The Cookie algo Sub-Field . . . . . . . . . . . . . . . . 4 69 3.3. The Reserved Sub-Field . . . . . . . . . . . . . . . . . 4 70 3.4. The Timestamp Sub-Field . . . . . . . . . . . . . . . . . 4 71 3.5. The Hash Sub-Field . . . . . . . . . . . . . . . . . . . 5 72 4. Cookie Algorithms . . . . . . . . . . . . . . . . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 6.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 In [RFC7873] in Section 6 it is "RECOMMENDED for simplicity that the 82 Same Server Secret be used by each DNS server in a set of anycast 83 servers." However, how precisely a Server Cookie is calculated from 84 this Server Secret, is left to the implementation. 86 This guidance has let to DNS Cookie implementations, calculating the 87 Server Cookie in different ways. This causes problems with anycast 88 deployments with DNS Software from multiple vendors, because even 89 when all DNS Software would share the same secret, as RECOMMENDED in 90 Section 6. of [RFC7873], they all produce different Server Cookies 91 based on that secret and (at least) the Client Cookie and Client IP 92 Address. 94 1.1. Contents of this document 96 In Section Section 2 instructions for constructing a Client Cookie 97 are given 99 In Section Section 3 instructions for constructing a Server Cookie 100 are given 102 In Section Section 4 the different hash functions usable for DNS 103 Cookie construction are listed. [FNV] and HMAC-SHA-256-64 [RFC6234] 104 are obsoleted and AES [RFC5649] and [SipHash-2.4] are introduced as a 105 REQUIRED hash function for DNS Cookie implementations. 107 1.2. Definitions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY", 111 and "OPTIONAL" in this document are to be interpreted as described in 112 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2. Constructing a Client Cookie 117 The Client Cookie is a nonce and should be treated as such. For 118 simplicity, it can be calculated from Client IP Address, Server IP 119 Address and a secret known only to the Client. The Client Cookie 120 SHOULD have at least 64-bits of entropy. If a secure pseudorandom 121 function (like SipHash24) is used there's no need to change Client 122 secret periodically and change the Client secret only if it has been 123 compromised. 125 It's recommended but not required that a pseudorandom function is 126 used to construct the Client Cookie: 128 Client-Cookie = MAC_Algorithm( 129 Client IP Address | Server IP Address, Client Secret ) 131 where "|" indicates concatenation. 133 3. Constructing a Server Cookie 135 The Server Cookie is effectively message authentication code (MAC) 136 and should be treated as such. 138 The Server Cookie is not required to be changed periodically if a 139 secure pseudorandom function is used. 141 The 128-bit Server Cookie consists of Sub-Fields: a 1 octet Version 142 Sub-Field, a 1 octet Cookie Algorithm Sub-Field, a 2 octet Reserved 143 Sub-Field, a 4 octet Timestamp Sub-Field and a 8 octet Hash Sub- 144 Field. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Version | Cookie Algo | Reserved | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Timestamp | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Hash | 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 3.1. The Version Sub-Field 159 The Version Sub-Field prescribes the structure and Hash calculation 160 formula. This document defines Version 1 to be the structure and way 161 to calculate the Hash Sub-Field as defined in this Section. 163 3.2. The Cookie algo Sub-Field 165 The Cookie Algo value defines what algorithm function to use for 166 calculating the Hash Sub-Field as described in Section 3.5. The 167 values are described in Section 4. 169 3.3. The Reserved Sub-Field 171 The value of the Reserved Sub-Field is reserved for future versions 172 of Server Side Cookie construction. Even though the value has no 173 specific meaning in this Version, note that it *is* used in 174 determining the Hash value as described in Section 3.5. 176 3.4. The Timestamp Sub-Field 178 The Timestamp value prevents Replay Attacks and MUST be checked by 179 the server to be within a defined period of time. The DNS Server 180 SHOULD allow Cookies within 1 hour period in the past and 5 minutes 181 into the future to allow operation of low volume clients and certain 182 time skew between the DNS servers in the anycast. 184 The DNS Server SHOULD generate new Server Cookie at least if the 185 received Server Cookie from the Client is older than half an hour. 187 3.5. The Hash Sub-Field 189 It's important that all the DNS servers use the same algorithm for 190 computing the Server Cookie. This document defines the Version 1 of 191 the Server Side algorithm to be: 193 Hash = Cookie_Algorithm( 194 Client Cookie | Version | Cookie Algo | Reserved | TimeStamp, 195 Server Secret ) 197 4. Cookie Algorithms 199 Implementation recommendations for Cookie Algorithms [DNSCOOKIE- 200 IANA]: 202 +--------+-----------------+---------------+---------------+ 203 | Number | Mnemonics | Client Cookie | Server Cookie | 204 +--------+-----------------+---------------+---------------+ 205 | 1 | FNV | MUST NOT | MUST NOT | 206 | 2 | HMAC-SHA-256-64 | MUST NOT | MUST NOT | 207 | 3 | AES | MAY | MAY | 208 | 4 | SIPHASH24 | MUST | MUST | 209 +--------+-----------------+---------------+---------------+ 211 [FNV] is a Non-Cryptographic Hash Algorithm and this document 212 obsoletes the usage of FNV in DNS Cookies. 214 HMAC-SHA-256-64 is an HMAC-SHA-256 [RFC6234] algorithm reduced to 215 64-bit. This particular algorithm was implemented in BIND, but it 216 was never the default algorithm and the computational costs makes it 217 unsuitable to be used in DNS Cookies. Therefore this document 218 obsoletes the usage of HMAC-SHA-256 algorithm in the DNS Cookies. 220 The AES algorithm [RFC5649] has been the default DNS Cookies 221 algorithm in BIND until version x.y.z, and other implementations MAY 222 implement AES algorithm as implemented in BIND for backwards 223 compatibility. However it's recommended that new implementations 224 implement only a pseudorandom functions for DNS Cookies, in this 225 document that would be SipHash24. 227 [SipHash-2.4] is a pseudorandom function suitable as message 228 authentication code, and this document REQUIRES compliant DNS Server 229 to use SipHash24 as a mandatory and default algorithm for DNS Cookies 230 to ensure interoperability between the DNS Implementations. 232 5. IANA Considerations 234 IANA is requested to create and maintain a sub-registry (the "DNS 235 Cookie Algorithm" registry) of the "Domain Name System (DNS) 236 Parameters" registry. The initial values for this registry are 237 described in Section 4. 239 6. References 241 6.1. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 249 (AES) Key Wrap with Padding Algorithm", RFC 5649, 250 DOI 10.17487/RFC5649, September 2009, 251 . 253 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 254 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 255 DOI 10.17487/RFC6234, May 2011, 256 . 258 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 259 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 260 . 262 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 263 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 264 May 2017, . 266 6.2. Informative References 268 [FNV] Fowler, G., Noll, L., Vo, K., Eastlake, D., and T. Hansen, 269 "The FNV Non-Cryptographic Hash Algorithm", 270 . 272 [SipHash-2.4] 273 Aumasson, J. and D. Bernstein, "SipHash: a fast short- 274 input PRF", 2012, . 276 Authors' Addresses 278 Ondrej Sury 279 Internet Systems Consortium 280 CZ 282 Email: ondrej@isc.org 284 Willem Toorop 285 NLnet Labs 286 Science Park 400 287 Amsterdam 1098 XH 288 Netherlands 290 Email: willem@nlnetlabs.nl