Keyserver flooding attack: mitigation straw-man

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Keyserver flooding attack: mitigation straw-man

Bjarni Runar Einarsson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello SKS-Devel,

Thank you for your efforts on SKS and keeping the public
keyservers running. However people may feel about the merits of
the SKS system itself, you are providing a valuable public
service.

Please forgive me if I'm stating the obvious, or raising ideas
that have been discussed to death before. However I find myself
plagued by an idea that *seems* blindingly obvious to me, but I
haven't seen discussed anywhere yet. Rather than sit on it, I
present it here for your critique.

What follows is a quick draft of a straw-man design for an opt-in
white-list based mitigation of the current flooding attacks.

Key components:

   1. A $reverse-proxy configuration which serves keys from
       disk instead of SKS, if possible
   2. A github (or gitlab, or ..,) repo containing key overrides
       and authorization statements
   3. The default pool inclusion policy requires servers use
       the $reverse-proxy config
   4. The default pool inclusion policy requires servers update
       from the repo once per $period

Assuming this is all in place, the idea is that the owner of a
key has a channel which allows them to exert control over how
their key is presented by the keyserver. The owner of a key can
request an "override" to the public git repository, which the
keyserver pools promise to implement if it is correctly signed.

So if you find your key is being flooded or spammed (or you would
for any other reason like to censor your own key), you sign an
authorization statement with that key, and then issue a pull
request against the shared git repository which adds your
authorization and the key itself to the SKS-override tree. From
that point onward, your key may still be poisoned in the raw SKS
database, but you've prevented it from being served to the
general public and you've prevented the people relying on your
key from being harmed. The cost is, from that point on you will
have to manually update your key using the above workflow instead
of SKS.

The policy of whoever manages the repository, would be to only
merge changes where the authorization statement has a valid
signature from the key owner (tooling can make this easy).

Anyone, including server admins, can hold the repository manager
to account and verify that the key owners really did authorize
the overrides (again, tooling). So this doesn't help people who
need anonymity, but it has accountability which I think would
allow us to start "censoring" which keys are served and how. If
an interface like Github is used, the public PR process also
provides accountability in case the repo admin abuses their
position to reject legitimate override requests.

Yes, it's a band-aid. But it could be implemented in just a day
or two and it would protect end-users and stop the bleeding while
the community figures out what to do about the bigger picture.

And yes, this does place the burden on the victim. It's not
perfect. But I think that is the wrong way to look at this
proposal: I propose giving the victims of flooding and poisoning
and spam attacks a way to take control, instead of being totally
helpless.

I apologise for not having presented a fully working
implementation, but I fear the community is not interested in
this sort of approach and I am reluctant to spend time working on
it until I feel there is at least some support for the idea. I
have prototyped this using nginx locally, and I'd be happy to
share my work if there is interest. But honestly I'm pretty sure
you guys are at least as qualified as I am to configure nginx,
that's not the issue here. :-)

So... what do you think, is this worth exploring further?

It's a very minor technical change, but it's a major rethink of
the current social contract around the SKS keyserver pool.

All the best,
 - Bjarni

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl0jyWwACgkQjgA3FgDP
lJEqNAf+OKmJXLH5AoT2D7oUlE1awPNrTdcANJm5zpMCi6b6+8tfiUz3b1dNSsGH
MTIa0EQbJG7ltvCS9763RofCNmrQTz6GcmhrWYwgylu9DGpgnbxyM0LaDh+WISVA
cjyJKNXEQtJE1M/RZwpXcLkZzW9nW6l07qtBe7b0xx5wveOycmg/8JOc99wMiqQb
dlk3llvOwZJF5eAQnpjQ0kRi3nEhfd/yUJ/9GhBYgmf1JjrCsYnOT6pYii+ch4FW
itqTb8VbzvF9O+pvVD+XzYxiHO2N64DVCFhOHxDMeXtoibujLphei5Mm2/9xTE/V
L1ZJ+0L+vcP1WikVwk0RMzdcA7UzZQ==
=0l1p
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyserver flooding attack: mitigation straw-man

Philihp Busby
Sounds reasonable, but why not just use Hagrid?

