[MLS] Two question regarding use of “reinit” in the RFC

Vera Wesselkamp <vera.wesselkamp@tum.de> Thu, 22 February 2024 15:51 UTC

Return-Path: <vera.wesselkamp@tum.de>
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 BD6BFC14F70F for <mls@ietfa.amsl.com>; Thu, 22 Feb 2024 07:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.406
X-Spam-Level:
X-Spam-Status: No, score=-4.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKpMJSC-U9CJ for <mls@ietfa.amsl.com>; Thu, 22 Feb 2024 07:51:26 -0800 (PST)
Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF01C14F6E9 for <mls@ietf.org>; Thu, 22 Feb 2024 07:51:25 -0800 (PST)
Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 4Tgd0n28gCzybF for <mls@ietf.org>; Thu, 22 Feb 2024 16:51:21 +0100 (CET)
Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= content-language:subject:subject:from:from:user-agent :mime-version:date:date:message-id:content-type:content-type :received:received; s=tu-postout21; t=1708617080; bh=n6H/1IXkH2+ bqUa9jQ5gtW5+GSIjQICMB+iEIMRSMYo=; b=XwHrI5syvo7b8uRSbhkCNeh5rTn Q3fvqdz0VCB8saia8tciMQl/aHjmXY9EcKjOhkcJpInmjI8JLZgHLYldNiHuFsbM QWa5dk62w0Zo1RSu7KEAEiEWHs8XaZGL6H6JMZQaS5lXoUZTvJBVepWR68VxhIkz rVwfpqFifW48QYqvf+VvGSSfI8GgGs8kxoscfTuTG/hrlhyYTph7qBxWqkCWuCx8 h5xN//xkWi1BTE5YDLI3lGwoczXlVLFkyiP1FquHSLMZudozDHxKYLqlZdSIRtP6 062hJq4a9WPCQ4qPQnjiTZizU5KaTL4NGA0Yskc5OhkIvHcY1BvFcBzP3kA==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de
Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id R70fgTVXU78p for <mls@ietf.org>; Thu, 22 Feb 2024 16:51:20 +0100 (CET)
Received: from [10.17.210.150] (dhcp-129.st.cs.uni-saarland.de [134.96.235.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPSA id 4Tgd0m3JkdzyZ7 for <mls@ietf.org>; Thu, 22 Feb 2024 16:51:20 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------oUjf0Phs9iTOlXRtKi0jsQHd"
Message-ID: <4e02fa06-7899-42c8-b157-d03760798a3c@tum.de>
Date: Thu, 22 Feb 2024 16:51:19 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Vera Wesselkamp <vera.wesselkamp@tum.de>
To: mls@ietf.org
Content-Language: de-DE, en-US
Autocrypt: addr=vera.wesselkamp@tum.de; keydata= xsDNBGKHut0BDAC2Wt/UK3pmw7ytNyjJjuKr4RfEF+Ix8ovqwwfytHcAkhM8le7hiP9hNFb5 0UEfew0ur7HBx1Mu4I5iT58n0oVU/GJSS1SIn6ZB/XKdCmgdEK012ERhJgmkXl/oykSEnAk8 TF/SLWly4rWh6+rsXvt/zhgo45BQqjqt0x1EjQUkBxs2fyUxGpXhl+eWJPnE0Ovki2jF6hNb ogNmtiAaTaw+xTrq9nxSWcQBfgPIBCJQX/4WCSg8ZzJkZ6LArAIJTafRAbKPZ3BvBoBkjZ17 6ptLw3U/+efTvHlS8wFs2DbaNtpqvDI1tpJeS7dcFtBjTaWXP4/MyxPa+eTMu1KtXGPLLC6q kPhfM9+qXSOIx1CghxlUiW4PpTax2vxLrBdaDufae7XumcIsyHjPJ5PWW0iXrqTd010UhW3N 9dX454Js7x6GtuB5x4L64od3fFQ72ZKWiQG+2dXZaUPHouyRPv3AgMuc4U/XPK2K2tXbps/8 T5GO/os3qRooV+wk0h2tK7sAEQEAAc0oVmVyYSBXZXNzZWxrYW1wIDx2ZXJhLndlc3NlbGth bXBAdHVtLmRlPsLBDQQTAQgANxYhBPRbzUK3RIAjcaTNQWnjjK9vLvxdBQJih7rdBQkFo5qA AhsDBAsJCAcFFQgJCgsFFgIDAQAACgkQaeOMr28u/F13OQv/YYzkLW66XAZX2Ba3KbEENYYn dL4Vh+f82VSXu6Zoh44v5qOLsiO0AyXG5U73dFxGUfCuOI91udTzaC96hv/TINrFri3GBUov Z+W7JOH7mj5xFYRvnf7lngpjlegD2tk7AIbGm9n7aCbP0P41wbKBiWhPPZW1BMPXwNj+gTTv ioqWR1GBd+SiQqzyAreBoEkRWEPxUH0YY0L0di0H03qxzm9qML5NAVs14HJDexcDBkc9WR0G n7CcoxSAWb45GakpDZxrQ2/kwsfPrybCo/VppD3hhttULYL5uI4SUfuL9mO4WPVq8tiaGxfn T71FO0wHfx+aNRfbuQCr2ZkvGScIH3TAvgZdcCPg4at9iBL/0AE8WsKh36ToIUcyYLZaBEIw nr1vWSV5kLmvY3zltQ9mwuFyRIB9Rmn7KvlflCPKwLGVF63OPZiEkENaaafKkHlsyObTomLB BZznarEiQOxT+32Bay7lKcmRXpe66jM+eXRBdqQjB0Lj1ZvQIBb/YpxkzsDNBGKHut4BDADH 1/2a6p1W9JiUjO1CRrlYx6vNWTlml+PCJBIDuJN2ihuHcWbUsMC9UTraq9+DFeQovGL/zRSl dfK5Zm6fAFAbDLpDoGCG+ZSFKfW+o/JyfmNMqF9algH+kvij2fkGyOASapinFx40dJA6AxYH s5lc/jmcwRPHvFCsRViDxf6u9RkvBzjMlwrgKskkgJbRQpExIEghIi52Nf5uFWtPEuFe9slx 2aSZW8M1DsrX9tOyXVCreGoMXpZqufKkVHPFjIN4mrKlt0+FyWI0/HmIdI5ygCyTI8XuXScp Vl9H/OjJ55a0MQhBaCV3olvNgFeyVBxz3RP0UST27sdJVwlA8MuLOXebG2puJlbnF5z/bEbo O/pdASbkpLcQU0iJnyE0i8Bes+zII5xiN0a4q9XKr2I3j7fhdJCCr1cnC84Z5hAwZHSft9iF HKmYlDnPhMyGX2emDABi0xcmSSHeGEVih2bQqtcZ54drwKCQt9Z54wCgFSBviFDguuNufVhW L4BHmU8AEQEAAcLA/AQYAQgAJhYhBPRbzUK3RIAjcaTNQWnjjK9vLvxdBQJih7reBQkFo5qA AhsMAAoJEGnjjK9vLvxdgEoL/1I3JRqruON/ajhijBVXsvJU4e1kRMnp/lkG0kYsPfv2sWVD Qt4eb7LfPAl5ucsDow/EibLVkDV/v/mX664v5MJu11EFtPjfUXAT1dIZlSdO5Xg1USyq9I9r BYIcQFluJAzooXGYDokCyTt6LCVjvkl9r6KV+Xu7yx2wGv/geNylL/UnDaZPPSnqYGvXjTbG lT+9ibVRKW8n+QGN0MaIggQn/n9XE3OwPaO8+yH5sZsKVqEYqLQwFXs/uAABsaRcflZMNRb0 O2/xcwHMh57FV0anIPvxxOVuYkRnkQ/uPzy/Fso2qIkzC/Y0bxd+FWUMCO2WNd3c9t/qwd+A c7vw+Vh+4Ydpci1LGaOix19HO30xlw4WkY4avcKP4HLuOYNsJqRlHExHZsmRQnOfW+HTLZWq QVeCazQIN+9JtSVDMqGA60UJHkUUioCerhziSs6YmhwDK4OqDjOCF13ZWnOqS7PjGd7Ro+kq dM9icWCCbcxnfu7aS3ZnlG6o33/08mxizA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/IOBuPzQr_BGxzcEalsvN5IJXZOc>
Subject: [MLS] Two question regarding use of “reinit” in the RFC
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 23 Feb 2024 09:40:38 -0000

Hello,

I have two instances in the RFC where I struggle to understand whether 
the word reinit/reinitialization refers to the reinitialization 
operation defined in section 11.2.

The first is the following use in Section 12.4.3.2:

    /Applications for whom this distinction is salient can choose to
    disallow external commits that contain a Remove, or to allow such
    resync commits only if they contain a *"reinit"* PSK proposal that
    demonstrates the joining member's presence in a prior epoch of the
    group./

I read this as a resumption PSK of type /resumption/ and of usage 
/reinit/ as specified in section 7. However that is direct contradiction 
to the following sentence:

    /A PreSharedKey proposal with type resumption and usage reinit MUST
    BE be considered invalid./

Hence my question: Does the “reinit” PSK proposal actually refer to a 
/reinit/ PSK or would an /application/ PSK be more appropriate for the 
described mechanism?

The second question refers to two appearances of the term in section 
16.12 of the RFC and concerns group splitting:

    /Applications provide mechanisms for failed commits to be reported,
    so that group members who were not able to recognize the error
    themselves can *reinitialize the group* if necessary./

I do not understand how to use the reinitialization operation defined in 
the RFC in this context. My understanding is that the paragraph 
describes a situation in which some members processed a commit 
correctly, but a few members members cannot and are hence stuck in an 
older epoch. Reinitialization would send an reinit proposal to the 
current epoch of the group for the members that could process the 
commit. I believe that the “stuck” members, however, would not be able 
to parse the reinit proposal and following commit, and can hence not 
process the reinitialization.

Similarly a few paragraphs later:

    /These members will need to either add themselves back with an
    external Commit or *reinitialize the group* from scratch./

This sentence also refers to members stuck in an old epoch. If these 
members propose a reinitialization in the old group, the members that 
have already advance to other epochs should equally not be able to 
process such a reinitialization.

I also described a similar situation for a paragraph in the architecture 
file in this issue 
<https://github.com/mlswg/mls-architecture/issues/234> before.

My question is if the use of reinitialization in this sentence refers to 
the operation defined in section 11.2, or just another mechanism, i.e. 
re-joining the group at the “stuck” epoch using external commits. If it 
does refer to the operation, how could the process of reinitializing 
look like and how does it resolve the split group?

Thanks for your help!

Vera