ietf-wg-privacypass / base-drafts Goto Github PK

Neither for hCaptcha nor for Cloudflare

The keys should not be rotated too frequently, for example. We can then refer to the existence of some mechanism that allows us to check this property, such as a log or registry. (We can then move the registry information out of the architecture document and into a separate one entirely.)

The APIs currently do not allow clients or servers to supply metadata into the issuance flow. Absent a slot for metadata, how would one implement the PMB or the PrivateStats variants? One way would be to add client public metadata to the Generate API, and server public and private metadata to the Issue API, and communicate these in the requests and responses as needed. The instantiations/ciphersuites could then impose limits on these inputs as needed. For example, the PMB variant might limit the server private metadata to a single byte of value 0x00 or 0x01, and the public metadata would be empty.

@dvorak42, would that be workable?

They don't currently have a version. That seems like something which would be good to add. Extension support seems useful, too, so we don't need to rev the version each time we need a small change.

"guidelines for contributions" links to some other WG (and its mailing list, etc.).

Servers should specify accepted redemption modes that they allow as a list associated with their public configuration. This would be a subset of the list ["single", "proxy", "async", "public"] corresponding to the redemptions modes in https://tools.ietf.org/html/draft-davidson-pp-architecture-01#section-5.

In all modes except "single" we should also allow optional specification of allowed verifiers that can ask for tokens on the server's behalf. If one of these verifiers asks for a client token associated with the server, then the client will first check this list to ensure that the verifier exists before sending the token. This ensures that clients don't reveal which tokens they hold to untrusted verifiers.

cc @chris-wood @dvorak42

Some protocols, like blind Schnorr signature schemes, require more than 1 round trip to complete. Currently, the protocol assumes a protocol that runs in one round trip, with some offline public key distribution step. In particular, issuance request messages are mapped almost directly to the underlying OPRF blind/request message.

We should consider what needs to change, if anything, to accommodate these differently shaped protocols. I suggest we loosen the 1-1 restriction (?) from the Privacy Pass API to the underlying cryptographic protocol APIs. It just so happens that Privacy Pass maps nicely to the OPRF construction, but that need not be the case. For example, and hand waving over details, in the blind Schnorr case, an implementation of the issuance request flow could involve first fetching the nonce commitment from the server, and then sending a blinded value for evaluation.

@dvorak42, what do you think?

This will match IssuanceResponse!

https://discord.gg/SVNV8Rv2

We don't have a good way to address this (now), so we should minimally acknowledge the risks and consequences.

Different applications may want different numbers of metadata bits. This number should probably be bounded, otherwise Privacy Pass... is not so private.

We currently have two sub-protocols: Issuance and Redemption. Redemption effectively gives the Privacy Pass token to someone else to verify using whatever is the underlying cryptographic protocol. Should we redefine Redemption as such? In particular, imagine we had a sub-protocol called Verify, which may or may not be interactive depending on the underlying cryptographic protocol. Redemption could then simply be:

• Reveal token to the relying party
• Relying party runs Verify

We might even consider punting the reveal step to the protocol wrapping Privacy Pass. The fact that tokens change hands before verification seems external to the protocol.

Protocols like VOPRF and blind RSA/BLS have different semantics and wire images. As an example, batching seems to be a per-crypto-protocol property. VOPRF supports it, whereas BLS/RSA do not.

Trying to map these to a shared wire format seems a bit awkward. I recommend we parameterize all PP protocol messages based on the underlying cryptographic construction. So, for example:

enum {
	VOPRF,
	BlindRSA,
} Protocol;

struct {
	Protocol proto;
	uint16 length; // allows skipping over unknown protocols
	select (proto) {
		case VOPRF:
			opaque blind_elements<1..2^16-1>;
  		case BlindRSA:
  			opaque blinded_msg[kLen];
	}
} IssuanceRequest;

struct {
	Protocol proto;
	uint16 length; // allows skipping over unknown protocols
	select (proto) {
		case VOPRF:
			IssuedToken tokens[m];
  			opaque proof<1..2^16-1>;
  		case BlindRSA:
  			opaque blind_sig[kLen];
	}
} IssuanceResponse;

(The same should probably apply to redemption messages as well.)

We can then refactor the document to only specify how these protocol messages are constructed and parsed, rather than specify how implementation-specific details should work.

0x170DBdd337bA421fED5498279a61db29B66aB37d

Originally posted by @phyo734 in #2 (comment)

API has been updated at https://github.com/cfrg/draft-irtf-cfrg-voprf/ quite substantially.

Per the charter.

... so that servers know clients are using the right key and haven't been downgraded, for whatever reason. In ECHO, we indicate this with a hash of the ECHOConfig structure, which would probably do the trick here, too. For example:

struct {
    uint8 update_digest[32];
     ClientIssuanceElement issue_element<1..n>
} IssuanceMessage;

