Subject: [MLS] recap of discussion: describing contents of MLS application_data

From: Rohan Mahy <[email-masked]>
Date: Wed, 23 Mar 2022 10:14:23 -0700

Hi,
I am going to try to summarize what I heard today. I think I heard three
options proposed:

1) There should be a field in MlsCiphertext/MlsPlaintext which describes
the format of the application_data.
2) There should be at least one extra framing layer inside MLS which can
describe the format of the rest of the application_data.
3) Each "application" should define its content and if it needs an extra
framing layer.

Reviewing these options:
1) Can be optional. One concrete proposal is defined (use the string in the
MIME type registry) which supports existing and new types including
vendor-defined types. Could specify a type that allows for further
precision or negotiation in any convenient format (TLS presentation syntax,
JSON, CBOR, Protobuf, etc.). Some future GroupInfo extension could override
this behavior. Nobody argued any concrete technical reason why this
approach would not work.

2) This would work fine, but it would need to be defined. Like #1 it could
be defined to be a single byte if it is not used. I can see some small
advantage over #1 if you wanted to replicate multipart MIME behavior with
explicit lengths instead of using boundary markers. Some future GroupInfo
extension could override this behavior. Nobody argued any concrete
technical reason why this would be superior to #1.

3) Effectively, this means defining some kind of framework with guidance
about how applications define the format. This seems needlessly
complicated, especially as nobody provided an existence proof of any
feature that could not be accomplished by approach #1 or #2.

I heard a lot of people say things today like "define later" and "future
work". Coming from the applications perspective, I find this completely
unacceptable. Imagine some artarea WG defined a new protocol and then
decided that it was going to add security later. The IETF security
community would be outraged, and with good reason. If we don't define some
minimum behavior now, we are creating a mess to cleanup later.

I predict that if the MLS WG does not define something, it will take about
30 seconds for the artarea ADs to slap a DISCUSS on the protocol document
until a comprehensive application_data negotiation mechanism is defined and
included.

Thanks,
-rohan

*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire

Wire <https://wire.com/en/download/> - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675

---

From: Richard Barnes <[email-masked]>
Date: Wed, 23 Mar 2022 15:21:28 -0400

I'm not as convinced that this is a DISCUSS risk as you are :)  After all,
TLS still doesn't have ALPN required!

On the contrary, I'm pretty sanguine that the application bytes handled by
MLS should be opaque to the MLS library.  I don't even think the ALPN
analogy really applies -- the only reason you need ALPN in that case is
that TLS is the only negotiation layer you have,  In MLS deployment cases,
I expect there to be more negotiation surface since it's not running right
on the transport.

I agree that in a lot of cases applications will want to send payloads that
have defined structures, for which MIME media types are a good descriptor.
As we learned with external/preconfigured keys, though, you can't just slap
an indicator in there -- you need a group extension to make sure everybody
will process it the same.  For that, draft-mahy-dispatch-immi-mls-mime is
right on the money.

So my counter-offer here is: Let's take #605 and port it over to that
document.  That way, you have a complete story:

- Clients advertise what MIME types they support
- Groups specify what MIME types are required
- Messages specify what MIME types they carry

The spec text would basically be as follows:

> When this extension is negotiated in a group, the `application_data`
field of an
> MLSMessage with type `application` MUST begin with a MIME media tyle
label of
> the following form:
>
> ~~~
> opaque media_type<V>;
> ~~~
>
> The `media_type` value MUST contain an ASCII-encoded MIME type label
{{cite}}.
> The remaining bytes of the `application_data` MUST be formatted as
specified by
> the media type.

That way, we end up with a fully coherent system when you're dealing in
MIME-identified data types (not just slapping on a MIME type label), while
still preserving the generality of the underlying protocol.

How does that strike you?

--Richard

[1] https://datatracker.ietf.org/doc/draft-mahy-dispatch-immi-mls-mime/

On Wed, Mar 23, 2022 at 1:14 PM Rohan Mahy <rohan.mahy=
[email-masked]> wrote:

> 1) Can be optional. One concrete proposal is defined (use the string in
> the MIME type registry) which supports existing and new types including
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Mar 2022 13:48:29 -0700

On Wed, Mar 23, 2022 at 10:14 AM Rohan Mahy <rohan.mahy=
[email-masked]> wrote:

