Autocrypt gossip_key must be preferred over public_key?

[r10s]

From Joining a verified group ("secure-join"):

[...] 6. Alice broadcasts an encrypted "vg-member-added" message to all group members (including Bob), gossiping the Autocrypt keys of everyone, including the new member Bob.

7. Bob receives the encrypted "vg-member-added" message and learns all the keys and e-mail addresses of group members. Bob's device sends a final "vg-member-added-received" message to Alice's device. Bob's device shows "You successfully joined the verified group 'X'". [...]

Assume in step 7., Bob receives the key from the other group member Claire. Bob was in contact with Claire before but has seen a different key for Claire. As only the gossiped key is verified, Bob should now prefer the gossiped key over the existing one he got directly from Claire some time before. In practice, Bob will probably throw away the public_key silently.

Same may happen for Claire or other group members when they receive the gossip_key of Bob that differs from the public_key they've seen.

I think this is no protocol issue, however, it is worth mentioning as in Autocrypt public_key is always preferred over gossip_key iirc.

[hpk42]

i think you are right -- in a verified group, the Autocrypt logic of prefering a direct key is shadowed by the verified group defining that the in-group verified keys need to be used. I guess it's best to not actually throw away the direct key but simply implement the verified-key-in-group logic as to precede and thus suspend the normal autocrypt choice.

[azul]

I totally agree for the scope of the group. Not sure about the Autocrypt side of things though. Main thing i am worried about is unpredicted sideeffects that are hard to understand. Especially if you take timing into account. The verified key may still be outdated.

Say Alice cannot read the verified group mails anymore because they lost their device / key material. But now the new Autocrypt setup she used with Bob also stops working because Bob was added to the verified group and got their old verified key and is using it over the newer unverified one.

Autocrypt and verified groups have different security / usability trade offs. So there are reasonable cases to use one key for the one and another one for the other.

[hpk42]

what i meant to suggest is that outside verified group messaging the normal autocrypt rules would apply.

also:

• i guess it's unlikely the inconsistent situation will last for long -- as soon as Claire sends a message that Bob sees things will be consistent again. In theory, using onion-key-lookup can accelerate this convergence.

• it's maybe even unlikely the verified gossiped key is outdated to begin with. If the verified group is a somewhat active group and Claire participates the verified key will be her direct and valid key

[azul]

What happens in the case of a verified contact right now? I assume we still use the latest keys we see. If a new Autocrypt key shows up after the verification it would be used and remove the verified contact checkmark. Or is the verification 'sticky'? Is there a warning? I don't think we have specified this yet.

edit: I guess this is a separate issue: :point_right: #32

[r10s]

i think for delta, i will track _public_keyverified and _gossip_keyverified flags then and do not throw away any keys.

when sending messages, a verified public key will be preferred over a verified gossiped key then; which seems to be fine as the verified public key would also be the key that would be broadcasted to new members.

this also gives us the possibility to tweak the selection algorithm at a later time.

[r10s]

instead of flags, delta holds the verified_key independently of public_key and gossip_key now.

so, the original issue seems to be solved.