George Kadianakis:
Hello all,
after lots of investigation on anonymous credentials, we are glad to present you with a draft of the onion services anti-DoS proposal using tokens.
Thanks! I finally managed to read through and think about the proposal (but note: I've not read proposal 327 yet, so I hope my remarks are not too silly were that proposal comes into play). I have some comments inline but did not tackle any XXX parts yet (and I'll provide a torspec branch later for fixing the typos I found).
While the basic idea of the proposal should remain reasonably solid, there are various XXX sprinkled around the proposal and some of them definitely need to be addressed before the proposal becomes truly usable.
We are particularly looking forward to feedback about:
- Token issuance services
- The anonymous credential scheme chosen
- The XXXs and design decisions of the proposal
Hope you have a pleasant read!
[snip]
## 3.3. Other security considerations
Apart from the above properties we also want:
Double spending protection: We don't want Malory to be able to double spend her tokens in various onion services thereby amplifying her attack. For this reason our tokens are not global, and can only be redeemed at a specific destination onion service.
Metadata: We want to encode metadata/attributes in the tokens. In particular, we want to encode the destination onion service and an expiration date. For more information see section [DEST_DIGEST]. For blind RSA tokens this is usually done using "partially blind signatures" but to keep it simple we instead encode the destination directly in the message to be blind-signed and the expiration date using a set of rotating signing keys.
One-show: There are anonymous credential schemes with multi-show support where one token can be used multiple times in an unlinkable fashion. However, that might allow an adversary to use a single token to launch a DoS attack, since revocation solutions are complex and inefficient in anonymous credentials. For this reason, in this work we use one-show tokens that can only be redeemed once. That takes care of the revocation problem but it means that a client will have to get more tokens periodically.
While reading I had the feeling we have the one-show property because we want to (easily) prevent double-spending. Thus, can't we just fold that part into the "Double spending protection" one? As it stands I found it confusing/redundant.
[snip]
## 4.2. Onion service signals ongoing DoS attack
Let me look at that from a slightly different angle. What about something like
## 4.2. Onion service signals DoS attack protection
? That is, would we be okay if onion services used the mechanism in this proposal for *preventing* DoS attacks(, too,) in the first place? Worst case would be every onion service has the anti-DoS security feature on 24/7 but there are other scenarios conceivable that point in a similar direction (e.g. anti-DoS protection only on on weekends or just at particular times).
Looking at the proposal for answering my question I am not sure. It seems you indicate in section 6 that this would be strongly undesired at least in cases where manual work needs to be done:
""" In the cases where manual work is needed by the user (e.g. solving a CAPTCHA) it's ideal if the work is presented to the user right before visiting the destination and *only* if it's *absolutely* required. [emphasis mine, GeKo] """
But there are other token issuers with different constraints conceivable (as you mention in the proposal itself).
The reason why I bring this up is two-fold:
1. We had been thinking about that issue back then when we were evaluating Prviacy Pass for an inclusion into Tor Browser and as a solution to/against Cloudflare's CAPTCHAs. One of the biggest arguments against doing that was that we were afraid of enabling a mechanism that would boil down in the longer run to requiring a kind of "driver's license" (you need to solve a CAPTCHA first) to just reading news on the Internet anywhere. Even though that may come anyway at some point in the future we thought the Tor Project should not be at the forefront on that trend essentially pushing it with our "seal of acceptance".
While I think that both contexts (the Privacy Pass - website and the Res token - onion service one) are sufficiently different that our concerns from back then do not apply 1:1, I do wonder how the story in the onion services one looks like...
2. Why would onion service providers even do such a thing as using the tokens outside of an ongoing DoS attack? Well, nobody wants to get hit by an attack in the first place if they can easily *prevent* it. Tokens would offer that (likely even for more attacks than just the intended DoS). In particular, the situation of an onion service provider is the classical one where they alone doing X is not too problematic but if all of them were doing X it could be. I can likely see a future where onion service guides start with "And if you are under DoS attack require tokens" but soon turn, subtly, into "And if you want to prevent DoS attacks require tokens" and finally "And for your onion service security require tokens". Who as an onion service provider does not want all of those things? (In particular if you imagine an adversary who wants to stifle onion service adoption by trying to bully onion services into enabling token usage 24/7 thus rendering the UX for users abysmal.)
So, again: are we okay with tokens used differently than we expect? If not, how do we prevent that?
When an onion service is under DoS attack it adds the following line in the "encrypted" (inner) part of the v3 descriptor as a way to signal to its clients that tokens are required for gaining access:
"token-required" SP token-type SP issuer-list NL [At most once] token-type: Is the type of token supported ("res" for this proposal) issuer: A comma separated list of issuers which are supported by this onion service## 4.3. Token issuance
When Alice visits an onion service with an active "token-required" line in its descriptor it checks whether there are any tokens available for this
Maybe better: "any not-yet expired tokens"? If I understood the proposal correctly then the expiry check should be possible at that point and it would potentially save Alice some token generation. Or maybe the token store is taking care of that part where it keeps track of the expiration and only keeps the unexpired ones?
onion service in its token store. If not, it needs to acquire some and hence the token issuance protocol commences.
[snip]
## 5.1. CAPTCHA token issuer
A use case resembling the setup of Cloudflare's PrivacyPass would be to have a CAPTCHA service that issues tokens after a successful CAPTCHA solution.
Tor Project, Inc runs https://ctokens.torproject.org which serves hCaptcha CAPTCHAs. When the user solves a CAPTCHA the server gives back a list of tokens. The amount of tokens rewarded for each solution can be tuned based on abuse level.
How does the abuse level come in? Is that just something based on users over and over again requesting tokens? Or is that a reaction to tokens involved in (DoS) attacks? Or...?
[snip]
## 8.1. Using Res tokens on Exit relays
There are more scenarios within Tor that could benefit from Res tokens however we didn't expand on those use cases to keep the proposal short. In the future, we might want to split this document into two proposals: one proposal that specifies the token scheme, and another that specifies how to use it in the context of onion servicves, so that we can then write more proposals that use the token scheme as a primitive.
I think splitting the proposals up would be really useful. One challenge might be, though, to write the token scheme one in a way that it is easily compatible with tokens for, say, onion services and exit nodes, given that the latter usage might have quite different requirements (you mention some points here in 8.2). I think it's worth a try anyway.
An extremely relevant use case would be to use Res tokens as a way to protect and improve the IP reputation of Exit relays. We can introduce an exit pool that requires tokens in exchange for circuit streams. The idea is that exits that require tokens will see less abuse, and will not have low scores in the various IP address reputation systems that now govern who gets access to websites and web services on the public Internet. We hope that this way we will see less websites blocking Tor.
There is much to say about using tokens in that context, but I guess this should be done in a different proposal/mail, so I'll omit a bunch of points for now. :) One thing I found interesting, though, while thinking about incentives for relay operators was that tokens at exit relays might actually alone be an incentive for more operators running exit relays. Given the hassle for relay operators involved in dealing with abuse and how that affects willingness to run exit nodes I suspect tokens at exits could help with that problem, too.
[snip]
Georg