Re: [MLS] AppAck

Brendan McMillion <> Sun, 22 November 2020 22:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE7CC3A0E39 for <>; Sun, 22 Nov 2020 14:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GID6fxXwMil6 for <>; Sun, 22 Nov 2020 14:07:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 451EF3A0E3C for <>; Sun, 22 Nov 2020 14:07:23 -0800 (PST)
Received: by with SMTP id g19so7756987qvy.2 for <>; Sun, 22 Nov 2020 14:07:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=htVHqlFQxP5s1ECXzEFPBdPbCIfHO/l3pNuyjw7J/Oo=; b=JlZkNLG4QsUCeZKljfa1cCS6xxLuKnFe3ySNyVZWubxzxEJ4/WFYk/p07rnsxYJbbA 7kQaZIz5+fvAXpzO5lKiICaELoutW+i7G6R/+g0KAxkLo73MAceIC6iRG/bv+zhZk1EQ UxFczMDx6Eizd9Aehi5+Mhmff1b7tZ9MDecQg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=htVHqlFQxP5s1ECXzEFPBdPbCIfHO/l3pNuyjw7J/Oo=; b=cXTOYyeGs1AJ4T8vioQVX3DK5pFXUrDMyRC4YGAmVuZTQx21IYAQSkIKLvGoHklauu 3xdlR3K45c59yKtNQpcONAR0/gxi5RfKEoiQ1REE3ss6OHqNAk1kDwBUGjn4UEK+E7qa xO/89sTVjYs51F+BQZ0TJiYL2156PHapMT1+3fr6qktePRZ4qlhXraldTeCnBS7/b9kG xf7tfWRmpXkpzFehmqbPe14IQhklJ2PlZxDZZ0wue/11mDgWgofd6+C5mNIjw3CDbUH0 yczN4W0cyIs91h8Qg2nKlSoZmXmb4zftSxBK+9G3FG1MP+5xHPZvpJjSlbvhfoHQS0kP pgOQ==
X-Gm-Message-State: AOAM531TWMbFFg96gctPayK6o7k8BfNS/k/YTWxeXM+wUXiFlh2VnodN qRIXYZZ2EyfTqvT6cLsr63o/8fvAUuCuqbv2BjGdbSaB+fG36w==
X-Google-Smtp-Source: ABdhPJzv0kAA3aoOZo1CYGQ8MPS8s1baCVgNnoYH5xkvEFGzt7b3PyzqkcHTF75c3Tcg0zaIkjO6UBhrUDF9LPXIxtE=
X-Received: by 2002:a0c:b181:: with SMTP id v1mr27547829qvd.36.1606082841918; Sun, 22 Nov 2020 14:07:21 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Brendan McMillion <>
Date: Sun, 22 Nov 2020 14:07:11 -0800
Message-ID: <>
To: Richard Barnes <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000045ecaf05b4b94df4"
Archived-At: <>
Subject: Re: [MLS] AppAck
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Nov 2020 22:07:25 -0000

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

> 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.
> 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
> _______________________________________________
> MLS mailing list