Adding support for fetching GPG key using WKD protocol

[Wiktor Kwapisiewicz]

Hello mutt-dev,

I would like to extend mutt to add fetching GPG keys over Web Key
Directory protocol.

(I've previously created an issue on gitlab [0] but I'll summarize the
thing here for the broader audience).

Web Key Directory is a new scheme for GPG key discovery. It converts the
e-mail address to HTTPS URL and fetches the key from there. It is
already supported by some e-mail clients (EnigMail, GpgOL).

For example kernel.org has it enabled and Linus' key is at:
https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x

As GnuPG 2 has it enabled by default "gpg --locate-key
***@kernel.org" will fetch that key.

I've been exploring mutt's source code and the change would mostly be
enabling external lookup for keys that are not locally present [1] when
encryption is explicitly turned on (gpgme backend).

That raises some privacy issues, the same was discussed on gnupg-devel
ML [2] (gpg by default will fetch the key via WKD when encrypting to a
recipient but will *not* fetch the key when verifying signatures).

The question is how to do it well. Maybe ask the user if they want to
search for the key using WKD if it's not locally present?

An option would be the first choice but I worry about it not being used
at all (as people rarely enable non-standard features [3]).

Thank you for your consideration!

Kind regards,
Wiktor

[0]: https://gitlab.com/muttmua/mutt/issues/55

[1]: gpgme_set_keylist_mode(ctx,
GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_EXTERN); in
crypto-gpgme.c#get_candidates.

[2]: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html

[3]: https://gitlab.com/muttmua/mutt/issues/3

[Kevin J. McCarthy]

I would like to extend mutt to add fetching GPG keys over Web Key Directory
protocol.

I asked Wiktor to post here, in order to give a broader audience the
opportunity to discuss how/if this should be implemented.

My initial idea was a quadoption to control the external query to WKD.
If no exact-address matches are initially found, consult the quadoption
(which will prompt the user if set to ask-yes or ask-no). If yes, then:
* For gpgme, requery with the GPGME_KEYLIST_MODE_EXTERN enabled.
* For classic-pgp, first perform a "gpg --locate-key", and then requery.

There is an existing $pgp_getkeys_command config variable, that supports
some kinds of pre-fetching. contrib/gpg.rc doesn't specify a value, and
I wonder if this could be repurposed?

I'd appreciate any and all input.

Thanks!

[Andras Salamon]

Post by Kevin J. McCarthy
My initial idea was a quadoption to control the external query to WKD.
If no exact-address matches are initially found, consult the quadoption

Does this mean that WKD would always be enabled?

If so, this potentially leaks from whom email is being received to third
parties, and I will patch my copy of mutt to remove it.

I suggest an option that initially has the default to not perform WKD.

-- Andras Salamon ***@dns.net

[Wiktor Kwapisiewicz]

Post by Andras Salamon
Does this mean that WKD would always be enabled?
If so, this potentially leaks from whom email is being received to third
parties, and I will patch my copy of mutt to remove it.

It is triggered only when you want to send an e-mail *to* a person AND
explicitly enable encryption AND you don't have their key locally. Then
it queries that person's HTTPS server.

It is not triggered when receiving e-mails.

Kind regards,
Wiktor

[Derek Martin]

Post by Wiktor Kwapisiewicz

Post by Andras Salamon
Does this mean that WKD would always be enabled?
If so, this potentially leaks from whom email is being received to third
parties, and I will patch my copy of mutt to remove it.

It is triggered only when you want to send an e-mail *to* a person
AND explicitly enable encryption AND you don't have their key
locally. Then it queries that person's HTTPS server.

So... This isn't really too different. If the config option somehow
got set unintentionally, it still potentially leaks information, even
if it is on send rather than on receipt. It's actually worse, because
it leaks whom you are actually sending messages to, rather than from
whom you're receiving them... Received messages could be spam or
other senders you simply don't know. Sending messages is a concious
choice, so it reveals something material.

