idnits 2.17.1 draft-bradley-dnssd-private-discovery-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: +-----------+----------+--------------------------------------------+ | Type | Name | Description | +-----------+----------+--------------------------------------------+ | 0x00 | Reserved | Reserved to protect against accidental | | | | zeroing. | | 0x01 | EPK | Ephemeral Public Key. 32-byte Curve25519 | | | | public key. | | 0x02 | TS | Timestamp. 4-byte timestamp. See | | | | Timestamps Section 4. | | 0x03 | SIG | Signature. 64-byte Ed25519 signature. | | 0x04 | ESIG | Encrypted signature. Ed25519 signature | | | | encrypted with ChaCha20-Poly1305. | | | | Formatted as the 64-byte encrypted portion | | | | followed by a 16-byte MAC (96 bytes | | | | total). | | 0x05 | EMSG | Encrypted message. Message encrypted with | | | | ChaCha20-Poly1305. Formatted as the N-byte | | | | encrypted portion followed by a 16-byte | | | | MAC (N + 16 bytes total). | | 0x06-0xFF | | Reserved for future use. Types in this | | | | range MUST not be sent. If they are | | | | received, they MUST be ignored. This is to | | | | allow future versions of document or other | | | | documents to define new types without | | | | breaking parsers. | +-----------+----------+--------------------------------------------+ -- The document date (October 22, 2018) is 2013 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) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Bradley 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track October 22, 2018 5 Expires: April 25, 2019 7 Private Discovery 8 draft-bradley-dnssd-private-discovery-00 10 Abstract 12 This document specifies a mechanism for advertising and discovering 13 in a private manner. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 25, 2019. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 51 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Probe . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.3. Announcement . . . . . . . . . . . . . . . . . . . . . . 5 55 3.4. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.5. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Implicit Nonces . . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Re-keying and Limits . . . . . . . . . . . . . . . . . . . . 7 60 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.1. TLV Items . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 10. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 Advertising and discovering with Bonjour can leak a lot of 71 information about a device or person, such as their name, the types 72 of services they provide or use, and persistent identifiers. This 73 information can be used to identify and track a person's location and 74 daily routine (e.g. buys coffee every morning at 8 AM at Starbucks on 75 Main Street). It can also reveal intimate details about a person's 76 behavior and medical conditions, such as discovery requests for a 77 glucose monitor, possibly indicating diabetes. 79 This document specifies additions to Bonjour to retain the same level 80 of advertising and discovery functionality while preserving privacy 81 and confidentiality. 83 This document does not specify how keys are provisioned. 84 Provisioning keys is complex enough to justify its own document(s). 85 This document assumes each peer has a long-term asymmetric key pair 86 (LTPK and LTSK) and communicating peers have each other's long-term 87 asymmetric public key (LTPK). 89 2. Conventions and Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119 [RFC2119]. 95 "Friend" 96 A peer you have a cryptographic relationship with. Specifically, 97 that you have the peer's LTPK. 99 "Probe" 100 A probe is an unsolicited multicast message sent to find friends 101 on the network. 103 "Announcement" 104 An announcement is an unsolicited multicast message sent to inform 105 friends on the network that you have become available or have 106 updated data. 108 "Response" 109 A response is a solicited unicast message sent in response to a 110 probe or announcement. 112 "Query" 113 A query is an unsolicited unicast message sent to get specific 114 info from a peer. 116 "Answer" 117 An answer is solicited unicast message sent in response to a query 118 to provide info or indicate the lack of info. 120 "Multicast" 121 This term is used in the generic sense of sending a message that 122 targets 0 or more peers. It's not strictly required to be a UDP 123 packet with a multicast destination address. It could be sent via 124 TCP or some other transport to a router that repeats the message 125 via unicast to each peer. 127 "Unicast" 128 This term is used in the generic sense of sending a message that 129 targets a single peer. It's not strictly required to be a UDP 130 packet with a unicast destination address. 132 Multi-byte values are encoded from the most significant byte to the 133 least significant byte (big endian). 135 When multiple items are concatenated together, the symbol "||" 136 (without quotes) between each item is used to indicate this. For 137 example, a combined item of A followed by B followed by C would be 138 written as "A || B || C". 140 3. Protocol 142 There are two techniques used to preserve privacy and provide 143 confidentiality in this document. The first is announcing, probing, 144 and responding with only enough info to allow a peer with your public 145 key to detect that it's you while hiding your identity from peers 146 without your public key. This technique uses a fresh random signed 147 with your private key using a signature algorithm that doesn't reveal 148 your public key. The second technique is to query and answer in a 149 way that only a specific friend can read the data. This uses 150 ephemeral key exchange and symmetric encryption and authentication. 152 3.1. Probe 154 A probe is sent via multicast to discover friends on the network. A 155 probe contains a fresh, ephemeral public key (EPK1), a timestamp 156 (TS1), and a signature (SIG1). This provides enough for a friend to 157 identify the source, but doesn't allow non-friends to identify it. 159 Probe Fields: 161 o EPK1 (Ephemeral Public Key 1). 163 o TS1 (Timestamp 1). See Timestamps Section 4. 165 o SIG1 (Signature of "Probe" || EPK1 || TS1 || "End"). 167 When a peer receives a probe, it verifies TS1. If TS1 is outside the 168 time window then it SHOULD be ignored. It then attempts to verify 169 SIG1 with the public key of each of its friends. If verification 170 fails for all public keys then it ignores the probe. If a 171 verification succeeds for a public key then it knows which friend 172 sent the probe. It SHOULD send a response to the friend. 174 3.2. Response 176 A response contains a fresh, ephemeral public key (EPK2) and a 177 symmetrically encrypted signature (ESIG2). The encryption key is 178 derived by first generating a fresh ephemeral public key (EPK2) and 179 its corresponding secret key (ESK2) and performing Diffie-Hellman 180 (DH) using EPK1 and ESK2 to compute a shared secret. The shared 181 secret is used to derive a symmetric session key (SSK2). A signature 182 of the payload is generated (SIG2) using the responder's long-term 183 secret key (LTSK2). The signature is encrypted with SSK2 (ESIG2). 184 The nonce for ESIG2 is 1 and is not included in the response. The 185 response is sent via unicast to the sender of the probe. 187 When the friend that sent the probe receives the response, it 188 performs DH, symmetrically verifies ESIG2 and, if successful, 189 decrypts it to reveal SIG2. It then tries to verify SIG2 with the 190 public keys of all of its friends. If a verification succeeds for a 191 public key then it knows which friend sent the response. If any 192 steps fail, the response is ignored. If all steps succeed, it 193 derives a session key (SSK1). Both session keys (SSK1 and SSK2) are 194 remembered for subsequent communication with the friend. 196 Response Fields: 198 o EPK2 (Ephemeral Public Key 2). 200 o ESIG2 (Encrypted Signature of "Response" || EPK2 || EPK1 || TS1 || 201 "End"). 203 Key Derivation values: 205 o SSK1: HKDF-SHA-512 with Salt = "SSK1-Salt", Info = "SSK1-Info", 206 Output size = 32 bytes. 208 o SSK2: HKDF-SHA-512 with Salt = "SSK2-Salt", Info = "SSK2-Info", 209 Output size = 32 bytes. 211 3.3. Announcement 213 An announcement indicates availability to friends on the network or 214 if it has update(s). It is sent whenever a device joins a network 215 (e.g. joins WiFi, plugged into Ethernet, etc.), its IP address 216 changes, or when it has an update for one or more of its private 217 Bonjour records (but not for public Bonjour records since those are 218 handled using non-private Bonjour methods). Announcements are sent 219 via multicast. 221 Announcement Fields: 223 o EPK1 (Ephemeral Public Key 1). 225 o TS1 (Timestamp 1). See Timestamps Section 4. 227 o SIG1 (Signature of "Announcement" || EPK1 || TS1 || "End"). 229 When a peer receives an announcement, it verifies TS1. If TS1 is 230 outside the time window then it SHOULD be ignored. It then attempts 231 to verify SIG1 with the public key of each of its friends. If 232 verification fails for all public keys then it ignores the probe. If 233 a verification succeeds for a public key then it knows which friend 234 sent the announcement. 236 3.4. Query 238 A query is sent via unicast to request specific info from a friend. 239 The raw DNS query records are generated the same way as a non-private 240 Bonjour query (e.g. PTR, SRV, TXT, etc.). Once this data is 241 generated (MSG1), it's encrypted with the symmetric session key (SSK1 242 for the original prober or SSK2 for the original responder) for the 243 target friend previously generated via the probe/response exchange. 244 This encrypted field is EMSG1. The nonce for EMSG1 is 1 larger than 245 the last nonce used with this symmetric key and is not included in 246 the query. For example, if this is the first message sent to this 247 friend after the probe/response then the nonce would be 2. The query 248 is sent via unicast to the friend. 250 When the friend receives a query, it symmetrically verifies EMSG1 251 against every active session's key and, if one is successful (which 252 also identifies the friend), it decrypts the field. If verification 253 fails, the query is ignored, If verification succeeds, the query is 254 processed. 256 Query Fields: 258 o EMSG1 (Encrypted DNS query(s)). 260 3.5. Answer 262 An answer is sent via unicast in response to a query from a friend. 263 The raw DNS answer records are generated the same way as a non- 264 private Bonjour answer (e.g. PTR, SRV, TXT, etc.). Once this data 265 is generated (MSG2), it's encrypted with the symmetric session key of 266 the destination friend (SSK1 it was the original prober or SSK2 if it 267 was the original responder from the previous probe/response 268 exchange). This encrypted field is EMSG2. The nonce for EMSG2 is 1 269 larger than the last nonce used with this symmetric key and is not 270 included in the answer. For example, if this is the first message 271 sent to this friend after the probe/response then the nonce would be 272 2. The answer is sent via unicast to the friend. 274 When the friend receives an answer, it symmetrically verifies EMSG2 275 against every active session's key and, if one is successful (which 276 also identifies the friend), it decrypts the field. If verification 277 fails, the answer is ignored, If verification succeeds, the answer is 278 processed. 280 Answer Fields: 282 o EMSG2 (Encrypted DNS answer(s)). 284 4. Timestamps 286 A timestamp in this document is the number of seconds since 287 2001-01-01 00:00:00 UTC. Timestamps sent in messages SHOULD be 288 randomized by +/- 30 seconds to reduce the fingerprinting ability of 289 observers. A timestamp of 0 means the sender doesn't know the 290 current time (e.g. lacks a battery-backed RTC and access to an NTP 291 server). Receivers MAY use a timestamp of 0 to decide whether to 292 enforce time window restrictions. This can allow discovery in 293 situations where one or more devices don't know the current time 294 (e.g. location without Internet access). 296 A timestamp is considered valid if it's within N seconds of the 297 current time of the receiver. The RECOMMENDED value of N is 900 298 seconds (15 minutes) to allow peers to remain discoverable even after 299 a large amount of clock drift. 301 5. Implicit Nonces 303 The nonces in this document are integers that increment by 1 for each 304 encryption. Nonces are never included in any message. Including 305 nonces in messages would enable transactions to be easily tracked by 306 following nonce 1, 2, 3, etc. This may seem futile if other layers 307 of the system also leak trackable identifiers, such as IP addresses, 308 but those problems can be solved by other documents. Random nonces 309 could avoid tracking, but make replay protection difficult by 310 requiring the receiver to remember previously received messages to 311 detect a replay. 313 One issue with implicit nonces and replay protection in general is 314 handling lost messages. Message loss and reordering is expected and 315 shouldn't cause complete failure. Accepting nonces within N of the 316 expected nonce enables recovery from some loss and reordering. When 317 a message is received, the expected nonce is checked first and then 318 nonce + 1, nonce - 1, up to nonce +/- N. The RECOMMENDED value of N 319 is 8 as a balance between privacy, robustness, and performance. 321 6. Re-keying and Limits 323 Re-keying is a hedge against key compromise. The underlying 324 algorithms have limits that far exceed reasonable usage (e.g. 96-bit 325 nonces), but if a key was revealed then we want to reduce the damage 326 by periodically re-keying. 328 Probes are periodically re-sent with a new ephemeral public key in 329 case the previous key pair was compromised. The RECOMMENDED maximum 330 probe ephemeral public key lifetime is 20 hours. This is close to 1 331 day since people often repeat actions on a daily basis, but with some 332 leeway for natural variations. If a probe ephemeral public key is 333 re-generated for other reasons, such as joining a WiFi network, the 334 refresh timer is reset. 336 Session keys are periodically re-key'd in case a symmetric key was 337 compromised. The RECOMMENDED maximum session key lifetime is 20 338 hours or 1000 messages, whichever comes first. This uses the same 339 close-to-a-day reasoning as probes, but adds a maximum number of 340 messages to reduce the potential for exposure when many messages are 341 being exchanged. Responses SHOULD be throttled if it appears that a 342 peer is making an excessive number of requests since this may 343 indicate the peer is probing for weaknesses (e.g. timing attacks, 344 ChopChop-style attacks). 346 7. Message Formats 348 The data defined by this document are contained within DNS records as 349 specified in RFC 6195 [RFC6195].. The following DNS Resource Record 350 (RR) types are specified. Note that these are from the "Private Use" 351 range for now, but will presumably move to the normal range after 352 IETF review: 354 +--------------+---------+------------------+ 355 | Name | RR Type | Description | 356 +--------------+---------+------------------+ 357 | Probe | 0xFF00 | See Section 3.1. | 358 | Response | 0xFF01 | See Section 3.2. | 359 | Announcement | 0xFF02 | See Section 3.3. | 360 | Query | 0xFF03 | See Section 3.4. | 361 | Answer | 0xFF04 | See Section 3.5. | 362 +--------------+---------+------------------+ 364 The RData within each DNS record is a Type-Length-Value with an 8-bit 365 type and a 16-bit length (TLV8x16). It has the following format. 367 +--------+-------------+--------------------------------------------+ 368 | Field | Size | Description | 369 | | (bytes) | | 370 +--------+-------------+--------------------------------------------+ 371 | Type | 1 | Identifies a value type as defined in | 372 | | | Section 7.1. | 373 | Length | 2 | Length of the value field in bytes. | 374 | Value | Variable | Value formatted based on the type field. | 375 +--------+-------------+--------------------------------------------+ 377 7.1. TLV Items 379 The following lists the TLV items defined by this document. 381 +-----------+----------+--------------------------------------------+ 382 | Type | Name | Description | 383 +-----------+----------+--------------------------------------------+ 384 | 0x00 | Reserved | Reserved to protect against accidental | 385 | | | zeroing. | 386 | 0x01 | EPK | Ephemeral Public Key. 32-byte Curve25519 | 387 | | | public key. | 388 | 0x02 | TS | Timestamp. 4-byte timestamp. See | 389 | | | Timestamps Section 4. | 390 | 0x03 | SIG | Signature. 64-byte Ed25519 signature. | 391 | 0x04 | ESIG | Encrypted signature. Ed25519 signature | 392 | | | encrypted with ChaCha20-Poly1305. | 393 | | | Formatted as the 64-byte encrypted portion | 394 | | | followed by a 16-byte MAC (96 bytes | 395 | | | total). | 396 | 0x05 | EMSG | Encrypted message. Message encrypted with | 397 | | | ChaCha20-Poly1305. Formatted as the N-byte | 398 | | | encrypted portion followed by a 16-byte | 399 | | | MAC (N + 16 bytes total). | 400 | 0x06-0xFF | | Reserved for future use. Types in this | 401 | | | range MUST not be sent. If they are | 402 | | | received, they MUST be ignored. This is to | 403 | | | allow future versions of document or other | 404 | | | documents to define new types without | 405 | | | breaking parsers. | 406 +-----------+----------+--------------------------------------------+ 408 8. Security Considerations 410 o Privacy considerations are specified in draft-cheshire-dnssd- 411 privacy-considerations. 413 o Ephemeral key exchange uses elliptic curve Diffie-Hellman (ECDH) 414 with Curve25519 as specified in RFC 7748 [RFC7748]. 416 o Signing and verification uses Ed25519 as specified in RFC 8032 417 [RFC8032]. 419 o Symmetric encryption uses ChaCha20-Poly1305 as specified in RFC 420 7539 [RFC7539]. 422 o Key derivation uses HKDF as specified in RFC 5869 [RFC5869] with 423 SHA-512 as the hash function. 425 o Randoms and randomization MUST use cryptographic random numbers. 427 Information leaks may still be possible in some situations. For 428 example, an attacker could capture probes from a peer they've 429 identified and replay them elsewhere within the allowed timestamp 430 window. This could be used to determine if a friend of that friend 431 is present on that network. 433 The network infrastructure may leak identifiers in the form of 434 persistent IP addresses and MAC addresses. Mitigating this requires 435 changes outside of Bonjour, such as periodically changing IP 436 addresses and MAC addresses. 438 9. IANA Considerations 440 The DNS record and TLV types defined by this document are intended to 441 be managed by IANA. 443 10. To Do 445 The following are some of the things that still need to be specified 446 and decided: 448 o Figure out how sleep proxies might work with this protocol. 450 o Define probe and announcement random delays to reduce collisions. 452 o Describe when to use the same EPK2 in a response to reduce churn 453 on probe/response collisions. 455 o Consider randomly answering probes for non-friends to mask real 456 friends. 458 11. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 466 Key Derivation Function (HKDF)", RFC 5869, 467 DOI 10.17487/RFC5869, May 2010, 468 . 470 [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA 471 Considerations", RFC 6195, DOI 10.17487/RFC6195, March 472 2011, . 474 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 475 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 476 . 478 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 479 for Security", RFC 7748, DOI 10.17487/RFC7748, January 480 2016, . 482 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 483 Signature Algorithm (EdDSA)", RFC 8032, 484 DOI 10.17487/RFC8032, January 2017, 485 . 487 Author's Address 489 Bob Bradley 490 Apple Inc. 491 One Apple Park Way 492 Cupertino CA 95014 493 USA 495 Email: bradley@apple.com