where update_digest = SHA256(server_update), or something.

We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.

You seem to be using this setup.

The usual method for having multiple drafts in a repo is to just drop multiple files in the root directory. The approach you have works until you try to do CI integration or access more advanced features, like the primitive support that exists for cross-document citations.

See QUIC for a complete and operational setup.

As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have.

cc @dvorak42, @alxdavids

A number of applications expect the Servers to be able to add a small amount of metadata to the Privacy Pass protocol. We should add a discussion on how metadata should be added to tokens, and then describe the subsequent impact that this would have on the client's expected privacy budget.

Generally speaking, adding a bit of metadata to tokens is likely to have a very similar impact to introducing an extra Issuer, and so this is something that will have to be covered in the general parametrization guidelines in the architecture document. Specific mechanisms for adding metadata to tokens are yet to be proposed, but may appear as alternative instantiations in the protocol document, or be specified separately as individual extensions.

Currently, the modified parameter in each server key configuration only includes the latest modification. Perhaps this parameter should be an array that holds ALL of the times when modifications occurred? This would allow clients to check the frequency of key rotations for detecting malicious server behavior?

The main protocol document assumes that VOPRF is the main instantiation of PrivacyPass. It also has support for ciphersuites that augment this particular instantiation. It's not clear how we'd "extend" this protocol to support other features, such as public verifiability or the k-bits of metadata. These seem to be separate "modes" or "configurations" of PrivacyPass. (I don't think it makes sense to try and cast the metadata bit variant as a different ciphersuite for the main instantiation.)

I propose we add some text describing different configurations. A configuration is an instantiation of the PrivacyPass API with certain properties. A configuration may (should?) also be extensible where applicable, e.g., in the ServerUpdate message or IssuanceRequest/Response messages. Interoperability across configurations would be unsupported, as they have would like have fundamentally different properties.

Some initial configurations that come to mind are:

• PrivacyPass with no metadata bits (VOPRF construction)
• PrivacyPass with k metadata bits (Google's design)
• PrivacyPass with public verifiability (blind signatures?)

cc @alxdavids

Throughout the drafts we currently use terms such as privacy-preserving & anonymity without establishing what properties we are assuming when using these terms. As mentioned on the mailing list, we should align around consistent terminology for the guarantees that we are offering (anonymous authorization) and then define exactly what this means in our context.

In particular, anonymity/anonymous refers to the fact that client redemption tokens cannot be linked to any other tokens issued by a given Issuer.

First raised here: https://mailarchive.ietf.org/arch/msg/privacy-pass/7IXHIdXy7bEg3OMlScihmNKFRx4/

m.me/AgentJenny143

We should consider renaming redemption_nonce to redemption_context. This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to.

We can also rename the context in the Token struct to challenge_digest to make it clear what role it has.

There should be documentation that addresses the risks of the centralization in the current Privacy Pass architecture with potential solutions. This was raised in the previous WG meeting: https://codimd.ietf.org/notes-ietf-108-privacypass.

This documentation should either be incorporated into the architecture document as a section when discussing the shape of the ecosystem, and/or security considerations. There is also the option of declaring a separate document for addressing this.

Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.

SecretKey, to me, implies a symmetric key. Can we make this PrivateKey? That's the terminology used (mostly) in RFC7748, at least.

There's currently no text around token expiration. Minimally, we could say that tokens expire when issuer (and verifier) keys rotate. Do we also want to bake in mechanisms for expiration to be cryptographically bound to issued tokens? For example, one might imagine using PMB-like constructions to encode an expiration "epoch" into the metadata bits. The single metadata bit variant would allow two epochs that way.

@dvorak42, @alxdavids: what do you think?

There are several dimensions to metadata, including:

• public vs private
• verifiable vs non-verifiable
• bounded or arbitrary-length

It's worth expanding on these dimensions. For example, the underlying cryptographic primitive may influence or limit one or more of these dimensions in a variety of ways. Also, whether metadata is public or private, or verifiable or not, is important for privacy reasons. (If metadata can't be verified, is it a tracking vector? Can private metadata track clients?)

In general, expounding upon these issues would likely be quite valuable for the draft.

These test vectors should cover the whole flow of the protocol, starting with the TokenChallenge input and producing a Token output.

(This might be done already, but just in case...)

We should probably provide guidance on how clients should pick issuers. For example, if a client is presented with a choice of two issuers, what does it do? Pick the same one and use it "all the time," pick one at random, or something else?

From: tfpauly/privacy-proxy#105

@chris-wood said:

Servers can offer multiple challenges in a WWW-Authenticate header to let the client fetch a pile of tokens for future spending. For tracking reasons, the lifetime of these should be bound to any cookie state associated with the origin. In particular, if the client wipes its cookies for the origin, then it should also clear any challenge state. It's possible for the server to encode client-specific information in the TokenChallenge.redemption_nonce, so we need to ensure this doesn't turn into a different type of tracking vector.

Formal analysis is important for new security protocols. The charter should include this, maybe add something like this at the end of paragraph 4:

"Formal analysis of the protocol will make sure the security and privacy properties of the protocol
are well-understood and well-documented."

The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count.

If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).

