Date: Sat, 9 Dec 2017 23:15:30 -0500 From: Phil Pennock <oss-security-phil@...dhuis.org> To: oss-security@...ts.openwall.com Subject: Re: Recommendations GnuPG-2 replacement On 2017-12-08 at 00:51 +0100, Marcus Brinkmann wrote: > because I am not registering the root certificate of the keyserver CA - > yes, openpgp keyservers have their own self-signed root CA). Look at the security and threat models and if you have a suggestion for something better, please make it. (So that you know I'm not a random crank: I wrote the operational guide for the SKS keyservers and have done a lot of work on the community side towards improving interop and helping move things forward. I'm at least a semi-informed crank.) The keyservers are run by various people with no formal affiliation, as a public good by each person choosing to cooperate. There is no shared organization, no formal responsibility. There are "pool" hostnames, which are maintained by spidering the peering mesh on the "list of peers" info page, and working under a common hostname. <https://sks-keyservers.net/overview-of-pools.php> has more information. So for hkps, we need "several" different people to all have certificates for the _same_ hostname. This is all directly opposite to the security model of the TTP PKIX. If we could get certificates from a browser-store CA, I'd tell you to stop trusting that CA because their processes are clearly broken. Thus Kristian runs a tiny CA and issues certs to those people who've been part of the community and ask to set things up, having demonstrated a working keyserver setup. What does TLS buy you? Protection against evesdropping. But you don't know who you're talking to in the first place, so that's not really that much. Protection against tampering, but the same applies. It's worth repeating: if the Acronym Agencies of various countries aren't sponsoring arms-length keyservers where they get all the traffic logs for some percentage of keyserver traffic, then they're incompetent. If they provide a useful public service and folks choose to use it, then they get the normal operator logs, because they're the operators. All legal. You don't know who is running the keyservers. You don't know what's happening to the logs. You don't know that the keyservers are trustworthy. They are, at most, a useful swamp for collecting the data from so that clients can do WoT calculations without caring about fishing in a contaminated swamp, as the WoT _if done right_ takes care of filtering out the sludge. If you care about privacy in who you talk with, get the keys from some other path, or run a keyserver, and use hkps with a certificate under your control. For myself, I need to look into building modern OCaml because FreeBSD are still shipping a version with known integer overflow vulnerabilities and so my SKS install is shut down. It's somewhere on my long todo list. My server has hkps for the public pool, and a Let's Encrypt cert under its own hostname. It meets my needs, when I'm running it. But the viability of the public keyservers is well past any reasonable expectation of their lifespan. We've had the EFF sponsoring spamming tools; we've had keyservers in Europe shut down because of privacy demands because an append-only mesh-fill datastore can't remove keys and people send out their email address and name paired into a key and then get upset because it's out there; we're one illicit-material-in-photo-uid incident away from global shutdown. Don't rely on the public keyservers and please don't complain if their security model, such as it is, requires a custom CA to be able to operate with what minimal veneer of security TLS might provide. -Phil, speaking only for myself
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