People frequently copy mutt configs from the internet without really
knowing what everything in them does. It's also possible that a
developer, say someone who was experimenting with various options,
could inadvertently set the option to yes before doing a checkin, and
nobody immediately notices...

[Vincent Lefevre]

Post by Derek Martin

Post by Wiktor Kwapisiewicz

Post by Andras Salamon
Does this mean that WKD would always be enabled?
If so, this potentially leaks from whom email is being received to third
parties, and I will patch my copy of mutt to remove it.

It is triggered only when you want to send an e-mail *to* a person
AND explicitly enable encryption AND you don't have their key
locally. Then it queries that person's HTTPS server.

So... This isn't really too different. If the config option somehow
got set unintentionally, it still potentially leaks information, even
if it is on send rather than on receipt. It's actually worse, because
it leaks whom you are actually sending messages to, rather than from
whom you're receiving them... Received messages could be spam or
other senders you simply don't know. Sending messages is a concious
choice, so it reveals something material.

So, perhaps if the WKD protocol were *also* used for received messages,
this would be less problematic.

[Wiktor Kwapisiewicz]

Hi Vincent,

Post by Vincent Lefevre

Post by Derek Martin
So... This isn't really too different. If the config option somehow
got set unintentionally, it still potentially leaks information, even
if it is on send rather than on receipt. It's actually worse, because
it leaks whom you are actually sending messages to, rather than from
whom you're receiving them... Received messages could be spam or
other senders you simply don't know. Sending messages is a concious
choice, so it reveals something material.

So, perhaps if the WKD protocol were *also* used for received messages,
this would be less problematic.

I think WKD can already be used in mutt for received messages, without
any modifications to mutt but given three conditions are satisfied:
* auto-key-locate in gpg.conf includes "wkd" (by default it's
"local,wkd" so that's OK),
* auto-key-retrieve is set (that enables automatic verification of
signatures, by default it is *not* enabled, for example Fabian Groffen
said he has it enabled),
* the *sender* of the message creates signature by specifying their
e-mail not keyid, this is rather elaborate edge case but "gpg -u
***@example.com --sign" adds user's e-mail to the signature (thus
enabling WKD lookup on signatures) but "gpg -u 0x123123 --sign" does
*not*. I don't know what mutt does at this point.

From other news I got the info from gnupg-devel mailing list from Andre

Post by Vincent Lefevre
You do it right. GPGME_KEYLIST_MODE_LOCATE (or an or of local and extern) uses
what is configured in auto-key-locate options.

[0]: https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033831.html

So setting LOCAL|EXTERN does *not* mean it will do network lookup it
means it *can* do network lookup if this is configured in gpg.conf
(option "auto-key-locate"). I've tested this on my sample program and
sure enough, setting "auto-key-locate" to "local" in gpg.conf does *not*
make network lookups even with LOCAL|EXTERN (a.k.a. LOCATE) in mutt.

LOCAL, that is used by GPGME by default, and currently by mutt, does not
consult user configuration in "auto-key-locate".

Kind regards,
Wiktor

[Kevin J. McCarthy]

Post by Andras Salamon

Post by Kevin J. McCarthy
My initial idea was a quadoption to control the external query to WKD.
If no exact-address matches are initially found, consult the quadoption

Does this mean that WKD would always be enabled?

The quadoption would allow the user to set to automatic (yes), prompt
(ask-yes/ask-no), or disable (no). I'd like feedback from everyone, but
I am disinclined to default-enable something that send http requests
out without the user fully understanding what's going on.

[Wiktor Kwapisiewicz]

Post by Kevin J. McCarthy

Post by Andras Salamon
Does this mean that WKD would always be enabled?

The quadoption would allow the user to set to automatic (yes), prompt
(ask-yes/ask-no), or disable (no). I'd like feedback from everyone, but
I am disinclined to default-enable something that send http requests
out without the user fully understanding what's going on.