>  I am going to try to summarize what I heard today. I think I heard
> three options proposed:
>
> 1) There should be a field in MlsCiphertext/MlsPlaintext which
> describes the format of the application_data.
>
> 2) There should be at least one extra framing layer inside MLS which
> can describe the format of the rest of the application_data.
>
> 3) Each "application" should define its content and if it needs an
> extra framing layer.
>
> Reviewing these options:
> 1) Can be optional. One concrete proposal is defined (use the string
> in the MIME type registry) which supports existing and new types
> including vendor-defined types. Could specify a type that allows for
> further precision or negotiation in any convenient format (TLS
> presentation syntax, JSON, CBOR, Protobuf, etc.). Some future
> GroupInfo extension could override this behavior. Nobody argued any
> concrete technical reason why this approach would not work.
>
> 2) This would work fine, but it would need to be defined. Like #1 it
> could be defined to be a single byte if it is not used. I can see some
> small advantage over #1 if you wanted to replicate multipart MIME
> behavior with explicit lengths instead of using boundary markers. Some
> future GroupInfo extension could override this behavior. Nobody argued
> any concrete technical reason why this would be superior to #1.
>
> 3) Effectively, this means defining some kind of framework with
> guidance about how applications define the format. This seems
> needlessly complicated, especially as nobody provided an existence
> proof of any feature that could not be accomplished by approach #1 or
> #2.

The question I am concerned with is not whether (1) or (2) will "work"
but rather what the correct layer to define this functionality is. As
I indicated during the meeting, MLS is a generic mechanism that is
intended to be embedded within a specific application.  It is the job
of that application to determine what kind of data it wishes to carry
around and what mechanism it wishes to use to indicate those types.

Indeed, any future application is free to define exactly the mechanism
you propose above for (1), or any other mechanism of its choice. Indeed,
as I understand your description of (1) above, a GroupInfo extension
would be allowed to override the default mechanism, so it seems
we are merely debating over whether there ought to be a default and
if so what it ought to be.

> I heard a lot of people say things today like "define later" and
> "future work". Coming from the applications perspective, I find this
> completely unacceptable. Imagine some artarea WG defined a new
> protocol and then decided that it was going to add security later. The
> IETF security community would be outraged, and with good reason.

I don't consider this to be a particularly sound analogy, because, as
I said, this is not a complete system but rather a building block for
other systems. It's no more surprising that the type of the data that
is being carried is externally determined than that RFC 5116 does
require that each plaintext block indicate the type of data that is
carried.  Rather, that is determined by context, as is the case
here.

Indeed, the apps area *does* define new protocol building blocks
without defining associated security mechanisms. Both CBOR and JSON
were defined precisely in this way. Of course, when they are embedded
in some concrete protocol, security needs to be provided, as is the
case here.

> If we
> don't define some minimum behavior now, we are creating a mess to
> cleanup later.

Can you please lay out in some more detail what the nature of that
mess is?

> I predict that if the MLS WG does not define something, it will take
> about 30 seconds for the artarea ADs to slap a DISCUSS on the protocol
> document until a comprehensive application_data negotiation mechanism
> is defined and included.

Like Richard, I do not particularly expect this to be a topic of
a DISCUSS. I would observe that in a recent situation (QUIC datagram),
we did something quite similar to what is being proposed here
for multiplexing and AFAICT the IESG was fine with it.

   Identifiers used to multiplex different kinds of datagrams, or flows
   of datagrams, are the responsibility of the application protocol
   running over QUIC to define.  The application defines the semantics
   of the Datagram Data field and how it is parsed.

   If the application needs to support the coexistence of multiple flows
   of datagrams, one recommended pattern is to use a variable-length
   integer at the beginning of the Datagram Data field.  This is a
   simple approach that allows a large number of flows to be encoded
   using minimal space.

Fortunately, however, we don't need to guess. I've CCed the ART ADs on
this thread, so let's hear from them whether they think this would
merit a DISCUSS.

-Ekr

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 24 Mar 2022 09:13:55 +0100

Hi Rohan, Hi all,

A few thoughts below...

> On 23 Mar 2022, at 21:48, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Mar 23, 2022 at 10:14 AM Rohan Mahy <rohan.mahy=[email-masked] <mailto:[email-masked]>> wrote:
> 

I agree with Ekr here, to me it is also about “at what layer should this happen?”.

I am against the first two options because the field in 1. and the framing in 2. are not needed by the 
MLS protocol itself and we designed MLS to carry opaque bytes in order to avoid the issues related to mixing the layers.

Also the burden of proof is reversed here… : ), can someone prove that no application
will be blocked by having only one byte as an mime identifier or a specific framing if they want to
send two different payload types in a single application data message for example.

These are restrictions after all...

More generally,

