idnits 2.17.1 draft-huitema-dnssd-tls-privacy-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 10, 2019) is 1845 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 164 -- Looks like a reference, but probably isn't: '16' on line 215 == Missing Reference: 'Ack' is mentioned on line 251, but not defined == Outdated reference: A later version (-07) exists of draft-huitema-quic-dnsoquic-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-02 == Outdated reference: A later version (-08) exists of draft-ietf-dnssd-prireq-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Standards Track D. Kaiser 5 Expires: September 11, 2019 University of Konstanz 6 March 10, 2019 8 Private Discovery with TLS-ESNI 9 draft-huitema-dnssd-tls-privacy-00 11 Abstract 13 DNS-SD (DNS Service Discovery) normally discloses information about 14 both the devices offering services and the devices requesting 15 services. This information includes host names, network parameters, 16 and possibly a further description of the corresponding service 17 instance. Especially when mobile devices engage in DNS Service 18 Discovery over Multicast DNS at a public hotspot, a serious privacy 19 problem arises. 21 We propose to solve this problem by developing a private discovery 22 profile for UDP based transports using TLS, such as DTLS and QUIC. 23 The profile is based on using the Encrypted SNI extension. We also 24 define a standalone private discovery service, that can be combined 25 with arbitrary applications in the same way as DNS-SD. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 11, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Discovery Service Using TLS and ESNI . . . . . . . . . . . . 3 64 2.1. Discovery Key . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. ESNI extension for discovery . . . . . . . . . . . . . . 5 66 2.3. Integration with DTLS . . . . . . . . . . . . . . . . . . 5 67 2.4. Integration with QUIC . . . . . . . . . . . . . . . . . . 7 68 3. Private Discovery DNS Service . . . . . . . . . . . . . . . . 8 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 4.1. Denial of service by spoofed response . . . . . . . . . . 9 71 4.2. Discovery Key compromise . . . . . . . . . . . . . . . . 9 72 4.3. Private Discovery Key compromise . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. Experimental use . . . . . . . . . . . . . . . . . . . . 10 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 7.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless 84 service discovery in local networks. It is very convenient for 85 users, but it requires the public exposure of the offering and 86 requesting identities along with information about the offered and 87 requested services. Parts of the published information can seriously 88 breach the user's privacy. These privacy issues and potential 89 solutions are discussed in [KW14a] and [KW14b]. 91 When analyzing these scenarios in [I-D.ietf-dnssd-prireq], we find 92 that the DNS-SD messages leak identifying information such as the 93 instance name, the host name or service properties. 95 We propose here a discovery solution that can replace DNS-SD in 96 simple deployment scenarios, with the following characteristics: 98 1. We only target discovery of peers on the same local network, 99 using multicast. We make no attempt at compatibility with the 100 server based solutions such as DNSSD over Unicast DNS [RFC6763]. 102 2. We do not attempt to keep the same formats as mDNS [RFC6762]. 104 3. We assume a solution that can be integrated in an application, 105 without dependency on system support. 107 The proposed solution aligns with TLS 1.3 [RFC8446], and specifically 108 with transports of TLS over UDP, such as DTLS [I-D.ietf-tls-dtls13] 109 or QUIC [I-D.ietf-quic-transport]. The solution uses SNI encryption 110 [I-D.ietf-tls-esni]. 112 The solution assumes that entities who want to be privately 113 discovered maintain an asymmetric discovery key pair. The public 114 component of that discovery key pair and the service name of the 115 entity are provisioned to authorized discovery clients. In this 116 document, we will refer to this public component as the "Discovery 117 Key" of the server. When needed, we will refer to the private 118 component of the key pair as the "Discovery Private Key". 120 1.1. Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Discovery Service Using TLS and ESNI 128 In the proposed solution, the first packet of a TLS-based UDP 129 transport is broadcast or multicast over the local network. These 130 packet carry the TLS 1.3 ClientHello message, including an Encrypted 131 SNI (ESNI) extension. The ESNI is encrypted with the Discovery Key 132 of the requested service. 134 The services who are ready to be discovered listend on the broadcast 135 or multicast address and check whether the received packets contain a 136 TLS 1.3 ClientHello Message and an ESNI extension. If the extension 137 can be decrypted with the Private Discovery Key of the local service, 138 they set up a connection. 140 This mechanism only works with TLS based protocols operating over 141 UDP, such as DTLS or QUIC. 143 2.1. Discovery Key 145 Private discovery relies on the privacy of the server Discovery Key, 146 which is used to encrypt the target server name carried in the ESNI 147 extension. Clients can only discover a server if they know the 148 server's Discovery Key. Servers receiving a properly encrypted 149 discovery request do not know the identity of the client issuing the 150 request, but they know that the client belongs to a group authorized 151 to perform the discovery. 153 In the ESNI based specification, the server's Discovery Key plays the 154 same role as the ESNI Encryption Key of the client facing server, but 155 a major difference is that the Discovery Key is kept private. 156 According to standard ESNI, the client facing server publish an ESNI 157 encryption key in the DNS. In contrast, the Discovery Key MUST NOT 158 be publicly available in the DNS. 160 The discovery key is passed to the peer in exactly the same format as 161 ESNI: 163 struct { 164 uint8 checksum[4]; 165 KeyShareEntry keys<4..2^16-1>; 166 CipherSuite cipher_suites<2..2^16-2>; 167 uint16 padded_length; 168 uint64 not_before; 169 uint64 not_after; 170 Extension extensions<0..2^16-1>; 171 } ESNIKeys; 173 This document does not discuss how the Discovery Key is provisioned 174 to authorized discovery clients. 176 The ESNI extension design assumes that several services are available 177 through a single client facing server. These different services have 178 different SNI values and length. ESNI pads these SNI to a padded 179 length specified for the client facing server, ensuring that third 180 parties cannot infer the identity of the service from the length of 181 the extension. In our design, requests for multiple services are 182 sent over multicast. If different services used different padding 183 length, third parties could infer the service identity from the ESNI 184 length. To provent this information leakage, services participating 185 in private discovery MUST set the padded length to exactly 128 bytes. 187 2.2. ESNI extension for discovery 189 The ESNI extension is defined in [I-D.ietf-tls-esni] as: 191 struct { 192 CipherSuite suite; 193 KeyShareEntry key_share; 194 opaque record_digest<0..2^16-1>; 195 opaque encrypted_sni<0..2^16-1>; 196 } ClientEncryptedSNI; 198 In standard ESNI usage, the "record_digest" identifies the ESNI 199 Encryption Key. Clients using private discovery MUST leave the 200 "record_digest" empty, and encode it as a zero-length binary string. 201 The ESNI Encryption Key will be the Discovery Key of the target 202 server. 204 The KeyShareEntry is set in accordance with the ESNI specification. 205 It is combined with the server Discovery Key to encrypt the SNI. 206 According to the ESNI specification, the encrypted structure 207 contains: 209 struct { 210 ServerNameList sni; 211 opaque zeros[ESNIKeys.padded_length - length(sni)]; 212 } PaddedServerNameList; 214 struct { 215 uint8 nonce[16]; 216 PaddedServerNameList realSNI; 217 } ClientESNIInner; 219 Servers that receive the extension as part of private discovery 220 attempt to decrypt the value using their Private Discovery Key. If 221 the decryption succeeds, and if the decrypted SNI corresponds to the 222 expected value, the server will accept the discovery request. 224 2.3. Integration with DTLS 226 The message flows of DTLS 1.3 [I-D.ietf-tls-dtls13] all start with 227 the client sending a TLS ClientHello message. The following figure 228 presents a simple DTLS flow using the ESNI extension for private 229 discovery: 231 Client Server 233 ClientHello +----------+ 234 + key_share* | Flight 1 | 235 + ESNI --------> +----------+ 237 ServerHello 238 + key_share* +----------+ 239 {EncryptedExtensions} | Flight 2 | 240 {ESNI} +----------+ 241 {Certificate*} 242 <-------- {Finished} 243 [Application Data*] 245 +----------+ 246 | Flight 3 | 247 {Finished} --------> +----------+ 248 [Application Data] 250 +----------+ 251 <-------- [Ack] | Flight 4 | 252 [Application Data*] +----------+ 254 [Application Data] <-------> [Application Data] 256 The first flight consists of a single UDP packet. In classic DTLS, 257 this would be sent to the IP address and UDP port chosen for the 258 application. Instead, the client using private discovery MUST sent 259 this to the "private discovery" multicast address defined in 260 Section 5 and to the UDP port chosen for the application. 262 The multicast message sent by the client will be received by many 263 servers. The servers using private discovery MUST verify that the 264 ESNI extension is present. If it is present, each server attempts to 265 decrypt the ESNI extension using the local private discovery key, as 266 specified in Section 2.2. If the verification succeeds, the server 267 proceeds with the connection, and sends the second flight of DTLS 268 packets to the IP address and UDP port from which it received the 269 client's first flight. 271 The client receiving the second flight of messages processe them as 272 specified in DTLS 1.3 [I-D.ietf-tls-dtls13]. The client MUST verify 273 that the ESNI extension is present, and matches the expected value as 274 specified in Section 2.2. If the ESNI extension is absent or does 275 not pass verification, the entire flight MUST be ignored. If the 276 verification succeeds, the client remembers the IP address and UDP 277 port of the server, and uses it for the reminder of the session. 279 A successful ESNI exchange demonstrtes to the server that the client 280 has knowledge of the server discovery key, and to the client that the 281 server is in possession of the corresponding private discovery key. 282 This is meant to restrict access to a subset of the client and server 283 population, but does not replace the need for server authenttication 284 and optional client authentication as specified in TLS 1.3. 286 2.4. Integration with QUIC 288 The QUIC Transport uses TLS to negotiate encryption keys. The use of 289 TLS in QUIC is specified in [I-D.ietf-quic-tls], and can be 290 summarized as follow: 292 1. The QUIC connection starts with the client sending an Initial 293 message, carrying a TLS ClientHello and its extensions. 295 2. The server replies with its own Initial message, carrying the 296 server hello and establishing the "handshake" keys used to 297 protect the reminder of the TLS 1.3 exchange. 299 3. Server and client exchange encrypted Handshake messages to verify 300 that the session is properly established and to negotiate the 301 encryption keys of the application data. 303 4. Server and Client exchange encrypted application messages until 304 they decide to close the connection. 306 All messages are sent over UDP. 308 When using Private Discovery, the client adds an ESNI extension to 309 the ClientHello sent in the Initial message. The ESNI extension is 310 formated a specified in Section 2.2. In classic QUIC, the Initial 311 message would be sent in a UDP packet to the IP address and UDP port 312 of the server. Instead, the client using private discovery MUST sent 313 this to the "private discovery" multicast address defined in 314 Section 5 and to the UDP port chosen for the application. 316 The multicast message sent by the client will be received by many 317 servers. The servers using private discovery MUST verify that the 318 ESNI extension is present. If it is present, each server attempts to 319 decrypt the ESNI extension using the local private discovery key, as 320 specified in Section 2.2. If the verification succeeds, the server 321 proceeds with the connection, and sends the next QUIC packets to the 322 IP address and UDP port from which it received the client's first 323 flight. 325 The client receiving the second flight of messages processe them as 326 specified in DTLS 1.3 [I-D.ietf-tls-dtls13]. The client MUST verify 327 that the ESNI extension is present, and matches the expected value as 328 specified in Section 2.2. If the ESNI extension is absent or does 329 not pass verfication, the entire QUIC connection MUST be ignored. If 330 the verification succeeds, the client remembers the IP address and 331 UDP port of the server, and uses it for the reminder of the QUIC 332 connection. 334 3. Private Discovery DNS Service 336 The mechanisms discussed in Section 2 assume that an application 337 based on DTLS or QUIC is modified to enable private local discovery. 338 This does not cover all services. The other services can be 339 supported by a two-phase process in which each application is paired 340 with an implementation of the private discovery service. 342 The private discovery service is an implementation of DNS over QUIC, 343 as specified in [I-D.huitema-quic-dnsoquic], modified to also 344 implement the Private Discovery over Quic defined in Section 2.4. 345 The DNS implementation is solely for the purpose of providing an 346 equivalent service to DNS-SD. 348 The Private Discovery DNS Service is run by the service that wants to 349 be discovered. The name of the discovery service is the name of the 350 service that needs to be discovered. The client are provisioned with 351 the associated Discovery Key. The discovers the Private Discovery DNS 352 Service, and can then use it to obtain the DNS records associated 353 with the application service: SRV, TXT, A or AAAA records. 355 4. Security Considerations 357 The use of TLS 1.3 and the ESNI extension provides robust defenses 358 agaisnt attacks. In particular, Private Discovery benefits from the 359 defenses against dictionary attacks and replay attacks built in the 360 ESNI design. Protections against a residual DOS attack is discussed 361 in Section 4.1. 363 The privacy of the discovery relies on keeping secret the discovery 364 key of the service. The consequences and partial mitigation of 365 leaking the discovery key are discussed in Section 4.2. 367 Compromising of the server's private discovery key will allow 368 attacker to break the privacy of the discovery, as discussed in 369 Section 4.3. 371 4.1. Denial of service by spoofed response 373 Attackers may try to disrupt a private discovery handshake by sending 374 a spoofed Server Hello (DTLS) or a spoofed Server Initial packet 375 (QUIC). The client will reject these attempts after noticing that 376 the encrypted extensions do not include a proper ESNI extension, 377 containing the expected copy of the ESNI nonce. 379 Attackers will not succeed spoofing the server, but they could 380 succeed in denying the connection if the fake response arrives before 381 the response from the actual server, and if the implementation just 382 gave up the attempt after failing to validate the first response that 383 it received. 385 To defend against this attack, implementations SHOULD keep listening 386 for responses and attempting validation until they receive at least 387 one valid response from the expected server. 389 4.2. Discovery Key compromise 391 The Discovery Key is known by all the authorized clients. If one of 392 these clients is compromised, the privacy of the server will be 393 compromised: attackers will be able to spoof the authorized client 394 and discover whether the server is present on a local network. 395 However, the leak can only be exploited in an active attack: the 396 attacker must actively set up a connection with the target server. 398 The attack is mitigated when the server migrates to a different 399 discovery key and restricts the availability of that key to non- 400 compromised clients. 402 Exploiting a compromized discovery key normally requires that the 403 attacker be present on the same link as the target. Attackers might 404 try to work around that limitation by sending unicast packet targeted 405 at plausible server locations. Servers participating in private 406 discovery MUST NOT accept discovery requests arriving from off-link 407 sources. 409 4.3. Private Discovery Key compromise 411 The private component of the asymmetric key pair used for discovery 412 MUST be kept secret by the server. If it is compromised, attackers 413 can process discovery requests and verify that they can be decrypted 414 with the server's private discovery key. They could also process 415 logs of of old discovery attempts. 417 The design provides two mitigations against the consequences of this 418 failure: 420 o The discovery requests do not uniquely identify the client, and 421 the attacker will only know that an attempt came from one of the 422 authorized clients. 424 o The actual communications are protected by TLS, and inherit from 425 the forward secrecy properties of TLS 1.3. 427 5. IANA Considerations 429 IANA is required to allocate the IPv6 multicast address FF02:: 430 for use as "Private Discovery Multicast Address" described in this 431 document. 433 5.1. Experimental use 435 **RFC Editor's Note:** Please remove this section prior to 436 publication of a final version of this document. 438 Early experiments MAY use the address FF02::60DB:F6C5. This address 439 is marked in the IANA registry as unassigned. 441 6. Acknowledgments 443 [[TODO]] 445 7. References 447 7.1. Normative References 449 [I-D.huitema-quic-dnsoquic] 450 Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. 451 Iyengar, "Specification of DNS over Dedicated QUIC 452 Connections", draft-huitema-quic-dnsoquic-06 (work in 453 progress), March 2019. 455 [I-D.ietf-quic-tls] 456 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 457 draft-ietf-quic-tls-18 (work in progress), January 2019. 459 [I-D.ietf-quic-transport] 460 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 461 and Secure Transport", draft-ietf-quic-transport-18 (work 462 in progress), January 2019. 464 [I-D.ietf-tls-dtls13] 465 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 466 Datagram Transport Layer Security (DTLS) Protocol Version 467 1.3", draft-ietf-tls-dtls13-30 (work in progress), 468 November 2018. 470 [I-D.ietf-tls-esni] 471 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 472 "Encrypted Server Name Indication for TLS 1.3", draft- 473 ietf-tls-esni-02 (work in progress), October 2018. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 481 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 482 . 484 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 485 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 486 . 488 7.2. Informative References 490 [I-D.ietf-dnssd-prireq] 491 Huitema, C., "DNS-SD Privacy and Security Requirements", 492 draft-ietf-dnssd-prireq-00 (work in progress), September 493 2018. 495 [KW14a] Kaiser, D. and M. Waldvogel, "Adding Privacy to Multicast 496 DNS Service Discovery", DOI 10.1109/TrustCom.2014.107, 497 2014, . 500 [KW14b] Kaiser, D. and M. Waldvogel, "Efficient Privacy Preserving 501 Multicast DNS Service Discovery", 502 DOI 10.1109/HPCC.2014.141, 2014, 503 . 506 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 507 DOI 10.17487/RFC6762, February 2013, 508 . 510 Authors' Addresses 512 Christian Huitema 513 Private Octopus Inc. 514 Friday Harbor, WA 98250 515 U.S.A. 517 Email: huitema@huitema.net 518 URI: http://privateoctopus.com/ 520 Daniel Kaiser 521 University of Konstanz 522 Konstanz 78457 523 Germany 525 Email: daniel.kaiser@uni-konstanz.de