Yes, I agree. I think it's safe to say that it will never be enabled by
default.

I'm thinking about how would get_candidates be modified.

Currently it's (pseudocode):

get_candidates() {
// searches only locally by default
keys = keylist_search();
return keys;
}

After the change it would be (assuming wkd_search would be the option):

get_candidates() {
if (wkd_search == "automatic") {
keylist_mode(LOCAL | EXTERNAL); // enables auto WKD
}
keys = keylist_search();
if (!keys) {
if (wkd_search == "ask") {
answer = ask("Key not found locally, do you want to search user's
domain for their key?")
if (answer == "yes") {
keylist_mode(LOCAL | EXTERNAL);
keys = keylist_search();
}
}
}
return keys;
}

The text to ask is up for discussion, I'm just asking if this general
flow of code sounds good.

Another question: what would be the default value for "wkd_search" -
"ask" or "no"?

Kind regards,
Wiktor

[Claus Assmann]

Post by Kevin J. McCarthy
I am disinclined to default-enable something that send http requests
out without the user fully understanding what's going on.

Agreed.

I would patch my copy of the source to not enable such code at all
-- IMHO it does not belong into the MUA but some "helper" program;
more complexity increases the likelihood of bugs.

[Fabian Groffen]

Hi,

Just wondering, I've got "auto-key-retrieve" set in my gpg.conf. I'm
using gpgme, and as far as I'm aware it fetches keys it doesn't know
upon reading the message (gives a little delay) to verify the signature
is OK.

Is this a different thing somehow?

Thanks,
Fabian

Post by Wiktor Kwapisiewicz
Hello mutt-dev,
I would like to extend mutt to add fetching GPG keys over Web Key
Directory protocol.
(I've previously created an issue on gitlab [0] but I'll summarize the
thing here for the broader audience).
Web Key Directory is a new scheme for GPG key discovery. It converts the
e-mail address to HTTPS URL and fetches the key from there. It is
already supported by some e-mail clients (EnigMail, GpgOL).
https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x
As GnuPG 2 has it enabled by default "gpg --locate-key
I've been exploring mutt's source code and the change would mostly be
enabling external lookup for keys that are not locally present [1] when
encryption is explicitly turned on (gpgme backend).
That raises some privacy issues, the same was discussed on gnupg-devel
ML [2] (gpg by default will fetch the key via WKD when encrypting to a
recipient but will *not* fetch the key when verifying signatures).
The question is how to do it well. Maybe ask the user if they want to
search for the key using WKD if it's not locally present?
An option would be the first choice but I worry about it not being used
at all (as people rarely enable non-standard features [3]).
Thank you for your consideration!
Kind regards,
Wiktor
[0]: https://gitlab.com/muttmua/mutt/issues/55
[1]: gpgme_set_keylist_mode(ctx,
GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_EXTERN); in
crypto-gpgme.c#get_candidates.
[2]: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html
[3]: https://gitlab.com/muttmua/mutt/issues/3
--

[Wiktor Kwapisiewicz]

Post by Fabian Groffen
Hi,
Just wondering, I've got "auto-key-retrieve" set in my gpg.conf. I'm
using gpgme, and as far as I'm aware it fetches keys it doesn't know
upon reading the message (gives a little delay) to verify the signature
is OK.
Is this a different thing somehow?

Yes, auto-key-retrieve is different from auto-key-locate.

Auto-key-retrieve is for signatures. It's a boolean flag that is
disabled by default (because signature verification usually happens
automatically when viewing signed content, and this could be used to
track when you view your e-mail in some clients).

Auto-key-locate is for encryption. It's a list of schemes tried in
succession and is triggered when using e.g. --locate-key (but also with
--encrypt --recipient $EMAIL). By default it's "local,wkd". The
reasoning is that if you explicitly want to send an e-mail to someone
and you don't have their key (local) you would want to fetch it from
their server (wkd). This is done only once (then the key is imported
into the keyring).

Actually auto-key-retrieve when enabled will use the list from
auto-key-locate.

This post by dkg goes into more details:
https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html

But I can answer specific questions if you have more.

Kind regards,
Wiktor

Post by Fabian Groffen
Thanks,
Fabian

Post by Wiktor Kwapisiewicz
Hello mutt-dev,
I would like to extend mutt to add fetching GPG keys over Web Key
Directory protocol.
(I've previously created an issue on gitlab [0] but I'll summarize the
thing here for the broader audience).
Web Key Directory is a new scheme for GPG key discovery. It converts the
e-mail address to HTTPS URL and fetches the key from there. It is
already supported by some e-mail clients (EnigMail, GpgOL).
https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x
As GnuPG 2 has it enabled by default "gpg --locate-key
I've been exploring mutt's source code and the change would mostly be
enabling external lookup for keys that are not locally present [1] when
encryption is explicitly turned on (gpgme backend).
That raises some privacy issues, the same was discussed on gnupg-devel
ML [2] (gpg by default will fetch the key via WKD when encrypting to a
recipient but will *not* fetch the key when verifying signatures).
The question is how to do it well. Maybe ask the user if they want to
search for the key using WKD if it's not locally present?
An option would be the first choice but I worry about it not being used
at all (as people rarely enable non-standard features [3]).
Thank you for your consideration!
Kind regards,
Wiktor
[0]: https://gitlab.com/muttmua/mutt/issues/55
[1]: gpgme_set_keylist_mode(ctx,
GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_EXTERN); in
crypto-gpgme.c#get_candidates.
[2]: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html
[3]: https://gitlab.com/muttmua/mutt/issues/3
--

[Derek Martin]

I'm not strongly opposed to this feature, but I am opposed to it
nonetheless, on much the same grounds as I am opposed to the "umask"
feature (which is a misnomer, but it's how people think of that) for
attachments. Convenience and security, unfortunately, are often
enemies, and I think this is another case of that. If this feature is
included, it is certain that many users will enable it for the sake of
convenience, but many of those users will not have a sufficiently
sophisticated understanding of the security risks associated with that
action, and will thus be incapable of making a truly informed
decision about whether those risks are worth the added convenience.
On that basis I think Mutt should force the user to explicitly decide
that they want to fetch a key, by doing so through the gnupg
interface.

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.

As a side note, I think automatic key retrieval of any sort largely
defeats the purpose of encryption. You have no idea if the key you've
downloaded actually belongs to the person you think it should belong
to, excepting the case where the key is just a refresh of a key you've
already manually verified (i.e. key is signed by a key you already
have verified, belonging to the same person). There are sometimes
other reasons, or other means by which to trust such keys (e.g. the
web of trust); but in the general case it is simply stupid to do so
without manually verifying the key and its owner's identity yourself.
You can consider that an additional argument to not support the
feature if you like.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.

Post by Wiktor Kwapisiewicz
Hello mutt-dev,
I would like to extend mutt to add fetching GPG keys over Web Key
Directory protocol.
(I've previously created an issue on gitlab [0] but I'll summarize
the thing here for the broader audience).
Web Key Directory is a new scheme for GPG key discovery. It converts
the e-mail address to HTTPS URL and fetches the key from there. It
is already supported by some e-mail clients (EnigMail, GpgOL).
For example kernel.org has it enabled and Linus' key is at: https://kernel.org/.well-known/openpgpkey/hu/pf113mfnx1f3eb1yiwhsipa91xfc7o4x
As GnuPG 2 has it enabled by default "gpg --locate-key
I've been exploring mutt's source code and the change would mostly
be enabling external lookup for keys that are not locally present
[1] when encryption is explicitly turned on (gpgme backend).
That raises some privacy issues, the same was discussed on
gnupg-devel ML [2] (gpg by default will fetch the key via WKD when
encrypting to a recipient but will *not* fetch the key when
verifying signatures).
The question is how to do it well. Maybe ask the user if they want
to search for the key using WKD if it's not locally present?
An option would be the first choice but I worry about it not being
used at all (as people rarely enable non-standard features [3]).
Thank you for your consideration!
Kind regards,
Wiktor
[0]: https://gitlab.com/muttmua/mutt/issues/55
[1]: gpgme_set_keylist_mode(ctx,
GPGME_KEYLIST_MODE_LOCAL|GPGME_KEYLIST_MODE_EXTERN); in
crypto-gpgme.c#get_candidates.
[2]: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033021.html
[3]: https://gitlab.com/muttmua/mutt/issues/3
--

[Wiktor Kwapisiewicz]

Hi Derek,

Thanks for your detailed e-mail! I will try to answer to points that
you've raised to the best of my knowledge.

Post by Derek Martin
On that basis I think Mutt should force the user to explicitly decide
that they want to fetch a key, by doing so through the gnupg
interface.

Is asking the user if they want to fetch the key interactively (if the
key is not found locally) not an explicit decision? Or do you mean that
the user should exit mutt and run gpg manually?

Post by Derek Martin
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 agree. The problem is that GPGME does not respect user
preferences w.r.t. key retrieval (stored in gpg.conf). I will ask on
gnupg-devel list if this is by design.

Post by Derek Martin
As a side note, I think automatic key retrieval of any sort largely
defeats the purpose of encryption. You have no idea if the key you've
downloaded actually belongs to the person you think it should belong
to, excepting the case where the key is just a refresh of a key you've
already manually verified (i.e. key is signed by a key you already
have verified, belonging to the same person). There are sometimes
other reasons, or other means by which to trust such keys (e.g. the
web of trust); but in the general case it is simply stupid to do so
without manually verifying the key and its owner's identity yourself.
You can consider that an additional argument to not support the
feature if you like.

Mutt already has appropriate messages relating to key validity
(crypt-gpgme.c:1330) for example "WARNING: We have NO indication whether
the key belongs to the person named as shown above" and key retrieval
doesn't change that.

But consider the situation, you have signed a key of person B and you
fully trust them, now you want to contact me and my key is signed with
person's B key. It doesn't matter how you retrieve my key, when you
import it it will be fully valid (as you trust person's B signatures).
What WKD changes is you'll get my key from my domain and you won't have
to search keyserver's for all potential keys looking for one that is
signed by one of your trusted contacts.

Another example (a little bit more contrived): I want to report broken
links on your home page :) (pizzashack.org)... confidentially. How would
I do that? I would obviously get your key from your page
(http://pizzashack.org/~ddm/pgp.key), WKD does just that, gets your key
from your site. It *does not* make it trusted, signed or anything else.
But I could at least send you the end-to-end encrypted message.

Actually that's how I got the idea of adding WKD to mutt: one person
couldn't reply to my PGP message with encryption because they couldn't
find my key (my guess is that the keyservers were failing but that's
immaterial).

Thanks for your time!

Kind regards,
Wiktor

[Derek Martin]

Wiktor,

Post by Wiktor Kwapisiewicz

Post by Derek Martin
On that basis I think Mutt should force the user to explicitly decide
that they want to fetch a key, by doing so through the gnupg
interface.

Is asking the user if they want to fetch the key interactively (if
the key is not found locally) not an explicit decision?

Not necessarily! Users get in the habit of accepting dialogs because,
well, obviously I want to do what I just said I want to do!

Post by Wiktor Kwapisiewicz
Or do you mean that the user should exit mutt and run gpg manually?

Yes.

Post by Wiktor Kwapisiewicz

Post by Derek Martin
Another way to look at this: Mutt likes to relegate tasks to an
application which is designated for that task.

[...]

Post by Wiktor Kwapisiewicz
Yes, I agree. The problem is that GPGME does not respect user
preferences w.r.t. key retrieval (stored in gpg.conf). I will ask on
gnupg-devel list if this is by design.

Yes, I can see that this is a problem. But Mutt's philosophy has
generally been that the tool designated to do the job should do the
job, and a bug in that tool should generally not be worked around in
Mutt, though exceptions exist when the situation calls for it. I'm
not convinced this one calls for it... the GnuPG people are pretty
reasonable and responsive.

Your other points are all reasonable, and like I said, my opposition
to the feature isn't strong--but you didn't change my mind either. :)

There's a trade-off here, as is often the case with security-sensitive
issues. If you make it too easy, it will be used improperly, some
percentage of the time, defeating the security that was meant to be
added. If you make it too hard, it won't be used at all when perhaps
it should.

It's become my opinion that e-mail privacy is a lost cause. There are
too many ways it can fail for you to be able to be confident that it
has not (in the event you actually have any communications worth
encrypting), some of which may put your life in danger[*]. This,
combined with the point above, is the reason my opposition is not
strong, but it's also another argument why Mutt doesn't need the
feature. That is, you simply don't need it because encrypting your
e-mail is pointless in the first place. :) Obviously there will be
many exceptions, but I think for the average person it's true.

But, I admit, I'm off in the weeds now... =8^)

-=-=-
[*] Like forcing you--OR your recipients--to decrypt your e-mail at
gunpoint. And worse still, if you use it when you don't need it,
encryption may lead some bad actors to believe you have something
worth encrypting when you don't, causing them to target you for no
good reason.

[Wiktor Kwapisiewicz]

Post by Derek Martin
Your other points are all reasonable, and like I said, my opposition
to the feature isn't strong--but you didn't change my mind either. :)

