Re: [MLS] Virtual Interim minutes

Richard Barnes <rlb@ipv.sx> Thu, 30 January 2020 14:44 UTC

Return-Path: <rlb@ipv.sx>
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 A6B3D120120 for <mls@ietfa.amsl.com>; Thu, 30 Jan 2020 06:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 2797Gp0G22HB for <mls@ietfa.amsl.com>; Thu, 30 Jan 2020 06:44:06 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 932181200FE for <mls@ietf.org>; Thu, 30 Jan 2020 06:44:06 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id d18so2599220qtj.10 for <mls@ietf.org>; Thu, 30 Jan 2020 06:44:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bgtfqERGX5hp+fXUh1XHUxRpbbIKnrnL+3xZ0AA4VbM=; b=DOY1hr4lpat4MZZPzOtdDQiDVIp3okB/HrxgzJ9PN01a5x0APYzseeFG1uxneZTz+E RLHzrYpCMnv9tdFKu42kiOVeQJJCwDtrJzDekYAQh6d/IWk8w85QdS68M3zYk3Rcl4q2 0GzTGBFeXfgO0BZL5lOMzD3b99G3dHVZaaV8FhuTccIPOLhG7zUUrrMhbFJzoLftsPjv DdBUAdlOUsDocCnNV9E9G5vpPYOH3hN1LDrGnUc+HO0ydgmrTKWVhYo5L1+4AUhPPf+p OrOj2VeHLxZYPH7IokXSWAnrAhLv0J0oDTVWx3Lf+psBsEedDKVAuLJ1Pd73n7h9xtIV SRVA==
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=bgtfqERGX5hp+fXUh1XHUxRpbbIKnrnL+3xZ0AA4VbM=; b=l5BlvQ5P5GyDH/yuJirdEbde4BUvjEDT2H8nL077wsFS/B5MaAR0dI807whlj+85er CAGcQ8LMeu9L2c9HYf4Ozx0Xp6wynpX7z0ba0eZeEaVe9fJRBHc8OyZH06iTIAHu08+0 cI2btfG9ZZt0xoEs8u7CHUTmJHBrc282wkC7v2/HEj5w+8y68wKzkTX7TFkO+nwg0b2R YeoBWfcNO9y4XUx4efwp3I5+acX75MXMW+Plb8GU5YUs8mKA9w8NuyFfnsja7n7fn6hA swVt/dQo2hmCToe1efwk59ALqYaSsNGmxkaLUQ3s58iSHCx/hl/i1ZH/+JU95N6loQvw hORw==
X-Gm-Message-State: APjAAAX0u8X53zOFkBdNt2Q+RuwFW23pgSN7T2Qvu1Znm+qutwcxGpXU +DxtkDdTWlBuZoKi99D0Lp6W2jdnKRuxorOQiu92gg==
X-Google-Smtp-Source: APXvYqxx1fSlmTNdkVRVKFAF7kFhJBdGdWtwPVWnFgWZFLLIUfrT2ku5fTxvgusMMmui3YFJ1AS72oM6/jNeFfT123Q=
X-Received: by 2002:ac8:4505:: with SMTP id q5mr2879884qtn.84.1580395445510; Thu, 30 Jan 2020 06:44:05 -0800 (PST)
MIME-Version: 1.0
References: <CAL02cgQ28dmBgk0fQq3uGfrYwOA0AJhbmMdkrQarJ4Z72+2RpA@mail.gmail.com> <003BB7AB-2DA7-40DF-BD3B-D8E199BC49E9@inria.fr>
In-Reply-To: <003BB7AB-2DA7-40DF-BD3B-D8E199BC49E9@inria.fr>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 30 Jan 2020 09:43:38 -0500
Message-ID: <CAL02cgQr-PXdwEd12-iKYZB7J59e+Le_5+AC_v5Lx=sYrcmchg@mail.gmail.com>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Cc: Nick Sullivan <nick=40cloudflare.com@dmarc.ietf.org>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000227777059d5c7ddd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/JzHui_i3fb0UnrA8mCOTaQDVcVo>
Subject: Re: [MLS] Virtual Interim minutes
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: Thu, 30 Jan 2020 14:44:08 -0000

On Wed, Jan 29, 2020 at 6:48 PM Benjamin Beurdouche <
benjamin.beurdouche@inria.fr>; wrote:

>
> > #285 - Get rid of ignored proposals.
> > I had added "ignored" to the Commit message to allow the Committer to
> indicate Proposals that they had received, but was not committing.  Brendan
> makes a plausible case in the PR that this distinction is not worthwhile,
> and this cleans it up.  Please speak up now if you have a concern /
> objection to merging this PR.
>
> I am obviously against allowing a network attacker to arbitrarily truncate
> the proposals from someone. The explicit acknowledgement of ignored
> proposals lets the sender of the proposal know that the committer actually
> received, processed and discarded the proposal. This is obviously way
> better that not knowing if the proposal even reached the committer.
>

Note that the current proposal ACKs all "valid" proposals, since the
Committer MUST include all valid proposals in the commit.  The only thing
that are omitted are proposals that would have no effect on the final group
state.  So the attacker cannot arbitrarily suppress proposals without being
noticed.  For example, an otherwise valid Add or Remove will never be
omitted, so if an endpoint sent an Add/Remove and it didn't end up in the
Commit, then he knows it was not received by the committer.

AFAICT the only interesting ambiguity arises when there are two Updates, in
which case the current spec doesn't specify which of the two should be
selected and which invalidated.  In such a situation, with the current
proposal, if you send two Updates and see the earlier one in the Commit,
you don't know if the later one didn't arrive or if the committer just
didn't choose it.  But this can be easily resolved by specifying that the
committer always chooses the Update with the highest generation for the
sender, so that if a Commit arrives that includes an update with a lower
generation than the highest you sent, then you know the later ones weren't
received.

In other words, if we make that fix, the only cases where you don't get an
ACK are the cases where the proposal wouldn't affect the protocol anyway.
Namely, Updates that are overwritten by another Update or a Remove.  So the
protocol ACKs everything that is meaningful to the protocol.

(Brendan also makes the practical point in the PR that it doesn't matter
for client behavior whether a missing proposal was received or not --
either way, it needs to retransmit to get the job done.)

The best argument I can imagine for keeping "ignored" is extensibility --
the analysis of whether something affects the protocol state might not be
so simple with some future type of Proposal.  But I'm having trouble
thinking of any example where this would be the case.

Could you live with something like the following?

1. Resolve the above-noted ambiguity about multiple Updates for the same
leaf
2. State explicitly that the only Proposals that may be omitted from a
Commit are:
  - Invalid proposals (e.g., because of a bad signature, parsing error,
reference to a non-existent leaf)
  - Proposals whose effect on the tree is overwritten by another proposal,
which at this point includes only:
    - Updates for a leaf prior to the latest Update received by the
committer
    - Updates for a leaf for which there is a Remove in the epoch

ISTM that that ensures that a Proposal is ACK'ed iff it matters to the
protocol.

--RLB