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

[Kristian Fiskerstrand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/17/2015 10:47 PM, Daniel Roesler wrote:
> 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.

And that means OpenPGP worked exactly as it should and the invalid
data was rejected by clients.

> 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.

Then that client is broken and other issues are bound to be
encountered anyways


> 
> 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),

exactly

> 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.

Not necessarily, OpenPGP is based on object security and all data is
self-contained for a reason, how you choose to distribute the key
should not matter, and any expectation of security coming from either
the transport nor keyserver validation can actually reduce security as
it introduce a point to subvert.

> 
> 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.

Please elaborate on how this is a DoS, I can see it being
un-appealing, but for it to qualify as a DoS the bar is higher than that.

> 3. More confidence for users that are browsing the web interface 
> that the subkeys/userids that they are seeing are verified.

This is a bad thing, they shouldn't believe it is without properly
verifying it

> 4. Adding defense in depth to the public key infrastructure.

No it doesn't , the security properties come from its design

> 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.

More code paths and complexities that opens up for new attack vectors
, high computational overhead and little gain

> 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.

No, because it doesn't solve anything

PS! Ironically your message itself has a bad signature, not sure if
that was intended ironically or not.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Donec eris sospes, multos numerabis amicos.
Tempora si fuerint nubila, solus eris.
As long as you are wealthy,you will have many friends.
When the tough times come, you will be left alone
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJVWQFtAAoJEP7VAChXwav6IQkH/3gq8bIwefH/7RohRWWP6ElA
67IUPENGsTbHpqgnbJAUrnpPZS1uSxZE1eAsSU1RNHUwje+af9BSB4MZR4q2Acsw
eQQ21tJhlSf6s9mki5Qz96aoSN39AHJ73xiknytTFOChUJViNNW/qQ5cqvLE5r2F
xvEpm02F9fddUNiCvJ2cp2jtRhO2T9IU1IqYu1MD29rNTj9hXj93I0m9V6bNXvNs
WtqdS+JGxQDjdV/ZoSLM8n0mPvIQCS9M5UIhKJxwz5gKv9LkjNpvOoNMv8Vprz9F
qNe4OK5D3pMU/i9Jzbw0gg8PM4iY3ZqKuTCI5fhU6jBhTBGTchfUh8I3B8o4DAM=
=I2HG
-----END PGP SIGNATURE-----