<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-mahy-dispatch-immi-mls-mime-00" submissionType="IETF" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">

<front>
<title abbrev="MLS MIME type Extensions">Inside MLS Message Interop (IMMI) MIME type extensions</title><seriesInfo value="draft-mahy-dispatch-immi-mls-mime-00" stream="IETF" status="informational" name="Internet-Draft"></seriesInfo>
<author initials="R." surname="Mahy" fullname="Rohan Mahy"><organization>Wire</organization><address><postal><street></street>
</postal><email>rohan.mahy@wire.com</email>
</address></author><date/>
<area>art</area>
<workgroup>dispatch</workgroup>
<keyword>mls</keyword>
<keyword>mime</keyword>

<abstract>
<t>This document defines two new extensions to the MLS (Messaging Layer Security) Protocol
to allow for negotiation of MIME types exchanged among members of an MLS group.</t>
</abstract>

</front>

<middle>

<section anchor="terminology"><name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to
be interpreted as described in RFC 2119 <xref target="RFC2219"></xref>.</t>
<t>The terms MLS client, MLS group, and KeyPackage have the same meanings as in
the MLS protocol <xref target="I-D.ietf-mls-protocol"></xref>.</t>
</section>

<section anchor="introduction"><name>Introduction</name>
<t>MLS is a group key establishment protocol motivated
by the desire for group chat with efficient end-to-end encryption. While one
of the motivations of MLS is interoperable standards-based secure messaging,
the MLS protocol does not define or prescribe any format for the encrypted
&quot;application messages&quot; encoded by MLS. This document describes two extensions
to MLS which allow MLS clients to advertise their supported MIME types, and
to specify which MIME types are required for a particular MLS group. These
allow clients to discover MLS groups with an interoperable and extensible set
of content types.</t>
<t>A companion document <xref target="I-D.mahy-dispatch-immi-content"></xref> describes a specific
profile for interoperable instant messaging body types.</t>
</section>

<section anchor="extension-description"><name>Extension Description</name>
<t>This document specifies two MLS extensions of type MimeTypeList:
<tt>accepted_mime_types</tt>, and <tt>required_mime_types</tt>.</t>
<t>MimeType is the ASCII string encoded as a TLS vector type containing a
single MIME type and any of its parameters.</t>
<t>MimeTypeList is an ordered list of MimeType objects.</t>

<artwork>// Text string representation of a single IANA registered MIME Type.
MimeType mime_type&lt;V&gt;

struct {
    MimeType mime_types&lt;V&gt;
} MimeTypeList

</artwork>
<t>Example MIME Types:</t>

<artwork>image/png
text/plain;charset=&quot;UTF-8&quot;
</artwork>
<t>An MLS client which implements this specification SHOULD include the
<tt>accepted_mime_types</tt> extensions in its KeyPackages, listing
all the MIME types it can receive.</t>
<t>When creating a new MLS group, the group MAY include a <tt>required_mime_type</tt>
extension in the group Extensions.  When used in a group, the client
MUST include the <tt>required_mime_types</tt> extension in the list of extensions
in RequiredCapabilities.</t>
<t>MLS clients SHOULD NOT add an MLS client to an MLS group with <tt>required_mime_types</tt>
unless the MLS client advertises it can support all of the required MIME
Types. As an exception, a client could be preconfigured to know that
certain clients support the mandatory types.</t>
</section>

<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document proposes registration of two MLS Extension Types.</t>

<section anchor="accepted-mime-types-mls-extension-type"><name>accepted_mime_types MLS Extension Type</name>
<t>The accepted_mime_types MLS Extension Type is used inside KeyPackage objects. It
contains a MimeTypeList representing all the MIME Types supported by the
MLS client publishing the KeyPackage.</t>

<artwork>Template:
Value: 0x0005
Name: accepted_mime_types

Message(s): This extension may appear in KeyPackage objects
Recommended: Y
Reference: RFC XXXX
</artwork>
<t>Description: list of MIME types supported by the MLS client advertising the KeyPackage</t>
</section>

<section anchor="required-mime-types-groupcontext-extension"><name>required_mime_types GroupContext extension</name>
<t>The required_mime_types MLS Extension Type is used inside GroupContext objects. It
contains a MimeTypeList representing the MIME Types which are mandatory for all
MLS members of the group to support.</t>

<artwork>Template:
Value: 0x0006
Name: required_mime_types

Message(s): This extension may appear in GroupContext objects
Recommended: Y
Reference: RFC XXXX
</artwork>
<t>Description: list of MIME types which every member of the MLS group is
required to support.</t>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>The Security Considerations of MLS apply.</t>
<t>Use of the extensions in this document
could leak some private information both in KeyPackages and inside an MLS group.
They
could be used to infer a specific implementation, platform, or even version.
Clients should consider carefully the implications in their environment of
making a list of acceptable MIME types available.</t>
<t>A client which can take over group administration could prevent members from
joining or sending messages in an established group, by requiring a list of
required MIME types which the attacker knows is unsupported. This attack is
not especially helpful, as taking over group administration can have more
disruptive effects.</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-mls-protocol.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2219.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="I-D.mahy-dispatch-immi-content" target="">
  <front>
    <title>Inside MLS Message Interop (IMMI) instant message content</title>
    <author fullname="Rohan Mahy">
      <organization>Wire</organization>
    </author>
    <date year="2022" month="March" day="7"></date>
  </front>
  <format type="TXT" target="https://www.ietf.org/archive/id/draft-mahy-dispatch-immi-content-00.txt"></format>
  <seriesInfo name="Internet-Draft" value="draft-mahy-dispatch-immi-content-00"></seriesInfo>
</reference>
</references>

</back>

</rfc>