Yes, I can see that, but it's hard to change your opinion that e-mail
privacy is a lost cause in just a couple of e-mails.

Mind me asking why do you put your key ID in e-mails if you're opposed
to encrypted communication?

Post by Derek Martin
FWIW, we've now seen from 3 mutt-dev followers that they would prefer
this code not go in... even to the point where they'd patch -R to
remove it. That, for my money, is reason enough to not include it.

There is no code at this point and as far as I can see the "ultimate
solution" of patching has been brought in context of "automatic WKD".
And automatic WKD was already dismissed by Kevin in his first e-mail.

Post by Derek Martin

Post by Kevin J. McCarthy
I am disinclined to default-enable something that send http requests
out without the user fully understanding what's going on.

Agreed.
I would patch my copy of the source to not enable such code at all

End of quote.

Post by Derek Martin
It's actually worse, because
it leaks whom you are actually sending messages to, rather than from
whom you're receiving them...

If you're sending e-mail to ***@example.com and do a WKD query it would
reveal that only to example.com. But you're sending the e-mail there so
that user (or their server admins) would already know that after you
send that e-mail.

Kind regards,
Wiktor

[Derek Martin]

Post by Wiktor Kwapisiewicz

Post by Derek Martin
Your other points are all reasonable, and like I said, my opposition
to the feature isn't strong--but you didn't change my mind either. :)

