Privacy Pass T. Pauly Internet-Draft Apple Intended status: Informational S. Hendrickson Expires: 4 September 2025 Google 3 March 2025 Including Privacy Pass Tokens in TLS Handshakes draft-pauly-privacypass-for-tls-00 Abstract This document defines a mechanism for TLS servers to request, and TLS clients to provide, Privacy Pass tokens as part of the Encrypted Client Hello in the TLS handshake. This creates a way to add support for anonymous attestation and rate-limiting to servers that are enforcing denial-of-service protections as part of processing TLS handshakes. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-pauly-privacypass-for-tls/. Discussion of this document takes place on the Privacy Pass mailing list (mailto:privacy-pass@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/privacy-pass/. Subscribe at https://www.ietf.org/mailman/listinfo/privacy-pass/. Source for this draft and an issue tracker can be found at https://github.com/tfpauly/draft-privacypass-for-tls. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Pauly & Hendrickson Expires 4 September 2025 [Page 1] Internet-Draft Privacy Pass for TLS March 2025 This Internet-Draft will expire on 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Requesting Privacy Pass Tokens . . . . . . . . . . . . . . . 4 5. Presenting Privacy Pass Tokens in Encrypted Client Hello . . 5 5.1. Handling Inability to Present Tokens . . . . . . . . . . 5 6. Applicable Token Types . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.1. Update of the TLS ExtensionType Registry . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Privacy Pass Tokens [PPARCH] are cryptographic authentication messages that can be used to verify properties of a network entity, such as proving that a client passed some attestation check, without being linkable to other tokens or revealing identities. [PPAUTH] defines how Privacy Pass Tokens can be requested by HTTP servers (via an authentication challenge) and provided by HTTP clients. This is useful for providing privacy-preserving authentication or attestation in HTTP workflows. However, Privacy Pass Tokens can also be used in other contexts and protocols. For example, [I-D.sawant-eap-ppt] defines how to include tokens in EAP (Extensible Authentication Protocol) exchanges. Pauly & Hendrickson Expires 4 September 2025 [Page 2] Internet-Draft Privacy Pass for TLS March 2025 Some server deployments enforce rate-limiting on TLS [TLS13] handshakes to prevent denial-of-service (DoS) attacks, particularly by rate limiting the number of connections allowed from individual client IP addresses or IP address subnets. This is common in scenarios where the cost of handling a terminated TLS connection is significantly higher than handling the initial handshake, like in L7 loadbalancers with heavy-weight protocol conversions after termination. This enforcement can particularly impact cases where many clients are using a particular IP subnet due to using a privacy-preserving proxy (some examples are described in [PRIVACYPARTITIONING]). For such cases, even if clients are able to provide Privacy Pass Tokens or similar proofs at the HTTP layer, their connections might be denied or rate-limiting during TLS session establishment. In order to signal that clients meet certain criteria (rate-limiting, etc), without disclosing individual client identities or pseudonyms, this document defines a way to include Privacy Pass Tokens within the TLS handshake. Specifically, these tokens are sent within the TLS Encrypted Client Hello [ECH]. This prevents network observers from being able to directly observe the tokens, while still allowing the TLS server to observe the token early in the handshake. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Overview Clients can include Privacy Pass tokens as part of the TLS Client Hello via the privacy_pass_token extension. This is described in Section 5. Clients MAY be configured to always present tokens when performing a TLS handshake with a particular server. However, in general, clients SHOULD NOT automatically include Privacy Pass tokens; without an explicit challenge, clients won't know the relevant token type or issuer to use. Servers can request tokens by adding the privacy_pass_challenge extension to a TLS Hello Retry Request. This is described in Section 4. Servers that want to receive Privacy Pass tokens as a way to enforce DoS protection SHOULD send challenges to clients when these clients would otherwise be blocked or rate-limited in some fashion. Pauly & Hendrickson Expires 4 September 2025 [Page 3] Internet-Draft Privacy Pass for TLS March 2025 4. Requesting Privacy Pass Tokens In order to request that a client sends a Privacy Pass token, a server can send a Hello Retry Request ([TLS13], Section 4.1.4) that includes a privacy_pass_challenge extension. The privacy_pass_challenge extension has the following format: struct { opaque challenge<1..2^16-1>; opaque token_key<0..2^16-1>; } PrivacyPassChallenge; The fields are defined as follows: * challenge contains a TokenChallenge structure, as defined in [PPAUTH], Section 2.1.1. * token_key contains a public key for use with the issuance protocol, where applicable. This is equivalent to the token-key parameter used in HTTP authentication challenges discussed in [PPAUTH], Section 2.1.1. The token_key may be empty (have a zero length), in which case clients are expected to fetch the token key for a particular issuer name in another way. If a client does not include the token in the Client Hello (or subsequent Client Hello after being challenged), the server MAY reject the request or apply rate-limiting. Clients SHOULD apply some form of consistency check on the token challenge to avoid (malicious) anonymity set partitioning by the server; see Section 6.2 of [PPARCH] for more details. Servers sending challenges can use a non-empty redemption_context in order to bind the token challenge to a particular context (such as the client IP address, or a time window) to aid in token replay prevention. Servers MAY combine sending privacy_pass_challenge extensions with a cookie extension ([TLS13], Section 4.2.2). For example, servers that cannot statefully persist the token challenge presented to the client in the privacy_pass_challenge extension can use the cookie extension to encode this challenge. Pauly & Hendrickson Expires 4 September 2025 [Page 4] Internet-Draft Privacy Pass for TLS March 2025 5. Presenting Privacy Pass Tokens in Encrypted Client Hello Clients can include Privacy Pass tokens in TLS handshakes using the privacy_pass_token extension. This extension MUST be sent in the Inner Client Hello, using [ECH]. If ECH is not supported, clients SHOULD NOT use Privacy Pass tokens in TLS in order to avoid adding more tracking entropy visible on the wire, and making it easier to trivially replay tokens to a server. The privacy_pass_token extension has the following format: struct { opaque token<1..2^16-1>; } PrivacyPassToken; The token field uses the Token structure defined in [PPAUTH], Section 2.1.1. Tokens are generally presented after receiving a challenge, but a client MAY include a token without having received a challenge if it has other out-of-band configuration to do so. 5.1. Handling Inability to Present Tokens Servers need to be able to detect when clients are unable to present a token after receiving a challenge. A client might be unable to present tokens because it has reached a token rate limit, because it does not have a way to generate tokens for the required token issuer, or simply because it does not support this specification. The RECOMMENDED approach to handle such cases is for the server to include a cookie extension ([TLS13], Section 4.2.2) along with the challenge, and for clients to retry the handshake including the cookie extension, but not including the privacy_pass_token extension. Servers can then assume that the client received the challenge and was unable to generate a valid token. The policy for what servers do in such cases will be specific to the overall use case, and beyond the scope of this document. 6. Applicable Token Types This document is defined such that any Privacy Pass token type would be possible to use in the TLS handshake. However, different token types will have different properties for latency, replay protection, and privacy. Pauly & Hendrickson Expires 4 September 2025 [Page 5] Internet-Draft Privacy Pass for TLS March 2025 Ideally, deployments can use token types that allow for unique redemption contexts (to prevent replay attacks) that also do not require communicating with a token attester or issuer for each token creation (thus improving latency, and not creating new activity that can be used to fingerprint clients). Some proposed token types like [ARC] and [BBS] have these properties. 7. Security Considerations Servers redeeming Privacy Pass tokens in TLS handshakes need to take care to avoid replay attacks. Using a fresh redemption context in the challenge ensures that tokens are equally fresh and unique. As discussed in Section 6, token issuance types that don't require clients talking to an issuance server with a new network request for every token generation will have better properties for privacy, since the client won't make a new request after each TLS handshake challenge. 8. IANA Considerations 8.1. Update of the TLS ExtensionType Registry IANA is requested to create the following entries in the existing registry for ExtensionType (defined in [TLS13]): 1. privacy_pass_challenge(0xfd00), with the "TLS 1.3" column values set to "HRR", "DTLS-Only" column set to "N", "Recommended" column set to "Yes". 2. privacy_pass_token(TBD), with "TLS 1.3" column values set to "CH", "DTLS-Only" column set to "N", and "Recommended" column set to "Yes", and the "Comment" column set to "Only appears in inner CH." 9. References 9.1. Normative References [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-23, 19 February 2025, . [PPARCH] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, . Pauly & Hendrickson Expires 4 September 2025 [Page 6] Internet-Draft Privacy Pass for TLS March 2025 [PPAUTH] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 9.2. Informative References [ARC] Yun, C. and C. A. Wood, "Privacy Pass Issuance Protocol for Anonymous Rate-Limited Credentials", Work in Progress, Internet-Draft, draft-yun-privacypass-arc-00, 5 February 2025, . [BBS] Ladd, W., "BBS for PrivacyPass", Work in Progress, Internet-Draft, draft-ladd-privacypass-bbs-01, 26 February 2024, . [I-D.sawant-eap-ppt] Sawant, P. and B. Brinckman, "Extensible Authentication Protocol (EAP) Using Privacy Pass Token", Work in Progress, Internet-Draft, draft-sawant-eap-ppt-01, 20 October 2024, . [PRIVACYPARTITIONING] Kühlewind, M., Pauly, T., and C. A. Wood, "Partitioning as an Architecture for Privacy", RFC 9614, DOI 10.17487/RFC9614, July 2024, . Acknowledgments TODO acknowledge. Pauly & Hendrickson Expires 4 September 2025 [Page 7] Internet-Draft Privacy Pass for TLS March 2025 Authors' Addresses Tommy Pauly Apple Email: tpauly@apple.com Scott Hendrickson Google Email: scott@shendrickson.com Pauly & Hendrickson Expires 4 September 2025 [Page 8]