Security considerations editorial #229

ekr · 2023-11-08T04:24:58Z

This is intended to tighten up the security considerations section a bit. It's mostly editorial but somewhat substantial changes.

beurdouche

Modulo some small changes this is fine.

beurdouche · 2023-11-08T07:45:27Z

draft-ietf-mls-architecture.md

-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.


This block has been deleted without being dispatched and the title of the next section disappeared as well which seems to be a mistake.

You're right. This is just pilot error. Thanks for catching it.

beurdouche · 2023-11-08T07:49:35Z

draft-ietf-mls-architecture.md

-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.


Suggested change

AEAD key, which is used to protect MLS Plaintext messages.

AEAD key to protect application messages.

I don't think that this is gramatically correct. You don't generate the key to protect the messages.

Please discard : )

beurdouche · 2023-11-08T07:50:29Z

draft-ietf-mls-architecture.md

+Each time a message is sent, the Ratchet Secret is used
+to create a new Ratchet Secret and a new corresponding AEAD key.


Suggested change

Each time a message is sent, the Ratchet Secret is used

to create a new Ratchet Secret and a new corresponding AEAD key.

Implementations can work this way but don't have to. Some implementations derive these in batch.

Well, I think we need to say something in order to explain the security properties. How about

"A new Ratchet Secret is used to generate the AEAD keys for each new message"

That works, yes !

beurdouche · 2023-11-08T07:58:26Z

draft-ietf-mls-architecture.md

-> 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.


I am not sure I agree with removing this. If I was the adversary I would try to collect the ciphertexts and attack some device that has been excluded from the group for not updating enough.

OK. I can live with keeping this.

draft-ietf-mls-architecture.md

Co-authored-by: Benjamin Beurdouche <[email protected]>

rohan-wire

I made a few comments inline that I'd like addressed, especially towards the end of the section. The earlier part of this PR does greatly improve the readability of the section.

draft-ietf-mls-architecture.md

rohan-wire · 2023-11-10T09:39:26Z

draft-ietf-mls-architecture.md

@@ -1700,7 +1701,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.


Add reference for MASQUE

draft-ietf-mls-architecture.md

rohan-wire · 2023-11-10T09:54:21Z

draft-ietf-mls-architecture.md

+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.


Please restore or rewrite the text about injecting a malicious client. I realize that earlier text alludes to that attack, but this is a very practical attack which has been exploited in the wild and we should explicitly call it out.

rohan-wire · 2023-11-10T09:57:18Z

draft-ietf-mls-architecture.md

+> number of notifications is too high, the client should provide a log of
 > state of the device so that the user can examine it.


I think the notifications are about new clients, which "the client" may not have access to. The "public log" might be a ledger generated by the AS for example.

Hmmm..... ISTM that there are two potential things this might be talking about:

Changes to the set of clients in a group.

Changes to the set of clients for a user, whether in a group or not.

I assumed that this text was about the former because of the text "This is especially the case in large groups where the UI might not reflect all the changes back to the users." which is clearly about groups, not the set of clients for a user.

Note that the next recommendation talks about transparency.

rohan-wire · 2023-11-10T10:01:33Z

draft-ietf-mls-architecture.md

-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.


Add back some mention of revocation. Maybe:

"When the credential type support revocation, the users of a group could check for revoked keys, for example for x509 credentials, using a mechanism such as CRLite."

(I don't particularly care if we mention CRLite or some other mechanism, but I think we should say something about revocation.)

Co-authored-by: rohan-wire <[email protected]>

beurdouche · 2024-01-19T13:43:50Z

Approved. Thanks Ekr and Rohan !

ekr added 4 commits November 7, 2023 07:46

First half of security considerations editorial cleanup

751cc91

Revise text around endpoint compromise

a6c6b31

Add masque

1eb839a

Substantially tighten some of the sections

ce18518

ekr requested a review from bifurcation November 8, 2023 04:25

beurdouche requested changes Nov 8, 2023

View reviewed changes

ekr and others added 4 commits November 8, 2023 00:36

Update draft-ietf-mls-architecture.md

674532c

Co-authored-by: Benjamin Beurdouche <[email protected]>

Update draft-ietf-mls-architecture.md

d51b1c5

Co-authored-by: Benjamin Beurdouche <[email protected]>

Restore something I accidentally removed

cc76422

Some of Beurdouche's comments

57ba696

rohan-wire suggested changes Nov 10, 2023

View reviewed changes

rohan-wire mentioned this pull request Nov 10, 2023

Aead key compromise cleanup #230

Merged

ekr and others added 4 commits November 11, 2023 00:38

Apply suggestions from code review

3ad2486

Co-authored-by: rohan-wire <[email protected]>

Apply suggestions from code review

d3d3cfd

Co-authored-by: rohan-wire <[email protected]>

Rowan's review comments

a6d6157

Add MASQUE citation

b7251e7

rohan-wire approved these changes Nov 12, 2023

View reviewed changes

beurdouche merged commit e99caf0 into mlswg:main Jan 19, 2024
1 check passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Security considerations editorial #229

Security considerations editorial #229

ekr commented Nov 8, 2023

beurdouche left a comment

beurdouche Nov 8, 2023

ekr Nov 8, 2023

beurdouche Nov 8, 2023

ekr Nov 8, 2023

beurdouche Nov 8, 2023

beurdouche Nov 8, 2023

beurdouche Nov 8, 2023

ekr Nov 8, 2023

beurdouche Nov 8, 2023

beurdouche Nov 8, 2023

ekr Nov 8, 2023

rohan-wire left a comment

rohan-wire Nov 10, 2023

rohan-wire Nov 10, 2023

rohan-wire Nov 10, 2023

ekr Nov 11, 2023 •

edited

Loading

rohan-wire Nov 10, 2023

beurdouche commented Jan 19, 2024

	AEAD key, which is used to protect MLS Plaintext messages.
	AEAD key to protect application messages.

		Each time a message is sent, the Ratchet Secret is used
		to create a new Ratchet Secret and a new corresponding AEAD key.

		> number of notifications is too high, the client should provide a log of
		> state of the device so that the user can examine it.

Security considerations editorial #229

Security considerations editorial #229

Conversation

ekr commented Nov 8, 2023

beurdouche left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rohan-wire left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ekr Nov 11, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beurdouche commented Jan 19, 2024

ekr Nov 11, 2023 •

edited

Loading