Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2366: Key verification flow additions: m.key.verification.ready and m.key.verification.done #2366

Merged
merged 9 commits into from
Jan 31, 2021
Merged

MSC2366: Key verification flow additions: m.key.verification.ready and m.key.verification.done #2366

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
33df2d1
initial proposal of `m.key.verification.accept`
uhoreg Nov 25, 2019
abbba47
rename to match MSC number
uhoreg Nov 25, 2019
5f5f99f
wording tweaks
uhoreg Nov 26, 2019
5742c30
s/accept/ready/ because we already have an m.key.verification.accept
uhoreg Nov 29, 2019
17abe05
send m.key.verification.cancel to other devices when one device is ready
uhoreg Nov 29, 2019
22f7eaa
add example
uhoreg Dec 4, 2019
4672a70
make .ready required, and add .done
uhoreg Apr 15, 2020
2e0ef11
Wording fixes
uhoreg May 18, 2020
c741049
more clarifications
uhoreg Jun 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 26 additions & 20 deletions proposals/2366-key-verification-accept.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Key verification flow addition: `m.key.verification.ready`
# Key verification flow additions: `m.key.verification.ready` and `m.key.verification.done`
uhoreg marked this conversation as resolved.
Show resolved Hide resolved

The current key verification framework is asymmetrical in that the user who
requests the verification is unable to select the key verification method.
Expand All @@ -17,11 +17,22 @@ responsible for choosing the verification method to use. However, with this
proposal, Bob would be able to just accept the verification request without
choosing a method, and allow Alice to choose the verification method.

In addition, the current key verification framework does not have a method for
clients to signal to the other side that a key verification was successful.
Some clients may wish to wait until the other side has either confirmed a
successful verification or indicated an error before displaying the result of
the verification, in order to give the two users a consistent view of the
verification as a whole.

## Proposal

A new event type is added to the key verification framework:
`m.key.verification.ready`, which may be sent by the target of the
`m.key.verification.request` message, upon receipt of the
Two new event types are added to the key verification framework. The new event
types are already described in [MSC2241 (Key verification in
DMs)](https://github.com/matrix-org/matrix-doc/pull/2241). This proposal adds
them to verifications in to-device messages.
richvdh marked this conversation as resolved.
Show resolved Hide resolved

The first event type is `m.key.verification.ready`, which may be sent by the
uhoreg marked this conversation as resolved.
Show resolved Hide resolved
target of the `m.key.verification.request` message, upon receipt of the
`m.key.verification.request` event. It has the fields:

- `from_device`: the ID of the device that sent the `m.key.verification.ready`
uhoreg marked this conversation as resolved.
Show resolved Hide resolved
Expand Down Expand Up @@ -50,22 +61,17 @@ message to the recipient's other devices when it received an
message when it receives an `m.key.verification.ready` or
`m.key.verification.start` message, whichever comes first.

The `m.key.verification.ready` event is optional; the recipient of the
`m.key.verification.request` event may respond directly with a
`m.key.verification.start` event instead. This is for compatibility with the
current version of the spec.
The `m.key.verification.ready` event is required for verifications in both DMs
and in to-device messages to accept verifications requested using an
`m.key.verification.request` event.

## Potential issues
The second event type is `m.key.verification.done`, which has no fields other
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How long should the other client wait until it receives a done, as old clients won't send that? The normal timeout of 10min sounds pretty long.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same question. Riot doesn't send this, when you are not verifying in DMs it seems. So we kinda need a behaviour for the transition phase, when a client follows the current spec.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It definitely should be sent in DMs.
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when you are not verifying in DMs

It seems to be only sent, when verifying via DMs. So it seems like it is not sent in to_device messaging. This proposal suggests, that clients would be sending them already, but they don't. Unless I am missing something.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, sorry. I read your sentence several times, and managed to miss the "not" every time. :-/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tried in Element Web in a non-DM self-verification, and it does send an m.key.verification.ready in response to m.key.verification.request. Trying to directly verify another user's device seems to send an m.key.verification.start directly, so it is not affected by this case.

I haven't tried Element Android or Element iOS yet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that matches my tests as well. It can deal with request, but if you start it from Element, it uses start (for to_device verifications).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested Element Web, and it sent an m.key.verification.done after verifying using to-device. I haven't tested Android or iOS. In response to the original question in this thread:

How long should the other client wait until it receives a done, as old clients won't send that?

I think that we're at the point where we don't need to worry about "old" clients (it looks like Element is doing this, and just waiting until the normal timeout), but if you do want to worry about old clients, you could 1) wait for the .done, but allow the user to exit the verification UI, or 2) exit the verification UI once it's completed on your side, without waiting for the .done to come in from the other user.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does element-web also send a .done if you don't initiate verification via popup but via the device menu on the right? The device menu on the right also skips the .request and starts directly with a .start, so yeah

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I tested initialting verification both via the popup and via the device menu. In both situations, it sent the .done in my tests. (I also noticed that initiating from the device menu skipped the .request step.)

than the usual `transaction_id` or `m.relates_to` field. This indicates that
the device has successfully completed its side of the verification.

There are now three possible ways that a key verification can be performed:

1. A device begins a verification by sending an `m.key.verification.start`
event. This is only possible for to-device verification.
2. A device sends an `m.key.verification.request` event and the recipient
replies with an `m.key.verification.start` event.
3. A device sends an `m.key.verification.request` event and the recipient
replies with an `m.key.verification.ready` event, and which point, either
device can send an `m.key.verification.start` event to begin the
verification.
## Potential issues

This increases the complexity of implementations.
Clients that follow the Client-Server 0.6.0 spec may not expect an
richvdh marked this conversation as resolved.
Show resolved Hide resolved
`m.key.verification.ready` message in response to `m.key.verification.request`.
However to our knowledge, no clients implement `m.key.verification.request` in
uhoreg marked this conversation as resolved.
Show resolved Hide resolved
this way yet.