draft-ietf-dprive-padding-policy-00.txt   draft-ietf-dprive-padding-policy-01.txt 
Network Working Group A. Mayrhofer Network Working Group A. Mayrhofer
Internet-Draft nic.at GmbH Internet-Draft nic.at GmbH
Intended status: Standards Track December 5, 2016 Intended status: Standards Track July 3, 2017
Expires: June 8, 2017 Expires: January 4, 2018
Padding Policy for EDNS(0) Padding Policy for EDNS(0)
draft-ietf-dprive-padding-policy-00 draft-ietf-dprive-padding-policy-01
Abstract Abstract
RFC 7830 specifies the EDNS0 'Padding' option, but does not specify RFC 7830 specifies the EDNS0 'Padding' option, but does not specify
the amount of padding to be used in specific applications. This memo the length of padding to be used in specific applications. This memo
lists the possible options ("Padding Policies"), discusses the lists the possible options ("Padding Policies"), discusses the
implications of each of these options, and provides implementation implications of each of these options, and provides a recommended
guidance. option.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 8, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 2 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3
4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3 4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3
4.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 3 4.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 3
4.3. Block Length Padding . . . . . . . . . . . . . . . . . . 4 4.3. Block Length Padding . . . . . . . . . . . . . . . . . . 4
4.4. Random Length Padding . . . . . . . . . . . . . . . . . . 4 4.4. Random Length Padding . . . . . . . . . . . . . . . . . . 4
4.5. Random Block Length Padding . . . . . . . . . . . . . . . 5 4.5. Random Block Length Padding . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7.1. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7.2. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 6 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6 9.1. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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 1. Introduction
RFC 7830 [RFC7830] specifies the Extensions Mechanisms for DNS RFC 7830 [RFC7830] specifies the Extensions Mechanisms for DNS
(EDNS(0)) "Padding" option, which allows DNS clients and servers to (EDNS(0)) "Padding" option, which allows DNS clients and servers to
artificially increase the size of a DNS message by a variable number artificially increase the size of a DNS message by a variable number
of bytes, hampering size-based correlation of encrypted DNS messages. of bytes, hampering size-based correlation of encrypted DNS messages.
However, RFC 7803 deliberately does not specify the actual amount of However, RFC 7830 deliberately does not specify the actual length of
padding to be used. This memo discusses options regarding the actual padding to be used. This memo discusses options regarding the actual
size of padding, and lists advantages and disadvantages of each of size of padding, lists advantages and disadvantages of each of these
these "Padding Strategies". "Padding Strategies", and provides a recommended strategy (TODO
pending concensus of the working group!)
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. General Guidance 3. General Guidance
Padding messages does not have any semantic impact on the DNS Padding DNS messages does not have any semantic impact on the DNS
protocol. However, the amount of (possible) padding does depend on protocol. However, the length of (possible) padding does depend on
the circumstances under which a DNS message is created, specifically the circumstances under which a DNS message is created, specifically
the maximum message length as dictated by protocol negotiations. the maximum message length as dictated by protocol negotiations.
Therefore, in order to not impact the possibility to add other EDNS Therefore, in order to not impact the possibility to add other EDNS
options, "Padding" MUST be the last ENDS option applied before a DNS options, "Padding" MUST be the last ENDS option applied before a DNS
message is sent. message is sent.
Especially in situations with scarce computing and networking Especially in situations with scarce computing and networking
resources such as long-life battery powered devices, the tradeoff resources such as long-life battery powered devices, the tradeoff
between significantly increasing the size of DNS messages by generous between significantly increasing the size of DNS messages by generous
padding and the corresponding gain in confidentiality must be padding and the corresponding gain in confidentiality must be
carefully considered. carefully considered.
4. Padding Strategies 4. Padding Strategies
This section is a non-exhaustive list of strategies with regards to This section is a non-exhaustive list of possible strategies to
choosing the appropriate padding length. choosing padding length
4.1. No Padding 4.1. No Padding
In the "No Padding" policy, the EDNS0 Padding option is not used, and In the "No Padding" policy, the EDNS0 Padding option is not used, and
the size of the final (actually, "non-padded") message obviously the size of the final (actually, "non-padded") message obviously
corresponds exactly to the size of the unpadded messages. Even matches exactly the size of the unpadded messages. Even though this
though this "non-policy" could seem out of choice in this list, it "non-policy" seems redundant in this list, its properties must be
needs to be considered for cases when either of the parties (client considered for cases where only of the parties (client or server)
or server) does not apply padding, while the other party does. applies padding.
Note that following this "policy" is required if the message size of Note that employing this "policy" is required also when the message
the unpadded message does not allow for the Padding option to be size of the unpadded message does not allow for the Padding option to
included (less than 4 octets message space left). Therefore, this be included (less than 4 octets message space left).
"non-policy" is listed here for the sake of completeness.
Advantages: The only advantage of this approach is that this "policy" Advantages: The only advantage of this approach is that this "policy"
requires no additional resources on client, server and network side. requires no additional resources on client, server and network side.
Disadvantages: The original size of the message remains unchanged, Disadvantages: The original size of the message remains unchanged,
hence this approach adds no additional entropy hence this approach provides no additional confidentiality.
TODO: Recommend that this policy MUST NOT be used unless message size TODO: Recommend that this policy MUST NOT be used unless message size
disallows the use of Padding. disallows the use of Padding.
4.2. Fixed Length Padding 4.2. Fixed Length Padding
In fixed length padding, a sender chooses to pad each message with a In fixed length padding, a sender chooses to pad each message with a
padding of constant length. padding of constant length.
Options: Actual length of padding Options: Actual length of padding
Advantages: Since the padding is constant in length, this policy is Advantages: Since the padding is constant in length, this policy is
very easy to implement, and at least ensures that the message length 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 diverges from the length of the original packet (even only by a fixed
value) value)
Disadvantage: Obviously, the amount of padding easily discoverable Disadvantage: Obviously, the amount of padding easily discoverable
from a single decrypted message. When a public DNS server applies from a single unencrypted message, or by observing message patterns.
this policy, the length of the padding hence must be assumed to be When a public DNS server applies this policy, the length of the
public knowledge. Therefore, this policy is almost as bad as the "No padding hence must be assumed to be public knowledge. Therefore,
Padding" option described above. this policy is equally useless "No Padding" option described above.
4.3. Block Length Padding 4.3. Block Length Padding
In Block Length Padding, a sender pads each message so that its 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 padded length is a multiple of a chosen block length. This creates a
greatly reduced variety of message lengths. An implementor needs to greatly reduced variety of message lengths. An implementor needs to
consider that even the zero-length EDNS0 Padding Option increases the consider that even the zero-length EDNS0 Padding Option increases the
length of the packet by 4 octets. length of the packet by 4 octets.
Options: Block Length - values between 16 and 128 (Discuss!) octets Options: Block Length - values between 16 and 128 (TODO Discuss!)
seem reasonable octets seem reasonable
Advantages: This policy is reasonably easy to implement, reduces the Advantages: This policy is reasonably easy to implement, reduces the
variety of message ("fingerprint") sizes significantly, and does not variety of message ("fingerprint") sizes significantly, and does not
require a source of (pseudo) random numbers, since the amount of require a source of (pseudo) random numbers, since the amount of
padding can be derived from the actual (unpadded) message. padding can be derived from the actual (unpadded) message.
Disadvantage: Given an unpadded message and the block size of the Disadvantage: Given an unpadded message and the block size of the
padding (which is assumed to be public knowledge once a server is padding (which is assumed to be public knowledge once a server is
reachable), the size of a message can be predicted. Therefore, the reachable), the size of a message can be predicted. Therefore, the
minimum and maximum length of the unpadded message is known. minimum and maximum length of the unpadded message is known.
skipping to change at page 5, line 30 skipping to change at page 5, line 37
Advantages: Compared to Block Length Padding, this creates more Advantages: Compared to Block Length Padding, this creates more
variety in the resulting message sizes for a certain individual variety in the resulting message sizes for a certain individual
original message length. Also, compared to "Random Length Padding", original message length. Also, compared to "Random Length Padding",
it might not require a "full blown" random number source. it might not require a "full blown" random number source.
Disadvantage: Requires more implementation effort compared to simple Disadvantage: Requires more implementation effort compared to simple
Block Length Padding Block Length Padding
TODO: Recommend over simple Block Length Padding? TODO: Recommend over simple Block Length Padding?
5. IANA Considerations 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?
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. This document has no considerations for IANA.
6. Security Considerations 8. Security Considerations
The choice of the right padding policy (and the right parameters for The choice of the right padding policy (and the right parameters for
the chose policy) has a significant impact on the resilience of the chose policy) has a significant impact on the resilience of
encrypted DNS against size-based correlation attacks. Therefore, any encrypted DNS against size-based correlation attacks. Therefore, any
implementor of EDNS0 Padding must carefully consider the chosen implementor of EDNS0 Padding must carefully consider the chosen
policy and its parameters. policy and its parameters.
A clients carefully chosen Padding policy may be without effect if A clients carefully chosen Padding policy may be without effect if
the corresponding server does apply an inffective (or no) Padding the corresponding server does apply an inffective (or no) Padding
policy on the response packets. Therefore, a client applying 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 may want to chose a DNS server which does apply at least an equally
effective Padding policy on responses. effective Padding policy on responses.
7. Changes 9. Changes
7.1. draft-ietf-dprive-padding-policy-00
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 Initial (mostly unmodified) WG version. Changed "Profile" to
"Policy" to avoid confusion with the (D)TLS profiles document. "Policy" to avoid confusion with the (D)TLS profiles document.
7.2. draft-mayrhofer-dprive-padding-profiles-00 9.3. draft-mayrhofer-dprive-padding-profiles-00
Initial version Initial version
8. Normative References 10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016, DOI 10.17487/RFC7830, May 2016,
<http://www.rfc-editor.org/info/rfc7830>. <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 Author's Address
Alexander Mayrhofer Alexander Mayrhofer
nic.at GmbH nic.at GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Vienna 1010 Vienna 1010
Austria Austria
Email: alex.mayrhofer.ietf@gmail.com Email: alex.mayrhofer.ietf@gmail.com
 End of changes. 23 change blocks. 
44 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/