draft-ietf-dprive-padding-policy-04.txt		draft-ietf-dprive-padding-policy-05.txt
	Network Working Group A. Mayrhofer		Network Working Group A. Mayrhofer
	Internet-Draft nic.at GmbH		Internet-Draft nic.at GmbH
	Intended status: Experimental February 6, 2018		Intended status: Experimental April 12, 2018
	Expires: August 10, 2018		Expires: October 14, 2018
	Padding Policy for EDNS(0)		Padding Policy for EDNS(0)
	draft-ietf-dprive-padding-policy-04		draft-ietf-dprive-padding-policy-05
	Abstract		Abstract
	RFC 7830 specifies the EDNS(0) '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 implications of		the possible options ("Padding Policies"), discusses implications 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
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 August 10, 2018.		This Internet-Draft will expire on October 14, 2018.
	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
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3		3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3
	4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3		4. Padding Strategies . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Block Length Padding . . . . . . . . . . . . . . . . . . 3		4.1. Block Length Padding - Recommended Strategy . . . . . . . 3
	4.2. Maximal Length Padding ('The Full Monty') . . . . . . . . 4		4.2. Other Sensible Strategies . . . . . . . . . . . . . . . . 5
	4.3. Random Length Padding . . . . . . . . . . . . . . . . . . 4		4.2.1. Maximal Length Padding . . . . . . . . . . . . . . . 5
	4.4. Random Block Length Padding . . . . . . . . . . . . . . . 5		4.2.2. Random Length Padding . . . . . . . . . . . . . . . . 5
	5. Recommended Strategy . . . . . . . . . . . . . . . . . . . . 5		4.2.3. Random Block Length Padding . . . . . . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. draft-ietf-dprive-padding-policy-04 . . . . . . . . . . . 7		8.1. draft-ietf-dprive-padding-policy-05 . . . . . . . . . . . 7
	9.2. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 7		8.2. draft-ietf-dprive-padding-policy-04 . . . . . . . . . . . 7
	9.3. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 7		8.3. draft-ietf-dprive-padding-policy-03 . . . . . . . . . . . 8
	9.4. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 7		8.4. draft-ietf-dprive-padding-policy-02 . . . . . . . . . . . 8
	9.5. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 7		8.5. draft-ietf-dprive-padding-policy-01 . . . . . . . . . . . 8
	9.6. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8		8.6. draft-ietf-dprive-padding-policy-00 . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8.7. draft-mayrhofer-dprive-padding-profiles-00 . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Non-sensible Padding Policies . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	A.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Non-sensible Padding Policies . . . . . . . . . . . 9
			A.1. No Padding . . . . . . . . . . . . . . . . . . . . . . . 9
	A.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 9		A.2. Fixed Length Padding . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[RFC7830] specifies the Extensions Mechanisms for DNS (EDNS(0))		[RFC7830] specifies the Extensions 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
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	3. General Guidance		3. General Guidance
	EDNS(0) options space: The maximum message length as dictated by		EDNS(0) options space: The maximum message length as dictated by
	protocol limitation limits the space for EDNS(0) options. Since		protocol limitation limits the space for EDNS(0) options. Since
	padding will reduce the message space available to other EDNS(0)		padding will reduce the message space available to other EDNS(0)
	options, "Padding" MUST be the last EDNS(0) option applied before a		options, "Padding" MUST be the last EDNS(0) option applied before a
	DNS message is sent.		DNS message is sent.
	Resource Conservation: Especially in situations where networking and		Resource Conservation: Especially in situations where networking and
	processing resources are scarce (eg. 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 tradeoff 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
	signifcantly change between different transport protocols, and reveal		significantly change between different transport protocols, and
	an indication of the original (unpadded) length. For example, given		reveal an indication of the original (unpadded) length. For example,
	a "Block Length" padding strategy with a block length of 32 octets,		given a "Block Length" padding strategy with a block length of 32
	and a DNS message with a size of 59 octets, the message would be		octets, and a DNS message with a size of 59 octets, the message would
	padded to 64 octets when transported over UDP. If that same message		be padded to 64 octets when transported over UDP. If that same
	was transported over TCP, and the padding strategy would consider the		message was transported over TCP, and the padding strategy would
	extra 2 octects of the length field (61 octets in total), the padded		consider the extra 2 octets of the length field (61 octets in total),
	message would be 96 octets long (as the minimum length of the Padding		the padded message would be 96 octets long (as the minimum length of
	option is 4 octets).		the Padding option is 4 octets).
	4. Padding Strategies		4. Padding Strategies
	This section is a non-exhaustive list of sensible strategies in		This section contains a recommended strategy, as well as a non-
	choosing padding length. Note that, for completeness, Appendix A		exhaustive list of other sensible strategies in choosing padding
	contains two more (non-sensible) strategies.		length. Note that, for completeness, Appendix A contains two more
			(non-sensible) strategies.
	4.1. Block Length Padding		4.1. Block Length Padding - Recommended Strategy
			Based on empirical research performed by Daniel K. Gillmor
			[dkg-padding-ndss], EDNS Padding SHOULD be performed following the
			"Block Length Padding" strategy as follows:
			(1) Clients SHOULD pad queries to the closest multiple of 128
			octets.
			(2) If a Server receives a query that includes the EDNS(0) Padding
			Option, it MUST pad the corresponding response (See Section 4 of
			RFC7830) and SHOULD pad the corresponding response to a multiple
			of 468 octets (see below).
			Note that the recommendation above applies only if DNS transport 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 EDNS(0) Padding Option increases
	the 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 above 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.2), since almost		to the "Maximal Length Padding" strategy (Section 4.2.1), since
	all messages will fit into a single block. In that case, reasonable		almost all messages will fit into a single block. In that case,
	values may be 288 bytes for the query (the maximum size of a one-		reasonable values may be 288 bytes for the query (the maximum size of
	question query over TCP, without any EDNS(0) options), and the		a one-question query over TCP, without any EDNS(0) options), and the
	EDNS(0) 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		The Block Size will interact with the MTU size. Especially for
	Section 5).		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 Padding may cause unneccessary fragmentation for UDP based
			delivery. Also, chosing a block length larger than the MTU of course
			forces to always fragment.
	4.2. Maximal Length Padding ('The Full Monty')		The empirical research cited above performed a simulation of padding,
			based on real-world DNS traffic captured on busy recursive resolvers
			of a research network. The evaluation of the performance of
			individual padding policies was based on a "cost to attacker" and
			"cost to defender" function, where the "cost to attacker" was defined
			as the percentage of query/response pairs falling into the same size
			bucket, and "cost to defender" as the size factor between padded and
			unpadded messages. Padding with a block size of 128 bytes on the
			query side, and 468 bytes on the response side was considered the
			optimum trade-off between defender and attacker cost. The response
			block size of 468 was chosen so that 3 blocks of 468 octets would
			still comfortably fit into typical Maximum Transmission Unit (MTU)
			size values.
			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 is chosen so that a multiple just fits into the MTU, Block
			Padding may cause unneccessary fragmentation for UDP based delivery.
			Also, chosing a block length larger than the MTU of course always
			forces to always fragment.
			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.
			4.2. Other Sensible Strategies
			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 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. Depending on the negotiated size, this strategy will
			commonly exceed the MTU, and then result in a consistent number of
			fragments reducing delivery probability when datagram based transport
			(such as UDP) is used.
	Maximal Length Padding is NOT RECOMMENDED.		Maximal Length Padding is NOT RECOMMENDED.
	4.3. 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 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 padding 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 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) which		Disadvantage: This policy requires a good source of (pseudo) random
	can keep up with the required message rates. Especially on busy		numbers which can keep up with the required message rates.
	servers, this may be a hindrance.		Especially on busy servers, this may be a hindrance.
	According to the limited empirical data available, Random Length		According to the limited empirical data available, Random Length
	Padding performs slightly worse than Block Length Padding.		Padding performs slightly worse than Block Length Padding.
	4.4. 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
	transction 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. 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) requires further empirical study.		strategies) requires further empirical study.
	5. Recommended Strategy		5. Acknowledgements
	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 receives a query that includes the EDNS(0) Padding
	Option, it MUST pad the corresponding response (See Section 4 of
	RFC7830) and SHOULD pad the corresponding response to a multiple
	of 468 octects.
	Note that the recommendation above does apply only if DNS transport
	is encrypted (See Section 6 of RFC 7830).
	The empirical research cited above performed a simulation of padding,
	based on real-world DNS traffic captured on busy recursive resolvers
	of a research network. The evaluation of the performance of
	individual padding policies was based on a "cost to attacker" and
	"cost to defender" function, where the "cost to attacker" was defined
	as the percentage of query/response pairs falling into the same size
	bucket, and "cost to defender" as the size factor between padded and
	unpadded messages. Padding with a block size of 128 bytes on the
	query side, and 468 bytes on the response side was considered the
	optimum trade-off between defender and attacker cost. The response
	block size of 468 was chosen so that 3 blocks of 468 octets would
	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
	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.		Magnus Westerlund, Charlie Kaufman, Joe Clarke and Meral Shirazipour
			performed reviews or provided substantial comments.
	7. IANA Considerations		6. IANA Considerations
	This document has no considerations for IANA.		This document has no considerations for IANA.
	8. Security Considerations		7. 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 EDNS(0) Padding must carefully consider which policies
	to implement, the default policy chosen, which parameters to make		to implement, the default policy chosen, which parameters to make
	configurable, and the default parameter values.		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
	inffective 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 Padding may want to choose a DNS server
	which does apply at least an equally effective Padding policy on		which does apply at least an equally effective Padding policy on
	responses.		responses.
	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 leak via other side channels (particularly timing
	information and number of query/response pairs). Counter-measures		information and number of query/response pairs). Counter-measures
	against such other side channels could include injecting artificial		against such other side channels could include injecting artificial
	"cover traffic" into the stream of DNS messages, or delaying DNS		"cover traffic" into the stream of DNS messages, or delaying DNS
	responses by a certain amount of jitter. Such strategies are out of		responses by a certain amount of jitter. Such strategies are out of
	scope of this document. Additionally, there is neither enough		scope of this document. Additionally, there is neither enough
	theoretic analysis nor experimental data available to recommend any		theoretic analysis nor experimental data available to recommend any
	such countermeasures.		such countermeasures.
	9. Changes		8. 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-04		8.1. 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.2. draft-ietf-dprive-padding-policy-04
	Changes based on WGLC: Changed implementor consideration text in		Changes based on WGLC: Changed implementor consideration text in
	Security Con section (Sara), moved "No Padding" and "Fixed Length		Security Con section (Sara), moved "No Padding" and "Fixed Length
	Padding" to appendix (Stephane, Paul), Changed TODO in Random Padding		Padding" to appendix (Stephane, Paul), Changed TODO in Random Padding
	to info from empirical study (Stephen), Added note to pad only if		to info from empirical study (Stephen), Added note to pad only if
	transport encrypted (Stephen), added intro text referencing to		transport encrypted (Stephen), added intro text referencing to
	DNSoTLS and DNSoDTLS (Stephane), added text about timing/jitter to		DNSoTLS and DNSoDTLS (Stephane), added text about timing/jitter to
	security considerations.		security considerations.
	9.2. draft-ietf-dprive-padding-policy-03		8.3. draft-ietf-dprive-padding-policy-03
	Editorial changes in various spots. Added text about excluding TCP		Editorial changes in various spots. Added text about excluding TCP
	length field, more security considerations, addressing Sara's other		length field, more security considerations, addressing Sara's other
	feedback to -02.		feedback to -02.
	9.3. draft-ietf-dprive-padding-policy-02		8.4. 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.4. draft-ietf-dprive-padding-policy-01		8.5. 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.5. draft-ietf-dprive-padding-policy-00		8.6. 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.6. draft-mayrhofer-dprive-padding-profiles-00		8.7. draft-mayrhofer-dprive-padding-profiles-00
	Initial version		Initial version
	10. References		9. References
	10.1. Normative References		9.1. 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>.
	[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>.
	10.2. Informative References		9.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>.
End of changes. 34 change blocks.
	104 lines changed or deleted		129 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/