what's necessary before new OpenPGP keys are used?

Patrick Brunschwig patrick at enigmail.net
Sat Dec 7 08:38:17 UTC 2019


Ben Bucksch wrote on 05.12.2019 19:20:
> On 05.12.19 18:33, Kai Engert wrote:
>> Changing subject, to make it clear this discussion is no longer about
>> Autocrypt.
>>
>> 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.

That's exactly the way how Autocrypt is intended to work, with the
addition that Autocrypt allows Bob to tell Alice whether or he prefers
encrypted mails or unencrypted.

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

This is at a plausible option in my eyes. Autocrypt would go a step
further and promote to use that new key, but it's true that this opens
up a certain attack vector. In general, replacing the current key if you
lost (or distrust) your old key is a challenge, and your proposal does
not cover this aspect sufficiently. How can Bob convince Alice to use
his new key, if he lost his old key?

-Patrick




More information about the tb-planning mailing list