Draft: draft-ietf-mls-protocol

Commentary: This PR : consolidates instructions on which key should be used to compute ( and verify ) a signature on an MLS message depending on the sender type reverts introduces a extension that ensures that group members agree on preconfigured signature keys , as discussed in and on the mailing list 
 As , the current preconfigured sender mechanism is n't interoperably specified . There is no confirmation that the members of a group agree on who the allowed preconfigured senders are , so different members might respond differently . It seems like there are two options here : the required details . We would need a extension to confirm agreement to use the mechanism at all , and would probably need to have a list of senders there as well . the feature from the base protocol . Since an extension is required in any case , there 's no pressing need to have the feature in the base protocol . Personally , I would lean toward ( 2 ) . Early deployment experience does n't show a lot of need for this feature . For example , in Webex , we just have the server forward a KeyPackage instead of synthesizing an Add proposal under a preconfigured signer ; the TLS authentication is as good as a preconfigured signer signature . As long as the SenderType enum is around , the extension should be a small follow - on spec if it is really needed . 
 and I would probably prefer the first option . I will write up a more detailed reason and post to the mailing list , but the TLDR is basically that in a really long session in async messaging , server driven proposals save you from some painful logic , and the extension would improve this to allow for interop / federation cases . 
 I am pretty clearly in favor of option 1 . Pre - configured senders are playing a key role for us in implementing automation of backend - initiated changes to the group . Things like : initiating the removal of  ( 's phone ) because his account ( or device ) was deprovisioned . announcing a change to the group 's properties due to system wide policy changes . Having an audit trail ( i.e. the preconfigured sender 's signature on the proposal ) makes this a lot easier for the group to authenticate why this action is being committed to by group members . ( Also , external commits are not a good alternative as they have the unwanted side - effect of the preconfigured sender learning the new epoch 's key schedule . ) As for how to agree on preconfigured sender public keys , I think a minimal solution could be to have a list of preconfigured sender public keys as a group context extension . We already have a mechanism to change it during the life time of the group ( via groupcontextextensions proposal ) so its a pretty small change to the the RFC . 
 Thanks  , that covers my feedback as well , no need for mailing list follow up 
 That sounds fine to me . want to write up a PR ? It seems like something of the following form : The idea being that BasicCredential already has the ( i d , public key ) pair that you would need , so you would just need to say that when , is the field from the corresponding BasicCredential . ( Also probably rename to . ) 
 Or actually , you could do things even more simply by just having the extension be a list of , and having be a index into the array . 
 Ok no problem . I 'll take a look today and propose something and we can iterate 
 What do you think about it just being credential instead of basic credential ? 
 I had the same thought . Since I kicked off the discussion , I felt the need to take a stab at closing it and I included the input from this threat and the list . See . My main goal was to consolidate the instructions on signature computation and verification and I thought I might as well deal with the preconfigured senders as well . Let me know if you want to take your own stab at the preconfigured senders extension and I 'll remove that part from the PR . 
 Thanks , glad I put this off until now :-) I 'll take a look at your PR 
 Here 's the Weekly Digest for : - - Last week 3 issues were created . Of these , 0 issues have been closed and 3 issues are still open . : greenheart : , by : greenheart : , by : greenheart : , by - - Last week , 4 pull requests were created , updated or merged . Last week , 3 pull requests were updated . : yellowheart : , by : yellowheart : , by : yellowheart : , by Last week , 1 pull request was merged . : purpleheart : , by - - Last week there was 1 commit . : hammerandwrench : by - - Last week there was 1 contributor . : bustin_silhouette : - - Last week there were no stargazers . - - Last week there were no releases . - - That 's all for last week , please < kbd : eyes : Watch</kbdand < kbd : star : Star</kbdthe repository to receive next weekly updates . : smiley : You can also . 
 Thanks for tackling this , looks good
Paragraph (version A):
The "signature" field in an MLSMessageAuth object is computed using
the signing private key corresponding to the public key, which was
authenticated by the credential at the leaf of the tree indicated by
the sender field.  The signature is computed using "SignWithLabel"
with label ""MLSMessageContentTBS"" and with a content that covers
the message content and the wire format that will be used for this
message.  If the sender is a member of the group, the content also
covers the GroupContext for the current epoch, so that signatures are
specific to a given group and epoch.
Paragraph (version B):
The signature is computed using "SignWithLabel" with label
""MLSMessageContentTBS"" and with a content that covers the message
content and the wire format that will be used for this message.  If
the sender's "sender_type" is "Member", the content also covers the
GroupContext for the current epoch, so that signatures are specific
to a given group and epoch.
Paragraph (version B):
"external": The signature key contained in the Credential at the
index indicated by the "sender_index" in the "external_senders"
group context extension (see Section external-senders-extension).
In this case, the "content_type" of the message MUST NOT be
"commit", since only members of the group or new joiners can send
Commit messages.
Paragraph (version B):
"proposal": The signature key in the credential contained in
KeyPackage in the Add proposal (see Section external-
proposals).
Paragraph (version B):
"commit": The signature key in the credential contained in the
KeyPackage in the Commit's path (see Section external-
initialization).
Paragraph (version B):
Recipients of an MLSMessage MUST verify the signature with the key
depending on the "sender_type" of the sender as described above.
Paragraph (version A):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
might propose to remove a member of a group who has been inactive for
a long time, or propose adding a newly-hired staff member to a group
representing a real-world team.  Proposals originating outside the
group are identified by a "preconfigured" or "new_member" SenderType
in MLSPlaintext.
Paragraph (version A):
ReInit proposals can also be sent to the group by a "preconfigured"
sender, for example to enforce a changed policy regarding MLS version
or ciphersuite.
Paragraph (version B):
Add and Remove proposals can be constructed and sent to the group by
a party that is outside the group.  For example, a Delivery Service
might propose to remove a member of a group who has been inactive for
a long time, or propose adding a newly-hired staff member to a group
representing a real-world team.  Proposals originating outside the
group are identified by a "external" or "new_member" SenderType in
MLSPlaintext.
Paragraph (version B):
ReInit proposals can also be sent to the group by a "external"
sender, for example to enforce a changed policy regarding MLS version
or ciphersuite.
Paragraph (version A):
The "preconfigured" SenderType is reserved for signers that are pre-
provisioned to the clients within a group.  If proposals with these
sender IDs are to be accepted within a group, the members of the
group MUST be provisioned by the application with a mapping between
these IDs and authorized signing keys.  Recipients MUST verify that
the MLSPlaintext carrying the Proposal message is validly signed with
the corresponding key.  To ensure consistent handling of external
proposals, the application MUST ensure that the members of a group
have the same mapping and apply the same policies to external
proposals.
Paragraph (version B):
The "external" SenderType is reserved for signers that are pre-
provisioned to the clients within a group.  It can only be used if
the "external_senders" extension is present in the group's group
context extensions.
Paragraph (version B):
The "external_senders" extension is a group context extension that
contains credentials of senders that are permitted to send external
proposals to the group.
Paragraph (version A):
Verify that the signature on the MLSMessageContent message
verifies using the public key from the credential stored at the
leaf in the tree indicated by the "sender" field.
Paragraph (version B):
Verify that the signature on the MLSMessageContent message as
described in Section content-authentication.