idnits 2.17.1 draft-sullivan-tls-anonymous-tickets-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 'SHOULD not' in this paragraph: Clients negotiate use of anonymous tickets via a new ExtensionType, anonymous_tickets(TBD). The extension_data for this extension MUST be empty, i.e., have length of 0. Servers that support ticket requests MAY echo this extension in the EncryptedExtensions, and SHOULD not send NewSessionTickets without receiving an AnonymousTicketRequest message from the client. Clients MUST NOT send anonymous ticket requests to servers that do not signal support for this message. If absent from a ClientHello, servers MUST NOT generate responses to AnonymousTicketRequests issued by the client. -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CloudflareResumption' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 462, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC7301' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'Springall16' is defined on line 481, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-rescorla-tls-semistatic-dh-00 == Outdated reference: A later version (-01) exists of draft-wood-linkable-identifiers-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sullivan 3 Internet-Draft Cloudflare 4 Intended status: Informational C. Wood 5 Expires: September 12, 2019 Apple Inc. 6 March 11, 2019 8 Anonymous Tickets for TLS 1.3 9 draft-sullivan-tls-anonymous-tickets-00 11 Abstract 13 This document describes a mechanism that enables unlinkable session 14 resumption for TLS 1.3 without server-side state. In contrast to 15 existing ticket-based resumption in TLS 1.3, wherein servers 16 construct and issue tickets to clients, this document specifies a 17 mechanism by which clients request "anonymous tickets" from servers. 18 When a session is resumed using an anonymous ticket, a server only 19 learns that it previously engaged in a session with some client, 20 rather than linking it to a specific client. Anonymous tickets are 21 only useful for clients with idempotent early data to send. 23 DISCLAIMER: This draft has not seen any significant security analysis 24 and may contain major errors. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Anonymous Ticket Protocol . . . . . . . . . . . . . . . . . . 4 64 3.1. Anonymous Ticket Requests and Responses . . . . . . . . . 5 65 3.2. Anonymous Ticket Resumption . . . . . . . . . . . . . . . 6 66 3.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Token Derivation . . . . . . . . . . . . . . . . . . . . . . 7 68 5. 0-RTT Data Implications . . . . . . . . . . . . . . . . . . . 8 69 6. Linkability Beyond TLS . . . . . . . . . . . . . . . . . . . 8 70 6.1. Network-Layer Linkability . . . . . . . . . . . . . . . . 8 71 6.2. Application-Layer Linkability . . . . . . . . . . . . . . 8 72 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 DISCLAIMER: This is a work-in-progress draft and as such has not seen 84 any significant security analysis and may contain major errors. 86 TLS session tickets enable temporal cross-connection linkability. 87 Per [RFC8446], session tickets are recommended to carry an encryption 88 of the session resumption_master_secret, from which clients and 89 servers derive keying material for subsequent upon resumption. With 90 such tickets, servers can stitch together resumed sessions from the 91 same client over time. This can be exploited to build a profile of 92 client and application behavior. 94 In this document, we describe a mechanism for TLS 1.3 [RFC8446] by 95 which sessions may be resumed in a way that does compromise client 96 privacy via cross-connection linkability. It reverses the process in 97 which tickets are granted. Rather than the server construct and 98 issue a ticket to the client, a client requests a blinded or 99 anonymous ticket from the server. Upon resumption with an anonymous 100 ticket, the server can only learn that the session is linked to some 101 client with which a session previously existed. Absent per-client 102 keys for deriving anonymous tickets, servers cannot link resumed 103 sessions to any specific session in the past. Anonymous tickets are 104 built on an oblivious pseudorandom function (OPRF) protocol, 105 described in [I-D.sullivan-cfrg-voprf]. 107 Anonymous tickets MUST only be used when clients have idempotent 108 early data to send. Absent this data, clients SHOULD perform a fresh 109 connection without resumption. 111 Anonymous tickets only address linkability within TLS. They do not 112 address linkability based on network-layer information such as IP 113 addresses or application-layer information such as HTTP cookies. 115 1.1. Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Preliminaries 123 The proposal in this document is based on a two party OPRF protocol 124 between a client C and server S. Specifically, we use the OPRF 125 protocol of Jarecki et al. [Jarecki16], which is described in {{!I- 126 D.sullivan-cfrg-voprf} and summarized here for completeness. Let G 127 be a cyclic group of prime order q, and g be a generator of this 128 group. Let k be a OPRF key chosen at random from Z_q, that is, the 129 integers modulo q. Let H1 be a hash function that maps arbitrary 130 input to G, and H2 be a hash function that maps arbitrary input to a 131 fixed-length digest. The OPRF is built on blinded exponentiation, 132 which dates back to Chaum's seminal work on blind signatures for 133 untraceable payments [Chaum]. The actual PRF computation is as 134 follows: 136 F(k, x) = y = H2(x, H1(x)^k) 138 The protocol for this PRF works as follows. Let x be the point of 139 interest to be evaluated. 141 1. C generates a random element r (the blind) in Z_q, and computes p 142 = (1/r) in Z_q. 144 2. C computes a = H1(x)^r. 146 3. C sends a to S. 148 4. S computes b = a^k = H1(x)^{rk}. 150 5. S sends b to C. 152 6. C removes the blind by computing c = b^p = H1(x)^k. 154 7. C finishes the PRF computation by computing y = H2(x, c). 156 This protocol is a secure PRF in the random oracle model. 158 3. Anonymous Ticket Protocol 160 The key idea for anonymous tickets is that, rather than servers 161 issuing tickets to clients at will, clients request "anonymous 162 tickets" from the server by executing the OPRF protocol outlined in 163 Section 2. The server is free to provide such a ticket or reject the 164 request with a suitable NACK. The protocol for fetching a ticket is 165 outlined below. Let k be a suitable OPRF key owned by the server for 166 constructing anonymous tickets. (Typically, such session ticket 167 "encryption" keys are symmetric. Here, k is asymmetric.) 169 1. C generates random element x in Z_q as discussed in Section 4. 171 2. C computes a = H1(x)^r, where r is a random element in Z_q and H1 172 is the hash function as described in Section Section 2. 174 3. S computes b = a^k (=(H1(x)^r)^k = H1(x)^{rk}) and sends the 175 result back to C. 177 4. C removes the blind r by computing b^{r^{-1}} = (a^k)^(r^{-1}) = 178 H1(x)^k. 180 5. C finishes the PRF computation by computing y = H2(x, H1(x)^k). 182 At this point, the client has y = F(k, x), where F is the PRF output 183 computed by the OPRF protocol. By the nature of the PRF, y is 184 unpredictable given only x without access to k. 186 We now describe how clients resume sessions using this anonymous 187 ticket. We will use PSK resumption from TLS 1.3 for illustration 188 purposes. 190 1. C derives the PSK as sk = HKDF-Expand-Label(y, "anonyous-ticket- 191 psk", "", Hash.length). 193 2. C builds the PreSharedKeyExtension with a PSKIdentity and 194 PSKBinderEntry, where PSKIdentity = x and PSKBinderEntry = 195 HMAC(sk, Transcript-Hash(ClientHello1[truncated]). 197 3. S parses the PreSharedKeyExtension and, from x, re-computes y and 198 sk using k. (That is, it computes y = H2(x, H1(x)^k), and then 199 derives sk.) 201 4. S verifies the PSK binder. If valid, S uses y as the PSK for the 202 session as detailed in [RFC8446]. 204 3.1. Anonymous Ticket Requests and Responses 206 Anonymous tickets may be requested via an AnonymousTicketRequest 207 post-handshake message, anonymous_ticket_request(TBD). Its structure 208 is shown below. 210 struct { 211 opaque identifier<0..255>; 212 opaque context<0..2^16-1>; 213 } AnonymousTicketRequest; 215 o identifier: A unique value for this anonymous ticket request. 216 Clients SHOULD fill this in with a monotonically increasing 217 counter. 219 o context: An opaque context to be used when generating the 220 anonymous ticket request. Clients and servers may use this 221 context to implement or exchange data to be included in the ticket 222 computation. Clients SHOULD make this field empty if it is not 223 needed. 225 When requesting an anonymous ticket, the contents of the 226 AnonymousTicketRequest message are populated as follows: 228 o identifier: A value unique to the ticket request, i.e., a counter. 230 o context: The value a (=H1(x)^r). 232 Upon receipt of a TicketRequest message, servers MAY reply with a 233 NewSessionTicket message, shown below as defined in [RFC8446]. 235 struct { 236 uint32 ticket_lifetime; 237 uint32 ticket_age_add; 238 opaque ticket_nonce<1..255>; 239 opaque ticket<1..2^16-1>; 240 Extension extensions<0..2^16-2>; 241 } NewSessionTicket; 243 The new ticket message MUST carry two extensions, ticket_identifer 244 and ticket_context, defined below. 246 enum { 247 ... 248 ticket_identifier(TBD), 249 ticket_context(TBD+1), 250 (65535) 251 } ExtensionType; 253 The value of ticket_identifier MUST match that of the corresponding 254 AnonymousTicketRequest identifier field. The value of ticket_context 255 MAY be used by servers to convey ticket context to clients. Its 256 value MUST be empty if the corresponding AnonymousTicketRequest 257 context field is empty. NewSessionTicket.ticket MUST carry the value 258 b (=H1(x)^{rk}). The remaining fields of the NewSessionTicket 259 message are populated as specified in [RFC8446]. 261 3.2. Anonymous Ticket Resumption 263 When resuming a TLS 1.3 connection using an anonymous ticket, clients 264 do the following: 266 1. Derive the PSK as outlined in Section 3. 268 2. Construct the PSKIdentity as outlined in Section 3. 269 Specifically, set PSKIdentity.identity to x, and 270 PSKIdentity.obfuscated_ticket_age to (R + 271 NewSessionTicket.ticket_age_add) mod 2^32, where R is a random 272 value sampled from (now(), now() + 273 NewSessionTicket.ticket_lifetime]. (This value MUST be sampled 274 uniformly from this range.) 276 3. Use the PSK and PSKIdentity to construct a PreSharedKeyExtension 277 extension for the ClientHello. 279 4. Include an empty anonymous_tickets extension in the ClientHello. 281 Upon receipt of such a ClientHello, servers SHOULD derive the PSK as 282 outlined in Section 3, verify the PSK binder, and proceed with the 283 connection according to [RFC8446]. 285 3.3. Negotiation 287 Clients negotiate use of anonymous tickets via a new ExtensionType, 288 anonymous_tickets(TBD). The extension_data for this extension MUST 289 be empty, i.e., have length of 0. Servers that support ticket 290 requests MAY echo this extension in the EncryptedExtensions, and 291 SHOULD not send NewSessionTickets without receiving an 292 AnonymousTicketRequest message from the client. Clients MUST NOT 293 send anonymous ticket requests to servers that do not signal support 294 for this message. If absent from a ClientHello, servers MUST NOT 295 generate responses to AnonymousTicketRequests issued by the client. 297 4. Token Derivation 299 Anonymous ticket generation requires the offered value x to be 300 unlinkable to any session state stored by client or server. Thus, 301 one approach would be to randomly generate x independent of session 302 state. While the PRF security properties ensure that F(k, x) is 303 unpredictable given only x, a faulty or backdoored PRNG could be 304 exploited to force clients to produce repeated values of x. This 305 could be exploited to identify and link compromised clients, for 306 example. 308 Thus, the token should be generated from a secret into which both the 309 client and server have contributed randomness. This can be done by 310 exporting a secret s from the exporter_master_secret, i.e., s = TLS- 311 Exporter("anonymous-ticket", exporter_master_secret, Hash.length), 312 where Hash is the negotiated hash function. 314 1. Generate a random bit string r of length equal to Hash.length. 316 2. Compute seed = HKDF-Expand(s XOR r, anonymous-ticket-input", 317 Hash.length). 319 3. Compute x = H1(seed), i.e., hash seed into a the group G of order 320 q. 322 This algorithm ensures that x is derived from randomness that is at 323 least as good as the traffic secret. In the event that the client's 324 PRNG fails or is subverted, x will still maintain entropy at least as 325 high as exporter_master_secret. 327 5. 0-RTT Data Implications 329 Since clients obfuscate their view of the blind session ticket 330 lifetime, servers MAY inadvertently determine that the resumption 331 Client Hello is a replay or otherwise stale. This would regress the 332 handshake to a full handshake, at the cost of privacy. 334 6. Linkability Beyond TLS 336 This section describes linkability concerns outside of TLS. Further 337 discussion of this topic may be found in 338 [I-D.wood-linkable-identifiers]. 340 6.1. Network-Layer Linkability 342 Servers may link client TLS sessions together using information that 343 exists outside of TLS. If a client uses a fixed and globally unique 344 IPv6 address, for example, then a server may easily link a resumed 345 session to past sessions. Thus, globally unique addresses render 346 blind ticket resumption useless. Clients MUST use temporary IIDs for 347 each resumed connection to the same host, as per RFC 7721. For 348 similar reasons, IPv4-only clients SHOULD update their address or NAT 349 binding for each resumed connection. 351 6.2. Application-Layer Linkability 353 Linkability above TLS is also a concern and prevalent problem, 354 especially on the Web. Clients may be tracked via client-side 355 identifiers such as cookies. See [TrackingOnTheWeb] and 356 [ClientIdentification] for more details about these techniques. They 357 may also be fingerprinted via mechanisms that do not rely on such 358 identifiers [CookielessMonster13]. Clearly, these mechanisms may be 359 used to link clients across session resumptions. However, in cases 360 where these techniques are either ineffective or inaccurate, blind 361 TLS session tickets allow clients to maintain some control over their 362 privacy. 364 7. Open Issues 366 There are several open issues to consider for this proposal. In no 367 particular order: 369 1. Why not use a simpler semi-static Diffie Hellman design? In 370 particular, the semi-static Diffie Hellman design in 371 [I-D.rescorla-tls-semistatic-dh] could be modified to support 372 0-RTT encryption using the server's semi-static key, thereby 373 achieving similar anonymity properties. Such a design would be 374 considerably simpler than that which is presented in this 375 document. One property that anonymous tickets provide which is 376 not attainable by the semi-static approach is that tickets may 377 only be used once per resumed connection. In contrast, clients 378 may use a semi-static key share for "anonymous" connections with 379 early data without limit. 381 2. Where is server-side state such as the negotiated ciphersuite and 382 ALPN values stored? One possibility is to have servers store an 383 OPRF key per (ciphersuite, ALPN token) tuple, and require clients 384 to use the same values upon resumption. Assuming servers select 385 the same values and identify the same OPRF key, the PSK binders 386 will match. 388 8. IANA Considerations 390 This document makes no IANA requests (yet). 392 9. Security Considerations 394 This design has not yet received any security analysis. It may be 395 completely broken. 397 10. Acknowledgments 399 The authors would like to thank Martin Thomson for helpful 400 discussions that led to this design. 402 11. References 404 11.1. Normative References 406 [I-D.sullivan-cfrg-voprf] 407 Davidson, A., Sullivan, N., and C. Wood, "Oblivious 408 Pseudorandom Functions (OPRFs) using Prime-Order Groups", 409 draft-sullivan-cfrg-voprf-03 (work in progress), March 410 2019. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 418 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 419 . 421 11.2. Informative References 423 [Chaum] "Blind Signatures for Untraceable Payments", n.d., 424 . 427 [ClientIdentification] 428 "Technical analysis of client identification mechanisms", 429 n.d., . 432 [CloudflareResumption] 433 "TLS Session Resumption - Full-speed and Secure", n.d., 434 . 437 [CookielessMonster13] 438 "Cookieless Monster - Exploring the Ecosystem of Web-based 439 Device Fingerprinting", n.d., 440 . 443 [I-D.rescorla-tls-semistatic-dh] 444 Rescorla, E., Sullivan, N., and C. Wood, "Semi-Static 445 Diffie-Hellman Key Establishment for TLS 1.3", draft- 446 rescorla-tls-semistatic-dh-00 (work in progress), October 447 2018. 449 [I-D.wood-linkable-identifiers] 450 Wood, C., "Linkable Identifiers", draft-wood-linkable- 451 identifiers-00 (work in progress), October 2018. 453 [Jarecki16] 454 "Highly-Efficient and Composable Password-Protected Secret 455 Sharing (Or How to Protect Your Bitcoin Wallet Online)", 456 n.d., . 458 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 459 RFC 4303, DOI 10.17487/RFC4303, December 2005, 460 . 462 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 463 (TLS) Protocol Version 1.2", RFC 5246, 464 DOI 10.17487/RFC5246, August 2008, 465 . 467 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 468 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 469 January 2012, . 471 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 472 Kivinen, "Internet Key Exchange Protocol Version 2 473 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 474 2014, . 476 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 477 "Transport Layer Security (TLS) Application-Layer Protocol 478 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 479 July 2014, . 481 [Springall16] 482 "Measuring the Security Harm of TLS Crypto Shortcuts", 483 n.d., . 485 [TrackingOnTheWeb] 486 "Detecting and Defending Against Third-Party Tracking on 487 the Web", n.d., . 490 Authors' Addresses 492 Nick Sullivan 493 Cloudflare 494 101 Townsend St 495 San Francisco 496 United States of America 498 Email: nick@cloudflare.com 500 Christopher A. Wood 501 Apple Inc. 502 One Apple Park Way 503 Cupertino, California 95014 504 United States of America 506 Email: cawood@apple.com