From nobody Sun Jun 6 01:46:18 2021 Return-Path: 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 E3D963A1115 for ; Sun, 6 Jun 2021 01:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=gjQbE0F5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OOzz2UxV 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 PtsVc2Eb8vbR for ; Sun, 6 Jun 2021 01:46:03 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85FA3A1110 for ; Sun, 6 Jun 2021 01:46:03 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 83A2317D6 for ; Sun, 6 Jun 2021 04:19:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 06 Jun 2021 04:19:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=OlC8Qwt1egD CJTmD3035va62hJS9iSD3fuEGNbMvR5Q=; b=gjQbE0F5QjABhIJksl1fyLKb+Wi QnMKv9pIG9QoD3YuB8Dqfi5LHXl3De+oV3Ux5p4R/+Futqa+fWw7/Qnww+a63lbE BkhwS1FmWQWF9lb5b5mfdNIcxJ3tYbywU6sDLRx0/5+lVTTybPdb9DEEQSDSA+pK 0Au4sgznc8JCKIqycQfTcRHC9uurwhecAa/cFVFmcdHLRhONSL1hI6lkwtAA2Nkw 9aKqFm0DjFW9aC8+aCe1YMZljhOGzxwppIwjE3IP3b7dqtgJ6YcX6kVx5XvxVzuk i9B1zOyUOmJdm/eZf4pmqqXKT0A1JYUZK54LbsxvlIk4HtnMg6/20/+/YIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=OlC8Qwt1egDCJTmD3035va62hJS9iSD3fuEGNbMvR5Q=; b=OOzz2UxV LeA1vOORRBqxj4IPBb/dli1VZY1ktdqDTFmd8UyJj7JVPNurIzXOzD3Kn74mWOjh /ry+q97hhVHCPdfGJ7ZC9mIf09MiiCj6+KKWuCPAR6kFS54NinKqJqkm7pumPFwn 8ZujRGub1QcDCIR3i2MU5Vxg8AoGRqX8w3h56mPcn1FlgnoGaOKdFJ3gmAFcsP3I +9Iy2nCll+BQsryFbDxTbhJ5EQmJH/4gkPbvNK2SVDUYilp8oTFMHN6LO/fL3jQ8 zxchSU5vNaL+t5ngZgEOy5v6mlc9IUBF2Fio+blKAefORxETRmfnB+dq3iNHwogA gRllEW6rAADnng== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedthedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 6 Jun 2021 04:19:55 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5796105866239154848==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210606084603.A85FA3A1110@ietfa.amsl.com> Date: Sun, 6 Jun 2021 01:46:03 -0700 (PDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org 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, 06 Jun 2021 08:46:11 -0000 --===============5796105866239154848== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #468 Clarify relationship between Ratchet Tree Evolution, Group Creatio= n, and Key Schedule (1 by knightcode) https://github.com/mlswg/mls-protocol/issues/468=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============5796105866239154848== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 06, 2021

Issues

mlswg/mls-protocol (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Repositories tracked by this digest:

--===============5796105866239154848==-- From nobody Tue Jun 8 02:17:14 2021 Return-Path: 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 307C13A294F for ; Tue, 8 Jun 2021 02:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jZWgd792ape3 for ; Tue, 8 Jun 2021 02:17:07 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 DA4073A294C for ; Tue, 8 Jun 2021 02:17:06 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id i6so14574268ybm.1 for ; Tue, 08 Jun 2021 02:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SgdTDVG4hDkM4WUhAgws+6AWaUSJMWHMfsb1pzqP/LA=; b=WkTXHPAZ+FNbQd11UX8WRWdvu7xETtrTSVFsm05uKN4n5L1FiwpVNUcffZPNQrs89G HKrXCv+73gaTjtyC217vOdA9VbvaPpE23hpIFkd5ykbE3a2mCXNqP4+w4nySJFQMQYnG SG3uzPq8bDmR3rfStLp0UXvbl+VUYfDvRPB/OaKFPw2tetx/K4JcmhK3D8co0LV0GwKE yM322kH4WrmOGCpdnkTJg7KsYNrAkvXkGeYcrQh8sx0CVWxV9jZ9hxwdjtSl6qp2REYm eAO/0Z8+NfE4fIsSqv1VH7v+DpfjPwVTDWAK3YxXOUP399RVwv4n0g6HEphzN4m00/VU sHDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SgdTDVG4hDkM4WUhAgws+6AWaUSJMWHMfsb1pzqP/LA=; b=T+XmwRZs/J49SR47oenmi8oYV8TRUmjvzIDT2vdhmkReiByosQn2SHpoet5pMHs1eS Rc/I2NL8JT+X+OR19i1iU5R+sbSOqeNA9eeXWLmlv6IdpqlH0YzeWBOZ6SbnBDksyFid jCVt+jGdq6sO8no0WbIe2Y+/qlXVzrr6qgsmvUUWQ0+fLphXplDpnjpHOOObc50Ecd4n 9jdyMprUuUriV8MoWICAhHEhc+zBYWwJLyMhGutCOpiG2ENWSRYNXh/s4D5dWjeet3Hg MxZToO9MOEJx7qis1n5icC30c+chtmN0PbDpEgby7YX8pZjYacuptHAc/Y9Dx1vK4OeB i+Zw== X-Gm-Message-State: AOAM5303PcJH5tX0Qo0NcnXUZ4hvO8TSyv/aQseqX8ZYDgsILAmOx3G8 K7vuLo/aFswr/anEhT6mCiRQbftCIf8hVaRX1Dh92+xp X-Google-Smtp-Source: ABdhPJxrUsYugSz0yvynZ0Xxxgt626F1DNKIbzkbu2QVJlE56ExU6E3f9m+0BS97tJGwzBVGPndLFu+TNdt9b38Dhhs= X-Received: by 2002:a25:7003:: with SMTP id l3mr14951225ybc.231.1623143825156; Tue, 08 Jun 2021 02:17:05 -0700 (PDT) MIME-Version: 1.0 From: Tijana Klimovic Date: Tue, 8 Jun 2021 11:16:53 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000001e2bce05c43d9fd5" Archived-At: Subject: [MLS] Key Schedule, ProposalOrRef objects, Group splitting attack X-BeenThere: mls@ietf.org 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: Tue, 08 Jun 2021 09:17:12 -0000 --0000000000001e2bce05c43d9fd5 Content-Type: text/plain; charset="UTF-8" Hello, I had a few questions about different parts of the specification. Firstly, I wanted to ask about the motivation behind the Key Schedule being what it is, namely a sequence alternating between KDF.Extract and KDF.Expand. Why couldn't it be just a single KDF.Extract followed by a single KDF.Expand, to form an actual key derivation function, and then derive the different keys by providing the appropriate context? Furthermore I am not sure why the KDF.Expand is used at all here since the length parameter provided is KDF.Nh which from the specification is supposed to be: "The value KDF.Nh is the size of an output from KDF.Extract, in bytes". Therefore, the KDF Expands used by the scheme don't really expand the pseudorandom key given by the KDF.Extract to have a bigger length. I am not sure why we use a ProposalOrRef type. And why only proposals sent by the commiter are included by value and all others are hashes of the MLSPlaintext containing proposals sent by members different from the commiter. Lastly, I haven't managed to find where the specification tackles the problem of the group splitting attack. Namely, if we for example have a group of 5 clients, the attacker can split the group state into two group states, by making sure that any message (proposal, commit, application) originating from client 1,2,3 is delivered to only client 1,2,3 only and that similarily any message originating from clients 4,5 are only delivered to clients 4,5. Many thanks. Tijana Klimovic --0000000000001e2bce05c43d9fd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I had= a few questions about different parts of the specification.

Firstly, I wanted to ask about the mo= tivation behind the Key Schedule being what it is, namely a sequence altern= ating between KDF.Extract and KDF.Expand. Why couldn't it be just a sin= gle KDF.Extract followed by a single KDF.Expand, to form an actual key deri= vation function, and then derive the different keys by providing the approp= riate context?=C2=A0

Fur= thermore I am not sure why the KDF.Expand is used at all here since the len= gth parameter provided is KDF.Nh which from the specification is supposed t= o be: "The value KDF.Nh is the size of an output from KDF.Extract, in = bytes". Therefore, the KDF Expands used by the scheme don't really= expand the pseudorandom key given by the KDF.Extract to have a bigger leng= th.

I am not sure why we= use a ProposalOrRef type. And why only proposals sent by the commiter are = included by value and all others are hashes of the MLSPlaintext containing = proposals sent by members different from the commiter.=C2=A0

Lastly, I haven't managed to find= where the specification tackles the problem of the group splitting attack.= Namely, if we for example have a group of 5 clients, the attacker can spli= t the group state into two group states, by making sure that any message (p= roposal, commit, application) originating from client 1,2,3 is delivered to= only client 1,2,3 only and that similarily any message originating from cl= ients 4,5 are only delivered to clients 4,5.=C2=A0
<= br>
Many thanks.
Tijana Klimo= vic



--0000000000001e2bce05c43d9fd5-- From nobody Tue Jun 8 12:01:14 2021 Return-Path: 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 95BE43A3A96 for ; Tue, 8 Jun 2021 12:01:05 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=raphaelrobert.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 N1ykS4R-FOea for ; Tue, 8 Jun 2021 12:01:00 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 8F02A3A3AAD for ; Tue, 8 Jun 2021 12:00:53 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id l2so22752517wrw.6 for ; Tue, 08 Jun 2021 12:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QO2vzz/3FqURT6WSxWxLxubX1OjtGLR35mn63kKhHmw=; b=qPIS+BcaIrxPAGPl9E2BKleyyI0dQyAa7n7A59yQsDBeboSB669RZzMJmOM8ZbFpvz jL7RWnbuaf5uicvAriCQyI+V8IpG01rinOglcL57vrOmnGVfxlqAMWq4m51CGoWC2a4B bQjvN/ExjT0zUrGaux3ShJWAJY0OKRirYdVWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QO2vzz/3FqURT6WSxWxLxubX1OjtGLR35mn63kKhHmw=; b=bz13MBXm3jG2npUI+5bxNkhsCaB4LEcsEY7A8mJSfSyOBm81j53Jo8+zXR/7VN8CJz gT05SdYlErI7BL02u2GeN6msbMK77R8dMzRaVdWjy/u39a+GpkebmNmxyEEMHlNsN7Vu M9KDTSQ59aCSkBRcP4MDG7VUMObm8wQef/VrgVm+ZSD/ChN+LnGKCpxuQOzDG99KBl03 r1Ysb/9kBYlIUAqYS9Cw6AAOzgeiVAyDEVseHjAIJj46Ow0Y4DStzXzGQqFpDKz/vyfL JC9l2BjoaPgCacZynX+cWLBQnRGhUUn98ezmOYOhjYGVCFe8/4JoMBS1Z0cdrG2QRflT fqpA== X-Gm-Message-State: AOAM533dH3oXu22OY8tRlLfWre7/dSVg6QcvoIYsae7QCoE230Jg44aH gFFQMSyFS7njl8K0gTLWlle4nw== X-Google-Smtp-Source: ABdhPJwOC7/dXCAb98s6G6iQbO+L21ARlYvfXMWH+B62H2Mm2SZsUWtqXL8NcLngHfQzHRWCgYBNmg== X-Received: by 2002:adf:f805:: with SMTP id s5mr23733079wrp.231.1623178848676; Tue, 08 Jun 2021 12:00:48 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id s1sm3827140wmj.8.2021.06.08.12.00.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jun 2021 12:00:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Raphael Robert In-Reply-To: Date: Tue, 8 Jun 2021 21:00:46 +0200 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tijana Klimovic X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [MLS] Key Schedule, ProposalOrRef objects, Group splitting attack X-BeenThere: mls@ietf.org 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: Tue, 08 Jun 2021 19:01:12 -0000 Here=E2=80=99s a partial answer: > On 8. Jun 2021, at 11:16, Tijana Klimovic = wrote: >=20 > Hello, >=20 > I had a few questions about different parts of the specification. >=20 > Firstly, I wanted to ask about the motivation behind the Key Schedule = being what it is, namely a sequence alternating between KDF.Extract and = KDF.Expand. Why couldn't it be just a single KDF.Extract followed by a = single KDF.Expand, to form an actual key derivation function, and then = derive the different keys by providing the appropriate context?=20 >=20 > Furthermore I am not sure why the KDF.Expand is used at all here since = the length parameter provided is KDF.Nh which from the specification is = supposed to be: "The value KDF.Nh is the size of an output from = KDF.Extract, in bytes". Therefore, the KDF Expands used by the scheme = don't really expand the pseudorandom key given by the KDF.Extract to = have a bigger length. I=E2=80=99ll let someone else comment on the above. >=20 > I am not sure why we use a ProposalOrRef type. And why only proposals = sent by the commiter are included by value and all others are hashes of = the MLSPlaintext containing proposals sent by members different from the = commiter.=20 Proposals are handshake messages in their own right and are distributed = between members within an epoch. At the end of an epoch someone sends a = Commit that references the proposals with a commit hash.=20 To make things easier for members who immediately want to commit to a = proposal, inline proposals are also supported so that members can do all = of it in one message. That=E2=80=99s all there is to it. In earlier versions of MLS, handshake messages were always committing. = Introducing the proposal-commit scheme brought some more flexibility in = general. Now there can be proposals from externals as well, or you can = propose to remove yourself from the group (which impossible before, = someone else had to remove you). >=20 > Lastly, I haven't managed to find where the specification tackles the = problem of the group splitting attack. Namely, if we for example have a = group of 5 clients, the attacker can split the group state into two = group states, by making sure that any message (proposal, commit, = application) originating from client 1,2,3 is delivered to only client = 1,2,3 only and that similarily any message originating from clients 4,5 = are only delivered to clients 4,5.=20 If the Delivery Service decides to route messages this way, there is not = much you can do about it as a client. The AppAck extension helps to = detect some of the dropped messages, but at the end of the day you have = to trust the DS to not do a DoS attack on clients. The protocol cannot = fix that problem. Of course you could try to mitigate this out-of-band, for example you = could have a mechanism where members can regularly compare the = authentication secrets or some other value exported from the exporter. Raphael >=20 > Many thanks. > Tijana Klimovic >=20 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Jun 9 10:58:19 2021 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F06593A20A0; Wed, 9 Jun 2021 10:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls-chairs@ietf.org, mls@ietf.org, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 7.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162326149585.12849.2635014386516277487@ietfa.amsl.com> Date: Wed, 09 Jun 2021 10:58:15 -0700 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 111 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 17:58:16 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack wish privacypass masque Key Participant Conflict: acme artarea dispatch perc secdispatch People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 10 06:05:31 2021 Return-Path: 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 A5E7E3A40BE for ; Thu, 10 Jun 2021 06:05:29 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=sn3rd.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 MEW1cD3s_W6h for ; Thu, 10 Jun 2021 06:05:25 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 3F7E43A40BA for ; Thu, 10 Jun 2021 06:05:25 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id e3so9247443qte.0 for ; Thu, 10 Jun 2021 06:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=j1Oow9gCRPXhg09wLDWcdbV7/Xj34iI3/2Zmw02Hv0w=; b=DzwtvXodLOdv4MBd0PCc9SVgDKS2Pl4IxzrfP51UDBEZCxD/fJzIeQERFYQJbe0ys0 FwXH5ALJc0KuUUdOppUm8t0KufrayItvNC5g4BSc9vJZGvMCnbWfPHpfslWq1Jfjrrzd FY7QbswnmkGOR6Oi+duFh7eorS9tUqtKu5h8Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=j1Oow9gCRPXhg09wLDWcdbV7/Xj34iI3/2Zmw02Hv0w=; b=SFfZ8SEZU/DFzlt/HIWbsOfRkRK3a+uduranVJLPeqNnbm0wtehbzvOWRgIrX0n4ud IAWHQVuXajvqnEzIYkKOFV7eN3sAeCNOXadu9wylvBPQ4Z6Bx8yLP02yHUVOBaJtbj+5 itP5rxe1ac+/ZGDydbY3dsEWJXQo35BnBZpd+ko40KzbcB3uibF5iCwiTeyQKsK9cgCy mJtjCp61E1HJ5ggbXpI4iN60XBLYo6e4Y3YpKru99fTUdKB+0NlcV+R/DdaW9El1tiBg QBZrM0jqsJrr/T3b6p/XLQ+XcKsk67t3Rzmirubk2N8FT24k7wGNPqjEfff+phGcB1kX d4KA== X-Gm-Message-State: AOAM533JMrnB6Z+QSjQ9BtM++lKlGxA/GpBjrigyFjdb7ZKkE7V4aiQ1 i0Gib0wkBFjWJhMG9nmhBgPoO/94TlN8/g== X-Google-Smtp-Source: ABdhPJyhzuUkX2i2ZMuR/PG58nlTQwOie82iSoqn/K0clKZfyw6FF+JlRzcWmVNw3dWbjJ7kiYOSlw== X-Received: by 2002:ac8:578e:: with SMTP id v14mr4997623qta.327.1623330321945; Thu, 10 Jun 2021 06:05:21 -0700 (PDT) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id b4sm2168042qti.43.2021.06.10.06.05.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jun 2021 06:05:21 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <5104FCB1-EF29-4884-8DAF-4D171D07100E@sn3rd.com> Date: Thu, 10 Jun 2021 09:05:19 -0400 To: MLS List X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [MLS] MLS@IETF111 X-BeenThere: mls@ietf.org 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: Thu, 10 Jun 2021 13:05:30 -0000 Please note that I have requested a 1-hour slot for IETF111. If we do = not feel that will be sufficient time to cover the issues, I can request = a long session. spt= From nobody Sun Jun 13 00:56:13 2021 Return-Path: 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 468713A0E02 for ; Sun, 13 Jun 2021 00:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=nc+n/jG/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Kh7YY3nz 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 nishVGiPTPjI for ; Sun, 13 Jun 2021 00:56:05 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF103A0E03 for ; Sun, 13 Jun 2021 00:56:05 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 8F27710D2 for ; Sun, 13 Jun 2021 03:39:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 13 Jun 2021 03:39:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=vziysV4SkOE peUVuoebiR5KYZDE+z8tVKaYvIbOqVn0=; b=nc+n/jG/VPueOknZwx7tSbrkA00 /Gt0BwKBuxCd5f/w1AzUDRhOBI6G7z/ZSo1bKTPeCCpb3lmpvc1stiaCoAXYx1t5 ZJC8DPYFh3YmrNXj9zdhO4nZ+w8U3y7OZv4QpXc9IeLLVZ3LhBlReL4ixErj/x08 ticIDwMdoNtDjZg13DIPWBrMPhlQMGnAKp5vd+mvEbe7aW8KvjenoFTP/KIoRtf3 ndrCKcO/i5Km7J93s/0B7yspco55bTV/jYqE21jLGiHP7KaAT9rxAaUOSoRvaC/B qLVwZzW+u2UGgcSxmLfx4+4gJHlOxGTsXpkIlwJrYOf0leQeQ6sftHemYXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=vziysV4SkOEpeUVuoebiR5KYZDE+z8tVKaYvIbOqVn0=; b=Kh7YY3nz wvxyI4KV5ccG6qN9OcKkuHD0pXJ+R5ZZeSXB8GOf0ec2XAK1WJ+AsePTiRKuIuVq U3gPdDVEIU073/lEiJVWGFPpBKcLPtfj5DFM6hsdZduFu5nPc33R0KaO0SwJoDGb Xzqez3yrocHbr6bOBj3+ufWWsixPx4MTs5c4yEyGI3pVk1edjCkt4thRgonkxxnz R/QPqrH9c6nNTZESPuyfxM+O3erJe23Tyl5ySqRBFW8FGpQKKMXDzoSfSW2xcYR6 rCqQ6ufajOhdK9pMaVqSImXVkdt6lYPstwcbFIgYoqOeJ2bvIgtAUnvKqpU0wIrN 6bY9odVujucbKw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvvddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 13 Jun 2021 03:39:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2148076758365127813==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210613075605.7FF103A0E03@ietfa.amsl.com> Date: Sun, 13 Jun 2021 00:56:05 -0700 (PDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org 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, 13 Jun 2021 07:56:10 -0000 --===============2148076758365127813== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #468 Clarify relationship between Ratchet Tree Evolution, Group Creatio= n, and Key Schedule (2 by knightcode) https://github.com/mlswg/mls-protocol/issues/468=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2148076758365127813== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 13, 2021

Issues

mlswg/mls-protocol (+0/-0/=F0=9F=92=AC2)

1 issues received 2 new comments:

Repositories tracked by this digest:

--===============2148076758365127813==-- From nobody Mon Jun 21 04:04:29 2021 Return-Path: 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 7A3CB3A003E for ; Mon, 21 Jun 2021 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BAqZAaxk3n9B for ; Mon, 21 Jun 2021 04:04:24 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BBE3A003F for ; Mon, 21 Jun 2021 04:04:23 -0700 (PDT) IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ALi2gP6m+5oNAQxfI/Y8VyISGVgPpDfIt3DAb?= =?us-ascii?q?v31ZSRFFG/FwWfrCoB1p726StN93YgBFpTngAtjkfZqyz/9ICOUqUotKGTOW2l?= =?us-ascii?q?dAT7sSjrcKoQePJ8SWzIc06U4jScRD4bbLZmSS4/yR3OD1KbYd/OU=3D?= X-IronPort-AV: E=Sophos;i="5.83,289,1616454000"; d="scan'208";a="385668395" Received: from unknown (HELO [192.168.42.138]) ([37.171.158.62]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 21 Jun 2021 13:04:20 +0200 To: Raphael Robert Cc: mls@ietf.org References: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= Message-ID: <073ddbb9-df13-10e1-c151-bbb52617dfaa@inria.fr> Date: Mon, 21 Jun 2021 13:04:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MLS] Turning mandatory extensions into fields X-BeenThere: mls@ietf.org 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: Mon, 21 Jun 2021 11:04:29 -0000 Hi and sorry for the late answer, Is there any good reason to merge the two structures (init keys and leaf content) other than the overlap they have? The overlap seems quite small to me (e.g. compared to the "Message Framing" section), it looks like it is only an HPKEPublicKey, a Credential and a signature. The non-overlap seems quite big to me, for example: - ProtocolVersion, CipherSuite only belong to init keys - parent hash, lifetime only belong to leaf content I think it would be a good idea to split the two structures again, I believe this would simplify the implementations by making parent hash easily accessible, and by removing unused values of the leaf content (what should we do with ProtocolVersion and CipherSuite, should we check that it is consistent with the group state? should we ignore them?) Thank you for your comments, Théophile. On 22/05/2021 12:20, Raphael Robert wrote: > Hi Théophile, > > The current scheme was introduced a while ago when we merged the the KeyPackages that clients publish ahead of time (previously called init keys) with the KeyPackages that clients use in their leaf nodes. > The reason was that there was quite some overlap between the two structs and the logical consequence was that data that differs for the two use cases was expressed as extensions. > > I’d be open to discussing disambiguating this again and I think I’m not the only one. This would also pave the way for Joël’s proposal to have an additional public key in the init keys in order to improve FS for members who don’t update quickly. > > Thanks > > Raphael > >> On 21. May 2021, at 23:03, Théophile Wallez wrote: >> >> Hello All, >> >> The MLS spec includes some extensions that are mandatory. >> Considering that this is v1 of the spec, why not just make these into fields and take them out of extensions? >> >> In particular, in the current draft, the parent hash is only an extension, but it is mandatory when the leaf is generating an UpdatePath. >> Let us make it a field in KeyPackage? >> Having it as an extension hides its importance for security, and makes the draft confusing to read. >> Also, it is a bit weird that parent_hash is a field in ParentNode, and it is an extension in KeyPackage. >> >> We propose the following changes: >> >>> New structure: >>> struct { >>> opaque parent_hash_value<0..255>; >>> } ParentHash; >>> >>> New field in KeyPackage: >>> optional parent_hash; >>> >>> This optional field must be present in the `leaf_key_package` of an UpdatePath (same constraints as the current extension). >> Or: >> >>> New field in KeyPackage: >>> opaque parent_hash<0..255>; >>> >>> `parent_hash` must be non-empty in the `leaf_key_package` of an UpdatePath (same constraints as the current extension). >> Best regards, >> Théophile, Benjamin, and Karthik_______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls From nobody Mon Jun 21 04:14:18 2021 Return-Path: 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 69DBB3A0417 for ; Mon, 21 Jun 2021 04:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 k2bxccYXOeol for ; Mon, 21 Jun 2021 04:14:12 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D5F3A040C for ; Mon, 21 Jun 2021 04:14:11 -0700 (PDT) IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Attii+6E6Q6XnTL74pLqE2ceALOsnbusQ8zAX?= =?us-ascii?q?Po5KKCC9E/bo8PxG+c5w6faaslossR0b9uxofZPwIk80lqQFhbX5X43DYOCOgg?= =?us-ascii?q?LBR+xfBMnZsl/d8kbFh4tgPNJbAtND4arLfCBHZKjBjjVQa+xQueVvp5rY49vj?= =?us-ascii?q?8w=3D=3D?= X-IronPort-AV: E=Sophos;i="5.83,289,1616454000"; d="scan'208,217";a="385669634" Received: from unknown (HELO [192.168.42.138]) ([37.171.158.62]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 21 Jun 2021 13:14:09 +0200 To: Raphael Robert Cc: MLS List References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> <4614A3C1-8461-48F8-AD53-C1399BC5F673@sn3rd.com> <6B8101F5-A54A-429A-82B0-5386E321F525@inria.fr> <8E5EC435-7B97-4852-AB90-F4E501ACDEDA@raphaelrobert.com> From: =?UTF-8?Q?Th=c3=a9ophile_Wallez?= Message-ID: <42346e03-df57-57c1-c781-249ebe13e798@inria.fr> Date: Mon, 21 Jun 2021 13:14:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8E5EC435-7B97-4852-AB90-F4E501ACDEDA@raphaelrobert.com> Content-Type: multipart/alternative; boundary="------------99814DA93854DDF8DE8746EF" Content-Language: en-US Archived-At: Subject: Re: [MLS] Optimizing Unmerged Leaves (or: bringing the MLS tree size back to O(n)) X-BeenThere: mls@ietf.org 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: Mon, 21 Jun 2021 11:14:17 -0000 This is a multi-part message in MIME format. --------------99814DA93854DDF8DE8746EF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi and sorry for the late answer, I'll also respond inline: On 22/05/2021 12:14, Raphael Robert wrote: > >> On 21. May 2021, at 16:59, Karthik Bhargavan >> > > wrote: >> >> Solution 1 >> ————— >> >> One possibility, close to the current MLS spec would be to not store >> the unmerged leaf at a node if it is already stored at the parent. >> This way, every leaf is present at most once in some >> `unmerged_leaves` array. >> In the worst case, this uses 4*n + 4*(n/2) = 6*n bytes (4*n for the >> `unmerged_leaves` array size, 4*(n/2) because at most n/2 leaves are >> stored in the `unmerged_leaves` arrays). >> In the best case, this uses 4*n bytes. >> The tree resolution algorithm will now have to do a little more >> calculation to re-compute the unmerged leaves at each node. > > This sounds rather straight forward on a logical level. It clearly > reduces the stored/transmitted payload size, but it introduces a new > cost: previously only O(log n) nodes needed to be modified during an > Update/Remove. Now we might have to “push down” the book keeping > information from parents to children, in the worst case this affects > n/2 nodes, so the cost of modifying nodes goes up to O(n). > If we consider a very large group, there would be a measurable > difference when clients load/store nodes from/to disk. > My current intuition is that currently I/O operations can be done in > O(log n) with clever parent hash caching. The worst case here would be > the following: A client is a member of a large group and has been > offline for a while (which is not a far fetched scenario). The client > now comes online and has to process a large number of handshake > messages. For robustness, the client might be inclined to frequently > persist the intermediary state. This is where the I/O cost kicks in. Indeed, when "pushing down" the unmerged leaves, if it is pushed down to a blank node, we might have to modify more than O(log n) nodes. This could be solved by storing unmerged leaves in blank nodes, but it is starting to get quite ugly. >> Solution 2+ >> ————— >> >> However, if we wish to compress further, we can do so as well, using >> two facts: >> - if a node `n` has two children `l` and `r`, then >> n.last_update_epoch is equal to either l.last_update_epoch or >> r.last_update_epoch, >> - if `l` is unmerged for some node then l.creation_epoch = >> l.last_update_epoch (because in this case, the leaf never generated >> an UpdatePath) (the converse is not true, for example in the case >> when its sibling generates an UpdatePath). >> >> So at each node, we can store the direction from which the node was >> last updated (for example with a boolean flag), then given any node >> `n` we can "follow the path" down the tree to obtain a leaf `l`, and >> we have n.last_update_epoch = l.last_update_epoch. >> Furthermore, we don't need to store the creation epoch for leaves: >> - if `l` is unmerged for `n`, then n.last_update_epoch < >> l.creation_epoch = l.last_update_epoch, >> - if `l` is not unmerged for `n`, then n.last_update_epoch >= >> l.last_update_epoch (because when `l` is updated, it updates all the >> nodes above it). >> This uses 8*n + 1*n = 9*n bytes for the whole tree. > > I didn’t check all the ramifications here tbh. I think it is similar > to solution 1 in terms of increased I/O cost. Actually, there is no "pushing down" here, when modifying nodes on a path from leaf to the root, only those nodes are modified (we update the direction of the parent nodes in the path, and update the last update epoch of the leaf), so the I/O cost is actually O(log n). Thank you for your comments, Théophile. --------------99814DA93854DDF8DE8746EF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi and sorry for the late answer,

I'll also respond inline:

On 22/05/2021 12:14, Raphael Robert wrote:

On 21. May 2021, at 16:59, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:

Solution 1
—————

One possibility, close to the current MLS spec would be to not store the unmerged leaf at a node if it is already stored at the parent.
This way, every leaf is present at most once in some `unmerged_leaves` array.
In the worst case, this uses 4*n + 4*(n/2) = 6*n bytes (4*n for the `unmerged_leaves` array size, 4*(n/2) because at most n/2 leaves are stored in the `unmerged_leaves` arrays).
In the best case, this uses 4*n bytes.
The tree resolution algorithm will now have to do a little more calculation to re-compute the unmerged leaves at each node.

This sounds rather straight forward on a logical level. It clearly reduces the stored/transmitted payload size, but it introduces a new cost: previously only O(log n) nodes needed to be modified during an Update/Remove. Now we might have to “push down” the book keeping information from parents to children, in the worst case this affects n/2 nodes, so the cost of modifying nodes goes up to O(n).
If we consider a very large group, there would be a measurable difference when clients load/store nodes from/to disk.
My current intuition is that currently I/O operations can be done in O(log n) with clever parent hash caching. The worst case here would be the following: A client is a member of a large group and has been offline for a while (which is not a far fetched scenario). The client now comes online and has to process a large number of handshake messages. For robustness, the client might be inclined to frequently persist the intermediary state. This is where the I/O cost kicks in.

Indeed, when "pushing down" the unmerged leaves, if it is pushed down to a blank node, we might have to modify more than O(log n) nodes. This could be solved by storing unmerged leaves in blank nodes, but it is starting to get quite ugly.

Solution 2+
—————

However, if we wish to compress further, we can do so as well, using two facts:
- if a node `n` has two children `l` and `r`, then n.last_update_epoch is equal to either l.last_update_epoch or r.last_update_epoch,
- if `l` is unmerged for some node then l.creation_epoch = l.last_update_epoch (because in this case, the leaf never generated an UpdatePath) (the converse is not true, for example in the case when its sibling generates an UpdatePath).

So at each node, we can store the direction from which the node was last updated (for example with a boolean flag), then given any node `n` we can "follow the path" down the tree to obtain a leaf `l`, and we have n.last_update_epoch = l.last_update_epoch.
Furthermore, we don't need to store the creation epoch for leaves:
- if `l` is unmerged for `n`, then n.last_update_epoch < l.creation_epoch = l.last_update_epoch,
- if `l` is not unmerged for `n`, then n.last_update_epoch >= l.last_update_epoch (because when `l` is updated, it updates all the nodes above it).
This uses 8*n + 1*n = 9*n bytes for the whole tree.

I didn’t check all the ramifications here tbh. I think it is similar to solution 1 in terms of increased I/O cost.

Actually, there is no "pushing down" here, when modifying nodes on a path from leaf to the root, only those nodes are modified (we update the direction of the parent nodes in the path, and update the last update epoch of the leaf), so the I/O cost is actually O(log n).

Thank you for your comments,
Théophile.

--------------99814DA93854DDF8DE8746EF-- From nobody Mon Jun 21 04:57:13 2021 Return-Path: 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 6E8633A09EC for ; Mon, 21 Jun 2021 04:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 44XPUzW_m8Ln for ; Mon, 21 Jun 2021 04:57:07 -0700 (PDT) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC80F3A09EB for ; Mon, 21 Jun 2021 04:57:06 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4G7p0v2p62zQk2b; Mon, 21 Jun 2021 13:57:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id Q6KC9Is9Eoof; Mon, 21 Jun 2021 13:56:57 +0200 (CEST) Date: Mon, 21 Jun 2021 13:56:56 +0200 (CEST) From: Konrad Kohbrok To: =?UTF-8?Q?Th=C3=A9ophile_Wallez?= , Raphael Robert Cc: mls@ietf.org Message-ID: <1913706681.187825.1624276616584@office.mailbox.org> In-Reply-To: <073ddbb9-df13-10e1-c151-bbb52617dfaa@inria.fr> References: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> <073ddbb9-df13-10e1-c151-bbb52617dfaa@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: X-Rspamd-Score: -4.83 / 15.00 / 15.00 X-Rspamd-Queue-Id: 00F911860 X-Rspamd-UID: 175ddd Archived-At: Subject: Re: [MLS] Turning mandatory extensions into fields X-BeenThere: mls@ietf.org 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: Mon, 21 Jun 2021 11:57:11 -0000 Hi Th=C3=A9ophile, thanks for bringing this up! I believe splitting the two structures would be a good idea. It would also = allow us to have a second private/public keypair in the init key struct for= better FS as suggested in the past by Jo=C3=ABl. That being said, I believe we need the lifetime field/extension in both str= ucts, as init key structs should also have an expiration date. If anything,= the lifetime extension could be omitted in the leaf struct, as I'm not sur= e what the consequence would be if a leaf key package expired in an active = group. (Would other group members still encrypt to the leaf key? Would they= reject messages from that member that are not updates? This would have to = be defined in the spec. Or is it already?) Cheers, Konrad > Th=C3=A9ophile Wallez hat am 21.06.2021 13:04= geschrieben: >=20 > =20 > Hi and sorry for the late answer, >=20 > Is there any good reason to merge the two structures (init keys and leaf= =20 > content) other than the overlap they have? > The overlap seems quite small to me (e.g. compared to the "Message=20 > Framing" section), it looks like it is only an HPKEPublicKey, a=20 > Credential and a signature. > The non-overlap seems quite big to me, for example: > - ProtocolVersion, CipherSuite only belong to init keys > - parent hash, lifetime only belong to leaf content >=20 > I think it would be a good idea to split the two structures again, I=20 > believe this would simplify the implementations by making parent hash=20 > easily accessible, and by removing unused values of the leaf content=20 > (what should we do with ProtocolVersion and CipherSuite, should we check= =20 > that it is consistent with the group state? should we ignore them?) >=20 > Thank you for your comments, >=20 > Th=C3=A9ophile. >=20 > On 22/05/2021 12:20, Raphael Robert wrote: > > Hi Th=C3=A9ophile, > > > > The current scheme was introduced a while ago when we merged the the Ke= yPackages that clients publish ahead of time (previously called init keys) = with the KeyPackages that clients use in their leaf nodes. > > The reason was that there was quite some overlap between the two struct= s and the logical consequence was that data that differs for the two use ca= ses was expressed as extensions. > > > > I=E2=80=99d be open to discussing disambiguating this again and I think= I=E2=80=99m not the only one. This would also pave the way for Jo=C3=ABl= =E2=80=99s proposal to have an additional public key in the init keys in or= der to improve FS for members who don=E2=80=99t update quickly. > > > > Thanks > > > > Raphael > > > >> On 21. May 2021, at 23:03, Th=C3=A9ophile Wallez wrote: > >> > >> Hello All, > >> > >> The MLS spec includes some extensions that are mandatory. > >> Considering that this is v1 of the spec, why not just make these into = fields and take them out of extensions? > >> > >> In particular, in the current draft, the parent hash is only an extens= ion, but it is mandatory when the leaf is generating an UpdatePath. > >> Let us make it a field in KeyPackage? > >> Having it as an extension hides its importance for security, and makes= the draft confusing to read. > >> Also, it is a bit weird that parent_hash is a field in ParentNode, and= it is an extension in KeyPackage. > >> > >> We propose the following changes: > >> > >>> New structure: > >>> struct { > >>> opaque parent_hash_value<0..255>; > >>> } ParentHash; > >>> > >>> New field in KeyPackage: > >>> optional parent_hash; > >>> > >>> This optional field must be present in the `leaf_key_package` of an U= pdatePath (same constraints as the current extension). > >> Or: > >> > >>> New field in KeyPackage: > >>> opaque parent_hash<0..255>; > >>> > >>> `parent_hash` must be non-empty in the `leaf_key_package` of an Updat= ePath (same constraints as the current extension). > >> Best regards, > >> Th=C3=A9ophile, Benjamin, and Karthik_________________________________= ______________ > >> MLS mailing list > >> MLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Jun 25 05:57:42 2021 Return-Path: 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 3A38C3A161B for ; Fri, 25 Jun 2021 05:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 Cyhs1NArDDZ7 for ; Fri, 25 Jun 2021 05:57:34 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 0BC133A161A for ; Fri, 25 Jun 2021 05:57:33 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id q190so18936798qkd.2 for ; Fri, 25 Jun 2021 05:57:33 -0700 (PDT) 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=Gvi53sv9b10k3Zl07ZDSgsIzmmJenWRMm34A08siG48=; b=qFYlzCR+BnT/pcdeywLet4QKz2nqAk2Z7NJM2+IYQvLI7sAMIb1ACVpRVgCrhEtYAF VfCdz/bXxPfOou2CqQ8WE+VWhpX1wjdqlfMMVT3cVvMUe0YvjsR7bWKmTgf810VAffLO 6joTAbP2ap3kzVvb57Ht9W3zdzx/yPYl7V7IDnLhWOJi+fqZb/SanK8Xh+FtFlv5YYpJ dH90xQ0LXOmIEgh2pM6OlTYOYmZ3Ii1gyuG8iz0HZ0FXarzqcLCScZxl54w1SAzT3nY+ 9bKbmnCq1giB0kGQxhUcLlUMgsig+eXoDG56ikgtHIWjfpkEVYpTXiV93e/NV/SBRUpu KlLg== 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=Gvi53sv9b10k3Zl07ZDSgsIzmmJenWRMm34A08siG48=; b=aLKNdKYZ32qbUAv6X9f8SqToexRH9eVbeaM0oBpeXXjn85UHDZZNAe68z2Gfzdb7Bn 13hfFLzS90RJBOMGdbGnDPtsof2WrWNdrHyEL2/UtIEYsaF/PfZp65m7e+ybeKO1q5KK 9z16RwjAxKr/3/HbXqOWKNMQE8ssYMfGbv3f1J3RMA3WZ+YiMgWLoV1HJfBDQZbgmEy8 e9o7e7UkMLEjGHQ1wRagT/k0Nh9bWfs3qAfB72uqD2TO/lGazLDe9aVCv6qeihWaVmMI +mCfTBrybWFlMLXZ9S8OGJVlj13GZcqOba0NZ7nvxEYCt5BCNhcnttsX7gPDQRy/yJlN metQ== X-Gm-Message-State: AOAM530AHtUpCfB2xvAPTByugicHEOHBbt4fbpgfRB5XmEDk5jDvBnTW FincocD2h3jZUquKKjca8gQ/jSGd5u2zQckrgZ9Xeg== X-Google-Smtp-Source: ABdhPJxYZ7KNEbzzhpBngyES6FWcIEGpxSN1Zwnh0Ke3EiGe6LlRmex4uWHlnw9uhxu6E7lX46VGXDVbuF4OgGxezOY= X-Received: by 2002:a37:63c2:: with SMTP id x185mr6981174qkb.159.1624625851576; Fri, 25 Jun 2021 05:57:31 -0700 (PDT) MIME-Version: 1.0 References: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> <073ddbb9-df13-10e1-c151-bbb52617dfaa@inria.fr> <1913706681.187825.1624276616584@office.mailbox.org> In-Reply-To: <1913706681.187825.1624276616584@office.mailbox.org> From: Richard Barnes Date: Fri, 25 Jun 2021 08:57:20 -0400 Message-ID: To: Konrad Kohbrok Cc: =?UTF-8?Q?Th=C3=A9ophile_Wallez?= , Raphael Robert , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000c6c63405c596ae00" Archived-At: Subject: Re: [MLS] Turning mandatory extensions into fields X-BeenThere: mls@ietf.org 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: Fri, 25 Jun 2021 12:57:39 -0000 --000000000000c6c63405c596ae00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would oppose such a big change this late in the game. There is substantial overlap in what is needed from KeyPackages and leaf nodes in the tree, and designing some new leaf struct would require significant reinvention and revalidation to ensure that we haven't damaged the authentication properties of the protocol. --RLB On Mon, Jun 21, 2021 at 7:57 AM Konrad Kohbrok wrote: > Hi Th=C3=A9ophile, > > thanks for bringing this up! > > I believe splitting the two structures would be a good idea. It would als= o > allow us to have a second private/public keypair in the init key struct f= or > better FS as suggested in the past by Jo=C3=ABl. > > That being said, I believe we need the lifetime field/extension in both > structs, as init key structs should also have an expiration date. If > anything, the lifetime extension could be omitted in the leaf struct, as > I'm not sure what the consequence would be if a leaf key package expired = in > an active group. (Would other group members still encrypt to the leaf key= ? > Would they reject messages from that member that are not updates? This > would have to be defined in the spec. Or is it already?) > > Cheers, > Konrad > > > Th=C3=A9ophile Wallez hat am 21.06.2021 13:= 04 > geschrieben: > > > > > > Hi and sorry for the late answer, > > > > Is there any good reason to merge the two structures (init keys and lea= f > > content) other than the overlap they have? > > The overlap seems quite small to me (e.g. compared to the "Message > > Framing" section), it looks like it is only an HPKEPublicKey, a > > Credential and a signature. > > The non-overlap seems quite big to me, for example: > > - ProtocolVersion, CipherSuite only belong to init keys > > - parent hash, lifetime only belong to leaf content > > > > I think it would be a good idea to split the two structures again, I > > believe this would simplify the implementations by making parent hash > > easily accessible, and by removing unused values of the leaf content > > (what should we do with ProtocolVersion and CipherSuite, should we chec= k > > that it is consistent with the group state? should we ignore them?) > > > > Thank you for your comments, > > > > Th=C3=A9ophile. > > > > On 22/05/2021 12:20, Raphael Robert wrote: > > > Hi Th=C3=A9ophile, > > > > > > The current scheme was introduced a while ago when we merged the the > KeyPackages that clients publish ahead of time (previously called init > keys) with the KeyPackages that clients use in their leaf nodes. > > > The reason was that there was quite some overlap between the two > structs and the logical consequence was that data that differs for the tw= o > use cases was expressed as extensions. > > > > > > I=E2=80=99d be open to discussing disambiguating this again and I thi= nk I=E2=80=99m > not the only one. This would also pave the way for Jo=C3=ABl=E2=80=99s pr= oposal to have > an additional public key in the init keys in order to improve FS for > members who don=E2=80=99t update quickly. > > > > > > Thanks > > > > > > Raphael > > > > > >> On 21. May 2021, at 23:03, Th=C3=A9ophile Wallez < > theophile.wallez@inria.fr> wrote: > > >> > > >> Hello All, > > >> > > >> The MLS spec includes some extensions that are mandatory. > > >> Considering that this is v1 of the spec, why not just make these int= o > fields and take them out of extensions? > > >> > > >> In particular, in the current draft, the parent hash is only an > extension, but it is mandatory when the leaf is generating an UpdatePath. > > >> Let us make it a field in KeyPackage? > > >> Having it as an extension hides its importance for security, and > makes the draft confusing to read. > > >> Also, it is a bit weird that parent_hash is a field in ParentNode, > and it is an extension in KeyPackage. > > >> > > >> We propose the following changes: > > >> > > >>> New structure: > > >>> struct { > > >>> opaque parent_hash_value<0..255>; > > >>> } ParentHash; > > >>> > > >>> New field in KeyPackage: > > >>> optional parent_hash; > > >>> > > >>> This optional field must be present in the `leaf_key_package` of an > UpdatePath (same constraints as the current extension). > > >> Or: > > >> > > >>> New field in KeyPackage: > > >>> opaque parent_hash<0..255>; > > >>> > > >>> `parent_hash` must be non-empty in the `leaf_key_package` of an > UpdatePath (same constraints as the current extension). > > >> Best regards, > > >> Th=C3=A9ophile, Benjamin, and > Karthik_______________________________________________ > > >> MLS mailing list > > >> MLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c6c63405c596ae00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would oppose such a big change this late in the gam= e.=C2=A0 There is substantial overlap in what is needed from KeyPackages an= d leaf nodes in the tree, and designing some new leaf struct would require = significant reinvention and revalidation to ensure that we haven't dama= ged the authentication properties of the protocol.

--RLB

On Mon, Jun 21, 2021 at 7:57 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de&g= t; wrote:
Hi Th= =C3=A9ophile,

thanks for bringing this up!

I believe splitting the two structures would be a good idea. It would also = allow us to have a second private/public keypair in the init key struct for= better FS as suggested in the past by Jo=C3=ABl.

That being said, I believe we need the lifetime field/extension in both str= ucts, as init key structs should also have an expiration date. If anything,= the lifetime extension could be omitted in the leaf struct, as I'm not= sure what the consequence would be if a leaf key package expired in an act= ive group. (Would other group members still encrypt to the leaf key? Would = they reject messages from that member that are not updates? This would have= to be defined in the spec. Or is it already?)

Cheers,
Konrad

> Th=C3=A9ophile Wallez <theophile.wallez@inria.fr> hat am 21.06.2021 13:0= 4 geschrieben:
>
>=C2=A0
> Hi and sorry for the late answer,
>
> Is there any good reason to merge the two structures (init keys and le= af
> content) other than the overlap they have?
> The overlap seems quite small to me (e.g. compared to the "Messag= e
> Framing" section), it looks like it is only an HPKEPublicKey, a <= br> > Credential and a signature.
> The non-overlap seems quite big to me, for example:
> - ProtocolVersion, CipherSuite only belong to init keys
> - parent hash, lifetime only belong to leaf content
>
> I think it would be a good idea to split the two structures again, I <= br> > believe this would simplify the implementations by making parent hash =
> easily accessible, and by removing unused values of the leaf content <= br> > (what should we do with ProtocolVersion and CipherSuite, should we che= ck
> that it is consistent with the group state? should we ignore them?) >
> Thank you for your comments,
>
> Th=C3=A9ophile.
>
> On 22/05/2021 12:20, Raphael Robert wrote:
> > Hi Th=C3=A9ophile,
> >
> > The current scheme was introduced a while ago when we merged the = the KeyPackages that clients publish ahead of time (previously called init = keys) with the KeyPackages that clients use in their leaf nodes.
> > The reason was that there was quite some overlap between the two = structs and the logical consequence was that data that differs for the two = use cases was expressed as extensions.
> >
> > I=E2=80=99d be open to discussing disambiguating this again and I= think I=E2=80=99m not the only one. This would also pave the way for Jo=C3= =ABl=E2=80=99s proposal to have an additional public key in the init keys i= n order to improve FS for members who don=E2=80=99t update quickly.
> >
> > Thanks
> >
> > Raphael
> >
> >> On 21. May 2021, at 23:03, Th=C3=A9ophile Wallez <theophile.wallez@in= ria.fr> wrote:
> >>
> >> Hello All,
> >>
> >> The MLS spec includes some extensions that are mandatory.
> >> Considering that this is v1 of the spec, why not just make th= ese into fields and take them out of extensions?
> >>
> >> In particular, in the current draft, the parent hash is only = an extension, but it is mandatory when the leaf is generating an UpdatePath= .
> >> Let us make it a field in KeyPackage?
> >> Having it as an extension hides its importance for security, = and makes the draft confusing to read.
> >> Also, it is a bit weird that parent_hash is a field in Parent= Node, and it is an extension in KeyPackage.
> >>
> >> We propose the following changes:
> >>
> >>> New structure:
> >>> struct {
> >>> opaque parent_hash_value<0..255>;
> >>> } ParentHash;
> >>>
> >>> New field in KeyPackage:
> >>> optional<ParentHash> parent_hash;
> >>>
> >>> This optional field must be present in the `leaf_key_pack= age` of an UpdatePath (same constraints as the current extension).
> >> Or:
> >>
> >>> New field in KeyPackage:
> >>> opaque parent_hash<0..255>;
> >>>
> >>> `parent_hash` must be non-empty in the `leaf_key_package`= of an UpdatePath (same constraints as the current extension).
> >> Best regards,
> >> Th=C3=A9ophile, Benjamin, and Karthik________________________= _______________________
> >> MLS mailing list
> >> MLS@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/mls=
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000c6c63405c596ae00-- From nobody Sun Jun 27 01:31:08 2021 Return-Path: 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 D32E23A20C4 for ; Sun, 27 Jun 2021 01:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=P3gVVG6v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Di/buf5l 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 QYvUNj69uc9m for ; Sun, 27 Jun 2021 01:30:56 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B713A20C5 for ; Sun, 27 Jun 2021 01:30:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 30D9C32007F9 for ; Sun, 27 Jun 2021 03:32:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 27 Jun 2021 03:32:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=jRcb2AECcpm pwtWo7Fo3VZ0KglIAceEG6D/OQ5Rjlgs=; b=P3gVVG6vfRcGHyG0MH+x0FRdifX 9oBTy898uhAODK6lR5Be0fpk27ETwvyGkAX8Jc4SoNJcYHKn5DhQQ3yiLGIjBjjB Vqa8iF5ltxI75RwZQWbf1LEtuiNgZhxqH2jzMXCgMaQptJ1XGFhtG/YtqiiKM05o lfsCQPVpv/9zo7nu6FBOEtAiPI2bv3rUHPM5CE+j89qFgvhlZXo4Ap1491J9Naak KbPmnih5Wxm9bZ0CgVjUydGCYHd3RyH3Yef8XpfImKHhx645+GFdvl1rdB2O8rZ6 vtjwQnDtyekiicvxG9vDWeP3agH7o8kqt30leOBrgRCJIIuCUeV9gNPBvzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=jRcb2AECcpmpwtWo7Fo3VZ0KglIAceEG6D/OQ5Rjlgs=; b=Di/buf5l AI1NTW+Wy736w78ZzPEzmOOBKTQMNfi9Lo8HfuHKemhrWl/v65gtXw0XL67z+C0I F5ikxAmnYOmW56PsE7Zcf2A9uZyKvPNEDGCXI/RNOgYzmRNCLQ4zmRJ0pB8XxezL ATIv2WJLRSQlYhGXyoYDYcdXGrJg2bEcTYJOTGg05sbgk/4ImYM0su0XMeKhfNEg rEQaio51/AlybdD/FzSCDz6Fkvc+P3FZV0VE0tRI6p5/SHhNSr3RMaFIYT6vSvpi 6LnHH316LkwWLLgbJkdjclla1x1ZmO9RxD9VPtxeYpw+nojeGzlOJJSwqZ3lyiHh 5j7hBl8YkQ9R2Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehuddguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 27 Jun 2021 03:32:54 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4085175883936744803==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210627083056.E4B713A20C5@ietfa.amsl.com> Date: Sun, 27 Jun 2021 01:30:56 -0700 (PDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org 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, 27 Jun 2021 08:31:03 -0000 --===============4085175883936744803== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC4) 1 issues received 4 new comments: - #468 Clarify relationship between Ratchet Tree Evolution, Group Creatio= n, and Key Schedule (4 by knightcode) https://github.com/mlswg/mls-protocol/issues/468=20 Pull requests ------------- * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #469 Fix typos in the "IANA Considerations" section (1 by beurdouche) https://github.com/mlswg/mls-protocol/pull/469=20 1 pull requests merged: - Fix typos in the "IANA Considerations" section https://github.com/mlswg/mls-protocol/pull/469=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============4085175883936744803== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday June 27, 2021

Issues

mlswg/mls-protocol (+0/-0/=F0=9F=92=AC4)

1 issues received 4 new comments:

Pull requests

mlswg/mls-protocol (+0/-1/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============4085175883936744803==--