From 751cc9163f36bed08e1223f23e26f4256c729424 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Nov 2023 07:46:52 -0800 Subject: [PATCH 01/12] First half of security considerations editorial cleanup --- draft-ietf-mls-architecture.md | 68 +++++++++++++++++----------------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index c3d8567..fd8c8df 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1199,44 +1199,42 @@ interoperability: # Security and Privacy Considerations -MLS adopts the Internet threat model {{?RFC3552}} and therefore assumes that the -attacker has complete control of the network. It is intended to provide the -security services described in the face of such attackers. +MLS adopts the Internet threat model {{?RFC3552}} and therefore +assumes that the attacker has complete control of the network. It is +intended to provide the security services described in +{{intended-security-guarantees}} in the face of attackers who can: -- The attacker can monitor the entire network. +- Monitor the entire network. -- The attacker can read unprotected messages. +- Read unprotected messages. -- The attacker can generate, inject and delete any message in the unprotected +- Can generate, inject and delete any message in the unprotected transport layer. +While MLS should be run over a secure transport such as QUIC +{{?RFC9000}} or TLS {{?RFC8446}}, the security guarantees of MLS do +not depend on the transport. This departs from the usual design +practice of trusting the transport because MLS is designed to +provide security even in the face of compromised network +elements, especially the DS. + +Generally, MLS is designed under the +assumption that the transport layer is present to keep metadata +private from network observers, while the MLS protocol provides +confidentiality, integrity, and authentication guarantees for the +application data (which could pass through multiple +systems). Additional properties such as partial anonymity or +deniability could also be achieved in specific architecture designs. + In addition, these guarantees are intended to degrade gracefully in the presence of compromise of the transport security links as well as of both clients and elements of the messaging system, as described in the remainder of this section. -Generally, MLS is designed under the assumption that the transport layer is -present to keep metadata private from network observers, while the MLS protocol provides confidentiality, -integrity, and authentication guarantees for the application data (which could pass -through multiple systems). Additional properties such as partial anonymity or deniability could also be -achieved in specific architecture designs. ## Assumptions on Transport Security Links As discussed above, MLS provides the highest level of security when its messages -are delivered over an encrypted transport. Any secure channel, -such as QUIC {{?RFC9000}}, TLS {{?RFC8446}}, can be used to -transport MLS messages. -However, the MLS protocol is designed to consider the following -threat-model: - -- The attacker can read, write, and delete arbitrary messages inside the secure - transport channel. - -This departs from most threat models where we consider that the secure channel -used for transport always provides secrecy. The reason for this consideration is -that in the group setting, active malicious insiders or adversarial services are -to be considered. - +are delivered over an encrypted transport. The main use of the secure transport layer for MLS is to protect the already limited amount of metadata. Very little information is contained in the unencrypted header of the MLS protocol message format for group operation @@ -1261,8 +1259,9 @@ metadata if it cannot compromise the secure channel. ### Integrity and Authentication of Custom Metadata -The MLS protocol provides an authenticated "Additional Authenticated Data" field -for applications to make data available outside a PrivateMessage. +MLS provides an authenticated "Additional Authenticated Data" (AAD) field +for applications to make data available outside a PrivateMessage, while +cryptographically binding it to the message. > **RECOMMENDATION:** Use the "Additional Authenticated Data" field of the > PrivateMessage instead of using other unauthenticated means of sending @@ -1406,13 +1405,14 @@ the scope of this document. ### Non-Repudiation vs Deniability {#Non-Repudiation-vs-Deniability} -MLS provides strong authentication within a group, such that a group member -cannot send a message that appears to be from another group member. -Additionally, some services require that a recipient be able to prove to the -service provider that a message was sent by a given client, in order to report -abuse. MLS supports both of these use cases. In some deployments, these services -are provided by mechanisms which allow the receiver to prove a message's origin -to a third party. This is often called "non-repudiation". +MLS messages are signed, preventing a group member from sending a +message that appears to be from another group member. Additionally, +some services require that a recipient be able to prove to the service +provider that a message was sent by a given client, in order to report +abuse. MLS supports both of these use cases. In some deployments, +these services are provided by mechanisms which allow the receiver to +prove a message's origin to a third party. This is often called +"non-repudiation". Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., the property that it is impossible to prove to a third party that a message was sent From a6c6b31eb04023700f018cba9dbb7d72c6900b2b Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Nov 2023 11:13:29 -0800 Subject: [PATCH 02/12] Revise text around endpoint compromise --- draft-ietf-mls-architecture.md | 89 +++++++++++++--------------------- 1 file changed, 35 insertions(+), 54 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index fd8c8df..c68b9b8 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1405,26 +1405,6 @@ the scope of this document. ### Non-Repudiation vs Deniability {#Non-Repudiation-vs-Deniability} -MLS messages are signed, preventing a group member from sending a -message that appears to be from another group member. Additionally, -some services require that a recipient be able to prove to the service -provider that a message was sent by a given client, in order to report -abuse. MLS supports both of these use cases. In some deployments, -these services are provided by mechanisms which allow the receiver to -prove a message's origin to a third party. This is often called -"non-repudiation". - -Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., the -property that it is impossible to prove to a third party that a message was sent -by a given sender. MLS does not make any claims with regard to deniability. It -may be possible to operate MLS in ways that provide certain deniability -properties, but defining the specific requirements and resulting notions of -deniability requires further analysis. - -### Associating a User's Clients - -When the same user uses multiple clients, it may be possible for other members -of a group to recognize all of those clients as belonging to the same user. For example, all of a user's clients might present credentials authenticating the user's identity. This association among devices might be considered a leak of private information. The remainder of this section describes several approaches @@ -1474,14 +1454,17 @@ the following compromise scenarios: The MLS protocol provides per-sender chains of symmetric authenticated encryption with additional data (AEAD) {{!RFC5116}} keys that are -generated from Group Secrets. These keys are used to protect MLS -Plaintext messages which can be Group Operation or Application -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. +generated from Group Secrets. Specifically, each epoch establishes +a per-sender "Ratchet Secret", which is then used to generate an +AEAD key, which is used to protect MLS Plaintext messages. +Each time a message is sent, the Ratchet Secret is used +to create a new Ratchet Secret and a new corresponding AEAD key. +Because of the properties of the key derivation function, it is +not possible to compute a Ratchet Secret from its corresponding +AEAD key or compute Ratchet Secret n-1 from Ratchet Secret n. -### Compromise of Application Ratchet 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 @@ -1541,26 +1524,28 @@ compromised, which can occur if the attacker has access to part of the memory containing the group secrets but not to the signature keys which might be stored in a secure enclave. -In this scenario, the adversary gains the ability to compute any number of AEAD -encryption keys for any AEAD chains and can encrypt and decrypt all messages for -the compromised epochs. +In this scenario, the adversary gains the ability to compute any +number of Ratchet Secrets for the epoch and their corresponding AEAD +encryption keys and thus can encrypt and decrypt all messages for the +compromised epochs. If the adversary is passive, it is expected from the PCS properties of the MLS protocol that, as soon as the compromised party remediates the compromise and sends an honest Commit message, the next epochs will provide message secrecy. -If the adversary is active, the adversary can follow the protocol and perform -updates on behalf of the compromised party with no ability for an honest group -to recover message secrecy. However, MLS provides PCS against active adaptive -attackers through its Remove group operation. This means that, as long as other -members of the group are honest, the protocol will guarantee message secrecy for -all messages exchanged in the epochs after the compromised party has been +If the adversary is active, the adversary can engage in the protocol +itself and perform updates on behalf of the compromised party with no +ability for an honest group to recover message secrecy. However, MLS +provides PCS against active adaptive attackers through its Remove +group operation. This means that, as long as other members of the +group are honest, the protocol will guarantee message secrecy for all +messages exchanged in the epochs after the compromised party has been removed. ### Compromise by an active adversary with the ability to sign messages -Under such a scenario, where an active adversary has compromised an MLS client, -two different settings emerge. In the strongest compromise scenario, the +If an active adversary has compromised an MLS client and can sign +messages, two different settings emerge. In the strongest compromise scenario, the attacker has access to the signing key and can forge authenticated messages. In a weaker, yet realistic scenario, the attacker has compromised a client but the client signature keys are protected with dedicated hardware features which do @@ -1595,18 +1580,19 @@ client in both cases. There is a significant difference, however in terms of recovery after a compromise. -Because of the PCS guarantees provided by the MLS protocol, when a previously -compromised client performs an honest Commit which is not under the control of -the adversary, both secrecy and authentication of messages can be recovered in -the case where the attacker didn't get access to the key. Because the adversary -doesn't have the key and has lost the ability to sign messages, they cannot -authenticate messages on behalf of the compromised party, even if they still -have control over some group keys by colluding with other members of the group. +Because of the PCS guarantees provided by the MLS protocol, when a +previously compromised client recovers from compromise and performs an +honest Commit, both secrecy and authentication of future messages can +be recovered as long as the attacker doesn't otherwise get access to +the key. Because the adversary doesn't have the signing key, they +cannot authenticate messages on behalf of the compromised party, even +if they still have control over some group keys by colluding with +other members of the group. -This is in contrast with the case where the signature key is leaked. In that -case PCS of the MLS protocol will eventually allow recovery of the -authentication of messages for future epochs but only after compromised parties -refresh their credentials securely. +This is in contrast with the case where the signature key is leaked. In that +case the compromised endpoint needs to refresh its credentials and invalidate +the old credentials before the attacker will be unable to authenticate +messages. Beware that in both oracle and private key access, an active adaptive attacker can follow the protocol and request to update its own credential. This in turn @@ -1636,12 +1622,7 @@ application to instruct the protocol implementation. > **RECOMMENDATION:** If the threat model of the system is against an adversary > which can access the messages on the device without even needing to attack -> MLS, the application should delete plaintext messages and ciphertexts -> as soon as practical after encryption or decryption. - -Even though, from the strict point of view of the security formalization, a -ciphertext is always public and will forever be, there is no loss in trying to -erase ciphertexts as much as possible. +> MLS, the application should delete plaintext messages. Note that this document makes a clear distinction between the way signature keys and other group shared secrets must be handled. In particular, a large set of From 1eb839ab728d9850f7ccf7174da6cb95f6c97cff Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Nov 2023 11:22:44 -0800 Subject: [PATCH 03/12] Add masque --- draft-ietf-mls-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index c68b9b8..5400205 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1681,7 +1681,7 @@ the IP address and depending on the protocol the MAC address of the device. Similar concerns exist in the peer-to-peer use cases of MLS. > **RECOMMENDATION:** In the case where privacy or anonymity is important, using -> adequate protection such as TOR or a VPN can improve metadata protection. +> adequate protection such as MASQUE, ToR, or a VPN can improve metadata protection. More generally, using anonymous credentials in an MLS based architecture might not be enough to provide strong privacy or anonymity properties. From ce18518805403d31f3d7a9828d342733293627e4 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 7 Nov 2023 20:23:37 -0800 Subject: [PATCH 04/12] Substantially tighten some of the sections --- draft-ietf-mls-architecture.md | 55 +++++++++++++++------------------- 1 file changed, 24 insertions(+), 31 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 5400205..b1e4cd7 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1797,46 +1797,46 @@ emitted credentials might be compromised. #### Authentication compromise: Ghost users and impersonations -One important feature of MLS is that all Members know which other members are in +One important property of MLS is that all Members know which other members are in the group at all times. If all Members of the group and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group. +This guarentee applies to the the cryptographic identities of the members, +but these identities need to be bound to people in the physical world. Details about how to verify the identity of a client depend on the MLS Credential type used. For example, cryptographic verification of credentials can -be largely performed autonomously (e.g. without user interaction) by +be largely performed autonomously (e.g., without user interaction) by the clients themselves for the `x509` Credential -type. In contrast, when MLS clients use the `basic` Credential type, a larger -degree of trust must be placed in a (likely) centralized authentication -resource, or on out-of-band processes such as manual verification. +type. + +In contrast, when MLS clients use the `basic` Credential type, then some +other mechanism must be used to verify identities. For instance the Authentication +Service could operate some sort of directory server to provide keys, +or users could potentially verify keys via some out-of-band mechanism. > **RECOMMENDATION:** Select the strongest MLS Credential type available among > the target members of an MLS group. -If the AS is compromised, it could validate a (or generate a new) signature -keypair for an attacker. Because a user can have many MLS clients running the -MLS protocol, it possibly has many signature keypairs for multiple -devices. These attacks could be very difficult to detect. - -> **RECOMMENDATION:** Provide a key transparency mechanism for the -> Authentication Services to allow public verification of the credentials -> authenticated by this service. - -Note that when a `basic` Credential is used, the Authentication Service also -needs an out-of-band mechanism to verify the identity asserted in the -Credential. - -In the case where an adversarial keypair is generated for a specific identity, -an infrastructure without any transparency mechanism or out-of-band -authentication mechanism could inject a malicious client into a group by -impersonating a user. This is especially the case in large groups where the UI -might not reflect all the changes back to the users. +If the AS is compromised, it could validate a (or generate a new) +signature keypair for an attacker. Because a user can have many MLS +clients running the MLS protocol, it possibly has many signature +keypairs for multiple devices. These attacks could be very difficult +to detect, especially in large groups where the UI might not reflect +all the changes back to the users. If the application participates in +a key transparency mechanism in which it is possible to determine +every key for a given user, then this then this would allow for the +detection of surreptitiously created false credentials. > **RECOMMENDATION:** Make sure that MLS clients reflect all the membership > changes to the users as they happen. If a choice has to be made because the -> number of notifications is too high, a public log should be maintained of the +> number of notifications is too high, the client should provide a log of > state of the device so that the user can examine it. +> **RECOMMENDATION:** Provide a key transparency mechanism for the +> Authentication Services to allow public verification of the credentials +> authenticated by this service. + While the ways to handle MLS credentials are not defined by the protocol or the architecture documents, the MLS protocol has been designed with a mechanism that can be used to provide out-of-band authentication to users. The @@ -1845,13 +1845,6 @@ one-time, per client, authentication secret which can be exchanged between users to prove their identity to each other. This can be done for instance using a QR code that can be scanned by the other parties. -Another way to improve the security for the users is to provide a transparency -mechanism which allows each user to check if credentials used in groups have -been published in the transparency log. Another benefit of this mechanism is for -revocation. The users of a group could check for revoked keys (in case of -compromise detection) using a mechanism such as CRLite or some more advanced -privacy preserving technology. - > **RECOMMENDATION:** Provide one or more out-of-band authentication > mechanisms to limit the impact of an Authentication Service compromise. From 674532caa2603aa4f69ba3d21806bb1b8144a362 Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Wed, 8 Nov 2023 00:36:04 -0800 Subject: [PATCH 05/12] Update draft-ietf-mls-architecture.md Co-authored-by: Benjamin Beurdouche --- draft-ietf-mls-architecture.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index b1e4cd7..5632105 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1802,8 +1802,7 @@ the group at all times. If all Members of the group and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group. -This guarentee applies to the the cryptographic identities of the members, -but these identities need to be bound to people in the physical world. +This guarentee applies to the the cryptographic identities of the members. Details about how to verify the identity of a client depend on the MLS Credential type used. For example, cryptographic verification of credentials can be largely performed autonomously (e.g., without user interaction) by From d51b1c5e0aa2bcaa050616f9299ddf677f0ee83c Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Wed, 8 Nov 2023 00:36:15 -0800 Subject: [PATCH 06/12] Update draft-ietf-mls-architecture.md Co-authored-by: Benjamin Beurdouche --- draft-ietf-mls-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 5632105..3433bf6 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1812,7 +1812,7 @@ type. In contrast, when MLS clients use the `basic` Credential type, then some other mechanism must be used to verify identities. For instance the Authentication Service could operate some sort of directory server to provide keys, -or users could potentially verify keys via some out-of-band mechanism. +or users could verify keys via an out-of-band mechanism. > **RECOMMENDATION:** Select the strongest MLS Credential type available among > the target members of an MLS group. From cc76422f21cd4252d30ee2519a723481a07a8cad Mon Sep 17 00:00:00 2001 From: EKR Date: Wed, 8 Nov 2023 01:01:45 -0800 Subject: [PATCH 07/12] Restore something I accidentally removed --- draft-ietf-mls-architecture.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 3433bf6..8bbef7f 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1405,6 +1405,27 @@ the scope of this document. ### Non-Repudiation vs Deniability {#Non-Repudiation-vs-Deniability} + +MLS provides strong authentication within a group, such that a group member +cannot send a message that appears to be from another group member. +Additionally, some services require that a recipient be able to prove to the +service provider that a message was sent by a given client, in order to report +abuse. MLS supports both of these use cases. In some deployments, these services +are provided by mechanisms which allow the receiver to prove a message's origin +to a third party. This is often called "non-repudiation". + +Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., the +property that it is impossible to prove to a third party that a message was sent +by a given sender. MLS does not make any claims with regard to deniability. It +may be possible to operate MLS in ways that provide certain deniability +properties, but defining the specific requirements and resulting notions of +deniability requires further analysis. + + +### Associating a User's Clients + +When the same user uses multiple clients, it may be possible for other members +of a group to recognize all of those clients as belonging to the same user. For example, all of a user's clients might present credentials authenticating the user's identity. This association among devices might be considered a leak of private information. The remainder of this section describes several approaches From 57ba696f94b254cfe0e79102d4fd995380696aeb Mon Sep 17 00:00:00 2001 From: EKR Date: Wed, 8 Nov 2023 01:02:52 -0800 Subject: [PATCH 08/12] Some of Beurdouche's comments --- draft-ietf-mls-architecture.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 8bbef7f..b0d9fa2 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1478,9 +1478,8 @@ encryption with additional data (AEAD) {{!RFC5116}} keys that are generated from Group Secrets. Specifically, each epoch establishes a per-sender "Ratchet Secret", which is then used to generate an AEAD key, which is used to protect MLS Plaintext messages. -Each time a message is sent, the Ratchet Secret is used -to create a new Ratchet Secret and a new corresponding AEAD key. -Because of the properties of the key derivation function, it is +A new Ratchet Secret generated and is used to generate the AEAD keys for each +message. Because of the properties of the key derivation function, it is not possible to compute a Ratchet Secret from its corresponding AEAD key or compute Ratchet Secret n-1 from Ratchet Secret n. @@ -1643,7 +1642,7 @@ application to instruct the protocol implementation. > **RECOMMENDATION:** If the threat model of the system is against an adversary > which can access the messages on the device without even needing to attack -> MLS, the application should delete plaintext messages. +> MLS, the application should delete plaintext and ciphertext messages. Note that this document makes a clear distinction between the way signature keys and other group shared secrets must be handled. In particular, a large set of From 3ad2486ce6961c82948d102a6f71589dedfcc8a4 Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Sat, 11 Nov 2023 00:38:08 -0800 Subject: [PATCH 09/12] Apply suggestions from code review Co-authored-by: rohan-wire <91096103+rohan-wire@users.noreply.github.com> --- draft-ietf-mls-architecture.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index b0d9fa2..958d05d 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1478,7 +1478,7 @@ encryption with additional data (AEAD) {{!RFC5116}} keys that are generated from Group Secrets. Specifically, each epoch establishes a per-sender "Ratchet Secret", which is then used to generate an AEAD key, which is used to protect MLS Plaintext messages. -A new Ratchet Secret generated and is used to generate the AEAD keys for each +A new Ratchet Secret is generated and is used to generate the AEAD keys for each message. Because of the properties of the key derivation function, it is not possible to compute a Ratchet Secret from its corresponding AEAD key or compute Ratchet Secret n-1 from Ratchet Secret n. @@ -1642,7 +1642,8 @@ application to instruct the protocol implementation. > **RECOMMENDATION:** If the threat model of the system is against an adversary > which can access the messages on the device without even needing to attack -> MLS, the application should delete plaintext and ciphertext messages. +> MLS, the application should delete plaintext and ciphertext messages +> as soon as practical after encryption or decryption. Note that this document makes a clear distinction between the way signature keys and other group shared secrets must be handled. In particular, a large set of From d3d3cfd3fb7f817d892d1126893dbf9034239cad Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Sat, 11 Nov 2023 00:39:01 -0800 Subject: [PATCH 10/12] Apply suggestions from code review Co-authored-by: rohan-wire <91096103+rohan-wire@users.noreply.github.com> --- draft-ietf-mls-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 958d05d..5540202 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1823,7 +1823,7 @@ the group at all times. If all Members of the group and the Authentication Service are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that Group. -This guarentee applies to the the cryptographic identities of the members. +This guarantee applies to the the cryptographic identities of the members. Details about how to verify the identity of a client depend on the MLS Credential type used. For example, cryptographic verification of credentials can be largely performed autonomously (e.g., without user interaction) by From a6d6157c8a2f086a14bf77075dc8063cf7c91e85 Mon Sep 17 00:00:00 2001 From: EKR Date: Sat, 11 Nov 2023 00:43:03 -0800 Subject: [PATCH 11/12] Rowan's review comments --- draft-ietf-mls-architecture.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 5540202..6b999de 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1589,6 +1589,9 @@ generate messages which look valid to other members of the group and to the infrastructure as they need to have access to group secrets to compute the encryption keys or the membership tag. + + + ### Compromise of the authentication with access to a signature key The difference between having access to the value of the signature key and only @@ -1625,6 +1628,9 @@ provider. > features to allow recovery of the authentication for future messages after a > compromise. +> **RECOMMENDATION:** When the credential type supports revocation, +> the users of a group should check for revoked keys. + ### Security consideration in the context of a full state compromise In real-world compromise scenarios, it is often the case that adversaries target @@ -1839,7 +1845,9 @@ or users could verify keys via an out-of-band mechanism. > the target members of an MLS group. If the AS is compromised, it could validate a (or generate a new) -signature keypair for an attacker. Because a user can have many MLS +signature keypair for an attacker. The attacker could then use this +keypair to join a group as if it were another of the user's clients. +Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices. These attacks could be very difficult to detect, especially in large groups where the UI might not reflect From b7251e7855667874a5705df3a756373ba11cc5d1 Mon Sep 17 00:00:00 2001 From: EKR Date: Sat, 11 Nov 2023 00:44:44 -0800 Subject: [PATCH 12/12] Add MASQUE citation --- draft-ietf-mls-architecture.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 6b999de..e8ec377 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1707,8 +1707,10 @@ the IP address and depending on the protocol the MAC address of the device. Similar concerns exist in the peer-to-peer use cases of MLS. -> **RECOMMENDATION:** In the case where privacy or anonymity is important, using -> adequate protection such as MASQUE, ToR, or a VPN can improve metadata protection. +> **RECOMMENDATION:** In the case where privacy or anonymity is +> important, using adequate protection such as MASQUE +> {{?I-D.schinazi-masque-proxy}}, ToR, or a VPN can improve metadata +> protection. More generally, using anonymous credentials in an MLS based architecture might not be enough to provide strong privacy or anonymity properties.