[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mayrhofer-dprive-padding-profile) 00 01

Network Working Group                                       A. Mayrhofer
Internet-Draft                                               nic.at GmbH
Intended status: Standards Track                            July 3, 2017
Expires: January 4, 2018


                       Padding Policy for EDNS(0)
                  draft-ietf-dprive-padding-policy-01

Abstract

   RFC 7830 specifies the EDNS0 'Padding' option, but does not specify
   the length of padding to be used in specific applications.  This memo
   lists the possible options ("Padding Policies"), discusses the
   implications of each of these options, and provides a recommended
   option.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Mayrhofer                Expires January 4, 2018                [Page 1]


Internet-Draft      draft-ietf-dprive-padding-policy           July 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  General Guidance  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Padding Strategies  . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  No Padding  . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  Fixed Length Padding  . . . . . . . . . . . . . . . . . .   3
     4.3.  Block Length Padding  . . . . . . . . . . . . . . . . . .   4
     4.4.  Random Length Padding . . . . . . . . . . . . . . . . . .   4
     4.5.  Random Block Length Padding . . . . . . . . . . . . . . .   5
   5.  Recommended Strategy  . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  draft-ietf-dprive-padding-policy-01 . . . . . . . . . . .   6
     9.2.  draft-ietf-dprive-padding-policy-00 . . . . . . . . . . .   6
     9.3.  draft-mayrhofer-dprive-padding-profiles-00  . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   RFC 7830 [RFC7830] specifies the Extensions Mechanisms for DNS
   (EDNS(0)) "Padding" option, which allows DNS clients and servers to
   artificially increase the size of a DNS message by a variable number
   of bytes, hampering size-based correlation of encrypted DNS messages.

   However, RFC 7830 deliberately does not specify the actual length of
   padding to be used.  This memo discusses options regarding the actual
   size of padding, lists advantages and disadvantages of each of these
   "Padding Strategies", and provides a recommended strategy (TODO
   pending concensus of the working group!)

2.  Terminology

   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
   [RFC2119].








Mayrhofer                Expires January 4, 2018                [Page 2]


Internet-Draft      draft-ietf-dprive-padding-policy           July 2017


3.  General Guidance

   Padding DNS messages does not have any semantic impact on the DNS
   protocol.  However, the length of (possible) padding does depend on
   the circumstances under which a DNS message is created, specifically
   the maximum message length as dictated by protocol negotiations.
   Therefore, in order to not impact the possibility to add other EDNS
   options, "Padding" MUST be the last ENDS option applied before a DNS
   message is sent.

   Especially in situations with scarce computing and networking
   resources such as long-life battery powered devices, the tradeoff
   between significantly increasing the size of DNS messages by generous
   padding and the corresponding gain in confidentiality must be
   carefully considered.

4.  Padding Strategies

   This section is a non-exhaustive list of possible strategies to
   choosing padding length

4.1.  No Padding

   In the "No Padding" policy, the EDNS0 Padding option is not used, and
   the size of the final (actually, "non-padded") message obviously
   matches exactly the size of the unpadded messages.  Even though this
   "non-policy" seems redundant in this list, its properties must be
   considered for cases where only of the parties (client or server)
   applies padding.

   Note that employing this "policy" is required also when the message
   size of the unpadded message does not allow for the Padding option to
   be included (less than 4 octets message space left).

   Advantages: The only advantage of this approach is that this "policy"
   requires no additional resources on client, server and network side.

   Disadvantages: The original size of the message remains unchanged,
   hence this approach provides no additional confidentiality.

   TODO: Recommend that this policy MUST NOT be used unless message size
   disallows the use of Padding.

4.2.  Fixed Length Padding

   In fixed length padding, a sender chooses to pad each message with a
   padding of constant length.




Mayrhofer                Expires January 4, 2018                [Page 3]


Internet-Draft      draft-ietf-dprive-padding-policy           July 2017


   Options: Actual length of padding

   Advantages: Since the padding is constant in length, this policy is
   very easy to implement, and at least ensures that the message length
   diverges from the length of the original packet (even only by a fixed
   value)

   Disadvantage: Obviously, the amount of padding easily discoverable
   from a single unencrypted message, or by observing message patterns.
   When a public DNS server applies this policy, the length of the
   padding hence must be assumed to be public knowledge.  Therefore,
   this policy is equally useless "No Padding" option described above.

