idnits 2.17.1 draft-ietf-dprive-edns0-padding-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 (January 25, 2016) is 3008 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 January 25, 2016 5 Expires: July 28, 2016 7 The EDNS(0) Padding Option 8 draft-ietf-dprive-edns0-padding-02 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 July 28, 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-02 . . . . . . . . . . . 4 59 8.2. draft-ietf-dprive-edns0-padding-01 . . . . . . . . . . . 5 60 8.3. draft-ieft-dprive-edns0-padding-00 . . . . . . . . . . . 5 61 8.4. draft-mayrhofer-edns0-padding-01 . . . . . . . . . . . . 5 62 8.5. draft-mayrhofer-edns0-padding-00 . . . . . . . . . . . . 5 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 9.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 The Domain Name System (DNS) [RFC1035] was specified to transport DNS 71 messages in clear text form. Since this can expose significant 72 amounts of information about the internet activities of an end user, 73 the IETF has undertaken work to provide confidentiality to DNS 74 transactions (see the DPRIVE WG). Encrypting the DNS transport is 75 considered as one of the options to improve the situation. 77 However, even if both DNS query and response messages were encrypted, 78 meta data of could still be used to correlate such messages with well 79 known unencrypted messages, hence jeopardizing some of the 80 confidentiality gained by encryption. One such property is the 81 message size. 83 This document specifies the Extensions Mechanisms for DNS (EDNS(0)) 84 "Padding" Option, which allows to artificially increase the size of a 85 DNS message by a variable number of bytes, significantly hampering 86 size-based correlation of the encrypted message. 88 2. Terminology 90 The terms "Requestor", "Responder" are to be interpreted as specified 91 in [RFC6891]. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 [RFC2119]. 98 3. The 'Padding' Option 100 The EDNS(0) [RFC6891] specifies a mechanism to include new options in 101 DNS packets, contained in the RDATA of the OPT meta-RR. This 102 document specifies the 'Padding' option in order to allow clients and 103 servers pad DNS packets by a variable number of bytes. The 'Padding' 104 option MUST occur at most once per OPT meta-RR (and hence, at most 105 once per message). 107 The figure below specifies the structure of the option in the RDATA 108 of the OPT RR: 110 0 8 16 111 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 112 | OPTION-CODE | 113 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 114 | OPTION-LENGTH | 115 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 116 | (PADDING) ... (PADDING) ... / 117 +- - - - - - - - - - - - - - - - 119 Figure 1 121 The OPTION-CODE for the 'Padding' option is 12. 123 The OPTION-LENGTH for the 'Padding' option is the size (in octets) of 124 the PADDING. The minimum number of padding octets is 0. 126 The PADDING octets SHOULD be set to 0x00. Other values MAY be used; 127 for example, in cases where there is a concern that the padded 128 message could be subject to compression before encryption. PADDING 129 octets of any value MUST be accepted in messages received. 131 4. Usage Considerations 133 This document does not specify the actual amount of padding to be 134 used, since this depends on the situation in which the option is 135 used. However, padded DNS messages MUST NOT exceed the number of 136 octets specified in the Requestor's Payload Size field encoded in The 137 RR Class Field (see Section 6.2.3 and 6.2.4 of [RFC6891]). 139 Responders MUST pad DNS responses when the respective DNS query 140 included the 'Padding' option, unless doing so would violate the 141 maximum UDP payload size. 143 Responders MAY pad DNS responses when the respective DNS query 144 indicated EDNS(0) support of the Requestor. 146 Responders MUST NOT pad DNS responses when the respective DNS query 147 did not indicate EDNS(0). 149 5. IANA Considerations 151 IANA has assigned EDNS Option Code 12 for Padding. 153 IANA is requested to update the respective registration record by 154 changing the Reference field to [[THISRFC]] and the Status field to 155 'Standard'. 157 6. Security Considerations 159 Padding DNS packets obviously increases their size, and will 160 therefore lead to increased traffic. 162 The use of the EDNS(0) Padding provides only a benefit when DNS 163 packets are not transported in clear text. Implementations therefore 164 SHOULD avoid using this option if the DNS transport is not encrypted. 166 Padding length might be affected by lower-level compression. 167 Therefore (as described in Section 3.3 of [RFC7525]), implementations 168 and deployments SHOULD disable TLS-level compression. 170 The payload of the 'Padding' option could (like many other fields in 171 the DNS protocol) be used as a covert channel. 173 7. Acknowledgements 175 This document was inspired by a discussion with Daniel Kahn Gillmor 176 during IETF93, as an alternative to the proposed padding on the TLS 177 layer. Allison Mankin, Andreas Gustaffson, Christian Huitema and 178 Jinmei Tatuya suggested text for this document. 180 8. Changes 182 Note to RFC Editors: Please remove this whole section before 183 publication 185 8.1. draft-ietf-dprive-edns0-padding-02 187 Clarified that changes section is to be removed before publication. 188 Clarified that both Requestors and Responders are to ignore padding 189 contents. changed text about non-zero padding contents based on WGLC 190 comments. removed security considerations about truncation based on 191 WGLC comment. added more acknowledgements. replaced "packets" with 192 "messages" where appropriate. 194 8.2. draft-ietf-dprive-edns0-padding-01 196 Fixed 'octects' typo. Changed 'covert channel' text to align with 197 allowing non-0x00 padding. changed IANA considerations - assigned 198 option code is 12. Changed field definitions to allow for non-0x00 199 padding, removed FORMERR requirement. referenced rfc7525 in security 200 considerations. added acknowledgements. 202 8.3. draft-ieft-dprive-edns0-padding-00 204 Adopted by WG. Changed text about message size limit based on 205 feedback. 207 8.4. draft-mayrhofer-edns0-padding-01 209 Changed minimum padding size to 0, rewrote Usage Considerations 210 section, extended Security considerations section 212 8.5. draft-mayrhofer-edns0-padding-00 214 Initial version 216 9. References 218 9.1. Normative References 220 [RFC1035] Mockapetris, P., "Domain names - implementation and 221 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 222 November 1987, . 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, 226 DOI 10.17487/RFC2119, March 1997, 227 . 229 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 230 for DNS (EDNS(0))", STD 75, RFC 6891, 231 DOI 10.17487/RFC6891, April 2013, 232 . 234 9.2. Informative References 236 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 237 "Recommendations for Secure Use of Transport Layer 238 Security (TLS) and Datagram Transport Layer Security 239 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 240 2015, . 242 Author's Address 244 Alexander Mayrhofer 245 nic.at GmbH 246 Karlsplatz 1/2/9 247 Vienna 1010 248 Austria 250 Email: alex.mayrhofer.ietf@gmail.com