Skip to main content

The Messaging Layer Security (MLS) Protocol

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,,,,,,,,,,,,
Subject: Protocol Action: 'The Messaging Layer Security (MLS) Protocol' to Proposed Standard (draft-ietf-mls-protocol-20.txt)

The IESG has approved the following document:
- 'The Messaging Layer Security (MLS) Protocol'
  (draft-ietf-mls-protocol-20.txt) as Proposed Standard

This document is the product of the Messaging Layer Security Working Group.

The IESG contact persons are Paul Wouters and Roman Danyliw.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

  In this document, we specify a key establishment protocol that provides
  efficient asynchronous group key establishment with forward secrecy and
  post compromise security for groups in size ranging from two to thousands.

Working Group Summary

  Smooth sailing in general. Different parties worked well together.

Document Quality

   There are a number of implementations available already. A number
   of vendors have authors on the document.

  - MLSpp = open source, deployed in production
  - OpenMLS = open source
  - Wickr's implementation = closed source
  - RingCentral's implementation = closed source, deployed in production
  - Element's Typescript implementation = open source, only prototype-grade

  There is strong confidence this protocol will be widely implemented and used.

   Early reviews brought up issues that were resolved along with the AD
   Review issues in the latest -17 version.

  There is a Media Type defined. IANA performed an early review and noted that
  a few that were addressed. The revised registration was shared with the mailing list, see

  Some discussion happened on whether "message/mls" was the right choice due to
  some special old/lost meaning of "message", but in the end it stuck with "message/mls".

  No MIB or Yang items in the document.


   Sean Turner is the Document Shepherd.
   Paul Wouters is the responsible AD.

RFC Editor Note