Ways to convey the Ratchet Tree in Messaging Layer Security
draft-mahy-mls-ratchet-tree-options-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rohan Mahy | ||
| Last updated | 2024-03-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mahy-mls-ratchet-tree-options-00
MLS R. Mahy
Internet-Draft Unaffiliated
Intended status: Informational 21 March 2024
Expires: 22 September 2024
Ways to convey the Ratchet Tree in Messaging Layer Security
draft-mahy-mls-ratchet-tree-options-00
Abstract
The Messaging Layer Security (MLS) protocol needs to share its
ratchet_tree object to welcome new clients into a group and in
external joins. While, the protocol only defines a mechanism for
sharing the entire tree, most implementations use various
optimizations to avoid sending this structure repeatedly in large
groups. This draft explores ways to convey these improvements in a
standardized way and to convey parts of a GroupInfo object that are
not visible to an intermediary server.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-mahy-mls-ratchet-tree-
options/.
Discussion of this document takes place on the MLS Working Group
mailing list (mailto:mls@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/mls/. Subscribe at
https://www.ietf.org/mailman/listinfo/mls/.
Source for this draft and an issue tracker can be found at
https://github.com/rohanmahy/mls-ratchet-tree-options/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Mahy Expires 22 September 2024 [Page 1]
Internet-Draft Ratchet tree options in MLS March 2024
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Conveying the Ratchet Tree . . . . . . . . . . . . . . . . . 3
4. Conveying the GroupInfo . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
In the Messaging Layer Security (MLS) protocol [RFC9420], the members
of a group are organized into a ratchet tree, the full representation
of which is described in the ratchet_tree extension. The protocol
specifies that the full ratchet_tree can be included in Welcome
messages or shared externally, but describes no concrete way to
convey externally. Likewise, when non-member clients want to join a
group, they can do so using an external commit. They require the
GroupInfo and the ratchet_tree.
Mahy Expires 22 September 2024 [Page 2]
Internet-Draft Ratchet tree options in MLS March 2024
Many MLS implementations allow external commits to get the GroupInfo
from a central server. In the MIMI architecture
[I-D.barnes-mimi-arch], this server is called the hub, and for
brevity we will use that term generically to refer to any central
server that provides either GroupInfo or ratchet_tree objects to new
members (i.e. welcomed clients or external joining clients).
When handshake messages (commits and proposals) are sent as
PublicMessages, the hub can construct its own version of the
ratchet_tree and most of the GroupInfo object as proposals and
commits arrive.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document assumes familiarity with terms and structs from the MLS
specification ([RFC9420]).
3. Conveying the Ratchet Tree
The ratchet tree can be conveyed inline in its entirety.
Alternatively, this document describes how it can be referred to by
reference, or "patched".
Mahy Expires 22 September 2024 [Page 3]
Internet-Draft Ratchet tree options in MLS March 2024
enum {
reserved(0),
full(1),
byReference(2),
delta(3),
(255)
} RatchetTreeRepresentation;
struct {
RatchetTreeRepresentation representation;
select (representation) {
case full:
Node ratchet_tree<V>;
case byReference:
/* an HTTPS URL */
opaque ratchet_tree_url<V>;
opaque tree_signature<V>;
case delta:
NodeChanges node_changes;
};
} RatchetTreeOption;
* full indicates that the complete ratchet_tree extension is
included in the RatchetTreeOption object.
* byReference indicates that the ratchet_tree is available from the
ratchet_tree_url.
* delta indicates that the new ratchet_tree differs from the
previous epoch. The changes are described in the node_changes.
struct {
unit32 index;
Node node;
} NodePlusIndex;
struct {
uint32 removed_nodes<V>;
NodePlusIndex updated_nodes<V>;
Node new_nodes<V>;
} NodeChanges
To describe changes between two ratchet trees in the NodeChanges
"patch" format, first make a list of node indexes of nodes that have
been completely removed, next make a list of nodes that were
completely replaced and their node indexes, finally make a list of
new nodes which were added after the right-most node in the tree.
Mahy Expires 22 September 2024 [Page 4]
Internet-Draft Ratchet tree options in MLS March 2024
4. Conveying the GroupInfo
In some systems the GroupInfo is sent to a hub with a full
ratchet_tree extension always included with every commit. This is
used in systems where the hub may or may not track the membership of
the group, but does not keep the entire ratchet_tree data structure.
As group size increases, the size of the ratchet_tree extension in
the GroupInfo scales roughly linearly. Even using basic credentials,
this object gets large quickly. If x509 credentials are used, the
size increases much more rapidly, and if a post-quantum ciphersuite
(for example [I-D.mahy-mls-xwing]) is used, the size will increase
even more rapidly with each new member.
In some systems that require unencrypted handshake messages, the hub
tracks commits as they are sent and constructs changes to the
ratchet_tree as each handshake is accepted. The hub could also
recreate a GroupInfo from inspecting unencrypted handshake messages
with the exception of the GroupInfo signature and the GroupInfo
extensions. This document defines a PartialGroupInfo struct that
contains these missing items. It can be included with a commit and
any referenced proposals to reconstruct a GroupInfo and ratchet_tree
from the GroupInfo and ratchet_tree included in the previous epoch.
enum {
no_ratchet_tree(0),
present(1),
removed(2),
added(3),
(255)
} RatchetTreePresence;
struct {
RatchetTreePresence ratchet_tree_presence;
/* GroupInfo extensions excluding ratchet_tree */
Extension group_info_extensions<V>;
opaque Signature<V>;
} PartialGroupInfo;
The value of the ratchet_tree_presence is defined as follows:
* no_ratchet_tree: the ratchet_tree extension appears in neither the
current nor previous epochs.
* present: there is a ratchet_tree extension in both the current and
previous epochs.
* removed: there was a ratchet_tree extension in the previous epoch
but none in the current epoch.
Mahy Expires 22 September 2024 [Page 5]
Internet-Draft Ratchet tree options in MLS March 2024
* added: there is a ratchet_tree extension in the current epoch but
there was none in the previous epoch.
The group_info_extensions object is the list of GroupInfo extensions,
omitting any ratchet_tree extension (if present). The only other
GroupInfo extension defined in the base protocol is external_pub, the
public key of the external commiter. The group_info_extensions is
often an empty list.
The Signature in the PartialGroupInfo is the signature produced by
the committer (represented by leaf index in the GroupInfo as the
signer).
5. Security Considerations
TODO Security
6. IANA Considerations
This document has no IANA actions.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
7.2. Informative References
[I-D.barnes-mimi-arch]
Barnes, R., "An Architecture for More Instant Messaging
Interoperability (MIMI)", Work in Progress, Internet-
Draft, draft-barnes-mimi-arch-03, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-barnes-mimi-
arch-03>.
Mahy Expires 22 September 2024 [Page 6]
Internet-Draft Ratchet tree options in MLS March 2024
[I-D.mahy-mls-xwing]
Mahy, R., "Messaging Layer Security Ciphersuite using
XWing Key Exchange Mechanism", Work in Progress, Internet-
Draft, draft-mahy-mls-xwing-00, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-mahy-mls-
xwing-00>.
[I-D.robert-mimi-delivery-service]
Robert, R. and K. Kohbrok, "MIMI Delivery Service", Work
in Progress, Internet-Draft, draft-robert-mimi-delivery-
service-06, 6 November 2023,
<https://datatracker.ietf.org/doc/html/draft-robert-mimi-
delivery-service-06>.
Acknowledgments
The PartialGroupInfo was first introduced in
[I-D.robert-mimi-delivery-service].
Author's Address
Rohan Mahy
Unaffiliated
Email: rohan.ietf@gmail.com
Mahy Expires 22 September 2024 [Page 7]