Subject: [MLS] AppAck

From: Richard Barnes <[email-masked]>
Date: Sat, 21 Nov 2020 15:45:03 -0500

Hey all,

For one more "feature" before feature freeze, I've just posted a PR for an
AppAck proposal.  This is joint work with Raphael and Benjamin, who had the
idea of doing a proposal for this; I'm really just the scribe.

https://github.com/mlswg/mls-protocol/pull/442

This PR addresses issue #160, which dates all the way back to May 2019.
You may recall that Benjamin raised it on the IETF call last week.  The
idea is to enable the members of the group to detect when the DS drops
application messages.

Please take a look, and speak up with any comments.  I would like to merge
this (or decide not to) in the next week or so, so that we can get draft-11
out and begin feature freeze / analysis.

Thanks,
--Richard

---

From: Brendan McMillion <[email-masked]>
Date: Sun, 22 Nov 2020 14:07:11 -0800

Hey Richard

I wrote a lot about this in the discussion in #219 but to recap, I
generally don't think we should do this because:

1. We don't know how applications expect to lose messages, or what
properties on message delivery/order they want to ensure.
2. Applications can easily implement some algorithm for ensuring what they
want and keep that data in the AAD
3. If what we specify doesn't match exactly what applications want, they'll
have to do #2 anyway and we wasted our time.

If you had a construction that could bend to suit a large number of
application use-cases, I think that would be good to include in the
standard. But like you say in the PR, you're being fairly prescriptive in
terms of how you expect messages to be lost and what you want to guarantee.
Namely, a.) you expect infrequent loss, b.) clients only want to validate
receipt of messages at a Commit, and c.) you don't care about total message
ordering. I would say that probably won't cover even most use-cases.

On Sat, Nov 21, 2020 at 12:45 PM Richard Barnes <[email-masked]> wrote:

> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Joel Alwen <[email-masked]>
Date: Mon, 23 Nov 2020 17:34:22 +0100

If using the AppAck proposal is not mandatory and it would be useful to several
of the envisaged deployments (which sounds to be the case) I don't see this as
being too problematic. Though I do agree that other message loss policies also
make sense. (E.g. wanting eventual agreement on total ordering.)

Moreover, it should be quite easy to support these proposals since they have
almost no effect on the cryptographic state so are easy to process. Its really a
UX thing I think.

On 22/11/2020 23:07, Brendan McMillion wrote:
> b.) clients only want to validate receipt of messages at a Commit,

Not sure why you say this is implied by how AppAck is defined. From the PR:

> * 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.
- Joël

---

From: Brendan McMillion <[email-masked]>
Date: Mon, 23 Nov 2020 13:26:26 -0800

> >   would provide a complete view of any losses experienced by active

Because proposals are allowed to be dropped, and you don't know if they
were dropped until the Commit. If in the end you find out your AppAck
proposals were dropped, what do you even do? You can't resend them, as the
generation counters have been reset. To get a per-message delivery
guarantee, you could tie application messages to the corresponding AppAck
somehow and only accept one if both get delivered, but that's more
complicated and also not what's currently in the PR.

I should also point out that this construction scales poorly. It requires
members to send twice as many messages, and that the size of each message
be proportional to the number of members, so the total amount of data
handled by the DS grows quadratically.