what's necessary before new OpenPGP keys are used?

Kai Engert 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 
>> encrypting.

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 
possible".

(If we required opt in, it should show "encryption possible, but needs 
review".)

Alice might be aware that sensitive topics should never be sent in plain 
text emails.

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.

You said:
 >> 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 
technically possible).

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".

Adversary wins.


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 
automatically.

Maybe I seem overly paranoid, but I think it would be good if 
Thunderbird were a suitable tool for people who are targetted by 
powerful adversaries.

Kai


More information about the tb-planning mailing list