From 2ea4e13239e78fde5692cb57187332d49bd1edc9 Mon Sep 17 00:00:00 2001 From: Sumner Evans Date: Fri, 7 Jun 2024 10:35:31 -0600 Subject: [PATCH] fixup! e2ee/device verification: move general error handling under framework Signed-off-by: Sumner Evans --- .../modules/end_to_end_encryption.md | 47 ++++++++++--------- 1 file changed, 24 insertions(+), 23 deletions(-) diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index ce8e6344..0e06f410 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -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