--- 1/draft-ietf-dnssd-push-19.txt 2019-06-18 13:13:14.658738549 -0700 +++ 2/draft-ietf-dnssd-push-20.txt 2019-06-18 13:13:14.746740785 -0700 @@ -1,19 +1,19 @@ Internet Engineering Task Force T. Pusateri Internet-Draft Unaffiliated Intended status: Standards Track S. Cheshire -Expires: September 25, 2019 Apple Inc. - March 24, 2019 +Expires: December 20, 2019 Apple Inc. + June 18, 2019 DNS Push Notifications - draft-ietf-dnssd-push-19 + draft-ietf-dnssd-push-20 Abstract The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning 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 asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to @@ -27,21 +27,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -67,28 +67,28 @@ 6.3. DNS Push Notification Updates . . . . . . . . . . . . . . 20 6.3.1. PUSH Message . . . . . . . . . . . . . . . . . . . . 20 6.4. DNS Push Notification UNSUBSCRIBE . . . . . . . . . . . . 25 6.4.1. UNSUBSCRIBE Message . . . . . . . . . . . . . . . . . 25 6.5. DNS Push Notification RECONFIRM . . . . . . . . . . . . . 27 6.5.1. RECONFIRM Message . . . . . . . . . . . . . . . . . . 28 6.6. DNS Stateful Operations TLV Context Summary . . . . . . . 30 6.7. Client-Initiated Termination . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7.1. Security Services . . . . . . . . . . . . . . . . . . . . 32 - 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 32 + 7.2. TLS Name Authentication . . . . . . . . . . . . . . . . . 33 7.3. TLS Session Resumption . . . . . . . . . . . . . . . . . 33 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction Domain Name System (DNS) records may be updated using DNS Update [RFC2136]. Other mechanisms such as a Discovery Proxy [DisProx] can also generate changes to a DNS zone. This document specifies a protocol for DNS clients to subscribe to receive asynchronous notifications of changes to RRSets of interest. It is immediately relevant in the case of DNS Service Discovery [RFC6763] but is not limited to that use case, and provides a general DNS mechanism for @@ -315,31 +315,30 @@ 6.1. Discovery The first step in DNS Push Notification subscription is to discover an appropriate DNS server that supports DNS Push Notifications for the desired zone. The client begins by opening a DSO Session to its normal configured DNS recursive resolver and requesting a Push Notification 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 - Push Notification subscription is successful, then the recursive - resolver will make a corresponding Push Notification subscription on - the client's behalf (if the recursive resolver doesn't already have - an active subscription for that name, type, and class), and pass on - any results it receives back to the client. This is closely - analogous to how a client sends normal DNS queries to its configured - DNS recursive resolver, which issues queries on the client's behalf - (if the recursive resolver doesn't already have appropriate answer(s) - in its cache), and passes on any results it receives back to the - client. + port for DNS-over-TLS [RFC7858]. If the request for a Push + Notification subscription is successful, then the recursive resolver + will make a corresponding Push Notification subscription on the + client's behalf (if the recursive resolver doesn't already have an + active subscription for that name, type, and class), and pass on any + results it receives back to the client. This is closely analogous to + how a client sends normal DNS queries to its configured DNS recursive + resolver, which issues queries on the client's behalf (if the + recursive resolver doesn't already have appropriate answer(s) in its + cache), and passes on any results it receives back to the client. In many contexts, the recursive resolver will be able to handle Push Notifications for all names that the client may need to follow. Use of VPN tunnels and split-view DNS can create some additional complexity in the client software here; the techniques to handle VPN tunnels and split-view DNS for DNS Push Notifications are the same as those already used to handle this for normal DNS queries. 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 @@ -1161,21 +1160,21 @@ C-A: Client request or unidirectional message, additional TLV CRP: Response back to client, primary TLV CRA: Response back to client, additional TLV +-------------+-----+-----+-----+-----+-----+ | TLV Type | C-P | C-U | C-A | CRP | CRA | +-------------+-----+-----+-----+-----+-----+ | SUBSCRIBE | X | | | | | | PUSH | | | | | | | UNSUBSCRIBE | | X | | | | - | RECONFIRM | X | | | | | + | RECONFIRM | | X | | | | +-------------+-----+-----+-----+-----+-----+ Table 2: DSO TLV Client Context Summary The server TLV contexts are: S-P: Server request message, primary TLV S-U: Server unidirectional message, primary TLV S-A: Server request or unidirectional message, additional TLV SRP: Response back to server, primary TLV @@ -1238,20 +1237,26 @@ The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for DNS Push Notifications [RFC8310]. Cleartext connections for DNS Push Notifications are not permissible. Since this is a new protocol, transition mechanisms from the Opportunistic Privacy profile are unnecessary. Also, see Section 9 of the DNS over (D)TLS Usage Profiles document [RFC8310] for additional recommendations for various versions of TLS 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 servers. TLS alone does not provide complete security. TLS certificate verification can provide reasonable assurance that the 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 query, if the SRV query is subverted then the client may have a secure connection to a rogue server. DNSSEC can provided added confidence that the SRV query has not been subverted. 7.1. Security Services @@ -1262,20 +1267,25 @@ Confidentiality: All application-layer communication is encrypted with the goal that no party should be able to decrypt it except the intended receiver. Data integrity protection: Any changes made to the communication in transit are detectable by the receiver. Authentication: An end-point of the TLS communication is 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 suites are beyond the scope of this document. Please refer to TLS Recommendations [RFC7525] for the best current practices. Keep in mind that best practices only exist for a snapshot in time and recommendations will continue to change. Updated versions or errata may exist for these recommendations. 7.2. TLS Name Authentication As described in Section 6.1, the client discovers the DNS Push