Yes, I can see that, but it's hard to change your opinion that
e-mail privacy is a lost cause in just a couple of e-mails.

I've thought extensively about it, and (I hope it's clear that) I'm
fairly well versed on the topic, so I think it's extraordinarily
unlikely you could change my opinion with any number of e-mails... ;-)
But I suppose anything is possible.

Post by Wiktor Kwapisiewicz
Mind me asking why do you put your key ID in e-mails if you're
opposed to encrypted communication?

Well... It's been there for decades. Quite literally. I was once an
avid user of encryption. But it's also there for digital signatures,
and so that if people really, really want to e-mail me directly,
rather than respond to me on some list I'm posting on, there's a way
that can be possible... if they're a little bit clever.

Post by Wiktor Kwapisiewicz

Post by Derek Martin
It's actually worse, because it leaks whom you are actually sending
messages to, rather than from whom you're receiving them...

would reveal that only to example.com. But you're sending the e-mail
there so that user (or their server admins) would already know that
after you send that e-mail.

False. It would also potentially reveal that to anyone who was
operating any part of the network in between your endpoint and the
example.com endpoint, as well as anyone who was able to subvert some
aspect of the example.com domain (its DNS, the webserver, etc.) by
MITM attack or similar. Or... other things.

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.

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.

But, in fact I am not--I'm just an average guy where I'm from.
Frankly I never say anything in e-mail that I would not say loudly in
a crowd of strangers, so... encrypting my mail is really pointless. :)
For truly sensitive communications, I will find a different way, as
suited to the specific circumstances.

