< draft-ietf-dnsop-server-cookies-02.txt		draft-ietf-dnsop-server-cookies-03.txt >
	DNSOP Working Group O. Sury		DNSOP Working Group O. Sury
	Internet-Draft Internet Systems Consortium		Internet-Draft Internet Systems Consortium
	Updates: 7873 (if approved) W. Toorop		Updates: 7873 (if approved) W. Toorop
	Intended status: Standards Track NLnet Labs		Intended status: Standards Track NLnet Labs
	Expires: May 21, 2020 D. Eastlake 3rd		Expires: November 21, 2020 D. Eastlake 3rd
	Futurewei Technologies		Futurewei Technologies
	M. Andrews		M. Andrews
	Internet Systems Consortium		Internet Systems Consortium
	November 18, 2019		May 20, 2020
	Interoperable Domain Name System (DNS) Server Cookies		Interoperable Domain Name System (DNS) Server Cookies
	draft-ietf-dnsop-server-cookies-02		draft-ietf-dnsop-server-cookies-03
	Abstract		Abstract
	DNS cookies, as specified in RFC 7873, are a lightweight DNS		DNS cookies, as specified in RFC 7873, are a lightweight DNS
	transaction security mechanism that provides limited protection to		transaction security mechanism that provides limited protection to
	DNS servers and clients against a variety of denial-of-service and		DNS servers and clients against a variety of denial-of-service and
	amplification, forgery, or cache poisoning attacks by off-path		amplification, forgery, or cache poisoning attacks by off-path
	attackers.		attackers.
	This document provides precise directions for creating Server Cookies		This document provides precise directions for creating Server Cookies
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 May 21, 2020.		This Internet-Draft will expire on November 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	8. Security and Privacy Considerations . . . . . . . . . . . . . 9		8. Security and Privacy Considerations . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
	Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11		Appendix B. Test vectors . . . . . . . . . . . . . . . . . . . . 11
	B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11		B.1. Learning a new Server Cookie . . . . . . . . . . . . . . 11
	B.2. The same client learning a renewed (fresh) Server Cookie 12		B.2. The same client learning a renewed (fresh) Server Cookie 12
	B.3. Another client learning a renewed Server Cookie . . . . . 13		B.3. Another client learning a renewed Server Cookie . . . . . 13
	B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14		B.4. IPv6 query with rolled over secret . . . . . . . . . . . 14
			Appendix C. Implementation status . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	DNS cookies, as specified in [RFC7873], are a lightweight DNS		DNS cookies, as specified in [RFC7873], are a lightweight DNS
	transaction security mechanism that provides limited protection to		transaction security mechanism that provides limited protection to
	DNS servers and clients against a variety of denial-of-service and		DNS servers and clients against a variety of denial-of-service and
	amplification, forgery, or cache poisoning attacks by off-path		amplification, forgery, or cache poisoning attacks by off-path
	attackers. This document specifies a means of producing		attackers. This document specifies a means of producing
	interoperable strong cookies so that an anycast server set including		interoperable strong cookies so that an anycast server set including
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 41 ¶
	This document has suggestions on Client Cookie construction in		This document has suggestions on Client Cookie construction in
	Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT		Section 3. The previous example in Appendix A.2 of [RFC7873] is NOT
	RECOMMENDED.		RECOMMENDED.
	3. Constructing a Client Cookie		3. Constructing a Client Cookie
	The Client Cookie is a cryptographic nonce and should be treated as		The Client Cookie is a cryptographic nonce and should be treated as
	such. It is RECOMMENDED to create a new Client Cookie for each new		such. It is RECOMMENDED to create a new Client Cookie for each new
	upstream server a Client connects to. The Client Cookie SHOULD have		upstream server a Client connects to. The Client Cookie SHOULD have
	at least 64-bits of entropy.		64-bits of entropy.
	When a Server does not support DNS Cookies, the Client MUST NOT send		When a Server does not support DNS Cookies, the Client MUST NOT send
	the same Client Cookie to that same Server again. Instead, it is		the same Client Cookie to that same Server again. Instead, it is
	recommended that the Client does not send a Client Cookie to that		recommended that the Client does not send a Client Cookie to that
	Server for a certain period, like for example five minutes, before it		Server for a certain period, like for example five minutes, before it
	retries with a new Client Cookie.		retries with a new Client Cookie.
	When a Server does support DNS Cookies, the Client should store the		When a Server does support DNS Cookies, the Client should store the
	Client Cookie alongside the Server Cookie it registered for that		Client Cookie alongside the Server Cookie it registered for that
	Server.		Server.
	skipping to change at page 15, line 22 ¶		skipping to change at page 15, line 22 ¶
	;example.net. IN A		;example.net. IN A
	;; ANSWER SECTION:		;; ANSWER SECTION:
	example.net. 86400 IN A 192.0.2.34		example.net. 86400 IN A 192.0.2.34
	;; Query time: 6 msec		;; Query time: 6 msec
	;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53)		;; SERVER: 2001:db8:8f::53#53(2001:db8:8f::53)
	;; WHEN: Wed Jun 5 13:36:57 UTC 2019		;; WHEN: Wed Jun 5 13:36:57 UTC 2019
	;; MSD SIZE rcvd: 84		;; MSD SIZE rcvd: 84
			Appendix C. Implementation status
			At the time of writing, BIND from version 9.16 and Knot DNS from
			version 2.9.0 create Server Cookies according to the recipe described
			in this draft. Unbound and NSD have an Proof of Concept
			implementation that has been tested for interoperability during the
			hackathon at the IETF104 in Prague. Construction of privacy
			maintaining Client Cookies according to the directions in this draft
			have been implemented in the getdns library and will be in the
			upcoming getdns-1.6.1 release and in Stubby version 0.3.1.
	Authors' Addresses		Authors' Addresses
	Ondrej Sury		Ondrej Sury
	Internet Systems Consortium		Internet Systems Consortium
	CZ		CZ
	Email: ondrej@isc.org		Email: ondrej@isc.org
	Willem Toorop		Willem Toorop
	NLnet Labs		NLnet Labs
End of changes. 8 change blocks.
	6 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/