Adding support for fetching GPG key using WKD protocol

Wiktor Kwapisiewicz wiktor at metacode.biz
Sat Jul 7 06:18:01 UTC 2018


Hi, Derek,

> Another way to look at this:  Mutt likes to relegate tasks to an
> application which is designated for that task.  In this case, gnupg
> (or whatever) is the application relegated to managing PGP keys.  As
> such the user should configure THAT application, to the extent
> possible, to do what they want with keys, and Mutt should ignore the
> problem.

Yes, I like that approach. But consider that I can send encrypted 
message with key retrieval from command line: (as WKD is enabled by 
default since GnuPG 2.1 and kernel.org uses WKD):

echo "message" | gpg -ear torvalds at kernel.org  | mail -s "Subject" 
torvalds at kernel.org

But I cannot do so from Mutt (an e-mail client)! That's because Mutt 
requires keyID... if it only passed the e-mail verbatim to gpg, gpg 
would do what gpg does and retrieve the key.

> That's a big part of the danger here...  You could retrieve a key that
> you think is for someone you know, when the request has actually been
> intercepted by, say, someone operating part of AT&T's backbone, and
> served a key of the attacker's making.*I*  would not fall into such a
> trap, because I will not rely on the privacy of encryption to such a
> key until I have personally verified it, and it seems as though you
> would not fall into it either, based on at least web of trust...  But
> I'm extremely confident that a percentage of users would be fooled by
> such an attack, and may in the process give away the keys to the
> store, so to speak.

WKD is done only through HTTPS, that eliminates a lot of attack vectors 
and is more secure than just looking at matching keys on the keyservers.

> However the mere revelation of who is receiving my messages can be
> just as dangerous, depending on the type of correspondence I'm having.
> For example, if I were a political refugee trying to secure my safe
> passage to a different locale with a more friendly regieme, the
> unexpected automatic key retrieval, intercepted by the people I were
> running from, could be enough for them to find me and kill me.  This
> is an extreme example, but this is one of the things which might
> genuinely justify the use of encryption.

Encryption can be used for variety of purposes. I'm thinking of stopping 
passive surveillance, that is a fact, by having keys be easier and more 
secure to discover.

Your hypothetical political refugee, if they wanted to be most secure, 
would post --throw-keyids encrypted messages, without Version and 
Comment headers [0] to alt.anonymous.messages through several remailers 
and over Tor. They also would use stronger keys than 1024 DSA/RSA [1]. 
I guess this is not your usual mutt user?

WKD actually makes it easier to do the thing properly as it retrieves 
the key only over secure HTTPS connection and only from one place.

Contrast this with keyservers that can be accessed using unencrypted 
HTTP and everyone can add a key with any name and e-mail. (everyone can 
also add any UID to *your* key [2], fake-revoke it, and they can also 
render any key unusable [3]).

Kind regards,
Wiktor

[0]: 
https://www.csoonline.com/article/2904395/microsoft-subnet/mistakes-that-betrayed-anonymity-of-former-dea-agent-and-silk-road-investigator.html

[1]: https://knowledge.digicert.com/generalinformation/INFO1684.html

[2]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/41

[3]: https://bitbucket.org/skskeyserver/sks-keyserver/issues/60

-- 
https://metacode.biz/@wiktor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180707/e6e69eb0/attachment-0001.asc>


More information about the Mutt-dev mailing list