Messaging Layer Security

Last updated
Messaging Layer Security
AbbreviationMLS
First publishedJuly 2023 (2023-07)
Organization IETF
Authors
  • R. Barnes
  • B. Beurdouche
  • R. Robert
  • J. Millican
  • E. Omara
  • K. Cohn-Gordon
DomainSecurity
Website www.rfc-editor.org/rfc/rfc9420.html

Messaging Layer Security (MLS) is a security layer for end-to-end encrypting messages. It is maintained by the MLS working group of the Internet Engineering Task Force, and is designed to provide an efficient and practical security mechanism for groups as large as 50,000 and for those who access chat systems from multiple devices. [1] [2] [3]

Contents

Security properties

Security properties of MLS include message confidentiality, message integrity and authentication, membership authentication, asynchronicity, forward secrecy, post-compromise security, and scalability. [4]

History

The idea was born in 2016 and first discussed in an unofficial meeting during IETF 96 in Berlin with attendees from Wire, Mozilla and Cisco. [5]

Initial ideas were based on pairwise encryption for secure 1:1 and group communication. In 2017, an academic paper introducing Asynchronous Ratcheting Trees was published by the University of Oxford and Facebook setting the focus on more efficient encryption schemes. [6]

The first BoF took place in February 2018 at IETF 101 in London. The founding members are Mozilla, Facebook, Wire, Google, Twitter, University of Oxford, and INRIA. [7]

As of March 29, 2023, the IETF has approved publication of Messaging Layer Security (MLS) as a new standard. [8] It was officially published on July 19, 2023. [9] [10] At that time, Google announced it intended to add MLS to the end to end encryption used by Google Messages over RCS. [11]

Matrix is one of the protocols declaring migration to MLS. [12]

Research on adding post-quantum cryptography (PQC) to MLS is ongoing, but MLS does not currently support PQC. [13] [14] [15]

Implementations

Related Research Articles

<span class="mw-page-title-main">Public-key cryptography</span> Cryptographic system with public and private keys

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key. Key pairs are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public-key cryptography depends on keeping the private key secret; the public key can be openly distributed without compromising security. There are many kinds of public-key cryptosystems, with different security goals, including digital signature, Diffie-Hellman key exchange, public-key key encapsulation, and public-key encryption.

The Secure Shell (SSH) Protocol is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network, such as the Internet. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In cryptography, Camellia is a symmetric key block cipher with a block size of 128 bits and key sizes of 128, 192 and 256 bits. It was jointly developed by Mitsubishi Electric and NTT of Japan. The cipher has been approved for use by the ISO/IEC, the European Union's NESSIE project and the Japanese CRYPTREC project. The cipher has security levels and processing abilities comparable to the Advanced Encryption Standard.

Datagram Transport Layer Security (DTLS) is a communications protocol providing security to datagram-based applications by allowing them to communicate in a way designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport—the application does not suffer from the delays associated with stream protocols, but because it uses User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP), the application has to deal with packet reordering, loss of datagram and data larger than the size of a datagram network packet. Because DTLS uses UDP or SCTP rather than TCP it avoids the TCP meltdown problem when being used to create a VPN tunnel.

<span class="mw-page-title-main">Forward secrecy</span> Practice in cryptography

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised, limiting damage. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

In cryptography, a hybrid cryptosystem is one which combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem. Public-key cryptosystems are convenient in that they do not require the sender and receiver to share a common secret in order to communicate securely. However, they often rely on complicated mathematical computations and are thus generally much more inefficient than comparable symmetric-key cryptosystems. In many applications, the high cost of encrypting long messages in a public-key cryptosystem can be prohibitive. This is addressed by hybrid systems by using a combination of both.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

Lattice-based cryptography is the generic term for constructions of cryptographic primitives that involve lattices, either in the construction itself or in the security proof. Lattice-based constructions support important standards of post-quantum cryptography. Unlike more widely used and known public-key schemes such as the RSA, Diffie-Hellman or elliptic-curve cryptosystems — which could, theoretically, be defeated using Shor's algorithm on a quantum computer — some lattice-based constructions appear to be resistant to attack by both classical and quantum computers. Furthermore, many lattice-based constructions are considered to be secure under the assumption that certain well-studied computational lattice problems cannot be solved efficiently.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

Post-quantum cryptography (PQC), sometimes referred to as quantum-proof, quantum-safe, or quantum-resistant, is the development of cryptographic algorithms that are currently thought to be secure against a cryptanalytic attack by a quantum computer. Most widely-used public-key algorithms rely on the difficulty of one of three mathematical problems: the integer factorization problem, the discrete logarithm problem or the elliptic-curve discrete logarithm problem. All of these problems could be easily solved on a sufficiently powerful quantum computer running Shor's algorithm or even faster and less demanding alternatives.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The initial HTTP/2 specification was published as on May 14, 2015.

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google. It was first implemented and deployed in 2012 and was publicly announced in 2013 as experimentation broadened. It was also described at an IETF meeting. The Chrome web browser, Microsoft Edge, Firefox, and Safari all support it. In Chrome, QUIC is used by more than half of all connections to Google's servers.

