[PATCH] ship sks-keyservers.netCA.pem in distributed tarball

[Christoph Anton Mitterer]

On Wed, 2015-12-09 at 15:24 -0500, Daniel Kahn Gillmor wrote:
> On Sat 2015-10-24 17:57:39 -0400, Werner Koch wrote:
> > On Fri, 23 Oct 2015 23:45, dkg at fifthhorseman.net said:
> > > Any followup on this?  is there a reason we shouldn't ship
> > > Kristian's
> > > cert as part of the source tarball?
> > 
> > Sure, we will do this.
> 
> This is still not done in 2.1.10, afaict.  Should i open a ticket at
> https://bugs.gnupg.org with the patch that started this original
> thread?
> 
> what's the best way for me to follow up on things like this? i don't
> want to feel like i'm nagging!

btw:

I still don't see how hkps adds any real security or trust... or
privacy - at least not as a single measurement.

The first problem is that there is too much power in one person (the
CA's root), and while I have no reason to distrust Kristian (and I hope
he doesn't take this personal in anyway)... it's still a conceptual
problem that we shouldn't introduce in GPG, at least not, if that means
we don't do any further/real measurements to improve keyserver network
security.
The next problem would be, that *anyone* gets certificates from
Kristian, without any real validation (at least nothing that would be
more than sending it to the email address the keyserver would announce
as it's operator - which is of course however nothing that Kristian
could know for sure, as it's not secured).

As I've said previously at several occasions, the best the clients
could IMHO do to improve the security of their interaction with the
keyserver network is the following:
- send any key submissions to *many* keyservers (ideally of course to
as many as possible)
- send any search requests to *many* keyservers (ideally of course to
as many as possible), match their results (and warn if there are too
many differences) and merge their results (i.e. if one keyserver would
e.g. include a revoc cert or other signatures, that another (possibly
evil) keyserver would have stripped off).
- For privacy concerns, Tor is the solution (speaking of gpg as tor
client)[1]

- Another, effective way would be, that gnupg.org operates a keyserver
itself and that this one is *always* included in the above mentioned
set of keyservers used for multi-submissions/requests.
The idea is simply: If one trusts GnuPG (i.e. the software) we can also
trust their server.. and if a powerful attacker would manage to force
Werner&Co. to manipulate their keyserver (by law or whatever), the
would possibly also manage to force them to introduce some very subtle
hidden security hole.

And again, this doesn't mean that I wouldn't see any value in
Kristian's work (actually I appreciate it, and my own keyserver also
has one of his certs in place),... but as the only measurement to
improve keyserver security, I don't think it's (effective) enough, and
rather may give a wrong sense of security.


Cheers,
Chris.


[1] There was that discussion recently on sks-devel about keyservers as
hidden tor services. I still largely remain on my PoV that there is no
real security benefit of that, except for the case, that there would be
hidden-Tor-services-only keyservers, whose operators remain fully
anonymous (in their communication with e.g. sks-devel) and which
operate *no* normal (i.e. non hidden-Tor-service) keyserver.
Cause, the only real security benefit that I've been convinced of is,
that by that way, we could hide some keyservers (and their key DBs)
from possibly evil powers (NSA and friends), which may force the
operators to manipulate the DB.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: </pipermail/attachments/20151209/e16aa309/attachment.bin>