The confidential content needed by the application must be encrypted in the application data.
The authenticated-only content can be send in the authenticated header or the non-encrypted messages.
The non-protected content can be send through the secure transport channel directly (TLS, QUIC, whatever).

An MLS based application must have negotiated a way to serialize/parse at least the first application message.
From that point on, the application can do whatever it wants with the opaque application data including changing
the formats of the application messages, semantics of the existing framings...

Our design goals include that the MLS protocol layer must enforce the least constraints on the applications.

Again, as Ekr said, if more information must be exchanged for federation or discovery because
these applications haven’t settled on something prior to the first message, then we have built the
extension mechanism.

Regarding the DISCUSS, I am interested by the opinions of the ADs but we are designing an
application agnostic security protocol which conveys opaque bytes here…

Best,
Benjamin

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 24 Mar 2022 08:23:17 -0700

I will keep my comments short to avoid rehashing.

I am against the first two options because the field in 1. and the framing
> in 2. are not needed by the
> MLS protocol itself and we designed MLS to carry opaque bytes in order to
> avoid the issues related to mixing the layers.
>
In my opinion, describing the next layer is a core feature of protocols,
and not "mixing layers". IP describes the transport protocol. Transport
protocols include a port number, HTTP and SIP include a Content-Type
header, XMPP has , JSON and XML use namespaces and schemas to describe
their contents. HTTP has dozens of applications, but nobody complains that
it has a default content description field. While I may never be able to
convince those who think that MLS is "special" and that the "application"
should define the contents of MLS, hopefully I have shown that there is
abundant evidence that my point of view is not unusual in IETF protocols.

Also the burden of proof is reversed here… : ), can someone prove that no
> application
Maybe you didn't read my proposal [1]. The mime_type field is preceded by a
length. If the length of the mime_type is zero bytes, then the overhead
used by this field is a single byte. When a mime_type is conveyed, the
overhead is the length of the string plus 1 (usually) or 2 (for very long
mime_types) bytes. There are currently hundreds of mime types defined and a
vendor can register a new */vnd.* mime type by just publishing a
specification (no IETF protocol action is required). Sending multiple types
has been well specified since the 1990s (see the multipart mime types [2]).
Existing semantics for sending alternative versions (ex:a proprietary
version and an interoperable baseline, or the same content in multiple
languages) was a main motivator for my usage. The Internet community has
roughly three decades of experience expressing the contents of payloads
using MIME types. I would be astounded if there is something you cannot
convey or express using this structure. Feel free to propose an
alternative, but no, the burden of proof is not reversed.

Our design goals include that the MLS protocol layer must enforce the least
> constraints on the applications.
>
I believe that my pull request qualifies. It provides a straightforward,
default way for applications to convey the contents. If they do not require
that in their application, they do not need to use it. If they want
something different or more complicated, they can still do that.
There is much upside to having a default mechanism and very little downside.

Thanks,
-rohan

[1] https://github.com/mlswg/mls-protocol/pull/605/files
[2] https://datatracker.ietf.org/doc/html/rfc2046

VAT-ID DE288748675

On Thu, Mar 24, 2022 at 1:14 AM Benjamin Beurdouche <
[email-masked]> wrote:

> MLS protocol itself and we designed MLS to carry opaque bytes in order to
> avoid the issues related to mixing the layers.
>
> From that point on, the application can do whatever it wants with the
> opaque application data including changing

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 24 Mar 2022 08:42:43 -0700

Hi Ekr,
Thanks for cc:ing Murray and Francesca. Yes, I think it is better to go
straight to the source.

Yes, to be clear I feel there ought to be a default mechanism to
communicate the content. I don't actually care if it is the mechanism I
proposed, but I haven't heard any complaints that the mechanism I proposed
would not work.

Philosophically, I guess you are looking at MLS like a protocol building
block like CBOR, and I am looking at it like a protocol which many
applications can use in concert with other defined protocols rather than
needing substantial new IETF protocol definition for each application (like
HTTP). The mess I alluded to is the interoperability disaster when two or
more similar applications define basic building blocks differently (like
what is the contents I am sending) because we leave everything up to the
application instead of defining sensible default behavior.

Thanks,
-rohan

VAT-ID DE288748675

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Mar 2022 10:19:40 -0700

> proposed, but I haven't heard any complaints that the mechanism I proposed

I agree it would work. Indeed, I think it's quite plausible that if I were
designing a system that I might use a design like the one you propose.
Rather, I think this is an architectural issue; as, I suppose, do you.

> HTTP).

I think that's a fair summary of our views.

