draft-ietf-dprive-edns0-padding-02.txt		draft-ietf-dprive-edns0-padding-03.txt
	Network Working Group A. Mayrhofer		Network Working Group A. Mayrhofer
	Internet-Draft nic.at GmbH		Internet-Draft nic.at GmbH
	Intended status: Standards Track January 25, 2016		Intended status: Standards Track March 6, 2016
	Expires: July 28, 2016		Expires: September 7, 2016
	The EDNS(0) Padding Option		The EDNS(0) Padding Option
	draft-ietf-dprive-edns0-padding-02		draft-ietf-dprive-edns0-padding-03
	Abstract		Abstract
	This document specifies the EDNS(0) 'Padding' option, which allows		This document specifies the EDNS(0) 'Padding' option, which allows
	DNS clients and servers to pad request and response messages by a		DNS clients and servers to pad request and response messages by a
	variable number of octets.		variable number of octets.
	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
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 28, 2016.		This Internet-Draft will expire on September 7, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. The 'Padding' Option . . . . . . . . . . . . . . . . . . . . 3		3. The 'Padding' Option . . . . . . . . . . . . . . . . . . . . 3
	4. Usage Considerations . . . . . . . . . . . . . . . . . . . . 3		4. Usage Considerations . . . . . . . . . . . . . . . . . . . . 3
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
	8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	8.1. draft-ietf-dprive-edns0-padding-02 . . . . . . . . . . . 4		8.1. draft-ietf-dprive-edns0-padding-03 . . . . . . . . . . . 5
	8.2. draft-ietf-dprive-edns0-padding-01 . . . . . . . . . . . 5		8.2. draft-ietf-dprive-edns0-padding-02 . . . . . . . . . . . 5
	8.3. draft-ieft-dprive-edns0-padding-00 . . . . . . . . . . . 5		8.3. draft-ietf-dprive-edns0-padding-01 . . . . . . . . . . . 5
	8.4. draft-mayrhofer-edns0-padding-01 . . . . . . . . . . . . 5		8.4. draft-ieft-dprive-edns0-padding-00 . . . . . . . . . . . 5
	8.5. draft-mayrhofer-edns0-padding-00 . . . . . . . . . . . . 5		8.5. draft-mayrhofer-edns0-padding-01 . . . . . . . . . . . . 5
			8.6. draft-mayrhofer-edns0-padding-00 . . . . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	9.1. Normative References . . . . . . . . . . . . . . . . . . 5		9.1. Normative References . . . . . . . . . . . . . . . . . . 5
	9.2. Informative References . . . . . . . . . . . . . . . . . 5		9.2. Informative References . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	The Domain Name System (DNS) [RFC1035] was specified to transport DNS		The Domain Name System (DNS) [RFC1035] was specified to transport DNS
	messages in clear text form. Since this can expose significant		messages in clear text form. Since this can expose significant
	amounts of information about the internet activities of an end user,		amounts of information about the internet activities of an end user,
	the IETF has undertaken work to provide confidentiality to DNS		the IETF has undertaken work to provide confidentiality to DNS
	transactions (see the DPRIVE WG). Encrypting the DNS transport is		transactions (see the DPRIVE WG). Encrypting the DNS transport is
	considered as one of the options to improve the situation.		considered as one of the options to improve the situation.
	However, even if both DNS query and response messages were encrypted,		However, even if both DNS query and response messages were encrypted,
	meta data of could still be used to correlate such messages with well		meta data could still be used to correlate such messages with well
	known unencrypted messages, hence jeopardizing some of the		known unencrypted messages, hence jeopardizing some of the
	confidentiality gained by encryption. One such property is the		confidentiality gained by encryption. One such property is the
	message size.		message size.
	This document specifies the Extensions Mechanisms for DNS (EDNS(0))		This document specifies the Extensions Mechanisms for DNS (EDNS(0))
	"Padding" Option, which allows to artificially increase the size of a		"Padding" Option, which allows to artificially increase the size of a
	DNS message by a variable number of bytes, significantly hampering		DNS message by a variable number of bytes, hampering size-based
	size-based correlation of the encrypted message.		correlation of the encrypted message.
	2. Terminology		2. Terminology
	The terms "Requestor", "Responder" are to be interpreted as specified		The terms "Requestor", "Responder" are to be interpreted as specified
	in [RFC6891].		in [RFC6891].
	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].
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	The PADDING octets SHOULD be set to 0x00. Other values MAY be used;		The PADDING octets SHOULD be set to 0x00. Other values MAY be used;
	for example, in cases where there is a concern that the padded		for example, in cases where there is a concern that the padded
	message could be subject to compression before encryption. PADDING		message could be subject to compression before encryption. PADDING
	octets of any value MUST be accepted in messages received.		octets of any value MUST be accepted in messages received.
	4. Usage Considerations		4. Usage Considerations
	This document does not specify the actual amount of padding to be		This document does not specify the actual amount of padding to be
	used, since this depends on the situation in which the option is		used, since this depends on the situation in which the option is
	used. However, padded DNS messages MUST NOT exceed the number of		used. However, padded DNS messages MUST NOT exceed the number of
	octets specified in the Requestor's Payload Size field encoded in The		octets specified in the Requestor's Payload Size field encoded in the
	RR Class Field (see Section 6.2.3 and 6.2.4 of [RFC6891]).		RR Class Field (see Section 6.2.3 and 6.2.4 of [RFC6891]).
	Responders MUST pad DNS responses when the respective DNS query		Responders MUST pad DNS responses when the respective DNS query
	included the 'Padding' option, unless doing so would violate the		included the 'Padding' option, unless doing so would violate the
	maximum UDP payload size.		maximum UDP payload size.
	Responders MAY pad DNS responses when the respective DNS query		Responders MAY pad DNS responses when the respective DNS query
	indicated EDNS(0) support of the Requestor.		indicated EDNS(0) support of the Requestor and the 'Padding' option
			was not included.
	Responders MUST NOT pad DNS responses when the respective DNS query		Responders MUST NOT pad DNS responses when the respective DNS query
	did not indicate EDNS(0).		did not indicate EDNS(0) support.
	5. IANA Considerations		5. IANA Considerations
	IANA has assigned EDNS Option Code 12 for Padding.		IANA has assigned EDNS Option Code 12 for Padding.
	IANA is requested to update the respective registration record by		IANA is requested to update the respective registration record by
	changing the Reference field to [[THISRFC]] and the Status field to		changing the Reference field to [[THISRFC]] and the Status field to
	'Standard'.		'Standard'.
	6. Security Considerations		6. Security Considerations
	Padding DNS packets obviously increases their size, and will		Padding DNS packets obviously increases their size, and will
	therefore lead to increased traffic.		therefore lead to increased traffic.
	The use of the EDNS(0) Padding provides only a benefit when DNS		The use of the EDNS(0) Padding only provides a benefit when DNS
	packets are not transported in clear text. Implementations therefore		packets are not transported in clear text. Further, it is possible
	SHOULD avoid using this option if the DNS transport is not encrypted.		EDNS(0) Padding may make DNS amplification attacks easier.
			Implementations therefore MUST NOT use this option if the DNS
			transport is not encrypted.
	Padding length might be affected by lower-level compression.		Padding length might be affected by lower-level compression.
	Therefore (as described in Section 3.3 of [RFC7525]), implementations		Therefore (as described in Section 3.3 of [RFC7525]), implementations
	and deployments SHOULD disable TLS-level compression.		and deployments SHOULD disable TLS-level compression.
	The payload of the 'Padding' option could (like many other fields in		The payload of the 'Padding' option could (like many other fields in
	the DNS protocol) be used as a covert channel.		the DNS protocol) be used as a covert channel.
	7. Acknowledgements		7. Acknowledgements
	This document was inspired by a discussion with Daniel Kahn Gillmor		This document was inspired by a discussion with Daniel Kahn Gillmor
	during IETF93, as an alternative to the proposed padding on the TLS		during IETF93, as an alternative to the proposed padding on the TLS
	layer. Allison Mankin, Andreas Gustaffson, Christian Huitema and		layer. Allison Mankin, Andreas Gustafsson, Christian Huitema, Jinmei
	Jinmei Tatuya suggested text for this document.		Tatuya and Shane Kerr suggested text for this document.
	8. Changes		8. Changes
	Note to RFC Editors: Please remove this whole section before		Note to RFC Editors: Please remove this whole section before
	publication		publication
	8.1. draft-ietf-dprive-edns0-padding-02		8.1. draft-ietf-dprive-edns0-padding-03
			Fixed typo in Acknowledgements, added Shane. Do not use over
			unencrypted transport is now a MUST. Logic around when responders
			may send the option clarified. Reduced "hampering" claim in
			introduction.
			8.2. draft-ietf-dprive-edns0-padding-02
	Clarified that changes section is to be removed before publication.		Clarified that changes section is to be removed before publication.
	Clarified that both Requestors and Responders are to ignore padding		Clarified that both Requestors and Responders are to ignore padding
	contents. changed text about non-zero padding contents based on WGLC		contents. changed text about non-zero padding contents based on WGLC
	comments. removed security considerations about truncation based on		comments. removed security considerations about truncation based on
	WGLC comment. added more acknowledgements. replaced "packets" with		WGLC comment. added more acknowledgements. replaced "packets" with
	"messages" where appropriate.		"messages" where appropriate.
	8.2. draft-ietf-dprive-edns0-padding-01		8.3. draft-ietf-dprive-edns0-padding-01
	Fixed 'octects' typo. Changed 'covert channel' text to align with		Fixed 'octects' typo. Changed 'covert channel' text to align with
	allowing non-0x00 padding. changed IANA considerations - assigned		allowing non-0x00 padding. changed IANA considerations - assigned
	option code is 12. Changed field definitions to allow for non-0x00		option code is 12. Changed field definitions to allow for non-0x00
	padding, removed FORMERR requirement. referenced rfc7525 in security		padding, removed FORMERR requirement. referenced rfc7525 in security
	considerations. added acknowledgements.		considerations. added acknowledgements.
	8.3. draft-ieft-dprive-edns0-padding-00		8.4. draft-ieft-dprive-edns0-padding-00
	Adopted by WG. Changed text about message size limit based on		Adopted by WG. Changed text about message size limit based on
	feedback.		feedback.
	8.4. draft-mayrhofer-edns0-padding-01		8.5. draft-mayrhofer-edns0-padding-01
	Changed minimum padding size to 0, rewrote Usage Considerations		Changed minimum padding size to 0, rewrote Usage Considerations
	section, extended Security considerations section		section, extended Security considerations section
	8.5. draft-mayrhofer-edns0-padding-00		8.6. draft-mayrhofer-edns0-padding-00
	Initial version		Initial version
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
End of changes. 17 change blocks.
	26 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/