[Wiktor Kwapisiewicz]

Hi, Derek,

Post by Derek Martin
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 ***@kernel.org | mail -s "Subject"
***@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.

Post by Derek Martin
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.

Post by Derek Martin
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

[Vincent Lefevre]

Post by Derek Martin

Post by Wiktor Kwapisiewicz
would reveal that only to example.com. But you're sending the e-mail
there so that user (or their server admins) would already know that
after you send that e-mail.

False. It would also potentially reveal that to anyone who was
operating any part of the network in between your endpoint and the
example.com endpoint, as well as anyone who was able to subvert some
aspect of the example.com domain (its DNS, the webserver, etc.) by
MITM attack or similar. Or... other things.
However the mere revelation of who is receiving my messages can be
just as dangerous, depending on the type of correspondence I'm having.

then, don't use e-mail, because e-mail will not guarantee the absence
of any leak of the recipient address.

IMHO, the default settings should be what is best for the average
user, in particular users who do not have much knowledge of
potential security issues. Perhaps the WKD protocol is better than
letting the average user decide what to do to retrieve the key:
for instance, retrieving it by plain http (not https) is perhaps
the worst thing to do.

Users with specific needs should be able to configure their software
as they need (not just e-mail, as leaks can come from DNS and so on).

[Derek Martin]