The mess I alluded to is the interoperability disaster when two or more
> similar applications define basic building blocks differently (like what is
> the contents I am sending) because we leave everything up to the

I think I'd need to hear more about how you think that might happen.
There's a huge amount of work required to make a workable messaging system
even with the security piece nailed down, and even more to make it
interoperable, so my feeling is that this is the least of the problems.

-Ekr

---

From: thomas leavy <[email-masked]>
Date: Fri, 25 Mar 2022 16:02:13 -0400

I would agree with the comments here that application data transported by MLS should be opaque and it is unnecessary to enforce a format description in application data. 

The way I view this problem overall is that interop of application layer data is something that can’t be solved by a format description alone in practice, and can be solved independent of MLS without modifying the core MLS protocol. It is easy enough to define an extension that tries to work towards application layer interop and applications can choose to adopt it if necessary. 

- Tom

> On Mar 23, 2022, at 3:21 PM, Richard Barnes <[email-masked]> wrote:
> 
> 
> I'm not as convinced that this is a DISCUSS risk as you are :)  After all, TLS still doesn't have ALPN required!
> 
> On the contrary, I'm pretty sanguine that the application bytes handled by MLS should be opaque to the MLS library.  I don't even think the ALPN analogy really applies -- the only reason you need ALPN in that case is that TLS is the only negotiation layer you have,  In MLS deployment cases, I expect there to be more negotiation surface since it's not running right on the transport.
> 
> I agree that in a lot of cases applications will want to send payloads that have defined structures, for which MIME media types are a good descriptor.  As we learned with external/preconfigured keys, though, you can't just slap an indicator in there -- you need a group extension to make sure everybody will process it the same.  For that, draft-mahy-dispatch-immi-mls-mime is right on the money.
> 
> So my counter-offer here is: Let's take #605 and port it over to that document.  That way, you have a complete story:
> 
> > When this extension is negotiated in a group, the `application_data` field of an
> > MLSMessage with type `application` MUST begin with a MIME media tyle label of
> > the following form:
> > 
> > ~~~
> > opaque media_type<V>; 
> > ~~~
> > 
> > The `media_type` value MUST contain an ASCII-encoded MIME type label {{cite}}.
> > The remaining bytes of the `application_data` MUST be formatted as specified by
> > the media type.
> 
> That way, we end up with a fully coherent system when you're dealing in MIME-identified data types (not just slapping on a MIME type label), while still preserving the generality of the underlying protocol.
> 
> On Wed, Mar 23, 2022 at 1:14 PM Rohan Mahy <rohan.mahy=[email-masked]> wrote:
>> Hi,
>> I am going to try to summarize what I heard today. I think I heard three options proposed: 
>> 
>> 1) There should be a field in MlsCiphertext/MlsPlaintext which describes the format of the application_data.
>> 2) There should be at least one extra framing layer inside MLS which can describe the format of the rest of the application_data.
>> 3) Each "application" should define its content and if it needs an extra framing layer.
>> 
>> Reviewing these options:
>> 1) Can be optional. One concrete proposal is defined (use the string in the MIME type registry) which supports existing and new types including vendor-defined types. Could specify a type that allows for further precision or negotiation in any convenient format (TLS presentation syntax, JSON, CBOR, Protobuf, etc.). Some future GroupInfo extension could override this behavior. Nobody argued any concrete technical reason why this approach would not work. 
>> 
>> 2) This would work fine, but it would need to be defined. Like #1 it could be defined to be a single byte if it is not used. I can see some small advantage over #1 if you wanted to replicate multipart MIME behavior with explicit lengths instead of using boundary markers. Some future GroupInfo extension could override this behavior. Nobody argued any concrete technical reason why this would be superior to #1.
>> 
>> 3) Effectively, this means defining some kind of framework with guidance about how applications define the format. This seems needlessly complicated, especially as nobody provided an existence proof of any feature that could not be accomplished by approach #1 or #2. 
>> 
>> I heard a lot of people say things today like "define later" and "future work". Coming from the applications perspective, I find this completely unacceptable. Imagine some artarea WG defined a new protocol and then decided that it was going to add security later. The IETF security community would be outraged, and with good reason. If we don't define some minimum behavior now, we are creating a mess to cleanup later.
>> 
>> I predict that if the MLS WG does not define something, it will take about 30 seconds for the artarea ADs to slap a DISCUSS on the protocol document until a comprehensive application_data negotiation mechanism is defined and included.
>> 
>> Thanks,
>> -rohan
>> 
>> Rohan Mahy  l  Vice President Engineering, Architecture
>> 
>> Wire - Secure team messaging.
>> 
>> Zeta Project Germany GmbH  l  Rosenthaler Straße 40, 10178 Berlin, Germany
>>

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 28 Mar 2022 10:45:44 -0700

