I agree for keyserver imports. For all other imports this would be a severe regression and thus the wrong thing to do.

hm, i see your point. If you could spell out what the specific regression(s) in more detail, though, that might help us to reason about their impact.

I took a look at the different channels in terms of who is capable of flooding the local keyring and inducing a DoS via poor performance:

• public keyservers (SKS pool or equivalent): trivial keyring DoS by anyone
• WKD, LDAP: keyring DoS by operator of domain
• honoring "preferred-keyserver" URLs: keyring DoS by certificate owner, since they control the URL
• constrained keyserver (e.g. keys.mailvelope.com, keys.openpgp.org): keyring DoS by keyserver operator.
• DANE -- not directly DoSable, due to DNS RR being limited to 64KiB (repeated queries from a malicious DNS server could build to a DoS, but that seems farther afield)
• --import from stdin -- self-DoS, maybe not worth protecting against by default

am i missing any other input channels?

how would you apply such a constraint to one channel or the other?

One reason is that you may want to look at older key- or self-signatures which import-clean removes. I can imgine use cases where this has been used for something. People are ofteh doing inetresting things with standard tools.

Now for your list:

• Keyservers: It is meanwhile obvious that we should not allow any key-signature import.
• WKD: GnuPG applies import-minimal and other filters.
• LDAP: Same as with the keyservers but is is used so often in-house that we can;t stop loading key-signature from there. Thanks for mentioning this; I may have handled this like HKP servers.
• Preferred keyservers are heavily discouraged and would anyway use the same code path as other keyservers.
• DANE: Also the keyserver code path but I think that we should not limit it. I can't remever the RFC details right now, it might even suggest to use create keys using export-minmal and then we should do the same.
• stdin: This is all kind of imports from other tools (e.g. keybase.io). I would not like to add change anything here.

in 2.2.16, anyway, gnupg does not appear to apply import-minimal for WKD.

from an empty GNUPGHOME:

0 dkg@alice:/tmp/cdtemp.FNyxgP$ gpg --list-sigs
0 dkg@alice:/tmp/cdtemp.FNyxgP$ gpg --locate-keys dkg@debian.org
gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <dkg@debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found
pub   ed25519 2019-01-19 [C] [expires: 2021-01-18]
      C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
uid           [ unknown] Daniel Kahn Gillmor <dkg@debian.org>
sub   ed25519 2019-01-19 [S] [expires: 2020-01-19]
sub   ed25519 2019-01-19 [A] [expires: 2020-01-19]
sub   cv25519 2019-01-19 [E] [expires: 2020-01-19]

0 dkg@alice:/tmp/cdtemp.FNyxgP$ gpg --list-sigs
/tmp/cdtemp.FNyxgP/pubring.kbx
------------------------------
pub   ed25519 2019-01-19 [C] [expires: 2021-01-18]
      C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
uid           [ unknown] Daniel Kahn Gillmor <dkg@debian.org>
sig 3        F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>
sig          792152527B75921E 2019-01-21  [User ID not found]
sig          8CBF9A322861A790 2019-01-20  [User ID not found]
sig          F6D3495BB0AE9A02 2019-01-19  [User ID not found]
sub   ed25519 2019-01-19 [S] [expires: 2020-01-19]
sig          F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>
sub   ed25519 2019-01-19 [A] [expires: 2020-01-19]
sig          F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>
sub   cv25519 2019-01-19 [E] [expires: 2020-01-19]
sig          F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>

0 dkg@alice:/tmp/cdtemp.FNyxgP$ gpg --edit-key dkg minimize save
gpg (GnuPG) 2.2.16; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  ed25519/F20691179038E5C6
     created: 2019-01-19  expires: 2021-01-18  usage: C   
     trust: unknown       validity: unknown
sub  ed25519/7618196529AE5FF8
     created: 2019-01-19  expires: 2020-01-19  usage: S   
sub  ed25519/3BAD4F117215E775
     created: 2019-01-19  expires: 2020-01-19  usage: A   
sub  cv25519/B0A9B7B2D8D2CE47
     created: 2019-01-19  expires: 2020-01-19  usage: E   
[ unknown] (1). Daniel Kahn Gillmor <dkg@debian.org>

