Re: [Sks-devel] "quality" of keyservers offering hkps

[Phil Pennock]

-----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 <address@hidden> 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-----