update verified key - Githubissues

r10s commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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: https://github.com/hpk42/countermitm/issues/46#issuecomment-388556701

azul commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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)

nextleap-project / countermitm

update verified key #46