Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend the token type registry for batched issuance #508

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 14 additions & 1 deletion draft-ietf-privacypass-architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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,
Expand All @@ -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
Expand Down
12 changes: 10 additions & 2 deletions draft-ietf-privacypass-auth-scheme.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -795,6 +800,9 @@ Public Metadata:
Private Metadata:
: N/A

Batched Issuance:
: N/A

Nk:
: N/A

Expand Down
5 changes: 4 additions & 1 deletion draft-ietf-privacypass-protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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}}
Expand All @@ -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}}
Expand Down
Loading