draft-ietf-dprive-padding-policy-06.txt   rfc8467.txt 
Network Working Group A. Mayrhofer Internet Engineering Task Force (IETF) A. Mayrhofer
Internet-Draft nic.at GmbH Request for Comments: 8467 nic.at GmbH
Intended status: Experimental July 19, 2018 Category: Experimental October 2018
Expires: January 20, 2019 ISSN: 2070-1721
Padding Policy for EDNS(0) Padding Policies for Extension Mechanisms for DNS (EDNS(0))
draft-ietf-dprive-padding-policy-06
Abstract Abstract
RFC 7830 specifies the EDNS(0) 'Padding' option, but does not specify RFC 7830 specifies the "Padding" option for Extension Mechanisms for
the actual padding length for specific applications. This memo lists DNS (EDNS(0)) but does not specify the actual padding length for
the possible options ("Padding Policies"), discusses implications of specific applications. This memo lists the possible options
each of these options, and provides a recommended (experimental) ("padding policies"), discusses the implications of each option, and
option. provides a recommended (experimental) option.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on January 20, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8467.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................2
3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 3. General Guidance ................................................3
4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3 4. Padding Strategies ..............................................3
4.1. Block Length Padding - Recommended Strategy . . . . . . . 3 4.1. Recommended Strategy: Block-Length Padding .................3
4.2. Other Strategies . . . . . . . . . . . . . . . . . . . . 5 4.2. Other Strategies ...........................................5
4.2.1. Maximal Length Padding . . . . . . . . . . . . . . . 5 4.2.1. Maximal-Length Padding ..............................5
4.2.2. Random Length Padding . . . . . . . . . . . . . . . . 5 4.2.2. Random-Length Padding ...............................5
4.2.3. Random Block Length Padding . . . . . . . . . . . . . 6 4.2.3. Random-Block-Length Padding .........................6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations .............................................6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations .........................................6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References ......................................................7
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References .......................................7
8.1. draft-ietf-dprive-padding-policy-06 . . . . . . . . . . . 7 7.2. Informative References .....................................7
8.2. draft-ietf-dprive-padding-policy-05 . . . . . . . . . . . 7 Appendix A. Padding Policies That Are Not Sensible ................8
8.3. draft-ietf-dprive-padding-policy-04 . . . . . . . . . . . 8 A.1. No Padding .................................................8
8.4. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 8 A.2. Fixed-Length Padding .......................................8
8.5. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 8 Acknowledgements ...................................................9
8.6. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 8 Author's Address ...................................................9
8.7. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 8
8.8. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Non-sensible Padding Policies . . . . . . . . . . . 9
A.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
[RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0)) [RFC7830] specifies the Extension Mechanisms for DNS (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.
Padding DNS messages is useful only when transport is encrypted, Padding DNS messages is useful only when transport is encrypted using
using protocols such as DNS over Transport Layer Security [RFC7858], protocols such as DNS over Transport Layer Security [RFC7858], DNS
DNS over Datagram Transport Layer Security [RFC8094] or other over Datagram Transport Layer Security [RFC8094], or other encrypted
encrypted DNS transports specified in the future. DNS transports specified in the future.
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 BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. General Guidance 3. General Guidance
EDNS(0) options space: The maximum message length as dictated by the EDNS(0) options space: The maximum message length, as dictated by the
protocol limits the space for EDNS(0) options. Since padding will protocol, limits the space for EDNS(0) options. Since padding will
reduce the message space available to other EDNS(0) options, reduce the message space available to other EDNS(0) options, the
"Padding" MUST be the last EDNS(0) option applied before a DNS "Padding" option MUST be the last EDNS(0) option applied before a DNS
message is sent. message is sent.
Resource Conservation: Especially in situations where networking and Resource Conservation: Especially in situations where networking and
processing resources are scarce (e.g. battery powered long-life processing resources are scarce (e.g., battery-powered long-life
devices, low bandwidth or high cost links), the tradeoff between devices, low bandwidth, or high-cost links), the trade-off between
increased size of padded DNS messages and the corresponding gain in increased size of padded DNS messages and the corresponding gain in
confidentiality must be carefully considered. confidentiality must be carefully considered.
Transport Protocol Independence: The message size used as input to Transport Protocol Independence: The message size used as input to
the various padding strategies MUST be calculated excluding the the various padding strategies MUST be calculated excluding the
potential extra 2-octet length field used in TCP transport. potential extra 2-octet length field used in TCP transport.
Otherwise, the padded (observable) size of the DNS packets could Otherwise, the padded (observable) size of the DNS packets could
significantly change between different transport protocols, and significantly change between different transport protocols and reveal
reveal an indication of the original (unpadded) length. For example, an indication of the original (unpadded) length. For example, given
given a "Block Length" padding strategy with a block length of 32 a Block-Length Padding strategy with a block length of 32 octets and
octets, and a DNS message with a size of 59 octets, the message would a DNS message with a size of 59 octets, the message would be padded
be padded to 64 octets when transported over UDP. If that same to 64 octets when transported over UDP. If that same message were
message was transported over TCP, and the padding strategy would transported over TCP and the padding strategy considered the extra 2
consider the extra 2 octets of the length field (61 octets in total), octets of the length field (61 octets in total), the padded message
the padded message would be 96 octets long (as the minimum length of would be 96 octets long (as the minimum length of the "Padding"
the Padding option is 4 octets). option is 4 octets).
4. Padding Strategies 4. Padding Strategies
This section contains a recommended strategy, as well as a non- This section contains a recommended strategy, as well as a
exhaustive list of other sensible strategies in choosing padding non-exhaustive list of other sensible strategies, for choosing
length. Note that, for completeness, Appendix A contains two more padding length. Note that, for completeness, Appendix A contains two
(non-sensible) strategies. more strategies that are not sensible.
4.1. Block Length Padding - Recommended Strategy 4.1. Recommended Strategy: Block-Length Padding
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 following the [NDSS-PADDING], padding SHOULD be performed following the Block-
"Block Length Padding" strategy as follows: Length Padding strategy 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 receives a query that includes the EDNS(0) Padding (2) If a server receives a query that includes the EDNS(0) "Padding"
Option, it MUST pad the corresponding response (See Section 4 of option, it MUST pad the corresponding response (see Section 4 of
RFC7830) and SHOULD pad the corresponding response to a multiple RFC 7830) and SHOULD pad the corresponding response to a
of 468 octets (see below). multiple of 468 octets (see below).
Note that the recommendation above applies only if the DNS transport Note that the recommendation above only applies if the DNS transport
is encrypted (See Section 6 of RFC 7830). is encrypted (see Section 6 of RFC 7830).
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 EDNS(0) Padding Option increases consider that even the zero-length "Padding" option increases the
the length of the packet by 4 octets. length of the packet by 4 octets.
Options: Block Length - for queries, values between 16 and 128 octets Options: Block length. For queries, values between 16 and 128 octets
were discussed before empiric research was performed. Responses will were discussed before empiric research was performed. Responses will
require larger block sizes (see [dkg-padding-ndss] and above for a require larger block sizes (see [NDSS-PADDING] and above for a
discussion). discussion).
Very large block lengths will have confidentiality properties similar Very large block lengths will have confidentiality properties similar
to the "Maximal Length Padding" strategy (Section 4.2.1), since to the Maximal-Length Padding strategy (Section 4.2.1), since almost
almost all messages will fit into a single block. Such "very large all messages will fit into a single block. Such "very large block
block length" values are 288 bytes for the query (the maximum size of length" values are:
a one-question query over TCP, without any EDNS(0) options), and the
EDNS(0) buffer size of the server for the responses. o 288 bytes for the query (the maximum size of a one-question query
over TCP, without any EDNS(0) options) and
o the 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 range of a padded message can be predicted. reachable), the size range of a padded message can be predicted.
Therefore, the minimum length of the unpadded message can be infered. Therefore, the minimum length of the unpadded message can be
inferred.
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" was defined as the size factor between
unpadded messages. Padding with a block size of 128 bytes on the padded and unpadded messages. Padding with a block size of 128 bytes
query side, and 468 bytes on the response side was considered the on the query side and 468 bytes on the response side was considered
optimum trade-off between defender and attacker cost. The response the optimum trade-off between defender and attacker cost. The
block size of 468 was chosen so that 3 blocks of 468 octets would response block size of 468 was chosen so that 3 blocks of 468 octets
still comfortably fit into typical Maximum Transmission Unit (MTU) would still comfortably fit into typical Maximum Transmission Unit
size values. (MTU) size values.
The Block Size will interact with the MTU size. Especially for The block size will interact with the MTU size. Especially for
length values that are a large fraction of the MTU, unless the block length values that are a large fraction of the MTU, unless the block
length is chosen so that a multiple just fits into the MTU, Block length is chosen so that a multiple just fits into the MTU, Block-
Padding may cause unneccessary fragmentation for UDP based delivery. Length Padding may cause unnecessary fragmentation for UDP-based
Also, chosing a block length larger than the MTU of course always delivery. Of course, choosing a block length larger than the MTU
forces to always fragment. always forces fragmentation.
Note: Once DNSSEC validating clients become more prevalent, observed Note: Once DNSSEC-validating clients become more prevalent, observed
size patterns are expected to change significantly. In such case, size patterns are expected to change significantly. In that case,
the recommended strategy might need to be revisited. the recommended strategy might need to be revisited.
4.2. Other Strategies 4.2. Other Strategies
4.2.1. Maximal Length Padding 4.2.1. Maximal-Length Padding
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 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 networks and equipment, and
the server. Depending on the negotiated size, this strategy will the server. Depending on the negotiated size, this strategy will
commonly exceed the MTU, and then result in a consistent number of commonly exceed the MTU and result in a consistent number of
fragments reducing delivery probability when datagram based transport fragments, reducing delivery probability when datagram-based
(such as UDP) is used. transport (such as UDP) is used.
Due to resource consumption, Maximal Length Padding is NOT Due to resource consumption, Maximal-Length Padding is NOT
RECOMMENDED. RECOMMENDED.
4.2.2. Random Length Padding 4.2.2. 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 EDNS(0) Padding random amount of padding. Due to the size of the "Padding" option
Option itself, each message size is hence increased by at least 4 itself, each message size is increased by at least 4 octets. The
octets. The upper limit for padding is the maximum message size. upper limit for padding is the maximum message size. However, a
However, a client or server may choose to impose a lower maximum client or server may choose to impose a lower maximum padding length.
padding length.
Options: Maximum and 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: Random Length padding allows an attacker who can Disadvantage: Random-Length Padding allows an attacker who can
observe a large number of requests to infer the length of the observe a large number of requests to infer the length of the
original value by observing the distribution of total lengths. original value by observing the distribution of total lengths.
According to the limited empirical data available, Random Length According to the limited empirical data available, Random-Length
Padding exposes slightly more entropy to an attacker than Block Padding exposes slightly more entropy to an attacker than Block-
Length Padding. Due to that, and the risk outlined above, Random Length Padding. Because of that, and the risk outlined above,
Length Padding is NOT RECOMMENDED. Random-Length Padding is NOT RECOMMENDED.
4.2.3. Random Block Length Padding 4.2.3. 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 length Specifically, a sender randomly chooses between a few block length
values and then applies Block Length Padding based on the chosen values and then applies Block-Length Padding based on the chosen
block length. The random selection of block length 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
transaction ID of the message. transaction ID of the message.
Options: Number of and the values for the set of Block Lengths, Options: Number of and the values for the set of block lengths;
source of "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. original message length.
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
strategies) requires further empirical study.
5. Acknowledgements
Daniel K. Gillmor performed empirical research out of which the Random-Block-Length Padding requires further empirical study, as do
"Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo other combinations of padding strategies.
Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman,
Magnus Westerlund, Charlie Kaufman, Joe Clarke and Meral Shirazipour
performed reviews or provided substantial comments.
6. IANA Considerations 5. IANA Considerations
This document has no considerations for IANA. This document has no IANA actions.
7. Security Considerations 6. 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 chosen 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 EDNS(0) Padding must carefully consider which policies implementor of the "Padding" option must carefully consider which
to implement, the default policy chosen, which parameters to make policies to implement, the default policy chosen, which parameters to
configurable, and the default parameter values. make configurable, and the default parameter values.
No matter how carefully a client selects their Padding policy, this No matter how carefully a client selects their padding policy, this
effort can be jeopardized if the server chooses to apply an effort can be jeopardized if the server chooses to apply an
ineffective Padding policy to the corresponding response packets. ineffective padding policy to the corresponding response packets.
Therefore, a client applying Padding may want to choose a DNS server Therefore, a client applying the "Padding" option may want to choose
which does apply at least an equally effective Padding policy on a DNS server that applies a padding policy on responses that is at
responses. least equally effective.
Note that even with encryption and padding, it might be trivial to Note that even with encryption and padding, it might be trivial to
identify that the observed traffic is DNS. Also, padding does not identify that the observed traffic is DNS. Also, padding does not
prevent information leak via other side channels (particularly timing prevent information leaks via other side channels (particularly
information and number of query/response pairs). Counter-measures timing information and number of query/response pairs).
against such other side channels could include injecting artificial Countermeasures against such side channels could include injecting
"cover traffic" into the stream of DNS messages, or delaying DNS artificial "cover traffic" into the stream of DNS messages or
responses by a certain amount of jitter. Such strategies are out of delaying DNS responses by a certain amount of jitter. Such
scope of this document. Additionally, there is neither enough strategies are out of the scope of this document. Additionally,
theoretic analysis nor experimental data available to recommend any there is not enough theoretic analysis or experimental data available
such countermeasures. to recommend any such countermeasures.
8. Changes
[Note to RFC Editors: This whole section is to be removed before
publication]
8.1. draft-ietf-dprive-padding-policy-06
Changes based on IESG evaluation: Removed duplicate paragraph about
MTU impact, switched Terminology boilerplate to RFC8174, changed text
regarding Random Padding, changed text regarding very large block
paddings, some minor edits.
8.2. draft-ietf-dprive-padding-policy-05
Changes based on outcomes of IETF-wide LC + various reviews: Meral
Shirazipour (Gen-ART), Charlie Kaufmann (SECDIR), Joe Clarke (OPSDIR
- changed document flow based on comments),
8.3. draft-ietf-dprive-padding-policy-04
Changes based on WGLC: Changed implementor consideration text in
Security Con section (Sara), moved "No Padding" and "Fixed Length
Padding" to appendix (Stephane, Paul), Changed TODO in Random Padding
to info from empirical study (Stephen), Added note to pad only if
transport encrypted (Stephen), added intro text referencing to
DNSoTLS and DNSoDTLS (Stephane), added text about timing/jitter to
security considerations.
8.4. 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.
8.5. draft-ietf-dprive-padding-policy-02
Changed Document Status to Experimental, added "maximum length"
padding policy, reworded "block length" policy, some editorial
changes.
8.6. draft-ietf-dprive-padding-policy-01
Some (mostly editorial) changes to text. Added "Recommendation"
section based on dkg's research.
8.7. draft-ietf-dprive-padding-policy-00
Initial (mostly unmodified) WG version. Changed "Profile" to
"Policy" to avoid confusion with the (D)TLS profiles document.
8.8. draft-mayrhofer-dprive-padding-profiles-00
Initial version
9. References 7. References
9.1. Normative References 7.1. Normative References
[dkg-padding-ndss] [NDSS-PADDING]
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>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://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,
<https://www.rfc-editor.org/info/rfc7830>. <https://www.rfc-editor.org/info/rfc7830>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 7.2. Informative References
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
Appendix A. Non-sensible Padding Policies Appendix A. Padding Policies That Are Not Sensible
A.1. No Padding A.1. No Padding
In the "No Padding" policy, the EDNS0 Padding option is not used, and In the No Padding policy, the "Padding" option is not used, and the
the size of the final (actually, "non-padded") message obviously size of the final (actually, "non-padded") message obviously exactly
exactly matches the size of the unpadded message. Even though this 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 in which just one of the parties (client or
applies padding. server) 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
the unpadded message does not allow for the Padding option to be unpadded message does not allow for the "Padding" option to be
included (less than 4 octets left). included -- i.e., there are fewer than 4 octets left.
Advantages: This "policy" requires no additional resources on client, Advantages: This policy requires no additional resources on the
server and network side. 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 provides no additional confidentiality. hence, this approach provides no additional confidentiality.
"No Padding" MUST NOT be used unless message size disallows the use The No Padding policy MUST NOT be used unless message size disallows
of Padding. the use of the "Padding" option.
A.2. Fixed Length Padding A.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 if only by a
value) fixed 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 hence must be assumed to be public knowledge. Therefore,
this policy is (almost) as useless as the "No Padding" option this policy is (almost) as useless as the No Padding policy described
described above. above.
"Fixed Length Padding" MUST NOT be used except for test applications. The Fixed-Length Padding policy MUST NOT be used except for test
applications.
Acknowledgements
Daniel K. Gillmor performed empirical research out of which the
"Recommended Strategy" was copied. Stephane Bortzmeyer and Hugo
Connery provided text. Shane Kerr, Sara Dickinson, Paul Hoffman,
Magnus Westerlund, Charlie Kaufman, Joe Clarke, and Meral Shirazipour
performed reviews or provided substantial comments.
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. 71 change blocks. 
256 lines changed or deleted 197 lines changed or added

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