Found 4 records.
Status: Verified (1)
RFC 9420, "The Messaging Layer Security (MLS) Protocol", July 2023
Source of RFC: mls (sec)
Errata ID: 8031
Status: Verified
Type: Editorial
Publication Format(s) : HTML
Reported By: Stefan Schaubeck
Date Reported: 2024-07-15
Verifier Name: RFC Editor
Date Verified: 2024-07-15
Section 7.9 says:
The parent_hash field in ParentHashInput captures information about the nodes above P. the original_sibling_tree_hash captures ...
It should say:
The parent_hash field in ParentHashInput captures information about the nodes above P. The original_sibling_tree_hash captures ...
Notes:
capital letter needed for first word of second sentence (i.e., "The" not "the").
Status: Reported (2)
RFC 9420, "The Messaging Layer Security (MLS) Protocol", July 2023
Source of RFC: mls (sec)
Errata ID: 8745
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Winkelmann
Date Reported: 2026-02-05
Section 13.4 says:
* A client adding a new member to a group MUST verify that the
LeafNode for the new member is compatible with the group's
extensions. The capabilities field MUST indicate support for each
extension in the GroupContext.
It should say:
* A client adding a new member to a group MUST verify that the
LeafNode for the new member is compatible with the group's
extensions. The capabilities field MUST indicate support for each
extension in the GroupContext.
* A client updating a leaf node in the group MUST verify that the
new LeafNode is compatible with the group's extensions. The
capabilities field MUST indicate support for each extension in the
GroupContext. This applies both to Update proposals and LeafNode
objects in the update_path in a Commit.
Notes:
The RFC says on the topic of validating LeafNode capabilities:
> Note that the latter two requirements mean that all
> MLS GroupContext extensions are mandatory, in the
> sense that an extension in use by the group MUST be
> supported by all members of the group.
> --- https://www.rfc-editor.org/rfc/rfc9420.html#section-13.4-6
To that end, it requires that we check that the LeafNodes in KeyPackages
that are added support all extensions in the group context. However, it
doesn't seem to require that the same check is performed for LeafNodes in
Update proposals or update paths.
Also see this thread on the mailing list: https://mailarchive.ietf.org/arch/msg/mls/k18P4FP7dfS2cBmP0kL6Uh50-ok/
Errata ID: 8211
Status: Reported
Type: Editorial
Publication Format(s) : HTML
Reported By: Richard Barnes
Date Reported: 2024-12-11
Section 7.4 says:
If member B subsequently generates an UpdatePath based on a secret "leaf_secret", then it would generate the following sequence of path secrets:
It should say:
If member B subsequently generates an UpdatePath based on a secret "path_secret[0]", then it would generate the following sequence of path secrets:
Notes:
This text is a vestige of an early method of computing path secrets, which started with a fresh leaf_secret instead of a fresh path_secret[0], the latter being clearly specified just above this text.
Figure 14 should also be updated to remove the leaf_secret and the two arrows emerging from it.
Status: Rejected (1)
RFC 9420, "The Messaging Layer Security (MLS) Protocol", July 2023
Source of RFC: mls (sec)
Errata ID: 8032
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Stefan Schaubeck
Date Reported: 2024-07-15
Rejected by: Paul Wouters
Date Rejected: 2024-07-16
Section 7.9.2 says:
... is equal to the resolution of C with D removed.
It should say:
... is equal to the resolution of C with C removed.
Notes:
I think it should be C instead of D, since C is not a leaf node at all and D is an unmerged leaf.
--VERIFIER NOTES--
As per Richard Barnes:
"The resolution of C with C removed" is nonsensical. The only reason C would appear in its own resolution is if the resolution is just [C], in which case removing C yields the empty list. The intent here is correct. If D is non-blank, as this section presumes, then the resolution of C will be [D, D.unmerged_leaves..., stuff_outside_of_subtree_D]. So what this says is that P and D agree on the unmerged leaves under D.