draft-ietf-dnssd-push-19.txt		draft-ietf-dnssd-push-20.txt
	Internet Engineering Task Force T. Pusateri		Internet Engineering Task Force T. Pusateri
	Internet-Draft Unaffiliated		Internet-Draft Unaffiliated
	Intended status: Standards Track S. Cheshire		Intended status: Standards Track S. Cheshire
	Expires: September 25, 2019 Apple Inc.		Expires: December 20, 2019 Apple Inc.
	March 24, 2019		June 18, 2019
	DNS Push Notifications		DNS Push Notifications
	draft-ietf-dnssd-push-19		draft-ietf-dnssd-push-20
	Abstract		Abstract
	The Domain Name System (DNS) was designed to return matching records		The Domain Name System (DNS) was designed to return matching records
	efficiently for queries for data that are relatively static. When		efficiently for queries for data that are relatively static. When
	those records change frequently, DNS is still efficient at returning		those records change frequently, DNS is still efficient at returning
	the updated results when polled, as long as the polling rate is not		the updated results when polled, as long as the polling rate is not
	too high. But there exists no mechanism for a client to be		too high. But there exists no mechanism for a client to be
	asynchronously notified when these changes occur. This document		asynchronously notified when these changes occur. This document
	defines a mechanism for a client to be notified of such changes to		defines a mechanism for a client to be notified of such changes to
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 September 25, 2019.		This Internet-Draft will expire on December 20, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 32 ¶		skipping to change at page 2, line 32 ¶
	6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20		6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20
	6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20		6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20
	6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25		6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25
	6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25		6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25
	6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27		6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27
	6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28		6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28
	6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30		6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30
	6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31		6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 32		7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32		7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32
	7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 32		7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33
	7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33		7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	10.1. Normative References . . . . . . . . . . . . . . . . . . 34		10.1. Normative References . . . . . . . . . . . . . . . . . . 35
	10.2. Informative References . . . . . . . . . . . . . . . . . 36		10.2. Informative References . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	Domain Name System (DNS) records may be updated using DNS Update		Domain Name System (DNS) records may be updated using DNS Update
	[RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can		[RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can
	also generate changes to a DNS zone. This document specifies a		also generate changes to a DNS zone. This document specifies a
	protocol for DNS clients to subscribe to receive asynchronous		protocol for DNS clients to subscribe to receive asynchronous
	notifications of changes to RRSets of interest. It is immediately		notifications of changes to RRSets of interest. It is immediately
	relevant in the case of DNS Service Discovery [RFC6763] but is not		relevant in the case of DNS Service Discovery [RFC6763] but is not
	limited to that use case, and provides a general DNS mechanism for		limited to that use case, and provides a general DNS mechanism for
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 14 ¶
	6.1. Discovery		6.1. Discovery
	The first step in DNS Push Notification subscription is to discover		The first step in DNS Push Notification subscription is to discover
	an appropriate DNS server that supports DNS Push Notifications for		an appropriate DNS server that supports DNS Push Notifications for
	the desired zone.		the desired zone.
	The client begins by opening a DSO Session to its normal configured		The client begins by opening a DSO Session to its normal configured
	DNS recursive resolver and requesting a Push Notification		DNS recursive resolver and requesting a Push Notification
	subscription. This connection is made to TCP port 853, the default		subscription. This connection is made to TCP port 853, the default
	port for DNS-over-TLS DNS over TLS [RFC7858]. If the request for a		port for DNS-over-TLS [RFC7858]. If the request for a Push
	Push Notification subscription is successful, then the recursive		Notification subscription is successful, then the recursive resolver
	resolver will make a corresponding Push Notification subscription on		will make a corresponding Push Notification subscription on the
	the client's behalf (if the recursive resolver doesn't already have		client's behalf (if the recursive resolver doesn't already have an
	an active subscription for that name, type, and class), and pass on		active subscription for that name, type, and class), and pass on any
	any results it receives back to the client. This is closely		results it receives back to the client. This is closely analogous to
	analogous to how a client sends normal DNS queries to its configured		how a client sends normal DNS queries to its configured DNS recursive
	DNS recursive resolver, which issues queries on the client's behalf		resolver, which issues queries on the client's behalf (if the
	(if the recursive resolver doesn't already have appropriate answer(s)		recursive resolver doesn't already have appropriate answer(s) in its
	in its cache), and passes on any results it receives back to the		cache), and passes on any results it receives back to the client.
	client.
	In many contexts, the recursive resolver will be able to handle Push		In many contexts, the recursive resolver will be able to handle Push
	Notifications for all names that the client may need to follow. Use		Notifications for all names that the client may need to follow. Use
	of VPN tunnels and split-view DNS can create some additional		of VPN tunnels and split-view DNS can create some additional
	complexity in the client software here; the techniques to handle VPN		complexity in the client software here; the techniques to handle VPN
	tunnels and split-view DNS for DNS Push Notifications are the same as		tunnels and split-view DNS for DNS Push Notifications are the same as
	those already used to handle this for normal DNS queries.		those already used to handle this for normal DNS queries.
	If the recursive resolver does not support DNS over TLS, or does		If the recursive resolver does not support DNS over TLS, or does
	support DNS over TLS but is not listening on TCP port 853, or does		support DNS over TLS but is not listening on TCP port 853, or does
	skipping to change at page 30, line 25 ¶		skipping to change at page 30, line 25 ¶
	C-A: Client request or unidirectional message, additional TLV		C-A: Client request or unidirectional message, additional TLV
	CRP: Response back to client, primary TLV		CRP: Response back to client, primary TLV
	CRA: Response back to client, additional TLV		CRA: Response back to client, additional TLV
	+-------------+-----+-----+-----+-----+-----+		+-------------+-----+-----+-----+-----+-----+
	| TLV Type | C-P | C-U | C-A | CRP | CRA |		| TLV Type | C-P | C-U | C-A | CRP | CRA |
	+-------------+-----+-----+-----+-----+-----+		+-------------+-----+-----+-----+-----+-----+
	| SUBSCRIBE | X | | | | |		| SUBSCRIBE | X | | | | |
	| PUSH | | | | | |		| PUSH | | | | | |
	| UNSUBSCRIBE | | X | | | |		| UNSUBSCRIBE | | X | | | |
	| RECONFIRM | X | | | | |		| RECONFIRM | | X | | | |
	+-------------+-----+-----+-----+-----+-----+		+-------------+-----+-----+-----+-----+-----+
	Table 2: DSO TLV Client Context Summary		Table 2: DSO TLV Client Context Summary
	The server TLV contexts are:		The server TLV contexts are:
	S-P: Server request message, primary TLV		S-P: Server request message, primary TLV
	S-U: Server unidirectional message, primary TLV		S-U: Server unidirectional message, primary TLV
	S-A: Server request or unidirectional message, additional TLV		S-A: Server request or unidirectional message, additional TLV
	SRP: Response back to server, primary TLV		SRP: Response back to server, primary TLV
	skipping to change at page 32, line 17 ¶		skipping to change at page 32, line 17 ¶
	The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS		The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS
	Push Notifications [RFC8310]. Cleartext connections for DNS Push		Push Notifications [RFC8310]. Cleartext connections for DNS Push
	Notifications are not permissible. Since this is a new protocol,		Notifications are not permissible. Since this is a new protocol,
	transition mechanisms from the Opportunistic Privacy profile are		transition mechanisms from the Opportunistic Privacy profile are
	unnecessary.		unnecessary.
	Also, see Section 9 of the DNS over (D)TLS Usage Profiles document		Also, see Section 9 of the DNS over (D)TLS Usage Profiles document
	[RFC8310] for additional recommendations for various versions of TLS		[RFC8310] for additional recommendations for various versions of TLS
	usage.		usage.
			As a consequence of requiring TLS, client certificate authentication
			and verification may also be enforced by the server for stronger
			client-server security or end-to-end security. However,
			recommendations for security in particular deployment scenarios are
			outside the scope of this document.
	DNSSEC is RECOMMENDED for the authentication of DNS Push Notification		DNSSEC is RECOMMENDED for the authentication of DNS Push Notification
	servers. TLS alone does not provide complete security. TLS		servers. TLS alone does not provide complete security. TLS
	certificate verification can provide reasonable assurance that the		certificate verification can provide reasonable assurance that the
	client is really talking to the server associated with the desired		client is really talking to the server associated with the desired
	host name, but since the desired host name is learned via a DNS SRV		host name, but since the desired host name is learned via a DNS SRV
	query, if the SRV query is subverted then the client may have a		query, if the SRV query is subverted then the client may have a
	secure connection to a rogue server. DNSSEC can provided added		secure connection to a rogue server. DNSSEC can provided added
	confidence that the SRV query has not been subverted.		confidence that the SRV query has not been subverted.
	7.1. Security Services		7.1. Security Services
	skipping to change at page 32, line 41 ¶		skipping to change at page 32, line 47 ¶
	Confidentiality: All application-layer communication is encrypted		Confidentiality: All application-layer communication is encrypted
	with the goal that no party should be able to decrypt it except		with the goal that no party should be able to decrypt it except
	the intended receiver.		the intended receiver.
	Data integrity protection: Any changes made to the communication in		Data integrity protection: Any changes made to the communication in
	transit are detectable by the receiver.		transit are detectable by the receiver.
	Authentication: An end-point of the TLS communication is		Authentication: An end-point of the TLS communication is
	authenticated as the intended entity to communicate with.		authenticated as the intended entity to communicate with.
			Anti-replay protection: TLS provides for the detection of and
			prevention against messages sent previously over a TLS connection
			(such as DNS Push Notifications). Prior messages cannot be re-
			sent at a later time as a form of a man-in-the-middle attack.
	Deployment recommendations on the appropriate key lengths and cypher		Deployment recommendations on the appropriate key lengths and cypher
	suites are beyond the scope of this document. Please refer to TLS		suites are beyond the scope of this document. Please refer to TLS
	Recommendations [RFC7525] for the best current practices. Keep in		Recommendations [RFC7525] for the best current practices. Keep in
	mind that best practices only exist for a snapshot in time and		mind that best practices only exist for a snapshot in time and
	recommendations will continue to change. Updated versions or errata		recommendations will continue to change. Updated versions or errata
	may exist for these recommendations.		may exist for these recommendations.
	7.2. TLS Name Authentication		7.2. TLS Name Authentication
	As described in Section 6.1, the client discovers the DNS Push		As described in Section 6.1, the client discovers the DNS Push
End of changes. 11 change blocks.
	21 lines changed or deleted		31 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/