One document matched: draft-mayrhofer-edns0-padding-01.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY rfc2119 PUBLIC ""
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc1035 PUBLIC ""
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc6891 PUBLIC ""
          "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml">
]>

<rfc category="std" docName="draft-mayrhofer-edns0-padding-01"
  ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <front>
    <title abbrev="draft-mayrhofer-edns0-padding">The EDNS(0) Padding Option</title>

    <author initials="A.M." surname="Mayrhofer"
      fullname="Alexander Mayrhofer">
      <organization>nic.at GmbH</organization>
      <address>
    <postal>
     <street>Karlsplatz 1/2/9</street>
     <city>Vienna</city>
     <code>1010</code>
     <country>Austria</country>
    </postal>
    <email>alex.mayrhofer.ietf@gmail.com</email>
   </address>
   </author>
   
   <date year="2015"/>
   <area>Operations and Management Area</area>
    <!-- <workgroup></workgroup> -->
    <abstract>
      <t>   
	  This document specifies the EDNS(0) 'Padding' option, which allows DNS clients and servers to pad request and response messages 
      by a variable number of octets.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
	  <t>The <xref target="RFC1035">Domain Name System (DNS)</xref> was specified to transport DNS packets in clear text form. 
	  Since this can expose significant amounts of information about the internet activities of an end user, the IETF has 
	  undertaken work to provide confidentiality to DNS transactions (see the DPRIVE WG). Encrypting the DNS transport is 
	  considered as one of the options to improve the situation.
	  </t>
	  <t>However, even if both DNS query and response packets were encrypted, meta data of these packets could be used 
	  to correlate such packets with well known unencrypted packets, hence jeopardizing some of the confidentiality 
	  gained by encryption. One such property is the message size.
	  </t>
	  <t> 
	  This document specifies the Extensions Mechanisms for DNS (EDNS(0)) "Padding" Option, which allows to artificially 
	  increase the size of a DNS message by a variable number of bytes, significantly hampering size-based correlation of the encrypted 
	  packet.
	  </t>
	</section>
    <section anchor="terminology" title="Terminology">
	  <t>The terms "Requestor", "Responder" are to be interpreted as specified in <xref target="RFC6891"/>.</t> 
      <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 
		"NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described
        in <xref target="RFC2119"/>. </t>
	 </section>
	 <section title="The 'Padding' Option">
	 <t>
	 The <xref target="RFC6891">EDNS(0)</xref> specifies a mechanism to 
	 include new options in DNS packets, contained in the RDATA of the OPT meta-RR. 
	 This document specifies the 'Padding' option in order to allow clients and servers
	 pad DNS packets by a variable number of bytes. The 'Padding' option MUST occur at 
	 most once per OPT meta-RR.
	 </t>
	 
	 <t>The figure below specifies the structure of the option in the RDATA of 
	 the OPT RR:</t>
	         <figure align="center" anchor="EDNS0_Padding">
          <preamble> </preamble>
          <artwork align="center"><![CDATA[
       0                       8                      16
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                  OPTION-CODE                  |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                 OPTION-LENGTH                 |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |        (PADDING) ...        (PADDING) ...     /
       +-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
]]></artwork>
        </figure>
	   <t>The OPTION-CODE for the 'Padding' option is [[TODO-IANA]].</t>
	   <t>The OPTION-LENGTH for the 'Padding' option is the size (in octects) of the PADDING. The minimum number of padding octects is 0.</t>
	   <t>The PADDING octects MUST be set to 0x00. If a Responder detects non-0x00 octects in the padding of a query, a FORMERR (RCODE=1) MUST be returned.</t>
	 </section>
	<section title="Usage Considerations">
	   <t>This document does not specify the actual amount
	   of padding to be used, since this depends on the situation
	   in which the option is used. However, padded DNS messages MUST NOT
	   exceed the respective UDP payload size (see Section 6.2.3 and 
	   6.2.4 of <xref target="RFC6891"/>).</t>
	   <t>Responders MUST pad DNS responses when the respective DNS query 
	   included the 'Padding' option, unless doing so would violate the maximum UDP payload size.</t>
	   <t>Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor.</t>
	   <t>Responders MUST NOT pad DNS responses when the respective DNS query did not indicate EDNS(0).</t>  
	</section>
    <section title="IANA Considerations">
	   <t>IANA is requested to assign an EDNS Option Code (as described in Section 9 of <xref target="RFC6891"/>) for 
	   the 'Padding' option specified in this document.
	   </t>
	</section>
    <section title="Security Considerations">
	  <t>Padding DNS packets obviously increases their size, and will therefore lead to increased traffic, 
	  can lead to increased number of truncated packets when used over UDP-based transport.
	  </t>
	  <t>The use of the EDNS(0) Padding provides only a benefit when DNS packets are not transported in clear text.
	  Implementations therefore SHOULD avoid using this option if the DNS transport is not encrypted.
	  </t>
	  <t>The payload of the 'Padding' option could be used as a covert channel. 
	  In order to prevent this, padding octets are required to be set to 0x00. It shall be noted that variations in 
	  the OPTION-SIZE itself could still be abused for expensive and low-bandwith covert communication.</t>
	</section>
	<section title="Acknowledgements">
	  <t>This document was inspired by a discussion with Daniel Kahn Gillmor during IETF93, as an 
	  alternative to the proposed padding on the TLS layer.</t>
	</section>
	<section title="Changes">
	  <section title="draft-mayrhofer-edns0-padding-01">
	    <t>Changed minimum padding size to 0, rewrote Usage Considerations section, extended Security considerations section</t>
      </section>
	  <section title="draft-mayrhofer-edns0-padding-00">
	    <t>Initial version</t>
      </section>
	</section>
  </middle>
  <back>
    <references title="Normative References">
				&rfc1035;
                &rfc2119;
				&rfc6891;
	</references>
  </back>
</rfc>