Draft: draft-ietf-mls-protocol

Commentary: cc 
 Looks good to me , thanks ! 
 Comment by Maybe add a sentence saying this means there is no repudiation of messages ? 
 I would prefer not to say anything like that here , because the degree to which signature implies non - repudiation depends on a bunch of context for how the signature keys are managed . Clearly if you have long term or certified keys , then yes , there 's a pretty high degree of non - repudiation . But people are also interested in configuring MLS to be deniable , e.g. , by exchanging signature keys over a deniable channel . So I would propose closing this with no action . 
 Ah , that is a very good point . In my head I was thinking signature means proof of key and key is proven to person . But that might certainly not be the case here . 
 The description of is clear that proposals defined in the RFC are not to be included because they are considered standard , however there is no such clarification around extensions . In general , extension requirements are not all that clear because in several places ( such as Lifetime ) it is mentioned that an extension must be included , however they are all listed as recommended rather than required in the table . It also raises a question in that if an extension is required to be implemented as part of the specification , and required in every KeyPackage , should it just be a field rather than an extension ? 
 Even that is not quite clear to me . At least to me it does n't follow from Section 10.1 . The last one at least , I can shed some light on , as we had this discussion before and I was arguing the same thing . From what I remember , the argument was the keeping it an extension rather than a field would force implementers to implement the Extension mechanism . I do n't have a super strong opinion here , but I seem to remember that that 's what it boiled down to . I generally agree , though , that some things around RequiredCapabilities ( RC ) and Capabilities in general is unclear . I discussed this with and here are some examples / questions that came up : If a group does n't have an RC extension , can we assume that all extensions / proposals in the spec are supported by everyone , or do we have to check all KeyPackages ? Do we want all extensions / proposals in the spec to be MTI and thus implicitly supported by everyone ? It might be useful to distinguish between basic ( MTI ) ones like Add , Remove , etc . and consider some optional such as ExternalInit or AppAck . Relatedly , should the extension in the KeyPackage list all the  proposals / extensions , too ? Are they invalid if they do or if they do n't ? We might want to discuss the difference between RC and a potential group policy . The way I understand it , RC is not meant to be an allow list or a block list , but instead should specify a minimum requirement for all clients in the group . A question here would be : If it 's not in the RC , but everyone 's capabilities support it , can I use / send it ? 
 Reacting to  's points here : It seems like to to be sure , you always need to check . RC just helps ensure that the check will produce the right answer . I would propose the answer to this be " Yes , the proposals / extensions in the spec are MTI " If the answer to the prior question is as I propose , then you do n't need to list spec proposals / extensions in Capabilities The difference between RC and checking everyone supports it is whether we expect it to be supported in the future . For Proposals , that might not matter ; for GroupContext extensions , it matters more . It also seems like there 's a fair argument that RequiredCapabilities should just be removed from the spec and replaced by some application - layer coordinated policy . I would be OK with that . To point about mandatory extensions -- I would probably be OK with converting mandatory extensions to fields , especially with the better division of labor proposed in . 
 I kind of like the idea of RequiredCapabilities because it enforces the proper checks lower down . Application layer would need to proxy packets via a middleware type of layer which could potentially be messy . 
 Discussion on working call : Agreement to not list in - spec capabilities in RC / Capabilities , so all those things are MTI
Paragraph (version A):
This extension lists the extensions and proposal types that must be
supported by all members of the group.  For new members, it is
enforced by existing members during the application of Add commits.
Existing members should of course be in compliance already.  In order
to ensure this continues to be the case even as the group's
extensions can be updated, a GroupContextExtensions proposal is
invalid if it contains a "required_capabilities" extension that
requires capabilities not supported by all current members.
Paragraph (version B):
This extension lists the extensions and proposal types that must be
supported by all members of the group.  The "default" proposal and
extension types defined in this document are assumed to be
implemented by all clients, and need not be listed in
RequiredCapabilities in order to be safely used.
Paragraph (version B):
For new members, support for required capabilities is enforced by
existing members during the application of Add commits.  Existing
members should of course be in compliance already.  In order to
ensure this continues to be the case even as the group's extensions
can be updated, a GroupContextExtensions proposal is invalid if it
contains a "required_capabilities" extension that requires non-
default capabilities not supported by all current members.