<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.24 (Ruby 3.4.1) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-mahy-mimi-msgid-aad-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title abbrev="MIMI Message ID in AAD">Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data</title>
    <seriesInfo name="Internet-Draft" value="draft-mahy-mimi-msgid-aad-00"/>
    <author fullname="Rohan Mahy">
      <organization>Your Organization Here</organization>
      <address>
        <email>rohan.mahy@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="April" day="22"/>
    <area/>
    <workgroup>More Instant Messaging Interoperability</workgroup>
    <keyword>message ID</keyword>
    <keyword>AAD</keyword>
    <keyword>Additional Authenticated Data</keyword>
    <keyword>message ID component</keyword>
    <abstract>
      <?line 38?>

<t>The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent.
This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://rohanmahy.github.io/mimi-msgid-aad/draft-mahy-mimi-msgid-aad.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-mahy-mimi-msgid-aad/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        More Instant Messaging Interoperability  mailing list (<eref target="mailto:mimi@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mimi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mimi/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/rohanmahy/mimi-msgid-aad"/>.</t>
    </note>
  </front>
  <middle>
    <?line 43?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Many messaging protocols and formats have a Message ID.
The MIMI content format defines how to calculate a MIMI Message ID <xref section="3.3" sectionFormat="of" target="I-D.ietf-mimi-content"/> for an application message.
A MIMI Message ID is currently only shared end-to-end encrypted with members of the MLS <xref target="RFC9420"/> group in which the message was sent.
This document defines an optional mechanism to share a Message ID in the
MLS AAD, so it is visible to intermediary providers.
This greatly facilitates debugging and troubleshooting, but causes a modest reduction in privacy.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="mechanism">
      <name>Mechanism</name>
      <t>This document defines a new Safe AAD <tt>message_id</tt> component as described in <xref section="4.9" sectionFormat="of" target="I-D.ietf-mls-extensions"/>.</t>
      <t>When the content of an MLS application message is a MIMI content message (media type <tt>application/mimi-content</tt>), if the <tt>message_id</tt> component is present inside <tt>SafeAAD.aad_items</tt>, it <bcp14>MUST</bcp14> contain the MIMI content Message ID calculated as described in <xref section="3.3" sectionFormat="of" target="I-D.ietf-mimi-content"/>.</t>
      <ul empty="true">
        <li>
          <t>To the extent that other application formats or media types have a Message ID, the Message ID for an application message of that type or format <bcp14>MAY</bcp14> be conveyed in this extension.</t>
        </li>
      </ul>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>An attacker with access to a fragment of message history, and the message logs of a MIMI provider in the path of a message could potentially learn more about the participants of a particular MIMI room or the room's corresponding MLS group.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="messageid-mls-component-type">
        <name>message_id MLS Component Type</name>
        <t>This document registers a new MLS Component Type in the Specification Required range with the following template:</t>
        <ul spacing="normal">
          <li>
            <t>Value: TBD (new assignment by IANA)</t>
          </li>
          <li>
            <t>Name: message_id</t>
          </li>
          <li>
            <t>Where: AD</t>
          </li>
          <li>
            <t>Recommended: Y</t>
          </li>
          <li>
            <t>Reference: RFC XXXX</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="I-D.ietf-mimi-content">
        <front>
          <title>More Instant Messaging Interoperability (MIMI) message content</title>
          <author fullname="Rohan Mahy" initials="R." surname="Mahy">
            <organization>Rohan Mahy Consulting Services</organization>
          </author>
          <date day="28" month="February" year="2025"/>
          <abstract>
            <t>   This document describes content semantics common in Instant Messaging
   (IM) systems and describes a profile suitable for instant messaging
   interoperability of messages end-to-end encrypted inside the MLS
   (Message Layer Security) Protocol.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-mimi-content-06"/>
      </reference>
      <reference anchor="RFC9420" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9420.xml">
        <front>
          <title>The Messaging Layer Security (MLS) Protocol</title>
          <author fullname="R. Barnes" initials="R." surname="Barnes"/>
          <author fullname="B. Beurdouche" initials="B." surname="Beurdouche"/>
          <author fullname="R. Robert" initials="R." surname="Robert"/>
          <author fullname="J. Millican" initials="J." surname="Millican"/>
          <author fullname="E. Omara" initials="E." surname="Omara"/>
          <author fullname="K. Cohn-Gordon" initials="K." surname="Cohn-Gordon"/>
          <date month="July" year="2023"/>
          <abstract>
            <t>Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9420"/>
        <seriesInfo name="DOI" value="10.17487/RFC9420"/>
      </reference>
      <reference anchor="RFC2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="I-D.ietf-mls-extensions" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mls-extensions.xml">
        <front>
          <title>The Messaging Layer Security (MLS) Extensions</title>
          <author fullname="Raphael Robert" initials="R." surname="Robert">
            <organization>Phoenix R&amp;D</organization>
          </author>
          <date day="19" month="February" year="2025"/>
          <abstract>
            <t>The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-mls-extensions-06"/>
      </reference>
    </references>
    <?line 105?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6VXbW/bNhD+zl/BKh+WDJHdtAHWGl1bN05RA3Hcxe66Yhga
