idnits 2.17.1 draft-ietf-dprive-padding-policy-04.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 (February 6, 2018) is 2269 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 February 6, 2018 5 Expires: August 10, 2018 7 Padding Policy for EDNS(0) 8 draft-ietf-dprive-padding-policy-04 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 August 10, 2018. 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 . . . . . . . . . . . . . . . . . . 3 57 4.2. Maximal Length Padding ('The Full Monty') . . . . . . . . 4 58 4.3. Random Length Padding . . . . . . . . . . . . . . . . . . 4 59 4.4. Random Block Length Padding . . . . . . . . . . . . . . . 5 60 5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. draft-ietf-dprive-padding-policy-04 . . . . . . . . . . . 7 66 9.2. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 7 67 9.3. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 7 68 9.4. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 7 69 9.5. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 7 70 9.6. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 10.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Non-sensible Padding Policies . . . . . . . . . . . 8 75 A.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 8 76 A.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 [RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0)) 82 "Padding" option, which allows DNS clients and servers to 83 artificially increase the size of a DNS message by a variable number 84 of bytes, hampering size-based correlation of encrypted DNS messages. 86 However, RFC 7830 deliberately does not specify the actual length of 87 padding to be used. This memo discusses options regarding the actual 88 size of padding, lists advantages and disadvantages of each of these 89 "Padding Strategies", and provides a recommended (experimental) 90 strategy. 92 Padding DNS messages is useful only when transport is encrypted, 93 using protocols such as DNS over Transport Layer Security [RFC7858], 94 DNS over Datagram Transport Layer Security [RFC8094] or other 95 encrypted DNS transports specified in the future. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 [RFC2119]. 104 3. General Guidance 106 EDNS(0) options space: The maximum message length as dictated by 107 protocol limitation limits the space for EDNS(0) options. Since 108 padding will reduce the message space available to other EDNS(0) 109 options, "Padding" MUST be the last EDNS(0) option applied before a 110 DNS message is sent. 112 Resource Conservation: Especially in situations where networking and 113 processing resources are scarce (eg. battery powered long-life 114 devices, low bandwidth or high cost links), the tradeoff between 115 increased size of padded DNS messages and the corresponding gain in 116 confidentiality must be carefully considered. 118 Transport Protocol Independence: The message size used as input to 119 the various padding strategies MUST be calculated excluding the 120 potential extra 2-octet length field used in TCP transport. 121 Otherwise, the padded (observable) size of the DNS packets could 122 signifcantly change between different transport protocols, and reveal 123 an indication of the original (unpadded) length. For example, given 124 a "Block Length" padding strategy with a block length of 32 octets, 125 and a DNS message with a size of 59 octets, the message would be 126 padded to 64 octets when transported over UDP. If that same message 127 was transported over TCP, and the padding strategy would consider the 128 extra 2 octects of the length field (61 octets in total), the padded 129 message would be 96 octets long (as the minimum length of the Padding 130 option is 4 octets). 132 4. Padding Strategies 134 This section is a non-exhaustive list of sensible strategies in 135 choosing padding length. Note that, for completeness, Appendix A 136 contains two more (non-sensible) strategies. 138 4.1. Block Length Padding 140 In Block Length Padding, a sender pads each message so that its 141 padded length is a multiple of a chosen block length. This creates a 142 greatly reduced variety of message lengths. An implementor needs to 143 consider that even the zero-length EDNS(0) Padding Option increases 144 the length of the packet by 4 octets. 146 Options: Block Length - values between 16 and 128 octets for the 147 queries seem reasonable, responses will require larger block sizes 148 (see [dkg-padding-ndss] and Section 5 for a discussion). 150 Very large block lengths will have confidentiality properties similar 151 to the "Maximum Length Padding" strategy (Section 4.2), since almost 152 all messages will fit into a single block. In that case, reasonable 153 values may be 288 bytes for the query (the maximum size of a one- 154 question query over TCP, without any EDNS(0) options), and the 155 EDNS(0) buffer size of the server for the responses. 157 Advantages: This policy is reasonably easy to implement, reduces the 158 variety of message ("fingerprint") sizes significantly, and does not 159 require a source of (pseudo) random numbers, since the padding length 160 required can be derived from the actual (unpadded) message. 162 Disadvantage: Given an unpadded message and the block size of the 163 padding (which is assumed to be public knowledge once a server is 164 reachable), the size of a padded message can be predicted. 165 Therefore, minimum and maximum length of the unpadded message are 166 known. 168 Block Length Padding is the currently RECOMMENDED strategy (see 169 Section 5). 171 4.2. Maximal Length Padding ('The Full Monty') 173 In Maximal Length Padding the sender pads every message to the 174 maximum size as allowed by protocol negotiations. 176 Advantages: Maximal Length Padding, when combined with encrypted 177 transport, provides the highest possible level of message size 178 confidentiality. 180 Disadvantages: Maximal Length Padding is wasteful, and requires 181 resources on the client, all intervening network and equipment, and 182 the server. 184 Maximal Length Padding is NOT RECOMMENDED. 186 4.3. Random Length Padding 188 When using Random Length Padding, a sender pads each message with a 189 random amount of padding. Due to the size of the EDNS(0) Padding 190 Option itself, each message size is hence increased by at least 4 191 octets. The upper limit for pading is the maximum message size. 192 However, a client or server may choose to impose a lower maximum 193 padding length. 195 Options: Maximum and minimum padding length. 197 Advantages: Theoretically, this policy should create a natural 198 "distribution" of message sizes. 200 Disadvantage: This policy requires a good source of (pseudo) which 201 can keep up with the required message rates. Especially on busy 202 servers, this may be a hindrance. 204 According to the limited empirical data available, Random Length 205 Padding performs slightly worse than Block Length Padding. 207 4.4. Random Block Length Padding 209 This policy combines Block Length Padding with a random component. 210 Specifically, a sender randomly chooses between a few block length 211 values and then applies Block Length Padding based on the chosen 212 block length. The random selection of block length might even be 213 reasonably based on a "weak" source of randomness, such as the 214 transction ID of the message. 216 Options: Number of and the values for the set of Block Lengths, 217 source of "randomness" 219 Advantages: Compared to Block Length Padding, this creates more 220 variety in the resulting message sizes for a certain individual 221 original message length. Also, compared to "Random Length Padding", 222 it might not require a "full blown" random number source. 224 Disadvantage: Requires more implementation effort compared to simple 225 Block Length Padding 227 Random Block Length Padding (as other combinations of padding 228 strategies) requires further empirical study. 230 5. Recommended Strategy 232 Based on empirical research performed by Daniel K. Gillmor 233 [dkg-padding-ndss], EDNS Padding SHOULD be performed as follows: 235 (1) Clients SHOULD pad queries to the closest multiple of 128 236 octets. 238 (2) If a Server receives a query that includes the EDNS(0) Padding 239 Option, it MUST pad the corresponding response (See Section 4 of 240 RFC7830) and SHOULD pad the corresponding response to a multiple 241 of 468 octects. 243 Note that the recommendation above does apply only if DNS transport 244 is encrypted (See Section 6 of RFC 7830). 246 The empirical research cited above performed a simulation of padding, 247 based on real-world DNS traffic captured on busy recursive resolvers 248 of a research network. The evaluation of the performance of 249 individual padding policies was based on a "cost to attacker" and 250 "cost to defender" function, where the "cost to attacker" was defined 251 as the percentage of query/response pairs falling into the same size 252 bucket, and "cost to defender" as the size factor between padded and 253 unpadded messages. Padding with a block size of 128 bytes on the 254 query side, and 468 bytes on the response side was considered the 255 optimum trade-off between defender and attacker cost. The response 256 block size of 468 was chosen so that 3 blocks of 468 octets would 257 still comfortably fit into typical MTU values. 259 Note: Once DNSSEC validating clients become more prevalent, observed 260 size patterns are expected to change significantly. In such case, 261 the recommended strategy might need to be revisited. 263 6. Acknowledgements 265 Daniel K. Gillmor performed empirical research out of which the 266 "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo 267 Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman 268 performed reviews and provided substantial comments. 270 7. IANA Considerations 272 This document has no considerations for IANA. 274 8. Security Considerations 276 The choice of the right padding policy (and the right parameters for 277 the chosen policy) has a significant impact on the resilience of 278 encrypted DNS against size-based correlation attacks. Therefore, any 279 implementor of EDNS(0) Padding must carefully consider which policies 280 to implement, the default policy chosen, which parameters to make 281 configurable, and the default parameter values. 283 No matter how carefully a client selects their Padding policy, this 284 effort can be jeopardized if the server chooses to apply an 285 inffective Padding policy to the corresponding response packets. 286 Therefore, a client applying Padding may want to choose a DNS server 287 which does apply at least an equally effective Padding policy on 288 responses. 290 Note that even with encryption and padding, it might be trivial to 291 identify that the observed traffic is DNS. Also, padding does not 292 prevent information leak via other side channels (particularly timing 293 information and number of query/response pairs). Counter-measures 294 against such other side channels could include injecting artificial 295 "cover traffic" into the stream of DNS messages, or delaying DNS 296 responses by a certain amount of jitter. Such strategies are out of 297 scope of this document. Additionally, there is neither enough 298 theoretic analysis nor experimental data available to recommend any 299 such countermeasures. 301 9. Changes 303 [Note to RFC Editors: This whole section is to be removed before 304 publication] 306 9.1. draft-ietf-dprive-padding-policy-04 308 Changes based on WGLC: Changed implementor consideration text in 309 Security Con section (Sara), moved "No Padding" and "Fixed Length 310 Padding" to appendix (Stephane, Paul), Changed TODO in Random Padding 311 to info from empirical study (Stephen), Added note to pad only if 312 transport encrypted (Stephen), added intro text referencing to 313 DNSoTLS and DNSoDTLS (Stephane), added text about timing/jitter to 314 security considerations. 316 9.2. draft-ietf-dprive-padding-policy-03 318 Editorial changes in various spots. Added text about excluding TCP 319 length field, more security considerations, addressing Sara's other 320 feedback to -02. 322 9.3. draft-ietf-dprive-padding-policy-02 324 Changed Document Status to Experimental, added "maximum length" 325 padding policy, reworded "block length" policy, some editorial 326 changes. 328 9.4. draft-ietf-dprive-padding-policy-01 330 Some (mostly editorial) changes to text. Added "Recommendation" 331 section based on dkg's research. 333 9.5. draft-ietf-dprive-padding-policy-00 335 Initial (mostly unmodified) WG version. Changed "Profile" to 336 "Policy" to avoid confusion with the (D)TLS profiles document. 338 9.6. draft-mayrhofer-dprive-padding-profiles-00 340 Initial version 342 10. References 344 10.1. Normative References 346 [dkg-padding-ndss] 347 Gillmor, D., "Empirical DNS Padding Policy", March 2017, 348 . 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 357 DOI 10.17487/RFC7830, May 2016, 358 . 360 10.2. Informative References 362 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 363 and P. Hoffman, "Specification for DNS over Transport 364 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 365 2016, . 367 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 368 Transport Layer Security (DTLS)", RFC 8094, 369 DOI 10.17487/RFC8094, February 2017, 370 . 372 Appendix A. Non-sensible Padding Policies 374 A.1. No Padding 376 In the "No Padding" policy, the EDNS0 Padding option is not used, and 377 the size of the final (actually, "non-padded") message obviously 378 exactly matches the size of the unpadded message. Even though this 379 "non-policy" seems redundant in this list, its properties must be 380 considered for cases where just one of the parties (client or server) 381 applies padding. 383 Also, this "policy" is required when the remaining message size of 384 the unpadded message does not allow for the Padding option to be 385 included (less than 4 octets left). 387 Advantages: This "policy" requires no additional resources on client, 388 server and network side. 390 Disadvantages: The original size of the message remains unchanged, 391 hence this approach provides no additional confidentiality. 393 "No Padding" MUST NOT be used unless message size disallows the use 394 of Padding. 396 A.2. Fixed Length Padding 398 In fixed length padding, a sender chooses to pad each message with a 399 padding of constant length. 401 Options: Actual length of padding 403 Advantages: Since the padding is constant in length, this policy is 404 very easy to implement, and at least ensures that the message length 405 diverges from the length of the original packet (even only by a fixed 406 value) 408 Disadvantage: Obviously, the amount of padding easily discoverable 409 from a single unencrypted message, or by observing message patterns. 410 When a public DNS server applies this policy, the length of the 411 padding hence must be assumed to be public knowledge. Therefore, 412 this policy is (almost) as useless as the "No Padding" option 413 described above. 415 "Fixed Length Padding" MUST NOT be used except for experimental 416 applications. 418 Author's Address 420 Alexander Mayrhofer 421 nic.at GmbH 422 Karlsplatz 1/2/9 423 Vienna 1010 424 Austria 426 Email: alex.mayrhofer.ietf@gmail.com 427 URI: http://edns0-padding.org/