what's necessary before new OpenPGP keys are used?
kaie at kuix.de
Thu Dec 5 19:42:58 UTC 2019
On 05.12.19 19:23, Ben Bucksch wrote:
>>> I suggest the user should be required to opt in whenever using a
>>> correspondent's key for the first time.
>> I would suggest to do that automatically. I.e. if Bob sends Alice a
>> key to use, and Alice doesn't have a key for Bob yet, then Alice
>> should automatically use that, without explicit user opt-in.
Bob's key might in fact have been sent by an adversary, who wants to
trick Alice into concluding that Bob is set up to use encryption.
>> 1) The recipient Bob has specifically requested to receive encrypted
>> mail, that's why the key is attached. So, we follow his wish by
We aren't sure if it was Bob's wish, or the wish of an adversary.
>> 2) Our user Alice set up for encrypted email, so she wants it as well.
>> 3) If the key is wrong and from an attacker who wants to spy, than
>> we're no worse off than sending plaintext mail.
There's one more risk to consider:
When inside the composer window, I'd like to have UI elements, that give
a visual feedback whether encryption can currently be used, or cannot be
used - even for users who aren't yet set up for encryption, in order to
encourage them to start using encryption.
If Thunderbird decided that the new key can automatically be used, then
our UI would have visuals, that tell Alice that "encryption with Bob is
(If we required opt in, it should show "encryption possible, but needs
Alice might be aware that sensitive topics should never be sent in plain
However, seeing that encryption with Bob is possible, Alice might
conclude that she doesn't need to wait until she will meet Bob again,
but that she can go ahead and send the sensitive information by email.
In this scenario, the adversary would have successfully tricked Alice
into sending sensitive information to the adversary, although she would
have never been willing to send that information in a plain text email.
If Thunderbird required that Alice opts in to use a key that might be
Bob's key, then Alice is given a chance to ponder about the conversation
with Bob. This will include the reminder that Bob's key is unverified,
and that she should decide if that's fine, or if she really needs to be
certain about Bob's key.
Another scenario is Alice starting to use a new, empty computer.
>> I am presuming that our user Alice has explicitly opted in to crypto.
While this is necessary for sending out signed email, I wonder if we
could offer the choice to encrypt an outgoing email, even if Alice
denies a recommendation to set up her own key (because that's
So, let's say, Alice started using a new computer. She doesn't have any
need to encrypt during the first couple of days, and hasn't yet migrated
all of her data, but needs to get some work done.
Maybe a powerful adversary even noticed that Alice has a new computer,
and that now might be a good time for a targeted attack.
Now she gets that email from Bob, who suggests "we need to talk about,
you know what I mean...".
Thunderbird imports the key automatically, Alice hits reply, Thunderbird
shows "we could encrypt if you want to". Alice thinks "ok, let's skip
the need to meet and just deal with that sensitive topic by email,
should be fine, it's encrypted, right".
If we required Alice to opt in, then Alice is given a chance to realize
"why am I asked to confirm this? I didn't have to do this before? Oh
right, I'm on that new computer. I should verify if I have the right
keys. Maybe I should call Bob to verify the key, or have a look on that
old laptop if the keys are the same."
My current preference is to require an opt in, not use the new key
Maybe I seem overly paranoid, but I think it would be good if
Thunderbird were a suitable tool for people who are targetted by
More information about the tb-planning