Draft: draft-ietf-mls-protocol

Commentary: Work in Progress editorial changes .
Paragraph (version A):
A signed object describing a client's identity and capabilities,
and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg-
hpke) public key that can be used to encrypt to that client, and
which other clients can use to introduce the client to a new
group.
Paragraph (version B):
A signed object describing a client's identity and capabilities,
and including a hybrid public-key encryption (HPKE RFC9180) public
key that can be used to encrypt to that client, and which other
clients can use to introduce the client to a new group.
Paragraph (version A):
Each new epoch is initiated with a Commit message.  The Commit
instructs existing members of the group to update their views of
ratchet tree by applying a set of Proposals, and uses the updated
ratchet tree to distribute fresh entropy to the group.  This fresh
entropy is provided only to members in the new epoch, not to members
who have been removed, so it maintains the confidentiality of the
epoch secret (in other words, it provides post-compromise security
with respect to those members).
Paragraph (version B):
Each new epoch is initiated with a Commit message.  The Commit
instructs existing members of the group to update their views of the
ratchet tree by applying a set of Proposals, and uses the updated
ratchet tree to distribute fresh entropy to the group.  This fresh
entropy is provided only to members in the new epoch, not to members
who have been removed, so it maintains the confidentiality of the
epoch secret (in other words, it provides post-compromise security
with respect to those members).
Paragraph (version A):
For each Commit that adds member(s) to the group, there is a
corresponding Welcome message.  The Welcome message provides new
members with the information they need to initialize their views of
the key schedule and ratchet tree, so that these views are equivalent
to the views held by other members of the group in this epoch.
Paragraph (version B):
For each Commit that adds member(s) to the group, there is a single
corresponding Welcome message.  The Welcome message provides all the
new members with the information they need to initialize their views
of the key schedule and ratchet tree, so that these views are
equivalent to the views held by other members of the group in this
epoch.
Paragraph (version A):
A group comprises a single linear sequence of epochs and groups are
generally independent of one-another.  However, it can sometimes be
useful to link epochs cryptographically, either within a group or
across groups.  MLS derives a resumption pre-shared key (PSK) from
each epoch to allow entropy extracted from one epoch to be injected
into a future epoch.  This link guarantees that members entering the
new epoch agree on a key if and only if were members of the group
during the epoch from which the resumption key was extracted.
Paragraph (version B):
A group has a single linear sequence of epochs.  Groups and epochs
are generally independent of one-another.  However, it can sometimes
be useful to link epochs cryptographically, either within a group or
across groups.  MLS derives a resumption pre-shared key (PSK) from
each epoch to allow entropy extracted from one epoch to be injected
into a future epoch.  This link guarantees that members entering the
new epoch agree on a key if and only if they were members of the
group during the epoch from which the resumption key was extracted.
Paragraph (version A):
The conditions under which each of these values must or must not be
present are laid out in views.
Paragraph (version A):
MLS uses HPKE for public-key encryption I-D.irtf-cfrg-hpke.  The
"DeriveKeyPair" function associated to the KEM for the ciphersuite
maps octet strings to HPKE key pairs.  As in HPKE, MLS assumes that
an AEAD algorithm produces a single ciphertext output from AEAD
encryption (aligning with RFC5116), as opposed to a separate
ciphertext and tag.
Paragraph (version B):
MLS uses HPKE for public-key encryption RFC9180.  The "DeriveKeyPair"
function associated to the KEM for the ciphersuite maps octet strings
to HPKE key pairs.  As in HPKE, MLS assumes that an AEAD algorithm
produces a single ciphertext output from AEAD encryption (aligning
with RFC5116), as opposed to a separate ciphertext and tag.
Paragraph (version A):
A BasicCredential is a raw, unauthenticated assertion of an identity/
key binding.  The format of the key in the "public_key" field is
defined by the relevant ciphersuite: the group ciphersuite for a
credential in a leaf node of a ratchet tree or the KeyPackage
ciphersuite for a credential in a KeyPackage object.  For
ciphersuites using Ed25519 or Ed448 signature schemes, the public key
is in the format specified RFC8032.  For ciphersuites using ECDSA
with the NIST curves P-256 or P-521, the public key is the output of
the uncompressed Elliptic-Curve-Point-to-Octet-String conversion
according to SECG.
Paragraph (version B):
A BasicCredential is a raw, unauthenticated assertion of an identity/
key binding.  The format of the key in the "public_key" field is
defined by the relevant ciphersuite: the group ciphersuite for a
credential in a leaf node of a ratchet tree or the KeyPackage
ciphersuite for a credential in a KeyPackage object.  For
ciphersuites using Ed25519 or Ed448 signature schemes, the public key
is in the format specified in RFC8032.  For ciphersuites using ECDSA
with the NIST curves P-256 or P-521, the public key is the output of
the uncompressed Elliptic-Curve-Point-to-Octet-String conversion
according to SECG.
Paragraph (version A):
The Credentials presented by the clients in a group authenticate
application-level identifiers for the clients.  These identifiers may
not uniquely identify clients.  For example, if a user has multiple
devices that are all present in an MLS group, then those devices'
clients will all present the user's application-layer identifiers.
Paragraph (version A):
Internally to the the protocol, group members are uniquely identified
by their leaves, expressed as LeafNodeRef objects.  These identifiers
are unstable: They change whenever the member sends a Commit, or
whenever an Update proposal from the member is committed.
Paragraph (version B):
The Credentials presented by the clients in a group authenticate
application-level identifiers for the clients.  These identifiers may
not uniquely identify clients.  For example, if a user has multiple
devices that are all present in an MLS group, then those devices'
clients could all present the user's application-layer identifiers.
Paragraph (version B):
Internally to the protocol, group members are uniquely identified by
their leaves, expressed as LeafNodeRef objects.  These identifiers
are unstable: They change whenever the member sends a Commit, or
whenever an Update proposal from the member is committed.
Paragraph (version A):
where "node_public_key" is the public key of the node that the path
secret is being encrypted for, group_context is the current
GroupContext object for the group, and the functions "SetupBaseS" and
"Seal" are defined according to I-D.irtf-cfrg-hpke.
Paragraph (version B):
where "node_public_key" is the public key of the node that the path
secret is being encrypted for, group_context is the current
GroupContext object for the group, and the functions "SetupBaseS" and
"Seal" are defined according to RFC9180.