[pkg-gnupg-maint] Bug#1009311: Bug#1009311: dirmngr: should no longer use keys.openpgp.org by default

[Daniel Kahn Gillmor]

Control: tags 1009311 + wontfix

Hi Vincent--

On Mon 2022-04-11 16:18:45 +0200, Vincent Lefevre wrote:
> The default https://keys.openpgp.org:443 key server is no longer working:
>
> $ gpg -v --recv-keys 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4
> gpg: data source: https://keys.openpgp.org:443
> gpg: pub  rsa2048/ACF8146CAE8CBBC4 2019-01-02  
> gpg: key ACF8146CAE8CBBC4: new key but contains no user ID - skipped
> gpg: Total number processed: 1
> gpg:           w/o user IDs: 1
>
> https://superuser.com/questions/1485213/gpg-cant-import-key-new-key-but-contains-no-user-id-skipped
> says: "You are probably using the keys.openpgp.org keyserver, which
> has an owner approval system – it will strip all user IDs unless
> the owner of the corresponding email address has allowed them to be
> published. Try to download the key from elsewhere [...]"
>
> The consequence is that when I want to check a signature made with
> this key, I get:
>
> gpg: Signature made 2022-04-09T21:49:20 CEST
> gpg:                using RSA key 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4
> gpg: Can't check signature: No public key

Upstream's preferred default keyserver, hkps://keyserver.ubuntu.com runs
a hockeypuck installation, which distributes arbitrarily large OpenPGP
certificates.  That keyserver is vulnerable to flooding attacks (see
https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/
for more detail)

For example, consider trying to fetch GnuPG upstream (Werner Koch)'s old
OpenPGP certificate from the upstream-preferred default keyserver:
0x80615870F5BAD690333686D0F2AD85AC1E42B367 (or try fetching my own
expired key 0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6 for that matter).
The upstream preferred keyserver will push tens of megabytes to you of
flooded key material.  Recent versions of GnuPG will discard almost all
of that data (gpg's dirmngr defaults to importing self-sigs only so that
a flooded certificate doesn't make your local keyring unusable as well),
but the transmission alone will still cost the user in terms of
bandwidth, latency, and battery life.

Anyone who wants to can flood any key on the upstream-preferred default
keyserver, just by pushing additional third-party certifications.

keys.openpgp.org is significantly more conservative: public key material
will show up there, as will revocations and subkey material.  but user
id information is only distributed if the user has responded to an
e-mail feedback request from the operators of keys.openpgp.org
confirming their intent to publish the User ID that contains that e-mail
address.

So we have two choices to compare between:

a) a default keyserver that is willing to publish any user ID
   information, but also permits arbitrarily flooded certificates.

b) a default keyserver that only publishes self-signed material, but
   won't distribute User IDs unless the e-mail account holder has
   explicitly signalled their intent to publish to that keyserver.

Given the bandwidth costs and potential for severe DoS on any user
associated with (a), (b) appears to be a more stable and responsible
default.

If another keyserver operator offers a different value proposition that
is better than either (a) or (b), i'm willing to consider it as a default
for debian.  Or, if someone else wants to take over the packaging of
GnuPG in debian, and they see the comparative advantage differently, i'd
be happy to let them make the decision.

           --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220428/75213b51/attachment.sig>