what's necessary before new OpenPGP keys are used?
ben.bucksch at beonex.com
Thu Dec 5 18:20:29 UTC 2019
On 05.12.19 18:33, Kai Engert wrote:
> Changing subject, to make it clear this discussion is no longer about
> On 05.12.19 17:53, Ben Bucksch wrote:
>> Maybe I missed it. It seems implicit, but I haven't read it explicitly:
> You haven't missed it. We haven't yet presented a a design for the
> user interface and interaction.
>> Will we use key for communications partners that send me plain text
>> emails with a key, and I do not know a key for that person yet? Will
>> encryption then happen automatically for my answer, and use that key
>> from now now?
> I suggest the user should be required to opt in whenever using a
> correspondent's key for the first time.
I am presuming that our user Alice has explicitly opted in to crypto.
I would suggest to do that automatically.
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.
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.
4) If the key is wrong and from an attacker that wants to disrupt
communication, then our user will notice at some point that he does not
get a reply. It is not an unusual situation and similar to a mail
classified as spam, and does not arrive.
So, I'm claiming that there's nothing to lose to automatically encrypt.
In fact, not doing so would be running counter to the explicitly stated
with of *both* communication partners. So, there's no point in asking,
and that would only be nagging.
> As soon as Alice has opted in to use Bob's key for encryption (with or
> without doing a full verification), then Alice's Thunderbird will
> continue to use Bob's key for future outgoing encrypted email, without
> further need to confirm.
That's for sure. Alice already approved. No point in asking again.
> However, as soon as we detect an ambiguity, like, a new key for Bob
> has either been received by email or discovered on some key
> publication service, we should go back to a "needs review" state, in
> which Alice should be presented with the ambiguity, and requested to
> resolve it.
I would *not* consider a new key for Bob on some key publication service
an ambiguity. That would leave obvious means for an attacker to disrupt
an already standing and secure communication between Alice and Bob.
There's even a 50% chance that Alice will accept the new attacker key
and be insecure from now on.
I would ask to resolve only if Bob starts sending a new key and
encrypted his emails with the new key. Even then, I would make it very
clear in the UI for Alice that this is a potential attack scenario. SSH
does this well here, and we should use that as example.
In general, the SSH model has prove to work really well and done a whole
lot of good for the security. We should follow it very closely. That
means: Automatically import keys and encrypt without asking (presuming
the user generally opted in to encryption with all its implications).
But then really insist on using that key. And set up Alice so that she
never changes her key, even for re-installs of Thunderbird on a new
More information about the tb-planning