SqJtIhKpkZQ9L8h/2W/ZL9tzlPyWt61YPsTU6Y53fO65OyqOY+aVz2WHRydG
z+VS6Sn3M8kHxkre184L7flAOiem9KqvvbSmlFYkKld+2byCao8rvaV4JpbS
8pFMK0tq3SxTXhktct6tsL/2KhVeZrwnvIiYSBIr5whi0B/0b+3Z7fYiRspT
Y5cdSCaGscykWhQIO7Ni4uNCzJZxoQoVF26qsliILH76lLkqKZRz8OuXJZT7
p+P3nO9xkTsDZ0pnspT4p310yCOJEI1VIqeHfvcdfozF6mL8PmK6KhJpOyxD
IB2WGu2kdpXrcG8ryRD6cyasFNg1Ygtjr6bWVCUd6L/hGLEruYRd1mE85sUa
AHoCAOHnMQh3rXhqitJoqLC51BUC5vybA+K8Bi2iZSFUjiVB/FZJP2kZOyW5
sOkM8pn3peu026RGIjWXrZVamwTtxJqFk23aoE2GU+VnVQJTa2ZCU/7au/kj
pRznc35r/7Vyq7ZvKXPLrP0gIVozX+QRYwLgGUs4wwPnkyrPaypFF7Q7H8A0
Cq8QvNDqT0God/gXU1k+3BLxD9LKoCgbeEJ4LfL9dkqiFvIAj9rYAhZz5IER
fTdPLI5jLhLnrUg9Y+NvKLx9KpUDZBovoFnvyjM5UVo6LvitSjokThSVbjhj
dL7k3oAzRGvHzaSu+ofqd39wNjqoOUQ1uZipdBYsVqRbCMdREr6FQyjHUZ9V
QXFtAlqI4NHNUCcU306RB+dno8dJzvdRCgfcGa48h5O5cirJJe0aTltaM1cZ
jtOqgS1UluWSsT1Cz5qsSmlrxgZCL5vA6agw8yY1OYLUWQOk4zMx3w2zVaeH
HD0A+swsKJZU5GlF1L2bBX59DUgDeZ63nhPqT/pxL5RKzdZm55sb2hvxcFGW
OUFAJg3WLda9sy/QQKYsTJHXkNyAc8bR3mJvYvxgmdplSWAuUDx3Ug/0r6+f
XLw/eXn87CkC+D/J1tyUTRoLmaIolCseTT4Lye+CpvdlVxH5C/RnYZfbWQ7e
p2i7dOqJSKkyqGUgkKSahuRSSpH7Cju5mTEeskOeVB5ZqlzgZWEyNBkOsGp+
UESlVXORLsEjkCcMRk2vaob06JSBpa4uWbRuTr3bobt+Go1pfNAvPx+G9cXp
T5/6F6c9Wo8+dM/O1gvWaIw+DD+d9TarjeXJcDA4Pe/VxpDyHRGLBt0veENR
RcOP4/7wvHsW1ZBu54VAB4yJrJEsrSQWCMdw8tSqBA+weXfy8e+/jo4bFjw7
OnoJFtQPL45+OMbDAgVZewsUqx+RvSUDTaWwtIvIc2BbIhG5gy6IgrLQfIZe
CTi//5WQ+a3DXyVpeXT8uhHQgXeEK8x2hAGzu5I7xjWI94jucbNGc0d+C+nd
eLtfdp5XuG8JX73JUQc8Pnrx5jULHBqsqoA92B+1XPCRmEgqA37ZlNpXlV1u
pjnBuZOyTTs5br281U5yF8s/0Ezo+uNubgD+Z+Qr1PGqf8GABh5K7542QzUo
dvvd6s1+qMVwP+CXW6bt7R52eXDIVd1bHjgNHICKLiwRZgZFAgDnb2Fef1Ve
Fu7ykNpB4AjtK1azYjusrW6y7r3ZI1j9S+sFUq/HJrgJAHos0eUNBHYHqNWo
QKfeAHLP5Djcmq0hyod7e92N4S1gC7VmxIB0VL5puKPX5wklvs5w3arW8xo9
iwC1omlTXXjzXqRXOELo/iJN4ZG6guATK6ZFw4dVHNgcl+FlXe3bvT830zAz
xO7MXQ3xUmDz8HplkJoqz3hpCElcrtE3crQKnJguOiIxlW8MLWa9KnHtafav
JcimrV1ZYwqChLRp/R1mnsHMc6BTRr2eiBymVg1Gv3vevQPE3h7fkDFYnKz5
OAbmt+vTyimQoDlZV+hdi9XJR6VM1WSVzwv5e6VoAFuhaWIS5qQ1MXluFuEr
SxZlHr4mWMx/Fjmu6Xz8rsf3yY3AV8tUhwiSZTjJAbTOwz11Ez9En6mxdjg+
EWL4pDsefdBkuK4GwQRvdQoFNHH+C/6aO2cCKhBG3fRKm0Uus0AAx6479YeO
zH6MJujgMroBIsPeEIRZaaKP/wPpsyFCOA4AAA==

-->

</rfc>
