Including Privacy Pass Tokens in TLS Handshakes

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."¶

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

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.¶

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.¶

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.¶

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.¶

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.¶

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

9. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses