oss-sec mailing list archives
Re: CVE Request: evolution mail client GPG key selection issue
From: Kurt Seifried <kseifried () redhat com>
Date: Thu, 25 Jul 2013 13:19:50 -0600
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/25/2013 11:05 AM, Daniel Kahn Gillmor wrote:
On 07/25/2013 04:46 AM, Kurt Seifried wrote:Yeah this was discussed internally a bit at Red Hat after you filed the bug, it's a messy problem. I think one concern was where do you want to place policy decisions for key usage and trust, in GPG, in the app using it, or something else?This is a critical observation. there currently exists a lot of infrastructure which uses gpg as the backend for dealing with keys. Moving those decision processes out of gpg and into frontends means that any tool which relies on gpg itself won't be able to make use of those policy decisions implemented only in a frontend.
One problem moving it to the backend is I may trust your key to sign email, but not to sign code and vice versa. At least for RPM this is handled internally (you install the key into RPM) so that's one less worry.
One concern I have is I sometimes used to (not any more!) download all the signing keys for keys I was using to see if I could establish a web of trust.Do you refresh your keyring regularly? If not, you risk not receiving
Yup. Key management sucks even with good software, and we don't have good software for this. Witness CRL/OCSP and then all the vendors shipping browser updates to specifically blacklist compromised certificates.
notification of revocation and other updates. If you do refresh your keyring regularly, then you are also vulnerable to arbitrary user ID and subkey injection, since keys are fetched by keyid or fingerprint (including by subkey) and anyone can graft someone else's primary key to their own key as a subkey (even an expired one, or one without proper usage flags).
Yeah the use of KeyIDs is just stupid (although I get why they did it, I still think it was stupid), they're to short. We should be using fingerprints only. Sigh.
In short: if anyone is relying on their local keyring as a "safe" storage place for keys they believe are valid, they're in an untenable position.
True, and trust me if my key ever gets compromised (and I know about it) I'll be phoning certain people and not relying on key revocation to let them know.
GnuPG needs the user to explicitly indicate which keys are valid, and user agents which use GnuPG to encrypt messages need to only send to keys which are known to be validly bound (by a trusted certifier) to the User ID in question.
The problem here is the all or nothing trust setting. I may trust your key enough to use it to encrypt email to you, but not to accept signed email from you for example. To steal a phrase from Moxie Marlinspike "no trust agility".
This can be done by either (a) designating certain keys with strong enough "ownertrust" and then being willing to rely on their certifications, or by the user themselves certifying keys that they believe to be valid. If the user is the only trusted certifier, and they have a key that they are willing to use for a remote peer but they do not want to publish their certification, they can make a non-exportable certification (a.k.a. "local signature") to indicate to gpg that the peer's key is valid for their address.
Also for what kind of usage.
Any ways for evolutions please use CVE-2013-4166 for this issue. Has anyone checked other popular mail clients like thunderbird/mutt/etc?Thunderbird's enigmail plugin has a user preference (in the "advanced" pane of the expert preferences dialog, in the config editor as extensions.enigmail.hushMailSupport) that says "Use '<' and '>' to specify email addresses". The help text also mentions "disable if recipients have old hushmail keys" -- this defaults to being checked (the config option is "false" when the checkbox is checked, confusingly). So by default enigmail is "fixing" things in the same way as the proposed evolution fix, if i understand the bug report correctly.
Yah, enigmail is surprisingly decent.
However, enigmail also has an option (under the "sending" pane of the hexpert preferences dialog, in the config editor as extensions.enigmail.alwaysTrustSend) which says "Always trust people's keys", with the help text of "Do not use the Web of Trust to determine the validaty of keys". this defaults to "true" (checked), which means that enigmail will happily send mail to a key that gpg does not believe belongs to the recipient address (i just tested this; it looks like with the default settings, enigmail will encrypt to the first key returned by gpg that has the given user ID, even if a later matching key has a higher validity).
from enigmail's perspective why is that key present at all, so I can see defaulting to trusting it, basically the policy sounds like "if the user bothers to grab a key lets use it" which is probably not the safest implicit policy, but does get things working.
This is a separate issue from the User ID matching issue originally raised in this thread though. --dkg
- -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQIcBAEBAgAGBQJR8XpWAAoJEBYNRVNeJnmTDFkQANZnkX7p9qhGjQammJYHRgHa /EgVMOvahJLTQSquB5oKfmOwOop44ICElTAyq+d7MIJKdPElC18i7ZZeQu4eFitk Y7CohxLr+yHxtPMdGlFZSW5xLjEIsK8pXtAVCRhi+VyImptj98SikklwHaEpjUoo tmttKKjEkfpHHZClTKphQ+sCGxMcNKSsu/uVh5ARvwaZ5vpv/OreT+dLJRIHxe13 i2IqHePnTYFB6O7aXxNqEL12UW7IA95k7OHJfosVQtunRBJfdyX2w+9WRA/0JZ1o y+h+eG4wgfgiSnNDAer3RpfVdApRCbXdJVIZ15J1c+TVsHZKS5rsz4PL5r3jmt8t 06dpgtyVd0aTqoj4Nq9tv2hFel5AyuI0veKN8IkFtM+BJhC6sZ5sMCgMmS12c6EZ SBQVathsDKXm/k0eXQQLqKdRFxQgpy/VfJeqt3RY0W98bRNjPWKP+fjSu+Y1Em5E wiRleThYO3cy77zS48Py0XDewEONB3iZLhbdXVqawvwOkfvXGKehKFdOmWH1sgcL X+H5fZ6BVxfQw7S8Nypg+TXryEQvpCacQFQhXk2fbGjbhSJOcYeIPyGmGtdH00p8 h6Ta8GDG1XGy1PwNXWNXWmPOZB7wpZEdJJNRKB2y+s9Ygu1gFDbIQeXVEkZ6uzeD GlONfZHgVbYNTVTDDrQR =Yfio -----END PGP SIGNATURE-----
Current thread:
- CVE Request: evolution mail client GPG key selection issue Yves-Alexis Perez (Jul 21)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Yves-Alexis Perez (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Daniel Kahn Gillmor (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Daniel Kahn Gillmor (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Daniel Kahn Gillmor (Jul 25)
- Re: CVE Request: evolution mail client GPG key selection issue Kurt Seifried (Jul 25)