On 2019-07-08T22:53:04Z (10:53PM -0000) Bjarni Runar Einarsson <[hidden email]> sed:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>Hello SKS-Devel,
>
>Thank you for your efforts on SKS and keeping the public
>keyservers running. However people may feel about the merits of
>the SKS system itself, you are providing a valuable public
>service.
>
>Please forgive me if I'm stating the obvious, or raising ideas
>that have been discussed to death before. However I find myself
>plagued by an idea that *seems* blindingly obvious to me, but I
>haven't seen discussed anywhere yet. Rather than sit on it, I
>present it here for your critique.
>
>What follows is a quick draft of a straw-man design for an opt-in
>white-list based mitigation of the current flooding attacks.
>
>Key components:
>
>   1. A $reverse-proxy configuration which serves keys from
>       disk instead of SKS, if possible
>   2. A github (or gitlab, or ..,) repo containing key overrides
>       and authorization statements
>   3. The default pool inclusion policy requires servers use
>       the $reverse-proxy config
>   4. The default pool inclusion policy requires servers update
>       from the repo once per $period
>
>Assuming this is all in place, the idea is that the owner of a
>key has a channel which allows them to exert control over how
>their key is presented by the keyserver. The owner of a key can
>request an "override" to the public git repository, which the
>keyserver pools promise to implement if it is correctly signed.
>
>So if you find your key is being flooded or spammed (or you would
>for any other reason like to censor your own key), you sign an
>authorization statement with that key, and then issue a pull
>request against the shared git repository which adds your
>authorization and the key itself to the SKS-override tree. From
>that point onward, your key may still be poisoned in the raw SKS
>database, but you've prevented it from being served to the
>general public and you've prevented the people relying on your
>key from being harmed. The cost is, from that point on you will
>have to manually update your key using the above workflow instead
>of SKS.
>
>The policy of whoever manages the repository, would be to only
>merge changes where the authorization statement has a valid
>signature from the key owner (tooling can make this easy).
>
>Anyone, including server admins, can hold the repository manager
>to account and verify that the key owners really did authorize
>the overrides (again, tooling). So this doesn't help people who
>need anonymity, but it has accountability which I think would
>allow us to start "censoring" which keys are served and how. If
>an interface like Github is used, the public PR process also
>provides accountability in case the repo admin abuses their
>position to reject legitimate override requests.
>
>Yes, it's a band-aid. But it could be implemented in just a day
>or two and it would protect end-users and stop the bleeding while
>the community figures out what to do about the bigger picture.
>
>And yes, this does place the burden on the victim. It's not
>perfect. But I think that is the wrong way to look at this
>proposal: I propose giving the victims of flooding and poisoning
>and spam attacks a way to take control, instead of being totally
>helpless.
>
>I apologise for not having presented a fully working
>implementation, but I fear the community is not interested in
>this sort of approach and I am reluctant to spend time working on
>it until I feel there is at least some support for the idea. I
>have prototyped this using nginx locally, and I'd be happy to
>share my work if there is interest. But honestly I'm pretty sure
>you guys are at least as qualified as I am to configure nginx,
>that's not the issue here. :-)
>
>So... what do you think, is this worth exploring further?
>
>It's a very minor technical change, but it's a major rethink of
>the current social contract around the SKS keyserver pool.
>
>All the best,
> - Bjarni
>
>-----BEGIN PGP SIGNATURE-----
>
>iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl0jyWwACgkQjgA3FgDP
>lJEqNAf+OKmJXLH5AoT2D7oUlE1awPNrTdcANJm5zpMCi6b6+8tfiUz3b1dNSsGH
>MTIa0EQbJG7ltvCS9763RofCNmrQTz6GcmhrWYwgylu9DGpgnbxyM0LaDh+WISVA
>cjyJKNXEQtJE1M/RZwpXcLkZzW9nW6l07qtBe7b0xx5wveOycmg/8JOc99wMiqQb
>dlk3llvOwZJF5eAQnpjQ0kRi3nEhfd/yUJ/9GhBYgmf1JjrCsYnOT6pYii+ch4FW
>itqTb8VbzvF9O+pvVD+XzYxiHO2N64DVCFhOHxDMeXtoibujLphei5Mm2/9xTE/V
>L1ZJ+0L+vcP1WikVwk0RMzdcA7UzZQ==
>=0l1p
>-----END PGP SIGNATURE-----

