From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: mls@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Messaging Layer Security (mls)
The Messaging Layer Security (mls) WG in the Security Area of the IETF is
undergoing rechartering. 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 2023-12-27.
Messaging Layer Security (mls)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Nick Sullivan <nicholas.sullivan+ietf@gmail.com>
Sean Turner <sean+ietf@sn3rd.com>
Secretaries:
Katriel Cohn-Gordon <me@katriel.co.uk>
Assigned Area Director:
Paul Wouters <paul.wouters@aiven.io>
Security Area Directors:
Roman Danyliw <rdd@cert.org>
Paul Wouters <paul.wouters@aiven.io>
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/
The Messaging Layer Security (MLS) protocol, RFC 9420, specifies a key
establishment protocol that provides efficient asynchronous group key
establishment with forward secrecy (FS) and post-compromise security (PCS)
for groups in size ranging from two to thousands.
MLS has 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)
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 MLS protocol provides a way to leverage
existing authentication technologies to associate identities with
keys used in the protocol, just as TLS does with X.509.
While developing the MLS protocol, the group drew 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 Double Ratchet - https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm
The working group followed the pattern of TLS 1.3, with specification,
implementation, and verification proceeding in parallel. When we arrived
at RFC, we had several interoperable implementations as well as a thorough
security analysis.
Note that consensus is required both for changes to the protocol mechanisms
from these documents and retention of the mechanisms from them. 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.
Now that MLS has been published, the group will work on the following MLS
protocol extensions:
* Support for use of MLS in protocols developed by the MIMI working group
* Support for new credential types
* Support for common operational patterns in messaging applications
* Support for quantum resistance
* Framework for safe extensibility
* Detection of lost application messages
* Support for sending messages to individual members of a group
Many of extensions to support these features will be included in
draft-ietf-mls-extensions, but some of the extensions will be published in
seperate Internet-Drafts.
Milestones:
Dec 2024 - Submit MLS extensions I-D to IESG as Proposed Standard
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
mls-chairs@ietf.org,
mls@ietf.org,
rlb@ipv.sx
Subject: WG Action: Rechartered Messaging Layer Security (mls)
The Messaging Layer Security (mls) WG in the Security Area of the IETF has
been rechartered. For additional information, please contact the Area
Directors or the WG Chairs.
Messaging Layer Security (mls)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Nick Sullivan <nicholas.sullivan+ietf@gmail.com>
Sean Turner <sean+ietf@sn3rd.com>
Secretaries:
Katriel Cohn-Gordon <me@katriel.co.uk>
Assigned Area Director:
Paul Wouters <paul.wouters@aiven.io>
Security Area Directors:
Roman Danyliw <rdd@cert.org>
Paul Wouters <paul.wouters@aiven.io>
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/
The Messaging Layer Security (MLS) protocol, RFC 9420, specifies a key
establishment protocol that provides efficient asynchronous group key
establishment with forward secrecy (FS) and post-compromise security (PCS)
for groups in size ranging from two to thousands.
MLS has 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)
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 MLS protocol provides a way to leverage
existing authentication technologies to associate identities with
keys used in the protocol, just as TLS does with X.509.
While developing the MLS protocol, the group drew 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 Double Ratchet - https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm
The working group followed the pattern of TLS 1.3, with specification,
implementation, and verification proceeding in parallel. When we arrived
at RFC, we had several interoperable implementations as well as a thorough
security analysis.
Note that consensus is required both for changes to the protocol mechanisms
from these documents and retention of the mechanisms from them. 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.
Now that MLS has been published, the group will work on the following MLS
protocol extensions:
* Support for use of MLS in protocols developed by the MIMI working group
* Support for new credential types
* Support for common operational patterns in messaging applications
* Support for quantum resistance
* Framework for safe extensibility
* Detection of lost application messages
* Support for sending messages to individual members of a group
Many of extensions to support these features will be included in
draft-ietf-mls-extensions, but some of the extensions will be published in
seperate Internet-Drafts.
Milestones:
Dec 2024 - Submit MLS extensions I-D to IESG as Proposed Standard