Re: [MLS] AppAck

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Mon, 08 March 2021 13:45 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012F43A2A6E for <mls@ietfa.amsl.com>; Mon, 8 Mar 2021 05:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rDQoNtkOiaX for <mls@ietfa.amsl.com>; Mon, 8 Mar 2021 05:44:59 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A273A2A6C for <mls@ietf.org>; Mon, 8 Mar 2021 05:44:58 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.81,232,1610406000"; d="scan'208,217";a="496734991"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.13]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 14:44:56 +0100
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <3DAD67EB-C8C6-45EA-BE68-11402D26E3FF@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_94339B2F-69BE-4123-9A6F-D3A7AF5632CC"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 8 Mar 2021 14:44:56 +0100
In-Reply-To: <CAL02cgStXUwm_wbhE-Yy8-QCys5dGo0H3cOyyxPQ0Mn_j2UrQw@mail.gmail.com>
Cc: Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org>, ML Messaging Layer Security <mls@ietf.org>
To: Richard Barnes <rlb@ipv.sx>
References: <CAL02cgT9VUoTBLG_bZGwYrTBPLyC5qco_nejcUv55K28VcECYw@mail.gmail.com> <CABP-pSSwe9bAi+-DYzAguFXT6GGzUXDZ6Fx3X0bvNYcfFn32Uw@mail.gmail.com> <45292c19-e818-441b-9549-8c9429d7017a@wickr.com> <CABP-pSSLaYji9o+m34Do4_27=231j-X+i5EcoMfegpA_WO+Ayg@mail.gmail.com> <CABP-pSQ_-4zB+9K1271XXNLm2ppJbw6FA2xT32n6Sm7BD4xiCg@mail.gmail.com> <CAL02cgStXUwm_wbhE-Yy8-QCys5dGo0H3cOyyxPQ0Mn_j2UrQw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/cQZ5ubgQX0KB3oC1OPEAxqcAjcU>
Subject: Re: [MLS] AppAck
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 13:45:02 -0000

Making it an inlined-proposal (if it is not) would make sense…
B.

> On 8 Mar 2021, at 14:43, Richard Barnes <rlb@ipv.sx> wrote:
> 
> This would probably be good to have a focused call on in a week or two.  I continue to believe this is a reasonable thing to have in the spec.
> --RLB
> 
> On Mon, Mar 8, 2021 at 1:05 AM Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org <mailto:40cloudflare.com@dmarc.ietf.org>> wrote:
> Hi all
> 
> Since I never heard back on this and still believe AppAck is a bad addition to the protocol, I've opened a PR to remove it here: https://github.com/mlswg/mls-protocol/pull/463 <https://github.com/mlswg/mls-protocol/pull/463>
> On Mon, Nov 23, 2020 at 1:26 PM Brendan McMillion <brendan@cloudflare.com <mailto:brendan@cloudflare.com>> wrote:
> 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.
> 
> 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.
> 
> On Mon, Nov 23, 2020 at 8:34 AM Joel Alwen <jalwen@wickr.com <mailto:jalwen@wickr.com>> wrote:
> 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
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org <mailto:MLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org <mailto:MLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls