Rate-Limited Tokens: origin binding of the blind signature

[nikitaborisov]

What is preventing a client from going to one website while using the rate-limiting policy of another site? More specifically, suppose Alice visits foo.com and gets a challenge nonce from it. She then runs the issuance protocol, but specifies bar.com as the origin in the encrypted token request. As I understand it, as long as foo.com and bar.com both trust the same issuer, this would work because the origin only sees the (blind) signature from the issuer.

Among many potential problems resulting from this lack of binding is that bar.com may have a much higher rate limit than foo.com.

@chris-wood suggests that perhaps a partially-blind signature could be used to fix this problem, where the issuer includes the origin as the public input to the partially-blind sig.

[tfpauly]

I think there are multiple approaches possible here:

1. Partially-blind signatures could allow the issuer to include the origin name info in the token back to the origin. That would work, but mainly relies on having a viable and efficient partially-blind signature scheme.
2. Go back to an earlier design where the issuer has a per-origin token key. We would need to remove the key ID from what the attester sees, and the client would need to run a consistency check (double-check, etc). This is probably a more palatable change if we have a good key consistency story.

[nikitaborisov]

For key consistency, an origin could advertise the public key(s) it will accept along with the challenge, and the client can make sure the blind signature uses one of those keys. It won't help if the issuer and origin collude to track a client (and in some cases, the origin and issuer are the same entity), but you could imagine a separate key transparency solution that could be deployed in the future.

[tfpauly]

Right — and the origin does provide the public key in the auth scheme challenge, so the client will know that the blind signature uses one of those keys.

[chris-wood]

As @tfpauly suggests, this seems like something we can mitigate with per-origin keys and an improved key consistency story. In particular, if we use per-origin keys, we need to remove the attester's role in enforcing key consistency for clients. There are approaches to do that, such as the one described by @bemasc.