idnits 2.17.1 draft-ietf-dprive-edns0-padding-00.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 4, 2015) is 3096 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) 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: Standards Track November 4, 2015 5 Expires: May 7, 2016 7 The EDNS(0) Padding Option 8 draft-ietf-dprive-edns0-padding-00 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 7, 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-ieft-dprive-edns0-padding-00 . . . . . . . . . . . 4 59 8.2. draft-mayrhofer-edns0-padding-01 . . . . . . . . . . . . 4 60 8.3. draft-mayrhofer-edns0-padding-00 . . . . . . . . . . . . 4 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The Domain Name System (DNS) [RFC1035] was specified to transport DNS 67 packets in clear text form. Since this can expose significant 68 amounts of information about the internet activities of an end user, 69 the IETF has undertaken work to provide confidentiality to DNS 70 transactions (see the DPRIVE WG). Encrypting the DNS transport is 71 considered as one of the options to improve the situation. 73 However, even if both DNS query and response packets were encrypted, 74 meta data of these packets could be used to correlate such packets 75 with well known unencrypted packets, hence jeopardizing some of the 76 confidentiality gained by encryption. One such property is the 77 message size. 79 This document specifies the Extensions Mechanisms for DNS (EDNS(0)) 80 "Padding" Option, which allows to artificially increase the size of a 81 DNS message by a variable number of bytes, significantly hampering 82 size-based correlation of the encrypted packet. 84 2. Terminology 86 The terms "Requestor", "Responder" are to be interpreted as specified 87 in [RFC6891]. 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. The 'Padding' Option 96 The EDNS(0) [RFC6891] specifies a mechanism to include new options in 97 DNS packets, contained in the RDATA of the OPT meta-RR. This 98 document specifies the 'Padding' option in order to allow clients and 99 servers pad DNS packets by a variable number of bytes. The 'Padding' 100 option MUST occur at most once per OPT meta-RR. 102 The figure below specifies the structure of the option in the RDATA 103 of the OPT RR: 105 0 8 16 106 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 107 | OPTION-CODE | 108 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 109 | OPTION-LENGTH | 110 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 111 | (PADDING) ... (PADDING) ... / 112 +- - - - - - - - - - - - - - - - 114 Figure 1 116 The OPTION-CODE for the 'Padding' option is [[TODO-IANA]]. 118 The OPTION-LENGTH for the 'Padding' option is the size (in octects) 119 of the PADDING. The minimum number of padding octects is 0. 121 The PADDING octects MUST be set to 0x00. If a Responder detects non- 122 0x00 octects in the padding of a query, a FORMERR (RCODE=1) MUST be 123 returned. 125 4. Usage Considerations 127 This document does not specify the actual amount of padding to be 128 used, since this depends on the situation in which the option is 129 used. However, padded DNS messages MUST NOT exceed the number of 130 octets specified in the Requestor's Payload Size field encoded in The 131 RR Class Field (see Section 6.2.3 and 6.2.4 of [RFC6891]). 133 Responders MUST pad DNS responses when the respective DNS query 134 included the 'Padding' option, unless doing so would violate the 135 maximum UDP payload size. 137 Responders MAY pad DNS responses when the respective DNS query 138 indicated EDNS(0) support of the Requestor. 140 Responders MUST NOT pad DNS responses when the respective DNS query 141 did not indicate EDNS(0). 143 5. IANA Considerations 145 IANA is requested to assign an EDNS Option Code (as described in 146 Section 9 of [RFC6891]) for the 'Padding' option specified in this 147 document. 149 6. Security Considerations 151 Padding DNS packets obviously increases their size, and will 152 therefore lead to increased traffic, can lead to increased number of 153 truncated packets when used over UDP-based transport. 155 The use of the EDNS(0) Padding provides only a benefit when DNS 156 packets are not transported in clear text. Implementations therefore 157 SHOULD avoid using this option if the DNS transport is not encrypted. 159 The payload of the 'Padding' option could be used as a covert 160 channel. In order to prevent this, padding octets are required to be 161 set to 0x00. It shall be noted that variations in the OPTION-SIZE 162 itself could still be abused for expensive and low-bandwith covert 163 communication. 165 7. Acknowledgements 167 This document was inspired by a discussion with Daniel Kahn Gillmor 168 during IETF93, as an alternative to the proposed padding on the TLS 169 layer. 171 8. Changes 173 8.1. draft-ieft-dprive-edns0-padding-00 175 Adopted by WG. Changed text about message size limit based on 176 feedback. 178 8.2. draft-mayrhofer-edns0-padding-01 180 Changed minimum padding size to 0, rewrote Usage Considerations 181 section, extended Security considerations section 183 8.3. draft-mayrhofer-edns0-padding-00 185 Initial version 187 9. Normative References 189 [RFC1035] Mockapetris, P., "Domain names - implementation and 190 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 191 November 1987, . 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 195 RFC2119, March 1997, 196 . 198 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 199 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 200 RFC6891, April 2013, 201 . 203 Author's Address 205 Alexander Mayrhofer 206 nic.at GmbH 207 Karlsplatz 1/2/9 208 Vienna 1010 209 Austria 211 Email: alex.mayrhofer.ietf@gmail.com