<span class="mw-page-title-main">Matrix (protocol)</span> Networking protocol for real-time communication and data synchronization

Matrix is an open standard and communication protocol for real-time communication. It aims to make real-time communication work seamlessly between different service providers, in the way that standard Simple Mail Transfer Protocol email currently does for store-and-forward email service, by allowing users with accounts at one communications service provider to communicate with users of a different service provider via online chat, voice over IP, and videotelephony. It therefore serves a similar purpose to protocols like XMPP, but is not based on any existing communication protocol.

<span class="mw-page-title-main">Signal Protocol</span> Non-federated cryptographic protocol

The Signal Protocol is a non-federated cryptographic protocol that provides end-to-end encryption for voice and instant messaging conversations. The protocol was developed by Open Whisper Systems in 2013 and was introduced in the open-source TextSecure app, which later became Signal. Several closed-source applications have implemented the protocol, such as WhatsApp, which is said to encrypt the conversations of "more than a billion people worldwide" or Google who provides end-to-end encryption by default to all RCS-based conversations between users of their Google Messages app for one-to-one conversations. Facebook Messenger also say they offer the protocol for optional Secret Conversations, as does Skype for its Private Conversations.

Post-Quantum Cryptography Standardization is a program and competition by NIST to update their standards to include post-quantum cryptography. It was announced at PQCrypto 2016. 23 signature schemes and 59 encryption/KEM schemes were submitted by the initial submission deadline at the end of 2017 of which 69 total were deemed complete and proper and participated in the first round. Seven of these, of which 3 are signature schemes, have advanced to the third round, which was announced on July 22, 2020.

DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States. In May 2020, Chrome switched to DNS over HTTPS by default.

xx messenger is a cross-platform decentralized encrypted instant messaging service developed by PrivaTegrity Corporation and running on a blockchain called xx network. Messages are delivered over a variety of mix network first described in 2016. Users can send one-to-one and group messages, which can include voice notes and images.

References

  1. "Inside MLS, the New Protocol for Secure Enterprise Messaging". Dark Reading. 27 June 2019. Retrieved 2019-11-15.
  2. at 10:29, Richard Chirgwin 22 Aug 2018. "Elders of internet hash out standards to grant encrypted message security for world+dog". www.theregister.co.uk. Retrieved 2019-11-15.{{cite web}}: CS1 maint: numeric names: authors list (link)
  3. "Messaging Layer Security". GitHub.
  4. "Messaging Layer Security (mls) -". datatracker.ietf.org. Retrieved 2019-03-05.
  5. "Das sind die sieben Entwickler-Trends 2019: Vom Java-Comeback über MLS bis KI/ML-zentrierte Technologien". IT Finanzmagazin. 2 January 2019. Retrieved 7 January 2019.
  6. Cohn-Gordon, Katriel; Cremers, Cas; Garratt, Luke; Millican, Jon; Milner, Kevin (2017). "On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees". Cryptology ePrint Archive.
  7. Chirgwin, Richard (22 August 2018). "Elders of internet hash out standards to grant encrypted message security for world+dog" . Retrieved 30 November 2018.
  8. Sullivan, Nick; Turner, Sean (2023-03-29). "Messaging Layer Security: Secure and Usable End-to-End Encryption". IETF . Retrieved 2023-07-28.
  9. "New MLS protocol provides groups better and more efficient security at Internet scale". 2023-07-19. Retrieved 2023-07-28.
  10. Beurdouche, Benjamin; Vasquez, Sarah (2023-07-20). "Messaging Layer Security is now an internet standard". Mozilla . Retrieved 2023-07-28.
  11. "An important step towards secure and interoperable messaging". Google Online Security Blog. Retrieved 2024-12-12.
  12. "Are We MLS Yet?". Are We MLS Yet?. Retrieved 2024-09-23.
  13. "Cryspen | Post-Quantum Group Messaging". cryspen.com. Retrieved 2024-12-12.
  14. Hashimoto, Keitaro; Katsumata, Shuichi; Prest, Thomas (2022-11-07). "How to Hide MetaData in MLS-Like Secure Group Messaging: Simple, Modular, and Post-Quantum" (PDF). Cryptology ePrint Archive. Retrieved 2024-12-09.
  15. "Post-quantum messaging: examining Apple's new PQ3 protocol". PQShield. 2024-02-22. Retrieved 2024-12-09.