IETF Logo Mail Archive

Re: [MLS] AppAck

Brendan McMillion <brendan@cloudflare.com> Mon, 23 November 2020 21:26 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 379FD3A12A8 for <mls@ietfa.amsl.com>; Mon, 23 Nov 2020 13:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-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 LxilRhlFHlbo for <mls@ietfa.amsl.com>; Mon, 23 Nov 2020 13:26:38 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 80E0D3A120B for <mls@ietf.org>; Mon, 23 Nov 2020 13:26:38 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id z188so7064980qke.9 for <mls@ietf.org>; Mon, 23 Nov 2020 13:26:38 -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 :cc; bh=n84QaZprmcKB8OFsEIg9Es3woimKI+NMEgK71qBt5E8=; b=Q5NMhOFBt6TKfRcdS0VlMvI6DrRjGRjIDKv1XjlIybYs41vHVTjZTPd2OGvrkMdIHk K/FgldFaxyem/+ynQrklKWx6lyVKlXi8xl33hWMgtc8BGj4PsLz2DMjqvfbZtrv7KlhV 98EC8WIjzz0Fsw/FKI50Jt3rnPpvGbWTCdlic=
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:cc; bh=n84QaZprmcKB8OFsEIg9Es3woimKI+NMEgK71qBt5E8=; b=VYtf3mvl88WNRF7NrKWQiZ/8YTzrnA4OdfE4l+F8RZJo4g39tVYxpR0l5u0pOnTa3v nWfmJlSsp56d1//iw9OCUmpx/qBIbgcw1kdrGzPY/+c3606Dx3RHcQfOzUcfIVBs/oZI xBuW0+N1b4bL33MTCF1VID+2giiaieUNSML+oEcmpQW5W2fp2z21q9/6SU5jstewxY0b ul9axTv4v9UctIhrUuMPqRsvAgh28tQPPAUzvL3TfCk8cwG6Rh0noOBNEOWK04+DMjUB /71Fd9IHw3++ap/RelTrdMSNeHJ3F41hkWpnJeX2tTQPfETFG9x0sjskV056oZb6TtUY asNQ==
X-Gm-Message-State: AOAM532hZWyfQP2LM9vvRXm7h0v6YJB5qRHB6oT4+7Tl4CNzGxy2+cpn wl/fw+SJKur4rLnYjwgG9Swfdfttsf14xeAPPYLR+8//8foMVMZS
X-Google-Smtp-Source: ABdhPJxxMxgbPZ5nS5mzONLcVFodaZRC3ATpFq69Q3gBhLcxdsLSo1Gph16WfK//O1vjnr04k/eB5weN0EJpZ1FMABk=
X-Received: by 2002:a37:64d4:: with SMTP id y203mr1577405qkb.150.1606166797365; Mon, 23 Nov 2020 13:26:37 -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>
In-Reply-To: <45292c19-e818-441b-9549-8c9429d7017a@wickr.com>
From: Brendan McMillion <brendan@cloudflare.com>
Date: Mon, 23 Nov 2020 13:26:26 -0800
Message-ID: <CABP-pSSLaYji9o+m34Do4_27=231j-X+i5EcoMfegpA_WO+Ayg@mail.gmail.com>
To: Joel Alwen <jalwen@wickr.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000685c7605b4ccd976"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/0vuDKRTg5kxTbd3cSWeAxT2tIfs>
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, 23 Nov 2020 21:26:40 -0000

>
> 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
>

v2.23.0 | Report a Bug | By Email