what's necessary before new OpenPGP keys are used?
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
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
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
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