Draft: draft-ietf-mls-protocol

Commentary: This involved a couple of changes other than just removing the field and references to it : Detecting duplicative Adds is now a little more ambiguous , since you ca n't just match on . However ( a ) this does n't degrade the security of the protocol , just makes it a little less efficient ( b ) as discussed in , if applications want to sharpen it , they can add an -like identifier in an extension . The External Commit language around resync got generalized to say that the KeyPackage needs to meet the requirements of an Update for the removed node , which captures the successor notions we 've discussed . I also noticed that when we forbade proposals by reference in , we did n't totally remove them . So I went ahead and fixed that here . 
 Comment by What is the logic to make MLS128DHKEMX25519AES128GCMSHA256_Ed25519 the only MTI ? It contains both FIPS and not FIPS items , pleasing no one . 
 I remember arguing that the FIPS suite should be MTI at one of the interims . The argument ( iirc ) was that people that need FIPS are going to implement FIPS anyways , so the MTI should be the one that 's subjectively / widely - considered best . " But then would n't a FIPS - only client not conform to the RFC ? " Yes , but the people that require FIPS will not care . 
 Well I know from IKEv2 / IPsec , that we do take this into account and do ensure there is only FIPS MITM . I also know we are discussing this in openpgp and also for that reason are adding AES_GCM there . So if the only reasoning is " FIPS will force people to break RFCs anyway " , that 's kinda weak    mean " MTI " ? I do n't think the MITM folks care about FIPS :) I think summary captures the state of the art pretty well . Note as well that , so this will soon be moot anyway . ( For some government - speed definition of " soon " . ) So yes , some FIPS folks might be sad in the short run , but things will even out . The working group had a robust discussion on this , and landed on this as a compromise that could get consensus . I do n't think these FIPS concerns are worth upsetting that consensus . 
 Realistically , most folks using end - to - end encrypted instant messaging today are already using a variation of the  protocol , using Ed25519 . Many of our largest customers normally use FIPS , but have exceptions to use Ed25519 in this context and have no problem using Ed25519 for MLS . 
 ( yes MTI :) That NIST doc is from 2017 , so I"m not sure what you mean with " soon " :) I personally think it should be fixed but wo n't block it . Let 's see what the IESG says though :) 
 We to have a way to reference a member that is stable over the member 's lifetime in the group . However , is never used in the protocol ; the main need for such references is to give applications a way to tell an MLS stack what to do , e.g. , which member to remove . is n't really required for this purpose , either : Leaf indices have the same stability as ( since members do n't change leaves ) , and no need for explicit checks on uniqueness . Applications can add their own unique identifiers in KeyPackage extensions Applications often want to refer to non - unique identifiers , e.g. , asking to remove all devices belonging to an email address So it seems like at this point , can safely be removed . 
 - tagging you all here since I seem to recall you had opinions on this topic . 
 With the changes in enforcing consistent verification methods and the fact that a prior key signs off on any new signature key , I think we have a fairly consistent chain for the identity and the endpoint_id can probably be removed . Leaving it in may strengthen security in some way , but I do not immediately see an issue . 
 What said . I left a comment in regarding the details on the check , but otherwise , I think we 're ok to remove . As you pointed out earlier if an application decides it 's necessary , they can always add it via an extension . 
 Thanks for taking care of the cleanup here after the discussion on . If the application has to provide a function that determines if a given KeyPackage represents a valid update , we could use the same function to determine if an Add is a duplicate . Although admittedly , in that case one would have to compare with all other KeyPackages in the group and the function might not be very efficient . Generally , I 'm ok with this solution , though .
Paragraph (version A):
an "endpoint_id" that uniquely identifies a client in a group.
Paragraph (version A):
If there are multiple proposals that apply to the same leaf, the
committer chooses one and includes only that one in the Commit,
considering the rest invalid.  The committer MUST NOT include any
Update proposals generated by the committer, since they would be
duplicative with the "path" field in the Commit.  The committer MUST
prefer any Remove received, or the most recent Update for the leaf if
there are no Removes.  If there are multiple Add proposals containing
KeyPackages with the same "endpoint_id", the committer again chooses
one to include and considers the rest invalid.  Add proposals that
contain KeyPackages with an "endpoint_id" tuple that matches that of
an existing KeyPackage in the group MUST be considered invalid.  The
committer MUST consider invalid any Add or Update proposal if the
Credential in the contained KeyPackage shares the same signature key
with a Credential in any leaf of the group, or indeed if the
KeyPackage shares the same "hpke_init_key" with another KeyPackage in
the group.
Paragraph (version B):
If there are multiple proposals that apply to the same leaf, the
committer chooses one and includes only that one in the Commit,
considering the rest invalid.  The committer MUST NOT include any
Update proposals generated by the committer, since they would be
duplicative with the "path" field in the Commit.  The committer MUST
prefer any Remove received, or the most recent Update for the leaf if
there are no Removes.  If there are multiple Add proposals containing
KeyPackages that the committer considers to represent the same client
or a client already in the group (for example, identical KeyPackages
or KeyPackages sharing the same Credential), the committer again
chooses one to include and considers the rest invalid.  The committer
MUST consider invalid any Add or Update proposal if the Credential in
the contained KeyPackage shares the same signature key with a
Credential in any leaf of the group, or if the KeyPackage shares the
same "hpke_init_key" with another KeyPackage in the group.
Paragraph (version A):
If a Remove proposal is present, then the "endpoint_id" of the
Add KeyPackage MUST be the same as the one in the removed node,
and the "credential" MUST present a set of identifiers that is
acceptable to the application for the removed participant (as
if this were an Update for that participant).
Paragraph (version B):
If a Remove proposal is present, then the leaf KeyPackage in
the "path" field MUST meet the same criteria as the KeyPackage
in an Update for the removed leaf (see update).  In particular,
the "credential" in the KeyPackage MUST present a set of
identifiers that is acceptable to the application for the
removed participant.