idnits 2.17.1 draft-ietf-dprive-padding-policy-03.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 (January 17, 2018) is 2289 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 January 17, 2018 5 Expires: July 21, 2018 7 Padding Policy for EDNS(0) 8 draft-ietf-dprive-padding-policy-03 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 July 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 4 58 4.3. Block Length Padding . . . . . . . . . . . . . . . . . . 4 59 4.4. Maximal Length Padding ('The Full Monty') . . . . . . . . 5 60 4.5. Random Length Padding . . . . . . . . . . . . . . . . . . 5 61 4.6. Random Block Length Padding . . . . . . . . . . . . . . . 6 62 5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 8 68 9.2. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 8 69 9.3. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 8 70 9.4. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 8 71 9.5. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 [RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0)) 78 "Padding" option, which allows DNS clients and servers to 79 artificially increase the size of a DNS message by a variable number 80 of bytes, hampering size-based correlation of encrypted DNS messages. 82 However, RFC 7830 deliberately does not specify the actual length of 83 padding to be used. This memo discusses options regarding the actual 84 size of padding, lists advantages and disadvantages of each of these 85 "Padding Strategies", and provides a recommended (experimental) 86 strategy. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 [RFC2119]. 95 3. General Guidance 97 EDNS(0) options space: The maximum message length as dictated by 98 protocol limitation limits the space for EDNS(0) options. Since 99 padding will reduce the message space available to other EDNS(0) 100 options, "Padding" MUST be the last EDNS(0) option applied before a 101 DNS message is sent. 103 Resource Conservation: Especially in situations where networking and 104 processing resources are scarce (eg. battery powered long-life 105 devices, low bandwidth or high cost links), the tradeoff between 106 increased size of padded DNS messages and the corresponding gain in 107 confidentiality must be carefully considered. 109 Transport Protocol Independence: The message size used as input to 110 the various padding strategies MUST be calculated excluding the 111 potential extra 2-octet length field used in TCP transport. 112 Otherwise, the padded (observable) size of the DNS packets could 113 signifcantly change between different transport protocols, and reveal 114 an indication of the original (unpadded) length. For example, given 115 a "Block Length" padding strategy with a block length of 32 octets, 116 and a DNS message with a size of 59 octets, the message would be 117 padded to 64 octets when transported over UDP. If that same message 118 was transported over TCP, and the padding strategy would consider the 119 extra 2 octects of the length field (61 octets in total), the padded 120 message would be 96 octets long (as the minimum length of the Padding 121 option is 4 octets). 123 4. Padding Strategies 125 This section is a non-exhaustive list of possible strategies in 126 choosing padding length. 128 4.1. No Padding 130 In the "No Padding" policy, the EDNS(0) Padding option is not used, 131 and the size of the final (actually, "non-padded") message obviously 132 exactly matches the size of the unpadded message. Even though this 133 "non-policy" seems redundant in this list, its properties must be 134 considered for cases where just one of the parties (client or server) 135 applies padding. 137 Also, this "policy" is required when the remaining message size of 138 the unpadded message does not allow for the Padding option to be 139 included (less than 4 octets left). 141 Advantages: This "policy" requires no additional resources on client, 142 server and network side. 144 Disadvantages: The original size of the message remains unchanged, 145 hence this approach provides no additional confidentiality. 147 "No Padding" MUST NOT be used unless message size disallows the use 148 of Padding. 150 4.2. Fixed Length Padding 152 In fixed length padding, a sender chooses to pad each message with a 153 padding of constant length. 155 Options: Actual length of padding 157 Advantages: Since the padding is constant in length, this policy is 158 very easy to implement, and at least ensures that the message length 159 diverges from the length of the original packet (even only by a fixed 160 value). 162 Disadvantage: Obviously, the amount of padding is easily discoverable 163 from a single unencrypted message, or by observing message patterns. 164 When a public DNS server applies this policy, the length of the 165 padding must be assumed to be public knowledge. Therefore, this 166 policy is (almost) as useless as the "No Padding" option described 167 above. 169 "Fixed Length Padding" MUST NOT be used except for experimental 170 applications. 172 4.3. Block Length Padding 174 In Block Length Padding, a sender pads each message so that its 175 padded length is a multiple of a chosen block length. This creates a 176 greatly reduced variety of message lengths. An implementor needs to 177 consider that even the zero-length EDNS(0) Padding Option increases 178 the length of the packet by 4 octets. 180 Options: Block Length - values between 16 and 128 octets for the 181 queries seem reasonable, responses will require larger block sizes 182 (see [dkg-padding-ndss] and Section 5 for a discussion). 184 Very large block lengths will have confidentiality properties similar 185 to the "Maximum Length Padding" strategy (Section 4.4), since almost 186 all messages will fit into a single block. In that case, reasonable 187 values may be 288 bytes for the query (the maximum size of a one- 188 question query over TCP, without any EDNS(0) options), and the 189 EDNS(0) buffer size of the server for the responses. 191 Advantages: This policy is reasonably easy to implement, reduces the 192 variety of message ("fingerprint") sizes significantly, and does not 193 require a source of (pseudo) random numbers, since the padding length 194 required can be derived from the actual (unpadded) message. 196 Disadvantage: Given an unpadded message and the block size of the 197 padding (which is assumed to be public knowledge once a server is 198 reachable), the size of a padded message can be predicted. 199 Therefore, minimum and maximum length of the unpadded message are 200 known. 202 Block Length Padding is the currently RECOMMENDED strategy (see 203 Section 5). 205 4.4. Maximal Length Padding ('The Full Monty') 207 In Maximal Length Padding the sender pads every message to the 208 maximum size as allowed by protocol negotiations. 210 Advantages: Maximal Length Padding, when combined with encrypted 211 transport, provides the highest possible level of message size 212 confidentiality. 214 Disadvantages: Maximal Length Padding is wasteful, and requires 215 resources on the client, all intervening network and equipment, and 216 the server. 218 Maximal Length Padding is NOT RECOMMENDED. 220 4.5. Random Length Padding 222 When using Random Length Padding, a sender pads each message with a 223 random amount of padding. Due to the size of the EDNS(0) Padding 224 Option itself, each message size is hence increased by at least 4 225 octets. The upper limit for pading is the maximum message size. 226 However, a client or server may choose to impose a lower maximum 227 padding length. 229 Options: Maximum and minimum padding length. 231 Advantages: Theoretically, this policy should create a natural 232 "distribution" of message sizes. 234 Disadvantage: This policy requires a good source of (pseudo) which 235 can keep up with the required message rates. Especially on busy 236 servers, this may be a significant hindrance. 238 TODO: Recommendation - this is (at first glance) the best policy, but 239 requires significant effort 241 4.6. Random Block Length Padding 243 This policy combines Block Length Padding with a random component. 244 Specifically, a sender randomly chooses between a few block length 245 values and then applies Block Length Padding based on the chosen 246 block length. The random selection of block length might even be 247 reasonably based on a "weak" source of randomness, such as the 248 transction ID of the message. 250 Options: Number of and the values for the set of Block Lengths, 251 source of "randomness" 253 Advantages: Compared to Block Length Padding, this creates more 254 variety in the resulting message sizes for a certain individual 255 original message length. Also, compared to "Random Length Padding", 256 it might not require a "full blown" random number source. 258 Disadvantage: Requires more implementation effort compared to simple 259 Block Length Padding 261 Random Block Length Padding (as other combinations of padding 262 strategies) requires further empirical study. 264 5. Recommended Strategy 266 Based on empirical research performed by Daniel K. Gillmor 267 [dkg-padding-ndss], EDNS(0) Padding SHOULD be performed as follows: 269 (1) Clients SHOULD pad queries to the closest multiple of 128 270 octets. 272 (2) If a Server receives a query that includes the EDNS(0) Padding 273 Option, it MUST pad the corresponding response (See Section 4 of 274 [RFC7830]) and SHOULD pad the response to a multiple of 468 275 octects. 277 The empirical research cited above performed a simulation of padding, 278 based on real-world DNS traffic captured on busy recursive resolvers 279 of a research network. The evaluation of the performance of 280 individual padding policies was based on a "cost to attacker" and 281 "cost to defender" function, where the "cost to attacker" was defined 282 as the percentage of query/response pairs falling into the same size 283 bucket, and "cost to defender" as the size factor between padded and 284 unpadded messages. Padding with a block size of 128 bytes on the 285 query side, and 468 bytes on the response side was considered the 286 optimum trade-off between defender and attacker cost. The response 287 block size of 468 was chosen so that 3 blocks of 468 octets would 288 still comfortably fit into typical MTU values. 290 Note: Once DNSSEC validating clients become more prevalent, observed 291 size patterns are expected to change significantly. In such case, 292 the recommended strategy might need to be revisited. 294 6. Acknowledgements 296 Daniel K. Gillmor performed empirical research out of which the 297 "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo 298 Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman 299 performed reviews and provided substantial comments. 301 7. IANA Considerations 303 This document has no considerations for IANA. 305 8. Security Considerations 307 The choice of the right padding policy (and the right parameters for 308 the chosen policy) has a significant impact on the resilience of 309 encrypted DNS against size-based correlation attacks. Therefore, any 310 implementor of EDNS(0) Padding must carefully consider the chosen 311 policy and its parameters. 313 No matter how carefully a client selects their Padding policy, this 314 effort can be jeopardized if the server chooses to apply an 315 inffective Padding policy to the corresponding response packets. 316 Therefore, a client applying Padding may want to choose a DNS server 317 which does apply at least an equally effective Padding policy on 318 responses. 320 Note that even with encryption and padding, it might be trivial to 321 identify that the observed traffic is DNS. Also, padding does not 322 prevent information leak via other side channels (particularly timing 323 information). 325 9. Changes 327 [Note to RFC Editors: This whole section is to be removed before 328 publication] 330 9.1. draft-ietf-dprive-padding-policy-03 332 Editorial changes in various spots. Added text about excluding TCP 333 length field, more security considerations, addressing Sara's other 334 feedback to -02. 336 9.2. draft-ietf-dprive-padding-policy-02 338 Changed Document Status to Experimental, added "maximum length" 339 padding policy, reworded "block length" policy, some editorial 340 changes. 342 9.3. draft-ietf-dprive-padding-policy-01 344 Some (mostly editorial) changes to text. Added "Recommendation" 345 section based on dkg's research. 347 9.4. draft-ietf-dprive-padding-policy-00 349 Initial (mostly unmodified) WG version. Changed "Profile" to 350 "Policy" to avoid confusion with the (D)TLS profiles document. 352 9.5. draft-mayrhofer-dprive-padding-profiles-00 354 Initial version 356 10. Normative References 358 [dkg-padding-ndss] 359 Gillmor, D., "Empirical DNS Padding Policy", March 2017, 360 . 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 369 DOI 10.17487/RFC7830, May 2016, 370 . 372 Author's Address 373 Alexander Mayrhofer 374 nic.at GmbH 375 Karlsplatz 1/2/9 376 Vienna 1010 377 Austria 379 Email: alex.mayrhofer.ietf@gmail.com