[Sks-devel] Proposal: Start verifying self-signatures

[Daniel Roesler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy all,

I'm sure by many of you have read the news that a very poorly
generated 4096 RSA keypair was factored.

Disclosure: 
http://trilema.com/2015/full-disclosure-4096-rsa-key-in-the-strongset-factored/

Discussion: https://news.ycombinator.com/item?id=9560790

The key in question (0x51221121) is listed in the keyserver pool as a
subkey for H. Peter Anvin[1]. However, it appears that the signature
on this subkey[2] is a direct copy of the signature on HPA's other
subkey[3]. So this broken subkey appears to have been added manually
and the signature packet copied. Unfortunately, since sks-keyservers
don't check self-signatures on public key packets, this broken subkey
was allowed to be uploaded to the sks-keyserver pool and gossiped
around. If a client imported this public key without checking the
subkey signature (there are more clients out there than GPG), they
might have been fooled into believing that a file was signed by HPA.

I'd like to propose that we revisit the decision to not be proactive
about verifying signatures in the sks-keyserver. Yes, it will always
fall on the client to verify signatures themselves (which GPG does by
not importing the broken subkey), but we should also make and effort
to prevent unverified subkeys from being gossipped around the pool.
Adding defense in depth is a good thing.

To start, I'd like to propose that User ID, User Attribute, or SubKey
self-signatures are verified on upload and on receive from gossip are
verified. If a User ID, User Attribute, or SubKey packet is not
verified via self-signature, the packet should be considered in an
invalid format and dropped.

Pros:
1. Makes it more difficult to insert bogus subkeys into the keyserver pool.
2. Prevents denial of service attacks that allows Mallory to spam a
bunch of new subkeys, user ids, or huge images onto a public key.
3. More confidence for users that are browsing the web interface that
the subkeys/userids that they are seeing are verified.
4. Adding defense in depth to the public key infrastructure.
5. Since we are just verifying self-signatures, there are no worries
about what to do if the issuer does not have their public key in the
pool (we should discuss being proactive about verifying
non-self-signatures, too, but we can discuss that at a later date).

Cons:
1. This adds some cryptography to the sks-keyserver. Luckily,
signature verification crypto doesn't have to worry about side channel
attacks. Alternatively, we could add openssl as a dependency and
outsource the signature verification to it.
2. This adds verification overhead to the server when uploading or
gossiping keys. Computers are much faster nowadays, so I don't know
that we can use this excuse anymore. We should error on the side of
being more proactive about security rather than efficiency.

What were the previous arguments against verifying self-signatures?

Thanks!
Daniel Roesler

[1]: http://p80.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x51221121
[2]: 
https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L498
[3]: 
https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-hpa-pub-json-L566

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVWP4vAAoJEOf2+tFy7+49PR0P/1NnXKbyxOg5M7eiEi2Qtubp
OlnmMvQVXIflzoKAkjMlWVfHDbvL0gvXiv7pvdUa/CosNG8aTWNvjy9FoI9cwPQq
iQ9VZYzLDyWIpU8UZOJG4PJDeQZcRyqpzZC/KEOfYsuKQZ67fMXpKlJR1TrWW8+q
FrrDHkFe8v/gBQecsDm5U8O34EAStI70m/8/ewsWLTbz4j2ZWTw+XIepntbG0Q0p
VESlZ/nWM/j1r+PepoiK+p8foYL5EBb2i5wQwiNPbOjr6W0GghmSRGni5sRiWTze
H1Nlb9VozLggWTlrOzYnnK/fbT7YoenfjWHq8ZFygHr73ntsDvI3gxsWQXoF3WA6
4hXFEm2EReenssULxeKT2Knpgcqy0AYaXA6FJ5kxn1wtBrWcZp1ezRxiOE0Rt/3h
S6oDa2+354xL1klDV+3Gyxff66LhAbSHnG/XadpET+o3qKlHe6CZPAgUwaUvQopj
mlK/Xo9dqqydq4dTCjxD5aHR+/JC9YPEXy+dSHDcsHWEJ2B/EFQ244bEmIUJc1/9
DbF5FjOFNxj7dLYh6iplkI0sC/1q/+AKDV+MzjneSq5nlF+dChyQS/+y5LkR3lAE
e8BIBLoYILVOQOJaMMEMtncnwKWjLHnucdQF8mrEV8Oa8kkyPOkMzU9HDOO5In9q
Mo2hD1M1nXL44/Psgucq
=++nF
-----END PGP SIGNATURE-----