GnuPG defaults: changing back to --no-auto-key-retrieve

[Daniel Kahn Gillmor]

hey folks--

Werner and i spoke yesterday about the choice of defaults for
auto-key-retrieve and auto-key-locate, which were updated in 2.1.23.

Summary
-------

GnuPG will revert the default of -retrieve for now so that the default
is --no-auto-key-retrieve.  The default for --auto-key-locate will
remain as local,wkd.

I pushed this change to upstream in commit
https://dev.gnupg.org/rGe6f84116abca2ed49bf14b2e28c3c811a3717227, and it
will be in the next released version.  I also just pushed 2.1.23-1 to
debian unstable, with a patch that includes this change.

What follows is my own notes from the discussion, i hope Werner will
chime in if his recollection is different.


--auto-key-retrieve vs. --auto-key-locate
-----------------------------------------

i hadn't fully understood this bit, hopefully it helps others:

   --auto-key-retrieve (henceforth "AKR" here) governs whether or not to
     retrieve unknown keys during signature verification.  It does
     lookups by long key ID or by full fingerprint only.  It is a
     boolean flag (the "false" value is --no-auto-key-retrieve).

   --auto-key-locate ("AKL") governs the list of mechanisms used to find
     keys when the user wants to find them based on an e-mail address.
     It is a list of "locate" mechanisms, including among other things
     "local", "wkd", "keyserver", "ldap", etc.  This happens only when
     encrypting messages.


So, AKR is for signature verification, and AKL is for encryption.

Trouble with --auto-key-retrieve
--------------------------------

During signature verification in an e-mail context, AKR is likely to
present a mechanism for "web bug" or "return reciept" functionality,
something most MUA developers are (justifiably) wary of.  This could
potentially happen even without the user's knowledge (e.g. if a MUA
tried to check signatures on mail as it was retrieved from the
mailserver, before the user sees it)

During signature verification in non-email contexts, AKR presents even
more troubling implications.  Consider a software distribution mechanism
that uses a curated keyring to indicate which keys' signatures are
acceptable.  If a malicious party managed to place their own signature
on the update server, and the system used AKR, it might pollute the
curated keyring with the malicious party's key, leading to further
compromise in the future.

Because of these risks, we're moving the default back to
--no-auto-key-retrieve.

MUAs that want to provide the user with a smooth experience, where they
understand the consequences can of course use --auto-key-retrieve
explicitly for their own invocations, in situations where the user
expects network activity.  Frontends like enigmail and notmuch already
offer the user such an option when a signature from an unknown key is
found.

But --auto-key-retrieve was not a safe option for a toolkit like gpg to
have by default, so it has been reverted.

Note also that polite MUAs that want their messages to be
easily-verified can also just ensure that their user's OpenPGP
certificate is included with every signed message.  This introduces no
additional network side-channels, and has latency benefits as well
compared to the post-hoc network lookup.


Why --auto-key-locate is different
----------------------------------

We left AKL alone, with the new default of local,wkd.  This situation is
different, because it is the user explicitly invoking GnuPG, asking for
encryption to an e-mail address.  If the user's local keyring doesn't
have the key, it's sensible to try to fetch a key for the user if
there's a way that we think is better-than-cleartext.

wkd is the only non-local option automatically enabled.

Note that if the user does not try to encrypt a message, then this
lookup won't happen, because gnupg should not be invoked anyway.  So
the network activity is only happening as a consequence of user
activity, and only when no local key is already present.

Sensible MUAs should probably indicate to the user whether a local key
is present for each user anyway while the message is composed, before it
is encrypted and sent.  So when the user has elected to send an
encrypted message, they should already have some indication of whether a
key lookup will be necessary or not.

And of course, users who prefer to have their encryption fail when there
is no local key rather than making an extra network lookup can always
set --no-auto-key-locate.




Hopefully these explanations are useful.  If you see concerns with the
reasoning or explanations, or (even better) if you havesuggestions for
further improvements, please don't hesitate.

happy hacking,


     --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170811/2a284a97/attachment.sig>