-
Notifications
You must be signed in to change notification settings - Fork 28
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
Aead key compromise cleanup #230
Conversation
Secret compromise. I mostly moved stuff around and deleted redundant text, but hopefully it will be clearer.
This builds on PR#229, so that should be reviewed first. |
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.
Let's finish PR #229 first, then merge that update into this one. I don't think it is possible to review this PR yet because of the overlapping changes with the other PR.
draft-ietf-mls-architecture.md
Outdated
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 |
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.
This looks like a mistake. was the intention to delete the entire Non-repudiation vs Deniability discussion?
And then the "Associating a User's Clients" section heading is removed and the second sentence of that section is now under the previous heading???
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.
Pilot error. This is fixed in #229, so when that PR is done i will rebase.
Co-authored-by: rohan-wire <[email protected]>
draft-ietf-mls-architecture.md
Outdated
@@ -1089,7 +1089,7 @@ interoperate. | |||
is useful for clients that do not have the ability to send the full public | |||
state in a Welcome message when inviting auser or for client that need to | |||
recover from a loss of their state. Such public state can contain privacy | |||
sensitive information such as group members' credentials and related public | |||
sensitive information such as group members' credentrials and related public |
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.
sensitive information such as group members' credentrials and related public | |
sensitive information such as group members' credentials and related public |
No description provided.