Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-24 03:54:10 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

fixup! e2ee/device verification: move general error handling under framework

Browse source 
Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
This commit is contained in:
Sumner Evans 2024-06-07 10:35:31 -06:00
parent d6c6a0361f
commit 2ea4e13239
No known key found for this signature in database
1 changed files with 24 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -602,27 +602,27 @@ package naming convention.
At any point the interactive verification can go wrong. The following describes
what to do when an error happens:
- Alice or Bob can cancel the verification at any time. An
[`m.key.verification.cancel`](#mkeyverificationcancel) message must be sent to
signify the cancellation.
- The verification can time out. Clients should time out a verification that
does not complete within 10 minutes. Additionally, clients should expire a
`transaction_id` which goes unused for 10 minutes after having last
sent/received it. The client should inform the user that the verification
timed out, and send an appropriate
[`m.key.verification.cancel`](#mkeyverificationcancel) message to the other
device.
- When the same device attempts to initiate multiple verification attempts,
the recipient should cancel all attempts with that device.
- When a device receives an unknown `transaction_id`, it should send an
appropriate [`m.key.verification.cancel`](#mkeyverificationcancel) message to
the other device indicating as such. This does not apply for inbound
[`m.key.verification.request`](#mkeyverificationrequest),
[`m.key.verification.start`](#mkeyverificationstart), or
[`m.key.verification.cancel`](#mkeyverificationcancel) messages.
- If the device receives a message out of sequence or that it was not expecting,
it should notify the other device with an appropriate
[`m.key.verification.cancel`](#mkeyverificationcancel) message.
- Alice or Bob can cancel the verification at any time. An
[`m.key.verification.cancel`](#mkeyverificationcancel) message must be sent
to signify the cancellation.
- The verification can time out. Clients should time out a verification that
does not complete within 10 minutes. Additionally, clients should expire a
`transaction_id` which goes unused for 10 minutes after having last
sent/received it. The client should inform the user that the verification
timed out, and send an appropriate
[`m.key.verification.cancel`](#mkeyverificationcancel) message to the other
device.
- When the same device attempts to initiate multiple verification attempts,
the recipient should cancel all attempts with that device.
- When a device receives an unknown `transaction_id`, it should send an
appropriate [`m.key.verification.cancel`](#mkeyverificationcancel) message
to the other device indicating as such. This does not apply for inbound
[`m.key.verification.request`](#mkeyverificationrequest),
[`m.key.verification.start`](#mkeyverificationstart), or
[`m.key.verification.cancel`](#mkeyverificationcancel) messages.
- If the device receives a message out of sequence or that it was not
expecting, it should notify the other device with an appropriate
[`m.key.verification.cancel`](#mkeyverificationcancel) message.
##### Short Authentication String (SAS) verification
@ -749,8 +749,9 @@ devices:
###### Error handling during SAS verification
At any point the interactive verification can go wrong. The following
describes what to do when an error happens:
At any point the interactive verification can go wrong. In addition to the
[Error handling during key verification](#error-handling-during-key-verification) The following describes
what to do when an error happens:
- If the two devices do not share a common key share, hash, HMAC, or
SAS method then the device should notify the other device with an