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