Re: [stir] Anti-spam with blind signatures

["Asveren, Tolga" <[e-mail]>]

A few questions:

i- What are the options to avoid IP linkage if sender is a smart-device, i.e. no STIR-aware GW is involved?
ii- How would this be used for scenarios involving a STIR-aware GW? Would GW use a different K_temp for each individual calling identity?
iii- Is there a real need for this if a GW is involved? A GW can anyhow rate limit ingress calls (also for other reasons) based on calling identity.

Thanks,
Tolga

From: stir [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Friday, July 28, 2017 1:03 PM
To: [e-mail]
Subject: [stir] Anti-spam with blind signatures

As Jon mentioned in Prague, our best privacy story is to encrypt the
PASSporT under the recipient's public key, thus protecting the
*sender's* identity (though of course not the recipient's [0]).
However, the problem now becomes that unauthenticated senders
can just spam the CPS.

We can significantly mitigate this issue by forcing senders to
authenticate each time they want to send an encrypted PASSporT but
decoupling that authentication from the actual PASSporT. This
comes at a small privacy cost of leaking the velocity at which
a caller makes calls (or technically, stores PASSporTs) but not
to whom. In order to do this, we can use "blind signatures" [1].
The basic protocol flow is as follows:

    Sender                                 CPS

    Authenticate to CPS --------------------->
    Blinded(K_temp) ------------------------->
    <------------- Sign(K_cps, Blinded(K_temp))
    [Disconnect]


    Sign(K_cps, K_temp))
    Sign(K_temp, E(K_receiver, PASSporT)) --->

In the first phase, the sender connects to the CPS, authenticates,
and sends a blinded version of a freshly generated public key. The
CPS returns a signed version of that blinded key. The sender can
then unblind the key and gets a signature on K_temp from the CPS

Then later, when it wants to send something, the sender connects
to the CPS anonymously (note: need to avoid IP linkage here) and
sends both the signed K_temp and its own signature over the
encrypted PASSporT. The CPS verifies both signatures and if they
verify, stores the encrypted passport (discarding the signatures).

This design lets the CPS rate limit how many PASSporTs a given
sender can store just by counting how many times K_temp appears
(there are things we might do to make this easier). Obviously,
this isn't perfect because you can't tell if a sender is just
sending bogus data, and I don't know how to fix that yet, but it's
a big improvement over the status quo.

-Ekr

[0] Though we could probably get *some* traction here by bucketing
these blobs by some granularity courser than recipient identity, such
as taking a prefix of H(recipient_pub).

[1] https://en.wikipedia.org/wiki/Blind_signature. The way this
works is that I can give you a "blinded" version of some message M.
You then sign the blinded version and send me the signature, and
I "unblind" the signature and recover a signature on M.