User ID "Daniel Kahn Gillmor <dkg@debian.org>": 3 signatures removed

pub  ed25519/F20691179038E5C6
     created: 2019-01-19  expires: 2021-01-18  usage: C   
     trust: unknown       validity: unknown
sub  ed25519/7618196529AE5FF8
     created: 2019-01-19  expires: 2020-01-19  usage: S   
sub  ed25519/3BAD4F117215E775
     created: 2019-01-19  expires: 2020-01-19  usage: A   
sub  cv25519/B0A9B7B2D8D2CE47
     created: 2019-01-19  expires: 2020-01-19  usage: E   
[ unknown] (1). Daniel Kahn Gillmor <dkg@debian.org>

0 dkg@alice:/tmp/cdtemp.FNyxgP$ gpg --list-sigs
/tmp/cdtemp.FNyxgP/pubring.kbx
------------------------------
pub   ed25519 2019-01-19 [C] [expires: 2021-01-18]
      C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
uid           [ unknown] Daniel Kahn Gillmor <dkg@debian.org>
sig 3        F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>
sub   ed25519 2019-01-19 [S] [expires: 2020-01-19]
sig          F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>
sub   ed25519 2019-01-19 [A] [expires: 2020-01-19]
sig          F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>
sub   cv25519 2019-01-19 [E] [expires: 2020-01-19]
sig          F20691179038E5C6 2019-01-19  Daniel Kahn Gillmor <dkg@debian.org>

0 dkg@alice:/tmp/cdtemp.FNyxgP$

In particular, note the User ID not found lines emitted after --locate-keys but before the minimize command is run. They go away after minimize.

If WKD is supposed to apply import-minimal, i can open a separate ticket about that if you like.

Well, I mixed this up. On sending a a new key to the server export-minimal is used. Receiving a key uses keep-uid=REQUESTED and a 64k limit.

@werner, i don't think there is a 64K limit either, at least not in 2.2.16. Here is 2.2.16 with an empty homedir fetching Zack's certificate here which is > 97KiB:

0 dkg@alice:/tmp/cdtemp.oR17hW$ gpg --list-keys
0 dkg@alice:/tmp/cdtemp.oR17hW$ gpg --locate-keys zack@debian.org
gpg: key 9C31503C6D866396: public key "Stefano Zacchiroli <zack@debian.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found
pub   rsa4096 2010-09-27 [SC] [expires: 2020-02-07]
      4900707DDC5C07F2DECB02839C31503C6D866396
uid           [ unknown] Stefano Zacchiroli <zack@debian.org>
sub   rsa4096 2010-09-27 [E]
sub   rsa4096 2012-12-01 [S] [expires: 2020-02-07]

0 dkg@alice:/tmp/cdtemp.oR17hW$ gpg --export zack@debian.org | wc
    562    2292   99589
0 dkg@alice:/tmp/cdtemp.oR17hW$

fwiw, i think 64KiB is too small anyway, so i'm glad that limit is not in place. It would be good to have the WKD draft have some clearly-stated expectations about client behavior to establish norms there. I've opened T4613 to record that suggestion.

You are right. I again mixed this up with gpg-wks-client. Over there we have a limit implemented unsing --max-output to avoid compression based attacks.

What I recently changed is a limit on the number of keys accepted.

I see that you have lowered the WKD limit to 64KiB with 6396f8d115f21ae15571b683e9ac9d1d7e3f44f4 -- i think this is a mistake, as reasonable certificates can be several times that size (e.g. zack's cleaned certificate, mentioned above). I'd prefer a limit of 256KiB.

fwiw, in the debian.org WKD directory, we're publishing all the debian developers' certificates (for those DD's whose certificates include an @debian.org e-mail address), and including all certifications from all other people associated with debian (all DD's and Debian Maintainers). zack's certificate is the largest of the bunch, at ~97KiB. So even a limit of 128KiB would let his certificate be loaded.

This is especially relevant if you are not going to implement the fallback to import-clean that was proposed in T4591.

That is a limit for the web key service to publish a certificate. IIRC, Debian developers do not use this but Debian creates the WKD from a database.

Due to T4628, i no longer think that import-clean is a good idea by default.

In my earlier comments here, i had not understood that it would have an impact on the locally-held third-party certifications.