IETF proposed a new standard for messaging - what you need to know
The Internet Engineering Council ( IETF) has published a draft of the new protocol - Message Layer Security (MLS). Its task is to provide secure messaging between two devices. It describes abstract data structures that can be used not only in chat applications, but also for working with TLS 1.3 and JSON. Let's talk about the principles of the MLS.
/ photo by Rama CC
IETF engineers have released two documents. The first describes the messaging requirements for implementing the MLS protocol, and the second describes the MLS protocol itself .
The messaging service (Messaging Service) includes two services that monitor the security of receiving / transmitting messages.
The first is the Authentication Service. Responsible for the safety of personal data - login, phone number, as well as a unique pair of keys to identify customers.
The second, the Delivery Service, stores and distributes keys to clients for the exchange of encrypted messages. The delivery service operates with only the data needed for the exchange of messages, and does not touch the personal information about the senders. This limits the “footprint” of server-side metadata.
In many systems, the delivery and identification services are represented by a single logical object or server. However, in MLS these are two separate components. The authors decided to separate these processes so that MLS can be used along with open authorization protocols, such as OAuth .
This gives another advantage. Even if the messaging service provider controls the authentication and delivery processes, the metadata will be reliably protected. The provider will fail to associate encrypted messages with public keys.
Messaging users are grouped together. To create a group, participants “add up" their UserInitKey keys and form a secret . UserInitKey is a key Diffie-Hellman pair and is used to initialize individual users.
The protocol involves two types of binary trees . The first, the Merkle tree (also known as the hash tree), serves to confirm the authenticity of the operations performed by the group members. The second view, the Ratchet tree, is used to extract their secrets.
The following basic operations can be performed in a group:
If a member of group A wants to create a dialogue with B and C, he first downloads their initialization keys (InitKeys). After that, these keys are used to form GroupAdd messages, which must add members B and C.
GroupAdd messages are sent to the whole group and are processed in order B and C. When their answers return to A, the group status is updated and the “newcomers” are displayed. Any other messages sent by system members before being accepted into the group are ignored.
Unlike TLS and DTLS, the new protocol does not contain the “handshake” phase as such. MLS uses the so-called Handshake Messages. Corresponding members exchange them every time they need to add or remove a new member of the group.
Handshake Message encapsulates a special message about a group state change, and also includes GroupInitKey so that the new member can be initialized and the signatures of one of the current group members, along with Merkle's proof (to make sure the person is "authenticated").
Representatives of Google, Mozilla, Twitter, MIT, INRIA , a French research institute, and Wire communication platform took part in the development of the architecture and requirements for MLS . The protocol itself was created by people from Cisco, Facebook, Google, and Oxford University. / photo Book Catalog CC
What do we do in IT-GRAD: • IaaS • PCI DSS hosting • Cloud FZ-152
Materials from our blog about corporate IaaS:
/ photo by Rama CC
IETF engineers have released two documents. The first describes the messaging requirements for implementing the MLS protocol, and the second describes the MLS protocol itself .
About messaging architecture
The messaging service (Messaging Service) includes two services that monitor the security of receiving / transmitting messages.
The first is the Authentication Service. Responsible for the safety of personal data - login, phone number, as well as a unique pair of keys to identify customers.
The second, the Delivery Service, stores and distributes keys to clients for the exchange of encrypted messages. The delivery service operates with only the data needed for the exchange of messages, and does not touch the personal information about the senders. This limits the “footprint” of server-side metadata.
In many systems, the delivery and identification services are represented by a single logical object or server. However, in MLS these are two separate components. The authors decided to separate these processes so that MLS can be used along with open authorization protocols, such as OAuth .
This gives another advantage. Even if the messaging service provider controls the authentication and delivery processes, the metadata will be reliably protected. The provider will fail to associate encrypted messages with public keys.
How MLS works
Messaging users are grouped together. To create a group, participants “add up" their UserInitKey keys and form a secret . UserInitKey is a key Diffie-Hellman pair and is used to initialize individual users.
The protocol involves two types of binary trees . The first, the Merkle tree (also known as the hash tree), serves to confirm the authenticity of the operations performed by the group members. The second view, the Ratchet tree, is used to extract their secrets.
The following basic operations can be performed in a group:
- Add a new group member (create a dialogue).
- Update group member secret data.
- Remove a member of the group.
If a member of group A wants to create a dialogue with B and C, he first downloads their initialization keys (InitKeys). After that, these keys are used to form GroupAdd messages, which must add members B and C.
GroupAdd messages are sent to the whole group and are processed in order B and C. When their answers return to A, the group status is updated and the “newcomers” are displayed. Any other messages sent by system members before being accepted into the group are ignored.
Unlike TLS and DTLS, the new protocol does not contain the “handshake” phase as such. MLS uses the so-called Handshake Messages. Corresponding members exchange them every time they need to add or remove a new member of the group.
Handshake Message encapsulates a special message about a group state change, and also includes GroupInitKey so that the new member can be initialized and the signatures of one of the current group members, along with Merkle's proof (to make sure the person is "authenticated").
What awaits MLS
Representatives of Google, Mozilla, Twitter, MIT, INRIA , a French research institute, and Wire communication platform took part in the development of the architecture and requirements for MLS . The protocol itself was created by people from Cisco, Facebook, Google, and Oxford University. / photo Book Catalog CC
The fate of the protocol will be decided next month when the IETF Council meets to discuss the draft options again. If everything goes smoothly, then in a year the MLS will be approved by the IESG (Internet Engineering Steering Group), and it will become the standard.
What do we do in IT-GRAD: • IaaS • PCI DSS hosting • Cloud FZ-152
Materials from our blog about corporate IaaS:
- Serverless computing in the cloud - a trend of modernity or necessity?
- How to place 100% of the infrastructure in the cloud IaaS-provider and not regret it
- Cloud technologies in the financial sector: the experience of Russian companies