Date: Fri, 10 Oct 2014 18:27:31 +0200 From: Kristian Fiskerstrand <kristian.fiskerstrand@...ptuouscapital.com> To: David Leon Gil <coruus@...il.com>, Daniel Kahn Gillmor <dkg@...thhorseman.net> CC: oss-security@...ts.openwall.com, "gnupg-devel@...pg.org" <gnupg-devel@...pg.org>, Werner Koch <wk@...pg.org>, thijs@...ian.org Subject: Re: 0xdeadbeef comes of age: making keysteak with GnuPG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/10/2014 06:01 PM, David Leon Gil wrote: > On Fri, Oct 10, 2014 at 11:47 AM, Daniel Kahn Gillmor > <dkg@...thhorseman.net> wrote: >> If we're going to advocate for accessing keyservers via https >> (which i think is a lovely idea, even if it doesn't mitigate all >> possible attacks), it's worth advocating for the well-curated >> hkps.pool.sks-keyservers.net , rather than encouraging >> everyone to flood either https://keybase.io or >> https://pgp.mit.edu with traffic. > > My problem with the HKPS pool is that I don't know Kristian. And > I don't have any reason to believe that he'd suffer serious > financial damage if the private key for the "sks-keyservers.net CA" > got used maliciously. You are quite correct that I probably wouldn't, and my primary income is from another industry, but at the same time that does bring a protection as I wouldn't be discouraged to fight any oppression. Of course, you can't know my motives and integrity, which is a very fair argument. > > (While I know that if a root CA were caught intentionally issuing > an MitM cert for keybase.io or pgp.mit.edu would face likely > delisting/bankruptcy.) The cases we've seen where this happens (turktrust, diginotar) doesn't really speak to a large financial hit either. Although for the root CAs the major problem is simply the amount of CAs accepted by standard implementations, several of which are run by various governments. In the end it comes down to what the threat model is and whom you're protecting yourself from. Currently the only criteria for whether someone gets a certificate for a server in the pool is based on technical merits and that they are in control of the server in question. If no such agency were to run a perfectly valid keyserver under a pseudonym it would not be part of the current model to exclude this keyserver. However the goal is primarily to avoid information leakage on transport, in particular during a refresh of the keyring. I certainly wouldn't mind coming to the point to have verified each keyserver operator's identity before issuing a certificate, but we're not there yet. This might change over time as things mature, but that is the status today. > > I'd be really happy if Kristian published a GPG-signed log of > every valid certificate for servers in the HKPS pool; then it would > be possible for the distrustful -- or targeted -- to, say, query > multiple HKPS keyservers. This is even better than trusting Root > CAs + Kristian.) This is certainly something I can consider if there is a wish for it in the community. But mainly you will see the servers included with a HKPS flag in the status page of the pool as I wouldn't sign a server not included here. You'll run into a catch-22 here as well, as you'd (i) need to have a valid OpenPGP trust path (ii) trust that the information I provide in that log is accurate. As I use sequential serial-numbers, the latter should be possible, but in theory I could generate an out-of-scope certificate and choose not to include it in that log. So the question boils down to trust in the first place. For better or for worse. > >  Most hkps.pool.sks-keyservers.net don't have an alternative > trust path to a standard root CA. Is this really something we wish to have, given the lack of credibility of the global PKIX model? It is also one of the purposes of the more user-controlled web of trust possibilities (both due to everyone being their own CA, or through explicitly granting others this trust) of OpenPGP that we're tryign to operate in. So personally I'm more focused on the possibility to verify operators and indeed the CA through this protocol. That said I'm making an effort to create better trust paths to my own OpenPGP key that signs the X.509 CA key in the first place. > >  This is different from saying that I think he *would > intentionally* sign a malicious cert, which I don't. I just have > no idea how secure the private key for that CA is. And I know that > a fully isolated, physically secure facility, and a good HSM are > really expensive. (But maybe he is doing this?) Sorry, but no, I don't keep it in a physical facility, it is on an older laptop used for such operations. Hardware modules I don't necessarily believe to be any better for security as verifying the firmware brings its own set of problems, but that is a discussion out of scope for this thread. > >  If this is already available somewhere, apologies; I haven't > managed to find anything like it. > References:  https://sks-keyservers.net/status/ - -- - ---------------------------- 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 - ---------------------------- "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUOAjsAAoJEPw7F94F4TagRtMQAK00DJRqXRpXum3Cz1Uv+TVX W72mZWheeek8nW6B66dMSPi46FetpXn8h80gs2YGvke7OeauDnmpxz74AmeghiZS H0dhCutVl7m7PH7d0DPrgczBifHgj9+9kJFS+/RJh/BH0ptCkUg7aG/97HSPLDnJ 4pqPHanp8glyciobJn+Oo1FNVD0JmcqGB1TLA74g7EruGcwshZYF8dlW0ZjJGWj4 f4Zo6sG5jTc3Hr0lpYeFcCZd/zCFMfgiJpBdr0QD8Ux6iljvDv5uKAf9NSiXOfbm JePd/Psbix8x9qe67rTP8+5uBJQHeH3pTbGHSAfGmM+rHglz5Q27Dkk241r2xRU/ VOgsPwHAvPuLyz3JWoP+6oGQbtmmpuze1XI6nplJ+tO/2bBvcWRTDV/S6SlBEUA5 n9TwwNqaGLO/RUfwnpQZGN/WwLfyb5lZ9GdxGtlppdnV1vj3J5OxhDmup3bDXrYg ThrZza7xz8mvgwex8IoPsl8gGiiHETlahBHexSiyYGcKrEeA8XZrP3+RlRfogr7g jvAzCqbAv21r5GRMUznjoQ2Fl8eDJ5TIzSO9YVZ+oY2/RomZXl9C/2B5akEYBw/U 6yJkSMfBsphfV3CC/NrvB90BDR62MDbJPjQJ3af6uV4icSoseuwrVKNbYUQsgx5a FQj/hCmmCeGrTF2/d0T2 =vy6k -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.