-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-08-14 at 13:30 +0200, Matthias Schreiber wrote: > On 14. August 2014 05:31:40 MESZ, Phil Pennock <[email protected]> > wrote: > > > >What is the threat model which you are trying to protect against? > > As the public keys themselves are of cause nothing which needs to be secured, > I see these two possible aspects: > > - meta data like 'who up-/downloaded which keys' could be revealed > - mitm attacks may manipulate up-/downloaded keys > > Or am I thinking in the wrong direction?
No, but it's important to understand something about keyservers. The data which they hold is unauthenticated, and anyone can run a keyserver. For context before I continue: I run an HKPS keyserver, was one of the first to do so, and have worked with Kristian on the setup and with the GnuPG developers on establishing which identity should be verified. So I support HKPS as a feature and I _cautiously_ support it for a public pool, but I worry about the false sense of security it engenders. If an acronym agency is not running a public keyserver, under an innocuous name, then they're slipping. It's the easiest way to automatically get a feed of every PGP public key created and uploaded for general use. Great ingress, can check for names and pseudonyms immediately and schedule some keys for priority factoring. If an acronym agency is not running a set of public keyservers, logging all client queries, to get a statistical sample of communicant flows, then they're slipping. Kristian is not in a position to filter the keyservers in his pool by the affiliation, public or hidden, of the keyserver operators. Selection is entirely based on technical merit, as assessed by a few simple heuristics. It is likely that at _least_ one of the currently participating members works for an acronym agency. Frankly, while it would be nice if no keyserver operators did so, if you have no connection or affiliation with the operator of the keyserver you use, then it's naive to _demand_ that the operators conform to your desired profiles and requirements. Thus, if you run an organisation where you care about traffic analysis and communicant pairing, then you should run your own PGP keyserver and get people in your organisation to exclusively use that keyserver. If you have the resources to run a keyserver, bias towards only using your own. The _default_ keyservers are a selection of publicly available keyservers where *NO* warranties are made about who is running them. So, to your two points, let's first look at "when using the general pool" and then "when using a particular keyserver" * meta data revelation: far easier to perform, and harder to detect, to just run an SKS keyserver publicly, under a pseudonym used by an agency employee. Run up HTTPS with a high quality cert, make sure you pass every quality assessment for the cert and HTTPS TLS negotiation. Provide a great service. Locks out analysis by people at other (foreign, or just competing) agency and still gives you full logs. MITM is usually detectable, even if just after the fact (oops, where did that BGP announcement come from?). Running quality servers which people appreciate, and _choose_ to use, is absolutely legal, requires no wiretapping, no warrants, and lets you keep the "usual, routine" logs. Everything is above board, legally, in just about every jurisdiction. It's a no-brainer. * MITM attacks: similarly, no need, just write logic into the keyserver, or between the front-end proxy and the server, to filter results for keys of interest. Do it behind the HTTPS, so that you don't need to tamper with the quality and are not detectable, and do it on your own systems, when queried, so that no laws are broken and no warrants required. So, for the general pool, I think revisiting the threat model may be of use. Having HKPS available, and of good quality, is useful for those of us who do not work for an acronym agency, to help protect end-users against attack when their client resolves to one of our servers. It keeps us from becoming complicit. It increases the chances of tampering becoming evident. It's chicken soup for the soul. It's good to have this, for the pool, to increase the difficulty of attack against queries going to non-agency servers. But for the end-user, using HKPS with the public pools is like playing Russian Roulette: sooner or later, the chamber is loaded with a bullet and you lose. HKPS available and verifiable protects against regimes outside of the nation where the keyserver is (and their spying allegiance nations). So for folks going into the Middle East, using a keyserver pool constrained to the USA is probably a good call, as long as you also use a validating DNS resolver (with a trusted root key set), so that DNS attacks can't redirect you to a member of another pool in a nation friendly to the local regime of concern. Kristian has set up sks-keyservers.net to be DNSSEC-signed, so you _can_ reliably choose a pool in a given region. (Of course, there aren't yet geographic pools of HKPS servers, but as the volume of servers grows, this might be more reasonable and might come? Kristian?) Separately, there's the HKPS issue "when using a particular keyserver". In this case, if you trust the keyserver operator, then quality HKPS is absolutely a good thing. Community tools which provide summaries of analysis might be a good thing, to help people find out. But if we're doing this for anything more than nudging keyserver operators to provide (at their own expense!) a better service for the general public, then these analyses would need to be paired with short biographies of the keyserver operators and their statements of who they are and why they run a public keyserver, together with disclaimers that none of the claims are validated and it's up to each person to make their own decisions. Thus, I welcome attempts to analyse the security available via HKPS against the public pool and make this data available, but I will push back against us making falsely reassuring statements which might mislead the public about the protection this provides. Regards, - -Phil; not an agency employee, not working for any government agency or a company contracting to such agencies, but was once accused of working for AIVD by contractors who couldn't understand why our ISP wouldn't leave them alone, unescorted, in our machine room. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJT7QVqAAoJEKBsj+IM0duFr/8IAJc3R0cO1JINXlQ7tJ68zMdm 8PIn5Ilba4wYBEcbR2MLFxGS3nVHKO//6SNN7o4j3gzGUm2nzVwi8/kKsBMmsztN w52Lkygb8hZtGkQnXfHzFDAxZry+qlMBXzJ/k6q6QWfdhwbz80bH3JvFw1vAVuv9 8z2SjzASiR7TjW6n7vxJrJXpW5ZZyQGKwbyuvHFiHPO3GOd6oj84N6QP1b42r+Ds fWtfT11PujoTo5lBXDLPOjMfOa2oBIQU7Os2Gh6Zf+eW7VPFeI9p3Ihnxj+MUUcN cH3Eo4eBukbqmBUSF42hV+EGu65jjRmIwzOkGB3batKQFfc4PKzOVoUKBtuCMuM= =THqZ -----END PGP SIGNATURE----- _______________________________________________ Sks-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/sks-devel
