Draft: draft-ietf-mls-protocol

Commentary: The way the spec is written now , clients need to implement all proposal types , and they must react to appropriately to all valid proposals , including AppAck . AppAck in a large , busy group could result in a situation where clients with longer latency connections to the DS ( perhaps in a different country , using satellite , or using some wireless networks ) might be effectively prevented from sending any messages , or worse could be prevented from sending AppAcks because their proposals are always a few hundred milliseconds late . I think AppAcks still have a place is relatively small groups with low message volumes , but I have a few suggestions : 1 ) Describe this issue either in the AppAck proposal section or in the security considerations section 2 ) I think it is reasonable for a group to consider some proposal types invalid . If there is consensus with this position , I 'd like to make this clear with an extra sentence or two . If that is not the consensus , then I will propose that only Add , Remove , and Update are assumed to be supported by each group , and other proposal types have to be explicitly . 
 My team had similar comments . I agree that this should n't be a 100 % necessary thing to support . 
 I would differentiate between " support " in the sense of " if you receive one , do something sensible with it " vs. " send this under some circumstances " . My understanding was that the requirement here was the former , and even that the definition of " sensible " was up to the implementation . The thinking being that if an application wanted to get some anti - suppression properties , it could send and verify these on some schedule , but when exactly they would be sent would be up to the application . Does that alleviate some of the concern here ? If so , I would totally be open to clarifying that . To point about latency , it seems like we could add an parameter to AppAck so that you could report on past epochs ' messages in a future epoch . On considering proposal types invalid -- I think there has always been a notion that applications might have policies on which proposals are acceptable . Not just at the proposal type level , but at even finer granularities . Think about things like groups where only certain members are allowed to add / remove participants . I would also be fine laying this out more explicitly , though maybe it would be a more natural fit in the architecture document . 
 Sorry , meant to delete a comment , closed the issue instead . 
 In the past I 've expressed reservations about AppAck being included in the spec . I do n't think it 's sufficiently general ( it only handles a one specific pattern of message loss and wo n't work for others , per comment ) , and I do n't like that we do n't specify how to handle dropped messages in any way . The AppAck functionality is likely to just be re - invented at the application - level because of this . For example , AppAck ca n't be used to implement read receipts It does n't help detect the suppression of handshake messages It does n't handle cases where some messages must be delivered and others may be dropped So instead I would propose removing AppAck from the spec . 
 I 've opened a PR to that effect in . 
 Virtual interim 2022 - 05 - 19 Agreement that the bar for support is quite low ... but you do n't get a security property unless members actually do something more than the minimum That sort of implies that you want the group to opt in to this mechanism So we should have a new proposal type in a separate I - D 
 ( To be clear , AppAck should move from the main spec here to its own I - D. ) 
 One comment that renumbering the groupcontextextensions proposal was probably a bad idea from a process perspective which we should avoid doing in the future . In this case it seems unlikely that many people have implemented it who could not make a breaking change .
Paragraph (version A):
An AppAck proposal is used to acknowledge receipt of application
messages.  Though this information implies no change to the group, it
is structured as a Proposal message so that it is included in the
group's transcript by being included in Commit messages.
Paragraph (version A):
An AppAck proposal represents a set of messages received by the
sender in the current epoch.  Messages are represented by the
"sender" and "generation" values in the MLSCiphertext for the
message.  Each MessageRange represents receipt of a span of messages
whose "generation" values form a continuous range from
"first_generation" to "last_generation", inclusive.
Paragraph (version A):
AppAck proposals are sent as a guard against the Delivery Service
dropping application messages.  The sequential nature of the
"generation" field provides a degree of loss detection, since gaps in
the "generation" sequence indicate dropped messages.  AppAck
completes this story by addressing the scenario where the Delivery
Service drops all messages after a certain point, so that a later
generation is never observed.  Obviously, there is a risk that AppAck
messages could be suppressed as well, but their inclusion in the
transcript means that if they are suppressed then the group cannot
advance at all.
Paragraph (version A):
The application might have the committer include an AppAck
proposal whenever a Commit is sent, so that other members could
know when one of their messages did not reach the committer.
Paragraph (version A):
The application could have a client send an AppAck whenever an
application message is sent, covering all messages received since
its last AppAck.  This would provide a complete view of any losses
experienced by active members.
Paragraph (version A):
The application could simply have clients send AppAck proposals on
a timer, so that all participants' state would be known.
Paragraph (version A):
An application using AppAck proposals to guard against loss/
suppression of application messages also needs to ensure that AppAck
messages and the Commits that reference them are not dropped.  One
way to do this is to always encrypt Proposal and Commit messages, to
make it more difficult for the Delivery Service to recognize which
messages contain AppAcks.  The application can also have clients
enforce an AppAck schedule, reporting loss if an AppAck is not
received at the expected time.