Internet DRAFT - draft-robert-mls-extensions
draft-robert-mls-extensions
Network Working Group R. Robert
Internet-Draft 27 May 2022
Intended status: Informational
Expires: 28 November 2022
The Messaging Layer Security (MLS) Extensions
draft-robert-mls-extensions-00
Abstract
This document describes extensions to the Messaging Layer Security
(MLS) protocol.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/mlswg/mls-extensions.
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/.
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 28 November 2022.
Copyright Notice
Copyright (c) 2022 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
Robert Expires 28 November 2022 [Page 1]
Internet-Draft MLS May 2022
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. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. AppAck . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1.1. Description . . . . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
3.1. Extended MLS Extension types . . . . . . . . . . . . . . 4
3.2. Extended MLS Proposal types . . . . . . . . . . . . . . . 5
4. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This document describes extensions to the Messaging Layer Security
(MLS) protocol that are not part of the main protocol specification.
The protocol specification includes a set of core extensions that are
likely to be useful to many applications. The extensions described
in this document are intended to be used by applications that need to
extend the MLS protocol.
2. Extensions
2.1. AppAck
Type: Proposal
2.1.1. Description
An AppAck proposal is used to acknowledge receipt of application
messages. Though this information implies no change to the group, it
is structured as a Proposal message so that it is included in the
group's transcript by being included in Commit messages.
struct {
uint32 sender;
uint32 first_generation;
uint32 last_generation;
} MessageRange;
struct {
MessageRange received_ranges<V>;
} AppAck;
Robert Expires 28 November 2022 [Page 2]
Internet-Draft MLS May 2022
An AppAck proposal represents a set of messages received by the
sender in the current epoch. Messages are represented by the sender
and generation values in the MLSCiphertext for the message. Each
MessageRange represents receipt of a span of messages whose
generation values form a continuous range from first_generation to
last_generation, inclusive.
AppAck proposals are sent as a guard against the Delivery Service
dropping application messages. The sequential nature of the
generation field provides a degree of loss detection, since gaps in
the generation sequence indicate dropped messages. AppAck completes
this story by addressing the scenario where the Delivery Service
drops all messages after a certain point, so that a later generation
is never observed. Obviously, there is a risk that AppAck messages
could be suppressed as well, but their inclusion in the transcript
means that if they are suppressed then the group cannot advance at
all.
The schedule on which sending AppAck proposals are sent is up to the
application, and determines which cases of loss/suppression are
detected. For example:
* The application might have the committer include an AppAck
proposal whenever a Commit is sent, so that other members could
know when one of their messages did not reach the committer.
* The application could have a client send an AppAck whenever an
application message is sent, covering all messages received since
its last AppAck. This would provide a complete view of any losses
experienced by active members.
* The application could simply have clients send AppAck proposals on
a timer, so that all participants' state would be known.
An application using AppAck proposals to guard against loss/
suppression of application messages also needs to ensure that AppAck
messages and the Commits that reference them are not dropped. One
way to do this is to always encrypt Proposal and Commit messages, to
make it more difficult for the Delivery Service to recognize which
messages contain AppAcks. The application can also have clients
enforce an AppAck schedule, reporting loss if an AppAck is not
received at the expected time.
3. IANA Considerations
This document requests the creation of the following new IANA
registries:
Robert Expires 28 November 2022 [Page 3]
Internet-Draft MLS May 2022
* MLS Extension Types (Section 3.1)
* MLS Proposal Types (Section 3.2)
All of these registries should be under a heading of "Messaging Layer
Security", and assignments are made via the Specification Required
policy [RFC8126].
RFC EDITOR: Please replace XXXX throughout with the RFC number
assigned to this document
3.1. Extended MLS Extension types
This registry lists identifiers for extensions to the MLS protocol.
The extension type field is two bytes wide, so valid extension type
values are in the range 0x0000 to 0xffff.
Template:
* Value: The numeric value of the extension type. Extended MLS
extension types start with the value 0x0100.
* Name: The name of the extension type
* Message(s): The messages in which the extension may appear, drawn
from the following list:
- KP: KeyPackage objects
- LN: LeafNode objects
- GC: GroupContext objects (and the group_context_extensions
field of GroupInfo objects)
- GI: The other_extensions field of GroupInfo objects
* Recommended: Whether support for this extension is recommended by
the IETF MLS WG. Valid values are "Y" and "N". The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N
transition.
* Reference: The document where this extension is defined
Initial contents:
Robert Expires 28 November 2022 [Page 4]
Internet-Draft MLS May 2022
+=======+======+============+=============+===========+
| Value | Name | Message(s) | Recommended | Reference |
+=======+======+============+=============+===========+
| N/A | N/A | N/A | N/A | RFC XXXX |
+-------+------+------------+-------------+-----------+
Table 1
3.2. Extended MLS Proposal types
This registry lists identifiers for types of proposals that can be
made for changes to an MLS group. The extension type field is two
bytes wide, so valid extension type values are in the range 0x0000 to
0xffff.
Template:
* Value: The numeric value of the proposal type. Extended MLS
proposal types start with the value 0x0100.
* Name: The name of the proposal type
* Recommended: Whether support for this extension is recommended by
the IETF MLS WG. Valid values are "Y" and "N". The "Recommended"
column is assigned a value of "N" unless explicitly requested, and
adding a value with a "Recommended" value of "Y" requires
Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N
transition.
* Path Required: Whether a Commit covering a proposal of this type
is required to have its path field populated.
* Reference: The document where this extension is defined
Initial contents:
+========+=========+=============+===============+===========+
| Value | Name | Recommended | Path Required | Reference |
+========+=========+=============+===============+===========+
| 0x0100 | app_ack | Y | Y | RFC XXXX |
+--------+---------+-------------+---------------+-----------+
Table 2
4. Normative References
Robert Expires 28 November 2022 [Page 5]
Internet-Draft MLS May 2022
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
Author's Address
Raphael Robert
Email: ietf@raphaelrobert.com
Robert Expires 28 November 2022 [Page 6]
