-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disclaim replay protection #271
base: main
Are you sure you want to change the base?
Conversation
As [discussed on the MLS mailing list](https://mailarchive.ietf.org/arch/msg/mls/SRAV33J5Ka9A4R-Ymv8a_T_TXhE/), an attacker with access to the groups symmetric secrets can create a new PrivateMessage containing the content of a previously sent message, and a different generation value. This PR clarifies that this sort of replay is not protected against by the protocol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Proposed a small wording adjustment.
Co-authored-by: Eric Rescorla <[email protected]>
MLS does not provide protections against replay of group messages by members | ||
of the group. Applications for whom replay is an important risk should apply | ||
mitigations at the application layer, as discussed below. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MLS does not provide protections against replay of group messages by members | |
of the group. Applications for whom replay is an important risk should apply | |
mitigations at the application layer, as discussed below. | |
MLS does not protect against one group member replaying a PrivateMessage sent by another | |
group member within the same epoch that the message was originally sent. Similarly, MLS | |
does not protect against the replay (by a group member or otherwise) of a PublicMessage | |
within the same epoch that the message was originally sent. Applications for | |
whom replay is an important risk should apply mitigations at the application layer, as | |
discussed below. |
I feel it's worth saying that replay is only possible within an epoch, and also that PublicMessages can be replayed by anyone (not just a group member) |
ratchet. If the other members of the group interpret a message with a new | ||
generation as a fresh message, then this message will appear fresh. (This is | ||
possible because the message signature does not cover the `generation` field | ||
of the message.) Messages sent as PublicMessages objects similarly lack replay |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of the message.) Messages sent as PublicMessages objects similarly lack replay | |
of the message.) Messages sent as PublicMessage objects similarly lack replay |
In WGLC; see this. |
As discussed on the MLS mailing list, an attacker with access to the groups symmetric secrets can create a new PrivateMessage containing the content of a previously sent message, and a different generation value. This PR clarifies that this sort of replay is not protected against by the protocol.