From a9379862d849928a04fa13446835ebee75b7a956 Mon Sep 17 00:00:00 2001 From: Richard Barnes Date: Thu, 6 Feb 2020 18:01:33 -0500 Subject: [PATCH 1/6] Add some per-message entropy --- draft-ietf-mls-protocol.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index fa0ebb76..d7eee920 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -1584,6 +1584,7 @@ object of the following form: struct { uint32 sender; uint32 generation; + opaque reuse_guard[4]; } MLSSenderData; ~~~~~ @@ -1591,6 +1592,10 @@ MLSSenderData.sender is assumed to be a `member` sender type. When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is `member` and use Sender.sender for MLSSenderData.sender. +The `reuse_guard` field contains a fresh random value used to avoid nonce reuse +in the case of state loss or corruption, as described in +{{content-signing-and-encryption}}. + The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely: @@ -1674,6 +1679,33 @@ handshake message or an unused generation from its (per-sender) application key chain for the current epoch, according to the type of message being encrypted. +Before use in the encryption operation, the nonce is XORed with a fresh random +value to guard against reuse. Because the key schedule generates nonces +deterministically, a client must keep persistent state as to where in the key +schedule it is; if this persistent state is lost or corrupted, a client might +reuse a generation that has already been used, in particular nonce reuse. + +To avoid this situation, the sender of a message MUST generate a fresh random +4-byte "reuse guard" value and XOR it with the first four bytes of the nonce +from the key schedule before using the nonce for encryption. The sender MUST +include the reuse guard in the `reuse_guard` field of the sender data object, so +that the recipient of the message can use it to compute the nonce to be used for +decryption. + +~~~~~ ++-+-+-+-+---------...---+ +| Key Schedule Nonce | ++-+-+-+-+---------...---+ + XOR ++-+-+-+-+---------...---+ +| Guard | 0 | ++-+-+-+-+---------...---+ + === ++-+-+-+-+---------...---+ +| Encrypt/Decrypt Nonce | ++-+-+-+-+---------...---+ +~~~~~ + The Additional Authenticated Data (AAD) input to the encryption contains an object of the following form, with the values used to identify the key and nonce: From 20f59e30f42537af36f469c579e5b1ca72f714a0 Mon Sep 17 00:00:00 2001 From: Richard Barnes Date: Thu, 6 Feb 2020 18:03:50 -0500 Subject: [PATCH 2/6] Reword --- draft-ietf-mls-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index d7eee920..f939bc7b 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -1683,7 +1683,7 @@ Before use in the encryption operation, the nonce is XORed with a fresh random value to guard against reuse. Because the key schedule generates nonces deterministically, a client must keep persistent state as to where in the key schedule it is; if this persistent state is lost or corrupted, a client might -reuse a generation that has already been used, in particular nonce reuse. +reuse a generation that has already been used, causing reuse of a key/nonce pair. To avoid this situation, the sender of a message MUST generate a fresh random 4-byte "reuse guard" value and XOR it with the first four bytes of the nonce From 9bc3c70338c1e72980410717acc6422661dea35e Mon Sep 17 00:00:00 2001 From: Richard Barnes Date: Fri, 7 Feb 2020 15:53:05 -0500 Subject: [PATCH 3/6] Just use the sender data nonce --- draft-ietf-mls-protocol.md | 30 ++++++------------------------ 1 file changed, 6 insertions(+), 24 deletions(-) diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index f939bc7b..0c8d51cf 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -1584,7 +1584,6 @@ object of the following form: struct { uint32 sender; uint32 generation; - opaque reuse_guard[4]; } MLSSenderData; ~~~~~ @@ -1592,10 +1591,6 @@ MLSSenderData.sender is assumed to be a `member` sender type. When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is `member` and use Sender.sender for MLSSenderData.sender. -The `reuse_guard` field contains a fresh random value used to avoid nonce reuse -in the case of state loss or corruption, as described in -{{content-signing-and-encryption}}. - The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely: @@ -1685,25 +1680,12 @@ deterministically, a client must keep persistent state as to where in the key schedule it is; if this persistent state is lost or corrupted, a client might reuse a generation that has already been used, causing reuse of a key/nonce pair. -To avoid this situation, the sender of a message MUST generate a fresh random -4-byte "reuse guard" value and XOR it with the first four bytes of the nonce -from the key schedule before using the nonce for encryption. The sender MUST -include the reuse guard in the `reuse_guard` field of the sender data object, so -that the recipient of the message can use it to compute the nonce to be used for -decryption. - -~~~~~ -+-+-+-+-+---------...---+ -| Key Schedule Nonce | -+-+-+-+-+---------...---+ - XOR -+-+-+-+-+---------...---+ -| Guard | 0 | -+-+-+-+-+---------...---+ - === -+-+-+-+-+---------...---+ -| Encrypt/Decrypt Nonce | -+-+-+-+-+---------...---+ +To avoid this situation, the sender or recipient of a message MUST generate XOR +the nonce from the key schedule with the fresh, random sender data nonce before +using the nonce for encryption. + +~~~~~ +enc_nonce = key_schedule_nonce XOR sender_data_nonce ~~~~~ The Additional Authenticated Data (AAD) input to the encryption From 91c310eec99604763207581ac890ec8aa25f4dbe Mon Sep 17 00:00:00 2001 From: Richard Barnes Date: Fri, 7 Feb 2020 16:13:23 -0500 Subject: [PATCH 4/6] Clarify that sender_data_nonce MUST be fresh --- draft-ietf-mls-protocol.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index 0c8d51cf..d1236181 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -1575,9 +1575,10 @@ The following sections describe the encryption and signing processes in detail. ## Metadata Encryption -The "sender data" used to look up the key for the content encryption -is encrypted under AEAD using the MLSCiphertext sender_data_nonce and -the sender_data_key from the keyschedule. It is encoded as an +The "sender data" used to look up the key for the content encryption is +encrypted under AEAD using the `sender_data_key` from the keyschedule and the +random `sender_data_nonce` noted above. Implementations MUST generate a fresh +random `sender_data_nonce` for each encryption operation. It is encoded as an object of the following form: ~~~~~ From bb805c09523dada5a47bda598f1ae9e9c0f7434a Mon Sep 17 00:00:00 2001 From: Richard Barnes Date: Mon, 17 Feb 2020 12:55:29 -0500 Subject: [PATCH 5/6] Revert "Clarify that sender_data_nonce MUST be fresh" This reverts commit 91c310eec99604763207581ac890ec8aa25f4dbe. --- draft-ietf-mls-protocol.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index d1236181..0c8d51cf 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -1575,10 +1575,9 @@ The following sections describe the encryption and signing processes in detail. ## Metadata Encryption -The "sender data" used to look up the key for the content encryption is -encrypted under AEAD using the `sender_data_key` from the keyschedule and the -random `sender_data_nonce` noted above. Implementations MUST generate a fresh -random `sender_data_nonce` for each encryption operation. It is encoded as an +The "sender data" used to look up the key for the content encryption +is encrypted under AEAD using the MLSCiphertext sender_data_nonce and +the sender_data_key from the keyschedule. It is encoded as an object of the following form: ~~~~~ From a7bd50001dd2a55c92f1e01dfae848ab4874c4b3 Mon Sep 17 00:00:00 2001 From: Richard Barnes Date: Mon, 17 Feb 2020 12:55:39 -0500 Subject: [PATCH 6/6] Revert "Just use the sender data nonce" This reverts commit 9bc3c70338c1e72980410717acc6422661dea35e. --- draft-ietf-mls-protocol.md | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/draft-ietf-mls-protocol.md b/draft-ietf-mls-protocol.md index 0c8d51cf..f939bc7b 100644 --- a/draft-ietf-mls-protocol.md +++ b/draft-ietf-mls-protocol.md @@ -1584,6 +1584,7 @@ object of the following form: struct { uint32 sender; uint32 generation; + opaque reuse_guard[4]; } MLSSenderData; ~~~~~ @@ -1591,6 +1592,10 @@ MLSSenderData.sender is assumed to be a `member` sender type. When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is `member` and use Sender.sender for MLSSenderData.sender. +The `reuse_guard` field contains a fresh random value used to avoid nonce reuse +in the case of state loss or corruption, as described in +{{content-signing-and-encryption}}. + The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely: @@ -1680,12 +1685,25 @@ deterministically, a client must keep persistent state as to where in the key schedule it is; if this persistent state is lost or corrupted, a client might reuse a generation that has already been used, causing reuse of a key/nonce pair. -To avoid this situation, the sender or recipient of a message MUST generate XOR -the nonce from the key schedule with the fresh, random sender data nonce before -using the nonce for encryption. - -~~~~~ -enc_nonce = key_schedule_nonce XOR sender_data_nonce +To avoid this situation, the sender of a message MUST generate a fresh random +4-byte "reuse guard" value and XOR it with the first four bytes of the nonce +from the key schedule before using the nonce for encryption. The sender MUST +include the reuse guard in the `reuse_guard` field of the sender data object, so +that the recipient of the message can use it to compute the nonce to be used for +decryption. + +~~~~~ ++-+-+-+-+---------...---+ +| Key Schedule Nonce | ++-+-+-+-+---------...---+ + XOR ++-+-+-+-+---------...---+ +| Guard | 0 | ++-+-+-+-+---------...---+ + === ++-+-+-+-+---------...---+ +| Encrypt/Decrypt Nonce | ++-+-+-+-+---------...---+ ~~~~~ The Additional Authenticated Data (AAD) input to the encryption