Re: [MLS] AppAck

Brendan McMillion <brendan@cloudflare.com> Mon, 08 March 2021 06:04 UTC

Return-Path: <brendan@cloudflare.com>
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 149D53A25A0 for <mls@ietfa.amsl.com>; Sun, 7 Mar 2021 22:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 4MkfzyN-F0zZ for <mls@ietfa.amsl.com>; Sun, 7 Mar 2021 22:04:47 -0800 (PST)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB223A259F for <mls@ietf.org>; Sun, 7 Mar 2021 22:04:47 -0800 (PST)
Received: by mail-qv1-xf2e.google.com with SMTP id x13so4103835qvj.7 for <mls@ietf.org>; Sun, 07 Mar 2021 22:04:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rL46QfnCE7/oAkcqmycwq/9hg2LrC+ILUgFC3q4eS7Y=; b=wfPqSR8RivVGDIVrBUIy9iszBSBc9hdWDnAXCAZpEpyRKHGpp379OYGiQGkpbAF1fn kLxASMX+wf9oGZ4U6vbCR5uGYDRZqghmoZX/j5Hq2pNQ01kjmV6BxoO7gH9J0mK6dxSN V+bNE5Gb1bw9PH8ypOT8UBPQSw0/Vtn6UZP00=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rL46QfnCE7/oAkcqmycwq/9hg2LrC+ILUgFC3q4eS7Y=; b=j0hGX/X7P2IwioTbBbR71KqLcDbpmUOvl9wa/8w+P+ifDv7zoPDj7vGh1P6DNmipCl EyZczABgAG+MapjPd2aruc3TLL3ifDZsEvX0uTjGWFaeHpG44HWKhrkyVRT8E23I5tZb 51hs1NxioRQ8UPE/DDJEWBX9CFLJsZVKkAnaNQGKclQyV0YZHKRV+vOu3/oNi8Q7HvWj c/yZMMYhMGu18n35RpRINyAT98WQkVdpdJYIh7n7eZ+rS7q+kOLCNUbJo63v5fXiiCuq 0mrH5G32lOgwcVZRhYQkf87IZfJM2UXSs/GdFGw3eIsz8BOkfzUwfw1QEOjKB5NRk7pE XpPw==
X-Gm-Message-State: AOAM5301mVLZZfcvsrKxykycEYXZ749VUAQ9/ojRC4MdBT6CniUC4mMn z05WRu01sEBfQZibCiTEm6JlA1LVcqxAwtzsw4HnELlrKWfnNg==
X-Google-Smtp-Source: ABdhPJxOAhMW7DYoiyGo0lMt/ANkjfQEwSBPfTLQ9gqOV4Y7SuHjbMroCEJxECSgJ+TTGJwhp8ZRWxEHbjO7rnuIccQ=
X-Received: by 2002:a05:6214:1085:: with SMTP id o5mr19532665qvr.5.1615183485337; Sun, 07 Mar 2021 22:04:45 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CABP-pSSLaYji9o+m34Do4_27=231j-X+i5EcoMfegpA_WO+Ayg@mail.gmail.com>
From: Brendan McMillion <brendan@cloudflare.com>
Date: Sun, 7 Mar 2021 22:04:34 -0800
Message-ID: <CABP-pSQ_-4zB+9K1271XXNLm2ppJbw6FA2xT32n6Sm7BD4xiCg@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e425fb05bd003582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/rPq9pxOFreM6t3MpoHT5b1JkNyA>
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 06:04:50 -0000

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

On Mon, Nov 23, 2020 at 1:26 PM Brendan McMillion <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> 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
>> https://www.ietf.org/mailman/listinfo/mls
>>
>