idnits 2.17.1 draft-pusateri-dnsop-private-subdomains-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2019) is 1853 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3445 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group T. Pusateri 3 Internet-Draft Unaffiliated 4 Intended status: Experimental March 24, 2019 5 Expires: September 25, 2019 7 Private DNS Subdomains 8 draft-pusateri-dnsop-private-subdomains-01 10 Abstract 12 This document describes a method of providing private DNS subdomains 13 such that each subdomain can be shared among multiple devices of a 14 single owner or group. A private subdomain can be used for sharing 15 personal services while increasing privacy and limiting knowledge of 16 scarce resources. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 25, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. Subdomain Operations . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Zone Creation . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Adding / Removing Resource Records . . . . . . . . . . . 4 57 3.3. Zone Destruction . . . . . . . . . . . . . . . . . . . . 5 58 4. Querying Resource Records . . . . . . . . . . . . . . . . . . 5 59 4.1. Signed Requests . . . . . . . . . . . . . . . . . . . . . 5 60 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Section 6.6 of [RFC7558] highlights the privacy risks of DNS service 70 announcements in clear text. While there has been a long focus on 71 access control to private services including the use of encryption 72 and authentication through TLS [RFC8446] for connections, the DNS-SD 73 announcements [RFC6763] themselves may leak private information 74 including but not limited to device types and versions, enabled 75 services on the device subject to attack, personal names and 76 identifiers used for tracking, etc. 78 Some services are meant to be advertised and used freely by devices 79 on the link but other services are restricted to an owner or group 80 and these services are announced publicly as a side effect of the 81 current service discovery deployment. 83 This document defines a method for collaborating devices to share 84 private services with one another but without revealing the existence 85 of these services in a public way. This provides an additional layer 86 of privacy protection for an individual's devices or those of a 87 defined group sharing a common purpose. 89 The additional privacy is achieved by creating private subdomains 90 that require a private key for bidirectional access to DNS queries 91 and responses for the zone. 93 This document defines a subdomain hierarchy for providers to enable 94 this feature as well as a mechanism for interoperable transfers to 95 and from the subdomain. This includes creating and destroying the 96 subdomains, adding and removing records through DNS Update, and 97 private authenticated queries. 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. These words may also appear in this 106 document in lower case as plain English words, absent their normative 107 meanings. 109 3. Subdomain Operations 111 An administrative domain provider will enable private subdomains by 112 creating a base subdomain at "_pvt.." In addition to the SOA 113 and NS records, a public KEY record [RFC2535], [RFC3445] MUST be 114 created at the apex which is openly available for queries. This 115 public key will be used for message encryption relating to the 116 maintenance of private subdomains. 118 The Zone bit for all KEY records used in this specification MUST be 119 set to 0. The protocol value for the KEY record is set to DNSSEC (3) 120 and the algorithm value is taken from the available algorithms 121 defined in the IANA DNS Security Algorithm Numbers. 123 3.1. Zone Creation 125 A subdomain is created by the owner in an administrative domain for 126 which the owner has a trusted relationship. For instance, if a user 127 has services provided by an administrative domain and that user has 128 been assigned a user name or account at that domain, the user could 129 then uniquely claim ownership of the subdomain 130 "._pvt.." 132 The administrative domain can use any means it finds sufficient to 133 verify the trusted relationship with the user including RADIUS, AAA, 134 email verification, or some other method not described here which may 135 include enabling the service on a per-user basis. 137 The user can then create the subdomain by sending an UPDATE [RFC2136] 138 to the MNAME of the SOA record for "_pvt.." containing a new 139 KEY record for the zone "._pvt.." The KEY record 140 contains a public key that will later be used by the administrative 141 domain to verify signed requests. If this zone already exists, the 142 UPDATE fails with RCODE YXRRSet. If the zone does not exist, the 143 user has successfully claimed the zone and all subsequent operations 144 by the user will require knowledge of the private key associated with 145 the registered public key in the KEY record. The user can distribute 146 this private key to any or all of its devices for access to the 147 private subdomain. 149 In response, appropriate NS records for "" will be created in 150 the "_pvtr.." and a new SOA record "._pvt.." 151 with appropriate record fields will also be created along side the 152 new KEY record submitted by the user. The authoritative servers for 153 the new "._pvt.." will be managed by the administrative 154 domain provider. 156 At this point, the owner has knowledge of the public key of 157 "_pvt.." and the administrative domain has knowledge of the 158 public key of "._pvt.." All subsequent operations for 159 the subdomain "._pvt.." are signed with the private key 160 of the sender. The administrative domain provider can verify the 161 sender should have access to the records in the private zone and the 162 owner can verify the received records are authentic and haven't been 163 tampered with. 165 3.2. Adding / Removing Resource Records 167 Once the zone is created, the user can begin adding or removing 168 records to the "._pvt." subdomain through additional 169 UPDATE messages for the zone. 171 To ensure zone additions and deletions are from the subdomain owner, 172 the UPDATE message must be signed with the owner's private key and 173 the signature included in the additional data section in the form of 174 a SIG(0) record [RFC2931]. More information about authenticating 175 UPDATE messages can be found in [RFC3007]. 177 If the administrative domain provider can verify the signature with 178 the subdomain owner's public key, the records are added to, or 179 removed from, the "._pvt.." zone. See section 2.5.2 of 180 [RFC2136] for the specifics of adding or removing records in the 181 Update section. 183 In order to change the KEY record at the apex of the zone, the old 184 KEY record should be added to the Prerequisite section and the new 185 KEY record in the Update section. Then the message is signed with 186 the subdomain owner's private key. 188 This is useful for changing the algorithm or key length for the 189 public/private key pair. 191 If instead the private key associated with the public key in the KEY 192 record has been compromised, the user should contact the 193 administrative domain out of band to verify authenticity and replace 194 the KEY record through a process established by the provider. 196 3.3. Zone Destruction 198 When the owner is ready to destroy the subdomain 199 "._pvt..", it can do so by deleting the KEY record at 200 the apex through an UPDATE message. As above, the UPDATE message 201 additional data section MUST contain a SIG(0) signature over the 202 entire message. Once validated, the zone will be removed along with 203 the NS records for "" in the "_pvt." zone. 205 The owner is free to destroy and re-create the subdomain as needed 206 for as long as the relationship continues with the administrative 207 domain. 209 4. Querying Resource Records 211 Only the owner and the administrative domain provider know the true 212 contents of the records. Queries must be made through direct 213 connections to an authoritative server for the subdomain over a TLS 214 connection. If the authoritative server also provides connections 215 over UDP or TCP without TLS, queries for records in private zones 216 over non-TLS connections MUST return an RCODE containing REFUSED. 218 4.1. Signed Requests 220 All queries MUST be signed with the private key of the owner. The 221 signature MUST be in the Additional records section in the form of a 222 SIG(0) record. If a query is received that is not signed or cannot 223 be verified with the public key in the KEY record at the apex of the 224 "._pvt..", a response containing the question as 225 received with an RCODE of REFUSED with no answers MUST be returned. 226 The Authority section of the response MUST contain the SOA record for 227 the "._pvt.." 229 Authoritative servers MUST verify the signature in the query before 230 returning the results. 232 5. Responses 234 6. Security Considerations 236 The Strict Privacy Usage Profile for DNS over TLS is REQUIRED for 237 connections to the authoritative name servers [RFC8310]. Since this 238 is a new protocol, transition mechanisms from the Opportunistic 239 Privacy profile are unnecessary. 241 See Section 9 of [RFC8310] for additional recommendations for various 242 versions of TLS usage. 244 DNSSEC is RECOMMENDED for the authentication of authoritative DNS 245 servers. TLS alone does not provide complete security. TLS 246 certificate verification can provide reasonable assurance that the 247 client is really communicating with the server associated with the 248 desired host name, but since the desired host name is learned via a 249 DNS query, if the DNS response is subverted then the client may have 250 a secure connection to a rogue server. DNSSEC can provide added 251 confidence that the response has not been subverted. 253 Deployment recommendations on the appropriate key lengths and cypher 254 suites are beyond the scope of this document. Please refer to TLS 255 Recommendations [RFC7525] for the best current practices. Consider 256 that best practices only exist for a snapshot in time and 257 recommendations will continue to change. Updated versions or errata 258 may exist for these recommendations. 260 The authoritative server connection endpoint SHOULD be authenticated 261 using DANE TLSA records for the associated DNS record used to 262 determine the name (SOA, SRV, etc). This associates the target's 263 name with a trusted TLS certificate [RFC7673]. This procedure uses 264 the TLS Sever Name Indication (SNI) extension [RFC6066] to inform the 265 server of the name the client has authenticated through the use of 266 TLSA records. Therefore, if the DNS record used to obtain the name 267 passes DNSSEC validation and a TLSA record matching the target name 268 is useable, an SNI extension must be used for the target name to 269 ensure the client is connecting to the server it has authenticated. 270 If the target name does not have a usable TLSA record, then the use 271 of the SNI extension is optional. See Usage Profiles for DNS over 272 TLS and DNS over DTLS [RFC8310] for more information on 273 authenticating domain names. 275 7. References 277 7.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 285 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 286 RFC 2136, DOI 10.17487/RFC2136, April 1997, 287 . 289 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 290 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 291 . 293 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 294 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 295 2000, . 297 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 298 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 299 . 301 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 302 Resource Record (RR)", RFC 3445, DOI 10.17487/RFC3445, 303 December 2002, . 305 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 306 Extensions: Extension Definitions", RFC 6066, 307 DOI 10.17487/RFC6066, January 2011, 308 . 310 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 311 "Recommendations for Secure Use of Transport Layer 312 Security (TLS) and Datagram Transport Layer Security 313 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 314 2015, . 316 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 317 Based Authentication of Named Entities (DANE) TLSA Records 318 with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 319 2015, . 321 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 322 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 323 May 2017, . 325 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 326 for DNS over TLS and DNS over DTLS", RFC 8310, 327 DOI 10.17487/RFC8310, March 2018, 328 . 330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 332 . 334 7.2. Informative References 336 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 337 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 338 . 340 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 341 "Requirements for Scalable DNS-Based Service Discovery 342 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 343 DOI 10.17487/RFC7558, July 2015, 344 . 346 Author's Address 348 Tom Pusateri 349 Unaffiliated 350 Raleigh NC 27608 351 USA 353 Phone: +1 (919) 867-1330 354 Email: pusateri@bangj.com