Hi Ekr,
I took my time over the weekend trying to come up with the best example of
the mess I fear could happen without a default way to convey the format of
application_data.

Imagine we have 6 implementations using MLS:

*#*

*Vendor*

*Type of Application*

*GI/KPextension*

*Framing*

*1*

U

Messaging

none

none

*2*

V

Messaging

extension A

JSON w/name spaces

*3*

W

Messaging

extension B

none

*4*

X

Messaging

extension C

TLP

*5*

V

IoT pub/sub bus

extension D

none

*6*

Z

Logging service

none

Protobuf

1. A new interoperable messaging standard becomes available, which has a
GroupInfo and KeyPackage extension "S". What is the migration path for the
4 messaging implementations? Without a way to convey which format is being
sent, our options are:

   - create a parallel group containing all the members in the original
   group who support S, and provide some breadcrumb in the original group that
   allows upgrading clients to find their way to the new group
   - have a flag day cutover to the new format, requiring a lot of
   out-of-band coordination
   - send both types. get lucky and use file magic to guess the received
   correct type, or hope that implementations robustly ignore formats they
   don't understand.

None of these options seems very attractive. By contrast, if the client can
assume a baseline default and convey the format of the application_data (or
use something with the semantics of multipart/alternative to send multiple
formats), a single MLS group could comfortably contain clients which only
use the format of one vendor, and implementations from another vendor which
also support the new interoperable standard. This would allow a graceful
migration.

2. Let's say that implementation 2 and implementation 4 both use GroupInfo
extensions which say that members of a group with their extension send all
their application_data using the relevant framing first (JSON or TLP
respectively) unless otherwise negotiated. When they choose to
interoperate, both vendors each implement the format of the other. It would
be logical to advertise both extensions in their KeyPackages, but when
forming a new group which format should one of the clients create? The
client creating a group can't know a priori if all future members of the
group are more likely to support the format of extension A or of extension
C.

3. Vendor X (enterprise) acquires vendor W (consumer). They want to
interoperate between their two proprietary products. As product W
implements the protocol used by product X, it has a similar all-or-nothing
migration route. Later vendor X implements the standard S. Now product W
has to decide implicitly based on the presence of *three* group and/or
keypackage extensions which format to send.

4. It's worth noting what is NOT part of the mess. If Vendor V wants to use
the same MLS library or the same DS/AS for the two applications it uses,
that should work fine because we never expect the two applications 1 and 5
to ever have clients in the same group.

I hope this helps.
Thanks,
-rohan

VAT-ID DE288748675

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 28 Mar 2022 10:57:11 -0700

Hi Thomas,

> It is easy enough to define an extension that tries to work towards
> application layer interop and applications can choose to adopt it if
> necessary.
>
I am not convinced it is so easy. I just sent a response to Ekr with some
scenarios that show how messy this could get without a default (or at least
RECOMMENDED) mechanism.

I want to point out that we are talking about implying the format of a
single message sent by a member to the group using either extensions set
for an entire group, and/or keypackage extensions (which are available for
use in unknown future groups). In this case I think explicitly describing
the application_data is much clearer.
Thanks,
-rohan

VAT-ID DE288748675

On Fri, Mar 25, 2022 at 1:02 PM thomas leavy <[email-masked]> wrote:

> I would agree with the comments here that application data transported
> by MLS should be opaque and it is unnecessary to enforce a format
> description in application data.
>
> The way I view this problem overall is that interop of application layer
> data is something that can’t be solved by a format description alone in
> practice, and can be solved independent of MLS without modifying the core
> MLS protocol. It is easy enough to define an extension that tries to work
> towards application layer interop and applications can choose to adopt it
> if necessary.
>
> - Tom
>
> I agree that in a lot of cases applications will want to send payloads
> that have defined structures, for which MIME media types are a good
> descriptor.  As we learned with external/preconfigured keys, though, you
> can't just slap an indicator in there -- you need a group extension to make
> sure everybody will process it the same.  For that,
> draft-mahy-dispatch-immi-mls-mime is right on the money.
>
>> small advantage over #1 if you wanted to replicate multipart MIME behavior
>> with explicit lengths instead of using boundary markers. Some future
>> concrete technical reason why this would be superior to #1.
>>
>> document until a comprehensive application_data negotiation mechanism is
>> defined and included.
>>
>> Thanks,
>> -rohan
>>