Draft: draft-ietf-mls-protocol

Commentary: Comment by I personally do n't like the underscored words in the html rendering of the document It " blank " the new American spelling of " blanc " ? I find " summarizes " a strange word here . It is not the hash contains a summary one can read . [ SECG ] has no IETF equivalent ? Should it ? proposaland -proposal and I would say " after removing member C " ( avoid ambiguity about " every third " ) I read this wrong the first way , the " , " vanishes due to the unscores . Maybe : This section defines tree hashes , the next section defines parent hashes . Or alternatively , leave onlthe the first sentence in 8.8 , then put the remainder and next section in two subsections ( so 8.8.1 and 8.8.2 ) Maybe : For example , a malicious group member could otherwise send Maybe : to public keys whose private key was previously compromised . This reads a little odd as " new groups " would have no history and thus no previous compromise . 
 Filed I think it 's important to emphasize the terms being defined , and this seems more readable than a definition list . Note that a hash function is often called a " message digest " , in the same sense as the " Weekly github digest " that goes to the mailing list . I think referring to  is still pretty state - of - the - art . But apparently RFC 8446 moved on from that , so I updated to use that representation .
Paragraph (version A):
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, P-384, 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):
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, P-384, or P-521), the public key
is represented as an encoded UncompressedPointRepresentation struct,
as defined in RFC8446.
Paragraph (version A):
"new_member_proposal": The signature key in the LeafNode in the
KeyPackage embedded in an External Add Proposal.  The
"content_type" of the message MUST be "proposal"and the
"proposal_type" of the Proposal MUST be "add".
Paragraph (version B):
"new_member_proposal": The signature key in the LeafNode in the
KeyPackage embedded in an External Add Proposal.  The
"content_type" of the message MUST be "proposal" and the
"proposal_type" of the Proposal MUST be "add".
Paragraph (version A):
MLS hashes the contents of the tree in two ways to authenticate
different properties of the tree.  This section defines _tree
hashes_, and _parent hashes_ are defined in parent-hashes.
Paragraph (version B):
MLS hashes the contents of the tree in two ways to authenticate
different properties of the tree.  _Tree hashes_ are defined in this
section, and _parent hashes_ are defined in parent-hashes.
Paragraph (version A):
perform billions of key derivations.
Paragraph (version B):
perform billions of key derivations unless they apply limits of the
type discussed above.
Paragraph (version A):
Post-compromise security is provided between epochs by members
regularly updating their leaf key in the ratchet tree.  Updating
their leaf key prevents group secrets from continuing to be encrypted
to previously compromised public keys.
Paragraph (version B):
Post-compromise security is provided between epochs by members
regularly updating their leaf key in the ratchet tree.  Updating
their leaf key prevents group secrets from continuing to be encrypted
to public keys whose private keys had previously been compromised.
Paragraph (version A):
Post-compromise security is also provided for new groups by members
regularly generating new KeyPackages and uploading them to the
Delivery Service, such that compromised key material won't be used
when the member is added to a new group.
Paragraph (version B):
New groups are also at risk of using previously compromised keys (as
with post-compromise security), if a member is added to a new group
via an old KeyPackage whose corresponding private key has been
compromised.  This risk can be mitigated by having clients regularly
generate new KeyPackages and upload them to the Delivery Service.
This way, the key material used to add a member to a new group is
more likely to be fresh and less likely to be compromised.