A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2018-05-23. Messaging Layer Security (mls) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Nick Sullivan <nick@cloudflare.com> Sean Turner <sean+ietf@sn3rd.com> Assigned Area Director: Benjamin Kaduk <kaduk@mit.edu> Security Area Directors: Eric Rescorla <ekr@rtfm.com> Benjamin Kaduk <kaduk@mit.edu> Mailing list: Address: mls@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/mls Archive: https://mailarchive.ietf.org/arch/browse/mls/ Group page: https://datatracker.ietf.org/group/mls/ Charter: https://datatracker.ietf.org/doc/charter-ietf-mls/ Several Internet applications have a need for group key establishment and message protection protocols with the following properties: o Message Confidentiality - Messages can only be read by members of the group o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with o Membership Authentication - Each participant can verify the set of members in the group o Asynchronicity - Keys can be established without any two participants being online at the same time o Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the group o Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the group o Scalability - Resource requirements have good scaling in the size of the group (preferably sub-linear) Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3). It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs. While authentication is a key goal of this working group, it is not the objective of this working group to develop new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications: o S/MIME - https://tools.ietf.org/html/rfc5751 o OpenPGP - https://tools.ietf.org/html/rfc4880 o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html o Signal - https://signal.org/docs/ The intent of this working group is to follow the pattern of TLS 1.3, with specification, implementation, and verification proceeding in parallel. By the time we arrive at RFC, we hope to have several interoperable implementations as well as a thorough security analysis. The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, generalizing the design described in: o draft-omara-mls-architecture o draft-barnes-mls-protocol Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. Milestones: May 2018 - Initial working group documents for architecture and key management Sep 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational Jun 2019 - Submit key management protocol to IESG as Proposed Standard Sep 2019 - Submit message protection protocol to IESG as Proposed Standard
