From ff9018d83ecff7f87328688abce46793d7c33fa3 Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Wed, 10 Apr 2024 10:25:52 -0400 Subject: [PATCH] Extend the token type registry for batched issuance --- draft-ietf-privacypass-architecture.md | 15 ++++++++++++++- draft-ietf-privacypass-auth-scheme.md | 12 ++++++++++-- draft-ietf-privacypass-protocol.md | 5 ++++- 3 files changed, 28 insertions(+), 4 deletions(-) diff --git a/draft-ietf-privacypass-architecture.md b/draft-ietf-privacypass-architecture.md index e284c451..67c4be60 100644 --- a/draft-ietf-privacypass-architecture.md +++ b/draft-ietf-privacypass-architecture.md @@ -504,6 +504,10 @@ of public metadata. arbitrary private information, i.e., information that the Client does not observe during Token issuance or redemption. See {{metadata-privacy}} for privacy considerations of private metadata. +1. Batched issuance. This means that Clients can request multiple Tokens in a single +batch, rather than requesting many Tokens with multiple token requests. Not all +cryptographic protocols underlying the issuance protocol support batched issuance. +See {{batch-privacy}} for privacy considerations of batched issuance protocols. The issuance protocol itself can be any interactive protocol between Client, Issuer, or other parties that produces a valid token bound to the Client's @@ -1101,7 +1105,7 @@ in applying these consistency checks across clients. Failure to apply a consistency check can allow Client-specific keys to violate Origin-Client unlinkability. -## Partitioning by Side-Channels +## Partitioning by Side-Channels {#side-channels} Side-channel attacks, such as those based on timing correlation, could be used to reduce anonymity set size. In particular, @@ -1114,6 +1118,15 @@ be small. Applications should take such side channels into consideration before choosing a particular deployment model and type of token challenge and redemption context. +## Partitioning by Batched Issuance {#batch-privacy} + +Clients that choose to use a batched version of an issuance protocol allow +the Issuer to link each of the individual token requests in a batch to the +same Client. If Clients choose different batch sizes, this may reveal +information to the Issuer that was not otherwise available (except via timing +side channels; see {{side-channels}}). Consistency in batch sizes is therefore +an important mitigation against partitioning attacks; see {{rotation-and-consistency}}. + # Security Considerations {#security} This document describes security and privacy requirements for the Privacy Pass diff --git a/draft-ietf-privacypass-auth-scheme.md b/draft-ietf-privacypass-auth-scheme.md index b9646576..7e6d6bcb 100644 --- a/draft-ietf-privacypass-auth-scheme.md +++ b/draft-ietf-privacypass-auth-scheme.md @@ -371,7 +371,7 @@ Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match. Note that each token has a unique client nonce, which is sent in token redemption ({{redemption}}). -If a client fetches a batch of multiple tokens for future use that are bound +If a client fetches multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies {{?COOKIES=I-D.ietf-httpbis-rfc6265bis}}, or if there is a network @@ -579,7 +579,7 @@ origins SHOULD include random token types, from the Reserved list of "greased" types (defined in {{token-types}}), with some non-trivial probability. Additionally, for deployments where tokens are not required (such as when tokens -are used as a way to avoiding showing CAPTCHAs), origins SHOULD randomly
 +are used as a way to avoiding showing CAPTCHAs), origins SHOULD randomly choose to not challenge clients for tokens with some non-trivial probability. This helps origins ensure that their behavior for handling clients that cannot redeem tokens is maintained and exercised consistently. @@ -729,6 +729,11 @@ Private Metadata: private metadata; see {{Section 3.5 of ARCHITECTURE}} for more details about this property. +Batched Issuance: +: A Y/N value indicating if the token type supports batched + issuance. see {{Section 3.5 of ARCHITECTURE}} for more + details about this property. + Nk: : The length in bytes of an output authenticator @@ -795,6 +800,9 @@ Public Metadata: Private Metadata: : N/A +Batched Issuance: +: N/A + Nk: : N/A diff --git a/draft-ietf-privacypass-protocol.md b/draft-ietf-privacypass-protocol.md index 839c69ef..dfb8d5cc 100644 --- a/draft-ietf-privacypass-protocol.md +++ b/draft-ietf-privacypass-protocol.md @@ -138,7 +138,8 @@ Issuers MUST provide two parameters for configuration: 1. Issuer Request URL: A token request URL for generating access tokens. For example, an Issuer URL might be - https://issuer.example.net/request. + https://issuer.example.net/request. Unless otherwise specified and configured, this + resource only accepts content with the media type "application/private-token-request". 2. Issuer Public Key values: A list of Issuer Public Keys for the issuance protocol. @@ -793,6 +794,7 @@ following entries. * Public Verifiability: N * Public Metadata: N * Private Metadata: N +* Batched Issuance: Y * Nk: 48 * Nid: 32 * Reference: {{private-flow}} @@ -808,6 +810,7 @@ following entries. * Public Verifiability: Y * Public Metadata: N * Private Metadata: N +* Batched Issuance: N * Nk: 256 * Nid: 32 * Reference: {{public-flow}}