alxdavids / draft-privacy-pass Goto Github PK

Is the actual encoding of protocol messages left to applications that build on top of PrivacyPass, or will a recommended coding show up here?

Since its a primarily a crypto protocol, it might make sense to consider TLS Presentation Language (basic length prefixed blobs) or DER rather than requiring a JSON/CBOR dependency for the protocol itself.

The current design of Privacy Pass allows double spends unless a record of each token redeemed is kept and checked at redemption.

In typical use, tokens issued may be reasonably expected to survive for multiple days. This creates an obligation for services to maintain globally consistent records for a long period of time to prevent abuse.

We can propose possible solutions, but want to first call this out as an issue for wider adoption in case others are thinking about the same issue.

There are at least two separate issues to address:

1. This request is not simply a replay
2. This redemption is not simply a replay

An ideal solution would allow fast evaluation of these properties while requiring a minimum of shared state.

In the security considerations, you have:

TODO: Can client's flag bad server practices?

Given that use of multiple keys can be used to segment users (with arbitrary granularity even), it seems that this system depends critically on having some way to limit the number of keys that a server can use.

(Adding an issue, can try drafting up a PR shortly)

It should be possible for a client to get multiple tokens issued at one time to avoid having to do a round-trip for each invocation of the issuance. The issuer might also want to publish the maximum number of tokens they'll issue at once (so the client knows how many blinded tokens to generate and send).