idnits 2.17.1 draft-ietf-dprive-edns0-padding-01.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 (November 24, 2015) is 3076 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 November 24, 2015 5 Expires: May 27, 2016 7 The EDNS(0) Padding Option 8 draft-ietf-dprive-edns0-padding-01 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 May 27, 2016. 33 Copyright Notice 35 Copyright (c) 2015 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-01 . . . . . . . . . . . 4 59 8.2. draft-ieft-dprive-edns0-padding-00 . . . . . . . . . . . 5 60 8.3. draft-mayrhofer-edns0-padding-01 . . . . . . . . . . . . 5 61 8.4. draft-mayrhofer-edns0-padding-00 . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 9.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 The Domain Name System (DNS) [RFC1035] was specified to transport DNS 70 packets in clear text form. Since this can expose significant 71 amounts of information about the internet activities of an end user, 72 the IETF has undertaken work to provide confidentiality to DNS 73 transactions (see the DPRIVE WG). Encrypting the DNS transport is 74 considered as one of the options to improve the situation. 76 However, even if both DNS query and response packets were encrypted, 77 meta data of these packets could be used to correlate such packets 78 with well known unencrypted packets, hence jeopardizing some of the 79 confidentiality gained by encryption. One such property is the 80 message size. 82 This document specifies the Extensions Mechanisms for DNS (EDNS(0)) 83 "Padding" Option, which allows to artificially increase the size of a 84 DNS message by a variable number of bytes, significantly hampering 85 size-based correlation of the encrypted packet. 87 2. Terminology 89 The terms "Requestor", "Responder" are to be interpreted as specified 90 in [RFC6891]. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. 97 3. The 'Padding' Option 99 The EDNS(0) [RFC6891] specifies a mechanism to include new options in 100 DNS packets, contained in the RDATA of the OPT meta-RR. This 101 document specifies the 'Padding' option in order to allow clients and 102 servers pad DNS packets by a variable number of bytes. The 'Padding' 103 option MUST occur at most once per OPT meta-RR. 105 The figure below specifies the structure of the option in the RDATA 106 of the OPT RR: 108 0 8 16 109 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 110 | OPTION-CODE | 111 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 112 | OPTION-LENGTH | 113 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 114 | (PADDING) ... (PADDING) ... / 115 +- - - - - - - - - - - - - - - - 117 Figure 1 119 The OPTION-CODE for the 'Padding' option is 12. 121 The OPTION-LENGTH for the 'Padding' option is the size (in octets) of 122 the PADDING. The minimum number of padding octets is 0. 124 The PADDING octets SHOULD be set to 0x00. Application developers who 125 are concerned about misguided lower layer compression MAY instead 126 fill the PADDING octets with the output of a cryptographic random 127 number generator. Responders MUST NOT reject messages containing 128 non-0x00 PADDING octets. 130 4. Usage Considerations 132 This document does not specify the actual amount of padding to be 133 used, since this depends on the situation in which the option is 134 used. However, padded DNS messages MUST NOT exceed the number of 135 octets specified in the Requestor's Payload Size field encoded in The 136 RR Class Field (see Section 6.2.3 and 6.2.4 of [RFC6891]). 138 Responders MUST pad DNS responses when the respective DNS query 139 included the 'Padding' option, unless doing so would violate the 140 maximum UDP payload size. 142 Responders MAY pad DNS responses when the respective DNS query 143 indicated EDNS(0) support of the Requestor. 145 Responders MUST NOT pad DNS responses when the respective DNS query 146 did not indicate EDNS(0). 148 5. IANA Considerations 150 IANA has assigned EDNS Option Code 12 for Padding. 152 IANA is requested to update the respective registration record by 153 changing the Reference field to [[THISRFC]] and the Status field to 154 'Standard'. 156 6. Security Considerations 158 Padding DNS packets obviously increases their size, and will 159 therefore lead to increased traffic, can lead to increased number of 160 truncated packets when used over UDP-based transport. 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 and Christian Huitema suggested text for this 178 document. 180 8. Changes 182 8.1. draft-ietf-dprive-edns0-padding-01 184 Fixed 'octects' typo. Changed 'covert channel' text to align with 185 allowing non-0x00 padding. changed IANA considerations - assigned 186 option code is 12. Changed field definitions to allow for non-0x00 187 padding, removed FORMERR requirement. referenced rfc7525 in security 188 considerations. added acknowledgements. 190 8.2. draft-ieft-dprive-edns0-padding-00 192 Adopted by WG. Changed text about message size limit based on 193 feedback. 195 8.3. draft-mayrhofer-edns0-padding-01 197 Changed minimum padding size to 0, rewrote Usage Considerations 198 section, extended Security considerations section 200 8.4. draft-mayrhofer-edns0-padding-00 202 Initial version 204 9. References 206 9.1. Normative References 208 [RFC1035] Mockapetris, P., "Domain names - implementation and 209 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 210 November 1987, . 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 218 for DNS (EDNS(0))", STD 75, RFC 6891, 219 DOI 10.17487/RFC6891, April 2013, 220 . 222 9.2. Informative References 224 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 225 "Recommendations for Secure Use of Transport Layer 226 Security (TLS) and Datagram Transport Layer Security 227 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 228 2015, . 230 Author's Address 231 Alexander Mayrhofer 232 nic.at GmbH 233 Karlsplatz 1/2/9 234 Vienna 1010 235 Austria 237 Email: alex.mayrhofer.ietf@gmail.com