idnits 2.17.1 draft-ietf-dprive-padding-policy-06.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 19, 2018) is 2107 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mayrhofer 3 Internet-Draft nic.at GmbH 4 Intended status: Experimental July 19, 2018 5 Expires: January 20, 2019 7 Padding Policy for EDNS(0) 8 draft-ietf-dprive-padding-policy-06 10 Abstract 12 RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify 13 the actual padding length for specific applications. This memo lists 14 the possible options ("Padding Policies"), discusses implications of 15 each of these options, and provides a recommended (experimental) 16 option. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 20, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Block Length Padding - Recommended Strategy . . . . . . . 3 57 4.2. Other Strategies . . . . . . . . . . . . . . . . . . . . 5 58 4.2.1. Maximal Length Padding . . . . . . . . . . . . . . . 5 59 4.2.2. Random Length Padding . . . . . . . . . . . . . . . . 5 60 4.2.3. Random Block Length Padding . . . . . . . . . . . . . 6 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. draft-ietf-dprive-padding-policy-06 . . . . . . . . . . . 7 66 8.2. draft-ietf-dprive-padding-policy-05 . . . . . . . . . . . 7 67 8.3. draft-ietf-dprive-padding-policy-04 . . . . . . . . . . . 8 68 8.4. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 8 69 8.5. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 8 70 8.6. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 8 71 8.7. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 8 72 8.8. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Non-sensible Padding Policies . . . . . . . . . . . 9 77 A.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 9 78 A.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 10 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 [RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0)) 84 "Padding" option, which allows DNS clients and servers to 85 artificially increase the size of a DNS message by a variable number 86 of bytes, hampering size-based correlation of encrypted DNS messages. 88 However, RFC 7830 deliberately does not specify the actual length of 89 padding to be used. This memo discusses options regarding the actual 90 size of padding, lists advantages and disadvantages of each of these 91 "Padding Strategies", and provides a recommended (experimental) 92 strategy. 94 Padding DNS messages is useful only when transport is encrypted, 95 using protocols such as DNS over Transport Layer Security [RFC7858], 96 DNS over Datagram Transport Layer Security [RFC8094] or other 97 encrypted DNS transports specified in the future. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. General Guidance 109 EDNS(0) options space: The maximum message length as dictated by the 110 protocol limits the space for EDNS(0) options. Since padding will 111 reduce the message space available to other EDNS(0) options, 112 "Padding" MUST be the last EDNS(0) option applied before a DNS 113 message is sent. 115 Resource Conservation: Especially in situations where networking and 116 processing resources are scarce (e.g. battery powered long-life 117 devices, low bandwidth or high cost links), the tradeoff between 118 increased size of padded DNS messages and the corresponding gain in 119 confidentiality must be carefully considered. 121 Transport Protocol Independence: The message size used as input to 122 the various padding strategies MUST be calculated excluding the 123 potential extra 2-octet length field used in TCP transport. 124 Otherwise, the padded (observable) size of the DNS packets could 125 significantly change between different transport protocols, and 126 reveal an indication of the original (unpadded) length. For example, 127 given a "Block Length" padding strategy with a block length of 32 128 octets, and a DNS message with a size of 59 octets, the message would 129 be padded to 64 octets when transported over UDP. If that same 130 message was transported over TCP, and the padding strategy would 131 consider the extra 2 octets of the length field (61 octets in total), 132 the padded message would be 96 octets long (as the minimum length of 133 the Padding option is 4 octets). 135 4. Padding Strategies 137 This section contains a recommended strategy, as well as a non- 138 exhaustive list of other sensible strategies in choosing padding 139 length. Note that, for completeness, Appendix A contains two more 140 (non-sensible) strategies. 142 4.1. Block Length Padding - Recommended Strategy 144 Based on empirical research performed by Daniel K. Gillmor 145 [dkg-padding-ndss], EDNS Padding SHOULD be performed following the 146 "Block Length Padding" strategy as follows: 148 (1) Clients SHOULD pad queries to the closest multiple of 128 149 octets. 151 (2) If a Server receives a query that includes the EDNS(0) Padding 152 Option, it MUST pad the corresponding response (See Section 4 of 153 RFC7830) and SHOULD pad the corresponding response to a multiple 154 of 468 octets (see below). 156 Note that the recommendation above applies only if the DNS transport 157 is encrypted (See Section 6 of RFC 7830). 159 In Block Length Padding, a sender pads each message so that its 160 padded length is a multiple of a chosen block length. This creates a 161 greatly reduced variety of message lengths. An implementor needs to 162 consider that even the zero-length EDNS(0) Padding Option increases 163 the length of the packet by 4 octets. 165 Options: Block Length - for queries, values between 16 and 128 octets 166 were discussed before empiric research was performed. Responses will 167 require larger block sizes (see [dkg-padding-ndss] and above for a 168 discussion). 170 Very large block lengths will have confidentiality properties similar 171 to the "Maximal Length Padding" strategy (Section 4.2.1), since 172 almost all messages will fit into a single block. Such "very large 173 block length" values are 288 bytes for the query (the maximum size of 174 a one-question query over TCP, without any EDNS(0) options), and the 175 EDNS(0) buffer size of the server for the responses. 177 Advantages: This policy is reasonably easy to implement, reduces the 178 variety of message ("fingerprint") sizes significantly, and does not 179 require a source of (pseudo) random numbers, since the padding length 180 required can be derived from the actual (unpadded) message. 182 Disadvantage: Given an unpadded message and the block size of the 183 padding (which is assumed to be public knowledge once a server is 184 reachable), the size range of a padded message can be predicted. 185 Therefore, the minimum length of the unpadded message can be infered. 187 The empirical research cited above performed a simulation of padding, 188 based on real-world DNS traffic captured on busy recursive resolvers 189 of a research network. The evaluation of the performance of 190 individual padding policies was based on a "cost to attacker" and 191 "cost to defender" function, where the "cost to attacker" was defined 192 as the percentage of query/response pairs falling into the same size 193 bucket, and "cost to defender" as the size factor between padded and 194 unpadded messages. Padding with a block size of 128 bytes on the 195 query side, and 468 bytes on the response side was considered the 196 optimum trade-off between defender and attacker cost. The response 197 block size of 468 was chosen so that 3 blocks of 468 octets would 198 still comfortably fit into typical Maximum Transmission Unit (MTU) 199 size values. 201 The Block Size will interact with the MTU size. Especially for 202 length values that are a large fraction of the MTU, unless the block 203 length is chosen so that a multiple just fits into the MTU, Block 204 Padding may cause unneccessary fragmentation for UDP based delivery. 205 Also, chosing a block length larger than the MTU of course always 206 forces to always fragment. 208 Note: Once DNSSEC validating clients become more prevalent, observed 209 size patterns are expected to change significantly. In such case, 210 the recommended strategy might need to be revisited. 212 4.2. Other Strategies 214 4.2.1. Maximal Length Padding 216 In Maximal Length Padding the sender pads every message to the 217 maximum size as allowed by protocol negotiations. 219 Advantages: Maximal Length Padding, when combined with encrypted 220 transport, provides the highest possible level of message size 221 confidentiality. 223 Disadvantages: Maximal Length Padding is wasteful, and requires 224 resources on the client, all intervening network and equipment, and 225 the server. Depending on the negotiated size, this strategy will 226 commonly exceed the MTU, and then result in a consistent number of 227 fragments reducing delivery probability when datagram based transport 228 (such as UDP) is used. 230 Due to resource consumption, Maximal Length Padding is NOT 231 RECOMMENDED. 233 4.2.2. Random Length Padding 235 When using Random Length Padding, a sender pads each message with a 236 random amount of padding. Due to the size of the EDNS(0) Padding 237 Option itself, each message size is hence increased by at least 4 238 octets. The upper limit for padding is the maximum message size. 239 However, a client or server may choose to impose a lower maximum 240 padding length. 242 Options: Maximum and minimum padding length. 244 Advantages: Theoretically, this policy should create a natural 245 "distribution" of message sizes. 247 Disadvantage: Random Length padding allows an attacker who can 248 observe a large number of requests to infer the length of the 249 original value by observing the distribution of total lengths. 251 According to the limited empirical data available, Random Length 252 Padding exposes slightly more entropy to an attacker than Block 253 Length Padding. Due to that, and the risk outlined above, Random 254 Length Padding is NOT RECOMMENDED. 256 4.2.3. Random Block Length Padding 258 This policy combines Block Length Padding with a random component. 259 Specifically, a sender randomly chooses between a few block length 260 values and then applies Block Length Padding based on the chosen 261 block length. The random selection of block length might even be 262 reasonably based on a "weak" source of randomness, such as the 263 transaction ID of the message. 265 Options: Number of and the values for the set of Block Lengths, 266 source of "randomness" 268 Advantages: Compared to Block Length Padding, this creates more 269 variety in the resulting message sizes for a certain individual 270 original message length. 272 Disadvantage: Requires more implementation effort compared to simple 273 Block Length Padding 275 Random Block Length Padding (as other combinations of padding 276 strategies) requires further empirical study. 278 5. Acknowledgements 280 Daniel K. Gillmor performed empirical research out of which the 281 "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo 282 Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman, 283 Magnus Westerlund, Charlie Kaufman, Joe Clarke and Meral Shirazipour 284 performed reviews or provided substantial comments. 286 6. IANA Considerations 288 This document has no considerations for IANA. 290 7. Security Considerations 292 The choice of the right padding policy (and the right parameters for 293 the chosen policy) has a significant impact on the resilience of 294 encrypted DNS against size-based correlation attacks. Therefore, any 295 implementor of EDNS(0) Padding must carefully consider which policies 296 to implement, the default policy chosen, which parameters to make 297 configurable, and the default parameter values. 299 No matter how carefully a client selects their Padding policy, this 300 effort can be jeopardized if the server chooses to apply an 301 ineffective Padding policy to the corresponding response packets. 302 Therefore, a client applying Padding may want to choose a DNS server 303 which does apply at least an equally effective Padding policy on 304 responses. 306 Note that even with encryption and padding, it might be trivial to 307 identify that the observed traffic is DNS. Also, padding does not 308 prevent information leak via other side channels (particularly timing 309 information and number of query/response pairs). Counter-measures 310 against such other side channels could include injecting artificial 311 "cover traffic" into the stream of DNS messages, or delaying DNS 312 responses by a certain amount of jitter. Such strategies are out of 313 scope of this document. Additionally, there is neither enough 314 theoretic analysis nor experimental data available to recommend any 315 such countermeasures. 317 8. Changes 319 [Note to RFC Editors: This whole section is to be removed before 320 publication] 322 8.1. draft-ietf-dprive-padding-policy-06 324 Changes based on IESG evaluation: Removed duplicate paragraph about 325 MTU impact, switched Terminology boilerplate to RFC8174, changed text 326 regarding Random Padding, changed text regarding very large block 327 paddings, some minor edits. 329 8.2. draft-ietf-dprive-padding-policy-05 331 Changes based on outcomes of IETF-wide LC + various reviews: Meral 332 Shirazipour (Gen-ART), Charlie Kaufmann (SECDIR), Joe Clarke (OPSDIR 333 - changed document flow based on comments), 335 8.3. draft-ietf-dprive-padding-policy-04 337 Changes based on WGLC: Changed implementor consideration text in 338 Security Con section (Sara), moved "No Padding" and "Fixed Length 339 Padding" to appendix (Stephane, Paul), Changed TODO in Random Padding 340 to info from empirical study (Stephen), Added note to pad only if 341 transport encrypted (Stephen), added intro text referencing to 342 DNSoTLS and DNSoDTLS (Stephane), added text about timing/jitter to 343 security considerations. 345 8.4. draft-ietf-dprive-padding-policy-03 347 Editorial changes in various spots. Added text about excluding TCP 348 length field, more security considerations, addressing Sara's other 349 feedback to -02. 351 8.5. draft-ietf-dprive-padding-policy-02 353 Changed Document Status to Experimental, added "maximum length" 354 padding policy, reworded "block length" policy, some editorial 355 changes. 357 8.6. draft-ietf-dprive-padding-policy-01 359 Some (mostly editorial) changes to text. Added "Recommendation" 360 section based on dkg's research. 362 8.7. draft-ietf-dprive-padding-policy-00 364 Initial (mostly unmodified) WG version. Changed "Profile" to 365 "Policy" to avoid confusion with the (D)TLS profiles document. 367 8.8. draft-mayrhofer-dprive-padding-profiles-00 369 Initial version 371 9. References 373 9.1. Normative References 375 [dkg-padding-ndss] 376 Gillmor, D., "Empirical DNS Padding Policy", March 2017, 377 . 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, 382 DOI 10.17487/RFC2119, March 1997, 383 . 385 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 386 DOI 10.17487/RFC7830, May 2016, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 9.2. Informative References 395 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 396 and P. Hoffman, "Specification for DNS over Transport 397 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 398 2016, . 400 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 401 Transport Layer Security (DTLS)", RFC 8094, 402 DOI 10.17487/RFC8094, February 2017, 403 . 405 Appendix A. Non-sensible Padding Policies 407 A.1. No Padding 409 In the "No Padding" policy, the EDNS0 Padding option is not used, and 410 the size of the final (actually, "non-padded") message obviously 411 exactly matches the size of the unpadded message. Even though this 412 "non-policy" seems redundant in this list, its properties must be 413 considered for cases where just one of the parties (client or server) 414 applies padding. 416 Also, this "policy" is required when the remaining message size of 417 the unpadded message does not allow for the Padding option to be 418 included (less than 4 octets left). 420 Advantages: This "policy" requires no additional resources on client, 421 server and network side. 423 Disadvantages: The original size of the message remains unchanged, 424 hence this approach provides no additional confidentiality. 426 "No Padding" MUST NOT be used unless message size disallows the use 427 of Padding. 429 A.2. Fixed Length Padding 431 In fixed length padding, a sender chooses to pad each message with a 432 padding of constant length. 434 Options: Actual length of padding 436 Advantages: Since the padding is constant in length, this policy is 437 very easy to implement, and at least ensures that the message length 438 diverges from the length of the original packet (even only by a fixed 439 value) 441 Disadvantage: Obviously, the amount of padding easily discoverable 442 from a single unencrypted message, or by observing message patterns. 443 When a public DNS server applies this policy, the length of the 444 padding hence must be assumed to be public knowledge. Therefore, 445 this policy is (almost) as useless as the "No Padding" option 446 described above. 448 "Fixed Length Padding" MUST NOT be used except for test applications. 450 Author's Address 452 Alexander Mayrhofer 453 nic.at GmbH 454 Karlsplatz 1/2/9 455 Vienna 1010 456 Austria 458 Email: alex.mayrhofer.ietf@gmail.com 459 URI: http://edns0-padding.org/