idnits 2.17.1 draft-ietf-dprive-edns0-padding-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 (March 6, 2016) is 2966 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: Standards Track March 6, 2016 5 Expires: September 7, 2016 7 The EDNS(0) Padding Option 8 draft-ietf-dprive-edns0-padding-03 10 Abstract 12 This document specifies the EDNS(0) 'Padding' option, which allows 13 DNS clients and servers to pad request and response messages by a 14 variable number of octets. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 7, 2016. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. The 'Padding' Option . . . . . . . . . . . . . . . . . . . . 3 53 4. Usage Considerations . . . . . . . . . . . . . . . . . . . . 3 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 8.1. draft-ietf-dprive-edns0-padding-03 . . . . . . . . . . . 5 59 8.2. draft-ietf-dprive-edns0-padding-02 . . . . . . . . . . . 5 60 8.3. draft-ietf-dprive-edns0-padding-01 . . . . . . . . . . . 5 61 8.4. draft-ieft-dprive-edns0-padding-00 . . . . . . . . . . . 5 62 8.5. draft-mayrhofer-edns0-padding-01 . . . . . . . . . . . . 5 63 8.6. draft-mayrhofer-edns0-padding-00 . . . . . . . . . . . . 5 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 9.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The Domain Name System (DNS) [RFC1035] was specified to transport DNS 72 messages in clear text form. Since this can expose significant 73 amounts of information about the internet activities of an end user, 74 the IETF has undertaken work to provide confidentiality to DNS 75 transactions (see the DPRIVE WG). Encrypting the DNS transport is 76 considered as one of the options to improve the situation. 78 However, even if both DNS query and response messages were encrypted, 79 meta data could still be used to correlate such messages with well 80 known unencrypted messages, hence jeopardizing some of the 81 confidentiality gained by encryption. One such property is the 82 message size. 84 This document specifies the Extensions Mechanisms for DNS (EDNS(0)) 85 "Padding" Option, which allows to artificially increase the size of a 86 DNS message by a variable number of bytes, hampering size-based 87 correlation of the encrypted message. 89 2. Terminology 91 The terms "Requestor", "Responder" are to be interpreted as specified 92 in [RFC6891]. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 [RFC2119]. 99 3. The 'Padding' Option 101 The EDNS(0) [RFC6891] specifies a mechanism to include new options in 102 DNS packets, contained in the RDATA of the OPT meta-RR. This 103 document specifies the 'Padding' option in order to allow clients and 104 servers pad DNS packets by a variable number of bytes. The 'Padding' 105 option MUST occur at most once per OPT meta-RR (and hence, at most 106 once per message). 108 The figure below specifies the structure of the option in the RDATA 109 of the OPT RR: 111 0 8 16 112 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 113 | OPTION-CODE | 114 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 115 | OPTION-LENGTH | 116 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 117 | (PADDING) ... (PADDING) ... / 118 +- - - - - - - - - - - - - - - - 120 Figure 1 122 The OPTION-CODE for the 'Padding' option is 12. 124 The OPTION-LENGTH for the 'Padding' option is the size (in octets) of 125 the PADDING. The minimum number of padding octets is 0. 127 The PADDING octets SHOULD be set to 0x00. Other values MAY be used; 128 for example, in cases where there is a concern that the padded 129 message could be subject to compression before encryption. PADDING 130 octets of any value MUST be accepted in messages received. 132 4. Usage Considerations 134 This document does not specify the actual amount of padding to be 135 used, since this depends on the situation in which the option is 136 used. However, padded DNS messages MUST NOT exceed the number of 137 octets specified in the Requestor's Payload Size field encoded in the 138 RR Class Field (see Section 6.2.3 and 6.2.4 of [RFC6891]). 140 Responders MUST pad DNS responses when the respective DNS query 141 included the 'Padding' option, unless doing so would violate the 142 maximum UDP payload size. 144 Responders MAY pad DNS responses when the respective DNS query 145 indicated EDNS(0) support of the Requestor and the 'Padding' option 146 was not included. 148 Responders MUST NOT pad DNS responses when the respective DNS query 149 did not indicate EDNS(0) support. 151 5. IANA Considerations 153 IANA has assigned EDNS Option Code 12 for Padding. 155 IANA is requested to update the respective registration record by 156 changing the Reference field to [[THISRFC]] and the Status field to 157 'Standard'. 159 6. Security Considerations 161 Padding DNS packets obviously increases their size, and will 162 therefore lead to increased traffic. 164 The use of the EDNS(0) Padding only provides a benefit when DNS 165 packets are not transported in clear text. Further, it is possible 166 EDNS(0) Padding may make DNS amplification attacks easier. 167 Implementations therefore MUST NOT use this option if the DNS 168 transport is not encrypted. 170 Padding length might be affected by lower-level compression. 171 Therefore (as described in Section 3.3 of [RFC7525]), implementations 172 and deployments SHOULD disable TLS-level compression. 174 The payload of the 'Padding' option could (like many other fields in 175 the DNS protocol) be used as a covert channel. 177 7. Acknowledgements 179 This document was inspired by a discussion with Daniel Kahn Gillmor 180 during IETF93, as an alternative to the proposed padding on the TLS 181 layer. Allison Mankin, Andreas Gustafsson, Christian Huitema, Jinmei 182 Tatuya and Shane Kerr suggested text for this document. 184 8. Changes 186 Note to RFC Editors: Please remove this whole section before 187 publication 189 8.1. draft-ietf-dprive-edns0-padding-03 191 Fixed typo in Acknowledgements, added Shane. Do not use over 192 unencrypted transport is now a MUST. Logic around when responders 193 may send the option clarified. Reduced "hampering" claim in 194 introduction. 196 8.2. draft-ietf-dprive-edns0-padding-02 198 Clarified that changes section is to be removed before publication. 199 Clarified that both Requestors and Responders are to ignore padding 200 contents. changed text about non-zero padding contents based on WGLC 201 comments. removed security considerations about truncation based on 202 WGLC comment. added more acknowledgements. replaced "packets" with 203 "messages" where appropriate. 205 8.3. draft-ietf-dprive-edns0-padding-01 207 Fixed 'octects' typo. Changed 'covert channel' text to align with 208 allowing non-0x00 padding. changed IANA considerations - assigned 209 option code is 12. Changed field definitions to allow for non-0x00 210 padding, removed FORMERR requirement. referenced rfc7525 in security 211 considerations. added acknowledgements. 213 8.4. draft-ieft-dprive-edns0-padding-00 215 Adopted by WG. Changed text about message size limit based on 216 feedback. 218 8.5. draft-mayrhofer-edns0-padding-01 220 Changed minimum padding size to 0, rewrote Usage Considerations 221 section, extended Security considerations section 223 8.6. draft-mayrhofer-edns0-padding-00 225 Initial version 227 9. References 229 9.1. Normative References 231 [RFC1035] Mockapetris, P., "Domain names - implementation and 232 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 233 November 1987, . 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, 237 DOI 10.17487/RFC2119, March 1997, 238 . 240 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 241 for DNS (EDNS(0))", STD 75, RFC 6891, 242 DOI 10.17487/RFC6891, April 2013, 243 . 245 9.2. Informative References 247 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 248 "Recommendations for Secure Use of Transport Layer 249 Security (TLS) and Datagram Transport Layer Security 250 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 251 2015, . 253 Author's Address 255 Alexander Mayrhofer 256 nic.at GmbH 257 Karlsplatz 1/2/9 258 Vienna 1010 259 Austria 261 Email: alex.mayrhofer.ietf@gmail.com