SKS Keyserver Network Under Attack

[Guilhem Moulin]

On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote:
> | High-risk users should stop using the keyserver network immediately.
> 
> So OK, I can purge requests to SKS keyservers from my machines. But what
> about upstream impacts? As I understand it, GnuPG authentication is
> pervasive. And I suspect that getting missing keys from SKS is common.
> As an error trap, if nothing else.

Third-party signatures from locally unknown certificates are arguably
not so useful, so how about using ‘--keyserver-options import-clean’?
(Or even making it the default behavior?)  Of course it's not perfect as
it still clutters network traffic and gpg(1) needs to clean up the mess
client-side (which is slow and CPU expensive), but at least it mitigates
the DoS attack: it doesn't prevent keyring updates, and limits the bloat
on disk.

Compare

    ~$ export GNUPGHOME="$(mktemp --tmpdir=/dev/shm --directory)"
    ~$ alias time="command time -f '%E (%U user, %S sys)  %P CPU  %Mk maxres'"
    ~$ gpg --import /usr/share/keyrings/*.gpg
    ~$ gpg --with-colons --list-sigs | grep -c ^pub:
    1187
    ~$ gpg --with-colons --list-sigs | grep -c ^sig:
    56001
    ~$ stat -c %s "$GNUPGHOME/pubring.kbx"
    34041308
    ~$ time gpg --recv-keys \
        C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \
        CC11BE7CBBED77B120F37B011DCBDC01B44427C7
    gpg: key 1DCBDC01B44427C7: 149109 signatures not checked due to missing keys
    gpg: error writing keyring '…/pubring.kbx': Provided object is too large
    gpg: key F20691179038E5C6: 54608 signatures not checked due to missing keys
    gpg: error writing keyring '…/pubring.kbx': Provided object is too large
    […]
    Command exited with non-zero status 2
    10:53.44 (269.47 user, 362.81 sys)  96% CPU  330976k maxres

(which fails the keyring update operation) with

    […]
    ~$ time gpg --keyserver-options import-clean --recv-keys \
        C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \
        CC11BE7CBBED77B120F37B011DCBDC01B44427C7
    gpg: key 1DCBDC01B44427C7: 1 duplicate signature removed
    gpg: key 1DCBDC01B44427C7: 1 signature reordered
    gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen <rjh at sixdemonbag.org>" imported
    gpg: key F20691179038E5C6: 2 duplicate signatures removed
    gpg: key F20691179038E5C6: 2 signatures reordered
    gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <dkg at fifthhorseman.net>" not changed
    gpg: no ultimately trusted keys found
    gpg: Total number processed: 2
    gpg:               imported: 1
    gpg:              unchanged: 1
    49:48.80 (1668.47 user, 1305.03 sys)  99% CPU  190840k maxres

(The initial import of /usr/share/keyrings/*.gpg is merely there to
start with a non-trivial keyring.  In particular, a keyring containing
certificates that issued third-party signatures on 1DCBDC01B44427C7 and
F20691179038E5C6.  The keyring even contains a non-poisoned version of
dkg's key, as on my system the glob matches ‘/usr/share/keyrings/debian-keyring.gpg’.)

I suppose validating keyservers are the way to go, but it seems like
there is currently no good solution for third-party signatures.  For
workflow relying on these (at least for locally known signers), or which
for some other reason need to stick to SKS, a possible mitigation is to
pass `--keyserver-options import-clean`.  As seen above refreshing the
keyring might take a veeery long time (possibly room for improvement,
from an algorithmic perspective I don't get why filtering signature
packets from unknown signers is so slow), but at least succeeds in
getting updates from SKS. 

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190630/97b93688/attachment-0001.sig>