Charter for Working Group

Several Internet applications have a need for group key establishmentand message protection protocols with the following properties:

o Message Confidentiality - Messages can only be read by members of the groupo Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered witho Membership Authentication - Each participant can verify the set of members in the groupo Asynchronicity - Keys can be established without any two participants being online at the same timeo Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the groupo Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the groupo Scalability - Resource requirements have good scaling in the size of the group (preferably sub-linear)

Several widely-deployed applications have developed their ownprotocols to meet these needs. While these protocols are similar,no two are close enough to interoperate. As a result, each applicationvendor has had to maintain their own protocol stack and independentlybuild trust in the quality of the protocol. The primary goal of thisworking group is to develop a standard messaging security protocol forhuman-to-human(s) communication with the above security and deploymentproperties so that applications can share code, and so that there can beshared validation of the protocol (as there has been with TLS 1.3).Humans are assumed to have access to one or more general-purposecomputers.

It is not a goal of this group to enable interoperability/federationbetween messaging applications beyond the key establishment,authentication, and confidentiality services. Full interoperabilitywould require alignment at many different layers beyond security,e.g., standard message transport and application semantics. Thefocus of this work is to develop a messaging security layer thatdifferent applications can adapt to their own needs.

While authentication is a key goal of this working group, it is notthe objective of this working group to develop new authenticationtechnologies. Rather, the security protocol developed by thisgroup will provide a way to leverage existing authenticationtechnologies to associate identities with keys used in the protocol,just as TLS does with X.509.

The intent of this working group is to follow the pattern ofTLS 1.3, with specification, implementation, and verificationproceeding in parallel. By the time we arrive at RFC, wehope to have several interoperable implementations as wellas a thorough security analysis.

The specifications developed by this working group will bebased on pre-standardization implementation and deploymentexperience, and generalizing the design described in:

o draft-omara-mls-architectureo draft-barnes-mls-protocol

Note that consensus is required both for changes to the protocol mechanismsfrom these documents and retention of the mechanisms from them. In particular,because something is in the initial document set does not imply that there isconsensus around the feature or around how it is specified.