idnits 2.17.1 draft-muks-dns-message-checksums-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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 27, 2015) is 3134 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 September 27, 2015 5 Expires: March 30, 2016 7 DNS message checksums 8 draft-muks-dns-message-checksums-00 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 March 30, 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 . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2.3. DIGEST . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2.4. NONCE-COPY . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Presentation format . . . . . . . . . . . . . . . . . . . 5 60 4. Checksum computation . . . . . . . . . . . . . . . . . . . . 5 61 5. Effects of using checksums . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Checksum algorithms . . . . . . . . . . . . . . . . 7 66 Appendix B. Change History (to be removed before publication) . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 [RFC1035] describes how DNS messages are to be transmitted over UDP. 72 A DNS query message is transmitted using one UDP datagram from client 73 to server, and a corresponding DNS reply message is transmitted using 74 one UDP datagram from server to client. 76 As a UDP datagram is transmitted in a single IP PDU, in theory the 77 size of a UDP datagram (including various lower internet layer 78 headers) can be as large as 64 KiB. But practically, if the datagram 79 size exceeds the path MTU, then the datagram will either be 80 fragmented at the IP layer, or dropped by a forwarder. In the case 81 of IPv4, DNS datagrams may be fragmented by a sender or a forwarder. 82 In the case of IPv6, DNS datagrams are fragmented by the sender only. 84 IP-layer fragmentation for large DNS response datagrams introduce 85 risk of cache poisoning by off-path attackers [Fragment-Poisonous] in 86 which an attacker can circumvent some defense mechanisms like port, 87 IP, and query randomization [RFC5452]. 89 This memo introduces the concept of a DNS message checksum which may 90 be used to stop the effects of such off-path attacks. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. DNS message checksum method 98 Clients supporting DNS message checksums add an EDNS option to their 99 queries, which declares their support for this feature. 101 The CHECKSUM EDNS option contains 4 fields: NONCE, ALGORITHM, DIGEST, 102 and NONCE-COPY. These fields are described in Section 3. 104 It is OPTIONAL for a client to add a CHECKSUM EDNS option to DNS 105 query messages. If it adds such an option, it MUST set the NONCE 106 field to a random 64-bit unsigned integer. The ALGORITHM field MUST 107 be set to 0 and the DIGEST field MUST be left empty. The NONCE field 108 MUST be randomly generated (i.e., in no predictable sequence) for 109 each query for which the client uses a CHECKSUM EDNS option. The 110 NONCE-COPY field MUST be set identical to the value in the NONCE 111 field. The client is expected to remember the per-query NONCE 112 field's value to be used in verifying the reply to this query 113 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 described in 125 Section 3. The NONCE-COPY field MUST be set identical to the value 126 in the NONCE field. The server is at liberty to choose any checksum 127 algorithm it wants to. A list of algorithms is given in Appendix A. 129 When a client receives a reply message for which it sent a CHECKSUM 130 EDNS option in the corresponding query, it SHOULD look for the 131 presence of the CHECKSUM EDNS option in the reply. The client may 132 handle the lack of a CHECKSUM EDNS option in the reply as it chooses 133 to. 135 If a CHECKSUM EDNS option is present in the reply, the client SHOULD 136 first check and ensure that both the NONCE and NONCE-COPY fields 137 contain the same nonce value that was sent in the corresponding query 138 message. If the nonce is different in either of these two fields, 139 the reply message MUST be discarded. Afterwards, the client SHOULD 140 proceed to compute a checksum over the reply message as described in 141 Section 4 using the checksum algorithm in the ALGORITHM field. It 142 SHOULD then compare the checksum value with the value that was 143 received in the DIGEST field for equality. If they are not equal, 144 the reply message MUST be discarded. If they are equal, the reply 145 message can be used normally as the client intends to use it. 147 3. The CHECKSUM EDNS(0) option 149 CHECKSUM is an EDNS(0) [RFC6891] option that is used to transmit a 150 digest of a DNS message in replies. Its use described in a previous 151 section. Here, its syntax is provided. 153 3.1. Wire format 155 The following describes the wire format of the OPTION-DATA field 156 [RFC6891] of the CHECKSUM EDNS option. All CHECKSUM option fields 157 must be represented in network byte order. 159 +--------------+------------------+--------------------+ 160 | Option field | Type | Field size | 161 +--------------+------------------+--------------------+ 162 | NONCE | unsigned integer | 64 bits (8 octets) | 163 | ALGORITHM | unsigned integer | 16 bits (2 octets) | 164 | DIGEST | byte array | Variable length | 165 | NONCE-COPY | unsigned integer | 64 bits (8 octets) | 166 +--------------+------------------+--------------------+ 168 3.2. Option fields 170 3.2.1. NONCE 172 The NONCE field is represented as an unsigned 64-bit integer in 173 network byte order. It MUST be randomly computed for each query 174 message which a client sends out, and is copied verbatim from the 175 query to the corresponding reply DNS message by the server. 177 3.2.2. ALGORITHM 179 The ALGORITHM field is represented as an unsigned 16-bit integer in 180 network byte order. In query messages, it MUST be set to 0. In 181 reply messages, it MUST contain the numeric value of the algorithm 182 used to compute the DIGEST field. A list of algorithms and their 183 values is given in Appendix A. 185 3.2.3. DIGEST 187 The DIGEST field is represented as a sequence of octets present after 188 the NONCE and ALGORITHM fields. Its size is implicitly computed from 189 the value in the OPTION-LENGTH field [RFC6891] for the CHECKSUM EDNS 190 option minus the size of the NONCE, ALGORITHM and NONCE-COPY fields. 192 In query messages, it MUST be empty. In reply messages, it MUST 193 contain the digest of the reply message which is computed as 194 described in Section 3. 196 3.2.4. NONCE-COPY 198 The NONCE-COPY field is represented as an unsigned 64-bit integer in 199 network byte order. Its value MUST be set to be identical to the 200 NONCE field. 202 3.3. Presentation format 204 As with other EDNS(0) options, the CHECKSUM EDNS option does not have 205 a presentation format. 207 4. Checksum computation 209 The NONCE and NONCE-COPY fields are present on either side of the 210 DIGEST field on purpose, so that an IP-layer PDU fragment will 211 contain both the DIGEST (in full or part) and at least one of NONCE 212 or NONCE-COPY fields. Suitable checksum algorithms MUST be chosen so 213 that the DIGEST field is not so large that this property is violated. 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 and NONCE-COPY fields MUST 222 be set to the value of the nonce from the query DNS message. The 223 ALGORITHM field MUST be set to the checksum algorithm intended to be 224 used. After this, the whole message contents (from the start of the 225 DNS message header onwards) must be input to the checksum algorithm 226 and the calculated checksum must be patched into the DIGEST field, 227 space for 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. Effects of using checksums 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 strong cryptographic methods for this case. 249 Checksum computation may increase resource usage on servers and 250 clients. It is thus desirable to use fast checksum algorithms which 251 provide ample security to verify a short-lived DNS message. 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 As a side-effect of using checksums, resolver cache poisoning attacks 258 are made more difficult due to the presence of the NONCE field. 260 6. IANA Considerations 262 The CHECKSUM EDNS(0) option requires an option code to be assigned 263 for it. Checksum algorithms in Appendix A need to be registered as 264 well. 266 7. Acknowledgements 268 TBD. 270 8. References 272 [Fragment-Poisonous] 273 Herzberg, A. and H. Shulman, "Fragmentation Considered 274 Poisonous", 2012. 276 [RFC1035] Mockapetris, P., "Domain names - implementation and 277 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 278 November 1987, . 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 282 RFC2119, March 1997, 283 . 285 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 286 Resilient against Forged Answers", RFC 5452, DOI 10.17487/ 287 RFC5452, January 2009, 288 . 290 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 291 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 292 RFC6891, April 2013, 293 . 295 Appendix A. Checksum algorithms 297 TBD. This section will list checksum algorithms in a later version 298 of the draft, after discussion. 300 Appendix B. Change History (to be removed before publication) 302 o draft-muks-dns-message-checksums-00 303 Initial draft. 305 Author's Address 307 Mukund Sivaraman 308 Internet Systems Consortium 309 950 Charter Street 310 Redwood City, CA 94063 311 US 313 Email: muks@isc.org 314 URI: http://www.isc.org/