idnits 2.17.1 draft-muks-dnsop-dns-message-checksums-01.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 (October 13, 2015) is 3117 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Sivaraman 3 Internet-Draft Internet Systems Consortium 4 Intended status: Experimental October 13, 2015 5 Expires: April 15, 2016 7 DNS message checksums 8 draft-muks-dnsop-dns-message-checksums-01 10 Abstract 12 This document describes a method for a client to be able to verify 13 that IP-layer PDU fragments of a UDP DNS message have not been 14 spoofed by an off-path attacker. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 15, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. DNS message checksum method . . . . . . . . . . . . . . . . . 3 52 3. The CHECKSUM EDNS(0) option . . . . . . . . . . . . . . . . . 4 53 3.1. Wire format . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.2. Option fields . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2.2. ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2.3. DIGEST . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Presentation format . . . . . . . . . . . . . . . . . . . 5 59 4. Checksum computation . . . . . . . . . . . . . . . . . . . . 5 60 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 61 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative references . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative references . . . . . . . . . . . . . . . . . 8 66 Appendix A. Checksum algorithms . . . . . . . . . . . . . . . . 8 67 Appendix B. Change history (to be removed before publication) . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 [RFC1035] describes how DNS messages are to be transmitted over UDP. 73 A DNS query message is transmitted using one UDP datagram from client 74 to server, and a corresponding DNS reply message is transmitted using 75 one UDP datagram from server to client. 77 As a UDP datagram is transmitted in a single IP PDU, in theory the 78 size of a UDP datagram (including various lower internet layer 79 headers) can be as large as 64 KiB. But practically, if the datagram 80 size exceeds the path MTU, then the datagram will either be 81 fragmented at the IP layer, or dropped by a forwarder. In the case 82 of IPv4, DNS datagrams may be fragmented by a sender or a forwarder. 83 In the case of IPv6, DNS datagrams are fragmented by the sender only. 85 IP-layer fragmentation for large DNS response datagrams introduces 86 risk of cache poisoning by off-path attackers [Fragment-Poisonous] in 87 which an attacker can circumvent some defense mechanisms like source 88 port and query ID randomization [RFC5452]. 90 This memo introduces the concept of a DNS message checksum which may 91 be used to stop the effects of such off-path attacks. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. DNS message checksum method 99 Clients supporting DNS message checksums add an EDNS option to their 100 queries, which signals their support for this feature. 102 The CHECKSUM EDNS option contains 3 fields: NONCE, ALGORITHM, and 103 DIGEST. These fields are described in Section 3. 105 It is OPTIONAL for a client to add a CHECKSUM EDNS option to DNS 106 query messages. If it adds such an option, it MUST set the NONCE 107 field to a random value. The ALGORITHM field MUST be set to 0 and 108 the DIGEST field MUST be left empty. The entire NONCE field MUST be 109 randomly generated (i.e., in no predictable sequence and the random 110 value must fill all bits of the field) for each query for which the 111 client uses a CHECKSUM EDNS option. The client is expected to 112 remember the per-query NONCE field's value to be used in verifying 113 the reply to this query message. 115 A client MUST NOT send multiple DNS query messages with the NONCE set 116 to a fixed unchanging value. Instead, it must not send the option at 117 all. 119 The server SHOULD add a CHECKSUM EDNS option in the reply message to 120 a corresponding query that arrived with this option present. The 121 NONCE field MUST be copied verbatim from the query message to the 122 corresponding reply message. A checksum is computed over the DNS 123 reply message as described in Section 4 and the ALGORITHM and DIGEST 124 fields MUST be set using the resulting checksum as given in 125 Section 3. The server is at liberty to choose any checksum algorithm 126 it wants to from the list of supported algorithms given in 127 Appendix A. 129 If a server receives a query containing a CHECKSUM EDNS option with 130 an ALGORITHM field that is not set to 0, it MUST ignore this option 131 and process the request as if there were no CHECKSUM EDNS option in 132 the query. 134 When a client receives a reply message for which it sent a CHECKSUM 135 EDNS option in the corresponding query, it SHOULD look for the 136 presence of the CHECKSUM EDNS option in the reply. 138 The client may handle the lack of a CHECKSUM EDNS option in the reply 139 as it chooses to. It is currently not specified, but may be updated 140 in the future. 142 If a client receives a reply containing a CHECKSUM EDNS option with 143 an unknown ALGORITHM value, it MUST ignore this option and handle the 144 reply as if there were no CHECKSUM EDNS option in it. From the 145 previous paragraph, it follows that the client behavior in this case 146 is also currently not specified, but may be updated in the future. 148 If a CHECKSUM EDNS option is present in the reply, the client SHOULD 149 first check and ensure that the NONCE field contains the same nonce 150 value that was sent in the corresponding query message. If the value 151 in the NONCE field is different, the reply message MUST be discarded. 152 Afterwards, the client SHOULD proceed to compute a checksum over the 153 reply message as described in Section 4 using the checksum algorithm 154 in the ALGORITHM field. It SHOULD then compare the checksum value 155 with the value that was received in the DIGEST field for equality. 156 If they are not equal, the reply message MUST be discarded. If they 157 are equal, the reply message can be used normally as the client 158 intends to use it. 160 3. The CHECKSUM EDNS(0) option 162 CHECKSUM is an EDNS(0) [RFC6891] option that is used to transmit a 163 digest of a DNS message in replies. Client and server behavior are 164 described in Section 2. In this section, the option's syntax is 165 provided. 167 3.1. Wire format 169 The following describes the wire format of the OPTION-DATA field 170 [RFC6891] of the CHECKSUM EDNS option. All CHECKSUM option fields 171 must be represented in network byte order. 173 +--------------+------------------+--------------------+ 174 | Option field | Type | Field size | 175 +--------------+------------------+--------------------+ 176 | NONCE | unsigned integer | 64 bits (8 octets) | 177 | ALGORITHM | unsigned integer | 8 bits (1 octet) | 178 | DIGEST | byte array | Variable length | 179 +--------------+------------------+--------------------+ 181 3.2. Option fields 183 3.2.1. NONCE 185 The NONCE field is represented as an unsigned 64-bit integer in 186 network byte order. It MUST be randomly computed for each query 187 message which a client sends out, and is copied verbatim from the 188 query to the corresponding reply DNS message by the server. 190 3.2.2. ALGORITHM 192 The ALGORITHM field is represented as an unsigned 8-bit integer in 193 network byte order. In query messages, it MUST be set to 0. In 194 reply messages, it MUST contain the numeric value of the algorithm 195 used to compute the DIGEST field. A list of algorithms and their 196 values is given in Appendix A. 198 3.2.3. DIGEST 200 The DIGEST field is represented as a variable-length sequence of 201 octets present after the NONCE and ALGORITHM fields. Its size is 202 implicitly computed from the value in the OPTION-LENGTH field 203 [RFC6891] for the CHECKSUM EDNS option minus the size of the NONCE 204 and ALGORITHM fields. In query messages, it MUST be empty. In reply 205 messages, it MUST contain the digest of the reply message which is 206 computed as described in Section 4. 208 3.3. Presentation format 210 As with other EDNS(0) options, the CHECKSUM EDNS option does not have 211 a presentation format. 213 4. Checksum computation 215 To generate the checksum digest to be placed in the DIGEST field, 216 first the entire DNS message must be prepared (rendered) along with 217 the CHECKSUM option embedded in it to the point that it is ready to 218 be sent out on the wire. In this CHECKSUM option, initially the 219 DIGEST field must be filled with zero values and its size must be 220 reserved equal to the size expected for the digest from the checksum 221 algorithm intended to be used. The NONCE field MUST be set to the 222 value of the nonce from the query DNS message. The ALGORITHM field 223 MUST be set to the checksum algorithm intended to be used. After 224 this, the whole message contents (from the start of the DNS message 225 header onwards) must be input to the checksum algorithm and the 226 calculated checksum must be patched into the DIGEST field, space for 227 which was reserved before. 229 To verify the checksum digest from a DNS message that was received, 230 first the DIGEST field is copied to a temporary location and the 231 DIGEST field in the message is patched with zero values. After this, 232 the whole message contents (from the start of the DNS message header 233 onwards) must be input to the checksum algorithm specified in the 234 ALGORITHM field. The calculated checksum must be compared for 235 equality with the checksum originally received in the DIGEST field, 236 the content of which was earlier saved to a temporary location. If 237 both are equal, the checksum matches. 239 5. Security considerations 241 The methods in this memo are designed to thwart off-path spoofing 242 attacks which may lead to cache-poisoning, including the specific 243 case when IP-layer PDU fragmentation occurs. 245 The CHECKSUM EDNS option is not designed to offer any protection 246 against on-path attackers. Very little can be done without using 247 shared-secret or public key cryptography for this case. 249 Checksum computation may increase resource usage on servers and 250 clients. It is thus desirable to use fast checksum algorithms that 251 meet the requirements of Appendix A. 253 The entropy source used for generating random values for use in the 254 NONCE field may be chosen similarly to provide ample security to 255 verify a short-lived DNS message. 257 The NONCE field effectively extends the ID field [RFC1035] in the DNS 258 message header. 260 As a side-effect of using checksums, resolver cache poisoning attacks 261 are made more difficult due to the presence of the NONCE field. 263 There is a risk of downgrade attack when the IP fragment containing 264 the CHECKSUM EDNS option is spoofed, deleting this option. This risk 265 would exist until the presence of the CHECKSUM option in replies is 266 made mandatory when a corresponding option is sent in the query. 267 This can be made so right from the start, or after an adoption 268 period. At that time, it may be stated that a client that does not 269 receive a CHECKSUM EDNS option in a reply would discard the reply 270 message and retry the query using TCP. 272 The CHECKSUM EDNS option cannot prevent some kinds of attack such as 273 response and NS blocking and NS pinning as described in 274 [Fragment-Poisonous]. 276 6. IANA considerations 278 This document defines a new EDNS(0) option, titled CHECKSUM (see 279 Section 3), assigned a value of from the DNS EDNS0 Option Codes 280 (OPT) space [to be removed upon publication: 281 https://www.iana.org/assignments/dns-parameters/dns- 282 parameters.xhtml#dns-parameters-11]. 284 +------+----------+--------+----------------------------------------+ 285 | Valu | Name | Status | Reference | 286 | e | | | | 287 +------+----------+--------+----------------------------------------+ 288 | TBD | CHECKSUM | TBD | [draft-muks-dnsop-dns-message- | 289 | | | | checksums] | 290 +------+----------+--------+----------------------------------------+ 292 The CHECKSUM EDNS(0) option also defines an 8-bit ALGORITHM field, 293 for which IANA is to create and maintain a new sub-registry entitled 294 "DNS message checksum algorithms" under the Domain Name System (DNS) 295 Parameters. Initial values for the DNS message checksum algorithms 296 registry are given in Appendix A; future assignments are to be made 297 through Expert Review as in BCP 26 [RFC5226]. Assignments consist of 298 a DNS message checksum algorithm name and its associated value. 300 7. Acknowledgements 302 Tomek Mrugalski offered tips on draft naming and upload process. Joe 303 Abley reviewed the draft and pointed out some nits that were not 304 detected automatically. Ray Bellis, Robert Edmonds, Tony Finch, Paul 305 Hoffman, Evan Hunt, Paul Vixie, and Paul Wouters reviewed drafts and 306 sent in comments and opinions. Mark Andrews mentioned an alternate 307 method at the same time (on an internal mailing list) to address 308 spoofing issues that provided further support to the idea that 309 CHECKSUM was worth pursuing. 311 8. References 313 8.1. Normative references 315 [RFC1035] Mockapetris, P., "Domain names - implementation and 316 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 317 November 1987, . 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 321 RFC2119, March 1997, 322 . 324 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 325 Resilient against Forged Answers", RFC 5452, DOI 10.17487/ 326 RFC5452, January 2009, 327 . 329 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 330 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 331 RFC6891, April 2013, 332 . 334 8.2. Informative references 336 [Fragment-Poisonous] 337 Herzberg, A. and H. Shulman, "Fragmentation Considered 338 Poisonous", 2012. 340 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 341 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 342 DOI 10.17487/RFC5226, May 2008, 343 . 345 Appendix A. Checksum algorithms 347 The ALGORITHM field as specified in Section 3 identifies the checksum 348 algorithm that is used to compute the checksum digest for a DNS 349 message. 351 The following table lists the currently defined checksum algorithm 352 types. Candidate checksum algorithms that are chosen for inclusion 353 in this list MUST be one-way cryptographic hash functions that may be 354 used by a client to securely verify a short-lived DNS message with a 355 maximum message size constraint of 64 KiB. 357 +----------+-------+-----------+-------------------------------+ 358 | Value(s) | Name | Length | Status, Remarks | 359 +----------+-------+-----------+-------------------------------+ 360 | 0 | EMPTY | 0 octets | Empty digest (query only) | 361 | 1 | SHA-1 | 20 octets | Mandatory | 362 | 2-239 | | | Unassigned | 363 | 240-254 | | | Reserved for experimental use | 364 | 255 | | | Reserved | 365 +----------+-------+-----------+-------------------------------+ 367 Appendix B. Change history (to be removed before publication) 369 o draft-muks-dnsop-dns-message-checksums-01 370 Reduced NONCE field to 8 bytes. Reduced ALGORITHM field to 1 371 byte. Added note about risk of downgrade attack. Expanded IANA 372 considerations section and algorithms appendix. Described 373 behaviors further. Added notes on picking a suitable checksum 374 algorithm. Updated cross references, language and grammar. 376 o draft-muks-dnsop-dns-message-checksums-00 377 Initial draft (renamed version). Removed the NONCE-COPY field as 378 it is no longer necessary. Doubled the size of the NONCE field to 379 128 bits. Added sample checksum algorithms. Fixed incorrect 380 reference, language and grammar. 382 Author's Address 384 Mukund Sivaraman 385 Internet Systems Consortium 386 950 Charter Street 387 Redwood City, CA 94063 388 US 390 Email: muks@mukund.org 391 URI: http://www.isc.org/