draft-ietf-dprive-padding-policy-02.txt   draft-ietf-dprive-padding-policy-03.txt 
Network Working Group A. Mayrhofer Network Working Group A. Mayrhofer
Internet-Draft nic.at GmbH Internet-Draft nic.at GmbH
Intended status: Experimental September 27, 2017 Intended status: Experimental January 17, 2018
Expires: March 31, 2018 Expires: July 21, 2018
Padding Policy for EDNS(0) Padding Policy for EDNS(0)
draft-ietf-dprive-padding-policy-02 draft-ietf-dprive-padding-policy-03
Abstract Abstract
RFC 7830 specifies the EDNS0 'Padding' option, but does not specify RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify
the actual padding length for specific applications. This memo lists the actual padding length for specific applications. This memo lists
the possible options ("Padding Policies"), discusses the implications the possible options ("Padding Policies"), discusses implications of
of each of these options, and provides a recommended (experimental) each of these options, and provides a recommended (experimental)
option. 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 31, 2018. This Internet-Draft will expire on July 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 4
4.3. Block Length Padding . . . . . . . . . . . . . . . . . . 4 4.3. Block Length Padding . . . . . . . . . . . . . . . . . . 4
4.4. Maximal Lenth Padding ('The Full Monty') . . . . . . . . 5 4.4. Maximal Length Padding ('The Full Monty') . . . . . . . . 5
4.5. Random Length Padding . . . . . . . . . . . . . . . . . . 5 4.5. Random Length Padding . . . . . . . . . . . . . . . . . . 5
4.6. Random Block Length Padding . . . . . . . . . . . . . . . 5 4.6. Random Block Length Padding . . . . . . . . . . . . . . . 6
5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 6 5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 7 9.1. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 8
9.2. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 7 9.2. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 8
9.3. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 7 9.3. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 8
9.4. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 7 9.4. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . 7 9.5. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
RFC 7830 [RFC7830] specifies the Extensions Mechanisms for DNS [RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0))
(EDNS(0)) "Padding" option, which allows DNS clients and servers to "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 7830 deliberately does not specify the actual length 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, lists advantages and disadvantages of each of these size of padding, lists advantages and disadvantages of each of these
"Padding Strategies", and provides a recommended (experimental) "Padding Strategies", and provides a recommended (experimental)
strategy. strategy.
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 DNS messages does not have any semantic impact on the DNS EDNS(0) options space: The maximum message length as dictated by
protocol. However, the length of (possible) padding does depend on protocol limitation limits the space for EDNS(0) options. Since
the circumstances under which a DNS message is created, specifically padding will reduce the message space available to other EDNS(0)
the maximum message length as dictated by protocol negotiations. options, "Padding" MUST be the last EDNS(0) option applied before a
Since padding may frustrate the message space available to other EDNS DNS message is sent.
options, "Padding" MUST be the last EDNS option applied before a DNS
message is sent.
Especially in situations with scarce computing and networking Resource Conservation: Especially in situations where networking and
resources such as long-life battery powered devices, the tradeoff processing resources are scarce (eg. battery powered long-life
between significantly increasing the size of DNS messages by generous devices, low bandwidth or high cost links), the tradeoff between
padding and the corresponding gain in confidentiality must be increased size of padded DNS messages and the corresponding gain in
carefully considered. confidentiality must be carefully considered.
Transport Protocol Independence: The message size used as input to
the various padding strategies MUST be calculated excluding the
potential extra 2-octet length field used in TCP transport.
Otherwise, the padded (observable) size of the DNS packets could
signifcantly change between different transport protocols, and reveal
an indication of the original (unpadded) length. For example, given
a "Block Length" padding strategy with a block length of 32 octets,
and a DNS message with a size of 59 octets, the message would be
padded to 64 octets when transported over UDP. If that same message
was transported over TCP, and the padding strategy would consider the
extra 2 octects of the length field (61 octets in total), the padded
message would be 96 octets long (as the minimum length of the Padding
option is 4 octets).
4. Padding Strategies 4. Padding Strategies
This section is a non-exhaustive list of possible strategies in This section is a non-exhaustive list of possible strategies in
choosing 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 EDNS(0) Padding option is not used,
the size of the final (actually, "non-padded") message obviously and the size of the final (actually, "non-padded") message obviously
exactly matches the size of the unpadded message. Even though this exactly matches the size of the unpadded message. Even though this
"non-policy" seems redundant in this list, its properties must be "non-policy" seems redundant in this list, its properties must be
considered for cases where just one of the parties (client or server) considered for cases where just one of the parties (client or server)
applies padding. applies padding.
Also, this "policy" is required when the remaining message size of Also, this "policy" is required when the remaining message size of
the unpadded message does not allow for the Padding option to be the unpadded message does not allow for the Padding option to be
included (less than 4 octets left). included (less than 4 octets left).
Advantages: This "policy" requires no additional resources on client, Advantages: This "policy" requires no additional resources on client,
skipping to change at page 4, line 10 skipping to change at page 4, line 21
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 is easily discoverable
from a single unencrypted message, or by observing message patterns. from a single unencrypted message, or by observing message patterns.
When a public DNS server applies this policy, the length of the When a public DNS server applies this policy, the length of the
padding hence must be assumed to be public knowledge. Therefore, padding must be assumed to be public knowledge. Therefore, this
this policy is (almost) as useless as the "No Padding" option policy is (almost) as useless as the "No Padding" option described
described above. above.
"Fixed Length Padding" MUST NOT be used except for experimental "Fixed Length Padding" MUST NOT be used except for experimental
applications. applications.
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 EDNS(0) Padding Option increases
length of the packet by 4 octets. the length of the packet by 4 octets.
Options: Block Length - values between 16 and 128 octets for the Options: Block Length - values between 16 and 128 octets for the
queries seem reasonable, responses will require larger block sizes queries seem reasonable, responses will require larger block sizes
(see [dkg-padding-ndss] and Section 5 for a discussion). (see [dkg-padding-ndss] and Section 5 for a discussion).
Very large block lengths will have confidentiality properties similar Very large block lengths will have confidentiality properties similar
to the "Maximum Length Padding" strategy (Section 4.4), since almost to the "Maximum Length Padding" strategy (Section 4.4), since almost
all messages will fit into a single block. In that case, reasonable all messages will fit into a single block. In that case, reasonable
values may be 288 bytes for the query (the maximum size of a one- values may be 288 bytes for the query (the maximum size of a one-
question query over TCP, without any EDNS0 options), and the EDNS question query over TCP, without any EDNS(0) options), and the
buffer size of the server for the responses. EDNS(0) buffer size of the server for the responses.
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 padding length require a source of (pseudo) random numbers, since the padding length
required can be derived from the actual (unpadded) message. required 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 padded message can be predicted. reachable), the size of a padded message can be predicted.
Therefore, minimum and maximum length of the unpadded message are Therefore, minimum and maximum length of the unpadded message are
known. known.
Block Length Padding is the currently RECOMMENDED strategy (see Block Length Padding is the currently RECOMMENDED strategy (see
Section 5). Section 5).
4.4. Maximal Lenth Padding ('The Full Monty') 4.4. Maximal Length Padding ('The Full Monty')
In Maximal Length Padding the sender pads every message to the In Maximal Length Padding the sender pads every message to the
maximum size as allowed by protocol negotiations. maximum size as allowed by protocol negotiations.
Advantages: Maximal Length Padding, when combined with encrypted Advantages: Maximal Length Padding, when combined with encrypted
transport, provides the highest possible level of message size transport, provides the highest possible level of message size
confidentiality. confidentiality.
Disadvantages: Maximal Length Padding is wasteful, and requires Disadvantages: Maximal Length Padding is wasteful, and requires
resources on the client, all intervening network and equipment, and resources on the client, all intervening network and equipment, and
the server. the server.
Maximal Length Padding is NOT RECOMMENDED. Maximal Length Padding is NOT RECOMMENDED.
4.5. Random Length Padding 4.5. Random Length Padding
When using Random Length Padding, a sender pads each message with a When using Random Length Padding, a sender pads each message with a
random amount of padding. Due to the size of the EDNS0 Padding random amount of padding. Due to the size of the EDNS(0) Padding
Option itself, each message size is hence increased by at least 4 Option itself, each message size is hence increased by at least 4
octets. The upper limit for pading is the maximum message size. octets. The upper limit for pading is the maximum message size.
However, a client or server may choose to impose a lower maximum However, a client or server may choose to impose a lower maximum
padding length. padding length.
Options: Maximum (and eventually minimum) padding length. Options: Maximum and minimum padding length.
Advantages: Theoretically, this policy should create a natural Advantages: Theoretically, this policy should create a natural
"distribution" of message sizes "distribution" of message sizes.
Disadvantage: This policy requires a good source of (pseudo) keeping Disadvantage: This policy requires a good source of (pseudo) which
up with the required message rates. Especially on busy servers, this can keep up with the required message rates. Especially on busy
may be a significant hindrance. servers, this may be a significant hindrance.
TODO: Recommendation - this is (at first glance) the best policy, but TODO: Recommendation - this is (at first glance) the best policy, but
requires significant effort requires significant effort
4.6. Random Block Length Padding 4.6. Random Block Length Padding
This policy combines Block Length Padding with a random component. This policy combines Block Length Padding with a random component.
Specifically, a sender randomly chooses between a few block lenght'es Specifically, a sender randomly chooses between a few block length
and then applies Block Length Padding based on the chosen block values and then applies Block Length Padding based on the chosen
length. The random selection of block lenght might even be block length. The random selection of block length might even be
reasonably based on a "weak" source of randomness, such as the reasonably based on a "weak" source of randomness, such as the
transction ID of the message. transction ID of the message.
Options: Number of size of the set of Block Lengths, source of Options: Number of and the values for the set of Block Lengths,
"randomness" source of "randomness"
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
Random Block Length Padding (as other combinations of padding Random Block Length Padding (as other combinations of padding
strategies) require further empirical study. strategies) requires further empirical study.
5. Recommended Strategy 5. Recommended Strategy
Based on empirical research performed by Daniel K. Gillmor Based on empirical research performed by Daniel K. Gillmor
[dkg-padding-ndss], EDNS Padding SHOULD be performed as follows: [dkg-padding-ndss], EDNS(0) Padding SHOULD be performed as follows:
(1) Clients SHOULD pad queries to the closest multiple of 128 (1) Clients SHOULD pad queries to the closest multiple of 128
octets. octets.
(2) If a Server sees padding in a query, it SHOULD pad the (2) If a Server receives a query that includes the EDNS(0) Padding
corresponding response to a multiple of 468 octects. Option, it MUST pad the corresponding response (See Section 4 of
[RFC7830]) and SHOULD pad the response to a multiple of 468
octects.
The empirical research cited above performed a simulation of padding, The empirical research cited above performed a simulation of padding,
based on real-world DNS traffic captured on busy recursive resolvers based on real-world DNS traffic captured on busy recursive resolvers
of a research network. The evaluation of the performance of of a research network. The evaluation of the performance of
individual padding policies was based on a "cost to attacker" and individual padding policies was based on a "cost to attacker" and
"cost to defender" function, where the "cost to attacker" was defined "cost to defender" function, where the "cost to attacker" was defined
as the percentage of query/response pairs falling into the same size as the percentage of query/response pairs falling into the same size
bucket, and "cost to defender" as the size factor between padded and bucket, and "cost to defender" as the size factor between padded and
unpadded messages. Padding with a block size of 128 bytes on the unpadded messages. Padding with a block size of 128 bytes on the
query side, and 468 bytes on the response side was considered the query side, and 468 bytes on the response side was considered the
optimum trade-off between defender and attacker cost. The response optimum trade-off between defender and attacker cost. The response
block size of 468 was chosen so that 3 blocks of 468 octets would block size of 468 was chosen so that 3 blocks of 468 octets would
still comfortably fit into typical MTU values. still comfortably fit into typical MTU values.
Note: Once DNSSEC validating clients become more prevalent, observed
size patterns are expected to change significantly. In such case,
the recommended strategy might need to be revisited.
6. Acknowledgements 6. Acknowledgements
Daniel K. Gillmor performed empirical research out of which the Daniel K. Gillmor performed empirical research out of which the
"Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo "Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo
Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman
performed reviews and provided substantial comments. performed reviews and provided substantial comments.
7. IANA Considerations 7. IANA Considerations
This document has no considerations for IANA. This document has no considerations for IANA.
8. 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 chosen 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 EDNS(0) 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 No matter how carefully a client selects their Padding policy, this
the corresponding server does apply an inffective (or no) Padding effort can be jeopardized if the server chooses to apply an
policy on the response packets. Therefore, a client applying Padding inffective Padding policy to the corresponding response packets.
may want to chose a DNS server which does apply at least an equally Therefore, a client applying Padding may want to choose a DNS server
effective Padding policy on responses. which does apply at least an equally effective Padding policy on
responses.
Note that even with encryption and padding, it might be trivial to
identify that the observed traffic is DNS. Also, padding does not
prevent information leak via other side channels (particularly timing
information).
9. Changes 9. Changes
[Note to RFC Editors: This whole section is to be removed before [Note to RFC Editors: This whole section is to be removed before
publication] publication]
9.1. draft-ietf-dprive-padding-policy-02 9.1. draft-ietf-dprive-padding-policy-03
Editorial changes in various spots. Added text about excluding TCP
length field, more security considerations, addressing Sara's other
feedback to -02.
9.2. draft-ietf-dprive-padding-policy-02
Changed Document Status to Experimental, added "maximum length" Changed Document Status to Experimental, added "maximum length"
padding policy, reworded "block length" policy, some editorial padding policy, reworded "block length" policy, some editorial
changes. changes.
9.2. draft-ietf-dprive-padding-policy-01 9.3. draft-ietf-dprive-padding-policy-01
Some (mostly editorial) changes to text. Added "Recommendation" Some (mostly editorial) changes to text. Added "Recommendation"
section based on dkg's research. section based on dkg's research.
9.3. draft-ietf-dprive-padding-policy-00 9.4. 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.
9.4. draft-mayrhofer-dprive-padding-profiles-00 9.5. draft-mayrhofer-dprive-padding-profiles-00
Initial version Initial version
10. Normative References 10. Normative References
[dkg-padding-ndss] [dkg-padding-ndss]
Gillmor, D., "Empirical DNS Padding Policy", March 2017, Gillmor, D., "Empirical DNS Padding Policy", March 2017,
<https://dns.cmrg.net/ <https://dns.cmrg.net/
ndss2017-dprive-empirical-DNS-traffic-size.pdf>. ndss2017-dprive-empirical-DNS-traffic-size.pdf>.
 End of changes. 39 change blocks. 
70 lines changed or deleted 101 lines changed or added

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