| Internet-Draft | Wire formats without authenticated_data | October 2024 |
| Pham, et al. | Expires 24 April 2025 | [Page] |
This document describes an extension to support two new wire formats for MLS messages: PublicMessageWithoutAAD and PrivateMessageWithoutAAD.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-pham-mls-additional-wire-formats/.¶
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/anhph0/mls-additional-wire-formats.¶
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 24 April 2025.¶
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.¶
Sometimes it is desirable to have additional authenticated data to be included in the computation of MLSMessage constructions, but not to have it sent on the wire as part of these messages. A use-case is applications that want to have some information available to the server together with a MLSMessage and at the same time want to prove the authenticity of the information to other clients.¶
An example of this is the case of delivery receipts where the server needs to know that a message from Alice has been delivered to Bob, but at the same time it wants Alice to be able to verify that the delivery receipt indeed comes from Bob.¶
This document proposes an extension to support new wire formats for MLS PrivateMessage and PublicMessage to support such cases. Applications will inject additional data as part of the MLSMessage computation, but the additional data is not included in the MLSMessage.¶
Note that it is the application's responsibility to know what needs to be used as additional data when it processes messages with these new wire formats.¶
struct {
ExtensionType extension_type;
opaque extension_data<V>;
} ExtensionContent;
¶
extension_type is a unique uint16 identifier registered in MLS Extension Types IANA registry (see Section 17.3 of [RFC9420]). This extension uses the mls_extension_message WireFormat as defined in Section 2.1.7.1 of the Extensions Framework, where the extension_data is TLS-serialized MessageWithoutAAD.¶
enum {
PublicMessageWithoutAAD(0),
PrivateMessageWithoutAAD(1),
} MessageWithoutAAD;
¶
uint16 WireFormat;
struct {
opaque group_id<V>;
uint64 epoch;
Sender sender;
ContentType content_type;
select (FramedContent.content_type) {
case application:
opaque application_data<V>;
case proposal:
Proposal proposal;
case commit:
Commit commit;
};
} FramedContentWithoutAAD;
¶
FramedContentWithoutAAD is authenticated using the same procedure for FramedContent described in Section 6.1 of [RFC9420]. A difference is that in the FramedContentTBS definition, we have FramedContent with authenticated_data being injected from the outside by the application.¶
Moreover, the signature in the FramedContentAuthData is computed by using SafeExtension.¶
SignWithLabel(SignatureKey, "LabeledExtensionContent", LabeledExtensionContent)¶
where LabeledExtensionContent is defined as:¶
label = Label extension_type = ExtensionType extension_data = FramedContent¶
with authenticated_data being injected to FramedContent by the application.¶
struct {
FramedContentWithoutAAD content;
FramedContentAuthData auth;
select (PublicMessageWithoutAAD.content.sender.sender_type) {
case member:
MAC membership_tag;
case external:
case new_member_commit:
case new_member_proposal:
struct{};
};
} PublicMessageWithoutAAD;
¶
The membership_tag in the PublicMessageWithoutAAD authenticates the sender's membership in the group. It is computed as follows:¶
membership_tag = MAC(membership_key, AuthenticatedContentTBM)¶
with AuthenticatedContentTBM and membership_key as defined as in the [RFC9420]. authenticated_data in the FramedContent is injected by the application.¶
struct {
opaque group_id<V>;
uint64 epoch;
ContentType content_type;
opaque encrypted_sender_data<V>;
opaque ciphertext<V>;
} PrivateMessageWithoutAAD;
¶
Similar to PrivateMessage, encrypted_sender_data and ciphertext are encrypted using the AEAD function specified by the cipher suite in use, using the SenderData and PrivateMessageContent structures as input.¶
The SenderData is encrypted using the sender_data_secret of the group.¶
The actual message content is encrypted using the key derived as follows:¶
Derive a secret as defined in Section 2.1.5 of the Extensions Framework:¶
DeriveExtensionSecret(Secret, Label) = ExpandWithLabel(epoch_secret, "ExtensionExport " + ExtensionType + " " + Label)
¶
Use the the secret in lieu of encryption_tree to seed the Secret Tree (Section 9 of [RFC9420]).¶
Follow the procedure of the Secret Tree to generate encryption keys and nonces for the encryption of the message content.¶
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.¶
No implications on the security of the base MLS protocol due to the use of SafeExtension.¶
This document requests the addition of various new values under the heading of "Messaging Layer Security".¶