update verified key

[r10s]

This is an Autocrypt / Delta Chat implementation question and not directly related to the countermitm-paper, however, i think it is discussed better here as in the delta-repository.

The question:

If a verified-key stored by a peer seems to be no longer valid (does not match direct-key or gossip-key) and the peer receives a new verified-key through gossip (step 7 of the verified-group-protocol) - shall we change the verified-key to the gossiped-key then?

Otherwise, a verified key is never updated and we're stuck with it until we do a qr scan with this person again which might be annoying.

[carmelatroncoso]

my 2 cents:

I am not fully sure that step 7 allows to learn new verified keys. The message only conveys the last key observed by Alice, which does not need to be the real one. I would say that this should trigger a message to verify the key with the person for whom the inconsistency was detected (as when using ClaimChains).

[azul]

@r10s I think we have conflicting interests here:

• expectation of confidentiality associated with a verified contact
• risk of unreadable mail for the peer

In general we try hard to prevent unreadable mail. But in a verified channel or group i would say we give higher priority to the confidentiality.

We also should follow the principle of least astonishment. For me that implies not reusing the verified gossip key for the verified contact. It might lead to unreadable mail. But that's also what would happen in the absence of the verified group. An old verified contact breaking and healing itself (because of a verified group) while another one stays broken seems pretty surprising to me.

Do users have a way to get out of the broken verified contact scenario? If I loose my key and cannot read your mails anymore... can i send you an unverified message that says so and you can reply to it and it won't be encryped / will use my new key?

I personally think verifications should be bound to the context. I have a verified key for you as a verified contact and i might have a different key for you in a verified group. But I understand that that is messy / difficult to implement.

[r10s]

Do users have a way to get out of the broken verified contact scenario? If I loose my key and cannot read your mails anymore... can i send you an unverified message that says so and you can reply to it and it won't be encryped / will use my new key?

@azul Yes, this is the normal Autocrypt way - if Alice loses her key and cannot read Bobs mail, Alice can send Bob a mail telling him that she cannot read. This mail from Alice to Bob will contain Alice's new key and then the Autocrypt connection is healed.

However, this won't heal the verified connection - the only way to heal it at the moment is a new out-of-band verification - which is unsatisfactory as Alice and Bob might live in different parts of the world and have never met in the past.

If Alice and Bob cannot meet in person, however, maybe a Claire can heal if she has verified connection to both, Alice and Bob. This was the initial questions - Bob might get Alice's verified key though the verified connection to Claire.
But maybe this would be too astonished to users, i do not know (yet :)

[azul]

@r10s I wonder if one could 'close' a verified connection or 'unlock' a verified contact.
That would basically be a concious decission by the user to acknowledge that something is messed up here.

[hpk42]

On Sat, May 12, 2018 at 06:51 -0700, Björn Petersen wrote: > Do users have a way to get out of the broken verified contact scenario? If I loose my key and cannot read your mails anymore... can i send you an unverified message that says so and you can reply to it and it won't be encryped / will use my new key? @azul Yes, this is the normal Autocrypt way - if Alice loses her key and cannot read Bobs mail, Alice can send Bob a mail telling him that she cannot read. This mail from Alice to Bob will contain Alice's new key and then the Autocrypt connection is healed. However, this won't heal the verified connection - the _only_ way to heal it at the moment is a new out-of-band verification - which is unsatisfactory as Alice and Bob might live in different parts of the world and have never met in the past.

sidenote: we might describe ways how to do delta verification remotely. take a screenshot and send it via unverified signal: this would be an out-of-band channel relative to the e-mail provider controlled machines. the problem is how to track these "notions" ... this is not stuff for countermitm at this point.

…

If Alice and Bob cannot meet in person, however, maybe a Claire can heal if she has verified connection to both, Alice and Bob. This was the initial questions - Bob might get Alice's verified key though the verified connection to Claire. But maybe this would be too astonished to users, i do not know (yet :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #46 (comment)

[azul]

Okay... I still think this is a very difficult question.
Say Claire verified the new key for Bob and also has a verified channel to Alice. So she could heal the connection between Alice and Bob.

First of all... what would the workflow be? Right now i imagine:

1. Claire and Bob verify contacts
2. Claire's device notices some of her verified groups have other keys for Bob
3. Claire's device informs those groups
4. Alice is in one of the groups and her device learns about the new keys
5. Alice's device accepts the new keys

However the information might actually spread further:
6) Alice's device notices some of her verified groups have other keys for Bob
7) Alice's device informs those groups

Here's some questions:
Would 3) and 7) look the same?
yes: less leakage of who personally verified whom
no: higher confidence in 3) than 7) (someone i know verified this rather than verification gossip)

When would we ask the user for consent?

• in 3) ... which Groups do you want to inform?
• in 5) ... do you want to accept the new keys?
• in 7) ... which groups do you want to inform?

[azul]

Okay... so the answers i am currently exploring are the most simple possible:

• 3) and 7) look the same
• no asking for consent

That means new keys would propagate through the verified groups without user intervention.

It's an attack vector for spreading bogus keys. However the person performing that attack...

• already must share a group with the victim
• will be visible as the origin

That's pretty strong assumptions.

On the positive side we gain quick recovery from device loss across all connected verified contacts by just performing a single verification.

[testbird]

The conflict only arises from mixing up oob in-person contact verification with in-band "key endorsement" (in lack of a better name). If the different levels would be visible to the user (e.g. as check-marked vs. black silhouette contacts), an additional message could be enough to notify the user about the status change, while the message exchange can continue normaly until the verified contact status can be reached again during a personal meeting ...or video chat.

Edit: That would be three contact states actually: black silhouette (opportunistic), no special marker (regular endorsed user), check-marked (personal oob verification)