Skip to content
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.

Sign up for GitHub

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

Jump to bottom

IESG Review by Erik Kline #849

Merged
merged 2 commits into from Feb 9, 2023
Merged

IESG Review by Erik Kline #849

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
01d812a
IESG Review by Erik Kline
bifurcation Jan 31, 2023
9630c6b
Update draft-ietf-mls-protocol.md
bifurcation Feb 7, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
17 changes: 11 additions & 6 deletions draft-ietf-mls-protocol.md
View file
Open in desktop
Expand Up @@ -962,7 +962,7 @@ for the new epoch so that it is not known to the removed member.
Note that this does not necessarily imply that any member
is actually allowed to evict other members; groups can
enforce access control policies on top of these
basic mechanism.
basic mechanisms.

~~~ aasvg
Group
Expand Down Expand Up @@ -1874,7 +1874,7 @@ and PrivateContentTBE.

### Content Encryption

Content to be encrypted is encoded in an PrivateContentTBE structure.
Content to be encrypted is encoded in a PrivateContentTBE structure.

~~~ tls
struct {
Expand Down Expand Up @@ -1952,7 +1952,7 @@ struct {
} PrivateContentAAD;
~~~

When decoding an PrivateContentTBE, the application MUST check that the
When decoding a PrivateContentTBE, the application MUST check that the
FramedContentAuthData is valid.

It is up to the application to decide what `authenticated_data` to provide and
Expand Down Expand Up @@ -2165,7 +2165,10 @@ KeyPackage, the `lifetime` field represents the times between which clients will
consider a LeafNode valid. These times are represented as absolute times,
measured in seconds since the Unix epoch (1970-01-01T00:00:00Z). Applications
MUST define a maximum total lifetime that is acceptable for a LeafNode, and
reject any LeafNode where the total lifetime is longer than this duration.
reject any LeafNode where the total lifetime is longer than this duration. In
order to avoid disagreements about whether a LeafNode has a valid lifetime, the
clients in a group SHOULD maintain time synchronization (e.g., using the Network
Time Protocol {{?RFC5905}}).

In the case where the leaf node was inserted into the tree via a Commit message,
the `parent_hash` field contains the parent hash for this leaf node (see
Expand Down Expand Up @@ -2217,7 +2220,9 @@ The client verifies the validity of a LeafNode using the following steps:
* If instead the LeafNode appears in a message being received by the client, e.g.,
a proposal, a commit, or a ratchet tree of the group the client is joining, it is
RECOMMENDED that the client verifies that the current time is within the range
of the `lifetime` field.
of the `lifetime` field. (This check is not required because the LeafNode
bifurcation marked this conversation as resolved.
Show resolved Hide resolved
might have expired in the time between when the message was sent and when it
was received.)

* Verify that the extensions in the LeafNode are supported by checking that the
ID for each extension in the `extensions` field is listed in the
Expand Down Expand Up @@ -4171,7 +4176,7 @@ message at the same time, by taking the following steps:
* Protect the AuthenticatedContent object using keys from the old epoch:
* If encoding as PublicMessage, compute the `membership_tag` value using the
`membership_key`.
* If encoding as an PrivateMessage, encrypt the message using the
* If encoding as a PrivateMessage, encrypt the message using the
`sender_data_secret` and the next (key, nonce) pair from the sender's
handshake ratchet.

Expand Down