idnits 2.17.1 draft-ietf-dprive-padding-policy-05.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 (April 12, 2018) is 2177 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 April 12, 2018 5 Expires: October 14, 2018 7 Padding Policy for EDNS(0) 8 draft-ietf-dprive-padding-policy-05 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 October 14, 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 - Recommended Strategy . . . . . . . 3 57 4.2. Other Sensible 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 . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. draft-ietf-dprive-padding-policy-05 . . . . . . . . . . . 7 66 8.2. draft-ietf-dprive-padding-policy-04 . . . . . . . . . . . 7 67 8.3. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 8 68 8.4. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 8 69 8.5. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 8 70 8.6. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 8 71 8.7. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Non-sensible Padding Policies . . . . . . . . . . . 9 76 A.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 9 77 A.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 [RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0)) 83 "Padding" option, which allows DNS clients and servers to 84 artificially increase the size of a DNS message by a variable number 85 of bytes, hampering size-based correlation of encrypted DNS messages. 87 However, RFC 7830 deliberately does not specify the actual length of 88 padding to be used. This memo discusses options regarding the actual 89 size of padding, lists advantages and disadvantages of each of these 90 "Padding Strategies", and provides a recommended (experimental) 91 strategy. 93 Padding DNS messages is useful only when transport is encrypted, 94 using protocols such as DNS over Transport Layer Security [RFC7858], 95 DNS over Datagram Transport Layer Security [RFC8094] or other 96 encrypted DNS transports specified in the future. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 [RFC2119]. 105 3. General Guidance 107 EDNS(0) options space: The maximum message length as dictated by 108 protocol limitation limits the space for EDNS(0) options. Since 109 padding will reduce the message space available to other EDNS(0) 110 options, "Padding" MUST be the last EDNS(0) option applied before a 111 DNS message is sent. 113 Resource Conservation: Especially in situations where networking and 114 processing resources are scarce (e.g. battery powered long-life 115 devices, low bandwidth or high cost links), the tradeoff between 116 increased size of padded DNS messages and the corresponding gain in 117 confidentiality must be carefully considered. 119 Transport Protocol Independence: The message size used as input to 120 the various padding strategies MUST be calculated excluding the 121 potential extra 2-octet length field used in TCP transport. 122 Otherwise, the padded (observable) size of the DNS packets could 123 significantly change between different transport protocols, and 124 reveal an indication of the original (unpadded) length. For example, 125 given a "Block Length" padding strategy with a block length of 32 126 octets, and a DNS message with a size of 59 octets, the message would 127 be padded to 64 octets when transported over UDP. If that same 128 message was transported over TCP, and the padding strategy would 129 consider the extra 2 octets of the length field (61 octets in total), 130 the padded message would be 96 octets long (as the minimum length of 131 the Padding option is 4 octets). 133 4. Padding Strategies 135 This section contains a recommended strategy, as well as a non- 136 exhaustive list of other sensible strategies in choosing padding 137 length. Note that, for completeness, Appendix A contains two more 138 (non-sensible) strategies. 140 4.1. Block Length Padding - Recommended Strategy 142 Based on empirical research performed by Daniel K. Gillmor 143 [dkg-padding-ndss], EDNS Padding SHOULD be performed following the 144 "Block Length Padding" strategy as follows: 146 (1) Clients SHOULD pad queries to the closest multiple of 128 147 octets. 149 (2) If a Server receives a query that includes the EDNS(0) Padding 150 Option, it MUST pad the corresponding response (See Section 4 of 151 RFC7830) and SHOULD pad the corresponding response to a multiple 152 of 468 octets (see below). 154 Note that the recommendation above applies only if DNS transport is 155 encrypted (See Section 6 of RFC 7830). 157 In Block Length Padding, a sender pads each message so that its 158 padded length is a multiple of a chosen block length. This creates a 159 greatly reduced variety of message lengths. An implementor needs to 160 consider that even the zero-length EDNS(0) Padding Option increases 161 the length of the packet by 4 octets. 163 Options: Block Length - values between 16 and 128 octets for the 164 queries seem reasonable, responses will require larger block sizes 165 (see [dkg-padding-ndss] and above for a discussion). 167 Very large block lengths will have confidentiality properties similar 168 to the "Maximal Length Padding" strategy (Section 4.2.1), since 169 almost all messages will fit into a single block. In that case, 170 reasonable values may be 288 bytes for the query (the maximum size of 171 a one-question query over TCP, without any EDNS(0) options), and the 172 EDNS(0) buffer size of the server for the responses. 174 Advantages: This policy is reasonably easy to implement, reduces the 175 variety of message ("fingerprint") sizes significantly, and does not 176 require a source of (pseudo) random numbers, since the padding length 177 required can be derived from the actual (unpadded) message. 179 Disadvantage: Given an unpadded message and the block size of the 180 padding (which is assumed to be public knowledge once a server is 181 reachable), the size of a padded message can be predicted. 182 Therefore, minimum and maximum length of the unpadded message are 183 known. 185 The Block Size will interact with the MTU size. Especially for 186 length values that are a large fraction of the MTU, unless the block 187 length is chosen so that a multiple just fits into the MTU, Block 188 Length Padding may cause unneccessary fragmentation for UDP based 189 delivery. Also, chosing a block length larger than the MTU of course 190 forces to always fragment. 192 The empirical research cited above performed a simulation of padding, 193 based on real-world DNS traffic captured on busy recursive resolvers 194 of a research network. The evaluation of the performance of 195 individual padding policies was based on a "cost to attacker" and 196 "cost to defender" function, where the "cost to attacker" was defined 197 as the percentage of query/response pairs falling into the same size 198 bucket, and "cost to defender" as the size factor between padded and 199 unpadded messages. Padding with a block size of 128 bytes on the 200 query side, and 468 bytes on the response side was considered the 201 optimum trade-off between defender and attacker cost. The response 202 block size of 468 was chosen so that 3 blocks of 468 octets would 203 still comfortably fit into typical Maximum Transmission Unit (MTU) 204 size values. 206 The Block Size will interact with the MTU size. Especially for 207 length values that are a large fraction of the MTU, unless the block 208 length is chosen so that a multiple just fits into the MTU, Block 209 Padding may cause unneccessary fragmentation for UDP based delivery. 210 Also, chosing a block length larger than the MTU of course always 211 forces to always fragment. 213 Note: Once DNSSEC validating clients become more prevalent, observed 214 size patterns are expected to change significantly. In such case, 215 the recommended strategy might need to be revisited. 217 4.2. Other Sensible Strategies 219 4.2.1. Maximal Length Padding 221 In Maximal Length Padding the sender pads every message to the 222 maximum size as allowed by protocol negotiations. 224 Advantages: Maximal Length Padding, when combined with encrypted 225 transport, provides the highest possible level of message size 226 confidentiality. 228 Disadvantages: Maximal Length Padding is wasteful, and requires 229 resources on the client, all intervening network and equipment, and 230 the server. Depending on the negotiated size, this strategy will 231 commonly exceed the MTU, and then result in a consistent number of 232 fragments reducing delivery probability when datagram based transport 233 (such as UDP) is used. 235 Maximal Length Padding is NOT RECOMMENDED. 237 4.2.2. Random Length Padding 239 When using Random Length Padding, a sender pads each message with a 240 random amount of padding. Due to the size of the EDNS(0) Padding 241 Option itself, each message size is hence increased by at least 4 242 octets. The upper limit for padding is the maximum message size. 243 However, a client or server may choose to impose a lower maximum 244 padding length. 246 Options: Maximum and minimum padding length. 248 Advantages: Theoretically, this policy should create a natural 249 "distribution" of message sizes. 251 Disadvantage: This policy requires a good source of (pseudo) random 252 numbers which can keep up with the required message rates. 253 Especially on busy servers, this may be a hindrance. 255 According to the limited empirical data available, Random Length 256 Padding performs slightly worse than Block Length Padding. 258 4.2.3. Random Block Length Padding 260 This policy combines Block Length Padding with a random component. 261 Specifically, a sender randomly chooses between a few block length 262 values and then applies Block Length Padding based on the chosen 263 block length. The random selection of block length might even be 264 reasonably based on a "weak" source of randomness, such as the 265 transaction ID of the message. 267 Options: Number of and the values for the set of Block Lengths, 268 source of "randomness" 270 Advantages: Compared to Block Length Padding, this creates more 271 variety in the resulting message sizes for a certain individual 272 original message length. Also, compared to "Random Length Padding", 273 it might not require a "full blown" random number source. 275 Disadvantage: Requires more implementation effort compared to simple 276 Block Length Padding 278 Random Block Length Padding (as other combinations of padding 279 strategies) requires further empirical study. 281 5. Acknowledgements 283 Daniel K. Gillmor performed empirical research out of which the 284 "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo 285 Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman, 286 Magnus Westerlund, Charlie Kaufman, Joe Clarke and Meral Shirazipour 287 performed reviews or provided substantial comments. 289 6. IANA Considerations 291 This document has no considerations for IANA. 293 7. Security Considerations 295 The choice of the right padding policy (and the right parameters for 296 the chosen policy) has a significant impact on the resilience of 297 encrypted DNS against size-based correlation attacks. Therefore, any 298 implementor of EDNS(0) Padding must carefully consider which policies 299 to implement, the default policy chosen, which parameters to make 300 configurable, and the default parameter values. 302 No matter how carefully a client selects their Padding policy, this 303 effort can be jeopardized if the server chooses to apply an 304 ineffective Padding policy to the corresponding response packets. 305 Therefore, a client applying Padding may want to choose a DNS server 306 which does apply at least an equally effective Padding policy on 307 responses. 309 Note that even with encryption and padding, it might be trivial to 310 identify that the observed traffic is DNS. Also, padding does not 311 prevent information leak via other side channels (particularly timing 312 information and number of query/response pairs). Counter-measures 313 against such other side channels could include injecting artificial 314 "cover traffic" into the stream of DNS messages, or delaying DNS 315 responses by a certain amount of jitter. Such strategies are out of 316 scope of this document. Additionally, there is neither enough 317 theoretic analysis nor experimental data available to recommend any 318 such countermeasures. 320 8. Changes 322 [Note to RFC Editors: This whole section is to be removed before 323 publication] 325 8.1. draft-ietf-dprive-padding-policy-05 327 Changes based on outcomes of IETF-wide LC + various reviews: Meral 328 Shirazipour (Gen-ART), Charlie Kaufmann (SECDIR), Joe Clarke (OPSDIR 329 - changed document flow based on comments), 331 8.2. draft-ietf-dprive-padding-policy-04 333 Changes based on WGLC: Changed implementor consideration text in 334 Security Con section (Sara), moved "No Padding" and "Fixed Length 335 Padding" to appendix (Stephane, Paul), Changed TODO in Random Padding 336 to info from empirical study (Stephen), Added note to pad only if 337 transport encrypted (Stephen), added intro text referencing to 338 DNSoTLS and DNSoDTLS (Stephane), added text about timing/jitter to 339 security considerations. 341 8.3. draft-ietf-dprive-padding-policy-03 343 Editorial changes in various spots. Added text about excluding TCP 344 length field, more security considerations, addressing Sara's other 345 feedback to -02. 347 8.4. draft-ietf-dprive-padding-policy-02 349 Changed Document Status to Experimental, added "maximum length" 350 padding policy, reworded "block length" policy, some editorial 351 changes. 353 8.5. draft-ietf-dprive-padding-policy-01 355 Some (mostly editorial) changes to text. Added "Recommendation" 356 section based on dkg's research. 358 8.6. draft-ietf-dprive-padding-policy-00 360 Initial (mostly unmodified) WG version. Changed "Profile" to 361 "Policy" to avoid confusion with the (D)TLS profiles document. 363 8.7. draft-mayrhofer-dprive-padding-profiles-00 365 Initial version 367 9. References 369 9.1. Normative References 371 [dkg-padding-ndss] 372 Gillmor, D., "Empirical DNS Padding Policy", March 2017, 373 . 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 382 DOI 10.17487/RFC7830, May 2016, 383 . 385 9.2. Informative References 387 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 388 and P. Hoffman, "Specification for DNS over Transport 389 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 390 2016, . 392 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 393 Transport Layer Security (DTLS)", RFC 8094, 394 DOI 10.17487/RFC8094, February 2017, 395 . 397 Appendix A. Non-sensible Padding Policies 399 A.1. No Padding 401 In the "No Padding" policy, the EDNS0 Padding option is not used, and 402 the size of the final (actually, "non-padded") message obviously 403 exactly matches the size of the unpadded message. Even though this 404 "non-policy" seems redundant in this list, its properties must be 405 considered for cases where just one of the parties (client or server) 406 applies padding. 408 Also, this "policy" is required when the remaining message size of 409 the unpadded message does not allow for the Padding option to be 410 included (less than 4 octets left). 412 Advantages: This "policy" requires no additional resources on client, 413 server and network side. 415 Disadvantages: The original size of the message remains unchanged, 416 hence this approach provides no additional confidentiality. 418 "No Padding" MUST NOT be used unless message size disallows the use 419 of Padding. 421 A.2. Fixed Length Padding 423 In fixed length padding, a sender chooses to pad each message with a 424 padding of constant length. 426 Options: Actual length of padding 428 Advantages: Since the padding is constant in length, this policy is 429 very easy to implement, and at least ensures that the message length 430 diverges from the length of the original packet (even only by a fixed 431 value) 432 Disadvantage: Obviously, the amount of padding easily discoverable 433 from a single unencrypted message, or by observing message patterns. 434 When a public DNS server applies this policy, the length of the 435 padding hence must be assumed to be public knowledge. Therefore, 436 this policy is (almost) as useless as the "No Padding" option 437 described above. 439 "Fixed Length Padding" MUST NOT be used except for experimental 440 applications. 442 Author's Address 444 Alexander Mayrhofer 445 nic.at GmbH 446 Karlsplatz 1/2/9 447 Vienna 1010 448 Austria 450 Email: alex.mayrhofer.ietf@gmail.com 451 URI: http://edns0-padding.org/