e2ee/device verification: move general error handling under framework

Most of the "Error and exception handling" section is generally
applicable to other verification methods besides SAS, so I moved those
bullet points under "Key verification framework".

Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
pull/1830/head
Sumner Evans 2 years ago
parent 49765e0e0a
commit 0872ec788a
No known key found for this signature in database

@ -597,6 +597,30 @@ package naming convention.
{{% event event="m.key.verification.cancel" %}} {{% event event="m.key.verification.cancel" %}}
###### General key verification error handling
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` 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` 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` message to the other device
indicating as such. This does not apply for inbound
`m.key.verification.start` or `m.key.verification.cancel` 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` message.
##### Short Authentication String (SAS) verification ##### Short Authentication String (SAS) verification
SAS verification is a user-friendly key verification process built off SAS verification is a user-friendly key verification process built off
@ -720,35 +744,17 @@ devices:
| | | |
``` ```
###### Error and exception handling ###### SAS error handling
At any point the interactive verification can go wrong. The following At any point the interactive verification can go wrong. The following
describes what to do when an error happens: describes what to do when an error happens:
- Alice or Bob can cancel the verification at any time. An
`m.key.verification.cancel` 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` 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` message to the other
device indicating as such. This does not apply for inbound
`m.key.verification.start` or `m.key.verification.cancel` messages.
- If the two devices do not share a common key share, hash, HMAC, or - 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 SAS method then the device should notify the other device with an
appropriate `m.key.verification.cancel` message. appropriate `m.key.verification.cancel` message.
- If the user claims the Short Authentication Strings do not match, - If the user claims the Short Authentication Strings do not match,
the device should send an appropriate `m.key.verification.cancel` the device should send an appropriate `m.key.verification.cancel`
message to the other device. message to the other device.
- 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` message.
###### Verification messages specific to SAS ###### Verification messages specific to SAS

Loading…
Cancel
Save