Clarification for step 6b in Setup Contact protocol

[flub]

The 6.b steps says: sends Bob a “vc-contact-confirm” message.

However this is the only step which does not explicitly specify whether this message needs to be encrypted or cleartext. What does this do to the security properties of Setup Contact? Can an implementation choose whether to send it encrypted or cleartext?

[hpk42]

Bob has in step 4.a ascertained that Alice's key is consistent with the 1.a bootstrap info.
So if Step 6.b is an un-encrypted "vc-contact-confirm" Bob can not be tricked into a wrong key for Alice. Also, Alice can in step 5.a not be tricked into a wrong key for Bob. So an unencrypted vc-contact-confirm does not give an attacker the possibility to make one of the two believe in a wrong key.

However, i think a vc-contact-confirm should usually be encrypted, anyway, because there is no good reason not to. If you agree with this reasoning, we could add such a note sometime.

[link2xt]

It has to be encrypted and signed. Otherwise an attacker might block vc-request-with-auth and signal "success" to Bob by forging vc-contact-confirm. At this point Bob is not verified on Alice's devices, but Bob believes that he is.

Bob has to verify the signature before displaying "success".

[hpk42]

On Tue, Jan 21, 2020 at 12:01 -0800, Alexander Krotov wrote:

It has to be encrypted and signed. Otherwise an attacker might block vc-request-with-auth and signal "success" to Bob by forging vc-contact-confirm. At this point Bob is not verified on Alice's devices, but Bob believes that he is.

Yes, but it would not lead to any of Alice or Bob encrypting with a wrong key.

But ok, if a UX shows "secure connection to Alice established" it's reasonable to assume that this means that Bob can be sure that Alice has positively verified Bob's key. So encrypting vc-contact-confirm can certainly not hurt.

[flub]

It has to be encrypted and signed. Otherwise an attacker might block vc-request-with-auth and signal "success" to Bob by forging vc-contact-confirm. At this point Bob is not verified on Alice's devices, but Bob believes that he is.

So by singing and encrypting vc-contact-confirm Bob can know that he is verified as far as Alice is concerned. Does this mean that if vc-contact-confirm is not encrypted and signed then this message does not actually add anything to the protocol as all information was already known by Bob in step 4?

For Alice's case however success is signaled to the user in step 6a, so presumably this is when Alice marks Bob as verified. However if an attacker blocks vc-contact-confirm Bob will never mark Alice as verified. So Alice does not have the property of knowing that Bob considers her verified? Yet the vc-contact-confirm step is necessary for Bob to know Alice considers him verified.

[link2xt]

So Alice does not have the property of knowing that Bob considers her verified?

Alice knows it when she receives vc-request-with-auth. But Bob still does not know if she received this message. At this point they both are in Verified status, but Bob does not know that.

Looks like it is the reason for this TODO: https://github.com/deltachat/deltachat-core-rust/blob/2773b89815c75579103f2b83c318c76a936b5847/src/contact.rs#L160

After receiving vc-request-with-auth, Alice can set her state to BidirectVerified. And after receiving vc-contact-confirm, so can do Bob.

Because attacker can stop the protocol at any point, it is impossible for both parties to know they are in the same state. It is a Two General's Problem, you can't solve it no matter how many steps of email exchange you add. You need a fault-tolerant channel for that.

However, we don't have the goal of getting to BidirectVerified status. Pragmatic solution is to only have Unverified and Verified status and instruct Bob to keep trying to run the protocol until he sees "success". It is assumed that Alice and Bob are in the same room and they both see the "success" message displayed on Bob's screen.

If attacker blocks the vc-request-with-auth message it is not that bad: Bob has still verified Alice. And even if all email messages are blocked, Alice can still verify Bob by running the first step of the protocol in reverse direction, like Telegram/Signal/WhatsApp do. They both will see blue "verified" ticks in the end.

[flub]

Sounds reasonable, I was thinking that you can never know that you reached bidirectional verified status because of the lost message problem. But you convinced me that Alice actually has this state, she only doesn't know whether Bob also has this state.

So remaining question I have before I could come up with a PR to suggest some wording improvements is where the requirement comes from for vc-contact-confirm to be encrypted rather than just signed (this questions applies to all messages I guess?).

[link2xt]

So remaining question I have before I could come up with a PR to suggest some wording improvements is where the requirement comes from for vc-contact-confirm to be encrypted rather than just signed (this questions applies to all messages I guess?).

There are different reasons for other messages, such as not revealing AUTH value, for example. For vc-contact-confirm I would encrypt it to prevent reuse attack: otherwise an attacker can copy it and resend to other contacts performing this protocol with Alice, because Alice's signature will stay valid. The real solution is to add a separate transaction token, but it's not that important.

[link2xt]

But I would just encrypt everything that can be encrypted without stating the reason for that. And probably terminate the protocol if some message is not encrypted already, but in this case we need to check that Delta Chat's will stay compatible.