From 1cd3dee6b5d45980e751c7eb61c86a987e158e2e Mon Sep 17 00:00:00 2001 From: Benjamin Beurdouche Date: Tue, 7 Nov 2023 13:56:59 +0100 Subject: [PATCH] Fix confusion between AEAD key and Ratchet Secret compromise #213 --- draft-ietf-mls-architecture.md | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index ec64b59..ab68fc7 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1460,7 +1460,9 @@ protocol. In this section we will explore the consequences and recommendations regarding the following compromise scenarios: -- The attacker has access to a specific symmetric encryption key +- The attacker has access to a symmetric encryption key + +- The attacker has access to a application ratchet secret - The attacker has access to the group secrets for one group @@ -1479,26 +1481,31 @@ messages. The Group Operation messages offer an additional protection as the secret exchanged within the TreeKEM group key agreement are public-key encrypted to subgroups with HPKE. -### Compromise of AEAD key material +### Compromise of Application Ratchet Key material In some circumstances, adversaries may have access to specific AEAD keys and nonces which protect an Application or a Group Operation message. While this is a limited kind of compromise, it can be realistic in cases of implementation -vulnerabilities where only part of the memory leaks to the adversary. +vulnerabilities where only part of the memory leaks to the adversary. As the +application AEAD keys are derived from the application ratchet secret, compromise +of a single application ratchet key does not imply compromise of any other AEAD +key or nonce. + +### Compromise of Ratchet Secret material -When an AEAD key is compromised, the adversary has access to a set of AEAD keys +When an Ratchet Secret is compromised, the adversary has access to a set of AEAD keys for the same chain and the same epoch, hence can decrypt messages sent using keys of this chain. An adversary cannot send a message to a group which appears to be from any valid client since they cannot forge the signature. -The MLS protocol will ensure that an adversary cannot compute any previous AEAD -keys for the same epoch, or any other epochs. Because of its Forward Secrecy -guarantees, MLS will also retain secrecy of all other AEAD keys generated for -*other* MLS clients, outside this dedicated chain of AEAD keys and nonces, even -within the epoch of the compromise. However the MLS protocol does not provide -Post Compromise Secrecy for AEAD encryption within an epoch. This means that if -the AEAD key of a chain is compromised, the adversary can compute an arbitrary -number of subsequent AEAD keys for that chain. +The MLS protocol will ensure that an adversary cannot compute any secret +anterior for the same epoch, or for any other epochs. Because of its Forward +Secrecy guarantees, MLS will also retain secrecy of all other AEAD keys +generated for *other* MLS clients, outside this dedicated chain of AEAD keys and +nonces, even within the epoch of the compromise. However the MLS protocol does +not provide Post Compromise Secrecy for AEAD encryption within an epoch. This +means that if the AEAD key of a chain is compromised, the adversary can compute +an arbitrary number of subsequent AEAD keys for that chain. These guarantees are ensured by the structure of the MLS key schedule which provides Forward Secrecy for these AEAD encryptions, across the messages within