idnits 2.17.1 draft-andrews-dnsop-defeat-frag-attack-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2019) is 1761 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) -- Looks like a reference, but probably isn't: '1' on line 191 ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4635 (Obsoleted by RFC 8945) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Intended status: Standards Track July 2, 2019 5 Expires: January 3, 2020 7 Defeating DNS/UDP Fragmentation Attacks 8 draft-andrews-dnsop-defeat-frag-attack-00 10 Abstract 12 It is possible to force a DNS server to fragment its response such 13 that a fragmentation reassembly attack can insert records into the 14 response. This document uses TSIG with a well known key to defeat 15 such attacks. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. The Well Known Key . . . . . . . . . . . . . . . . . . . . . 3 53 3. Using The Well Known Key . . . . . . . . . . . . . . . . . . 3 54 4. Old Servers . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 58 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 Appendix A. Configuring Servers to support the Well Known TSIG 60 Key . . . . . . . . . . . . . . . . . . . . . . . . 5 61 A.1. BIND 9 . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 A.2. Other Vendors . . . . . . . . . . . . . . . . . . . . . . 5 63 Appendix B. Configuring Recursive Servers to send the Well Known 64 TSIG Key . . . . . . . . . . . . . . . . . . . . . . 5 65 B.1. BIND 9 . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 B.2. Other Vendors . . . . . . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 It is possible to force a DNS server to fragment its response such 72 that a fragmentation reassembly attack can insert records into the 73 response. This document uses TSIG with a well known key to defeat 74 such attacks. 76 Using TSIG [RFC2845] with a well known key effectively adds a 77 crytographgically strong checksum to every DNS message. When 78 combined with DNS COOKIE [RFC7873] in the request, it is effectively 79 impossible to guess the correct checksum for the response. When DNS 80 COOKIE is not used, a 64 bit nonce can be added to the Other Data 81 section of the requests TSIG to achieve the same protection as it is 82 part of the data that is hashed. 84 Existing servers, that support TSIG, can be configured with the well 85 known key allowing them to answer clients that send requests with the 86 well known key. 88 Existing clients, including recursive servers, that support TSIG, can 89 be configured to send queries with the well known key for servers 90 they regularly talk to after testing to see if the server has been 91 configured with the well known key. 93 Tools, like those used to generate the Alexa 1 Million - TSIG Well 94 Know Key Handling Report (experimental) report referenced below, can 95 be used periodically to generate lists of servers that support the 96 well known TSIG key. Alternatively one can configure a server to 97 send the well known key and have a exclusion list. This would be a 98 late stage solution. 100 Signaling should be added to DHCP and RA to identify which servers 101 support the well known TSIG key. 103 This does not protect against attackers that can see the DNS 104 requests. 106 2. The Well Known Key 108 The well known key has a owner name of "." and uses HMAC-SHA256 109 [RFC4635] as its algorithm with a key of 256 zero bits. 111 Should it become necessary to roll the well known key's algorithm, an 112 updated RFC should be published with new algorithm and matching key 113 definition. The standard TSIG error response of NOTAUTH/BADALG can 114 be used to signal to try alternate algorithms. It is possible for 115 servers to support multiple algorithms simultaneously by trying each 116 in turn. Not all existing servers support trying multiple 117 algorithms/keys for the same name. 119 3. Using The Well Known Key 121 Clients should opportunistically attempt to use the well known key 122 and if they get an expected error they should fallback to not using 123 the well known key unless they have already had a successful 124 transaction using the well known key or have a priori knowledge that 125 the well known key is supported. 127 All members of a anycast cluster of servers should use the same well 128 known keys. 130 When sending a request a 64 bit nonce should be added to the TSIG 131 Other Data section to increase the entropy of the request. The TSIG 132 Other Data section currently unused in TSIG requests. 134 4. Old Servers 136 STD 13 [RFC1034] [RFC1035] compliant servers that do not support TSIG 137 will return FORMERR or ignore the TSIG in the request. 139 Old servers that support TSIG are expected to return NOTAUTH/BADKEY. 141 In practice other results are seen. The following contains the 142 results of sending a plain DNS query and the above well known key to 143 all DNS servers for the Alexa Top 1 Million sorted pairwise. It is 144 regenerated monthly. 146 Alexa 1 Million - TSIG Well Know Key Handling Report (experimental) 147 [1] 149 5. Security Considerations 151 Using TSIG as a cryptographic checksum to defeat UDP fragmentation 152 attacks requires that there is sufficient entropy in the request to 153 have enough different MACs generatated. A plain DNS query only has 154 the current time and DNS query id to provide entropy. Additional 155 entropy is added by using DNS COOKIE and/or adding a nonce to the 156 TSIG Other Data data of the request. 158 Using a well known TSIG key does not fully protect against an 159 attacker that can see the request but it reduces the attack to a 160 plain response race rather than one that allows preloading the 161 fragmentation reassembly buffers. 163 6. References 165 6.1. Normative References 167 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 168 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 169 . 171 [RFC1035] Mockapetris, P., "Domain names - implementation and 172 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 173 November 1987, . 175 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 176 Wellington, "Secret Key Transaction Authentication for DNS 177 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 178 . 180 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication 181 Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", 182 RFC 4635, DOI 10.17487/RFC4635, August 2006, 183 . 185 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 186 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 187 . 189 6.2. URIs 191 [1] https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt 193 Appendix A. Configuring Servers to support the Well Known TSIG Key 195 A.1. BIND 9 197 Add the following to named.conf. Some end-of-life versions do not 198 support HMAC-SHA256. 200 key "." { 201 algorithm hmac-sha256; 202 secret "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="; 203 }; 205 A.2. Other Vendors 207 Other DNS vendors please send me instructions for your servers. 209 Appendix B. Configuring Recursive Servers to send the Well Known TSIG 210 Key 212 B.1. BIND 9 214 Define the key as above and add multiple of the following to 215 named.conf for the servers you wish to send the well known TSIG key 216 to. 218 server { keys "."; }; 220 B.2. Other Vendors 222 Other DNS vendors please send me instructions for your servers. 224 Author's Address 226 M. Andrews 227 Internet Systems Consortium 228 950 Charter Street 229 Redwood City, CA 94063 230 US 232 Email: marka@isc.org