Hi Thijs, On Fri, 22 Aug 2014 13:41:20 +0200 "Thijs Kinkhorst" <[email protected]> wrote:
> This bug has been fixed in GnuPG 1.4.17. > > Although it's a good robustness and anti-keyring-polution measure, I > don't think it's an acute security issue in stable that needs to be > fixed in a DSA, because the threat model is unclear to me. The threat model is that someone has received a fingerprint over a trusted channel and is using that fingerprint to retrieve a key. Since a fingerprint is sufficient to validate a key, the user would not do any additional validation after retrieving the key, allowing a malicious key server to return a phony key that the user would trust. > I think it's well understood that keyservers are not trustworthy per > se and that the web of trust is to be used to verify which keys are > to be trusted. If you need to rely on a keyserver not being rogue > you've already lost. Any key injected in such a download would still > not pass web of trust validation. Web of Trust is not the only way to validate keys. Comparing fingerprints is another way. Though I use the WoT, I also print my fingerprint on my personal business card, so someone whom I've met in person has a way of retrieving and validating my key without using the WoT, which I've found is difficult for casual GPG users to use. Others may want to avoid the WoT entirely because it publicly leaks information about their social connections. While it's definitely true that you can't trust anything retrieved from a key server by key ID or UID, you ought to be able to trust a key retrieved by full fingerprint. It's a reasonable assumption that you don't need to run `gpg --fingerprint` to verify the fingerprint of a key you just downloaded by fingerprint. I held this assumption, and judging by reactions I saw on Twitter, I was not alone. I fear that other users still hold this assumption, and if this bug is not corrected in a DSA, these users will be at risk of downloading and trusting a phony key. Cheers, Andrew -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
