Checking key server response against the request parameters

[Nicholas Cole]

On Wed, Sep 18, 2013 at 2:53 PM, Stefan Tomanek
<tomanek at internet-sicherheit.de> wrote:
> Dies schrieb Stefan Tomanek (tomanek at internet-sicherheit.de):
>
>> And it looks like you are working under the assumption that a) the keyserver is
>> playing nice with you and b) you are actually talking to the keyserver you
>> specified. Both assumptions are completely bogus, considering that is trivial
>> to mount an man-in-the-middle attack against keyserver traffic.
>
> After investigating the issue further, even more attack scenarios come to mind.
>
> Consider this:
>
> John H. Newuser installs gnupg and enigmail.
>
> He fetches the public keys from his coworkers (to verify their signatures),
> using the keyserver.
>
> He then generates a key pair for himself and transmits confidential material
> to someone, of course checking the fingerprint of the recipient's key first.
>
> Well, at this point, he might have already run into trouble without even
> noticing. At every key server action, it is possible for the server (or anyone
> in the middle) to poison his keyring.
>
> In this scenario, the malign keyserver sent an additional key with its replies,
> matching the User ID of our victim. GnuPG will in fact add this key to the
> keyring, disregarding the fact that the user has never asked for it.
>
> The fun fact: The secret key remains in control of the attacker, while enigmail
> (and many other MUAs as well) encrypts every mail using the injected public key
> (encrypt-to-self), since gnupg will search in a linear fashion through the
> pubring for matching keys.
>
> I guess that this scenario can be mitigated in many ways, but in my opinion
> gnupg should never add keys to my secring/pubring without me explicitly asking
> for it.


Stefan,

I've been following the other patches - but I don't quite follow this
last scenario at all.  The whole point of keyservers is that they
don't have to be trusted. Malicious users can (and have) upload fake
keys all the time.  As long as users check fingerprints and assign
introducer trust with care, there is no problem.  If I search for John
H. Newuser's key and get back 1 real and 2 fake ones, the only harm
that is done is if I fail to check the fingerprints before signing the
correct one, and my HD has a couple of extra keys on it that I
probably ought to delete, but which will do no harm, unless I adopt
the "always trust" trust model and then fail to do any external
checking.

N.