Post by Vincent Lefevre

Post by Derek Martin

Post by Wiktor Kwapisiewicz
would reveal that only to example.com. But you're sending the e-mail
there so that user (or their server admins) would already know that
after you send that e-mail.

False. It would also potentially reveal that to anyone who was
operating any part of the network in between your endpoint and the
example.com endpoint, as well as anyone who was able to subvert some
aspect of the example.com domain (its DNS, the webserver, etc.) by
MITM attack or similar. Or... other things.
However the mere revelation of who is receiving my messages can be
just as dangerous, depending on the type of correspondence I'm having.

then, don't use e-mail, because e-mail will not guarantee the absence
of any leak of the recipient address.

Exactly my point. If you really care about keeping private
communications private, do not use e-mail. Working backward from
that, there's no reason to bother with encryption on e-mail.

[Derek Martin]

Post by Wiktor Kwapisiewicz
Mind me asking why do you put your key ID in e-mails if you're
opposed to encrypted communication?

Also for what it's worth, I never said I was opposed to encrypted
communication. What I said is I think encrypted email protects you a
lot less than you think, and it's most likely pointless to begin with,
and could potentially even make you a target.

I'm actually still quite in favor of encryption, in general, and
encrypted communication in principle. I just think in practice it's
way more trouble than it's worth, and what it's worth is probably less
than you think it is.

[Derek Martin]

Post by Wiktor Kwapisiewicz
Yes, I agree. The problem is that GPGME does not respect user
preferences w.r.t. key retrieval (stored in gpg.conf). I will ask on
gnupg-devel list if this is by design.

FWIW, we've now seen from 3 mutt-dev followers that they would prefer
this code not go in... even to the point where they'd patch -R to
remove it. That, for my money, is reason enough to not include it.

Others echoed my sentiment that getting gnupg to handle this would
be the preferred solution.