One document matched: draft-mayrhofer-edns0-padding-00.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-00"
  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>alexander.mayrhofer@nic.at</email>
   </address>
   </author>
   
   <date year="2015"/>
   <area>Operations and Management Area</area>
    <!-- <workgroup></workgroup> -->
    <abstract>
      <t>   
	  This document specifies the EDNS0 'Padding' option, allowing DNS clients and servers to pad request and response packets 
      by a variable number of bytes. This is to be used together with encrypted DNS transports in order to impede message-size 
      based correlation attacks on the confidentiality of messages.	  
      </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 current 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, and hence jeopardizing some of the confidentiality 
	  gained by encryption. One such property is the message size.
	  </t>
	  <t>Size-based correlation of encrypted packets can be avoided by padding application messages with additional data. 
	  This document specifies the Extensions Mechanisms for DNS (EDNS(0)) "Padding" Option, which allows to artificially 
	  increase the size of a DNS packet by a variable number of bytes, in order to prevent size-based correlation 
	  once the packet is encrypted.
	  </t>
	</section>
    <section anchor="terminology" title="Terminology">
      <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">EDNS0 specification</xref> specifies a way to 
	 include new options for DNS packets, contained in the RDATA of the OPT meta-RR. 
	 This document specifies one such new 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 1.</t>
	   <t>The PADDING octects SHOULD be set to 0x00 (TODO: Discuss - together with compression in the encrypted transport, this could weaken the padding).</t>
	 </section>
	<section title="Client Considerations">
	   <t>A client SHOULD use the 'Padding' option in a DNS query (QR=0) only when transport of the DNS packets is encrypted. Note that there might 
	   be situations (such as bump-in-the-wire encryption) where a client is unable to identify whether or not encryption is being performed.</t>
	   <t>This document is silent on the length of the padding a client should use, since this is believed to be subject of the specification of an actual encrypted DNS transport (and might depend on its properties).</t>
	   
	</section>
	<section title="Server Considerations">
	   <t>A server MUST use the 'Padding' option in a DNS response (QR=1) only when that response correlates to a query that contained the 'Padding' option.</t>
	   <t>This document is silent on the length of the padding a server should use, since this is believed to be subject of the specification of an actual encrypted DNS transport.</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, 
	  and can lead to increased number of truncated packets when used over UDP-based transport, or trigger similar
	  operational issues.
	  </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>
	</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>
  </middle>
  <back>
    <references title="Normative References">
				&rfc1035;
                &rfc2119;
				&rfc6891;
	</references>
  </back>
</rfc>