idnits 2.17.1 draft-pusateri-dnsop-private-subdomains-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1874 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) Summary: 2 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 11, 2019 5 Expires: September 12, 2019 7 Private DNS Subdomains 8 draft-pusateri-dnsop-private-subdomains-00 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 12, 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. Domain name encryption . . . . . . . . . . . . . . . . . 3 56 3.2. Zone Creation . . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Adding / Removing Resource Records . . . . . . . . . . . 5 58 3.4. Zone Destruction . . . . . . . . . . . . . . . . . . . . 6 59 4. Querying Resource Records . . . . . . . . . . . . . . . . . . 6 60 4.1. Signed Requests . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Encrypted Questions . . . . . . . . . . . . . . . . . . . 7 62 5. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Signatures in Responses . . . . . . . . . . . . . . . . . 7 64 5.2. Encrypted Records . . . . . . . . . . . . . . . . . . . . 7 65 6. Encrypted Resource Record (ENCR) . . . . . . . . . . . . . . 8 66 6.1. Encrypted Resource Record RDATA format . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Section 6.6 of [RFC7558] highlights the privacy risks of DNS service 77 announcements in clear text. While there has been a long focus on 78 access control to private services including the use of encryption 79 and authentication through TLS [RFC8446] for connections, the DNS-SD 80 announcements [RFC6763] themselves may leak private information 81 including but not limited to device types and versions, enabled 82 services on the device subject to attack, personal names and 83 identifiers used for tracking, etc. 85 Some services are meant to be advertised and used freely by devices 86 on the link but other services are restricted to an owner or group 87 and these services are announced publicly as a side effect of the 88 current service discovery deployment. 90 This document defines a method for collaborating devices to share 91 private services with one another but without revealing the existence 92 of these services in a public way. This provides an additional layer 93 of privacy protection for an individual's devices or those of a 94 defined group sharing a common purpose. 96 The additional privacy is achieved by creating private subdomains 97 that require a private key for bidirectional access to DNS queries 98 and responses for the zone. 100 This document defines a subdomain hierarchy for providers to enable 101 this feature as well as a mechanism for interoperable transfers to 102 and from the subdomain. This includes creating and destroying the 103 subdomains, adding and removing records through DNS Update, and 104 techniques for private authenticated queries and responses. 106 2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. These words may also appear in this 113 document in lower case as plain English words, absent their normative 114 meanings. 116 3. Subdomain Operations 118 An administrative domain provider will enable private subdomains by 119 creating a base subdomain at "_pvt.." In addition to the SOA 120 and NS records, a public KEY record [RFC2535], [RFC3445] MUST be 121 created at the apex which is openly available for queries. This 122 public key will be used for message encryption relating to the 123 maintenance of private subdomains. 125 The Zone bit for all KEY records used in this specification MUST be 126 set to 0. The protocol value for the KEY record is set to DNSSEC (3) 127 and the algorithm value is taken from the available algorithms 128 defined in the IANA DNS Security Algorithm Numbers. Only algorithms 129 that can be used for encryption are eligible for use in the KEY 130 record for this purpose. 132 3.1. Domain name encryption 134 Domain names in questions, responses, and updates MUST provide the 135 subdomain name in clear text to correctly route the query and cache 136 the responses in resolvers along the path. However, labels before 137 the subdomain name are encrypted to provide privacy. Therefore, 138 domain names must be encoded and decoded at the sender and receiver 139 of the DNS message. 141 Only the owner and the administrative domain provider know the true 142 contents of the records. Intermediary resolvers or forwarders simply 143 see the encrypted questions or answers as normal cacheable questions 144 or response records and can effectively return cache results like any 145 other records without being able to understand the true contents. 147 The QTYPE of a question and the RRTYPE in a response record are also 148 encoded in the name to further increase privacy and reduce record 149 type optimizations that might assume particular formats of RDATA for 150 known record types. For example, if an "A" record type was used, 151 some implementations MAY assume 4-byte RDATA and get confused by an 152 encrypted version that contains more bytes. Therefore, a Encrypted 153 Resource Record type (ENCR) is defined in Section 6 which is returned 154 in all answers. The original QTYPE and RRTYPE are prepended to the 155 original QNAME in the question or owner name in the response before 156 encrypting. The QTYPE is then always set to ENCR and the answers are 157 naturally returned with this type as well. 159 The subdomain suffix is first removed and the remaining portion of 160 the original domain name is prepended with the QTYPE or RRTYPE and 161 encrypted with the public key found in the apex of the 162 "_pvt.." Next the subdomain labels are appended in clear 163 text to the encrypted portion of the name and type. 165 Since there is a limit of 63 octets to a label, it is possible that 166 the encrypted portion of the name could surpass this limit. Further 167 work and experimentation MAY be needed to arrive at the best solution 168 to this issue and this document will be updated at that time. The 169 current solution is to include an initial byte after the length of 170 the first label containing the number of labels that make up the 171 encrypted portion of the name. Those labels will be concatenated 172 (excluding the length bytes) to form the encrypted portion of the 173 name. This encoding and decoding is only performed by the querier 174 and the authoritative server responding to the query and is 175 transparent to intermediate forwarders and resolvers. 177 3.2. Zone Creation 179 A subdomain is created by the owner in an administrative domain for 180 which the owner has a trusted relationship. For instance, if a user 181 has services provided by an administrative domain and that user has 182 been assigned a user name or account at that domain, the user could 183 then uniquely claim ownership of the subdomain 184 "._pvt.." 186 The administrative domain can use any means it finds sufficient to 187 verify the trusted relationship with the user including RADIUS, AAA, 188 email verification, or some other method not described here which may 189 include enabling the service on a per-user basis. 191 The user can then create the subdomain by sending an UPDATE [RFC2136] 192 to the MNAME of the SOA record for "_pvt.." containing a new 193 KEY record for the zone "._pvt.." The KEY record 194 contains a public key that will later be used by the administrative 195 domain to verify signed requests and send encrypted responses. If 196 this zone already exists, the UPDATE fails with RCODE YXRRSet. If 197 the zone does not exist, the user has successfully claimed the zone 198 and all subsequent operations by the user will require knowledge of 199 the private key associated with the registered public key in the KEY 200 record. The user can distribute this private key to any or all of 201 its devices for access to the private subdomain. 203 In response, appropriate NS records for "" will be created in 204 the "_pvtr.." and a new SOA record "._pvt.." 205 with appropriate record fields will also be created along side the 206 new KEY record submitted by the user. The authoritative servers for 207 the new "._pvt.." will be managed by the administrative 208 domain provider. 210 At this point, the owner has knowledge of the public key of 211 "_pvt.." and the administrative domain has knowledge of the 212 public key of "._pvt.." All subsequent operations for 213 the subdomain "._pvt.." use encrypted records based on 214 the public key of the message receiver. All operations by the owner 215 MUST included a signature using the private key which can be verified 216 by the receiver using the owners public key. In this way, the 217 records are only ever updated or revealed to an authorized user. 219 3.3. Adding / Removing Resource Records 221 Once the zone is created, the user can begin adding or removing 222 records to the "._pvt." subdomain through additional 223 UPDATE messages for the zone. The subdomain in the Zone section of 224 the UPDATE appears as usual in plain text. However, individual 225 records in the Update section of the message are encrypted with the 226 administrative domain's public KEY found at "_pvt.." In 227 order to encrypt the records to be added, they will be encoded in a 228 new resource record type defined below called an Encrypted Resource 229 Record Section 6. These records use the same CLASS as the 230 encapsulated record and contain an algorithm type to indicate how 231 they can be decrypted. 233 To ensure zone additions and deletions are from the subdomain owner, 234 the UPDATE message must be signed with the owner's private key and 235 the signature included in the additional data section in the form of 236 a SIG(0) record [RFC2931]. The owner MUST sign the encrypted form of 237 the records in the Update section in order for the receiver to 238 validate the UPDATE message before attempting to decrypt the records 239 contained within. More information about authenticating UPDATE 240 messages can be found in [RFC3007]. 242 The administrative domain provider can then use the private key 243 associated with the public key stored in the KEY record at 244 "_pvt.." to individually decrypt the resource records 245 contained in the Update section. If the records can be successfully 246 decrypted, they are added to, or removed from, the 247 "._pvt.." zone. If the records cannot be decrypted, 248 the receiver MUST return FORMERR. See section 2.5.2 of [RFC2136] for 249 the specifics of adding or removing records in the Update section. 251 In order to change the KEY record at the apex of the zone, the old 252 KEY record should be added to the Prerequisite section and the new 253 KEY record in the Update section. The entire UPDATE message MUST be 254 signed by placing the SIG(0) signature record in the Additional data 255 section. 257 This is useful for changing the algorithm or key length for the 258 public/private key pair. 260 If instead the private key associated with the public key in the KEY 261 record has been compromised, the user should contact the 262 administrative domain out of band to verify authenticity and replace 263 the KEY record through a process established by the provider. 265 3.4. Zone Destruction 267 When the owner is ready to destroy the subdomain 268 "._pvt..", it can do so by deleting the KEY record at 269 the apex through an UPDATE message. As above, the UPDATE message 270 additional data section MUST contain a SIG(0) signature over the 271 entire message. Once validated, the zone will be removed along with 272 the NS records for "" in the "_pvt." zone. The KEY 273 record containing the public key is not encrypted. 275 The owner is free to destroy and re-create the subdomain as needed 276 for as long as the relationship continues with the administrative 277 domain. 279 4. Querying Resource Records 281 The question section of a DNS query contains the QNAME, QTYPE, and 282 QCLASS. The original QNAME and QTYPE are encoded into a new 283 encrypted form and used as the QNAME of the outgoing query. The 284 outgoing QTYPE is always "ENCR". The outgoing QCLASS is not encoded 285 and contains the class of the original query. 287 4.1. Signed Requests 289 All queries MUST be signed with the private key of the owner. The 290 signature MUST be in the Additional records section in the form of a 291 SIG(0) record. If a query is received that is not signed or cannot 292 be verified with the public key in the KEY record at the apex of the 293 "._pvt..", a response containing the question as 294 received with an RCODE of REFUSED with no answers MUST be returned. 295 The Authority section of the response MUST contain the SOA record for 296 the "._pvt.." in clear text. 298 Authoritative servers MUST verify the signature in the query before 299 decoding the QNAME and returning the results. It is not necessary 300 for intermediate caching resolvers to verify the signature in the 301 query since any cached answers are already encrypted. 303 4.2. Encrypted Questions 305 When a query is received by the authoritative server for the zone, 306 the private key corresponding to the public key stored in the KEY 307 record at "_pvt." is used to decrypt the question. Only the 308 authoritative servers have the ability to decrypt the query. The 309 original question is recreated and matching records are found. 311 5. Responses 313 Responses include the encrypted version of the question (with the 314 subdomain in clear text), along with any matching answers represented 315 as Encrypted Resource Records Section 6. Likewise, the owner name 316 for each record in the answer section includes the encrypted label(s) 317 and the subdomain part in clear text. 319 5.1. Signatures in Responses 321 Response SIG(0) signature verification is difficult because the 322 receiver is not able to determine which public key to use to verify 323 the signature. The response could come from the authoritative server 324 or it could come from an intermediate caching resolver. 326 Future work will attempt to provide a way to ensure response message 327 integrity if that which is already provided by DNSSEC [RFC4034] is 328 deemed insufficient. 330 5.2. Encrypted Records 332 Each resource record included in the response is encrypted by the 333 authoritative server using the public key in the KEY record at the 334 apex of "._pvt.." These responses can be cached by 335 resolvers and returned in subsequent queries using normal DNS 336 operations. 338 The encrypted owner name of an "ENCR" record is decrypted to obtain 339 the actual owner name and RRTYPE. The "ENCR" RDATA is decrypted to 340 obtain the actual RDATA of the original record. The format of the 341 "ENCR" RDATA provides algorithm information sufficient for 342 decryption. 344 6. Encrypted Resource Record (ENCR) 346 The format of an ENCR record is defined here for use in the IANA 347 registry of DNS Resource Record Types. It contains the encrypted 348 output of an existing resource record along with the algorithm used 349 for encryption. The combination of the contents of this resource 350 record along with the public key in the KEY record is sufficient to 351 decode the encrypted contents to obtain the origin resource record. 353 List encryption algorithms here. 355 6.1. Encrypted Resource Record RDATA format 357 Show RDATA packet format here. 359 7. Security Considerations 361 Since responses are not signed, there is a opportunity for the 362 message contents to be tampered with. Fake records can not be 363 created but records could be removed from the Answer section and 364 header fields could be modified. This can be partly alleviated 365 through the use of DNSSEC. If the "ENCR" records which make up an 366 RRset have DNSSEC RRSIG signatures, the receiver can determine if 367 elements of the set have been tampered with. It cannot detect if the 368 entire set has been removed. 370 8. IANA Considerations 372 This document defines a new DNS Resource Record Type named "ENCR" 373 described as an Encrypted Resource Record with value TBD. 375 9. References 377 9.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 385 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 386 RFC 2136, DOI 10.17487/RFC2136, April 1997, 387 . 389 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 390 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 391 . 393 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 394 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 395 2000, . 397 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 398 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, 399 . 401 [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY 402 Resource Record (RR)", RFC 3445, DOI 10.17487/RFC3445, 403 December 2002, . 405 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 406 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 407 May 2017, . 409 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 410 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 411 . 413 9.2. Informative References 415 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 416 Rose, "Resource Records for the DNS Security Extensions", 417 RFC 4034, DOI 10.17487/RFC4034, March 2005, 418 . 420 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 421 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 422 . 424 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 425 "Requirements for Scalable DNS-Based Service Discovery 426 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 427 DOI 10.17487/RFC7558, July 2015, 428 . 430 Author's Address 432 Tom Pusateri 433 Unaffiliated 434 Raleigh NC 27608 435 USA 437 Phone: +1 (919) 867-1330 438 Email: pusateri@bangj.com