Groth-Sahai based alternative?

[wbl]

This is a radically different looking approach to solve a somewhat different but related problem. We would like clients to produce tokens that are a function of their IP address, an issuer secret parameter, and the origin where the token is displayed. We'd like these tokens not to be linkable across sites, but not mangleable on a site. IP address is used as an example, other identifiers could also work.

To do this I propose the following: The Issuer I takes a request from a client C, computes z=h(IP(C), secret) for some hash function h, and sends back z along with a structure signature of a special value zg_1,zg_2 with a structure preserving signature on zg_1, zg_2. Maybe we have to fiddle a bit with this. The client just has to do this once.

The client connects to a site S by computing w=H(S), T=zw, where H is a hash function to G_1. The client then sends a zero knowledge Groth-Sahai proof that T is correctly formed (by pairing equations involving the special value) and that the issuer signed the special value. The special value isn't revealed by the ZK properties of the Groth-Sahai proof.

The site can use T the way it uses IP addresses today. Crucially a different site will have a different token T', with no way to link them.

This has a number of differences from the current proposal:

• The mediator doesn't exist
• Issuer works once per client
• Sites implement their own policies freely, and can use the identifier to link repeated requests, e.g. to find a pattern of vandalism and respond with a ban
• Sites get an equivalent to the IP address they currently use
• Uses more complicated cryptography, but conceptually pretty simple: validate a token, generate a token, issue a signature
• The issuer is stateless

[tfpauly]

Interesting idea!

I have a couple comments/questions:

• Part of the goal of Private Access Tokens is to move away from needing IP-based authentication/rate-limiting. It prefers rooting the authentication on a device or account. Maintaining the IP address stability is one way to provide some of the existing behavior, but I'm hoping to have something that doesn't have some of the annoying properties of rate-limiting per IP (users behind a NAT are forced to share fate), and allows us to use private IPs to talk to the mediator/issuer infrastructure.

• If the client only talks to the Issuer once, and can mint its own tokens after that for a specific origin, either it will be presenting the same token to the same origin over an over (which I think is the case you have here) or it would be able to mint new tokens and look like as many users as it wants. If this is the former case, then we effectively have a super-cookie that allows a server to recognize the same client coming back. That's an anti-goal of Private Access Tokens. We want a way to ensure that the server cannot recognize a client coming back to them, even if they're on the same access network, if they cleared cookies.

• If the Issuer is chosen by the Origin, and the Client must directly talk to the Issuer using a non-private IP, the Origin now has the power to tell the Client to reach out to an arbitrary site with its real IP address. This is a regression in privacy, I think; for PATs, the Client only ever reveals its IP address to a Mediator it chooses and trusts, not an arbitrary Issuer (which could be the Origin itself). Yes, the Issuer may not know your actual identity, but it can track where users are and build up state if it wants.

[wbl]

This is the part of the conversation where I would be suggesting we find a cafe next week. Alas! You raise some excellent points.

• IP could really be any string: email, account name, some attestation key. All that is important is that it be expensive to obtain another one.
• You're correct that we'd present the same token over and over. For anti-abuse use cases this is more compelling than the paywall usecase. However it's possible to periodize the credentials: instead of W=H(S), make it W=H(S, t) where t is the current time rounded to some precision. This doesn't require another Issuer interaction.
• The Origin (perhaps a better name is needed... but it's hard to come up with one) and Client would have to agree upon a mutually agreeable Issuer, although this is a one time event. If the Client just takes any Issuer, and that changes every time, that would be a problem. How big a problem this is in a deployment depends on the number of Issuers and how widely they are trusted. My thought is that developers of Privacy Enhancing Technologies would be able to deploy these also.

[tfpauly]

Yes, absolutely something for a discussion over coffee!

The other aspect I'm thinking about is the risk for abuse when you allow and expect token replay. With a challenge-based system, the origin knows that the client had to fetch the token within a certain time; you could try to run the issuance through some other device that was more trusted than you, but you'd need to proxy for each new token challenge. If we only talk to an issuer to get a secret once, what stops a client from leaking that information to many other clients? The origin could still rate limit that entire group as "one", but it means that it's fairly trivial to start giving access to clients that otherwise wouldn't be trusted.

I think what I'm seeing is that a model that tries to put enforcement back on the origin based on one-time information from an issuer can work as a replacement for some captcha-style use cases, but has more trouble with the cases like metered paywalls or trusting that a client is in a specific geolocation. Does that sound right?

[wbl]

Was off by a week on IETF timing, but yes.

I think the geolocation policy would definitely be a problem as the token is easily liftable and long lasting, unless we have frequent rotation which has its own issues. For paywall metering the supercookie concern is an issue, especially on subrequests. If it's only presented on a top level navigation, given the paywall durations (typically per month) and limits (~10 views) it might not be so bad, provided we don't have additional, especially cross site tracking vectors. I think for captcha you really want one time tokens, not persistent ones because of the ability to farm.