See Mark's original issue.

Currently, RedemptionRequest messages have the following structure:

struct {
  opaque data<1..2^16-1>; // input to the token issuance flow
  opaque tag<1..2^16-1>;  // output of the token issuance flow
  opaque info<1..2^16-1>; // application information bound to the token
} RedemptionRequest;

This has a couple of interesting properties. First, anyone with access to data can replay it in the issuance flow and compute tag. We might be able to address that by making the redemption flow a two round protocol, similar to what we've done for the issuance flow, or by allowing clients to encrypt data under the redeemer's public key. Or something else entirely.

Second, tag effectively authenticates info. Is there any reason why we couldn't merge these two fields and encrypt the latter with an AEAD? And if we were to do that, perhaps we could simplify the redemption interface and have it produce a secret that applications use as needed? Specifically, the Redeem function might return a secret rather than a RedemptionRequest. Turning the redemption API into an Export-like interface might help accommodate different application use cases.

cc @armfazh, @siyengar, @dvorak42

Currently, in the proxied-verifier server running mode, the entire redemption token is sent to the server. However, we may be able to avoid this by only sending the initial data inside the RedemptionRequest, and keeping the tag and info at the proxy. This is because data is operated on under the server key, while the rest of the information is just added to a hash function evaluation. This means that the token issuer only sees the token (and can then implement double-spending protection based on this), but nothing else about the request to the verifier.

The change will probably drop the requirement for the VerifyFinalize API in the VOPRF doc, which is also advantageous. Originally discussed with @chris-wood, @siyengar, and Zutian Luo.

We say it's possible, but let's be a bit more concrete.

In the architecture document, we should have more discussion of correlation attacks and ways to mitigate. For example, interactive vs non-interactive tokens can making timing correlation attacks more or less relevant. For mitigations, the deployment model of issuer/origin (and attester) can make a difference.

The Privacy Pass protocol was originally designed as a response to providing an anonymous authorization users of anonymity-preserving services such as Tor. We should specify this motivating use-case (along with the applications that have arisen since) as a new section to the protocol document.

This will ensure that the standardisation of the protocol continues to be informed, and to be driven by, the key problems that we are trying to solve.

First raised here: https://mailarchive.ietf.org/arch/msg/privacy-pass/7IXHIdXy7bEg3OMlScihmNKFRx4/

Need to provide recommendations for section {{recs-srvr}} in the pp-architecture draft. It seems to me that it is easy for individual clients to identify and react to servers that seem to be acting maliciously. For example, the client can monitor and reject key material from servers where the configuration was last modified very recently and how often the rotations seem to be occurring. However, I'm not exactly sure what the reporting mechanism should be to alert other clients to this behavior.

This function outputs a ServerConfig and ServerUpdate. It might simplify things if this just output a config, from which the update could be created.

Something like:

• Specification of protocol & surrounding architecture - February 2021
• Specification of application-layer requirements (including HTTP integration) - March 20201
• Specification of HTTP browser API (in coordination with W3C) - April 20201

It might be easiest to fully specify a Privacy Pass configuration, e.g., "Privacy Pass based on curve448_hkdf_sha512_ell2_ro," with a single identifier. That same identifier could go in the ServerUpdate structure as a way of fully defining the properties of the structure.

Token issuance and redemption flows from the same IP address, for example, would be linkable, but this isn't a break in the privacy pass protocol. We should discuss these orthogonal privacy considerations.

The Data structures section of the protocol draft says "data structures ... are written in the TLS presentation language (RFC8446)". Per RFC8446 3.4, vectors are defined as <item type> <vector type>[n] where n is the length of the vector in bytes. ("In either case, the length declares the number of bytes, not the number of elements, in the vector.") In the draft, though, the length is specified by number of items, not number of bytes.

Hi there,

We have been working on privacy-preserving Single Sign-On and we found our work, called EL PASSO, is very closely related to Privacy Pass.
EL PASSO implements anonymous credentials, enables selective attribute disclosure, and allows users to prove properties about their identity without revealing it in the clear.
We also have accountability designed in: when a user misbehaves on a relying party, the relying party can report the user to authorities to reveal the identity of that user.
There are other interesting features in EL PASSO like inter-RP unlinkability and intro-RP linkability that can provide desired security properties.

A preprint version can be found on arXiv: https://arxiv.org/abs/2002.10289 and a final version will appear in PETS 2021.
We hope this work can provide some useful input to Privacy Pass and we are also looking forward to future collaborations with Privacy Pass.