draft-ietf-mls-architecture-12.txt		draft-ietf-mls-architecture-13.txt
	Network Working Group B. Beurdouche		Network Working Group B. Beurdouche
	Internet-Draft Inria & Mozilla		Internet-Draft Inria & Mozilla
	Intended status: Informational E. Rescorla		Intended status: Informational E. Rescorla
	Expires: 4 September 2024 Mozilla		Expires: 23 September 2024 Mozilla
	E. Omara		E. Omara
	S. Inguva		S. Inguva
	A. Duric		A. Duric
	Wire		Wire
	3 March 2024		22 March 2024
	The Messaging Layer Security (MLS) Architecture		The Messaging Layer Security (MLS) Architecture
	draft-ietf-mls-architecture-12		draft-ietf-mls-architecture-13
	Abstract		Abstract
	The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)		The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol)
	provides a Group Key Agreement protocol for messaging applications.		provides a Group Key Agreement protocol for messaging applications.
	MLS is meant to protect against eavesdropping, tampering, message		MLS is meant to protect against eavesdropping, tampering, message
	forgery, and provide Forward Secrecy (FS) and Post-Compromise		forgery, and provide Forward Secrecy (FS) and Post-Compromise
	Security (PCS).		Security (PCS).
	This document describes the architecture for using MLS in a general		This document describes the architecture for using MLS in a general
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 4 September 2024.		This Internet-Draft will expire on 23 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	5.2. Delivery of Messages . . . . . . . . . . . . . . . . . . 14		5.2. Delivery of Messages . . . . . . . . . . . . . . . . . . 14
	5.2.1. Strongly Consistent . . . . . . . . . . . . . . . . . 15		5.2.1. Strongly Consistent . . . . . . . . . . . . . . . . . 15
	5.2.2. Eventually Consistent . . . . . . . . . . . . . . . . 15		5.2.2. Eventually Consistent . . . . . . . . . . . . . . . . 15
	6. Functional Requirements . . . . . . . . . . . . . . . . . . . 16		6. Functional Requirements . . . . . . . . . . . . . . . . . . . 16
	6.1. Membership Changes . . . . . . . . . . . . . . . . . . . 16		6.1. Membership Changes . . . . . . . . . . . . . . . . . . . 16
	6.2. Parallel Groups . . . . . . . . . . . . . . . . . . . . . 18		6.2. Parallel Groups . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Asynchronous Usage . . . . . . . . . . . . . . . . . . . 18		6.3. Asynchronous Usage . . . . . . . . . . . . . . . . . . . 18
	6.4. Access Control . . . . . . . . . . . . . . . . . . . . . 18		6.4. Access Control . . . . . . . . . . . . . . . . . . . . . 18
	6.5. Handling Authentication Failures . . . . . . . . . . . . 19		6.5. Handling Authentication Failures . . . . . . . . . . . . 19
	6.6. Recovery After State Loss . . . . . . . . . . . . . . . . 20		6.6. Recovery After State Loss . . . . . . . . . . . . . . . . 20
	6.7. Support for Multiple Devices . . . . . . . . . . . . . . 20		6.7. Support for Multiple Devices . . . . . . . . . . . . . . 21
	6.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 21		6.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
	6.9. Application Data Framing and Type Advertisements . . . . 21		6.9. Application Data Framing and Type Advertisements . . . . 21
	6.10. Federation . . . . . . . . . . . . . . . . . . . . . . . 21		6.10. Federation . . . . . . . . . . . . . . . . . . . . . . . 21
	6.11. Compatibility with Future Versions of MLS . . . . . . . . 22		6.11. Compatibility with Future Versions of MLS . . . . . . . . 22
	7. Operational Requirements . . . . . . . . . . . . . . . . . . 22		7. Operational Requirements . . . . . . . . . . . . . . . . . . 22
	8. Security and Privacy Considerations . . . . . . . . . . . . . 26		8. Security and Privacy Considerations . . . . . . . . . . . . . 26
	8.1. Assumptions on Transport Security Links . . . . . . . . . 27		8.1. Assumptions on Transport Security Links . . . . . . . . . 27
	8.1.1. Integrity and Authentication of Custom Metadata . . . 27		8.1.1. Integrity and Authentication of Custom Metadata . . . 27
	8.1.2. Metadata Protection for Unencrypted Group		8.1.2. Metadata Protection for Unencrypted Group
	Operations . . . . . . . . . . . . . . . . . . . . . 28		Operations . . . . . . . . . . . . . . . . . . . . . 28
	skipping to change at page 19, line 6 ¶		skipping to change at page 19, line 6 ¶
	Because all clients within a group (members) have access to the		Because all clients within a group (members) have access to the
	shared cryptographic material, MLS protocol allows each member of the		shared cryptographic material, MLS protocol allows each member of the
	messaging group to perform operations, However, every service/		messaging group to perform operations, However, every service/
	infrastructure has control over policies applied to its own clients.		infrastructure has control over policies applied to its own clients.
	Applications managing MLS clients can be configured to allow for		Applications managing MLS clients can be configured to allow for
	specific group operations. On the one hand, an application could		specific group operations. On the one hand, an application could
	decide that a group administrator will be the only member to perform		decide that a group administrator will be the only member to perform
	add and remove operations. On the other hand, in many settings such		add and remove operations. On the other hand, in many settings such
	as open discussion forums, joining can be allowed for anyone.		as open discussion forums, joining can be allowed for anyone.
	The MLS protocol can, in certain modes, exchange unencrypted group		While MLS Application messages are always encrypted, MLS handshake
	operation messages. This flexibility is to allow services to perform		messages can be sent either encrypted (in an MLS PrivateMessage) or
	access control tasks on behalf of the group.		unencrypted (in an MLS PublicMessage). Applications may be designed
			such that intermediaries need to see handshake messages, for example
	While the Application messages will always be encrypted, having the		to enforce policy on which commits are allowed, or to provide MLS
	handshake messages in plaintext has privacy consequences as someone		ratchet tree data in a central location. If handshake messages are
	could collect the signatures on the handshake messages and use them		unencrypted, it is especially important that they be sent over a
	for tracking.		channel with strong transport encryption (see Section 8) in order to
			prevent external attackers from monitoring the status of the group.
	*RECOMMENDATION:* Prefer using encrypted group operation messages		Applications that use unencrypted handshake messages may take
	to avoid privacy issues related to non-encrypted signatures.		additional steps to reduce the amount of metadata that is exposed to
			the intermediary. Everything else being equal, using encrypted
			handshake messages provides stronger privacy properties than using
			unencrypted handshake messages, as it prevents intermediaries from
			learning about the structure of the group.
	If handshake messages are encrypted, any access control policies must		If handshake messages are encrypted, any access control policies must
	be applied at the client, so the application must ensure that the		be applied at the client, so the application must ensure that the
	access control policies are consistent across all clients to make		access control policies are consistent across all clients to make
	sure that they remain in sync. If two different policies were		sure that they remain in sync. If two different policies were
	applied, the clients might not accept or reject a group operation and		applied, the clients might not accept or reject a group operation and
	end-up in different cryptographic states, breaking their ability to		end-up in different cryptographic states, breaking their ability to
	communicate.		communicate.
	*RECOMMENDATION:* Avoid using inconsistent access control policies		*RECOMMENDATION:* Avoid using inconsistent access control policies
	skipping to change at page 46, line 6 ¶		skipping to change at page 46, line 6 ¶
	Asynchronous Decentralized Key Management for Large		Asynchronous Decentralized Key Management for Large
	Dynamic Groups A protocol proposal for Messaging Layer		Dynamic Groups A protocol proposal for Messaging Layer
	Security (MLS)", 2018, <https://hal.inria.fr/hal-		Security (MLS)", 2018, <https://hal.inria.fr/hal-
	02425247/file/treekem+%281%29.pdf>.		02425247/file/treekem+%281%29.pdf>.
	[BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok,		[BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok,
	"Cryptographic Security of the MLS RFC, Draft 11", 2021,		"Cryptographic Security of the MLS RFC, Draft 11", 2021,
	<https://eprint.iacr.org/2021/137.pdf>.		<https://eprint.iacr.org/2021/137.pdf>.
	[CAPBR] Brewer, E., "Towards robust distributed systems		[CAPBR] Brewer, E., "Towards robust distributed systems
	(abstract)", Proceedings of the nineteenth annual ACM		(abstract)", ACM, Proceedings of the nineteenth annual ACM
	symposium on Principles of distributed computing,		symposium on Principles of distributed computing,
	DOI 10.1145/343477.343502, July 2000,		DOI 10.1145/343477.343502, July 2000,
	<https://doi.org/10.1145/343477.343502>.		<https://doi.org/10.1145/343477.343502>.
	[CHK21] Cremers, C., Hale, B., and K. Kohbrok, "The Complexities		[CHK21] Cremers, C., Hale, B., and K. Kohbrok, "The Complexities
	of Healing in Secure Group Messaging: Why Cross-Group		of Healing in Secure Group Messaging: Why Cross-Group
	Effects Matter", 2021,		Effects Matter", 2021,
	<https://www.usenix.org/system/files/sec21-cremers.pdf>.		<https://www.usenix.org/system/files/sec21-cremers.pdf>.
	[CONIKS] Melara, M., Blankstein, A., Bonneau, J., Felten, E., and		[CONIKS] Melara, M., Blankstein, A., Bonneau, J., Felten, E., and
	skipping to change at page 46, line 44 ¶		skipping to change at page 46, line 44 ¶
	federation-03>.		federation-03>.
	[I-D.schinazi-masque-proxy]		[I-D.schinazi-masque-proxy]
	Schinazi, D., "The MASQUE Proxy", Work in Progress,		Schinazi, D., "The MASQUE Proxy", Work in Progress,
	Internet-Draft, draft-schinazi-masque-proxy-02, 28		Internet-Draft, draft-schinazi-masque-proxy-02, 28
	February 2024, <https://datatracker.ietf.org/doc/html/		February 2024, <https://datatracker.ietf.org/doc/html/
	draft-schinazi-masque-proxy-02>.		draft-schinazi-masque-proxy-02>.
	[KT] McMillion, B., "Key Transparency Architecture", Work in		[KT] McMillion, B., "Key Transparency Architecture", Work in
	Progress, Internet-Draft, draft-ietf-keytrans-		Progress, Internet-Draft, draft-ietf-keytrans-
	architecture-00, 18 January 2024,		architecture-01, 4 March 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-		<https://datatracker.ietf.org/doc/html/draft-ietf-
	keytrans-architecture-00>.		keytrans-architecture-01>.
	[Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and		[Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and
	G. Danezis, "The Loopix Anonymity System", 2017.		G. Danezis, "The Loopix Anonymity System", 2017.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/rfc/rfc3552>.		<https://www.rfc-editor.org/rfc/rfc3552>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
End of changes. 9 change blocks.
	19 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/