4.3.  Block Length Padding

   In Block Length Padding, a sender pads each message so that its
   padded length is a multiple of a chosen block length.  This creates a
   greatly reduced variety of message lengths.  An implementor needs to
   consider that even the zero-length EDNS0 Padding Option increases the
   length of the packet by 4 octets.

   Options: Block Length - values between 16 and 128 (TODO Discuss!)
   octets seem reasonable

   Advantages: This policy is reasonably easy to implement, reduces the
   variety of message ("fingerprint") sizes significantly, and does not
   require a source of (pseudo) random numbers, since the amount of
   padding can be derived from the actual (unpadded) message.

   Disadvantage: Given an unpadded message and the block size of the
   padding (which is assumed to be public knowledge once a server is
   reachable), the size of a message can be predicted.  Therefore, the
   minimum and maximum length of the unpadded message is known.

   TODO: Recommended policy?

4.4.  Random Length Padding

   When using Random Length Padding, a sender pads each message with a
   random amount of padding.  Due to the size of the EDNS0 Padding
   Option itself, each message size is hence increased by at least 4
   octets.  The upper limit for pading is the maximum message size.
   However, a client or server may choose to impose a lower maximum
   padding length.

   Alternatively, pad a certain percentage of "remaining space"?

   Options: Maximum (and eventually minimum) padding length.



Mayrhofer                Expires January 4, 2018                [Page 4]


Internet-Draft      draft-ietf-dprive-padding-policy           July 2017


   Advantages: This policy should create the best "distribution" of
   message sizes

   Disadvantage: This policy requires a good source of (pseudo) random
   numbers which keeps up with the required message rates.  Especially
   on busy servers, this could be a significant hindrance.

   TODO: Recommendation - this is (at first glance) the best policy, but
   requires significant effort

4.5.  Random Block Length Padding

   This policy combines Block Length Padding with a random component.
   Specifically, a sender randomly chooses between a few block lenght'es
   and then applies Block Length Padding based on the chosen block
   length.  The random selection of block lenght might even be
   reasonably based on a "weak" source of randomness, such as the
   transction ID of the message.

   Options: Number of size of the set of Block Lengths, source of
   "randomness"

   Advantages: Compared to Block Length Padding, this creates more
   variety in the resulting message sizes for a certain individual
   original message length.  Also, compared to "Random Length Padding",
   it might not require a "full blown" random number source.

   Disadvantage: Requires more implementation effort compared to simple
   Block Length Padding

   TODO: Recommend over simple Block Length Padding?

5.  Recommended Strategy

   Based on empirical research performed by Daniel K.  Gillmor
   [dkg-padding-ndss], EDNS Padding SHOULD be performed as follows:

   (1)  Clients should pad queries to the closest multiple of 128
        octets.

   (2)  If a Server sees padding in a query, it should pad its response
        to a multiple of 468 octects.

   (3)  TODO: recommend to not pad when query was unpadded?







Mayrhofer                Expires January 4, 2018                [Page 5]


Internet-Draft      draft-ietf-dprive-padding-policy           July 2017


6.  Acknowledgements

   Daniel K.  Gillmor performed empirical research out of which the
   "Recommended Strategy" was copied.

7.  IANA Considerations

   This document has no considerations for IANA.

8.  Security Considerations

   The choice of the right padding policy (and the right parameters for
   the chose policy) has a significant impact on the resilience of
   encrypted DNS against size-based correlation attacks.  Therefore, any
   implementor of EDNS0 Padding must carefully consider the chosen
   policy and its parameters.

   A clients carefully chosen Padding policy may be without effect if
   the corresponding server does apply an inffective (or no) Padding
   policy on the response packets.  Therefore, a client applying Padding
   may want to chose a DNS server which does apply at least an equally
   effective Padding policy on responses.

9.  Changes

9.1.  draft-ietf-dprive-padding-policy-01

   Some (mostly editorial) changes to text.  Added "Recommendation"
   section based on dkg's research.

9.2.  draft-ietf-dprive-padding-policy-00

   Initial (mostly unmodified) WG version.  Changed "Profile" to
   "Policy" to avoid confusion with the (D)TLS profiles document.

9.3.  draft-mayrhofer-dprive-padding-profiles-00

   Initial version

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.




Mayrhofer                Expires January 4, 2018                [Page 6]


Internet-Draft      draft-ietf-dprive-padding-policy           July 2017


   [RFC7830]  Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
              DOI 10.17487/RFC7830, May 2016,
              <http://www.rfc-editor.org/info/rfc7830>.

10.2.  Informative References

   [dkg-padding-ndss]
              Gillmor, D., "Empirical DNS Padding Policy", March 2017,
              <https://dns.cmrg.net/ndss2017-dprive-empirical-DNS-
              traffic-size.pdf>.

Author's Address

   Alexander Mayrhofer
   nic.at GmbH
   Karlsplatz 1/2/9
   Vienna  1010
   Austria

   Email: alex.mayrhofer.ietf@gmail.com































Mayrhofer                Expires January 4, 2018                [Page 7]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/