what's necessary before new OpenPGP keys are used?

Kai Engert kaie at kuix.de
Thu Dec 5 22:04:15 UTC 2019

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

We might want to distinguish where it has been published.

Maybe we'll have some kind of automatic key refresh mechanism, that 
checks for an updated key using WKD, or maybe on a keyserver (helpful 
for refreshed keys that would have expired, but that were extended by 
the key owner).

If we found an ambiguous key, which we have never seen before, on one of 
the sources that we allow for learning about new keys, then we probably 
should consider that for ambiguity warnings.

Do we consider arriving emails with attached keys a valid source for 
learning about new keys? If yes, then an attacker simply has to send an 
email with a fake key in Bob's name, to trigger an ambiguity warning in 
Alice's Thunderbird.

If this seems to happen frequently, we could reduce the amount of 
"ambiguous key reviewing" Alice has to do, by only showing ambiguity in 
the UI, but not block the user from using already accepted and still 
valid keys.

Still, if this happens a lot, the "pending ambiguity review" might 
become a common display and start to get ignored by Alice.

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

With this model, to trick Thunderbird into displaying an ambiguity 
status for the adversary's key, the adversary would simply have to send 
an email to Alice, encrypted to both Alice's known public key, and also 
to the adversary's new key, right?

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

SSH doesn't silently accept a key when connecting to a service for the 
first time.

SSH prompts the user when connecting to a service for the first time, 
and requires the user to accept the key.

That's what I'm suggesting, too. Tell Alice: "Here's Bob's key, please 
confirm you're willing to use it".


More information about the tb-planning mailing list