>_______________________________________________
>Sks-devel mailing list
>[hidden email]
>https://lists.nongnu.org/mailman/listinfo/sks-devel


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (997 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keyserver flooding attack: mitigation straw-man

Bjarni Runar Einarsson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Philihp Busby <[hidden email]> wrote:
> Sounds reasonable, but why not just use Hagrid?

I like Hagrid.

But it doesn't solve the same problems. Hagrid (deliberately)
does not support all of the same workflows as the SKS keyserver
pool, nor does Hagrid federate (yet), which is an sticking point
for many.

Also note that I'm talking about what we could do *this week*, to
buy time for the community to decide whether "just use Hagrid"
(maybe with a few new features) is in fact the right course of
action.

Thanks for reading!

 - Bjarni

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl0j2IcACgkQjgA3FgDP
lJHRLgf+JLsKesrKnEFEryKOx7092e5n/Wez1mN73jDT4CkgGqVLUx17bWmhJ6Bz
1rFHEyQ5SAYanVQ+nzm/Qo/2hzBAn0W/BmHT6bKte6tGNB2o28O5epJLd6iaMUyc
RveoYIDVgDCqLP1PAXLTSm/OmHc7NbVNpnZvEDkn63EzhVaPqWlwGO3eIgBkp+vx
ba3MrSEbXh+k1RTwA3mSP7smGApe08/iAHKAnOQHHlXEh4k3zlu30iK4o/CcZ+jg
Cu5DXshsoMN6s26ecpUCpvne4uyG7wuH9gHnJgo/tKPyNegNHxzznYLxFNIHbra4
0c+yYHu3vVhl+Tc2DLmdjrL6iwPOGA==
=2hSf
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyserver flooding attack: mitigation straw-man

Yegor Timoshenko
In reply to this post by Bjarni Runar Einarsson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bjarni, thanks for creating the MUA I'm using to write this
message!

> So if you find your key is being flooded or spammed (or you
> would for any other reason like to censor your own key), you
> sign an authorization statement with that key, and then issue a
> pull request against the shared git repository which adds your
> authorization and the key itself to the SKS-override tree. From
> that point onward, your key may still be poisoned in the raw
> SKS database, but you've prevented it from being served to the
> general public and you've prevented the people relying on your
> key from being harmed. The cost is, from that point on you will
> have to manually update your key using the above workflow
> instead of SKS.
Overall, this sounds like a MVP for protecting against current
attack results by policy. Specific workflow you've described does
work for long-term consequences.

However.

First off, there is the social problem of getting all peers
on-board with this workflow, which I will not get into.

Then, there is a number of massive denial-of-service
vulnerabilities in SKS gossip protocol: the simplest one is that
if attacker pushes >1 MB worth of unique OpenPGP packets for a
specific key separated onto 3 or more keyservers, merging process
will escalate traffic between keyservers to that comparable of a
distributed denial-of-service attack (this happens because of
timeouts and subsequent retries from each peer), while merging
itself seems to be an O(n^2) operation.

It is possible to partly mitigate this issue using bandaids, for
example, see:
https://gist.github.com/yegortimoshenko/781c880be8f1b8a91c9c23fa83a35d58

That said, it won't stop any attacker with computing power
comparable to that of PocketBeagle from destroying the whole SKS
network (disabling everyone who peers, that is), because they can
keep changing the keys (say, automatically) faster than anyone
can keep up. So, any bandaid would only work against accidental
or limited attacks. Also, mitigation requires applying a patch,
or at least, given an intricate enough patch, centralized
blacklist, in which case effective tradeoffs of the whole system
will be similar to those of centralized keyserver designs like
Hagrid (https://keys.openpgp.org).

Same concerns/limitations also apply to this flooding attack, or
poisoning attacks that abuse the fact that SKS accepts non-RFC
compliant packets: potential attacker might as well flood/poison
everyone's keys, because no known attack seems to require much in
terms of time or computing power.

I think the logical continuation of your idea is to convert SKS
dump to a Git repo and serve keys from there and accept any
modifications to it via pull requests from that point forward.
I'd guess that many SKS operators would switch to plain-text
database as source of truth, as a transparent forkable medium. It
does require human resources to keep up however, and quite likely
I underestimate the scale of things.

TLDR: This is an improvement, but it won't stop any malicious
attacker (i.e. anyone who wants to take down SKS, either by
flooding or poisoning all keys or by abusing denial-of-service
issues in gossip protocol).

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE2O6+NAvfE/J3pC6k+HLNsxw094UFAl0j2gYACgkQ+HLNsxw0
94XjtQv+LS0CUIGcypbK3mqTSZj63V9CvSOLB03817FYt5YsMFlBEqqO216vpZg2
2KB9BJ2O5AUj4+r93EncixIz+AlbSMb2PvCUxJTPSNp3zLaxfzZxKcmU4r3tNcJu
RKQAxjfTceDwp4VrH/HMu8qSG0KKn7o2cC1F35D7QPBOUZZxd4CQ2lBjLfsYa7yu
Ia1eu3aLugl4gGT/eHabtYdFFuPQWcpAg73RGVeTyFrmxHMtu5yl87+yORxbCLTh
9nbWXLlMT6KVZH4gqpONiks22a1f9ht2wWwv8CkLzT68rUx4LrDyjRCHZ6UVJhdD
DcCHMU9A3sspTIrkrc29Ga7VFCC/4sx2wntDJhW07CeaehmPEPEtB2kzaBRbAx9F
aeWkozAkSyLYSzxC4yYy7Y0QaskS2fy13SFgRpfkwdi4rlL0U5PVxnqCu5D4wYFu
/XzhkkvcIpLIRkjm6IKZaMpDBnleYK8erTj7A8o/s1IrzeWsLZNErvvBdtlqIVaC
HU/E91GZ
=1Ndp
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyserver flooding attack: mitigation straw-man

Bjarni Runar Einarsson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yegor Timoshenko <[hidden email]> wrote:
> Bjarni, thanks for creating the MUA I'm using to write this
> message!

Hah, you're welcome. :-)

> That said, it won't stop any attacker with computing power
> comparable to that of PocketBeagle from destroying the whole
> SKS network (disabling everyone who peers, that is), because

This is correct, however ...

> TLDR: This is an improvement, but it won't stop any malicious
> attacker (i.e. anyone who wants to take down SKS, either by
> flooding or poisoning all keys or by abusing denial-of-service
> issues in gossip protocol).

I think this depends on the motivations of the attacker - which
we can in this case venture guesses about, given the contents and
context of the vandalism.

Adding an official way for the SKS network to at least partially
respect the wishes of key owners who want to remove their names
or e-mails. or otherwise have some control over how their key is
presented, may actually eliminate the motivation to burn it all
to the ground.

Wanting this myself is part of what motivated me to post the
straw-man at all; I think this would be a generally useful
addition. If not the letter, it is at least closer to the spirit
of things like the GDPR and related, valid concerns people have
raised repeatedly.

Thanks for the thoughtful response!
 - Bjarni

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEETBSz4pzXkOHlSFMhjgA3FgDPlJEFAl0j3RkACgkQjgA3FgDP
lJFp4Af+MUo8uTkbhkP+n+zULxCslFvDiwZ4NKh0QG0uTVjLH9VNJSLpIFQiKAMp
s6g1HfX74PDc4G8aPRvdea0O50ZINHgBi+8tHIusrlEsyz3yv69RZF+83S7NfeTH
SjkvMhBP/BcnNZ5QYPNko1ho9qQm/rbmIdmaFpnC2hok4jwfGBbokhg5pVsrJhns
A09RRC7+ZAQnAUaT8Qdor8jRy9wQhO3qGg5RZMBbMrJsMsQSdk/bei+8PhGeCeqK
SmhZ1jJ8wNlvnlEzN7q1chXkB5WxSDRyGcGWij+nl0x1gFNAXaSJpZIiVUWhKSsO
noHOkoX3UVNLufWOgMiCYww7kpsjig==
=gL4t
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyserver flooding attack: mitigation straw-man

compuguy
In reply to this post by Yegor Timoshenko
Yegor Timoshenko wrote

>
> I think the logical continuation of your idea is to convert SKS
> dump to a Git repo and serve keys from there and accept any
> modifications to it via pull requests from that point forward.
> I'd guess that many SKS operators would switch to plain-text
> database as source of truth, as a transparent forkable medium. It
> does require human resources to keep up however, and quite likely
> I underestimate the scale of things.
>
> TLDR: This is an improvement, but it won't stop any malicious
> attacker (i.e. anyone who wants to take down SKS, either by
> flooding or poisoning all keys or by abusing denial-of-service
> issues in gossip protocol).

I think the git repo proposal is the best way forward. The current way the
SKS Keyservers propagate changes is way to vulnerable to abuse/DoS.

-compuguy



--
Sent from: http://nongnu.13855.n7.nabble.com/SKS-Devel-f83255.html

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel