[tor-dev] [RFC] Proposal: "Res tokens: Anonymous Credentials for Onion Service DoS Resilience"

Sun Jun 13 12:00:50 UTC 2021

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20210613/854ced9c/attachment.sig>