idnits 2.17.1 draft-ietf-dprive-padding-policy-02.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 (September 27, 2017) is 2402 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 September 27, 2017 5 Expires: March 31, 2018 7 Padding Policy for EDNS(0) 8 draft-ietf-dprive-padding-policy-02 10 Abstract 12 RFC 7830 specifies the EDNS0 'Padding' option, but does not specify 13 the actual padding length for specific applications. This memo lists 14 the possible options ("Padding Policies"), discusses the implications 15 of 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 March 31, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 3 58 4.3. Block Length Padding . . . . . . . . . . . . . . . . . . 4 59 4.4. Maximal Lenth Padding ('The Full Monty') . . . . . . . . 5 60 4.5. Random Length Padding . . . . . . . . . . . . . . . . . . 5 61 4.6. Random Block Length Padding . . . . . . . . . . . . . . . 5 62 5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 9.1. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 7 68 9.2. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 7 69 9.3. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 7 70 9.4. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 7 71 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 RFC 7830 [RFC7830] specifies the Extensions Mechanisms for DNS 77 (EDNS(0)) "Padding" option, which allows DNS clients and servers to 78 artificially increase the size of a DNS message by a variable number 79 of bytes, hampering size-based correlation of encrypted DNS messages. 81 However, RFC 7830 deliberately does not specify the actual length of 82 padding to be used. This memo discusses options regarding the actual 83 size of padding, lists advantages and disadvantages of each of these 84 "Padding Strategies", and provides a recommended (experimental) 85 strategy. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in 92 [RFC2119]. 94 3. General Guidance 96 Padding DNS messages does not have any semantic impact on the DNS 97 protocol. However, the length of (possible) padding does depend on 98 the circumstances under which a DNS message is created, specifically 99 the maximum message length as dictated by protocol negotiations. 100 Since padding may frustrate the message space available to other EDNS 101 options, "Padding" MUST be the last EDNS option applied before a DNS 102 message is sent. 104 Especially in situations with scarce computing and networking 105 resources such as long-life battery powered devices, the tradeoff 106 between significantly increasing the size of DNS messages by generous 107 padding and the corresponding gain in confidentiality must be 108 carefully considered. 110 4. Padding Strategies 112 This section is a non-exhaustive list of possible strategies in 113 choosing padding length 115 4.1. No Padding 117 In the "No Padding" policy, the EDNS0 Padding option is not used, and 118 the size of the final (actually, "non-padded") message obviously 119 exactly matches the size of the unpadded message. Even though this 120 "non-policy" seems redundant in this list, its properties must be 121 considered for cases where just one of the parties (client or server) 122 applies padding. 124 Also, this "policy" is required when the remaining message size of 125 the unpadded message does not allow for the Padding option to be 126 included (less than 4 octets left). 128 Advantages: This "policy" requires no additional resources on client, 129 server and network side. 131 Disadvantages: The original size of the message remains unchanged, 132 hence this approach provides no additional confidentiality. 134 "No Padding" MUST NOT be used unless message size disallows the use 135 of Padding. 137 4.2. Fixed Length Padding 139 In fixed length padding, a sender chooses to pad each message with a 140 padding of constant length. 142 Options: Actual length of padding 144 Advantages: Since the padding is constant in length, this policy is 145 very easy to implement, and at least ensures that the message length 146 diverges from the length of the original packet (even only by a fixed 147 value) 149 Disadvantage: Obviously, the amount of padding easily discoverable 150 from a single unencrypted message, or by observing message patterns. 151 When a public DNS server applies this policy, the length of the 152 padding hence must be assumed to be public knowledge. Therefore, 153 this policy is (almost) as useless as the "No Padding" option 154 described above. 156 "Fixed Length Padding" MUST NOT be used except for experimental 157 applications. 159 4.3. Block Length Padding 161 In Block Length Padding, a sender pads each message so that its 162 padded length is a multiple of a chosen block length. This creates a 163 greatly reduced variety of message lengths. An implementor needs to 164 consider that even the zero-length EDNS0 Padding Option increases the 165 length of the packet by 4 octets. 167 Options: Block Length - values between 16 and 128 octets for the 168 queries seem reasonable, responses will require larger block sizes 169 (see [dkg-padding-ndss] and Section 5 for a discussion). 171 Very large block lengths will have confidentiality properties similar 172 to the "Maximum Length Padding" strategy (Section 4.4), since almost 173 all messages will fit into a single block. In that case, reasonable 174 values may be 288 bytes for the query (the maximum size of a one- 175 question query over TCP, without any EDNS0 options), and the EDNS 176 buffer size of the server for the responses. 178 Advantages: This policy is reasonably easy to implement, reduces the 179 variety of message ("fingerprint") sizes significantly, and does not 180 require a source of (pseudo) random numbers, since the padding length 181 required can be derived from the actual (unpadded) message. 183 Disadvantage: Given an unpadded message and the block size of the 184 padding (which is assumed to be public knowledge once a server is 185 reachable), the size of a padded message can be predicted. 186 Therefore, minimum and maximum length of the unpadded message are 187 known. 189 Block Length Padding is the currently RECOMMENDED strategy (see 190 Section 5). 192 4.4. Maximal Lenth Padding ('The Full Monty') 194 In Maximal Length Padding the sender pads every message to the 195 maximum size as allowed by protocol negotiations. 197 Advantages: Maximal Length Padding, when combined with encrypted 198 transport, provides the highest possible level of message size 199 confidentiality. 201 Disadvantages: Maximal Length Padding is wasteful, and requires 202 resources on the client, all intervening network and equipment, and 203 the server. 205 Maximal Length Padding is NOT RECOMMENDED. 207 4.5. Random Length Padding 209 When using Random Length Padding, a sender pads each message with a 210 random amount of padding. Due to the size of the EDNS0 Padding 211 Option itself, each message size is hence increased by at least 4 212 octets. The upper limit for pading is the maximum message size. 213 However, a client or server may choose to impose a lower maximum 214 padding length. 216 Options: Maximum (and eventually minimum) padding length. 218 Advantages: Theoretically, this policy should create a natural 219 "distribution" of message sizes 221 Disadvantage: This policy requires a good source of (pseudo) keeping 222 up with the required message rates. Especially on busy servers, this 223 may be a significant hindrance. 225 TODO: Recommendation - this is (at first glance) the best policy, but 226 requires significant effort 228 4.6. Random Block Length Padding 230 This policy combines Block Length Padding with a random component. 231 Specifically, a sender randomly chooses between a few block lenght'es 232 and then applies Block Length Padding based on the chosen block 233 length. The random selection of block lenght might even be 234 reasonably based on a "weak" source of randomness, such as the 235 transction ID of the message. 237 Options: Number of size of the set of Block Lengths, source of 238 "randomness" 240 Advantages: Compared to Block Length Padding, this creates more 241 variety in the resulting message sizes for a certain individual 242 original message length. Also, compared to "Random Length Padding", 243 it might not require a "full blown" random number source. 245 Disadvantage: Requires more implementation effort compared to simple 246 Block Length Padding 248 Random Block Length Padding (as other combinations of padding 249 strategies) require further empirical study. 251 5. Recommended Strategy 253 Based on empirical research performed by Daniel K. Gillmor 254 [dkg-padding-ndss], EDNS Padding SHOULD be performed as follows: 256 (1) Clients SHOULD pad queries to the closest multiple of 128 257 octets. 259 (2) If a Server sees padding in a query, it SHOULD pad the 260 corresponding response to a multiple of 468 octects. 262 The empirical research cited above performed a simulation of padding, 263 based on real-world DNS traffic captured on busy recursive resolvers 264 of a research network. The evaluation of the performance of 265 individual padding policies was based on a "cost to attacker" and 266 "cost to defender" function, where the "cost to attacker" was defined 267 as the percentage of query/response pairs falling into the same size 268 bucket, and "cost to defender" as the size factor between padded and 269 unpadded messages. Padding with a block size of 128 bytes on the 270 query side, and 468 bytes on the response side was considered the 271 optimum trade-off between defender and attacker cost. The response 272 block size of 468 was chosen so that 3 blocks of 468 octets would 273 still comfortably fit into typical MTU values. 275 6. Acknowledgements 277 Daniel K. Gillmor performed empirical research out of which the 278 "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo 279 Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman 280 performed reviews and provided substantial comments. 282 7. IANA Considerations 284 This document has no considerations for IANA. 286 8. Security Considerations 288 The choice of the right padding policy (and the right parameters for 289 the chose policy) has a significant impact on the resilience of 290 encrypted DNS against size-based correlation attacks. Therefore, any 291 implementor of EDNS0 Padding must carefully consider the chosen 292 policy and its parameters. 294 A clients carefully chosen Padding policy may be without effect if 295 the corresponding server does apply an inffective (or no) Padding 296 policy on the response packets. Therefore, a client applying Padding 297 may want to chose a DNS server which does apply at least an equally 298 effective Padding policy on responses. 300 9. Changes 302 [Note to RFC Editors: This whole section is to be removed before 303 publication] 305 9.1. draft-ietf-dprive-padding-policy-02 307 Changed Document Status to Experimental, added "maximum length" 308 padding policy, reworded "block length" policy, some editorial 309 changes. 311 9.2. draft-ietf-dprive-padding-policy-01 313 Some (mostly editorial) changes to text. Added "Recommendation" 314 section based on dkg's research. 316 9.3. draft-ietf-dprive-padding-policy-00 318 Initial (mostly unmodified) WG version. Changed "Profile" to 319 "Policy" to avoid confusion with the (D)TLS profiles document. 321 9.4. draft-mayrhofer-dprive-padding-profiles-00 323 Initial version 325 10. Normative References 327 [dkg-padding-ndss] 328 Gillmor, D., "Empirical DNS Padding Policy", March 2017, 329 . 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, 334 DOI 10.17487/RFC2119, March 1997, 335 . 337 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 338 DOI 10.17487/RFC7830, May 2016, 339 . 341 Author's Address 343 Alexander Mayrhofer 344 nic.at GmbH 345 Karlsplatz 1/2/9 346 Vienna 1010 347 Austria 349 Email: alex.mayrhofer.ietf@gmail.com