what's necessary before new OpenPGP keys are used?

Ben Bucksch ben.bucksch at beonex.com
Thu Dec 5 18:23:24 UTC 2019


On 05.12.19 19:20, Ben Bucksch wrote:
> 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.


Sorry, correction: These sentences where in the wrong order and 
therefore misleading. I meant to write:


>> 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.
>
> I am presuming that our user Alice has explicitly opted in to crypto.
>
Rationale:

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



More information about the tb-planning mailing list