From nobody Sun May 2 01:01:07 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 6D4F53A22DE for ; Sun, 2 May 2021 01:01:05 -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=FGk+wGVS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K5k9Fwg4 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 2SHFIPUWyyKS for ; Sun, 2 May 2021 01:01:00 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7843A22DC for ; Sun, 2 May 2021 01:01:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E111613EA for ; Sun, 2 May 2021 03:41:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 02 May 2021 03:41:51 -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=vmOQJIuk5Ry Mlw+jJkCMhzee1u2B+rYSp7XEfx8twMw=; b=FGk+wGVSmx5XOlkyt1/+aypOBUL EQSI4usI5dJnIipWXLsLZ6bxey4LYJH5wfYRffXBNrbCbhZwFlkeNDo/VGBYBdoj bwFDWy5mkfp7W29FFJ/rYxxAtohuS/4hfH41MujxD9t5XMwv8AK1IkpeEoYwMOpL zOa0uMEanIv3eLi3KECIqZPXfG0aoQ0UQOQSAPL24u4WwTgv5fjXvLHtM56JPlhN YtGm5g6xdPoVKruiE50v6/rI6i248HdAuzALFO7lwenMAKThKoqFdoachcbDRR+f rdXj2i2u9aLBmhgBjbe2qqLw2e0Reg6rYOpuJ6L3SwYPHZP14vB4VW/Z2Fw== 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= fm2; bh=vmOQJIuk5RyMlw+jJkCMhzee1u2B+rYSp7XEfx8twMw=; b=K5k9Fwg4 lNBHipq6yh8lVmXj8sdrbO4bv/2piuu/p+D8f5wkgjh8FsE4oPpC8vH1t3bG1TCU Grf7/98OsXpbp9n46f7N66pZoJRaXrnpKJqrDc291KbnEoVsTUxQ1RoJHkxagDjg 4fD2GNClmd4Cr9oSM9DIIajI2rzWX/zsGz2Q/5QDzlptNGk3B0CUcni2mzmMQkIw Hf/rCD5te9AvwBHjmaOX3pyplzh6WCDd5dHwwlIm9G+CfzTKDgZXHbNcCLFT38Vf mdaiK79ppRtHbxv/W+UPeEJedUoqDrRJn2sBBLkjanRv7jwNcq78cOShw5Vd6M+L h0C1m7E6mbj1RQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefuddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepudefrdekvddruddrudekleenucevlhhushhtvghrufhiiigvpedvnecu rfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvg ht X-ME-Proxy: Received: from fv-az201-515.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net (unknown [13.82.1.189]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 2 May 2021 03:41:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3219658279811307225==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210502080100.BC7843A22DC@ietfa.amsl.com> Date: Sun, 2 May 2021 01:01:00 -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, 02 May 2021 08:01:06 -0000 --===============3219658279811307225== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 issues created: - Clarify relationship between Ratchet Tree Evolution, Group Creation, an= d Key Schedule (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 --===============3219658279811307225== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday May 02, 2021

Issues

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

1 issues created:

Repositories tracked by this digest:

--===============3219658279811307225==-- From nobody Mon May 3 07:03:56 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 E86D33A13AE for ; Mon, 3 May 2021 07:03:49 -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=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 FFMl6WHLykVr for ; Mon, 3 May 2021 07:03:45 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 166A83A1363 for ; Mon, 3 May 2021 07:03:44 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 8so5060324qkv.8 for ; Mon, 03 May 2021 07:03:44 -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=hWC+hXROuhpKCEX5rww3m53Jo8hAsRkWeQzI/Zq1ylo=; b=mpf+qmUEi5GgRUcF9PwNETMokctQNdm8BiQUwHwTDbfBy7QVdccq4hSuuLhQel7kHZ wcqd2XlVmcnV9rDMvXdssiB8yat5ZoZrtPZntDITvEcO4BfLcSEDawrpWuDMDtBa1jYs +kH/BU7sz0U76dpzY+DgDcosUgyBiIr517FzU= 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=hWC+hXROuhpKCEX5rww3m53Jo8hAsRkWeQzI/Zq1ylo=; b=WmF84+9TKMHjFgCjt3PgfVrfVMTUk9WCF/ym65fdMtBa0LhFupghWVBIq0VImEOXaq Lmgl22nV1YjY/zCghz8BCcf5T+XvmgDcXw+dlTEba3fQiF5sAM2qyiUVY2Yq0WDKLaS6 7V6sOwpW3eCt6HSUoGRCHF0tOVNjQvfyJdsM3BRCYHi1oSHyw46qnDaWIgMyXCXEFCWn V6FKh5780NRZQkOSafdG3Go9OzmW7VQPKZw+4eDOUMIxl3qTFeOYhjHpbBm/3qknY7BZ 0jtWNm76PiplaUZ6A+h9sibAaAtNZYmrUoKuIjPhW3Fx1ZXrt5yvigngT5OarlmE5H2I a3dg== X-Gm-Message-State: AOAM531935+tJwBl0LqRkNw5jG0dsbFmD6E9ZuxwjZ9e1QuunXy2APk5 tFqnsvQ8H54PoOwP8ksWvvJA9Q2t8Rr0kg== X-Google-Smtp-Source: ABdhPJzzgV03hfyQH//34CFbEpb0d8AFtJZJMaTt1z5pezTX8i7DKoSWImiqgpxoEQ2C7DAG3gpu2w== X-Received: by 2002:a37:58c5:: with SMTP id m188mr19100886qkb.327.1620050622955; Mon, 03 May 2021 07:03:42 -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 q125sm8559045qkf.68.2021.05.03.07.03.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 May 2021 07:03:42 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <19C0CBD8-FAA9-4F2E-9F71-F38E4BD16F4F@sn3rd.com> Date: Mon, 3 May 2021 10:03:41 -0400 To: MLS List X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [MLS] Virtual Interim Poll 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, 03 May 2021 14:03:55 -0000 Hi! It=E2=80=99s about time to have another virtual interim WG meeting = to iron any remaining issues. We would also like to get an update on the = architecture I-D. The chairs are proposing the week of May 24-28. Please = fill out the following doodle poll to indicate your availability: https://doodle.com/poll/5zpgt5rz7msvaikc?utm_source=3Dpoll&utm_medium=3Dli= nk Cheers, spt (for the chairs)= From nobody Tue May 4 05:22:24 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 6EC043A3242 for ; Tue, 4 May 2021 05:22:22 -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 VabkqjQoI54a for ; Tue, 4 May 2021 05:22:17 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 21FDB3A3246 for ; Tue, 4 May 2021 05:22:17 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id j3so4256257qvs.1 for ; Tue, 04 May 2021 05:22:16 -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:date:references :to:in-reply-to:message-id; bh=02XqgJlYMQ6RbhoJwH4FgiIEh03xhT5RbxM9VewtDUU=; b=AoAGziSzj4yHjo5ZXoJhEp9EWFvyarebwssV2A06amWxNodaSWGuqfIO17UwK8fJ03 eilLqfZ5Yz5KUWAyBKumPkiF8PGQ1cEFVLCy6XuWJMLWs1SzKIa3j5wiYckjlkABOG0n AodsLoLTT8MqJXuqbVOANPs3+k9W1H2cxICa0= 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:date:references:to:in-reply-to:message-id; bh=02XqgJlYMQ6RbhoJwH4FgiIEh03xhT5RbxM9VewtDUU=; b=HgYFljLo7lJJRAU0jYTzlR43v8IN6G2h8WikLp3Ill1KxyMqqYUyunLY6uKsTMRJ4k kEFqWCj5LaI7q3wiFYMt4q959YgueF95TyzaIn0DHjwBMA20uyOCIhKodlSn7Ix1EjwX cjmeB+Kfl1Ih6A4XNgirixoHX4sp0zU8amVEzvcuQpxFPy6qLNSjdwr2MdYxVUCDc5d7 IUanIIl6ivYhcqXENWFkEIvCPoMp4UVgcfzU/HecW27l/ykmY3IM97HFtllWNEHp5Eap 5FIh05d+6cSmNA1GfG7n8+IM+AeIsi7BkwwDvh2p7aeu230dNn4ltHxLr7NqZGyI8H1v RAWw== X-Gm-Message-State: AOAM530bIInNdylj0c28iCWXKhldqKen+EtwBR24RG7bHgXcYykjvKES +lGhKWSLqfHoynzlvZsRoJFJhz5+d4NDew== X-Google-Smtp-Source: ABdhPJxpa77CWSkgzlfoIW73BnkFbncKIvwHlFCHAAsvt1Q/0hKBunh2ai0hUG1qtL9QxpTxvav1xA== X-Received: by 2002:a0c:9e5e:: with SMTP id z30mr25561933qve.61.1620130935418; Tue, 04 May 2021 05:22:15 -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 g5sm2786453qtm.2.2021.05.04.05.22.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 May 2021 05:22:14 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 4 May 2021 08:22:13 -0400 References: <19C0CBD8-FAA9-4F2E-9F71-F38E4BD16F4F@sn3rd.com> To: MLS List In-Reply-To: <19C0CBD8-FAA9-4F2E-9F71-F38E4BD16F4F@sn3rd.com> Message-Id: <51FA4B25-86F1-43E2-8E8E-A04370FCD415@sn3rd.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Virtual Interim Poll 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, 04 May 2021 12:22:22 -0000 Thanks to those that have responded so far. I should have mentioned that we would like to arrive at a decision by = the end of this week so please do indicate your availability before = then. Cheers, spt > On May 3, 2021, at 10:03, Sean Turner wrote: >=20 > Hi! It=E2=80=99s about time to have another virtual interim WG meeting = to iron any remaining issues. We would also like to get an update on the = architecture I-D. The chairs are proposing the week of May 24-28. Please = fill out the following doodle poll to indicate your availability: > = https://doodle.com/poll/5zpgt5rz7msvaikc?utm_source=3Dpoll&utm_medium=3Dli= nk >=20 > Cheers, > spt (for the chairs) From nobody Thu May 6 10:57:41 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 073C83A2AF1 for ; Thu, 6 May 2021 10:57:40 -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, FREEMAIL_FROM=0.001, 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 (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 O5eccuN4nFrK for ; Thu, 6 May 2021 10:57:35 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 E883F3A2AF0 for ; Thu, 6 May 2021 10:57:34 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id q10so1641970qkc.5 for ; Thu, 06 May 2021 10:57:34 -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=WTHTJdMFZuVc4yXTGa6vLNrFB6lf55dvuXLnc18DPkQ=; b=mrNejQsh2AqlA2IPbrhRkWPT/NiHiEuGvTtBFeeacAoc1t/9O1+hJSWpDHRyp0e76A YxSaz1Ido23VHM7OX03WwptOiZKfDZaIzB7nwA6ja7EGXZBkBc6tRvwn8vT4R+HpBf+z MQEK8VUEFb0CuQ8om7k9Nw7y8bhYdwnP7OQuQLfMRPGd2hc88xeRt9+DUglNidla8J3k RTUnGGDiILW93UJAyv3KTmIxtixO7p4OzyjbiKi5CKbwJPzk7nROkebQG4lt/emP0FZ5 c8BQEQ1+bxFLWvsxb7Ve90vM2nRPcwz6EDEUF34XBjs3YRTJLHM2s83NxyP5PDwGr2hC mQcA== 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=WTHTJdMFZuVc4yXTGa6vLNrFB6lf55dvuXLnc18DPkQ=; b=sjH1XjXvl5Fz0xLcupul+1MTYEtwoSkNb5DXZnbFe9AI0D3i1L90OI/Lj+auTfevCg Ii6Q/S7NY0LGPYsAUo3Epo9f2piHw5abbIta/Ys2PMSKwfiR8AxxjIXCLjpg3c7rSppC e/Ux48eZdJqgbgBlEN2lJJoHQnAkpCB0NdssTTrsq5+cJ2yRT50tJpHJbNSERTomlo+u r3NRWbCvhFfDNQXEF3vXav0ipcSrPBpRrAsITvuSmXdTAP7GcjLV3Iop5AtvGreyEKkN MziwwzgSdnbTE8SsNKBrPbpdKGoDVRSU10SFrX1qhy2aoJ+birdbfZ8isXoBH2jWBzxD lPaA== X-Gm-Message-State: AOAM530hVkCJpOH5/RxXgyNpE4uG5E95Ba43jGWVZ3WqlezvH8nSs+os Vx+iZiVIdUwGXqyYmAZoO00eLz77g381w02u+d9m9+zoK5oAyg== X-Google-Smtp-Source: ABdhPJyeqVVospSOXgeGrNKCjkfYs5QwPDQzHLEwKSgq2xLSwW/kWg4aGem0+DXIA9cAFr03MXuq/W8kBaOCFLlRp1Q= X-Received: by 2002:a05:620a:1593:: with SMTP id d19mr5115613qkk.211.1620323851560; Thu, 06 May 2021 10:57:31 -0700 (PDT) MIME-Version: 1.0 From: Alec Muffett Date: Thu, 6 May 2021 18:56:55 +0100 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000097eb1505c1ad0b60" Archived-At: Subject: [MLS] Functional Definition of End-to-End Secure Messaging 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, 06 May 2021 17:57:40 -0000 --00000000000097eb1505c1ad0b60 Content-Type: text/plain; charset="UTF-8" Hi All, I am drafting an I-D to offer a measurable definition of End-to-End Secure Messaging, including End-to-End Encrypted Messaging. It's basically a "Duck Test" for End-to-End Secure Messengers: "Does quack like an E2EE-Secure Messenger, should?" I believe that such a definition is a long-overdue necessity for settling arguments such as "Would adding a Ghost participant *really* break End-to-End Security" (answer: "yes"). I think that the MLS group might be a good workgroup for such a document. What do you think, please? Current draft text: https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.txt As HTML: https://htmlpreview.github.io/?https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secure-messaging.html - Alec -- https://alecmuffett.com/about --00000000000097eb1505c1ad0b60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I am drafting an I-D to offer a measu= rable definition of End-to-End Secure Messaging, including End-to-End Encry= pted Messaging.

It's basically a "Duck Test" for End-t= o-End Secure Messengers: "Does <this software> quack like an E2E= E-Secure Messenger, should?"

I believe that such a definition i= s a long-overdue necessity for settling arguments such as "Would addin= g a Ghost participant *really* break End-to-End Security" (answer: &qu= ot;yes").

I think that the MLS group might be a good workgroup = for such a document.=C2=A0

--00000000000097eb1505c1ad0b60-- From nobody Fri May 7 01:40:54 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 DFAFB3A11E8 for ; Fri, 7 May 2021 01:40:43 -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, HTML_MESSAGE=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 (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 IZJnvGVrbJ9h for ; Fri, 7 May 2021 01:40:38 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 4B4FE3A11D0 for ; Fri, 7 May 2021 01:40:38 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id s20so6874975ejr.9 for ; Fri, 07 May 2021 01:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lzKNFDRxjlTNuncS7QnAfxBigzcwHa4GjNDhUVsaE1A=; b=tJKkIQn9fuHcyGmHYfZ1Foh1iLLxGARnGaCZZGkZ+7mKrQdqaSQUPPR5xPsoYR0GJw EAsAIA9UNM928H3glWGVTxFRyTTG7mMZXIKb8noAgWa6ZL9GkXkfKX26X4pQWZ4EcKHg 3YUpxffNmcAV9N7N598N8oetc8BNNGeMlj+Ns= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lzKNFDRxjlTNuncS7QnAfxBigzcwHa4GjNDhUVsaE1A=; b=hGKfL2plsoH+cjmPFKEilVJ8ZNkviroxQ1/FZeKrs+0IP+oRJDB+0hQLgDpwBItJHQ sWXJoJ+E5zTPVstinFhsjTlYES9nbaIvBjwGSD3pryN3JNZOZXCk84hXIi3urcppnxHn 48CoyT1n45bn8FyA5TD/Kw6OiOO48PUK+dlI9mB5K38zCyi1FpZHA/hIPkjNxDv7Inp4 B0DoRKaxUZpxzMuk8ShB5iOq/io7ldx7jW/+0WmX/6RQS1tI+SitYML2CfvkIm+cjLdz 6nrEM15Ij7aJ/v1g/1inbj2hbjWwbv6JyvQ+gg8HAem4wrZEkEjbPLXCr/8OwyDQZ6S1 rqAg== X-Gm-Message-State: AOAM532jUkrX64c56OP+tKiYV0UCBHoKVsCV+TYmMApBfS9zodpfRwhl KZrfIFBtxrK2HGEKlZkzW/lBb4kDizTKwtOW9QU= X-Google-Smtp-Source: ABdhPJyjfs+TNDvfpfJzbzLid9Z8pegIMzKba3ttDqnZmpEvqw7i4wfwn0fHbeWNJNl17Vt52mvBlQ== X-Received: by 2002:a17:906:55cc:: with SMTP id z12mr2152952ejp.318.1620376835597; Fri, 07 May 2021 01:40:35 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id lr15sm3039941ejb.107.2021.05.07.01.40.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 01:40:35 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_49ABECEA-4474-4690-8C12-9153CCC47188" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 10:40:34 +0200 In-Reply-To: Cc: Alec Muffett To: Messaging Layer Security WG References: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 08:40:53 -0000 --Apple-Mail=_49ABECEA-4474-4690-8C12-9153CCC47188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for sharing! You mention the prior art by Knodel et al. at the end and I=E2=80=99m = wondering if it wouldn=E2=80=99t be a better starting point for = discussion? Especially since it has the advantage of building upon = notions that are well-defined and established in the industry. I=E2=80=99m also still struggling with your definition of a = =E2=80=9Cbackdoor=E2=80=9D in 4.4: 'A "backdoor" is any intentional or unintentional mechanism, in respect of a given message and that message's set of participants, where some PCASM of that message MAY become available to a non- participant without the intentional action of a participant.=E2=80=99 You previously mentioned that intent is hard to measure and I agree with = that. But I=E2=80=99m quite convinced a design or implementation flaw = shouldn=E2=80=99t be called a =E2=80=9Cbackdoor=E2=80=9D until there is = sufficient proof of intent. If you call it a =E2=80=9Cbackdoor=E2=80=9D = right from the beginning, most people will assume that intent was there. = This would be very discouraging for everyone who contributes to E2EE = protocols, because it introduces the risk of being stigmatised as = someone with (criminal) intent just because an honest mistake was made. = Long story short, I strongly reject that notion of a =E2=80=9Cbackdoor=E2=80= =9D for being intimidating. That being said, discussion around these topics is a good thing and = I=E2=80=99m curious to hear other people=E2=80=99s thoughts! Raphael > On 6. May 2021, at 19:56, Alec Muffett wrote: >=20 > Hi All, >=20 > I am drafting an I-D to offer a measurable definition of End-to-End = Secure Messaging, including End-to-End Encrypted Messaging. >=20 > It's basically a "Duck Test" for End-to-End Secure Messengers: "Does = quack like an E2EE-Secure Messenger, should?" >=20 > I believe that such a definition is a long-overdue necessity for = settling arguments such as "Would adding a Ghost participant *really* = break End-to-End Security" (answer: "yes"). >=20 > I think that the MLS group might be a good workgroup for such a = document.=20 >=20 > What do you think, please? >=20 > Current draft text: > = https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/b= lob/main/text/draft-muffett-end-to-end-secure-messaging.txt = >=20 > As HTML: > = https://htmlpreview.github.io/?https://github.com/alecmuffett/draft-muffet= t-end-to-end-secure-messaging/blob/main/text/draft-muffett-end-to-end-secu= re-messaging.html = >=20 > - Alec >=20 > -- > https://alecmuffett.com/about = ___________________________________________= ____ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_49ABECEA-4474-4690-8C12-9153CCC47188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for sharing!

You mention the prior art by Knodel et al. at the end and = I=E2=80=99m wondering if it wouldn=E2=80=99t be a better starting point = for discussion? Especially since it has the advantage of building upon = notions that are well-defined and established in the industry.

I=E2=80=99m also still = struggling with your definition of a =E2=80=9Cbackdoor=E2=80=9D in = 4.4:

'A = "backdoor" is any intentional or unintentional mechanism, in
respect of a given message and that message's set of = participants,
where some PCASM of that message MAY become = available to a non-
participant without the intentional = action of a participant.=E2=80=99

You previously mentioned that intent is = hard to measure and I agree with that. But I=E2=80=99m quite convinced a = design or implementation flaw shouldn=E2=80=99t be called a = =E2=80=9Cbackdoor=E2=80=9D until there is sufficient proof of intent. If = you call it a =E2=80=9Cbackdoor=E2=80=9D right from the beginning, most = people will assume that intent was there. This would be very = discouraging for everyone who contributes to E2EE protocols, because it = introduces the risk of being stigmatised as someone with (criminal) = intent just because an honest mistake was made. Long story short, I = strongly reject that notion of a =E2=80=9Cbackdoor=E2=80=9D for being = intimidating.

That being said, discussion around these topics is a good = thing and I=E2=80=99m curious to hear other people=E2=80=99s = thoughts!

Raphael

On 6. May 2021, at 19:56, Alec = Muffett <alec.muffett@gmail.com> wrote:

Hi All,

I am = drafting an I-D to offer a measurable definition of End-to-End Secure = Messaging, including End-to-End Encrypted Messaging.

It's basically a "Duck Test" for End-to-End Secure = Messengers: "Does <this software> quack like an E2EE-Secure = Messenger, should?"

I believe that such a = definition is a long-overdue necessity for settling arguments such as = "Would adding a Ghost participant *really* break End-to-End Security" = (answer: "yes").

I think that the MLS group = might be a good workgroup for such a document. 

_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_49ABECEA-4474-4690-8C12-9153CCC47188-- From nobody Fri May 7 05:13:46 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 974253A1E6C for ; Fri, 7 May 2021 05:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 Fq_sf2Ob41jR for ; Fri, 7 May 2021 05:13:39 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 662FC3A1E64 for ; Fri, 7 May 2021 05:13:39 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id u7so4633858qvv.12 for ; Fri, 07 May 2021 05:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cPhYXj9DSY3xjm8OI0aqKAwgXX1fI/5/k+JBX5HK2Uo=; b=tfaVgmG0D2waAeh/1pa+0DORN8bWg0SKcjl6KYnAZm4WxpuO7mn6cNLmDI+VD683sE RhVSHRnNRPIBYgniObn06opTtzVmM8Uu4gBWKupCwsDahu49vOKmpVm8sXFqUJ1eZJtw zKZK9/XEFhrzEdtN9gcCrymXVPfV9bQYNnJjTjt5Kee6tMtAPxSs4EjX0bZdjq45JOwL FDqrSsyEUKMmMdLszE9T0gbfR6HQa60bT8blb5IX/N5B/9OszsQCELQfA7E59eeLXV89 J3HkbM/6WjvkfKZIOYOYQPg1w7/Dt3dwxE1jrNHsYHKq/jYlJlXhnZmg7YBwUXcqIGl+ GEvQ== 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=cPhYXj9DSY3xjm8OI0aqKAwgXX1fI/5/k+JBX5HK2Uo=; b=Ugooo27ZrTtLi1QtvxynLLvrM836gTGce36S+eawOC+su1mc1TofsGbRzhgorfGlR6 7RBhoT+JQVaskFvEi0J0p3Tj5ZqSDDZbf3NeqG62f2QHEFWLAgEYLh2fiAeqWsmpT3up 27mDZXmUqjjDDX26MPAbwsbG84m1LzAdJDQjHhaQJR4cXiP0tN3i3yLgMT2BahcLyUvo 9/aivXAWiPVTUqzu5DszLRAzGFd7oaw489Kwul7sKNXp2nVjKqpXAaos+ndsGqVIpUXE qrmXVyoT0DNbmg0vzqHlSGEUa8bvbHRyOkDpXjKCzilC40A0axv5qIqAKl2rC+hOUXOb 9/Mw== X-Gm-Message-State: AOAM531Koqv8YpF5k9JeRNVVAiYViFhzexwkrF3fgyPm2v90Hqo8Mflu xDAqMhpQtE8BWZ3wOF9HdSYO6m/DzINDQD5R2YA= X-Google-Smtp-Source: ABdhPJxH/BhbdFdrIHb9S3myA6Z+lFXASoOkEDffedW1VVbt0gfXSjR3UWUsW/fQ/ZtGEQkslctHm/Zv1BFW/IcS/E4= X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr9396289qve.27.1620389617228; Fri, 07 May 2021 05:13:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Fri, 7 May 2021 13:13:00 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000885e7305c1bc5bb3" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 12:13:45 -0000 --000000000000885e7305c1bc5bb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Raphael! Those are great questions, and I have already updated the draft to address the latter one, but will paste the explanation here, too. On Fri, 7 May 2021 at 09:40, Raphael Robert wrote: > Thanks for sharing! > You mention the prior art by Knodel et al. at the end and I=E2=80=99m won= dering if > it wouldn=E2=80=99t be a better starting point for discussion? > Especially since it has the advantage of building upon notions that are > well-defined and established in the industry. > I feel that there need to be two separate approaches; *draft-knodel-e2ee-definition-00* focuses deeply upon platform "goals" qualitative provision of end-to-end *encryption* solutions, rather than to specify what is necessary for an end-to-end secure (via client-server-centric encryption, or otherwise) messenger solution to be worthy of the (currently ill-defined, but widely used) terminology. It describes "scanning" rather what the effects of "scanning" would look like; it describes "not allowing pattern inference" but remains open to someone redefining what "inference" means, as opposed to leveraging "indistinguishability" for a concrete definition. There is a lot of overlap, but in the end https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5 leaves the applied definition of E2E-Encryption somewhat open, whereas draft-muffett-end-to-end-secure-messaging-00 is essentially a long and nitpicky way of saying "If you're gonna call something end-to-end secure, here is what 'end' means, and you will need to respect your ends." Obviously with enough discussion and rewriting it would be possible to somewhat merge the two documents, but since they take separate routes towards addressing the matter, I am inclined to see both go forward and see how their utility compares. > I=E2=80=99m also still struggling with your definition of a =E2=80=9Cback= door=E2=80=9D in 4.4: > ... > You previously mentioned that intent is hard to measure and I agree with > that. But I=E2=80=99m quite convinced a design or implementation flaw sho= uldn=E2=80=99t be > called a =E2=80=9Cbackdoor=E2=80=9D until there is sufficient proof of in= tent. If you call > it a =E2=80=9Cbackdoor=E2=80=9D right from the beginning, most people wil= l assume that > intent was there. > This would be very discouraging for everyone who contributes to E2EE > protocols, because it introduces the risk of being stigmatised as someone > with (criminal) intent just because an honest mistake was made. Long stor= y > short, I strongly reject that notion of a =E2=80=9Cbackdoor=E2=80=9D for = being intimidating. > I hear that you are worried about pejorative stigma of terminology, so let me share the rationale that I've just added to the draft: > > > > > > *In software engineering there is a perpetual tension between the concept= s > of "feature" versus "bug" - and occasionally "misfeature" versus "misbug"= . > These tensions arise from the problem of [DualUse] - that it is not > feasible to firmly and completely ascribe "intention" to any hardware or > software mechanism.The information security community have experienced a > historical spectrum of mechanisms which have assisted non-participant > access to PCASM. These have variously been named as "export-grade key > restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and > Meltdown), "law enforcement access fields" (Clipper), and "key escrow" > (Crypto Wars).All of these terms combine an "access facilitation mechanis= m" > with an "intention or opportunity" - and for all of them an access > facilitation mechanism is first REQUIRED.An access facilitation mechanism > is a "door", and is inherently [DualUse]. Because the goal of E2ESM is to > limit access to PCASM exclusively to a defined set of participants, then > the intended means of access is clearly the "front door"; and any other > access mechanism is a "back door".If the term "back door" is considered > innately pejorative, alternative, uncertain constructions such as > "illegitimate access feature", "potentially intentional data-access > weakness", "legally-obligated exceptional access mechanism", or any other > phrase, all MUST combine both notions of an access mechanism (e.g. "door"= ) > and a definite or suspected intention (e.g. "legal obligation").So the > phrase "back door" is brief, clear, and widely understood to mean "a > secondary means of access". In the above definition we already allow for > the term to be prefixed with "intentional" or "unintentional".Thus it see= ms > appropriate to use this term in this context, not least because it is als= o > not far removed from the similar and established term "side channel".* ...and to call out that last point, I find it particularly interesting to compare "back door" to "side channel"; to me, neither are particularly stigmatic until combined with an adjective to describe "intent". I have a back door in my house. It's not inherently evil. - alec --=20 https://alecmuffett.com/about --000000000000885e7305c1bc5bb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Raphael!

Those are great questions, and I have al= ready updated the draft to address the latter one, but will paste the expla= nation here, too.

On Fri, 7 May 2021 at 09:40, = Raphael Robert <ietf@raphaelro= bert.com> wrote:
Thanks for sharing!
You me= ntion the prior art by Knodel et al. at the end and I=E2=80=99m wondering i= f it wouldn=E2=80=99t be a better starting point for discussion?=C2=A0
Especially since it has the adva= ntage of building upon notions that are well-defined and established in the= industry.

I feel that th= ere need to be two separate approaches; draft-knodel-e2ee-definition-00<= /i> focuses deeply upon platform "goals" qualitative provision of= end-to-end encryption=C2=A0solutions, rather than to specify what i= s necessary for an end-to-end secure (via client-server-centric encryption,= or otherwise) messenger solution to be worthy of the (currently ill-define= d, but widely used) terminology.=C2=A0 It describes "scanning" ra= ther what the effects of "scanning" would look like; it describes= "not allowing pattern inference" but remains open to someone red= efining what "inference" means, as opposed to leveraging "in= distinguishability" for a concrete definition.=C2=A0

There is a lot of overlap, but in the end=C2=A0https://tools= .ietf.org/html/draft-knodel-e2ee-definition-00#section-5 leaves the app= lied definition of E2E-Encryption somewhat open, whereas draft-muffett-end-= to-end-secure-messaging-00 is essentially a long and nitpicky way of saying= "If you're gonna call something end-to-end secure, here is what &= #39;end' means, and you will need to respect your ends."

<= /div>
Obviously with enough discussion and rewriting it would be = possible to somewhat merge the two documents, but since they take separate = routes towards addressing the matter, I am inclined to see both go forward = and see how their utility compares.

=C2=A0
I=E2=80=99m also still struggling with your definition of a =E2= =80=9Cbackdoor=E2=80=9D in 4.4:
...
You previously = mentioned that intent is hard to measure and I agree with that. But I=E2=80= =99m quite convinced a design or implementation flaw shouldn=E2=80=99t be c= alled a =E2=80=9Cbackdoor=E2=80=9D until there is sufficient proof of inten= t. If you call it a =E2=80=9Cbackdoor=E2=80=9D right from the beginning, mo= st people will assume that intent was there.
<= div style=3D"color:rgb(0,0,0)">
This wo= uld be very discouraging for everyone who contributes to E2EE protocols, be= cause it introduces the risk of being stigmatised as someone with (criminal= ) intent just because an honest mistake was made. Long story short, I stron= gly reject that notion of a =E2=80=9Cbackdoor=E2=80=9D for being intimidati= ng.


I hear that you are worried about= pejorative stigma of terminology, so let me share the rationale that I'= ;ve just added to the draft:

I= n software engineering there is a perpetual tension between the concepts of= "feature" versus "bug" - and occasionally "misfea= ture" versus "misbug". These tensions arise from the problem= of [DualUse] - that it is not feasible to firmly and completely ascribe &q= uot;intention" to any hardware or software mechanism.
The informati= on security community have experienced a historical spectrum of mechanisms = which have assisted non-participant access to PCASM. These have variously b= een named as "export-grade key restrictions" (TLS, then Logjam), = "side channel attacks" (Spectre and Meltdown), "law enforcem= ent access fields" (Clipper), and "key escrow" (Crypto Wars)= .
All of these terms combine an "access facilitation mechanism"= ; with an "intention or opportunity" - and for all of them an acc= ess facilitation mechanism is first REQUIRED.
An access facilitation mec= hanism is a "door", and is inherently [DualUse]. Because the goal= of E2ESM is to limit access to PCASM exclusively to a defined set of parti= cipants, then the intended means of access is clearly the "front door&= quot;; and any other access mechanism is a "back door".
If the= term "back door" is considered innately pejorative, alternative,= uncertain constructions such as "illegitimate access feature", &= quot;potentially intentional data-access weakness", "legally-obli= gated exceptional access mechanism", or any other phrase, all MUST com= bine both notions of an access mechanism (e.g. "door") and a defi= nite or suspected intention (e.g. "legal obligation").
So the = phrase "back door" is brief, clear, and widely understood to mean= "a secondary means of access". In the above definition we alread= y allow for the term to be prefixed with "intentional" or "u= nintentional".
Thus it seems appropriate to use this term in this c= ontext, not least because it is also not far removed from the similar and e= stablished term "side channel".
=C2=A0
...and to call out that last point, I find it particularl= y interesting to compare "back door" to "side channel";= to me, neither are particularly stigmatic until combined with an adjective= to describe "intent".

I have a back doo= r in my house.=C2=A0 It's not inherently evil.
=C2=A0<= /div>
=C2=A0 =C2=A0 - alec

--
=
--000000000000885e7305c1bc5bb3-- From nobody Fri May 7 05:53:35 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 F35D53A1FB5 for ; Fri, 7 May 2021 05:53:32 -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_DNSWL_BLOCKED=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=cridland.net 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 x8FX7C3xt_L1 for ; Fri, 7 May 2021 05:53:28 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 E6DD23A2000 for ; Fri, 7 May 2021 05:51:59 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id d11so9138465wrw.8 for ; Fri, 07 May 2021 05:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82TphbPngo3Y6XvbD04BkzMUKPIaaSCdcRvwlROZGUQ=; b=Bbb1ihFEIT+3MjxzMMN1smA3tXoD1P36Rz1qBGRZYw4vBu11WCapCZZuYPHABhGZBY 6NtpbiEUgTkoLltsWGXQUIHx1fNF4NnG/wVNzeLJIG6Gu1M6p6FucG4DTmqMz1C0ypqu yf8jixyiKFLATFjdAYU76sFUEyksmi3Pgpb0w= 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=82TphbPngo3Y6XvbD04BkzMUKPIaaSCdcRvwlROZGUQ=; b=ZNwJbCjvKPJ/i7QCmjDOh4lki0H2UeL4Xzf7wnkX68lzbMxFToXzQEnO2Fhlus8SeI fO3dJ4e2hjtSsdiYBpkZ/6H1V+5gr/4zX4xysVWJnYbGgQzdWMVnao6Be9yC5jzSufgS hu+QbSBwnr4+ZMw9v2z92Wdbe98mYe7XsC7aeTVCCoykd31nS9i6dSSiQSUpLFxabSH2 Pl4MJL2MYe5vlyaV90rHPDWmuATLAoPT1ijI12j+SeNj8FG6dgYAxpYmxf6nLtkcvkTI lrzFs7de70ZU7stPgnw50xUPQlfUQZTmA82qZ7FE9GLxwqZJUNV0ft/zs7sz7yutvbRw N5ng== X-Gm-Message-State: AOAM5330OkbQnMPu+K6lAUUr5AoNhRkczNVALLGLnY5SkPioyvVS/KdE Ug8tkGGkMl8m5OXMJLb/zO6BRIqgeIVke7Rj/kv27w== X-Google-Smtp-Source: ABdhPJwyPnNWDgC5DGL5xnUz/XEOoji+UaT61a7ucwSb9fy71X/2AXiNrd2schrp1eRsCfAypFztEIO6V3fbiO/7Nyc= X-Received: by 2002:a05:6000:1b06:: with SMTP id f6mr12075117wrz.339.1620391917836; Fri, 07 May 2021 05:51:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cridland Date: Fri, 7 May 2021 13:51:47 +0100 Message-ID: To: Alec Muffett Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000a8ecbf05c1bce422" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 12:53:33 -0000 --000000000000a8ecbf05c1bce422 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alec, On Thu, 6 May 2021 at 18:57, Alec Muffett wrote: > What do you think, please? > As I said on Twitter, I'm hesitant to try to build a one-size-fits-all definition of "secure". I think a much more useful first step (and one where consensus is much easier to gain) would be to talk about different threats and their potential mitigations and trade-offs, rather than blanket statements that things are or are not secure in some absolute sense which I'm unconvinced exists. "Secure" is not an absolute, and has to be handled in context. MLS provides a (very) useful set of tools with which to build various models of secure, including the consumer-grade personal security you appear to be driving toward. The primary objection I have here is that people will make the assumption that any system that does not conform to your arbitrary definition of "Secure" is, by inference, "Insecure". As an example, consider =C2=A73.3. I currently write instant messaging applications for the NHS (the UK's National Health Service, its overwhelmingly dominant health provider) as well as others, for clinical messaging. This obviously needs to be secure. Your stipulation is that clinicians joining a particular group chat must not be able to see past messages. This in turn means that clinicians must be ill-informed about the patient's past, and therefore there is a heightened clinical risk to the patient. I would argue that patient safety should be an outcome of an applicable security stance. I think there is genuine risk involved in providing people with a misleading single definition of "secure". This is not to say that your definition is particularly "wrong"; it's not capable of being wrong for the same reason that it's not capable of being "right". Dave. --000000000000a8ecbf05c1bce422 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alec,

What do you think,=C2=A0please?
=C2=A0
As I said on Twitter, I'm hesitant= =C2=A0to try to build a one-size-fits-all definition of "secure".= I think a much more useful first step (and one where consensus is much eas= ier to gain) would be to talk about different threats and their potential m= itigations and trade-offs, rather than blanket=C2=A0statements that things = are or are not secure in some absolute=C2=A0sense which I'm unconvinced= exists. "Secure" is not an absolute, and has to be handled in co= ntext. MLS provides a (very) useful set of tools with which to build variou= s models of secure, including the consumer-grade personal security you appe= ar to be driving toward.

The primary objection I h= ave here is that people will make the assumption that any system that does = not conform to your arbitrary definition of "Secure" is, by infer= ence, "Insecure".

As an example, conside= r =C2=A73.3. I currently write instant messaging applications for the NHS (= the UK's National Health Service, its overwhelmingly dominant health pr= ovider) as well as others, for clinical messaging. This obviously needs to = be secure. Your stipulation is that clinicians joining a particular group c= hat must not be able to see past messages. This in turn means that clinicia= ns must be ill-informed about the patient's past, and therefore there= =C2=A0is a heightened clinical risk to the patient. I would argue that pati= ent=C2=A0safety should be an outcome of an applicable security stance. I th= ink there is genuine risk involved in providing people with a misleading si= ngle definition of "secure".

This is= not to say that your definition is particularly "wrong"; it'= s not capable of being wrong for the same reason that it's not capable = of being "right".

Dave.
--000000000000a8ecbf05c1bce422-- From nobody Fri May 7 06:50:43 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 608653A2247 for ; Fri, 7 May 2021 06:50:42 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 5blumvsXMbdO for ; Fri, 7 May 2021 06:50:37 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 2FB1D3A2249 for ; Fri, 7 May 2021 06:50:37 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id c11so6513931qth.2 for ; Fri, 07 May 2021 06:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h3yAeFy99rtOV4fY2QOOkWq4T0ULT9syhIX6ARuhKUM=; b=elDzbXxnzIfrgY2rLoxRBSl/Ev/VaOL/qsw4Fnw39H9U54rQWXbo7myAzMjk1/0GVu 2jNyHEtOL2LVMD+ZsO6FQ7B7hg67qenSsoV4mP17GnRfnhLDdNfWYEFtnzFOi1XH6fsK XlX2boBF8kNP4z2XMIqP3VPqR8sCSgyjpzHs+wwoS+Po74y6IffsMV8lJsLlNvw4Lwny vXHwmNw5Ez96nrUqIV9zdhIe5MyskA21m1fHfJQUkRoYZb/rXGT6Nds2zGdlsU1+Bvp9 0w5QYC6jz+B/FQQ+P3H1Hxcr5lgX4Q/XfmM4N0uah61iqn4npapnkFiXaRoqn3bvi/qW 1euQ== 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=h3yAeFy99rtOV4fY2QOOkWq4T0ULT9syhIX6ARuhKUM=; b=XaRGtoRZAaA+3R/DqwUQriPI33r3Epds5Ow5yAIJG5gzE4HCl0AkSmhmdwMD5aKL9j BsRYYyR1h27id75MuI0lNuPvTsZXoIqmOT3vfT/b386hyHdwMQsbscE0amuZCWq8eH88 5H78RmIbIWyzUkTKxSdT2UELAtmZU6tACBRFEhktpiamPlM1ZKABW5YFGHlAkkuS0pGn dgAoDxGntTKaVfXQoMRilgSDnEbIotpK6co02lvOOuU7KzlL3BJIl5yta/AJk7/Uv6fo uDc9+qoZ0ga/u66256p+UziqDGpiy9EP2Z6V0frfaIKmHPr5hjO4CCRsqV+7SsqI4KFK LArA== X-Gm-Message-State: AOAM533b1CXAeJYbiTzH47y2KN1d/KNB8MQzLAaiyFlevIiGdNorIzcm scNehiqKBqMRpP6eADYcl5NDzqnWqg9zRmTN5cA= X-Google-Smtp-Source: ABdhPJzX0Xx/v41eK042Taq6EonhhGz9dX22LpI8jFaPwul8fd2xrkG/Uf0nifR+s0i+0xlr4quLgtPjYRDvLpgKUY8= X-Received: by 2002:ac8:574e:: with SMTP id 14mr60473qtx.191.1620395434673; Fri, 07 May 2021 06:50:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Fri, 7 May 2021 14:49:58 +0100 Message-ID: To: Dave Cridland Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000047898205c1bdb6c5" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 13:50:43 -0000 --00000000000047898205c1bdb6c5 Content-Type: text/plain; charset="UTF-8" Hey Dave! Nice to follow up in long-form. :-) On Fri, 7 May 2021 at 13:51, Dave Cridland wrote: > As I said on Twitter, I'm hesitant to try to build a one-size-fits-all > definition of "secure". > But that's not what I am trying to do; I am trying to build a one-size-fits-all definition of "end-to-end secure", which is pretty easy to do because there's an inherent threat-model in the phrase "end to end". It comes down to "there are ends. respect them." > I think a much more useful first step (and one where consensus is much > easier to gain) would be to talk about different threats and their > potential mitigations and trade-offs, rather than blanket statements that > things are or are not secure in some absolute sense which I'm unconvinced > exists. > The set of threats is practically infinite, and as we're aware from firewall design it is much more robust to work with an "allowlist" rather than a "blocklist". Hence this approach. > "Secure" is not an absolute > I agree. > and has to be handled in context. > And the context is "end to end", and - especially - "end" is a term that many use and few strictly define. MLS provides a (very) useful set of tools with which to build various > models of secure, including the consumer-grade personal security you appear > to be driving toward. > I am not driving towards anything other than a measurable definition of "end-to-end secure messaging". > The primary objection I have here is that people will make the assumption > that any system that does not conform to your arbitrary definition of > "Secure" is, by inference, "Insecure". > That *is* an objection, however it pivots on the assertion that I am somehow attempting to define "secure" - but I am not. The document clearly states that it is a "Functional Definition of End-to-End Secure Messaging"; perhaps you can suggest how to make that more clear? As an example, ... Your stipulation is that clinicians joining a particular > group chat must not be able to see past messages. This in turn means that > clinicians must be ill-informed about the patient's past, and therefore > there is a heightened clinical risk to the patient. I would argue that > patient safety should be an outcome of an applicable security stance. I > think there is genuine risk involved in providing people with a misleading > single definition of "secure" > That's a great question with a practical use-case, but to me it begs the question of: "why is the system that you [Dave] are describing, appropriate to describe as 'end-to-end secure'?" - who are the ends? Are the messages stored in such a way that they could be accessed by a non-participant, for instance a database administrator? Where is your forward secrecy, and how is what you describe somehow different to (say) a security-hardened version of Facebook Messenger? These are questions which really ought to be asked of *every* platform, and they are *not* being asked, because we have no metric to measure against. Hence this document. This is not to say that your definition is particularly "wrong"; it's not > capable of being wrong for the same reason that it's not capable of being > "right". > I disagree, and I suggest that it is the very nature of your critique which demonstrates the functional requirement for a metric like draft-muffett-end-to-end-secure-messaging - alec -- https://alecmuffett.com/about --00000000000047898205c1bdb6c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Dave!=C2=A0

Nice to follow up in long-form. :-)

On Fri, 7 May 2021= at 13:51, Dave Cridland <dave@crid= land.net> wrote:
As = I said on Twitter, I'm hesitant=C2=A0to try to build a one-size-fits-al= l definition of "secure".

=
But that's not what I am trying to do; I am trying to build=C2=A0a= one-size-fits-all definition of "end-to-end secure", which is pr= etty easy to do because there's an inherent threat-model in the phrase = "end to end".

It comes down to "the= re are ends. respect them."

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">
I think a much more useful first ste= p (and one where consensus is much easier to gain) would be to talk about d= ifferent threats and their potential mitigations and trade-offs, rather tha= n blanket=C2=A0statements that things are or are not secure in some absolut= e=C2=A0sense which I'm unconvinced exists.

The set of threats is practically infinite, and as we'r= e aware from firewall design it is much more robust to work with an "a= llowlist" rather than a "blocklist".=C2=A0 Hence this approa= ch.

=C2=A0
=
"Secure" is not an absolute
I agree.

=C2=A0
and has to be handled in context.

And the context is "end to end", and -= especially - "end" is a term that many use and few strictly defi= ne.
=C2=A0

=
MLS provides a (very) useful set of tools with which to build various = models of secure, including the consumer-grade personal security you appear= to be driving toward.

I am= not driving towards anything other than a measurable definition of "e= nd-to-end secure messaging".

=C2=A0
Th= e primary objection I have here is that people will make the assumption tha= t any system that does not conform to your arbitrary definition of "Se= cure" is, by inference, "Insecure".

That *is* an objection, however it pivots on the = assertion that I am somehow attempting to define "secure" - but I= am not.

The document clearly states that it is a = "Functional Definition of End-to-End Secure Messaging"; perhaps y= ou can suggest how to make that more clear?


As an= example, ... Your stipulation is that clinicians joining a particular grou= p chat must not be able to see past messages. This in turn means that clini= cians must be ill-informed about the patient's past, and therefore ther= e=C2=A0is a heightened clinical risk to the patient. I would argue that pat= ient=C2=A0safety should be an outcome of an applicable security stance. I t= hink there is genuine risk involved in providing people with a misleading s= ingle definition of "secure"
<= br>
That's a great question with a practical use-case, but to= me it begs the question of:

=C2=A0 "why is t= he system that you [Dave] are describing, appropriate to describe as 'e= nd-to-end secure'?"=C2=A0

- who are the e= nds?=C2=A0 Are the messages stored in such a way that they could be accesse= d by a non-participant,=C2=A0for instance a database administrator? Where i= s your forward secrecy, and how is what you describe somehow different to (= say) a security-hardened version of Facebook Messenger?

These are questions which really ought to be asked of *every* platfor= m, and they are *not* being asked, because we have no metric to measure aga= inst.=C2=A0 Hence this document.
=C2=A0

This is not to= say that your definition is particularly "wrong"; it's not c= apable of being wrong for the same reason that it's not capable of bein= g "right".

I di= sagree, and I suggest that it is the very nature of your critique which dem= onstrates the functional requirement for a metric like draft-muffett-end-to= -end-secure-messaging

=C2=A0 =C2=A0 - alec

--
--00000000000047898205c1bdb6c5-- From nobody Fri May 7 07:50:45 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 AACBF3A24C2 for ; Fri, 7 May 2021 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 dKtsJDpky9ju for ; Fri, 7 May 2021 07:50:38 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 5FE533A24BD for ; Fri, 7 May 2021 07:50:38 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id gx5so14010731ejb.11 for ; Fri, 07 May 2021 07:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=f0dmoDtzWNMnKipke9upYYq/XYcSxBjG5dzQrw5UWcc=; b=uUiV3a/loJXXWGHB/gkw42aN3fpkCZo30ElrNAtX9JRiiUNAOMaDT5khBxKstXQYuA oJHfEzPDYi+0y6SUj1gnKt1P7yk+Qnw2JYGguA2q/TEkSWEdTw7t6QONz7ow0gBrQTHL JMg1P0rt6XzQbf6TkiUBIdiOEv4CuJyAH7jX8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=f0dmoDtzWNMnKipke9upYYq/XYcSxBjG5dzQrw5UWcc=; b=XnbDWsWP6htPFXtF63p17TjhaHkkab/iN7A9RKkYMqapTMAfG1kZV08A1vGMtnzltQ GVT4fd9dFWKXq+req5x6q0hefm01Ivm5LW6/TmAZrrhEGrzQ9hWXNemLfwzDiNDJY8U0 AqZ9M/+QukVJ1TDWnzOWRmqMBe8MaxiRShFTJMjA4XlzUcZZ6bN2p2mNSaOqG0Zmr5N7 wg1sXu4SGLhC5eZHJs2tnwXUPWi/UgB+Lkzjg+EPWaozC/uRAFh1SuWnlTzHPgcFicMP Acjfiaiu57mDdbWwpltc685IfLu7vHXVJuzQk/V6iY1NKECtMYwNr7KfiTihliPrq9bh NA4Q== X-Gm-Message-State: AOAM530/OzMFDfGIOjfNxRqBRwv0CmvmqaMEvreifJ+OoaKtuFr7CR4/ UTY/jDYkiNzjxVVBrpSbT6qHBA== X-Google-Smtp-Source: ABdhPJw4HWV1cbt9FeuWeA1pM2Ec2bhaSB9LMrXiVTzsVhIqLFYjAfkFWZxb65t6icIaFdkp9Dw0Zw== X-Received: by 2002:a17:906:1684:: with SMTP id s4mr10289724ejd.506.1620399031444; Fri, 07 May 2021 07:50:31 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id d25sm3583349ejd.59.2021.05.07.07.50.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 07:50:30 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6F8F9074-CE3A-4438-9F0A-B19DDE4E3F66" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 16:50:29 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Alec Muffett References: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 14:50:44 -0000 --Apple-Mail=_6F8F9074-CE3A-4438-9F0A-B19DDE4E3F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7. May 2021, at 14:13, Alec Muffett wrote: >=20 > Hey Raphael! >=20 > Those are great questions, and I have already updated the draft to = address the latter one, but will paste the explanation here, too. >=20 > On Fri, 7 May 2021 at 09:40, Raphael Robert > wrote: > Thanks for sharing! > You mention the prior art by Knodel et al. at the end and I=E2=80=99m = wondering if it wouldn=E2=80=99t be a better starting point for = discussion?=20 > Especially since it has the advantage of building upon notions that = are well-defined and established in the industry. >=20 > I feel that there need to be two separate approaches; = draft-knodel-e2ee-definition-00 focuses deeply upon platform "goals" = qualitative provision of end-to-end encryption solutions, rather than to = specify what is necessary for an end-to-end secure (via = client-server-centric encryption, or otherwise) messenger solution to be = worthy of the (currently ill-defined, but widely used) terminology. It = describes "scanning" rather what the effects of "scanning" would look = like; it describes "not allowing pattern inference" but remains open to = someone redefining what "inference" means, as opposed to leveraging = "indistinguishability" for a concrete definition.=20 I agree that the two drafts a quite different. Yours is much more = specific in certain aspects. And this is where it also gets tricky :) Dave has a good point that it might not be straight forward to have a = =E2=80=9Cone-size-fits-all=E2=80=9D model. = draft-knodel-e2ee-definition-00 is much broader could certainly be = expanded to include more precise definitions to illustrate the more = abstract notions. Just having fixed set of precise criteria sounds nice = in terms of simplicity but might simply prove to be insufficient to = capture all valid use cases. In either case, having a document that can be used as a checklist to = determine with absolute certainty whether a system is = end-to-end-encrypted or not sound like a dangerous endeavour. Given the = complexity of the subject, the answer cannot always be binary. When you say =E2=80=9Cill-defined, but widely used terminology=E2=80=9D, = what exactly are you referring to? Statements in the press? What exact = problem needs fixing here? Having a bit more context on that would = certainly help with the overall assessment. Maybe we are just talking = past each other. >=20 > There is a lot of overlap, but in the end = https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#section-5 = = leaves the applied definition of E2E-Encryption somewhat open, whereas = draft-muffett-end-to-end-secure-messaging-00 is essentially a long and = nitpicky way of saying "If you're gonna call something end-to-end = secure, here is what 'end' means, and you will need to respect your = ends." >=20 > Obviously with enough discussion and rewriting it would be possible to = somewhat merge the two documents, but since they take separate routes = towards addressing the matter, I am inclined to see both go forward and = see how their utility compares. >=20 > =20 > I=E2=80=99m also still struggling with your definition of a = =E2=80=9Cbackdoor=E2=80=9D in 4.4: > ... > You previously mentioned that intent is hard to measure and I agree = with that. But I=E2=80=99m quite convinced a design or implementation = flaw shouldn=E2=80=99t be called a =E2=80=9Cbackdoor=E2=80=9D until = there is sufficient proof of intent. If you call it a =E2=80=9Cbackdoor=E2= =80=9D right from the beginning, most people will assume that intent was = there. > This would be very discouraging for everyone who contributes to E2EE = protocols, because it introduces the risk of being stigmatised as = someone with (criminal) intent just because an honest mistake was made. = Long story short, I strongly reject that notion of a =E2=80=9Cbackdoor=E2=80= =9D for being intimidating. >=20 >=20 > I hear that you are worried about pejorative stigma of terminology, so = let me share the rationale that I've just added to the draft: >=20 > In software engineering there is a perpetual tension between the = concepts of "feature" versus "bug" - and occasionally "misfeature" = versus "misbug". These tensions arise from the problem of [DualUse] - = that it is not feasible to firmly and completely ascribe "intention" to = any hardware or software mechanism. > The information security community have experienced a historical = spectrum of mechanisms which have assisted non-participant access to = PCASM. These have variously been named as "export-grade key = restrictions" (TLS, then Logjam), "side channel attacks" (Spectre and = Meltdown), "law enforcement access fields" (Clipper), and "key escrow" = (Crypto Wars). > All of these terms combine an "access facilitation mechanism" with an = "intention or opportunity" - and for all of them an access facilitation = mechanism is first REQUIRED. > An access facilitation mechanism is a "door", and is inherently = [DualUse]. Because the goal of E2ESM is to limit access to PCASM = exclusively to a defined set of participants, then the intended means of = access is clearly the "front door"; and any other access mechanism is a = "back door". > If the term "back door" is considered innately pejorative, = alternative, uncertain constructions such as "illegitimate access = feature", "potentially intentional data-access weakness", = "legally-obligated exceptional access mechanism", or any other phrase, = all MUST combine both notions of an access mechanism (e.g. "door") and a = definite or suspected intention (e.g. "legal obligation"). > So the phrase "back door" is brief, clear, and widely understood to = mean "a secondary means of access". In the above definition we already = allow for the term to be prefixed with "intentional" or "unintentional". > Thus it seems appropriate to use this term in this context, not least = because it is also not far removed from the similar and established term = "side channel". > =20 > ...and to call out that last point, I find it particularly interesting = to compare "back door" to "side channel"; to me, neither are = particularly stigmatic until combined with an adjective to describe = "intent". >=20 > I have a back door in my house. It's not inherently evil. Whoever built the back door to your house hopefully did so with full = intent :) This is precisely where I see the problem: doors are = mechanisms built with full intent to enter a building/room. If the = building/room can also be entered because the walls were not made thick = enough (intentionally or unintentionally), we wouldn=E2=80=99t call this = a door. So only when there is a strong suspicion of intent (preferably = evidence), something should be called a door. I simply cannot convince = myself that a door can be something that is built unintentionally. Hence = the risk of stigma. But maybe I just have an unusual understanding of what a door is. I = would love to hear other opinions on this. Raphael > =20 > - alec >=20 > --=20 > https://alecmuffett.com/about >=20 --Apple-Mail=_6F8F9074-CE3A-4438-9F0A-B19DDE4E3F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7. May 2021, at 14:13, Alec Muffett <alec.muffett@gmail.com> wrote:

Hey Raphael!

Those are great questions, and I have = already updated the draft to address the latter one, but will paste the = explanation here, too.

On Fri, 7 May 2021 at 09:40, Raphael Robert <ietf@raphaelrobert.com> wrote:
Thanks for sharing!
You = mention the prior art by Knodel et al. at the end and I=E2=80=99m = wondering if it wouldn=E2=80=99t be a better starting point for = discussion? 
Especially since it has the = advantage of building upon notions that are well-defined and established = in the industry.

I feel that there need to be two = separate approaches; draft-knodel-e2ee-definition-00 = focuses deeply upon platform "goals" qualitative provision of end-to-end = encryption solutions, rather than to specify what = is necessary for an end-to-end secure (via client-server-centric = encryption, or otherwise) messenger solution to be worthy of the = (currently ill-defined, but widely used) terminology.  It describes = "scanning" rather what the effects of "scanning" would look like; it = describes "not allowing pattern inference" but remains open to someone = redefining what "inference" means, as opposed to leveraging = "indistinguishability" for a concrete = definition. 

I agree that the two = drafts a quite different. Yours is much more specific in certain = aspects. And this is where it also gets tricky :)
Dave has a = good point that it might not be straight forward to have a = =E2=80=9Cone-size-fits-all=E2=80=9D = model. draft-knodel-e2ee-definition-00 is much broader could = certainly be expanded to include more precise definitions to illustrate = the more abstract notions. Just having fixed set of precise criteria = sounds nice in terms of simplicity but might simply prove to be = insufficient to capture all valid use cases.
In either case, = having a document that can be used as a checklist to determine with = absolute certainty whether a system is end-to-end-encrypted or not sound = like a dangerous endeavour. Given the complexity of the subject, the = answer cannot always be binary.

When = you say =E2=80=9Cill-defined, but widely used terminology=E2=80=9D, what = exactly are you referring to? Statements in the press? What exact = problem needs fixing here? Having a bit more context on that would = certainly help with the overall assessment. Maybe we are just talking = past each other.


There is a lot of overlap, but in the end https://tools.ietf.org/html/draft-knodel-e2ee-definition-00#sec= tion-5 leaves the applied definition of E2E-Encryption somewhat = open, whereas draft-muffett-end-to-end-secure-messaging-00 is = essentially a long and nitpicky way of saying "If you're gonna call = something end-to-end secure, here is what 'end' means, and you will need = to respect your ends."

Obviously with enough discussion and rewriting it would be = possible to somewhat merge the two documents, but since they take = separate routes towards addressing the matter, I am inclined to see both = go forward and see how their utility compares.

 
I=E2=80=99m also still struggling with your = definition of a =E2=80=9Cbackdoor=E2=80=9D in 4.4:
...
You previously = mentioned that intent is hard to measure and I agree with that. But = I=E2=80=99m quite convinced a design or implementation flaw shouldn=E2=80=99= t be called a =E2=80=9Cbackdoor=E2=80=9D until there is sufficient proof = of intent. If you call it a =E2=80=9Cbackdoor=E2=80=9D right from the = beginning, most people will assume that intent was = there.
This would be very discouraging for everyone who contributes = to E2EE protocols, because it introduces the risk of being stigmatised = as someone with (criminal) intent just because an honest mistake was = made. Long story short, I strongly reject that notion of a = =E2=80=9Cbackdoor=E2=80=9D for being = intimidating.


I hear that you are worried about = pejorative stigma of terminology, so let me share the rationale that = I've just added to the draft:

In software engineering = there is a perpetual tension between the concepts of "feature" versus = "bug" - and occasionally "misfeature" versus "misbug". These tensions = arise from the problem of [DualUse] - that it is not feasible to firmly = and completely ascribe "intention" to any hardware or software = mechanism.
The information security community have = experienced a historical spectrum of mechanisms which have assisted = non-participant access to PCASM. These have variously been named as = "export-grade key restrictions" (TLS, then Logjam), "side channel = attacks" (Spectre and Meltdown), "law enforcement access fields" = (Clipper), and "key escrow" (Crypto Wars).
All of these = terms combine an "access facilitation mechanism" with an "intention or = opportunity" - and for all of them an access facilitation mechanism is = first REQUIRED.
An access facilitation mechanism is a = "door", and is inherently [DualUse]. Because the goal of E2ESM is to = limit access to PCASM exclusively to a defined set of participants, then = the intended means of access is clearly the "front door"; and any other = access mechanism is a "back door".
If the term "back door" = is considered innately pejorative, alternative, uncertain constructions = such as "illegitimate access feature", "potentially intentional = data-access weakness", "legally-obligated exceptional access mechanism", = or any other phrase, all MUST combine both notions of an access = mechanism (e.g. "door") and a definite or suspected intention (e.g. = "legal obligation").
So the phrase "back door" is brief, = clear, and widely understood to mean "a secondary means of access". In = the above definition we already allow for the term to be prefixed with = "intentional" or "unintentional".
Thus it seems = appropriate to use this term in this context, not least because it is = also not far removed from the similar and established term "side = channel".
 
...and to call out that = last point, I find it particularly interesting to compare "back door" to = "side channel"; to me, neither are particularly stigmatic until combined = with an adjective to describe "intent".

I have a back door in my house.  = It's not inherently = evil.

Whoever built the back door to = your house hopefully did so with full intent :) This is precisely where = I see the problem: doors are mechanisms built with full intent to enter = a building/room. If the building/room can also be entered because the = walls were not made thick enough (intentionally or unintentionally), we = wouldn=E2=80=99t call this a door. So only when there is a strong = suspicion of intent (preferably evidence), something should be called a = door. I simply cannot convince myself that a door can be something that = is built unintentionally. Hence the risk of stigma.
But maybe = I just have an unusual understanding of what a door is. I would love to = hear other opinions on this.

Raphael


= --Apple-Mail=_6F8F9074-CE3A-4438-9F0A-B19DDE4E3F66-- From nobody Fri May 7 07:59:34 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 B14953A2521 for ; Fri, 7 May 2021 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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=cdt.org 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 bDcyvoLj8432 for ; Fri, 7 May 2021 07:59:28 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 E797D3A2519 for ; Fri, 7 May 2021 07:59:27 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id j11so6759176qtn.12 for ; Fri, 07 May 2021 07:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:references:content-language :to:from:subject:in-reply-to; bh=b4fz9ROmmJ7LuPGfXIA0r2Qk9m/ZoAkQUJyADkR3tH4=; b=hmoKLI/bdxAluXCJxivAbix8CW5edonUSwBXG/JemqTZ0/1jXXkaj7ioEcPsebfdts xk7Jh7auUbZ4ocqY7V4CR64IEvU1HwSEvxuu7/2eeee2ono/iT60ay0c50s3B44wgn6U lTQ2PDF7AHYfufgkDOPT+PRNj0K39yf/0qKQM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent :references:content-language:to:from:subject:in-reply-to; bh=b4fz9ROmmJ7LuPGfXIA0r2Qk9m/ZoAkQUJyADkR3tH4=; b=D/s6r4s/xLB0YDsXhUqsBiMY4KPIOOBzNUg33LvfVcVp+6CRSLLqyQ740xAVlFK6o4 x2KdPwUNds7SiqjJuWwPpHRvWRXpNe2LjJiWI/zskMQLbyD0z+lKk9+bF7Z0fuwtVxkS IU1/pW0AXrc0S8MLdnrpiD1WRTttLbS8ZzBF4357h1MDsKs/+F9B0iJvta3TqPb2ND9W edFHfGvjcqRTuSf6cb860TFvcakUHlD72ExwW/jGkVLtQ5TNw+N8ww80Nc9QjLhRDFTa C5W8KDik11aRPhmP/tBuwOkleIKFe9CuOuYds6bX6Z6y4+a+90pqIeW0YqvwRFN5C1QH bDIw== X-Gm-Message-State: AOAM530Lx1Gci5d3anmQ6LKeXLi395r/4SlW3Q1jAV2+EVHACsB1uaQD C1UdYmqaJ5v3HHms5HhRaicyWPZVb9qViPNk X-Google-Smtp-Source: ABdhPJzELfKv4PP+wZBuaWJ3Kx2R48vUFCjts4JvAgb/fBA4Kav2JqR2rlkhecR5ssGNdLekwwQYFA== X-Received: by 2002:a05:622a:342:: with SMTP id r2mr9715756qtw.232.1620399564620; Fri, 07 May 2021 07:59:24 -0700 (PDT) Received: from [192.168.0.130] (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with UTF8SMTPSA id c5sm4665973qkl.7.2021.05.07.07.59.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 May 2021 07:59:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------mhIhvIF5OLLLfeY0Zp5qN8Zd" Message-ID: <818a638a-a687-5fb2-0f93-9654f4a1d9e9@cdt.org> Date: Fri, 7 May 2021 10:59:23 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0 References: <162039893366.31953.3182470506238059389@ietfa.amsl.com> Content-Language: en-US To: Messaging Layer Security WG From: Mallory Knodel In-Reply-To: <162039893366.31953.3182470506238059389@ietfa.amsl.com> X-Forwarded-Message-Id: <162039893366.31953.3182470506238059389@ietfa.amsl.com> Archived-At: Subject: [MLS] Fwd: New Version Notification for draft-knodel-e2ee-definition-01.txt 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, 07 May 2021 14:59:33 -0000 This is a multi-part message in MIME format. --------------mhIhvIF5OLLLfeY0Zp5qN8Zd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, There's been oblique discussion of this draft, thanks to Alec's citation in his recent effort. My co-authors and I thought we should go ahead and share a -01 version with the group. Most of our feedback so far has been around better definition of an end, so we broke that into its own sub-section. The goal is to clearly define e2ee in three different ways: constituent formal definition, functionalities, and user expectations. This assumes a technology is defined by its properties. Conversely, we are not trying to define properties by the technology in use, eg "this app is secure because it's e2ee", which is totally valid. But without our effort, it's becomes circular. Lastly I'll just mention that while we aim to define e2ee, we also end up defining a few other terms as well. It's perhaps worth considering this a terminology draft for the mls working group, as Raphael just suggested. We are certainly open to that, so please help us by opening issues or sending pull requests to help solidify those terms: https://github.com/mallory/e2ee/edit/main/draft-e2ee.md. Any and all reviews welcome, -Mallory -------- Forwarded Message -------- Subject: New Version Notification for draft-knodel-e2ee-definition-01.txt Date: Fri, 07 May 2021 07:48:53 -0700 From: internet-drafts@ietf.org To: Sofía Celi , Fred Baker , Fred Baker , Gurshabad Grover , Mallory Knodel , Olaf Kolkman , Sofia Celi A new version of I-D, draft-knodel-e2ee-definition-01.txt has been successfully submitted by Mallory Knodel and posted to the IETF repository. Name: draft-knodel-e2ee-definition Revision: 01 Title: Definition of End-to-end Encryption Document date: 2021-05-07 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt Status: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/ Htmlized: https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition Htmlized: https://tools.ietf.org/html/draft-knodel-e2ee-definition-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-knodel-e2ee-definition-01 Abstract: End-to-end encryption (E2EE) is an application of cryptography in communications systems between endpoints. E2EE systems are unique in providing features of confidentiality, integrity and authenticity for users. Improvements to E2EE strive to maximise the system's security while balancing usability and availability. Users of E2EE communications expect trustworthy providers of secure implementations to respect and protect their right to whisper. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------mhIhvIF5OLLLfeY0Zp5qN8Zd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi all,

There's been oblique discussion of this draft, thanks to Alec's citation in his recent effort.

My co-authors and I thought we should go ahead and share a -01 version with the group. Most of our feedback so far has been around better definition of an end, so we broke that into its own sub-section.

The goal is to clearly define e2ee in three different ways: constituent formal definition, functionalities, and user expectations. This assumes a technology is defined by its properties. Conversely, we are not trying to define properties by the technology in use, eg "this app is secure because it's e2ee", which is totally valid. But without our effort, it's becomes circular.

Lastly I'll just mention that while we aim to define e2ee, we also end up defining a few other terms as well. It's perhaps worth considering this a terminology draft for the mls working group, as Raphael just suggested. We are certainly open to that, so please help us by opening issues or sending pull requests to help solidify those terms: https://github.com/mallory/e2ee/edit/main/draft-e2ee.md.

Any and all reviews welcome,

-Mallory



-------- Forwarded Message --------
Subject: New Version Notification for draft-knodel-e2ee-definition-01.txt
Date: Fri, 07 May 2021 07:48:53 -0700
From: internet-drafts@ietf.org
To: Sofía Celi <cherenkov@riseup.net>, Fred Baker <fredbaker.IETF@gmail.com>, Fred Baker <fredbaker.ietf@gmail.com>, Gurshabad Grover <gurshabad@cis-india.org>, Mallory Knodel <mknodel@cdt.org>, Olaf Kolkman <kolkman@isoc.org>, Sofia Celi <cherenkov@riseup.net>



A new version of I-D, draft-knodel-e2ee-definition-01.txt
has been successfully submitted by Mallory Knodel and posted to the
IETF repository.

Name: draft-knodel-e2ee-definition
Revision: 01
Title: Definition of End-to-end Encryption
Document date: 2021-05-07
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt
Status: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
Htmlized: https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition
Htmlized: https://tools.ietf.org/html/draft-knodel-e2ee-definition-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-knodel-e2ee-definition-01

Abstract:
End-to-end encryption (E2EE) is an application of cryptography in
communications systems between endpoints. E2EE systems are unique in
providing features of confidentiality, integrity and authenticity for
users. Improvements to E2EE strive to maximise the system's security
while balancing usability and availability. Users of E2EE
communications expect trustworthy providers of secure implementations
to respect and protect their right to whisper.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------mhIhvIF5OLLLfeY0Zp5qN8Zd-- From nobody Fri May 7 08:05:01 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 6FF203A2590 for ; Fri, 7 May 2021 08:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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=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 m_5xXEVq1b-Z for ; Fri, 7 May 2021 08:04:44 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 ACDA43A257C for ; Fri, 7 May 2021 08:04:44 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id x8so8724295qkl.2 for ; Fri, 07 May 2021 08:04:44 -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:date:references :to:in-reply-to:message-id; bh=BUraTRyMg2KEsj2p6MJ7bhNgraVDqnA1U+2OqZtid/Q=; b=LgY9vkmyMSNeHLBTRVJ9Ni1Xi3eW4nldC3izMNDQJtY9KJyNq1R+p6a/e37irGaIFl S0q1Zj5YhOmsDdHKotR466LVkGTXnXFTnUOvayLnyiCVImRFG6Sae4cIS/bzg990bmk1 nMiaExeobHo/4O5jM4vyFNW2t45eynFM/gvrw= 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:date:references:to:in-reply-to:message-id; bh=BUraTRyMg2KEsj2p6MJ7bhNgraVDqnA1U+2OqZtid/Q=; b=A5b+AcC9eK3PXNaSxXkUmCMrz+MAaUZGIM5RUN0p9Qwe+0HtKNBICYPUlkLykf4Py6 GEGUADTVrcZut/aQdQGt31t6tOUi4W7Dc3TvrXzAvSVT/DOnvZoE/FyRjcBX2IqmR2MF UO/lycPWai75hc7gOzNYGmeNMAa5mVCsReadn4bf5SG/yxh9xgLGBHd400qRUaCQeLGK LQYbZULsM+ZS3mQcMGbEd1TWsDIACf/WkJspCGq1tysWzV6mWl2tKhfKiY+RfBzwLLpb d/V9WTxpwiDTdz/3xWR7iUAxPhI/eT4iuxwQyrdRcHhpu9sPQbYPB6NZ1FuDUbWpTogI 1G1w== X-Gm-Message-State: AOAM532pw9lf/sGxB1LU95UYnMTZKjmLPOUIHijbkw/xtvj15x8pTyS9 i7gMQfjld0xfwoO8hAx3hlFY4P7S82HVTA== X-Google-Smtp-Source: ABdhPJxulQvWJ/i5Tpyjk4NWi9OqUhEYyWIUFOksx4awyAjSy/wxRUQ7x5CHvp5VJvc4RUMCLQgedw== X-Received: by 2002:a37:ba83:: with SMTP id k125mr9825880qkf.336.1620399882982; Fri, 07 May 2021 08:04:42 -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 g5sm6004611qtm.2.2021.05.07.08.04.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 08:04:41 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 11:04:41 -0400 References: <19C0CBD8-FAA9-4F2E-9F71-F38E4BD16F4F@sn3rd.com> <51FA4B25-86F1-43E2-8E8E-A04370FCD415@sn3rd.com> To: MLS List In-Reply-To: <51FA4B25-86F1-43E2-8E8E-A04370FCD415@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Virtual Interim Poll 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, 07 May 2021 15:04:59 -0000 Thanks again for those who responded. It looks like Wednesday the 26th = from 1400-1600 UTC (1600-1800 CEST, 1000-1200 EDT, 0700-0900 PDT) works = well enough for everyone. I will submit the request for the interim and = setup the WebEx. Look for the formal announcement sometime later today. We will make sure to put Joel=E2=80=99s entropy PR first to make sure we = have sufficient time to discuss before he needs to drop.=20 spt > On May 4, 2021, at 08:22, Sean Turner wrote: >=20 > Thanks to those that have responded so far. >=20 > I should have mentioned that we would like to arrive at a decision by = the end of this week so please do indicate your availability before = then. >=20 > Cheers, > spt >=20 >> On May 3, 2021, at 10:03, Sean Turner wrote: >>=20 >> Hi! It=E2=80=99s about time to have another virtual interim WG = meeting to iron any remaining issues. We would also like to get an = update on the architecture I-D. The chairs are proposing the week of May = 24-28. Please fill out the following doodle poll to indicate your = availability: >> = https://doodle.com/poll/5zpgt5rz7msvaikc?utm_source=3Dpoll&utm_medium=3Dli= nk >>=20 >> Cheers, >> spt (for the chairs) >=20 From nobody Fri May 7 09:23:45 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 6C5773A2877 for ; Fri, 7 May 2021 09:23:43 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 BlDLemXSArho for ; Fri, 7 May 2021 09:23:38 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 EB1D13A2872 for ; Fri, 7 May 2021 09:23:36 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id i17so9003342qki.3 for ; Fri, 07 May 2021 09:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IDVqEsXvNvzWyLkYZtTuHFQHeRdTwREj4lwcQDHxgMQ=; b=YYCA9+LSuCY8d4tlQRm/LoUU/InQK1jZowNGeAVVb9+Z2G3t2H/PJaxtOq5GjHIMKn SLxo7EtlZH8Kvg2CGlOhyREfDMtiPdAl2j53w40510xps1C+zSh6nBQCtr1V7VMycbmq LSzfzVRXMvQYrpg7tKRCPuuD8CaMVODSKqx50LNLdu0ozih1tC1QXhQAlVtz5q/UJFu6 /Xjbv6aGlV2R8XQAj2ZAjkFVricvktgJP5SkSTwrtWSYDea2y+sGGMHE+CzjfGVb4Mfv VEoGrVeLfqaMqyDvGoXHAkcDT0EpeH307GyDC/mbcCX6W7kyyLNWeacvuMKDyxol2cHU S4zw== 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=IDVqEsXvNvzWyLkYZtTuHFQHeRdTwREj4lwcQDHxgMQ=; b=O9pk3sT6rMuriNFkjviKg4i1NOBZgM0VXgkB6A62S3ORDMhRhf+rNAfyLxmKG4ieIj FvZP7iqwQOX/ZVvstz6trwUEhbv1TsHkN1/5ChvJx+DEoi6mTKzoHbx0fJTYdrfGq+9D 1/b7+SIx6gk9bcd+J6dChnQeM90BBTtQeMb6S0ws27hIv8BjCeUuxJ5wRgYG6jBdI/2M FkraCjwPWwU4jjpbrgrMiXKHEtYJhT3OzkJLzWm86iN9PiErXjS/W4wbB46GXKjel+IQ 0Gzw3iQi/59S4XlK94vwu71pctUrpq87ELX5Xn73zfr7IQlmPPoG01d7ME+TbmvZqXlk hrBw== X-Gm-Message-State: AOAM5339FxnsqK80D02LjkGAw6hyuSq3L3Ypwk6p4ITjykqSTPh6YgYF WbeV7FfJAfJ7DcT4s3vQQCJiR2s3FCVeYgEg7YYuT7aAI3jASg== X-Google-Smtp-Source: ABdhPJyboK2Za/zI5LPRFUbuKs02CkHwhSRctpYo1bqbTrDZzy+Id1RAqEHwAdIDOQ15RLy2pwGOiSl/pjEaYyIQ6PI= X-Received: by 2002:a05:620a:127b:: with SMTP id b27mr10055641qkl.104.1620404614005; Fri, 07 May 2021 09:23:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Fri, 7 May 2021 17:22:57 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000006907aa05c1bfd9d6" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 16:23:44 -0000 --0000000000006907aa05c1bfd9d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Heya! All references in the attached, are against: URL: https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/bl= ob/157627c713f81a27c9528c87b6e58111ba54e485/text/draft-muffett-end-to-end-s= ecure-messaging.txt ...which should be constant even if the document is subsequently updated. On Fri, 7 May 2021 at 15:50, Raphael Robert wrote: > > I agree that the two drafts a quite different. Yours is much more specifi= c > in certain aspects. And this is where it also gets tricky :) > Dave has a good point that it might not be straight forward to have a > =E2=80=9Cone-size-fits-all=E2=80=9D model. > This is not a one-size-fits-all model of "security". It's a definition of end-to-end secure messengers". It is a formalisation of the following argument: *1/ in an "end-to-end secure messenger", there are "ends"; this flows from the expression* *2/ messages are sent from "ends", to "ends", and a sequence of messages constitutes a "conversation" (obvious?)* *3/ for each message, the set of "ends" is "frozen" upon "send" (3.3) to the current & wholly visible set of conversation "ends" (3.2) ; if it were not frozen thusly we would lack forward secrecy and simply be reinventing Yahoo Messenger, which wasn't end-to-end secure, hence we can't be doing that* *4/ no "end" may have privileged access to content, (3.1 - participating as an 'end' does not somehow bestow exceptional access to content, e.g by also being a database administrator)* *5/ no "non-end" may have any access to content (3.3.2)* *6/ it requires the consent ("intentional action") of an existing member, to add more "ends" to a conversation (3.4) * *7/ the software should help ends understand where they are logged-in (3.5)*That's it. That's the whole specification, although it's padded with stuff like "indistinguishability" to disambiguate questions like *"what if we just leak a *little* bit of the content?"* and *"what about conversation metadata?".* Everything extrapolates from the term *"end to end secure messenger"*, and I would be interested to hear examples of purportedly "end-to-end secure messengers" which don't already meet it. I would like to know why they do not? draft-knodel-e2ee-definition-00 is much broader could certainly be expanded > to include more precise definitions to illustrate the more abstract > notions. > And there's the rub; the point of this is to avoid abstract notions, because we need a concrete definition in order to judge what is meant by "end to end secure messenger" - not to mention to measure the features which some states propose be drilled into them. > Just having fixed set of precise criteria sounds nice in terms of > simplicity but might simply prove to be insufficient to capture all valid > use cases. > I welcome examples of use-cases where this definition falls short. Notably this definition *also* works for Ricochet which uses Tor Onions and point-to-point communication to provide end-to-end security, without even a hint of content encryption. It turns out that it is not always necessary to use content encryption (e.g. Signal Protocol) to implement a "closed distribution list" for a sequence of messages - which is all that "end to end security" is, in the most fundamental sense. The technologies have to adapt in order to address the underlying architecture: client-server, direct peer-to-peer, mesh, etc. In either case, having a document that can be used as a checklist to > determine with absolute certainty whether a system is end-to-end-encrypte= d > or not sound like a dangerous endeavour. > I would welcome examples of the dangers. > Given the complexity of the subject, the answer cannot always be binary. > Certainly it cannot *yet* be binary, for want of a metric to measure against. > When you say =E2=80=9Cill-defined, but widely used terminology=E2=80=9D, = what exactly are > you referring to? > "End"; I would be interested to hear what your definition of this term is, and so we might compare it to Section *4.1* and the explanatory note in Section *5*, Statements in the press? What exact problem needs fixing here? > The issue is that "end to end secure messenger" has no definition against which we can measure the features of a given software solution. This I-D offers one. And then, when the UK Government (or other) propose that "...adding a 'Ghost' will not break end-to-end security", we can precisely measure the impact of, and rebut, that statement. Having a bit more context on that would certainly help with the overall > assessment. Maybe we are just talking past each other. > I hope this helps. - alec --=20 https://alecmuffett.com/about --0000000000006907aa05c1bfd9d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Heya!

All references in the attache= d, are against:=C2=A0


...which shou= ld be constant even if the document is subsequently updated.

=

On Fri, 7 May 2= 021 at 15:50, Raphael Robert <ietf@raphaelrobert.com> wrote:
I agree that the two drafts a quite different. Yours is much more spe= cific in certain aspects. And this is where it also gets tricky :)
Dave has a good point that it might not be straight forward to have a =E2= =80=9Cone-size-fits-all=E2=80=9D model.=C2=A0
=
This is not a one-size-fits-all model of "security"= ;.=C2=A0 It's a definition of end-to-end secure messengers". =C2= =A0

It is a formalisation of the following argument:

1/ = in an "end-to-end secure messenger", there are "ends"; = this flows from the expression

= 2/ messages are sent from "ends", to "ends", and a s= equence of messages constitutes a "conversation" (obvious?)
3/ for each message, the set of &= quot;ends" is "frozen" upon "send" (3.3) to= the current & wholly visible set of conversation "ends" (= 3.2) ; if it were not frozen thusly we would lack forward secrecy and s= imply be reinventing Yahoo Messenger, which wasn't end-to-end secure, h= ence we can't be doing that

4/ no "end" may have privileged access to content, (3.1 - participating as an 'end' does not somehow bestow exceptional a= ccess to content, e.g by also being a database administrator)
5/ no "non-end" may have= any access to content (3.3.2)

6/ it requires the consent ("intentional action") of an= existing member, to add more "ends" to a conversation (3.4)=C2=A0

7/ the software should help ends understand where they are= logged-in (3.5)

That's it.=C2=A0 That's the whol= e specification, although it's padded with stuff like "indistingui= shability" to disambiguate questions like "what if we just lea= k a *little* bit of the content?" and "what about conversa= tion metadata?".=C2=A0

<= div class=3D"gmail_quote">Everything extrapolates from the term "en= d to end secure messenger", and I would be interested to hear exam= ples of purportedly "end-to-end secure messengers" which don'= t already meet it.=C2=A0 I would like to know why they do not?


draft-knodel-e2ee-definition-00 is much broade= r could certainly be expanded to include more precise definitions to illust= rate the more abstract notions.

And there's the rub; the point of this is to avoid abstract notions, = because we need a concrete definition in order to judge what is meant by &q= uot;end to end secure messenger" - not to mention to measure the featu= res which some states propose be drilled into them.

=C2=A0
Just having fixed set of precise criteria sou= nds nice in terms of simplicity but might simply prove to be insufficient t= o capture all valid use cases.

= I welcome examples of use-cases where this definition falls short.

Notably this definition also works for Ricochet whi= ch uses Tor Onions and point-to-point communication to provide end-to-end s= ecurity, without even a hint of content encryption. It turns out that it is= not always necessary to use content encryption (e.g. Signal Protocol) to i= mplement a "closed distribution list" for a sequence of messages = - which is all that "end to end security" is,=C2=A0in the most fu= ndamental sense.=C2=A0 The technologies have to adapt in order to address t= he underlying architecture: client-server, direct peer-to-peer, mesh, etc.<= /div>


In either case, having a do= cument that can be used as a checklist to determine with absolute certainty= whether a system is end-to-end-encrypted or not sound like a dangerous end= eavour.

I would welcome exampl= es of the dangers.

=C2=A0
=
Given= the complexity of the subject, the answer cannot always be binary.

Certainly it cannot yet be bina= ry, for want of a metric to measure against.

=C2= =A0
When you say =E2=80=9Cill-defined, but widely used= terminology=E2=80=9D, what exactly are you referring to?

"End"; I would be interested to hear = what your definition of this term is, and so we might compare it to Section= 4.1 and the explanatory note in Section 5,


Statements in the press? What exact problem n= eeds fixing here?

The issue is = that "end to end secure messenger" has no definition against whic= h we can measure the features of a given software solution.=C2=A0 This I-D = offers one.

And then, when the UK Government (or o= ther) propose that "...adding a 'Ghost' will not break end-to-= end security", we can precisely measure the impact of, and rebut, that= statement.


Having a bit m= ore context on that would certainly help with the overall assessment. Maybe= we are just talking past each other.

=
I hope this helps.

=C2=A0 =C2=A0 - alec=

--
--0000000000006907aa05c1bfd9d6-- From nobody Fri May 7 09:39:36 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 4B2853A294D; Fri, 7 May 2021 09:39:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162040556024.10515.18434867074453969330@ietfa.amsl.com> Date: Fri, 07 May 2021 09:39:20 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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: Fri, 07 May 2021 16:39:31 -0000 The Messaging Layer Security (mls) WG will hold a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 America/New_York (14:00 to 16:00 UTC). Agenda: GitHub issues and pull requests related to -protocol and -architecture. Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m0e7f495c200143a9f02b11d4d7dfa487 From nobody Fri May 7 10:34:51 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 3472D3A2B4B for ; Fri, 7 May 2021 10:34:50 -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=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 PsXshrhl36f0 for ; Fri, 7 May 2021 10:34:45 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 A194F3A2B51 for ; Fri, 7 May 2021 10:33:32 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id o27so9241152qkj.9 for ; Fri, 07 May 2021 10:33:32 -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:date:references :to:in-reply-to:message-id; bh=/PiRmVowPW5QavisvPv60ozWlXhd4QsX/QbliFuDSnA=; b=k+rlevBf3rmXyTzmb88ZjayZ82NQXq7JFFzYZg2mxR03mlUW+1gNR2E/k2V+QLxwBt 3wduTuI9y475sDxVgWnsEbEbdiGLw403gnnHrS7FQ/KwC1i1IGP46gpgU2WxNhrmleJv DBGn+s+TbmcZr0gFYLJkQAQTyCxf7XnvZe8dE= 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:date:references:to:in-reply-to:message-id; bh=/PiRmVowPW5QavisvPv60ozWlXhd4QsX/QbliFuDSnA=; b=oltz9xuq+hTJX9Obrmc1iGn6ACehGDi0vAKzzOVOIF7BWCrWRh/XD5V2BhlSYXbhbH bwNEimkgGXE72OSurUzA3SWGSVWPVztBqm330hF/RHklO7jmwRMAtWRJBHFD2VtF3/OY ynHxkZfbt3DYU7eKi/W2aTyGGHHTK+g9RHRwpb3+e4mdGFRLf1cXyVuyY8Gq7tqqweQO LT5TXfzZaY08rbMTnJDiXiOEMiPKMVdcIfxaARqtOBpJIfTXKeWFbX/nEu85dsM1Qy/r Y8iATwmih4Auf1Wfbu5tN6vd7OvSHSSdOpVIKbqm4oEOTHEbMojvCEzzCkiyr66LETD/ 7atA== X-Gm-Message-State: AOAM532rBQvociU5PC3FdBXLy8YW43LuOCjO2I8lUx/d376XwVuH+u+i RDm2zuwKi5/WNY/6umEhvY6JP3zJvgOD3Q== X-Google-Smtp-Source: ABdhPJyDxgsKu3clSU7+cNKFagduZJvzyDLk7OEE4bEH8XQnMTOidEI0vs2EdtbnpSD1pOgTn0heAA== X-Received: by 2002:a05:620a:1266:: with SMTP id b6mr10706553qkl.81.1620408810708; Fri, 07 May 2021 10:33:30 -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 q126sm5150731qkd.48.2021.05.07.10.33.29 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 10:33:30 -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.80.0.2.43\)) Date: Fri, 7 May 2021 13:33:29 -0400 References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> To: MLS List In-Reply-To: <162040556024.10515.18434867074453969330@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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, 07 May 2021 17:34:50 -0000 Meeting Scheduled! More information can also be found here: https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls spt > On May 7, 2021, at 12:39, IESG Secretary = wrote: >=20 > The Messaging Layer Security (mls) WG will hold > a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >=20 > Agenda: > GitHub issues and pull requests related to -protocol and = -architecture. >=20 > Information about remote participation: > = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Fri May 7 13:43:52 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 F40863A3242 for ; Fri, 7 May 2021 13:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 r1Zx9pbfKYf5 for ; Fri, 7 May 2021 13:43:44 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 46A2F3A323E for ; Fri, 7 May 2021 13:43:43 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id b25so15464723eju.5 for ; Fri, 07 May 2021 13:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q+JuqY7DoeXDliiSuJHpqvIgd3ds4cyruIOmbuB4f6o=; b=qi2si3e/HIo3fNcOLmk1HRI9KO4VI09hb5XYuqYFvs6rwr4PD+jM3rjZb1+BidGgWs HbbO/hyOno4iwuLlyjJSvb1nFDFsfbVLBrxcLFk4epRSF8d5xwQBgTUchM+bBGJZzbeW L/NvqJQrk5g6PlEAHIR89lkiqPMiQuMhYn0HY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q+JuqY7DoeXDliiSuJHpqvIgd3ds4cyruIOmbuB4f6o=; b=DLqml4TEG5WYrZT8yNfwd87P1CNvJOC0fQlyHu9EZh1B1sA/tunuYgCrGlG04TEd4l /ld5TltH2GYuMvRefG4rzlNnmLFb5dlmYNO2oC8n1TQIIWR9OtrOjcsJup9q+Yptsc5r pCH7Ci5Z0AZ2yyeIZckiU9pgi2sYwL1rbaHp8t59lneMhfgbpwcfa5/x2WCKBvZBxEQr iEqH+7h3KV9Ldg/G/aHymp7rQvEItKPbzaq/4RzYVeiddht1iHbggPN1o07Ka3yjJYzZ RS3YFPulxLNYxu3mFerczUFfq+m5yeHAk6MAhqMqe5f7qaPu3YP8cm8khLAnekwEavhj QwIQ== X-Gm-Message-State: AOAM531vfUCehtYjtNLQFWOdJe9POhfx3R5sojEYkqOlKOvsOKJ/YaLF I17sq+Epb+k45c66NR1ddPXZJA== X-Google-Smtp-Source: ABdhPJyvH7ycv7910vS7ccseZshOOj2h+TIn6ubbtizjyUOiWMR06ekAd4U/nTzYcl/nxQr1Znci9w== X-Received: by 2002:a17:906:29ce:: with SMTP id y14mr11966610eje.189.1620420221102; Fri, 07 May 2021 13:43:41 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id k5sm5650434edk.46.2021.05.07.13.43.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 13:43:40 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4F9B8EEA-7A31-4A65-B970-93852B4417F5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 22:43:39 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Alec Muffett References: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 20:43:50 -0000 --Apple-Mail=_4F9B8EEA-7A31-4A65-B970-93852B4417F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the additional context, it certainly helps! I definitely think it is worth attempting to capture the aspects of what = could constitute and end-to-end secure messaging system. I=E2=80=99m = only arguing about the details here, not the effort in general. I also = want to add that I can=E2=80=99t claim to be aware of all prior = literature on that subject, so I like the fact that = draft-knodel-e2ee-definition-01 cites a few sources. Regarding the definition of an =E2=80=9Cend=E2=80=9D, = draft-knodel-e2ee-definition-01 has section 2.1, 4.3 & 4.5. Your draft = has section 4.1 & 5. In my mind both drafts could be a bit more = assertive here. I like that you introduce different types of = participants. I think that point is particularly important, because if = the participants are not just =E2=80=9Chumans with a messenger app=E2=80=9D= , it begs the question who has control over the messages that were = received by that participant. Other humans who are not part of the = =E2=80=9Cconversation=E2=80=9D? Future participants of the = =E2=80=9Cconversation=E2=80=9D? A machine that will scan the message = content and act on it? In the end this defines what = =E2=80=9Cconfidentiality=E2=80=9D really means, besides the academic = definition. To be more precise, I would add to the definition of participants, that = all participants must know exactly the type of other participants. It = matters whether participant Eve is a bot or a human. This would be an = actionable definition in order to refute that a system with ghost user = is still e2e secure. If a participant lies about the kind of participant = they are, this would constitute a breach and contradict the end user = expectations. > On 7. May 2021, at 18:22, Alec Muffett wrote: >=20 > Heya! >=20 > All references in the attached, are against:=20 >=20 > URL: = https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/b= lob/157627c713f81a27c9528c87b6e58111ba54e485/text/draft-muffett-end-to-end= -secure-messaging.txt = >=20 > ...which should be constant even if the document is subsequently = updated. >=20 >=20 > On Fri, 7 May 2021 at 15:50, Raphael Robert > wrote: >=20 > I agree that the two drafts a quite different. Yours is much more = specific in certain aspects. And this is where it also gets tricky :) > Dave has a good point that it might not be straight forward to have a = =E2=80=9Cone-size-fits-all=E2=80=9D model.=20 >=20 > This is not a one-size-fits-all model of "security". It's a = definition of end-to-end secure messengers". =20 >=20 > It is a formalisation of the following argument: >=20 > 1/ in an "end-to-end secure messenger", there are "ends"; this flows = from the expression >=20 > 2/ messages are sent from "ends", to "ends", and a sequence of = messages constitutes a "conversation" (obvious?) >=20 > 3/ for each message, the set of "ends" is "frozen" upon "send" (3.3) = to the current & wholly visible set of conversation "ends" (3.2) ; if it = were not frozen thusly we would lack forward secrecy and simply be = reinventing Yahoo Messenger, which wasn't end-to-end secure, hence we = can't be doing that >=20 > 4/ no "end" may have privileged access to content, (3.1 - = participating as an 'end' does not somehow bestow exceptional access to = content, e.g by also being a database administrator) >=20 > 5/ no "non-end" may have any access to content (3.3.2) >=20 > 6/ it requires the consent ("intentional action") of an existing = member, to add more "ends" to a conversation (3.4)=20 >=20 > 7/ the software should help ends understand where they are logged-in = (3.5) >=20 > That's it. That's the whole specification, although it's padded with = stuff like "indistinguishability" to disambiguate questions like "what = if we just leak a *little* bit of the content?" and "what about = conversation metadata?".=20 >=20 > Everything extrapolates from the term "end to end secure messenger", = and I would be interested to hear examples of purportedly "end-to-end = secure messengers" which don't already meet it. I would like to know = why they do not? I think what both drafts don=E2=80=99t fully cover yet is the fact that = end users have expectations. For me everything extrapolates from the = =E2=80=9Cset of typical end user expectations=E2=80=9D. The software and = its documentation should make it as clear as possible to the user how = the system works, who can potentially have access to messages (e.g. a LE = ghost user, a recording bot, only other humans that can be transparently = authenticated out-of-band). >=20 >=20 > draft-knodel-e2ee-definition-00 is much broader could certainly be = expanded to include more precise definitions to illustrate the more = abstract notions. >=20 > And there's the rub; the point of this is to avoid abstract notions, = because we need a concrete definition in order to judge what is meant by = "end to end secure messenger" - not to mention to measure the features = which some states propose be drilled into them. >=20 > =20 > Just having fixed set of precise criteria sounds nice in terms of = simplicity but might simply prove to be insufficient to capture all = valid use cases. >=20 > I welcome examples of use-cases where this definition falls short. I don=E2=80=99t have a good counter-example at hand, but that doesn=E2=80=99= t mean it doesn=E2=80=99t exist. I guess it would be great if we had = links to existing literature, or comparative analysis of past and = current e2e secure systems to corroborate the idea. >=20 > Notably this definition also works for Ricochet which uses Tor Onions = and point-to-point communication to provide end-to-end security, without = even a hint of content encryption. It turns out that it is not always = necessary to use content encryption (e.g. Signal Protocol) to implement = a "closed distribution list" for a sequence of messages - which is all = that "end to end security" is, in the most fundamental sense. The = technologies have to adapt in order to address the underlying = architecture: client-server, direct peer-to-peer, mesh, etc. >=20 >=20 > In either case, having a document that can be used as a checklist to = determine with absolute certainty whether a system is = end-to-end-encrypted or not sound like a dangerous endeavour. >=20 > I would welcome examples of the dangers. In a way this is what Dave pointed out earlier. There could be both = false positives and false negatives. False positive: A system that works in a way that doesn=E2=80=99t = contradict the definitions of the draft, but that contradicts the = typical end user expectations. False negative: A system that contradicts one or more definitions of the = draft (most likely because they are too restrictive) but still meets the = typical end user expectations. False positives are downright dangerous for end users, while false = negatives might hinder the adoption of an otherwise great system. > =20 > Given the complexity of the subject, the answer cannot always be = binary. >=20 > Certainly it cannot yet be binary, for want of a metric to measure = against. My hunch here is that either draft could evolve into something that =E2=80= =94 when used as benchmark =E2=80=94 gives a high degree of confidence = whether a system is e2e secure or not. In a way it would be like a legal document: it tries to be as precise as = possible, but there might still be the need for interpretation by = experts in the field (including the possibility of disagreement). > =20 > When you say =E2=80=9Cill-defined, but widely used terminology=E2=80=9D,= what exactly are you referring to? >=20 > "End"; I would be interested to hear what your definition of this term = is, and so we might compare it to Section 4.1 and the explanatory note = in Section 5, >=20 >=20 > Statements in the press? What exact problem needs fixing here? >=20 > The issue is that "end to end secure messenger" has no definition = against which we can measure the features of a given software solution. = This I-D offers one. >=20 > And then, when the UK Government (or other) propose that "...adding a = 'Ghost' will not break end-to-end security", we can precisely measure = the impact of, and rebut, that statement. I understand you want something actionable with punchy definitions and I = agree that it would be a useful thing to have. For it to become that, it = needs consensus from the wider community. Not only because that=E2=80=99s = the idea behind IETF, but also because it carries more weight in the = end. With that in mind, it would be great if some more folks would chime = in so that this is not only two party conversation with only two = opinions. What I=E2=80=99m also not sure about is whether the two drafts will be = sufficiently different in the end, in the sense that they would cater to = different audiences. They are de facto different now, but maybe it would = be worth trying to bring them together? I am an author of neither, so I = can really only float the idea. Another aspect that is at least partially covered in = draft-knodel-e2ee-definition-01 is that of authentication. I think this = plays a big role when it comes to =E2=80=9Cghost users=E2=80=9D and = transparency of participants. It=E2=80=99s also something that is still = very much an area of exploration for secure messengers. There is room = for improvement across the board and in that sense the drafts could = serve as a guideline for existing and future messengers. Lastly I also would like to mention the MLS architecture draft = (https://tools.ietf.org/html/draft-ietf-mls-architecture-06 = ) that = touches on a lot of these subjects. While its purpose is a different = one, it goes strictly beyond the scope of MLS and highlights aspects = that are relevant for many secure messaging systems. I hope the above makes it a bit more clear what I maybe failed to = express earlier. Raphael >=20 >=20 > Having a bit more context on that would certainly help with the = overall assessment. Maybe we are just talking past each other. >=20 > I hope this helps. >=20 > - alec >=20 > --=20 > https://alecmuffett.com/about >=20 --Apple-Mail=_4F9B8EEA-7A31-4A65-B970-93852B4417F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the additional context, it certainly helps!

I definitely think it is = worth attempting to capture the aspects of what could constitute and = end-to-end secure messaging system. I=E2=80=99m only arguing about the = details here, not the effort in general. I also want to add that I = can=E2=80=99t claim to be aware of all prior literature on that subject, = so I like the fact that draft-knodel-e2ee-definition-01 cites a few = sources.

Regarding the definition of an =E2=80=9Cend=E2=80=9D, = draft-knodel-e2ee-definition-01 has section 2.1, 4.3 & 4.5. Your = draft has section 4.1 & 5. In my mind both drafts could be a bit = more assertive here. I like that you introduce different types of = participants. I think that point is particularly important, because if = the participants are not just =E2=80=9Chumans with a messenger app=E2=80=9D= , it begs the question who has control over the messages that were = received by that participant. Other humans who are not part of the = =E2=80=9Cconversation=E2=80=9D? Future participants of the = =E2=80=9Cconversation=E2=80=9D? A machine that will scan the message = content and act on it? In the end this defines what = =E2=80=9Cconfidentiality=E2=80=9D really means, besides the academic = definition.
To be more precise, I would add to the = definition of participants, that all participants must know exactly the = type of other participants. It matters whether participant Eve is a bot = or a human. This would be an actionable definition in order to refute = that a system with ghost user is still e2e secure. If a participant lies = about the kind of participant they are, this would constitute a breach = and contradict the end user expectations.

On 7. = May 2021, at 18:22, Alec Muffett <alec.muffett@gmail.com> wrote:

Heya!

All references in the attached, are against: 


...which should be = constant even if the document is subsequently updated.


On Fri, 7 = May 2021 at 15:50, Raphael Robert <ietf@raphaelrobert.com> wrote:
I agree that the two drafts a quite = different. Yours is much more specific in certain aspects. And this is = where it also gets tricky :)
Dave has a good point = that it might not be straight forward to have a =E2=80=9Cone-size-fits-all= =E2=80=9D model. 

This is not a one-size-fits-all model = of "security".  It's a definition of end-to-end secure messengers". =  

It is a formalisation of the following = argument:

1/ in an = "end-to-end secure messenger", there are "ends"; this flows from the = expression

2/ messages are sent from "ends", to = "ends", and a sequence of messages constitutes a "conversation" = (obvious?)

3/ for each message, the set of = "ends" is "frozen" upon "send" (3.3) to the current = & wholly visible set of conversation "ends" (3.2) = ; if it were not frozen thusly we would lack forward secrecy and simply = be reinventing Yahoo Messenger, which wasn't end-to-end secure, hence we = can't be doing that

4/ no "end" may have privileged = access to content, (3.1 - participating as an 'end' = does not somehow bestow exceptional access to content, e.g by also being a database administrator)

5/ no = "non-end" may have any access to content (3.3.2)

6/ it requires the consent ("intentional action") of an = existing member, to add more "ends" to a conversation (3.4

7/ the software should help ends understand where they are = logged-in (3.5)

That's = it.  That's the whole specification, although it's padded with = stuff like "indistinguishability" to disambiguate questions like "what if we just leak a *little* bit of the content?" and = "what about conversation metadata?". 

Everything extrapolates from the term "end to end secure messenger", and I would be interested = to hear examples of purportedly "end-to-end secure messengers" which = don't already meet it.  I would like to know why they do = not?

I think what both drafts don=E2=80=99t fully cover yet = is the fact that end users have expectations. For me everything = extrapolates from the =E2=80=9Cset of typical end user expectations=E2=80=9D= . The software and its documentation should make it as clear as possible = to the user how the system works, who can potentially have access to = messages (e.g. a LE ghost user, a recording bot, only other humans that = can be transparently authenticated out-of-band).



draft-knodel-e2ee-definition-00 is much = broader could certainly be expanded to include more precise definitions = to illustrate the more abstract notions.

And there's the rub; the = point of this is to avoid abstract notions, because we need a concrete = definition in order to judge what is meant by "end to end secure = messenger" - not to mention to measure the features which some states = propose be drilled into them.

 
Just having fixed set of precise criteria = sounds nice in terms of simplicity but might simply prove to be = insufficient to capture all valid use = cases.

I welcome examples of use-cases where this definition falls = short.
I don=E2=80=99t have a good counter-example at = hand, but that doesn=E2=80=99t mean it doesn=E2=80=99t exist. I guess it = would be great if we had links to existing literature, or comparative = analysis of past and current e2e secure systems to corroborate the = idea.


Notably this definition also works for Ricochet which uses Tor Onions and = point-to-point communication to provide end-to-end security, without = even a hint of content encryption. It turns out that it is not always = necessary to use content encryption (e.g. Signal Protocol) to implement = a "closed distribution list" for a sequence of messages - which is all = that "end to end security" is, in the most fundamental sense.  = The technologies have to adapt in order to address the underlying = architecture: client-server, direct peer-to-peer, mesh, etc.


In either case, having a document that can be = used as a checklist to determine with absolute certainty whether a = system is end-to-end-encrypted or not sound like a dangerous endeavour. =

I would welcome examples of the = dangers.
=
In a way this is what Dave pointed out = earlier. There could be both false positives and false = negatives.

False positive: A system = that works in a way that doesn=E2=80=99t contradict the definitions of = the draft, but that contradicts the typical end user = expectations.

False negative: A = system that contradicts one or more definitions of the draft (most = likely because they are too restrictive) but still meets the typical end = user expectations.

False positives = are downright dangerous for end users, while false negatives might = hinder the adoption of an otherwise great system.

 
Given the complexity of the subject, the = answer cannot always be binary.

Certainly it cannot yet be binary, for want of a metric to measure = against.
=
My hunch here is that either draft could evolve = into something that =E2=80=94 when used as benchmark =E2=80=94 gives a = high degree of confidence whether a system is e2e secure or = not.
In a way it would be like a legal document: it tries to = be as precise as possible, but there might still be the need for = interpretation by experts in the field (including the possibility of = disagreement).

 
When you say =E2=80=9Cill-defined, but widely = used terminology=E2=80=9D, what exactly are you referring to? =

"End"; I would be interested to hear what your definition of = this term is, and so we might compare it to Section 4.1 = and the explanatory note in Section 5,


Statements in the press? What exact problem = needs fixing here?

The issue is that "end to end secure = messenger" has no definition against which we can measure the features = of a given software solution.  This I-D offers one.

And then, when the UK = Government (or other) propose that "...adding a 'Ghost' will not break = end-to-end security", we can precisely measure the impact of, and rebut, = that = statement.

I understand you want something actionable = with punchy definitions and I agree that it would be a useful thing to = have. For it to become that, it needs consensus from the wider = community. Not only because that=E2=80=99s the idea behind IETF, but = also because it carries more weight in the end. With that in mind, it = would be great if some more folks would chime in so that this is not = only two party conversation with only two opinions.
What I=E2=80= =99m also not sure about is whether the two drafts will be sufficiently = different in the end, in the sense that they would cater to different = audiences. They are de facto different now, but maybe it would be worth = trying to bring them together? I am an author of neither, so I can = really only float the idea.

Another = aspect that is at least partially covered in draft-knodel-e2ee-definition-01 is that of authentication. I = think this plays a big role when it comes to =E2=80=9Cghost = users=E2=80=9D and transparency of participants. It=E2=80=99s also = something that is still very much an area of exploration for secure = messengers. There is room for improvement across the board and in that = sense the drafts could serve as a guideline for existing and future = messengers.

Lastly I = also would like to mention the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-architecture-06)= that touches on a lot of these subjects. While its purpose is a = different one, it goes strictly beyond the scope of MLS and highlights = aspects that are relevant for many secure messaging = systems.

I hope the = above makes it a bit more clear what I maybe failed to express = earlier.

Raphael



Having a bit more context on that would = certainly help with the overall assessment. Maybe we are just talking = past each other.

I hope this = helps.

  =   - alec

--
=

= --Apple-Mail=_4F9B8EEA-7A31-4A65-B970-93852B4417F5-- From nobody Fri May 7 14:06:20 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 AABB53A32FD for ; Fri, 7 May 2021 14:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 xfYy84fO36Ts for ; Fri, 7 May 2021 14:06:13 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 14E453A32F6 for ; Fri, 7 May 2021 14:06:12 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id n2so15553333ejy.7 for ; Fri, 07 May 2021 14:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=we2npicSKMnhoQ6BUQufVgTWojlTUqzV5oJcXmRO+Ws=; b=ClL+1impK0syLURDrAxQZk24T5ShAp3Su2jfVMfHfyiM0rt0WfGRacZL877oo0Y0uX kLLzZwijAqL+FGEXaZKP3fAlPZ4pgn9R9lDBDmRmsQvM/FpLRvfdpuoHFqZsLyyIuEZb Bu4r8tstS/pjjuY+BruhWTSvH6blkWGRm8xOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=we2npicSKMnhoQ6BUQufVgTWojlTUqzV5oJcXmRO+Ws=; b=GEInXt7DvIkXcRx+VxBGntnPa0M8AF5OjlWlQTGBnGKZk4E1LKfKjaSMH+8qEpKwf9 Kw6lJs59Pxp19Zjf871ICIitB8O8SnOz4Bs3DRi0kwr2fhTwOs7LW+7zAtpIUuE7RIXX ap04fmCgFBrJ7qOO/pp4Kza9FjfalzT5XkVVEfEqPj3zl26J6N4Ec8YY45KklOCxQzd/ wsqBilHh9Wcct4T4J25QbHCH5A6XNXWHR+T+YlLkNXpt8L+jXbiHuFOZYSAJMRqKEe5N T1lNRm1jZ9+JkDVN9T0xCV1JbAtBawanMCa+lo19wu6xKtqSGreCUdgqXA84ky1aWihz zpdA== X-Gm-Message-State: AOAM532s2keOxYXTQT88bFsR0qmaJ1cTZzdSx7rn/y5/m3EUwfIipOoV gLsiPOCTQKsWfOEEvZyq0m5JAohc97IjaISBcog= X-Google-Smtp-Source: ABdhPJwx5GmjaI7QDdHI2eJs63hr1X8JeTyytVpMEYwYTuLnrOHzB5TeHhppBtFZIEp7UaLrakNSpw== X-Received: by 2002:a17:906:1d4c:: with SMTP id o12mr12176505ejh.203.1620421570067; Fri, 07 May 2021 14:06:10 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id z4sm4122277ejw.54.2021.05.07.14.06.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 14:06:09 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_FCBAA723-468E-4EDE-B0E2-B5A8990D1EC4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 7 May 2021 23:06:08 +0200 In-Reply-To: <818a638a-a687-5fb2-0f93-9654f4a1d9e9@cdt.org> Cc: Messaging Layer Security WG To: Mallory Knodel References: <162039893366.31953.3182470506238059389@ietfa.amsl.com> <818a638a-a687-5fb2-0f93-9654f4a1d9e9@cdt.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] New Version Notification for draft-knodel-e2ee-definition-01.txt 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, 07 May 2021 21:06:19 -0000 --Apple-Mail=_FCBAA723-468E-4EDE-B0E2-B5A8990D1EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for sharing Mallory! I like that it has a wholistic approach and that it is based on prior = research. I need to think a bit more about it in general, what comes to mind right = now in no particular order: - What are the possible synergies between your draft and the MLS = architecture draft = (https://tools.ietf.org/html/draft-ietf-mls-architecture-06 = )? - Topics that could possibly be expanded: authentication, metadata = (e.g. persisted metadata vs. observable metadata) - End user expectations: As mentioned for Alec=E2=80=99s draft as well, = I think end user expectations are the center piece. Bridging the gap = between academic definitions and the UX of secure messengers would = provide some real value in my mind. In essence, it=E2=80=99s great to have this draft and it is relevant for = MLS in my mind. Thanks again for sharing! Raphael > On 7. May 2021, at 16:59, Mallory Knodel wrote: >=20 > Hi all, >=20 > There's been oblique discussion of this draft, thanks to Alec's = citation in his recent effort. >=20 > My co-authors and I thought we should go ahead and share a -01 version = with the group. Most of our feedback so far has been around better = definition of an end, so we broke that into its own sub-section. >=20 > The goal is to clearly define e2ee in three different ways: = constituent formal definition, functionalities, and user expectations. = This assumes a technology is defined by its properties. Conversely, we = are not trying to define properties by the technology in use, eg "this = app is secure because it's e2ee", which is totally valid. But without = our effort, it's becomes circular. >=20 > Lastly I'll just mention that while we aim to define e2ee, we also end = up defining a few other terms as well. It's perhaps worth considering = this a terminology draft for the mls working group, as Raphael just = suggested. We are certainly open to that, so please help us by opening = issues or sending pull requests to help solidify those terms: = https://github.com/mallory/e2ee/edit/main/draft-e2ee.md = . >=20 > Any and all reviews welcome, >=20 > -Mallory >=20 >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-knodel-e2ee-definition-01.txt > Date: Fri, 07 May 2021 07:48:53 -0700 > From: internet-drafts@ietf.org > To: Sof=C3=ADa Celi = , Fred Baker = , Fred Baker = , Gurshabad = Grover , = Mallory Knodel , Olaf Kolkman = , Sofia Celi = >=20 >=20 > A new version of I-D, draft-knodel-e2ee-definition-01.txt > has been successfully submitted by Mallory Knodel and posted to the > IETF repository. >=20 > Name: draft-knodel-e2ee-definition > Revision: 01 > Title: Definition of End-to-end Encryption > Document date: 2021-05-07 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt = > Status: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/ = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition = > Htmlized: https://tools.ietf.org/html/draft-knodel-e2ee-definition-01 = > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-knodel-e2ee-definition-01 = >=20 > Abstract: > End-to-end encryption (E2EE) is an application of cryptography in > communications systems between endpoints. E2EE systems are unique in > providing features of confidentiality, integrity and authenticity for > users. Improvements to E2EE strive to maximise the system's security > while balancing usability and availability. Users of E2EE > communications expect trustworthy providers of secure implementations > to respect and protect their right to whisper. >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_FCBAA723-468E-4EDE-B0E2-B5A8990D1EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for sharing Mallory!

I like that it has a wholistic approach = and that it is based on prior research.
I need to = think a bit more about it in general, what comes to mind right now in no = particular order:

 - What are the possible synergies between your draft = and the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-architecture-06)= ?
 - Topics that could possibly be expanded: = authentication, metadata (e.g. persisted metadata vs. observable = metadata)
 - End user expectations: As = mentioned for Alec=E2=80=99s draft as well, I think end user = expectations are the center piece. Bridging the gap between academic = definitions and the UX of secure messengers would provide some real = value in my mind.

In essence, it=E2=80=99s great to have this draft and it is = relevant for MLS in my mind. Thanks again for sharing!

Raphael

On 7. May 2021, at 16:59, Mallory Knodel <mknodel@cdt.org> = wrote:

=20 =20

Hi all,

There's been = oblique discussion of this draft, thanks to Alec's citation in his recent effort.

My co-authors and = I thought we should go ahead and share a -01 version with the group. Most of our feedback so far has been around better definition of an end, so we broke that into its own sub-section.

The goal is to clearly define e2ee = in three different ways: constituent formal definition, functionalities, and user expectations. This assumes a technology is defined by its properties. Conversely, we are not trying to define properties by the technology in use, eg "this app is secure because it's e2ee", which is totally valid. But without our effort, it's becomes circular.

Lastly I'll just mention that while we = aim to define e2ee, we also end up defining a few other terms as well. It's perhaps worth considering this a terminology draft for the mls working group, as Raphael just suggested. We are certainly open to that, so please help us by opening issues or sending pull requests to help solidify those terms: https://g= ithub.com/mallory/e2ee/edit/main/draft-e2ee.md.

Any and all reviews welcome,

-Mallory



-------- Forwarded Message -------- = =
Subject: New Version Notification for draft-knodel-e2ee-definition-01.txt
Date: Fri, 07 May 2021 07:48:53 -0700
From: internet-drafts@ietf.org
To: Sof=C3=ADa Celi <cherenkov@riseup.net>, = Fred Baker <fredbaker.IETF@gmail.com><= /a>, Fred Baker <fredbaker.ietf@gmail.com><= /a>, Gurshabad Grover <gurshabad@cis-india.org>, Mallory Knodel <mknodel@cdt.org>, Olaf = Kolkman <kolkman@isoc.org>, Sofia = Celi <cherenkov@riseup.net>



A new version of I-D, draft-knodel-e2ee-definition-01.txt
has been successfully submitted by Mallory Knodel and posted to the
IETF repository.

Name: draft-knodel-e2ee-definition
Revision: 01
Title: Definition of End-to-end Encryption
Document date: 2021-05-07
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt=
Status: ht= tps://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
Htmlized: https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition Htmlized: https= ://tools.ietf.org/html/draft-knodel-e2ee-definition-01
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-knodel-e2ee-definition-01=

Abstract:
End-to-end encryption (E2EE) is an application of cryptography = in
communications systems between endpoints. E2EE systems are unique in
providing features of confidentiality, integrity and authenticity for
users. Improvements to E2EE strive to maximise the system's security
while balancing usability and availability. Users of E2EE
communications expect trustworthy providers of secure implementations
to respect and protect their right to whisper.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_FCBAA723-468E-4EDE-B0E2-B5A8990D1EC4-- From nobody Fri May 7 14:39:45 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 88CDF3A3298 for ; Fri, 7 May 2021 14:39:43 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 X_GUDwvs7lQR for ; Fri, 7 May 2021 14:39:38 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 1E75F3A3293 for ; Fri, 7 May 2021 14:39:38 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id z1so5560009qvo.4 for ; Fri, 07 May 2021 14:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fd3H18WAVQ9Wk5Q0mYo/ARQVv1syKX+Yw5KuZL7RmP8=; b=lTvzX1dU95v2YqZ3m9Midvfe1ZgkHXDy2C8090owZmTKIEnLUhHU/YHrmSZqeze9P2 S0sPoxPpQQqqgbsZqXubwrDetLukVl9goSqPMpUbdGGQa9lLgJD8pgMsKy973ID5k7xd XnftHt9HtjqZxZzbwONrJQ0t5WDrRXyYgRieR0kEfQ680Cuo60OR2eyBaEZn/LZh5zbe /D9+rzhsZdboNoxaSwtm5Y1TFgfAhwMhdvKQrggYwjA2Ssb9HNx5bG4LqT21J5viHC7C QPmfIwSdbS/YdPi/1LRNW3zOea2LaquXIb4XBVnZ9aKhEyTv1KVNYkfi5BhDLGuafSyO 7+Ww== 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=fd3H18WAVQ9Wk5Q0mYo/ARQVv1syKX+Yw5KuZL7RmP8=; b=GXT8uk9eE0fGkxUAq0Sros9c5SoqnhkqHNVJqi0S1DyqARccAHG1hBg3G8Be44sD2E eoEPkwBvK8GfLeHgMz6arF4DYXo80iKzRk0V2PiEiRDtVuypHYWaTE/MU9r3JFz0NTlk 0PclOay2yoNTvRSrV1HV/ozuCgyOGYCspnE4fkq/m4U48LXquhxr8f74+AxQXcYM3cH8 mq0dG+SMkSQfx5cj8LqJ8l8qk+jNkV+FY/0EWdtU0i8nyq7JYMFheLTQ8ffeWZUPunwq aAuuhqj0iSXhMcB9uTBaL7bnXkzueixMv5MZ7+94oKd5+rXi0JYDJXmuBtIRgkl7+/IA IyQA== X-Gm-Message-State: AOAM531MdhFi1UDrAc+8p1PRnvnRURyuaasyv68jJ+6+iEcFbxUez0IP W4tK8y7ALbjuq+15+T6GuZAdAOvTg3NtvPaKxwn+6L49gANNBg== X-Google-Smtp-Source: ABdhPJzupLCRssxwIAMnIOx6nOlvynSGeDdSvfpeBCvFdRPIWlHQJ0y7Hu7uYHW35LOXix11RZR6Nw+faXkUebXUCu4= X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr11958535qve.27.1620423576320; Fri, 07 May 2021 14:39:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Fri, 7 May 2021 22:38:59 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000a6fcd305c1c443f3" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 07 May 2021 21:39:44 -0000 --000000000000a6fcd305c1c443f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 7 May 2021 at 21:43, Raphael Robert wrote: > Thanks for the additional context, it certainly helps! > I'm glad! I want to see this - or something better than it - succeed at providing a measuring stick for what constitutes an end-to-end secure messenger, be it one that uses client-server architectures with data at rest on a central server; or one that uses secure point to point networking, or even mesh-networking like Briar. The fundamental realisation was that "end-to-end" is basically synonymous with "closed distribution list with no 'blind' membership"; then it's simply a matter of describing that. I definitely think it is worth attempting to capture the aspects of what > could constitute and end-to-end secure messaging system. I=E2=80=99m only= arguing > about the details here, not the effort in general. I also want to add tha= t > I can=E2=80=99t claim to be aware of all prior literature on that subject= , so I > like the fact that draft-knodel-e2ee-definition-01 cites a few sources. > I have a few sources, too, but the summary in my previous email appears obvious to me; once one stops looking at "E2EE" and starts looking at the generic pattern of "E2ESM", it seems to just flow from the description. [...] I like that you introduce different types of participants. I think > that point is particularly important, because if the participants are not > just =E2=80=9Chumans with a messenger app=E2=80=9D, it begs the question = who has control > over the messages that were received by that participant. > [...] > To be more precise, I would add to the definition of participants, that > all participants must know exactly the type of other participants. > I take your point; I did actually consider that for a while - there would be benefits to being better informed about the other "participants" - but eventually I rejected the proposition as being intrusive and impractical to mandate/require, although there's certainly opportunities for some platforms (?) to offer such information if they choose. To explain: I don't really "introduce different types of participants'', instead I merely "allow" that they exist; it is fine for one participant to be a human being, another to be an autoresponse bot, and the third to be a conversation-archiver. The important point is that none of them are "invisible" to other participants as would be the case with a "ghost", nor may there be a "ghost outside the machine" accessing content (PCASM) by means of a back door. However the participants MUST be able to see each other, and... from that, how far should we go in terms of visibility? Should "Signal" be required to disclose to the other participants in a conversation that I use both my Phone AND ALSO that I use Signal Desktop on two separate devices? Should WhatsApp be required to highlight when I am using WhatsAppForWeb in a browser, rather than my primary device? I decided that these questions are beyond the scope of defining End-to-End Secure Messaging, not least because they are heavily platform specific - for Signal the entity is represented by a cryptographic key with several devices, whereas WhatsApp uses a on-phone identity and (roughly) all other WhatsAp "clients" call back to the phone for session keys. > It matters whether participant Eve is a bot or a human. > It does... and it does not, because to pursue that goal requires us also to get into (say) WhatsApp-For-Business with Bot-Augmented-Human-Clusters, etc. This is why... > This would be an actionable definition in order to refute that a system > with ghost user is still e2e secure. > ...this is why the standard is written: 1/ To see plaintext content, the viewer must be a participant (for a given message) 2/ Participants (at the time of composition) must all see each other, so they know who could see their message(s) 3/ Anyone who is not a participant, MUST not see plaintext content This kills "Ghosts" because they cannot be invisible, and they cannot access plaintext from outside of the conversation "walls". The question of whether the visible user "User:XenaWarierPrinces" is a human, bot, or some kind of bot-human hybrid, is a social question, and best left to the platform. > If a participant lies about the kind of participant they are, this would > constitute a breach and contradict the end user expectations. > That strikes me as a matter for a per-user Acceptable Use Policy, and - being a matter of intent - rests outside the scope of defining howan End-to-End Secure Messenger should behave. A little higher-up you observed: Regarding the definition of an =E2=80=9Cend=E2=80=9D ... In my mind both dr= afts could be a > bit more assertive here I feel my definition is sharp. and clear, because I leverage "Trusted Compute Base" as a concept. This is a bit of a punt, but it flows directly back to my question "Should WhatsApp be required to highlight when I am using WhatsAppForWeb?" - because if it were obligatory for a platform to surface that I *do* use WhatsAppForWeb, perhaps it should also surface what browser I am using, and at what patch level? So: for the purposes of having a viable standard, it is necessary to accept that all participants - human, bot, spook, recorder, malicious, kind - are equal participants, and that the bounds of their usage is defined by what *THEY* consider to be "secure". To not accept this would put us in the realms of "Ranum's Law", viz: that this is a social problem and you can't solve social problems in software. I think what both drafts don=E2=80=99t fully cover yet is the fact that end= users > have expectations. For me everything extrapolates from the =E2=80=9Cset o= f typical > end user expectations=E2=80=9D. The software and its documentation should= make it > as clear as possible to the user how the system works, who can potentiall= y > have access to messages (e.g. a LE ghost user, a recording bot, only othe= r > humans that can be transparently authenticated out-of-band). I am delighted for users to have expectations, and I look forward to learning how their expectations negatively impact this standard other than in terms of omission that is arguably not better dealt with at a non-RFC, platform-differentiation level. There could be both false positives and false negatives. > False positive: A system that works in a way that doesn=E2=80=99t contrad= ict the > definitions of the draft, but that contradicts the typical end user > expectations. > False negative: A system that contradicts one or more definitions of the > draft (most likely because they are too restrictive) but still meets the > typical end user expectations. > False positives are downright dangerous for end users, while false > negatives might hinder the adoption of an otherwise great system. I look forward to concrete examples, and will work to adapt the specification to fit them where it makes sense. I understand you want something actionable with punchy definitions and I > agree that it would be a useful thing to have. For it to become that, it > needs consensus from the wider community. I wish to share these perspectives with the wider community, in order to pursue consensus. That is why I am investing this effort. Not only because that=E2=80=99s the idea behind IETF, but also because it c= arries > more weight in the end. With that in mind, it would be great if some more > folks would chime in so that this is not only two party conversation with > only two opinions. I would be delighted to hear and address perspectives from others. What I=E2=80=99m also not sure about is whether the two drafts will be suff= iciently > different in the end, in the sense that they would cater to different > audiences. We shall certainly see; at the moment I am a househusband with plenty of spare time to dedicate to this effort, so I have ample resource to dedicate towards building a consensus definition. Another aspect that is at least partially covered in draft-knodel-e2ee-definition-01 > is that of authentication. That is an interesting concept: whether the entity can somehow be linked to an external identity namespace; as we see from arguments about Signal's use of "phone numbers" as an identity principal - and that some people detest their doing so - it's not a required feature of End-to-End Secure Messengers, and so will not appear in this specification. I think this plays a big role when it comes to =E2=80=9Cghost users=E2=80= =9D and > transparency of participants. This is really interesting; I am getting the sense that you are strongly drawn to the notion of "real" or "genuine identity" being part of an end-to-end secure messenger solution. Would that be correct? Lastly I also would like to mention the MLS architecture draft ( > https://tools.ietf.org/html/draft-ietf-mls-architecture-06) that touches > on a lot of these subjects. Indeed, I think that you and I last met at a MLS shindig hosted at Facebook some years ago :-) > While its purpose is a different one, it goes strictly beyond the scope o= f > MLS and highlights aspects that are relevant for many secure messaging > systems. I hope the above makes it a bit more clear what I maybe failed to express > earlier. It is really interesting, and I am grateful for the pushback and the opportunity / spark to explain. :-) - Alec https://alecmuffett.com/about --000000000000a6fcd305c1c443f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 7 May 2021 at 21:43= , Raphael Robert <ietf@raphael= robert.com> wrote:
Thanks for the additional contex= t, it certainly helps!

I'm glad! = I want to see this - or something better than it - succeed at providing=C2= =A0a measuring stick for what constitutes an end-to-end secure messenger, b= e it one that uses client-server architectures with data at rest on a centr= al server; or one that uses secure point to point networking, or even mesh-= networking like Briar.
=C2=A0
The fundamental realisati= on was that "end-to-end" is basically synonymous with "close= d distribution list with no 'blind' membership"; then it's= simply a matter of describing that.


I definitely think it is worth attempting to capture the aspects o= f what could constitute and end-to-end secure messaging system. I=E2=80=99m= only arguing about the details here, not the effort in general. I also wan= t to add that I can=E2=80=99t claim to be aware of all prior literature on = that subject, so I like the fact that=C2=A0draft-knodel-e2ee-definition-01 = cites a few sources.

I have= a few sources, too, but the summary in my previous email appears obvious t= o me; once one stops looking at "E2EE" and starts looking at the = generic pattern of "E2ESM", it seems to just flow from the descri= ption.
=C2=A0

[...] I = like that you introduce different types of participants. I think that point= is particularly important, because if the participants are not just =E2=80= =9Chumans with a messenger app=E2=80=9D, it begs the question who has contr= ol over the messages that were received by that participant.
[...]
To be more precise, I would add to t= he definition of participants, that all participants must know exactly the = type of other participants.

I = take your point; I did actually consider that for a while - there would be = benefits to being better informed about the other "participants" = - but eventually I rejected the=C2=A0proposition as being intrusive and imp= ractical to mandate/require, although there's certainly opportunities f= or some platforms (?) to offer such information if they choose.
<= br>
To explain:

I don't really "= ;introduce different types of participants'', instead I merely &quo= t;allow" that they exist; it is fine for one participant to be a human= being, another to be an autoresponse=C2=A0bot, and the third to be a conve= rsation-archiver.=C2=A0 The important point is that none of them are "= invisible" to other participants as would be the case with a "gho= st", nor may there be a "ghost outside the machine" accessin= g content (PCASM) by means of a back door.

However= the participants MUST be able to see each other, and... from that, how far= should we go in terms of visibility? =C2=A0

Shoul= d "Signal" be required to disclose to the other participants in a= conversation that I use both my Phone AND ALSO that I use Signal Desktop o= n two separate devices?

Should WhatsApp be require= d to highlight when I am using WhatsAppForWeb in a browser, rather than my = primary device?

I decided that these questions are= beyond the scope of defining End-to-End Secure Messaging, not least becaus= e they are heavily platform specific - for Signal the entity is represented= by a cryptographic key with several devices, whereas WhatsApp uses a on-ph= one identity and (roughly) all other WhatsAp "clients" call back = to the phone for session keys.

=C2=A0
It matters whether participant Eve is a bot or a human.

It does... and it does not, because to p= ursue that goal requires us also to get into (say) WhatsApp-For-Business wi= th Bot-Augmented-Human-Clusters, etc. This is why...

=C2=A0
This would be an actionable definition in or= der to refute that a system with ghost user is still e2e secure.

...this is why the standard is written:<= /div>

1/ To see plaintext content, the viewer must be a = participant (for a given message)
2/ Participants (at the time of= composition) must all see each other, so they know who could see their mes= sage(s)
3/ Anyone who is not a participant, MUST not see plaintex= t content

This kills "Ghosts" because th= ey cannot be invisible, and they cannot access plaintext from outside of th= e conversation "walls".

The question of = whether the visible user "User:XenaWarierPrinces" is a human, bot= , or some kind of bot-human hybrid, is a social question, and best left to = the platform.

=C2=A0
If a par= ticipant lies about the kind of participant they are, this would constitute= a breach and contradict the end user expectations.

That strikes me as a matter for a per-user Accepta= ble Use Policy, and - being a matter of intent - rests outside the scope of= defining howan End-to-End Secure Messenger should behave.


A little higher-up you observed:

Regarding the definition of an =E2=80=9Cend=E2=80=9D ...= =C2=A0In my mind both drafts could be a bit more assertive here

I feel my definition is sharp. and clear, because I leverag= e "Trusted Compute Base" as a concept.=C2=A0 This is a bit of a p= unt, but it flows directly back to my question "Should WhatsApp be req= uired to highlight when I am using WhatsAppForWeb?" - because if it we= re obligatory for a platform to surface that I *do* use WhatsAppForWeb, per= haps it should also surface what browser I am using, and at what patch leve= l?

So:= for the purposes of having a viable standard, it is necessary to accept th= at all participants - human, bot, spook, recorder, malicious, kind - are eq= ual participants, and that the bounds of their usage is defined by what *TH= EY* consider to be "secure". To not accept this would put us in t= he realms of "Ranum's Law", viz: that this is a social proble= m and you can't solve social problems in software.


I think what both drafts don=E2=80=99t fully co= ver yet is the fact that end users have expectations. For me everything ext= rapolates from the =E2=80=9Cset of typical end user expectations=E2=80=9D. = The software and its documentation should make it as clear as possible to t= he user how the system works, who can potentially have access to messages (= e.g. a LE ghost user, a recording bot, only other humans that can be transp= arently authenticated out-of-band).

I am de= lighted for users to have expectations, and I look forward to learning how = their expectations negatively impact this standard other than in terms of o= mission that is arguably not better dealt with at a non-RFC, platform-diffe= rentiation level.=C2=A0


There could be both false positives and false negatives.
False pos= itive: A system that works in a way that doesn=E2=80=99t contradict the def= initions of the draft, but that contradicts the typical end user expectatio= ns.
False negative: A system that contradicts one or more definitions of= the draft (most likely because they are too restrictive) but still meets t= he typical end user expectations.
False positives are downright dangerou= s for end users, while false negatives might hinder the adoption of an othe= rwise great system.

I look forward to concrete examples, and will work to adapt = the specification to fit them where it=C2=A0makes sense.


I understand you want something acti= onable with punchy definitions and I agree that it would be a useful thing = to have. For it to become that, it needs consensus from the wider community= .=C2=A0

I wish to share these perspectives = with the wider community, in order to pursue consensus.=C2=A0 That is why I= am investing this effort.


Not only because that=E2=80=99s the idea behind IETF, but also because = it carries more weight in the end. With that in mind, it would be great if = some more folks would chime in so that this is not only two party conversat= ion with only two opinions.

I would be deli= ghted to hear and address perspectives from others.


What I=E2=80=99m also not sure about is whethe= r the two drafts will be sufficiently different in the end, in the sense th= at they would cater to different audiences.=C2=A0

We shall certainly see; at the moment I am a househusband with plent= y of spare time to dedicate to this effort,=C2=A0so I have ample resource t= o dedicate towards building a consensus definition.


Another aspect that is at least partially cove= red in=C2=A0draft-knodel-e2ee-definition-01 is that= of authentication.=C2=A0
<= br>
That is an interesting concept= : whether the entity can somehow be linked to an external identity namespac= e; as we see from arguments about Signal's use of "phone numbers&q= uot; as an identity principal - and that some people detest their doing so = - it's not a required feature of End-to-End Secure Messengers, and so w= ill not appear in this specification.


I think this plays a big role when it come= s to=C2=A0=E2=80=9Cghost users=E2=80=9D and transparency of participants.= =C2=A0

This is really interesting; I am getting the sens= e that you are strongly drawn to the notion of "real" or "ge= nuine identity" being part of an end-to-end secure messenger solution.= =C2=A0

Would that be correct?


Lastly I also would like to mention the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-architecture-06) th= at touches on a lot of these subjects.

<= div>Indeed, I think that you and I last met at a MLS shindig hosted at Face= book some years ago :-)

=C2=A0
While its purpose is a different one, it goes st= rictly beyond the scope of MLS and highlights aspects that are relevant for= many secure messaging systems.
I hope = the above makes it a bit more clear what I maybe failed to express earlier.=

It is= really interesting, and I am grateful for the pushback and the opportunity= / spark to explain. :-)

=C2=A0 =C2=A0 - Alec


--000000000000a6fcd305c1c443f3-- From nobody Sat May 8 04:13:15 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 78FF93A0DF6 for ; Sat, 8 May 2021 04:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_FROM=0.001, HTML_MESSAGE=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 1YHrJ4st-iTX for ; Sat, 8 May 2021 04:13:13 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 DEDF83A0DF3 for ; Sat, 8 May 2021 04:13:12 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id j11so8511118qtn.12 for ; Sat, 08 May 2021 04:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zkN2MERvm0lAbR6K+IrOoWIjBkl1ZYwI+PWegYrgBs0=; b=uFOBwTHEvV0SfQ5rsgaAlQDck01JjTJ9zmXeLDd6Ffi+1O9SquP7L69LyPNlwW6LTS JI54pMHUAN5wInKB0j66pBjal7LX6xNHfQZY6XspB3j63+IDuJkMiwSb6BphnG+kdPfe yyrjj+b8r2uDsbFFqMKHPhW2Ei48d124hynDN4C1YbeHaxvHd4xCKPrlgvbJU2085VQm ff+bwmIZwvarFozOmT8NzVa8HXQCrXBFTJKTLLgzjvhCJv716TlK9JeWfHMOC+P74MN7 utMtRG4LfSNlNPTONIL9w3z8bPsWjBBtKNGShyPPxwHvS6Hp+3DaJE5Doq0UORYPocgI yhaQ== 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; bh=zkN2MERvm0lAbR6K+IrOoWIjBkl1ZYwI+PWegYrgBs0=; b=QSyq1oSCH0gbLCnndSGgp5eni25HrSaN5cRS0TPWLKSdcyj9fAwWX4EfQgzTWuGNj+ 5RZNQMPrWCAVYopEYmhnSTIZ6FIsLccKQCuDLwuycOM/BEJbOLrqNnsTBjx+L6SiS1vJ 6wgBinqOep8R+crkzputzpAF0WgDw9dJ7qNPP5SegsX9BHQecq2PSFB9aeFFDS/3QX6G VS7The9+jioria6sebSmn4Vqf1QIl2ztq0FcjkvWWVFa81F7Kkgy9BF4BAEugCLhBdyq PHaToRjq5QumIMnTIuSQRVNx69a1J+PVWkHUNqGrFDMWMNM97J4zgLWwC3Awf5QWcCdV 2QEg== X-Gm-Message-State: AOAM532bNuqeJMlf0cwTHoKpe3WqHJXn40vQzMtc2VyT7vm5fr5oPWxZ u8WhjxepyLT/MwCmmGNBNsOkRSfErt96Rj5QV3cNG4RlrvU= X-Google-Smtp-Source: ABdhPJzMMx/KjD/7tb/k0qpJPzdZ5Fpj5liHWVOrq435CcB5uuddz3VWjkfhqnThmnCGRqpPIQkDOz331OpvC3Td4DA= X-Received: by 2002:ac8:574e:: with SMTP id 14mr4205382qtx.191.1620472390304; Sat, 08 May 2021 04:13:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Sat, 8 May 2021 12:12:33 +0100 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000031480105c1cfa1e2" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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: Sat, 08 May 2021 11:13:15 -0000 --00000000000031480105c1cfa1e2 Content-Type: text/plain; charset="UTF-8" Status Update for Functional Definition of End-to-End Secure Messaging: 1/ Version-00 has been submitted, and Version-01 started; work in progress text and diffs are at: URL: https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging (see main page for links) 2/ A big part of the reason for having a standard for measuring End-to-End Secure Messengers is that it permits the development of objective product comparisons; work in progress for comments, input, and corrections at: URL: https://docs.google.com/spreadsheets/d/1UjZhZjq-Afg0ZPrEUcvmVRYDDIrPH77PVyEJHRUZyqQ/edit?usp=sharing - Alec --00000000000031480105c1cfa1e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Status Update for Functi= onal Definition of End-to-End Secure Messaging:

1/ Version-00 has be= en submitted, and Version-01 started; work in progress text and diffs are a= t:=C2=A0

URL: https://github.com/alecmuffett/draft-muffett-end-to-end-sec= ure-messaging=C2=A0(see main page for links)

2/ A bi= g part of the reason for having a standard for measuring End-to-End Secure = Messengers is that it permits the development of objective product comparis= ons; work in progress for comments, input, and corrections at:

=C2=A0 - Ale= c

--00000000000031480105c1cfa1e2-- From nobody Sat May 8 06:27:34 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 A79B83A171B for ; Sat, 8 May 2021 06:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 eNEpqgmWb5V1 for ; Sat, 8 May 2021 06:27:17 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 21A903A1731 for ; Sat, 8 May 2021 06:27:16 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id b17so13521502ede.0 for ; Sat, 08 May 2021 06:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ALezc2Gj7lTevPwonoRbZUreX76SEs+XA+lInB585Ww=; b=wld+yM5M4ZmcpH36fkCXYL0B76tB72y3A/xm19Ru7bms95wroyg7D6nB16/zEFltZW 5D/UHhk+ZTyoJ07+w/h7FHrSXCufH4F6Cueo1rB2KbiAWr0M7pOG54IrE8ETtIQpPGUJ Rxg72tORQSsldvSbehimwT7UKg09EoB+merwA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ALezc2Gj7lTevPwonoRbZUreX76SEs+XA+lInB585Ww=; b=m8GPMMU27TxAB4bbIWAfGm7l9DhXhEnFTi8Ui5n2jTNkQjihNcC/P0U7DFtecu2oF+ 0dZKhoUbzrEw3L4a9tqmUpn8Yv3/oiJjt8Zyy1aGAgkR34LBi1lPnrycr1QDXEJjE3mA pf0T2QflCkuyROTEfAkEYdJpAXW351lTDmvxp639lpkiKF8DvWWs4Q/XHFDsxJfyAKLs jaV4exlwkiagRMJN6YCUw9JkW6Ey/jLJHTrqzSppesWTCKmWsF4K12A2I9/6UIpxxI9K WMBbsP9U1pyErr9ywurWwtdYDwLkY6czl8EuY+j6pqqqpwSAlqV2OVZsK0tRQ86mJBmv KMig== X-Gm-Message-State: AOAM5333p6OvIV11GEOKFBVpxad0SNIhhz2wju3eSsKQgg4BHZ1LDKo6 UzohJgjtx55MxF6PwLg44VZnxA== X-Google-Smtp-Source: ABdhPJx/mBcCHbb0VCr47ktq7MPqWnQSCUiZg7yebwWiBwa2T3hRJZxpIkNckB/SrMj+8Gc86nqVJQ== X-Received: by 2002:aa7:cf12:: with SMTP id a18mr17947108edy.160.1620480434561; Sat, 08 May 2021 06:27:14 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id t14sm5205651ejc.121.2021.05.08.06.27.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 May 2021 06:27:13 -0700 (PDT) From: Raphael Robert Message-Id: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4924649E-4D1E-4D25-B2BF-84E6EF0C20E7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Sat, 8 May 2021 15:27:12 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Alec Muffett References: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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: Sat, 08 May 2021 13:27:33 -0000 --Apple-Mail=_4924649E-4D1E-4D25-B2BF-84E6EF0C20E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > I take your point; I did actually consider that for a while - there = would be benefits to being better informed about the other = "participants" - but eventually I rejected the proposition as being = intrusive and impractical to mandate/require, although there's certainly = opportunities for some platforms (?) to offer such information if they = choose. >=20 > To explain: >=20 > I don't really "introduce different types of participants'', instead I = merely "allow" that they exist; it is fine for one participant to be a = human being, another to be an autoresponse bot, and the third to be a = conversation-archiver. The important point is that none of them are = "invisible" to other participants as would be the case with a "ghost", = nor may there be a "ghost outside the machine" accessing content (PCASM) = by means of a back door. >=20 > However the participants MUST be able to see each other, and... from = that, how far should we go in terms of visibility? =20 >=20 > Should "Signal" be required to disclose to the other participants in a = conversation that I use both my Phone AND ALSO that I use Signal Desktop = on two separate devices? >=20 > Should WhatsApp be required to highlight when I am using = WhatsAppForWeb in a browser, rather than my primary device? >=20 > I decided that these questions are beyond the scope of defining = End-to-End Secure Messaging, not least because they are heavily platform = specific - for Signal the entity is represented by a cryptographic key = with several devices, whereas WhatsApp uses a on-phone identity and = (roughly) all other WhatsAp "clients" call back to the phone for session = keys. Whether users should really see a notification whenever someone adds a = new device to their account is indeed a matter of debate. If = cryptographic assurances exist that adding a new device could only have = been done by possessing some private key material, I believe this nuance = is indeed out-of-scope for your draft. > There could be both false positives and false negatives. > False positive: A system that works in a way that doesn=E2=80=99t = contradict the definitions of the draft, but that contradicts the = typical end user expectations. > False negative: A system that contradicts one or more definitions of = the draft (most likely because they are too restrictive) but still meets = the typical end user expectations. > False positives are downright dangerous for end users, while false = negatives might hinder the adoption of an otherwise great system. >=20 > I look forward to concrete examples, and will work to adapt the = specification to fit them where it makes sense. Again, the absence of examples doesn=E2=80=99t validate the claim. But I = think there is a great example nonetheless: the re-encryption = vulnerability in WhatsApp that was discovered in 2017. I think there are lessons to be learned from that: - The vulnerability itself was not something that most people had on = their radar before it was discovered. It was a "new=E2=80=9D kind of = vulnerability that most people hadn=E2=80=99t thought of. My point here = is that you cannot always think of all the vulnerabilities in advance = and thus produce a false negative when benchmarking. - The vulnerability clearly offered a way to access at least one = message from a WhatsApp user (in its entirety). According to your = definition of what a backdoor is (in section 4.4 in -01.), this would = qualify as a backdoor. WhatsApp itself refuted the claim that this was a = backdoor and so did a number news outlets (e.g. = https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature= -encrypted-messages = ). My point here is that the definition of backdoor = might still be problematic in more than one way. - The vulnerability was in fact a lack of authentication. My point here = is that authentication really matters for E2ESM, encryption alone is not = enough. - End user expectations were not really met and people were taken by = surprise. I think was mostly due to the lack of understanding how = WhatsApp works internally. My point here is that a system should only be = called E2ESM when there is sufficient understanding of how it works. = I=E2=80=99m tempted to make a concrete proposal to maybe quantify this = better: Whether a system qualifies as E2ESM can only be determined if at least 2 = of the following 3 criteria are met: - The software has extensive documentation about its inner workings = that cover all aspects that are relevant to security & privacy - The software is open source - The source code has been audited by a sufficiently independent party = and the unabridged report is publicly available > Another aspect that is at least partially covered in = draft-knodel-e2ee-definition-01 is that of authentication.=20 >=20 > That is an interesting concept: whether the entity can somehow be = linked to an external identity namespace; as we see from arguments about = Signal's use of "phone numbers" as an identity principal - and that some = people detest their doing so - it's not a required feature of End-to-End = Secure Messengers, and so will not appear in this specification. >=20 >=20 > I think this plays a big role when it comes to =E2=80=9Cghost users=E2=80= =9D and transparency of participants.=20 >=20 > This is really interesting; I am getting the sense that you are = strongly drawn to the notion of "real" or "genuine identity" being part = of an end-to-end secure messenger solution.=20 >=20 > Would that be correct? I was more thinking about the authentication on a cryptographic level = between =E2=80=9Cends=E2=80=9D. The user-level identifier is a whole = other dimension (and probably out-of-scope). As mentioned above, authentication really matters in the context of = E2ESM and the maturity of the concepts that are currently implemented in = secure messengers is far behind the quality of the actual E2E encryption = in itself. > Lastly I also would like to mention the MLS architecture draft = (https://tools.ietf.org/html/draft-ietf-mls-architecture-06 = ) that = touches on a lot of these subjects. >=20 > Indeed, I think that you and I last met at a MLS shindig hosted at = Facebook some years ago :-) I believe we did! :) =20 > While its purpose is a different one, it goes strictly beyond the = scope of MLS and highlights aspects that are relevant for many secure = messaging systems. > I hope the above makes it a bit more clear what I maybe failed to = express earlier. >=20 > It is really interesting, and I am grateful for the pushback and the = opportunity / spark to explain. :-) I feel I should re-iterate that I=E2=80=99m not pushing back on the = effort itself, I think its really commendable!=20 Raphael >=20 > - Alec >=20 >=20 > https://alecmuffett.com/about >=20 --Apple-Mail=_4924649E-4D1E-4D25-B2BF-84E6EF0C20E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


I take your point; I did = actually consider that for a while - there would be benefits to being = better informed about the other "participants" - but eventually I = rejected the proposition as being intrusive and impractical to = mandate/require, although there's certainly opportunities for some = platforms (?) to offer such information if they choose.

To explain:

I don't really = "introduce different types of participants'', instead I merely "allow" = that they exist; it is fine for one participant to be a human being, = another to be an autoresponse bot, and the third to be a = conversation-archiver.  The important point is that none of them = are "invisible" to other participants as would be the case with a = "ghost", nor may there be a "ghost outside the machine" accessing = content (PCASM) by means of a back door.

However the participants MUST be able = to see each other, and... from that, how far should we go in terms of = visibility?  

Should "Signal" be required to disclose to the other = participants in a conversation that I use both my Phone AND ALSO that I = use Signal Desktop on two separate devices?

Should WhatsApp be required to = highlight when I am using WhatsAppForWeb in a browser, rather than my = primary device?

I decided that these questions are beyond the scope of = defining End-to-End Secure Messaging, not least because they are heavily = platform specific - for Signal the entity is represented by a = cryptographic key with several devices, whereas WhatsApp uses a on-phone = identity and (roughly) all other WhatsAp "clients" call back to the = phone for session = keys.

Whether users should really see a notification = whenever someone adds a new device to their account is indeed a matter = of debate. If cryptographic assurances exist that adding a new device = could only have been done by possessing some private key material, I = believe this nuance is indeed out-of-scope for your draft.

There could be both false positives and = false negatives.
False positive: A system that works in a = way that doesn=E2=80=99t contradict the definitions of the draft, but = that contradicts the typical end user expectations.
False = negative: A system that contradicts one or more definitions of the draft = (most likely because they are too restrictive) but still meets the = typical end user expectations.
False positives are = downright dangerous for end users, while false negatives might hinder = the adoption of an otherwise great system.
I = look forward to concrete examples, and will work to adapt the = specification to fit them where it makes = sense.
Again, the absence of examples doesn=E2=80=99t = validate the claim. But I think there is a great example nonetheless: = the re-encryption vulnerability in WhatsApp that was discovered in = 2017.

I think there are lessons to = be learned from that:

 - The = vulnerability itself was not something that most people had on their = radar before it was discovered. It was a "new=E2=80=9D kind of = vulnerability that most people hadn=E2=80=99t thought of. My point here = is that you cannot always think of all the vulnerabilities in advance = and thus produce a false negative when benchmarking.

 - The vulnerability clearly offered a way to = access at least one message from a WhatsApp user (in its entirety). = According to your definition of what a backdoor is (in section 4.4 in = -01.), this would qualify as a backdoor. WhatsApp itself refuted the = claim that this was a backdoor and so did a number news outlets = (e.g. https://www.theguardian.com/technology/2017/jan/13/whatsapp-des= ign-feature-encrypted-messages). My point here is that the = definition of backdoor might still be problematic in more than one = way.

 - The vulnerability was = in fact a lack of authentication. My point here is that authentication = really matters for E2ESM, encryption alone is not enough.

 - End user expectations were not really met = and people were taken by surprise. I think was mostly due to the lack of = understanding how WhatsApp works internally. My point here is that a = system should only be called E2ESM when there is sufficient = understanding of how it works. I=E2=80=99m tempted to make a concrete = proposal to maybe quantify this better:

Whether a system qualifies as E2ESM can only be = determined if at least 2 of the following 3 criteria are = met:

 - The software has = extensive documentation about its inner workings that cover all aspects = that are relevant to security & privacy
 - The = software is open source
 - The source code has been = audited by a sufficiently independent party and the unabridged report is = publicly available

Another aspect that is at least partially = covered in draft-knodel-e2ee-definition-01 is that = of authentication. 

That is an interesting concept: whether the entity can = somehow be linked to an external identity namespace; as we see from = arguments about Signal's use of "phone numbers" as an identity principal = - and that some people detest their doing so - it's not a required = feature of End-to-End Secure Messengers, and so will not appear in this = specification.


I think this plays a big = role when it comes to =E2=80=9Cghost users=E2=80=9D and = transparency of participants. 

This is really interesting; I am getting the = sense that you are strongly drawn to the notion of "real" or "genuine = identity" being part of an end-to-end secure messenger = solution. 

Would that be = correct?

I was more thinking about the = authentication on a cryptographic level between =E2=80=9Cends=E2=80=9D. = The user-level identifier is a whole other dimension (and probably = out-of-scope).
As mentioned above, authentication really = matters in the context of E2ESM and the maturity of the concepts that = are currently implemented in secure messengers is far behind the quality = of the actual E2E encryption in itself.

Lastly I also would like = to mention the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-architecture-06)= that touches on a lot of these subjects.

Indeed, I think that you = and I last met at a MLS shindig hosted at Facebook some years ago = :-)

I believe we did! :)
 
While its purpose is a = different one, it goes strictly beyond the scope of MLS and highlights = aspects that are relevant for many secure messaging = systems.
I hope the above makes it a bit more = clear what I maybe failed to express earlier.

It is really interesting, and I = am grateful for the pushback and the opportunity / spark to explain. = :-)

I feel I should re-iterate that I=E2=80=99m not = pushing back on the effort itself, I think its really = commendable! 

Raphael


= --Apple-Mail=_4924649E-4D1E-4D25-B2BF-84E6EF0C20E7-- From nobody Sat May 8 12:27:33 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 DDF263A0CD8 for ; Sat, 8 May 2021 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 AXM61QSPGJrl for ; Sat, 8 May 2021 12:27:26 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 C846D3A0CD6 for ; Sat, 8 May 2021 12:27:25 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id f8so4955672qth.6 for ; Sat, 08 May 2021 12:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=exA95pgFWQUQ1EJPXgAgoZ6bFfQ/leszRSEdi//ZC7s=; b=rUDERKqViMMX4VHdycLHoyZDk3YhiCdDtgh/Yayz19BmLvVEk00ue164jUCKctiSTV GM79GLEPDbxZQD+YkneMJFA/aJsz6UoFf70+KKjkm3hmyCdUAM2Tlj/Y+ewvWUgFpvwu 30R03oxm7/VID873115DCNOGbGmksxeknTLLkjRQBYGiRlTjnVajK1k7GyTXKIKcxJju 4MRqSbKFQQP/fCTPN5C1s+Ys+mj4MqEOwAiuOTxKi5U9dxWbPcjeR9EJxdKvqsrezEPp KS4z0/kmPoEtv6o4wN/BWvb5qCtXeYhIIlJ/r5F4Qj9R/Kenvi31OaXMnEvzsaT1aPOT dz0Q== 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=exA95pgFWQUQ1EJPXgAgoZ6bFfQ/leszRSEdi//ZC7s=; b=F3pjSmWVJtC2gJ86xHysNE7j9NWR9z/gw3/8J2E1tW0q4PAefiPg9AeGvgZNpOXn+d 8Q9pVleMM8EjBTnxSVwOB3MYGd4pe7xcrDFbsrx/Bzo8h+MlT3dj+XTfip+JFA7TXgGD cn+y46JoejsO31qp5043Epwza4rA1omrMcHIpXpP/GJyD2oV4mWALHiYhQuCTA/LVybY qwN0Rs3nkAikO1IEEbeDMOz8RBC+fMwRB+FmLrfYeuF6VH+9pDk94mhlJq6MV0OFAGeo z7fxhHi5nP57J3ziCcyFmMxzZwGNuR9DzMRhHYdY+Vr2a9XBO1fVP7r4EVFWF99jvTHO BlVg== X-Gm-Message-State: AOAM532WLbE8w8AHhEpOvBCxAwlGbmBaqErHNK0ovzGUjL9CLsnO2z0V RB+l06vhk7pi1ZgIdYFHj+2ztvRfECufbDBhuca0Lw5LunK3AQ== X-Google-Smtp-Source: ABdhPJy0nn3rcO7F73EwPjrDvB34iR3Zwqs4CbTCjMypUS3B1Irhnln+58y/3e9frnJK1xMSCM4suLdpoHeMBZHaSXc= X-Received: by 2002:ac8:72d8:: with SMTP id o24mr5607853qtp.321.1620502043933; Sat, 08 May 2021 12:27:23 -0700 (PDT) MIME-Version: 1.0 References: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> In-Reply-To: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> From: Alec Muffett Date: Sat, 8 May 2021 20:26:47 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000afc01a05c1d6881a" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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: Sat, 08 May 2021 19:27:31 -0000 --000000000000afc01a05c1d6881a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 8 May 2021 at 14:27, Raphael Robert wrote: > > Whether users should really see a notification whenever someone adds a ne= w > device to their account is indeed a matter of debate. If cryptographic > assurances exist that adding a new device could only have been done by > possessing some private key material, I believe this nuance is indeed > out-of-scope for your draft. > Exactly. I believe that the feature *is* however necessary for participants to maintain integrity, because there is little benefit in requiring group conversations to be closed against "participant injection" (section 3.4) if the security services of an illiberal state will simply demand (e.g. a hypothetical) that they be provided "Ghost" access via WhatsAppForWeb, i.e. the ghost is injected into a participant instead of a conversation. This is why section 3.5 exists. URL: https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/bl= ob/main/text/draft-muffett-end-to-end-secure-messaging.txt Again, the absence of examples doesn=E2=80=99t validate the claim. But I th= ink > there is a great example nonetheless: the re-encryption vulnerability in > WhatsApp that was discovered in 2017. > > I think there are lessons to be learned from that: > > - The vulnerability itself was not something that most people had on > their radar before it was discovered. It was a "new=E2=80=9D kind of vuln= erability > that most people hadn=E2=80=99t thought of. My point here is that you can= not always > think of all the vulnerabilities in advance and thus produce a false > negative when benchmarking. > > - The vulnerability clearly offered a way to access at least one message > from a WhatsApp user (in its entirety). According to your definition of > what a backdoor is (in section 4.4 in -01.), this would qualify as a > backdoor. > The WhatsApp "resend" issue does not qualify as a "backdoor" under this specification, but you're not the first person to raise that observation. If we quote Section 4.4: > Backdoor: A "backdoor" is any intentional or unintentional mechanism, in respect of a given message and that message's set of participants, where some PCASM of that message MAY become available to a non- participant without the intentional action of a participant. We must also quote Section 4.1: > Participant: A participant is any entity - human, machine, software bot, conversation archiver, or other, that is bounded by the extent of that entity's [TrustedComputingBase]. In the case of the WhatsApp resending "backdoor", each individual message is legitimately encrypted to key material associated with the participant. As we all opined at the time, this is a possibly unwise but legitimate implementational choice: https://technosociology.org/?page_id=3D1687 To leverage this mechanism a malicious actor needs to steal your phone/SIM, or clone your phone, both of which are initial failures of the Trusted Compute Base (TCB, Section 4.1) and are outside the scope of this standard. Otherwise it would also be necessary to accept that the "ability to steal a Facebook account password" is likewise a backdoor in FBMSecretConversations; or that "a malicious WhatsApp employee could "nuke" a user's identity and - in concert with phone-cloning - re-register that phone number to a new device owned by the malicious employee" is also somehow a "backdoor". At some point all "security" comes down to "standing on a bunch of assumptions", and this standard uses the well-documented concept of a TCB to express that point. > WhatsApp itself refuted the claim that this was a backdoor and so did a > number news outlets (e.g. > https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-featur= e-encrypted-messages). > > I know; I think I was the first to shout about it. Certainly I was the rudest: https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report-= 1791158247 (first paragraph) My point here is that the definition of backdoor might still be problematic > in more than one way. > I look forward to learning the problems and addressing them. > - The vulnerability was in fact a lack of authentication. My point here > is that authentication really matters for E2ESM, encryption alone is not > enough. > ...and yet not all messengers require PIN-locks, instead trusting integrity to using phone numbers as the identity principal. Some E2ESM like Ricochet (and, I think, Briar?) use bearer-cryptokeys simultaneously as identity principals and network addresses, so the concept of "identity" is moot. In short: the matter of "identity" is not obligated to extend beyond the consistent and defined concept of an "end" / participant. As such, it falls out of scope. That said, I am wondering whether it would be useful to add a wishlist of RFC2119 "optional" features, like optional PIN-lockdown for identity, where the platform would benefit from it. Maybe this could be one such? - End user expectations were not really met and people were taken by > surprise. I think was mostly due to the lack of understanding how WhatsAp= p > works internally. My point here is that a system should only be called > E2ESM when there is sufficient understanding of how it works. > ...and this standard literally proposes a yardstick to hold up against that understanding. > I=E2=80=99m tempted to make a concrete proposal to maybe quantify this be= tter: > Whether a system qualifies as E2ESM can only be determined if at least 2 > of the following 3 criteria are met: > - The software has extensive documentation about its inner workings that > cover all aspects that are relevant to security & privacy > - The software is open source > - The source code has been audited by a sufficiently independent party > and the unabridged report is publicly available > Those are all political and social requirements, which are nice and I would welcome more software delivering them, but would exclude (say) WhatsApp from the list. I feel that *that* would be controversial. > I was more thinking about the authentication on a cryptographic level > between =E2=80=9Cends=E2=80=9D. The user-level identifier is a whole othe= r dimension (and > probably out-of-scope). > So, notification regarding surprise key changes, that sort of thing, perhaps as an addition to Section 3.2? > I feel I should re-iterate that I=E2=80=99m not pushing back on the effor= t itself, > I think its really commendable! > Thank you! I hope some value comes out of it, including this work-in-progress: https://docs.google.com/spreadsheets/d/1UjZhZjq-Afg0ZPrEUcvmVRYDDIrPH77PVyE= JHRUZyqQ/edit?usp=3Dsharing - Alec --=20 https://alecmuffett.com/about --000000000000afc01a05c1d6881a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 8 May 2021 at 14:27, Raphael R= obert <ietf@raphaelrobert.com<= /a>> wrote:


URL:= =C2=A0
Again, the absence of examples doesn= =E2=80=99t validate the claim. But I think there is a great example nonethe= less: the re-encryption vulnerability in WhatsApp that was discovered in 20= 17.

I think there are lessons to be learned from t= hat:

=C2=A0- The vulnerability itself was not some= thing that most people had on their radar before it was discovered. It was = a "new=E2=80=9D kind of vulnerability that most people hadn=E2=80=99t = thought of. My point here is that you cannot always think of all the vulner= abilities in advance and thus produce a false negative when benchmarking.

=C2=A0- The vulnerability clearly offered a way to = access at least one message from a WhatsApp user (in its entirety). Accordi= ng to your definition of what a backdoor is (in section 4.4 in -01.), this = would qualify as a backdoor.

The WhatsApp "resend" issue does no= t qualify as a "backdoor" under this specification, but you'r= e not the first person to raise that observation. =C2=A0
If we quote Section 4.4:=C2=A0

> B= ackdoor: A "backdoor" is any intentional or unintentional mechani= sm, in respect of a given message and that message's set of participant= s, where some PCASM of that message MAY become available to a non- particip= ant without the intentional action of a participant.

We must also quote Section 4.1:

> Participant: A participant is any entity - human, machine, software b= ot, conversation archiver, or other, that is bounded by the extent of that = entity's [TrustedComputingBase].=C2=A0

<= div>
To leverage this mechanism a malicious actor needs to st= eal your phone/SIM, or clone your phone, both of which are initial failures= of the Trusted Compute Base (TCB, Section 4.1) and are outside the scope o= f this standard. Otherwise it would also be necessary to accept that the &q= uot;ability to steal a Facebook account password" is likewise a backdo= or in FBMSecretConversations; or that "a malicious WhatsApp employee c= ould "nuke" a user's identity and - in concert with phone-clo= ning - re-register that phone number to a new device owned by the malicious= employee" is also somehow a "backdoor".

At some point all "security" comes down to "standing o= n a bunch of assumptions", and this standard uses the well-documented = concept of a TCB to express that point.

=C2=A0
WhatsApp itself refuted the claim that this was a backdoor a= nd so did a number news outlets (e.g.=C2=A0https://www.theguardian.com/technology/2017/jan/13/whatsap= p-design-feature-encrypted-messages).
I know; I think I was the first to shout about it. Certainly I = was the rudest:=C2=A0https://gizmodo.com/theres-no-s= ecurity-backdoor-in-whatsapp-despite-report-1791158247=C2=A0(first para= graph)=C2=A0
=C2=A0

My point here= is that the definition of backdoor might still be problematic in more than= one way.

I look forward to lea= rning the problems and addressing them.

=C2=A0
=C2=A0- The vulnerability was in fact a lack of authenticatio= n. My point here is that authentication really matters for E2ESM, encryptio= n alone is not enough.

...a= nd yet not all messengers require PIN-locks, instead trusting integrity to = using phone numbers as the identity principal.=C2=A0 Some E2ESM like Ricoch= et (and, I think, Briar?) use bearer-cryptokeys simultaneously as identity = principals and network addresses, so the concept of "identity" is= moot.=C2=A0

In short: the matter of "identit= y" is not obligated to extend beyond the consistent and defined concep= t of an "end" / participant.=C2=A0 As such, it falls out of scope= .

That said, I am wondering whether it would be us= eful to add a wishlist of RFC2119 "optional" features, like optio= nal PIN-lockdown for identity, where the platform would benefit=C2=A0from i= t. Maybe this could be one such?
=C2=A0

=C2=A0- End user expectations were not really met and peo= ple were taken by surprise. I think was mostly due to the lack of understan= ding how WhatsApp works internally. My point here is that a system should o= nly be called E2ESM when there is sufficient understanding of how it works.=

...and this standard liter= ally proposes a yardstick to hold up against that understanding.
=
=C2=A0
I=E2=80=99m tempted to make a concr= ete proposal to maybe quantify this better:
Whether a system qual= ifies as E2ESM can only be determined if at least 2 of the following 3 crit= eria are met:
=C2=A0- The software has extensive documentation ab= out its inner workings that cover all aspects that are relevant to security= & privacy
=C2=A0- The software is open source
=C2= =A0- The source code has been audited by a sufficiently independent party a= nd the unabridged report is publicly available

Those are all political and social requirements, which are = nice and I would welcome more software delivering them, but would exclude (= say) WhatsApp from the list. =C2=A0

I feel that *t= hat* would be controversial.

=C2=A0
I was more thinking about the authentication on a cryptographic level be= tween =E2=80=9Cends=E2=80=9D. The user-level identifier is a whole other di= mension (and probably out-of-scope).

So, notification regarding surprise key changes, that sort of thing, = perhaps as an addition to Section 3.2?
=C2=A0
=C2=A0
I feel I should re-iterate that I=E2=80=99m not pushing= back on the effort itself, I think its really commendable!=C2=A0

Thank you! I hope some value comes= out of it, including this work-in-progress:=C2=A0
=C2=A0<= /div>
=C2=A0 - Alec

--
--000000000000afc01a05c1d6881a-- From nobody Sat May 8 14:10:36 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 4D99A3A1301 for ; Sat, 8 May 2021 14:10:34 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 ftJZoegnUIu0 for ; Sat, 8 May 2021 14:10:29 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 446A03A12FF for ; Sat, 8 May 2021 14:10:29 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id u7so6555999qvv.12 for ; Sat, 08 May 2021 14:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vb3bwk5RwvI9FfJHPIr2N+PqHmI36G2uOOODiVUJam8=; b=lecxLs5IgdEcN1rCp+WbkraGERsxPpE+seA3ylul/t+/Ee23iTyx/dpw7J763otaDC 6hrBhLfXyzfMGQzhYQtaMXsERd8Jm7MyDvrAmWs8LLmB4eYQFieOsSnZeGVeOenh0h7m o5uLSYE1KyOOMB622m1JUsOYMD1UjqhYEpR4oGm00Ib189miAVCLnYBSZC0xWl/tPErC ymLj7jp1H5a4dokjLj7BhJfgoX5vHLb+k8te//Xcp++ptOCcDkiY6zAO0TOpdw26glQp mNGeFNgZRzDJ85fjUDqJAr5j+iqsKwq674VM0IMiDUlX8k30Qnm9BiUqGQm5+V87RYd+ 1OcQ== 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=Vb3bwk5RwvI9FfJHPIr2N+PqHmI36G2uOOODiVUJam8=; b=c4bFg2nZ/dopmFIacDIOgIXKXB8cIx2rO3nF6uQSMD7LLgjY2httw6IGS0O56Z+mvN gCvN1FvlAyv+7Da079KlLTOicTu9a0ESP1eV6w1jnNhAgDsIJNZZ4iQYDWPRmZvPEmbL iRX3wUlbBo6ZxClIv44UXkTKIv3rrcW2yHi+jLBkiFkvUGZCPmi2MekyNmUo0UC4FgNz MR7jz6h+N4KxPXLdb1wxFXrR6XzJWlxfoNF1Z/6eqBkEyeEIs7QzKjkmI4fTBI9hC0z1 bi+WQBdkgwQs0BAycR8BT5Y9VusjfRi+855Ifp7cDGXuZXH3XokFAduoeTA0CUOL6lEJ F51A== X-Gm-Message-State: AOAM53107E5DJiupyWAFAqArZqd8QrtjqC28RstEGFHGHiYGu/4L+RvS eX9cHRyh7P/+cKAXL9Ml4LJgBInc1CEZu+OhtsM= X-Google-Smtp-Source: ABdhPJwIw4ujcskDwhzSqbT5x0hHhoSg7Hz041pf67ZXMbh8hrFpYTlPBHgyaKTBFyLSMXkkkLU7rQ0qmN8xY1DRwls= X-Received: by 2002:a0c:9e0f:: with SMTP id p15mr16232939qve.27.1620508227402; Sat, 08 May 2021 14:10:27 -0700 (PDT) MIME-Version: 1.0 References: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> In-Reply-To: From: Alec Muffett Date: Sat, 8 May 2021 22:09:50 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000004000dc05c1d7f90c" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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: Sat, 08 May 2021 21:10:34 -0000 --0000000000004000dc05c1d7f90c Content-Type: text/plain; charset="UTF-8" On Sat, 8 May 2021 at 20:26, Alec Muffett wrote: > We must also quote Section 4.1: > > > Participant: A participant is any entity - human, machine, software bot, > conversation archiver, or other, that is bounded by the extent of that > entity's [TrustedComputingBase]. > > In the case of the WhatsApp resending "backdoor", each individual message > is legitimately encrypted to key material associated with the participant. > As we all opined at the time, this is a possibly unwise but legitimate > implementational choice: https://technosociology.org/?page_id=1687 > > To leverage this mechanism a malicious actor needs to steal your > phone/SIM, or clone your phone, both of which are initial failures of the > Trusted Compute Base (TCB, Section 4.1) and are outside the scope of this > standard. [...deletia...]. > > At some point all "security" comes down to "standing on a bunch of > assumptions", and this standard uses the well-documented concept of a TCB > to express that point. > Incidentally, there's a great pun / potential vulnerability name inherent in this observation, viz: *"split ends attack"*. Just wanted to call dibs. :-) Have a great weekend! - alec -- https://alecmuffett.com/about --0000000000004000dc05c1d7f90c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 8 May 2021 at 20:26, Alec Muffett= <alec.muffett@gmail.com&g= t; wrote:
We must also quote Section 4.1:

> Participant: A participant= is any entity - human, machine, software bot, conversation archiver, or ot= her, that is bounded by the extent of that entity's [TrustedComputingBa= se].=C2=A0

In the case of the WhatsApp resen= ding "backdoor", each individual message is legitimately encrypte= d to key material associated with the participant.=C2=A0 As we all opined a= t the time, this is a possibly unwise but legitimate implementational choic= e:=C2=A0https://technosociology.org/?page_id=3D1687

=
To leverage this mechanism a malicious actor needs to steal your phone= /SIM, or clone your phone, both of which are initial failures of the Truste= d Compute Base (TCB, Section 4.1) and are outside the scope of this standar= d. [...deletia...].

At some point all "securi= ty" comes down to "standing on a bunch of assumptions", and = this standard uses the well-documented concept of a TCB to express that poi= nt.
=


Incidentally, there's a= great pun / potential vulnerability name inherent in this observation, viz= : "split ends attack".

Just wante= d to call dibs. :-)

Have a great weekend!

=C2=A0 =C2=A0 - alec

--
--0000000000004000dc05c1d7f90c-- From nobody Sun May 9 00:56: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 9CF143A1FF6 for ; Sun, 9 May 2021 00:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[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=kBFkc7fm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fzz0gH5v 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 QcqMeQAw8P-7 for ; Sun, 9 May 2021 00:56:02 -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 E2A4E3A1FF3 for ; Sun, 9 May 2021 00:56:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1444B18F7 for ; Sun, 9 May 2021 03:40:15 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 09 May 2021 03:40:15 -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=/lYP2xJ9Cwu 3bDDT/7nboIrct/SLKjqLqq6BrZ/stdQ=; b=kBFkc7fmW6DIWiO8KRcEqdHLvkT 2rB/EGkAw4U/g3zC6wCH6Qxq3K+fgbMj3gYVo/X6DrPsyxRij37pi0UUYYt4MBN+ 67JyumP2OkXfijE/7rcIUrAMP09KsZ/VW0o+QQLQXUjPmiurWDE/zZAtkjEXag+2 tceJFvkKcvlpT8JjVvBu7MGor1J7FH4NPJNhxVW+e5ovfs2UP3fMOhsujX5wVTzh V/uPuy1Gd12ExO8Hl7mSxAvhx5K/DGP2R1ZQ8A0qw1PfBTRWUGX3ccncnKHkVbwF aOSWjnBA/EW9hM8ZtJTYTZ4TkbZxD9WhNB0ov7W8N0pJaBZoibs73Rz/Bcg== 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= fm2; bh=/lYP2xJ9Cwu3bDDT/7nboIrct/SLKjqLqq6BrZ/stdQ=; b=Fzz0gH5v ukTCdRzoE1KSUh+nm2fAN/3Uh+cNV+yzQ8Sq8RQ/QR2W4i0qvx2KTjBTW0+ERu4N mBjN8jiymhqXkCiIUPhIEbIxljiKpG3WBt4+MAzba6Wa95t3MSOKgcJAJa2MsQYL OH9Gg3VXJj/uQ5nlvpMuIwWZqpWh69HPZhwDinkm1acgjgcq9JNcsCPTJS/KvQYv 0yP/5jvHhtHH6s4JzpFV6v4kHIuh+7+KSbKqorRbHZE0RlXp/OBBZEpovUZHIV5D 5I21rGCNTH/wVjzITY3e9vfst/jVg4yS5j/MUVmBO09eEKpMsY9VNeu5ADxx/n8X TeRO9owWuCFgcA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeghedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecukfhppedvtddrudekhedrkeekrdduiedunecuvehluhhsthgvrhfuihiivgep udenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhoth drnhgvth X-ME-Proxy: Received: from fv-az154-953.kzav01uq0i3u1f1hch3ggm0mbb.bx.internal.cloudapp.net (unknown [20.185.88.161]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 9 May 2021 03:40:14 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6087527516078832626==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210509075602.E2A4E3A1FF3@ietfa.amsl.com> Date: Sun, 9 May 2021 00:56:02 -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, 09 May 2021 07:56:09 -0000 --===============6087527516078832626== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Fix typos in the "IANA Considerations" section (by TWal) 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 --===============6087527516078832626== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday May 09, 2021

Pull requests

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

1 pull requests submitted:

Repositories tracked by this digest:

--===============6087527516078832626==-- From nobody Sun May 9 10:58:57 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 200603A184E for ; Sun, 9 May 2021 10:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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=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 CNa09RrLb_04 for ; Sun, 9 May 2021 10:58:51 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 A49823A184F for ; Sun, 9 May 2021 10:58:50 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id w3so21106032ejc.4 for ; Sun, 09 May 2021 10:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vIpZJKEjnnq411LhFOU9WsModKdZDKHCRPvK5By6TQ0=; b=A9QSuBqI5RWRTOkzwY5N5Y8uHByX2Bn18nqzamx72U5EpmqDPcyetGyYkOYoyDQA12 F+0SlP7EdOpwof+0zYhj/Yzod88S/wgyLMPO95eSnvDWUhYRDjCbkfnBRKcEYUIBvmzk gn+m5rL0MzH2XWpHm7i+9XjE3NLdzPTcvasrc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vIpZJKEjnnq411LhFOU9WsModKdZDKHCRPvK5By6TQ0=; b=ui1+Tx5FKT+HYqxIRyQPk/tBX/g16R5aLfJRggYl0GvFTjf6EK7GWLzJ1ZhC9DC0TD Bgpvv57gYdLxpuBHTihnTyXO5GWTg+FnZ0L4JIA+COXZXV68ztDOEMNNIiIIaqKwO9qT spAjvLP1GRi3EVO8Taw68z2C29c5wQmmZdeHA2EbihXYRRcYpMPSngcvSfOSuIkJq8ts 8vTO2F2HI5WQnwnmr3Mw7VvyVpSOB/kervtLuQ/3vUG1pcyo7psBohFH/YwVwfGy2yRm M2SNguSqHFHkGMHhvtfNFL1JuN1NRMIo7Mpu7F8m1bUSqHdwNc+3ulZWQ6E0xWyv6xGs ubnw== X-Gm-Message-State: AOAM530n7n0yIIZ8J9vRT9PBHqkWqhMOOkvz9ZotZw70U5SGFalx/p7a dyms2pAa9F2gkLhXcL3+FheI/A== X-Google-Smtp-Source: ABdhPJx+mj2Sf2QTJB2kD6ihXyhZyceY2a7KW7/EJERaIUtlQZ1s6Ubzo8W0D5O+TQl5nh/tytjtFw== X-Received: by 2002:a17:906:6854:: with SMTP id a20mr21167136ejs.329.1620583128270; Sun, 09 May 2021 10:58:48 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id g9sm7262182ejo.8.2021.05.09.10.58.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 May 2021 10:58:47 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_97C908FE-CF47-4716-9C78-079B77DD1141" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Sun, 9 May 2021 19:58:45 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Alec Muffett References: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 09 May 2021 17:58:56 -0000 --Apple-Mail=_97C908FE-CF47-4716-9C78-079B77DD1141 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The WhatsApp "resend" issue does not qualify as a "backdoor" under = this specification, but you're not the first person to raise that = observation. =20 >=20 > If we quote Section 4.4:=20 >=20 > > Backdoor: A "backdoor" is any intentional or unintentional = mechanism, in respect of a given message and that message's set of = participants, where some PCASM of that message MAY become available to a = non- participant without the intentional action of a participant. >=20 > We must also quote Section 4.1: >=20 > > Participant: A participant is any entity - human, machine, software = bot, conversation archiver, or other, that is bounded by the extent of = that entity's [TrustedComputingBase].=20 >=20 > In the case of the WhatsApp resending "backdoor", each individual = message is legitimately encrypted to key material associated with the = participant. As we all opined at the time, this is a possibly unwise = but legitimate implementational choice: = https://technosociology.org/?page_id=3D1687 = >=20 > To leverage this mechanism a malicious actor needs to steal your = phone/SIM, or clone your phone, both of which are initial failures of = the Trusted Compute Base (TCB, Section 4.1) and are outside the scope of = this standard. Otherwise it would also be necessary to accept that the = "ability to steal a Facebook account password" is likewise a backdoor in = FBMSecretConversations; or that "a malicious WhatsApp employee could = "nuke" a user's identity and - in concert with phone-cloning - = re-register that phone number to a new device owned by the malicious = employee" is also somehow a "backdoor". >=20 > At some point all "security" comes down to "standing on a bunch of = assumptions", and this standard uses the well-documented concept of a = TCB to express that point. >=20 > =20 > WhatsApp itself refuted the claim that this was a backdoor and so did = a number news outlets (e.g. = https://www.theguardian.com/technology/2017/jan/13/whatsapp-design-feature= -encrypted-messages = ). >=20 > I know; I think I was the first to shout about it. Certainly I was the = rudest: = https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-despite-report= -1791158247 = (first paragraph)=20 Yeah, that=E2=80=99s not how I remember it. I=E2=80=99m pretty sure the = gist of it was that the vendor (or an actor controlling the vendor=E2=80=99= s infrastructure) could convince WA clients to re-encrypt messages to a = different cryptographic identity. No SIM-card cloning was required. I=E2=80=99m absolutely not calling this a backdoor, but it was a way for = the vendor to stealthy trigger re-encryption and thus potentially get = access to message content. There=E2=80=99s a good chance that falls = under your new definition of a backdoor. I find the section 4.2 & 4.5 in draft-knodel-e2ee-definition-01 less = controversial in that respect and they are probably sharp enough to = serve as a yardstick. > - The vulnerability was in fact a lack of authentication. My point = here is that authentication really matters for E2ESM, encryption alone = is not enough. >=20 > ...and yet not all messengers require PIN-locks, instead trusting = integrity to using phone numbers as the identity principal. Some E2ESM = like Ricochet (and, I think, Briar?) use bearer-cryptokeys = simultaneously as identity principals and network addresses, so the = concept of "identity" is moot.=20 >=20 > In short: the matter of "identity" is not obligated to extend beyond = the consistent and defined concept of an "end" / participant. As such, = it falls out of scope. >=20 > That said, I am wondering whether it would be useful to add a wishlist = of RFC2119 "optional" features, like optional PIN-lockdown for identity, = where the platform would benefit from it. Maybe this could be one such? Agreed, I really wouldn=E2=80=99t consider anything beyond the = cryptographic identity of an endpoint. Anything else is vendor-specific = as you say. > I=E2=80=99m tempted to make a concrete proposal to maybe quantify this = better: > Whether a system qualifies as E2ESM can only be determined if at least = 2 of the following 3 criteria are met: > - The software has extensive documentation about its inner workings = that cover all aspects that are relevant to security & privacy > - The software is open source > - The source code has been audited by a sufficiently independent = party and the unabridged report is publicly available >=20 > Those are all political and social requirements, which are nice and I = would welcome more software delivering them, but would exclude (say) = WhatsApp from the list. =20 >=20 > I feel that *that* would be controversial. Oh well, I see that differently. If rubber-stamping some of FB=E2=80=99s = poorer decisions with that draft is a desired goal, it changes the = optics quite a bit.=20 draft-knodel-e2ee-definition-01 has a much higher degree of = independence. > I was more thinking about the authentication on a cryptographic level = between =E2=80=9Cends=E2=80=9D. The user-level identifier is a whole = other dimension (and probably out-of-scope). >=20 > So, notification regarding surprise key changes, that sort of thing, = perhaps as an addition to Section 3.2? It really falls in under =E2=80=9Cauthentication=E2=80=9D in general. = draft-knodel-e2ee-definition-01 has the nice concept of encrypted = channels (although it contradicts the MLS notion of groups a bit). It should be clear to the user at the time of encryption who the = participants are and there should be a way to verify the participants = and their cryptographic identity. I know this pretty much excludes = iMessage. But if we want a definition of E2ESM that covers iMessage, we = need to drop authentication completely and that=E2=80=99s definitely = weak sauce. Raphael --Apple-Mail=_97C908FE-CF47-4716-9C78-079B77DD1141 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The = WhatsApp "resend" issue does not qualify as a "backdoor" under this = specification, but you're not the first person to raise that = observation.  

If we quote Section 4.4: 

> Backdoor: A "backdoor" is any = intentional or unintentional mechanism, in respect of a given message = and that message's set of participants, where some PCASM of that message = MAY become available to a non- participant without the intentional = action of a participant.

We must also quote Section = 4.1:

> Participant: A participant is any entity - human, = machine, software bot, conversation archiver, or other, that is bounded = by the extent of that entity's [TrustedComputingBase]. 

In the case of the = WhatsApp resending "backdoor", each individual message is legitimately = encrypted to key material associated with the participant.  As we = all opined at the time, this is a possibly unwise but legitimate = implementational choice: https://technosociology.org/?page_id=3D1687

To leverage this = mechanism a malicious actor needs to steal your phone/SIM, or clone your = phone, both of which are initial failures of the Trusted Compute Base = (TCB, Section 4.1) and are outside the scope of this standard. Otherwise = it would also be necessary to accept that the "ability to steal a = Facebook account password" is likewise a backdoor in = FBMSecretConversations; or that "a malicious WhatsApp employee could = "nuke" a user's identity and - in concert with phone-cloning - = re-register that phone number to a new device owned by the malicious = employee" is also somehow a "backdoor".

At some point all "security" comes down = to "standing on a bunch of assumptions", and this standard uses the = well-documented concept of a TCB to express that point.

 
WhatsApp itself refuted the claim that this = was a backdoor and so did a number news outlets (e.g. https://www.theguardian.com/technology/2017/jan/13/whatsapp-des= ign-feature-encrypted-messages).

I know; I think I was = the first to shout about it. Certainly I was the rudest: https://gizmodo.com/theres-no-security-backdoor-in-whatsapp-des= pite-report-1791158247 (first = paragraph) 

Yeah, that=E2=80=99s = not how I remember it. I=E2=80=99m pretty sure the gist of it was that = the vendor (or an actor controlling the vendor=E2=80=99s infrastructure) = could convince WA clients to re-encrypt messages to a different = cryptographic identity. No SIM-card cloning was = required.
I=E2=80=99m absolutely not calling this a backdoor, = but it was a way for the vendor to stealthy trigger re-encryption and = thus potentially get access to message content. There=E2=80=99s a good = chance that falls under your new definition of a backdoor.
I = find the section 4.2 & 4.5 in draft-knodel-e2ee-definition-01 = less controversial in that respect and they are probably sharp enough to = serve as a yardstick.

 - The vulnerability was in fact a lack = of authentication. My point here is that authentication really matters = for E2ESM, encryption alone is not enough.

...and yet not all messengers require = PIN-locks, instead trusting integrity to using phone numbers as the = identity principal.  Some E2ESM like Ricochet (and, I think, = Briar?) use bearer-cryptokeys simultaneously as identity principals and = network addresses, so the concept of "identity" is moot. 

In short: the matter of = "identity" is not obligated to extend beyond the consistent and defined = concept of an "end" / participant.  As such, it falls out of = scope.

That = said, I am wondering whether it would be useful to add a wishlist of = RFC2119 "optional" features, like optional PIN-lockdown for identity, = where the platform would benefit from it. Maybe this could be one = such?

Agreed, I really wouldn=E2=80=99= t consider anything beyond the cryptographic identity of an endpoint. = Anything else is vendor-specific as you say.

I=E2=80=99m tempted to make a concrete = proposal to maybe quantify this better:
Whether a = system qualifies as E2ESM can only be determined if at least 2 of the = following 3 criteria are met:
 - The software = has extensive documentation about its inner workings that cover all = aspects that are relevant to security & privacy
 - The software is open source
 - The source code has been audited by a sufficiently = independent party and the unabridged report is publicly = available

Those are all political and social = requirements, which are nice and I would welcome more software = delivering them, but would exclude (say) WhatsApp from the list. =  

I feel = that *that* would be = controversial.
=

Oh well, I see = that differently. If rubber-stamping some of FB=E2=80=99s poorer = decisions with that draft is a desired goal, it changes the optics quite = a bit. 
draft-knodel-e2ee-definition-01 has a much higher = degree of independence.

I was more thinking about the authentication = on a cryptographic level between =E2=80=9Cends=E2=80=9D. The user-level = identifier is a whole other dimension (and probably = out-of-scope).

So, notification regarding surprise key = changes, that sort of thing, perhaps as an addition to Section = 3.2?

It really falls in under = =E2=80=9Cauthentication=E2=80=9D in = general. draft-knodel-e2ee-definition-01 has the nice concept of = encrypted channels (although it contradicts the MLS notion of groups a = bit).
It should be clear to the user at the time of encryption = who the participants are and there should be a way to verify the = participants and their cryptographic identity. I know this pretty much = excludes iMessage. But if we want a definition of E2ESM that covers = iMessage, we need to drop authentication completely and that=E2=80=99s = definitely weak sauce.

Raphael

= --Apple-Mail=_97C908FE-CF47-4716-9C78-079B77DD1141-- From nobody Sun May 9 16:41:40 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 B6E703A24E2 for ; Sun, 9 May 2021 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=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 (1024-bit key) header.d=riseup.net 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 dXwGri4bLUN9 for ; Sun, 9 May 2021 16:41:34 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 EB5B33A24DF for ; Sun, 9 May 2021 16:41:33 -0700 (PDT) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4Fdggc56C5zDv3q for ; Sun, 9 May 2021 16:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1620603692; bh=JzCPT/7SKTQ1JgAk20KtnaKSxLvLwKja95WoAQHVMoo=; h=To:References:From:Subject:Date:In-Reply-To:From; b=s4Dn/IL4mzktU0BOM+7RMNSi4cU9m0ibZ5IEz60ZXpvyfRxvZL/77h+fumd1R9yla b8RFRrUgwD4ZQLxhyZVINzi01iMPJSE/ofMkhWwCS3BBYXYlw1RyoqHRKAJVC2Z3wQ OzoX3yuiSwpIG/QbXpbiNKYUPTQaaCiYxztGliiw= X-Riseup-User-ID: 5B7603CEFD6745DA0EDFAE78D23F7BC246ECEFC001B3F36600FDD7EA90637E1C Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4Fdggc1QD2z1xph for ; Sun, 9 May 2021 16:41:31 -0700 (PDT) To: mls@ietf.org References: From: =?UTF-8?Q?Sof=c3=ada_Celi?= Message-ID: <937f9db9-d0e2-390e-0ef8-8dfa73e993b0@riseup.net> Date: Mon, 10 May 2021 00:41:30 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 09 May 2021 23:41:39 -0000 Dear, Raphael, Thank you so much you all for this very interesting thread. > Regarding the definition of an “end”, draft-knodel-e2ee-definition-01 > has section 2.1, 4.3 & 4.5. Your draft has section 4.1 & 5. In my mind > both drafts could be a bit more assertive here. I like that you > introduce different types of participants. I think that point is > particularly important, because if the participants are not just “humans > with a messenger app”, it begs the question who has control over the > messages that were received by that participant. Other humans who are > not part of the “conversation”? Future participants of the > “conversation”? A machine that will scan the message content and act on > it? In the end this defines what “confidentiality” really means, besides > the academic definition. These are really interesting points. I see four points: * Future or past recipients of a conversation: it could be that a conversation is read prior to the intended recipient, or after the intended recipient. This is somewhat not cover in every day applications, as someone else can get access to a device and read the messages intended for a recipient. In those terms, I think this is described as 'secure' for the network (and the intended recipient is the device, then); but if a device is compromised, then the contents could be potentially read by someone else. A point to include here then is the idea of 'disappearing messages', as a property for trying to avoid this. But if a message is read and disappeared prior to the actual "recipient" reading it, then the purpose is also lost. It could also be that someone asks you to show the contents of a conversation, as it has happened to many while crossing borders or an abusers that controls the devices in a case of domestic violence. * Messages read by something that is not a "human": this could be a bot that is part of a conversation (but should it be?, if so, it should be disclosed to the sender-s-, and potentially properly "authenticated") or malware in the device itself. * Messages read by a backdoor or vulnerability: I think that if an application has a backdoor (with the whole purpose of having it there to read the contents) then it is not end-to-end encrypted. If someone or something is added to the conversation, then it should be authenticated and disclosed. * Multiple devices: this could be better explained by stating that the intended recipients could be multiple devices (these all have to be authenticated to the conversation). I really like all of these points (for taking them into account). @Mallory, I can add some ideas around this to our draft and we can discuss all further ;) Thank you, -- Sofía Celi @claucece http://claucece.github.io/ Cryptographic research and implementation at many places, but mainly at Cloudflare FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02 From nobody Sun May 9 23:31:16 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 E62083A15FA for ; Sun, 9 May 2021 23:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 ubCsfenFl9AA for ; Sun, 9 May 2021 23:31:10 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 CEC413A15F9 for ; Sun, 9 May 2021 23:31:09 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id 1so11234474qtb.0 for ; Sun, 09 May 2021 23:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lEj6z6/S+key911YuyKeKuGgwHIaXKr3jah+FElMdT4=; b=gFmm8mCRxVPlZFhqxYAeeI1+JV+qFIEH7NOvvf2MIm3V4S0fYH7JupcDPC04DaqC2X W6rMHKwnbmIplVRU4A8kOkb6NnXokbyJSlS+/2FbXMtO1iSrY4W2VYIZNrylKL0o6nGu RtMFGb5mRdOdYhw6StEF3QS4JUaTpYfQ2CEmzupl4fVLu/vdrxWvb/KAUQrf/1ITvlLQ RBMxWnWI9QijNs4LQ036IwaFnKbYLxIELzOcE+8eeQNPFDcSuOtVcso4FKhB9QMc4rDO vAjQ2AbfrqPLjWy/NnB87iuP3oGwXHz9iFHFshmChlpnV+IFQDJVeMBfNjZXDl608KGQ wHjA== 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=lEj6z6/S+key911YuyKeKuGgwHIaXKr3jah+FElMdT4=; b=gdivEKZ3M2P/ObCbiFB2kp/CQbclrfAJ/0tSYvLM46vKaA0C05HzCguOLPcnwBpqb0 NKTf2akDSj8jXU2XtGXCD5fAheFz/IZQZSPnBS+ImD7QoYjiUi+t/60Bl+IuGVe8sUM5 RXvao3hm2PaT4hgXgfXk2S4xvlS2KJI+s3dpc1/xjiM8Ds+DUUmVSBROKm60x2gjZKLy +OuVsg2cuGh88WAwlCrZ2RskKigeq8eVFsRtNdlazdwisWMPY7d5kRH1YgNmLrjLl2Q7 qaxc2UR3o2JP5UPAVZ9T3e7DtGIwzXra7SKyciREWMYlZ9jfUuUmQeyUiazi0QnEYZUT uX1Q== X-Gm-Message-State: AOAM530HJOhKcV6dhfk5YdV41kp8VEm+HaP0CGpKkf/Dqj44xVp2ccx7 Ir5SawJ0HX5pd3u2rF1ZL658klyasOxDvayXwrMmsoDehv7iJA== X-Google-Smtp-Source: ABdhPJyBYBH6PzqLp+PmP/pUcx8K8y6FW8RrU702Yxp1E6oYUTKyh8G1zDhbUI78JijtXUfMsp4pu/mkfJmJYL4xijE= X-Received: by 2002:ac8:574e:: with SMTP id 14mr11969621qtx.191.1620628268013; Sun, 09 May 2021 23:31:08 -0700 (PDT) MIME-Version: 1.0 References: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> In-Reply-To: From: Alec Muffett Date: Mon, 10 May 2021 07:30:31 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000003a5d6d05c1f3ec0b" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 06:31:15 -0000 --0000000000003a5d6d05c1f3ec0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 9 May 2021 at 18:58, Raphael Robert wrote: > Yeah, that=E2=80=99s not how I remember it. I=E2=80=99m pretty sure the g= ist of it was > that the vendor (or an actor controlling the vendor=E2=80=99s infrastruct= ure) could > convince WA clients to re-encrypt messages to a different cryptographic > identity. No SIM-card cloning was required. > Mm; there's a very simple proof of my point: in order to add a new device and to steal these messages, it is first necessary for the malicious actor to successfully impersonate a new user device, in order to subvert the trust that WhatsApp has in the integrity of the user. To perform this subversion requires SIM-cloning, some form of phone-jacking, or - in the very simplest circumstance, as happened to one of my family last week - socially engineering the user to forward the confirmatory SMS/nonce for new device setup, *to* the malicious actor. The proof is: this is an abnormal activity. It mostly does not happen, otherwise far more WhatsApp account theft would occur, enabled by malicious actors simply connecting a new device and saying "Hey, I am Raphael Robert, please send me anything addressed to him." *This* is the concept of a Trusted Compute Base. We should all be deeply worried that the integrity of Signal, WhatsApp, etc, all rely upon confirmatory SMSes, but that's outside the scope of this standard. In short: the matter of "identity" is not obligated to extend beyond the > consistent and defined concept of an "end" / participant. As such, it > falls out of scope. > That said, I am wondering whether it would be useful to add a wishlist of > RFC2119 "optional" features, like optional PIN-lockdown for identity, whe= re > the platform would benefit from it. Maybe this could be one such? > > > Agreed, I really wouldn=E2=80=99t consider anything beyond the cryptograp= hic > identity of an endpoint. Anything else is vendor-specific as you say. > Concur. > If rubber-stamping some of FB=E2=80=99s poorer decisions with that draft = is a > desired goal, it changes the optics quite a bit. > draft-knodel-e2ee-definition-01 has a much higher degree of independence. > That's a tragic strawman; to repeat, the goal is to provide a metric for judging the "minimally viable product behaviour" for something to be worthy of being called "end-to-end secure"; it's also short, and measurable against an implementation. I was more thinking about the authentication on a cryptographic level >> between =E2=80=9Cends=E2=80=9D. The user-level identifier is a whole oth= er dimension (and >> probably out-of-scope). >> > > So, notification regarding surprise key changes, that sort of thing, > perhaps as an addition to Section 3.2? > > > It really falls in under =E2=80=9Cauthentication=E2=80=9D in > general. draft-knodel-e2ee-definition-01 has the nice concept of encrypte= d > channels (although it contradicts the MLS notion of groups a bit). > It should be clear to the user at the time of encryption who the > participants are > For me, that's Sections 3.1 and 3.2. > and there should be a way to verify the participants and their > cryptographic identity. > Yes, but "verify them against... what?" [explanation follows below, after joke] > I know this pretty much excludes iMessage. But if we want a definition of > E2ESM that covers iMessage, > Rubber-stamping some of Apple's decisions? [joke] > we need to drop authentication completely and that=E2=80=99s definitely w= eak sauce. > The word "authentication" is only meaningful within two - what shall we call them, "frames"? 1/ that the "participant" is-or-is-not part of the conversation; but that's the very *definition* of an end-to-end-secure conversation: that "the only people who can read are participants, and participants are those who can read", and it is the trusted-compute-base of each participant-entity which defines their participation 2/ that the "participant" somehow relates to some external identity framework, for instance a PKI or a Driving License Number. ...however I suspect that you may mean: 3/ that the "participant" is fully in control of their devices and endpoints, and that one of them has not been subverted or inserted by a malicious actor; but this (again) eventually requires the E2ESM client to perform a security audit of the device that it's hosted on, etc. This one is hard, and possibly illiberal/unwise. I would like to check please whether I am correctly reflecting your wants for authentication? 1, 2, 3, or other? - Alec --=20 https://alecmuffett.com/about --0000000000003a5d6d05c1f3ec0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, 9 May 2021 at 18:58, Raphael = Robert <ietf@raphaelrobert.com= > wrote:
Yeah, that=E2=80=99s not how I remember it= . I=E2=80=99m pretty sure the gist of it was that the vendor (or an actor c= ontrolling the vendor=E2=80=99s infrastructure) could convince WA clients t= o re-encrypt messages to a different cryptographic identity. No SIM-card cl= oning was required.=C2=A0

Mm; t= here's a very simple proof of my point: in order to add a new device an= d to steal these messages, it is first necessary for the malicious actor to= successfully impersonate a new user device, in order to subvert the trust = that WhatsApp has in the integrity of the user.

To= perform this subversion requires SIM-cloning, some form of phone-jacking, = or - in the very simplest circumstance, as happened=C2=A0to one of my famil= y last week - socially engineering the user to forward the confirmatory SMS= /nonce for new device setup, *to* the malicious actor.

=
The proof is: this is an abnormal activity. It mostly does not happen,= otherwise far more WhatsApp account theft would occur, enabled by maliciou= s actors simply connecting a new device and saying "Hey, I am Raphael = Robert, please send me anything addressed to him."

*This* is the concept of a Trusted Compute Base.

=
We should all be deeply worried that the integrity of Signal, WhatsApp= , etc, all rely upon confirmatory SMSes, but that's outside the scope o= f this standard.


In shor= t: the matter of "identity" is not obligated to extend beyond the= consistent and defined concept of an "end" / participant.=C2=A0 = As such, it falls out of scope.
That said, I am wondering whether= it would be useful to add a wishlist of RFC2119 "optional" featu= res, like optional PIN-lockdown for identity, where the platform would bene= fit=C2=A0from it. Maybe this could be one such?

Agr= eed, I really wouldn=E2=80=99t consider anything beyond the cryptographic i= dentity of an endpoint. Anything else is vendor-specific as you say.
<= /div>

Concur.


=

If rubber-stamping some of FB=E2=80= =99s poorer decisions with that draft is a desired goal, it changes the opt= ics quite a bit.=C2=A0
draft-knodel-e2ee-definition-01 has a much= higher degree of independence.

That's a tragic=C2=A0strawman; to repeat, the goal is to provide= a metric for judging the "minimally viable product behaviour" fo= r something to be worthy of being called "end-to-end secure"; it&= #39;s also short, and measurable against an implementation.

<= /div>

=
I was more thinking about the aut= hentication on a cryptographic level between =E2=80=9Cends=E2=80=9D. The us= er-level identifier is a whole other dimension (and probably out-of-scope).=

So, notification regarding sur= prise key changes, that sort of thing, perhaps as an addition to Section 3.= 2?
<= /blockquote>

It really falls in under =E2=80=9Cauthentication= =E2=80=9D in general.=C2=A0draft-knodel-e2ee-definition-01 has the nice con= cept of encrypted channels (although it contradicts the MLS notion of group= s a bit).
It should be clear to the user at the time of encryptio= n who the participants are

For= me, that's Sections 3.1 and 3.2.

=C2=A0
=
and there should be a way to verify the participants and their = cryptographic identity.

Yes, bu= t "verify them against... what?" [explanation follows below, afte= r joke]
=C2=A0
I know this pretty much excludes = iMessage. But if we want a definition of E2ESM that covers iMessage,
=

Rubber-stamping some of Apple's = decisions? [joke]
=C2=A0
we need to drop authent= ication completely and that=E2=80=99s definitely weak sauce.

The word "authentication" is = only meaningful within two - what shall we call them, "frames"?

1/ that the "participant" is-or-is-not pa= rt of the conversation; but that's the very *definition* of an end-to-e= nd-secure conversation: that "the only people who can read are partici= pants, and participants are those who can read", and it is the trusted= -compute-base of each participant-entity which defines their participation<= /div>

2/ that the "participant" somehow relate= s to some external identity framework, for instance a PKI or a Driving Lice= nse Number.

...however I suspect that you may mean= :

3/ that the "participant" is fully in = control of their devices and endpoints, and that one of them has not been s= ubverted or inserted by a malicious actor; but this (again) eventually requ= ires the E2ESM client to perform a security audit of the device that it'= ;s hosted on, etc.=C2=A0 This one is hard, and possibly illiberal/unwise.

I would like to check please whether I am correctly= reflecting your wants for authentication? 1, 2, 3, or other?
=C2=A0 =C2=A0 - Alec


--
--0000000000003a5d6d05c1f3ec0b-- From nobody Mon May 10 00:15:16 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 5A1053A09FE for ; Mon, 10 May 2021 00:15:15 -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, FREEMAIL_FROM=0.001, 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 (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 iDU7Q-xV5FXI for ; Mon, 10 May 2021 00:15:10 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 15AAA3A09FA for ; Mon, 10 May 2021 00:15:09 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id o27so14443788qkj.9 for ; Mon, 10 May 2021 00:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vBYoc8urDTmAK8Qnda8J9rti5lEUH3pOebwxlwa48s4=; b=OknEo1JBsOh8q0LPZ/qQQUaOCU8lLlbJk8sy399h84n2172eyJf8W0d0Q0DiiRu9Dj z8najuqccvMQxf2j2+BEQ0xBjm8zgBUCqiQ7QqvyZ1VmBH8waiWpegCoQJf7XS6+EJNI nh6Sfm+xUJ5p1daGwS8TttQE7YlV5/88EZPGAYMU9cvOxcMi2eP1BWVjO34TodLuiXT9 hgFpJyyI2ViV0k5Jtxc8KzEpqX9zNaSwQ4u8s+vuqoie43GnEX72AghcYmnMk4ygEddE T71XXAxZzMp6sxVqFJRBOjRJvJu5YeRapSwDj+nwh1rb9ATKk1nC3ryMmjNIez/6d+su IqDw== 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=vBYoc8urDTmAK8Qnda8J9rti5lEUH3pOebwxlwa48s4=; b=F/CX7ewOc/OJW7auiVj1DW9s0S4VcvycwRKTEuf/RN5vc8tt29OINrlC0qyrrffsJQ nJGkiIeSNcNuFtoYzNVGXRgIGOlthWzpZ6p+Z/I4ub7n6go2K8u/z5glfVrF2Y2moRNS MBl9oq05TWorWjcPJ5dljLqZJ9iZU2//rFZvjx0Qd6QcXGWomtHMyj+GSzYW2LiUh9iP ouBllIyOMxhwNox7AlHH8VHnPZpAa55N5OewJl+yRKnYTO+YkFKDjNcrYoaGShKlq9b4 OpFxL5UCqwO7xwK2SIg0Ih7bZfHzu0O20HPr5lHSshGW18/V8tDSZJ49TqIcOWKj9syh MmTQ== X-Gm-Message-State: AOAM5312ITbRNWqljdcebv1ftXv1F7dbsM2sOMAwgN0sWCyE4l30da+E qSkcQCgjbZHF5+UQWMtjZLTv1oTNmQYE1P4vl+M= X-Google-Smtp-Source: ABdhPJzlnbnmuO7NkGZ75AR35QlBqSGvgHgJ1XFmfKHj/2dCJ0OqMhB2gF4XDtoxYlpBEr00U5n/B1EmJWkEqnuDl44= X-Received: by 2002:a37:9c84:: with SMTP id f126mr21142146qke.240.1620630908012; Mon, 10 May 2021 00:15:08 -0700 (PDT) MIME-Version: 1.0 References: <937f9db9-d0e2-390e-0ef8-8dfa73e993b0@riseup.net> In-Reply-To: <937f9db9-d0e2-390e-0ef8-8dfa73e993b0@riseup.net> From: Alec Muffett Date: Mon, 10 May 2021 08:14:31 +0100 Message-ID: To: =?UTF-8?Q?Sof=C3=ADa_Celi?= Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000958d9305c1f489ae" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 07:15:15 -0000 --000000000000958d9305c1f489ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sof=C3=ADa! On Mon, 10 May 2021 at 00:41, Sof=C3=ADa Celi wrote: > > These are really interesting points. I see four points: > > * Future or past recipients of a conversation: it could be that a > conversation is read prior to the intended recipient, or after the > intended recipient. This is somewhat not cover in every day > applications, as someone else can get access to a device and read the > messages intended for a recipient. In those terms, I think this is > described as 'secure' for the network (and the intended recipient is the > device, then); but if a device is compromised, then the contents could > be potentially read by someone else. Exactly. This is the concept of the Trusted Computing Base, in a nutshell: https://en.wikipedia.org/wiki/Trusted_computing_base > A point to include here then is the > idea of 'disappearing messages', as a property for trying to avoid this. > They are very useful - I am a strong convert to them, although they are not obligatory for an end-to-end secure messaging network. > But if a message is read and disappeared prior to the actual "recipient" > reading it, then the purpose is also lost. Yes; or alternatively if they exist until "N" hours or days after being read on any given device, there are other models where their purpose is also lost. On that basis, it's up to the user to make wise choices and use of the features that exist *beyond* basic end-to-end security. * Messages read by something that is not a "human": this could be a bot > that is part of a conversation (but should it be?, if so, it should be > disclosed to the sender-s-, and potentially properly "authenticated") or > malware in the device itself. > If a "Bot" should be disclosed to a sender, should it also be disclosed that the user is using an assistive spellchecker app? Or an assistive keyboard app which may exfiltrate content to Chinese state authorities? Example of this latter debate: https://www.reddit.com/r/privacytoolsIO/comments/kzpxwt/opinions_on_naomi_w= u_signal_ime_vulnerability/ Hence why I believe that it is not tenable to pursue disclosures of anything beyond "these are the participants within this conversation, and the rest of the universe is outside". Or perhaps those "assistive apps" exist as backdoors, in which case: * Messages read by a backdoor or vulnerability: I think that if an > application has a backdoor (with the whole purpose of having it there to > read the contents) then it is not end-to-end encrypted. ...does this mean that anyone with a spellchecker (Grammarly: https://www.silicon.co.uk/security/grammar-extension-data-leak-flaw-228005) or chinese keyboard, is excluded from what being we would call "end-to-end secure"? The only resolution for this that I can see - that is even possible? - is for the participant to define their "trusted computing base". Hence this draft standard. > If someone or > something is added to the conversation, then it should be authenticated > and disclosed. > Strongly concur. > * Multiple devices: this could be better explained by stating that the > intended recipients could be multiple devices (these all have to be > authenticated to the conversation). > What if one device has several heads, such as "WhatsAppForWeb"? Should those be disclosed? Should a victim of domestic abuse attempting to escape - or: a philanderer - be "outed" as having a second phone? As using a secret laptop? - alec --=20 https://alecmuffett.com/about --000000000000958d9305c1f489ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi= Sof=C3=ADa!

On Mon, 10 May 2021 at 00:41, Sof=C3=ADa Celi <cherenkov@riseup.net> wrote:

These are really interesting points. I see four points:

* Future or past recipients of a conversation: it could be that a
conversation is read prior to the intended recipient, or after the
intended recipient. This is somewhat not cover in every day
applications, as someone else can get access to a device and read the
messages intended for a recipient. In those terms, I think this is
described as 'secure' for the network (and the intended recipient i= s the
device, then); but if a device is compromised, then the contents could
be potentially read by someone else.

Exact= ly.=C2=A0 This is the concept of the Trusted Computing Base, in a nutshell:= =C2=A0http= s://en.wikipedia.org/wiki/Trusted_computing_base


=C2=A0
A point to include here then= is the
idea of 'disappearing messages', as a property for trying to avoid = this.

They are very useful - I am a str= ong convert to them, although they are not obligatory for an end-to-end sec= ure messaging network.

=C2=A0
But if a message is read and disappeared prior to the actual "recipien= t"
reading it, then the purpose is also lost.

= Yes; or alternatively if they exist until "N" hours or days after= being read on any given device, there are other models where their purpose= is also lost.

On that basis, it's up to the u= ser to make wise choices and use of the features that exist *beyond* basic = end-to-end security.


* Messages read by something that is not a "human": this could be= a bot
that is part of a conversation (but should it be?, if so, it should be
disclosed to the sender-s-, and potentially properly "authenticated&qu= ot;) or
malware in the device itself.

If a &quo= t;Bot" should be disclosed to a sender, should it also be disclosed th= at the user is using an assistive spellchecker app?

Or an assistive keyboard app which may exfiltrate content to Chinese stat= e authorities?

Example of this latter debate: https://www.reddit.com/r/privacytoolsIO= /comments/kzpxwt/opinions_on_naomi_wu_signal_ime_vulnerability/

Hence why I believe that it is not tenable to pursue = disclosures of anything beyond "these are the participants within this= conversation, and the rest of the universe is outside".
Or perhaps those "assistive apps" exist as backdoors,= in which case:

* Messages read by a backdoor or vulnerability: I think that if an
application has a backdoor (with the whole purpose of having it there to read the contents) then it is not end-to-end encrypted.
<= br>
...does this mean that anyone with a spellchecker (Grammarly:= https://www.silicon.co.uk/security/grammar-extension-data-leak= -flaw-228005) or chinese keyboard, is excluded from what being we would= call "end-to-end secure"?

The only reso= lution for this that I can see - that is even possible? - is for the partic= ipant to define their "trusted computing base".=C2=A0 Hence this = draft standard.
=C2=A0
If someone or
something is added to the conversation, then it should be authenticated
and disclosed.

Strongly concur.

=C2=A0
* Multiple devices: this could be better explained by stating that the
intended recipients could be multiple devices (these all have to be
authenticated to the conversation).

Wha= t if one device has several heads, such as "WhatsAppForWeb"?=C2= =A0 Should those be disclosed?

Should a victim of = domestic abuse attempting to escape - or: a philanderer - be "outed&qu= ot; as having a second phone?=C2=A0 As using a secret laptop?
=C2=A0 =C2=A0 =C2=A0- alec

--
--000000000000958d9305c1f489ae-- From nobody Mon May 10 06:45:38 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 82ACD3A1D6A for ; Mon, 10 May 2021 06:45:36 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=cdt.org 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 KiJjxrvrUhPt for ; Mon, 10 May 2021 06:45:31 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 C75673A1D66 for ; Mon, 10 May 2021 06:45:30 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id c10so2087844qtx.10 for ; Mon, 10 May 2021 06:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=9zCoRpwL7pqtn90GiBQlCPvh2oeBiohmTMClIY49t9Q=; b=YcYnu2yzFdwumyQIP83n1FhlNUPUjnL6RsMFQ6+OPbF2NsB2bNqY6XDHa55V86xKXn qdQnA73L+Jzf/PHyGpuUOYlHjNTROhYp8STVMo6d16wDvJrTJFG+lVDnt6SGSj1M6pOT 0rTCoHi+1NzaW9kqzryKMoOFHcgAZWoXNiGrU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=9zCoRpwL7pqtn90GiBQlCPvh2oeBiohmTMClIY49t9Q=; b=qoj8yhyZTF+iwkzx71mQT/Ic5Z1DLCTPHDuWZQ8hTgaj8NiYOt6yu77R10XpxvStmB m1B6FgfEsM/xuFlcJIWbqDUPK6K4H6DtPh1FWsG9f8GUhuhDx5iWveTVxTuFBKxqPYrP 6Xqf6Evoj0o1pi7k7bX8XzE+t3UztXMJh2JrssbdvsrrBYdh3vpbXhIMQM8XOPc6BsSk ye6DQY6BuvXZ1mEsoviEF7xRNQPna/LSH1fgBoVvpvx6uUrPiLmtX3F/Vhaf4vQGUy0/ 4zCP3X1+yZHGXROgv9SIVp8AALYmnj//1E3NmMneSvUWTkl0+pitpBPUWaLw/cePAOyv HsGQ== X-Gm-Message-State: AOAM531vFOXsYdXxvg6Q2BLdRT+DIpuxrMXyi17miRYx0SpX4/8tPXnR CaKF0E0hMhux25yIP6TH7AtZ0g== X-Google-Smtp-Source: ABdhPJwoT1K6XCIzsrXsxLsETRTFwFn0ph2ppWYXkya9O1F4ZuZT8SavOxfDJ/eoh/wn17KsXvpPZw== X-Received: by 2002:ac8:7947:: with SMTP id r7mr21951414qtt.104.1620654329102; Mon, 10 May 2021 06:45:29 -0700 (PDT) Received: from ?IPV6:2601:140:8680:4c40:3161:a834:2760:43ad? ([2601:140:8680:4c40:3161:a834:2760:43ad]) by smtp.gmail.com with UTF8SMTPSA id o189sm11191800qkd.60.2021.05.10.06.45.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 06:45:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------JdIUG0JBbir4GtsjGDky0Ua5" Message-ID: Date: Mon, 10 May 2021 09:45:27 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Raphael Robert , Alec Muffett Cc: Messaging Layer Security WG References: From: Mallory Knodel In-Reply-To: Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 13:45:37 -0000 This is a multi-part message in MIME format. --------------JdIUG0JBbir4GtsjGDky0Ua5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 5/7/21 4:43 PM, Raphael Robert wrote: > > Regarding the definition of an “end”, > draft-knodel-e2ee-definition-01 has section 2.1, 4.3 & 4.5. Your draft > has section 4.1 & 5. In my mind both drafts could be a bit more > assertive here. I like that you introduce different types of > participants. I think that point is particularly important, because if > the participants are not just “humans with a messenger app”, it > begs the question who has control over the messages that were received > by that participant. Other humans who are not part of the > “conversation”? Future participants of the “conversation”? A > machine that will scan the message content and act on it? In the end > this defines what “confidentiality” really means, besides the > academic definition. We just added a new section to accommodate for this. It's particularly important because if you look at the various attempts to modify e2ee such that third parties can know things about the messages, there is play with the notion of end. Client-side scanning is a real proposal and putting that feature within an app would be awful, but better than putting it in the OS, for example. But we still need to improve this section. I would really love for someone to propose some text changes here to make it as strong as it can be. -Mallory > To be more precise, I would add to the definition of participants, > that all participants must know exactly the type of other > participants. It matters whether participant Eve is a bot or a human. > This would be an actionable definition in order to refute that a > system with ghost user is still e2e secure. If a participant lies > about the kind of participant they are, this would constitute a breach > and contradict the end user expectations. > >> On 7. May 2021, at 18:22, Alec Muffett wrote: >> >> Heya! >> >> All references in the attached, are against: >> >> URL: >> https://github.com/alecmuffett/draft-muffett-end-to-end-secure-messaging/blob/157627c713f81a27c9528c87b6e58111ba54e485/text/draft-muffett-end-to-end-secure-messaging.txt >> >> ...which should be constant even if the document is subsequently updated. >> >> >> On Fri, 7 May 2021 at 15:50, Raphael Robert >> wrote: >> >> >> I agree that the two drafts a quite different. Yours is much more >> specific in certain aspects. And this is where it also gets tricky :) >> Dave has a good point that it might not be straight forward to >> have a “one-size-fits-all” model. >> >> >> This is not a one-size-fits-all model of "security".  It's a >> definition of end-to-end secure messengers". >> >> It is a formalisation of the following argument: >> >> /1/ in an "end-to-end secure messenger", there are "ends"; this flows >> from the expression >> >> / >> /2/ messages are sent from "ends", to "ends", and a sequence of >> messages constitutes a "conversation" (obvious?) >> >> / >> /3/ for each message, the set of "ends" is "frozen" upon "send" >> (*3.3*) to the current & wholly visible set of conversation "ends" >> (*3.2*) ; if it were not frozen thusly we would lack forward secrecy >> and simply be reinventing Yahoo Messenger, which wasn't end-to-end >> secure, hence we can't be doing that >> >> / >> /4/ no "end" may have privileged access to content, (*3.1* - >> participating as an 'end' does not somehow bestow exceptional access >> to content, e.g by *also* being a database administrator) >> >> / >> /5/ no "non-end" may have any access to content (*3.3.2*) >> >> / >> /6/ it requires the consent ("intentional action") of an existing >> member, to add more "ends" to a conversation (*3.4*) / >> / >> / >> /7/ the software should help ends understand where they are logged-in >> (*3.5*) >> >> /That's it.  That's the whole specification, although it's padded >> with stuff like "indistinguishability" to disambiguate questions like >> /"what if we just leak a *little* bit of the content?"/ and /"what >> about conversation metadata?"./ >> >> Everything extrapolates from the term /"end to end secure >> messenger"/, and I would be interested to hear examples of >> purportedly "end-to-end secure messengers" which don't already meet >> it.  I would like to know why they do not? > > I think what both drafts don’t fully cover yet is the fact that end > users have expectations. For me everything extrapolates from the > “set of typical end user expectations”. The software and its > documentation should make it as clear as possible to the user how the > system works, who can potentially have access to messages (e.g. a LE > ghost user, a recording bot, only other humans that can be > transparently authenticated out-of-band). > >> >> >> draft-knodel-e2ee-definition-00 is much broader could certainly >> be expanded to include more precise definitions to illustrate the >> more abstract notions. >> >> >> And there's the rub; the point of this is to avoid abstract notions, >> because we need a concrete definition in order to judge what is meant >> by "end to end secure messenger" - not to mention to measure the >> features which some states propose be drilled into them. >> >> >> >> Just having fixed set of precise criteria sounds nice in terms of >> simplicity but might simply prove to be insufficient to capture >> all valid use cases. >> >> >> I welcome examples of use-cases where this definition falls short. > > I don’t have a good counter-example at hand, but that doesn’t mean > it doesn’t exist. I guess it would be great if we had links to > existing literature, or comparative analysis of past and current e2e > secure systems to corroborate the idea. > >> >> Notably this definition *also* works for Ricochet which uses Tor >> Onions and point-to-point communication to provide end-to-end >> security, without even a hint of content encryption. It turns out >> that it is not always necessary to use content encryption (e.g. >> Signal Protocol) to implement a "closed distribution list" for a >> sequence of messages - which is all that "end to end security" >> is, in the most fundamental sense.  The technologies have to adapt >> in order to address the underlying architecture: client-server, >> direct peer-to-peer, mesh, etc. >> >> >> In either case, having a document that can be used as a checklist >> to determine with absolute certainty whether a system is >> end-to-end-encrypted or not sound like a dangerous endeavour. >> >> >> I would welcome examples of the dangers. > > In a way this is what Dave pointed out earlier. There could be both > false positives and false negatives. > > False positive: A system that works in a way that doesn’t contradict > the definitions of the draft, but that contradicts the typical end > user expectations. > > False negative: A system that contradicts one or more definitions of > the draft (most likely because they are too restrictive) but still > meets the typical end user expectations. > > False positives are downright dangerous for end users, while false > negatives might hinder the adoption of an otherwise great system. > >> >> >> Given the complexity of the subject, the answer cannot always be >> binary. >> >> >> Certainly it cannot *yet* be binary, for want of a metric to measure >> against. > > My hunch here is that either draft could evolve into something that > — when used as benchmark — gives a high degree of confidence > whether a system is e2e secure or not. > In a way it would be like a legal document: it tries to be as precise > as possible, but there might still be the need for interpretation by > experts in the field (including the possibility of disagreement). > >> >> >> When you say “ill-defined, but widely used terminology”, what >> exactly are you referring to? >> >> >> "End"; I would be interested to hear what your definition of this >> term is, and so we might compare it to Section *4.1* and the >> explanatory note in Section *5*, >> >> >> Statements in the press? What exact problem needs fixing here? >> >> >> The issue is that "end to end secure messenger" has no definition >> against which we can measure the features of a given software >> solution.  This I-D offers one. >> >> And then, when the UK Government (or other) propose that "...adding a >> 'Ghost' will not break end-to-end security", we can precisely measure >> the impact of, and rebut, that statement. > > I understand you want something actionable with punchy definitions and > I agree that it would be a useful thing to have. For it to become > that, it needs consensus from the wider community. Not only because > that’s the idea behind IETF, but also because it carries more weight > in the end. With that in mind, it would be great if some more folks > would chime in so that this is not only two party conversation with > only two opinions. > What I’m also not sure about is whether the two drafts will be > sufficiently different in the end, in the sense that they would cater > to different audiences. They are de facto different now, but maybe it > would be worth trying to bring them together? I am an author of > neither, so I can really only float the idea. > > Another aspect that is at least partially covered in > draft-knodel-e2ee-definition-01 is that of authentication. I think > this plays a big role when it comes to “ghost users” and > transparency of participants. It’s also something that is still very > much an area of exploration for secure messengers. There is room for > improvement across the board and in that sense the drafts could serve > as a guideline for existing and future messengers. > > Lastly I also would like to mention the MLS architecture draft > (https://tools.ietf.org/html/draft-ietf-mls-architecture-06) that > touches on a lot of these subjects. While its purpose is a different > one, it goes strictly beyond the scope of MLS and highlights aspects > that are relevant for many secure messaging systems. > > I hope the above makes it a bit more clear what I maybe failed to > express earlier. > > Raphael > >> >> >> Having a bit more context on that would certainly help with the >> overall assessment. Maybe we are just talking past each other. >> >> >> I hope this helps. >> >>     - alec >> >> -- >> https://alecmuffett.com/about >> > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------JdIUG0JBbir4GtsjGDky0Ua5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi,

On 5/7/21 4:43 PM, Raphael Robert wrote:

Regarding the definition of an “end”, draft-knodel-e2ee-definition-01 has section 2.1, 4.3 & 4.5. Your draft has section 4.1 & 5. In my mind both drafts could be a bit more assertive here. I like that you introduce different types of participants. I think that point is particularly important, because if the participants are not just “humans with a messenger app”, it begs the question who has control over the messages that were received by that participant. Other humans who are not part of the “conversation”? Future participants of the “conversation”? A machine that will scan the message content and act on it? In the end this defines what “confidentiality” really means, besides the academic definition.

We just added a new section to accommodate for this. It's particularly important because if you look at the various attempts to modify e2ee such that third parties can know things about the messages, there is play with the notion of end. Client-side scanning is a real proposal and putting that feature within an app would be awful, but better than putting it in the OS, for example.

But we still need to improve this section. I would really love for someone to propose some text changes here to make it as strong as it can be.

-Mallory

To be more precise, I would add to the definition of participants, that all participants must know exactly the type of other participants. It matters whether participant Eve is a bot or a human. This would be an actionable definition in order to refute that a system with ghost user is still e2e secure. If a participant lies about the kind of participant they are, this would constitute a breach and contradict the end user expectations.

On 7. May 2021, at 18:22, Alec Muffett <alec.muffett@gmail.com> wrote:

Heya!

All references in the attached, are against: 


...which should be constant even if the document is subsequently updated.


On Fri, 7 May 2021 at 15:50, Raphael Robert <ietf@raphaelrobert.com> wrote:

I agree that the two drafts a quite different. Yours is much more specific in certain aspects. And this is where it also gets tricky :)
Dave has a good point that it might not be straight forward to have a “one-size-fits-all” model. 

This is not a one-size-fits-all model of "security".  It's a definition of end-to-end secure messengers".  

It is a formalisation of the following argument:

1/ in an "end-to-end secure messenger", there are "ends"; this flows from the expression

2/ messages are sent from "ends", to "ends", and a sequence of messages constitutes a "conversation" (obvious?)

3/ for each message, the set of "ends" is "frozen" upon "send" (3.3) to the current & wholly visible set of conversation "ends" (3.2) ; if it were not frozen thusly we would lack forward secrecy and simply be reinventing Yahoo Messenger, which wasn't end-to-end secure, hence we can't be doing that

4/ no "end" may have privileged access to content, (3.1 - participating as an 'end' does not somehow bestow exceptional access to content, e.g by also being a database administrator)

5/ no "non-end" may have any access to content (3.3.2)

6/ it requires the consent ("intentional action") of an existing member, to add more "ends" to a conversation (3.4

7/ the software should help ends understand where they are logged-in (3.5)

That's it.  That's the whole specification, although it's padded with stuff like "indistinguishability" to disambiguate questions like "what if we just leak a *little* bit of the content?" and "what about conversation metadata?". 

Everything extrapolates from the term "end to end secure messenger", and I would be interested to hear examples of purportedly "end-to-end secure messengers" which don't already meet it.  I would like to know why they do not?

I think what both drafts don’t fully cover yet is the fact that end users have expectations. For me everything extrapolates from the “set of typical end user expectations”. The software and its documentation should make it as clear as possible to the user how the system works, who can potentially have access to messages (e.g. a LE ghost user, a recording bot, only other humans that can be transparently authenticated out-of-band).



draft-knodel-e2ee-definition-00 is much broader could certainly be expanded to include more precise definitions to illustrate the more abstract notions.

And there's the rub; the point of this is to avoid abstract notions, because we need a concrete definition in order to judge what is meant by "end to end secure messenger" - not to mention to measure the features which some states propose be drilled into them.

 
Just having fixed set of precise criteria sounds nice in terms of simplicity but might simply prove to be insufficient to capture all valid use cases.

I welcome examples of use-cases where this definition falls short.

I don’t have a good counter-example at hand, but that doesn’t mean it doesn’t exist. I guess it would be great if we had links to existing literature, or comparative analysis of past and current e2e secure systems to corroborate the idea.


Notably this definition also works for Ricochet which uses Tor Onions and point-to-point communication to provide end-to-end security, without even a hint of content encryption. It turns out that it is not always necessary to use content encryption (e.g. Signal Protocol) to implement a "closed distribution list" for a sequence of messages - which is all that "end to end security" is, in the most fundamental sense.  The technologies have to adapt in order to address the underlying architecture: client-server, direct peer-to-peer, mesh, etc.


In either case, having a document that can be used as a checklist to determine with absolute certainty whether a system is end-to-end-encrypted or not sound like a dangerous endeavour.

I would welcome examples of the dangers.

In a way this is what Dave pointed out earlier. There could be both false positives and false negatives.

False positive: A system that works in a way that doesn’t contradict the definitions of the draft, but that contradicts the typical end user expectations.

False negative: A system that contradicts one or more definitions of the draft (most likely because they are too restrictive) but still meets the typical end user expectations.

False positives are downright dangerous for end users, while false negatives might hinder the adoption of an otherwise great system.

 
Given the complexity of the subject, the answer cannot always be binary.

Certainly it cannot yet be binary, for want of a metric to measure against.

My hunch here is that either draft could evolve into something that — when used as benchmark — gives a high degree of confidence whether a system is e2e secure or not.
In a way it would be like a legal document: it tries to be as precise as possible, but there might still be the need for interpretation by experts in the field (including the possibility of disagreement).

 
When you say “ill-defined, but widely used terminology”, what exactly are you referring to?

"End"; I would be interested to hear what your definition of this term is, and so we might compare it to Section 4.1 and the explanatory note in Section 5,


Statements in the press? What exact problem needs fixing here?

The issue is that "end to end secure messenger" has no definition against which we can measure the features of a given software solution.  This I-D offers one.

And then, when the UK Government (or other) propose that "...adding a 'Ghost' will not break end-to-end security", we can precisely measure the impact of, and rebut, that statement.

I understand you want something actionable with punchy definitions and I agree that it would be a useful thing to have. For it to become that, it needs consensus from the wider community. Not only because that’s the idea behind IETF, but also because it carries more weight in the end. With that in mind, it would be great if some more folks would chime in so that this is not only two party conversation with only two opinions.
What I’m also not sure about is whether the two drafts will be sufficiently different in the end, in the sense that they would cater to different audiences. They are de facto different now, but maybe it would be worth trying to bring them together? I am an author of neither, so I can really only float the idea.

Another aspect that is at least partially covered in draft-knodel-e2ee-definition-01 is that of authentication. I think this plays a big role when it comes to “ghost users” and transparency of participants. It’s also something that is still very much an area of exploration for secure messengers. There is room for improvement across the board and in that sense the drafts could serve as a guideline for existing and future messengers.

Lastly I also would like to mention the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-architecture-06) that touches on a lot of these subjects. While its purpose is a different one, it goes strictly beyond the scope of MLS and highlights aspects that are relevant for many secure messaging systems.

I hope the above makes it a bit more clear what I maybe failed to express earlier.

Raphael



Having a bit more context on that would certainly help with the overall assessment. Maybe we are just talking past each other.

I hope this helps.

    - alec

--


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------JdIUG0JBbir4GtsjGDky0Ua5-- From nobody Mon May 10 07:46:53 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 4BAA93A1EF6 for ; Mon, 10 May 2021 07:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 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_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.273] autolearn=no 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 3Hv8AVL9c9Io for ; Mon, 10 May 2021 07:46:46 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 BDC5D3A1F72 for ; Mon, 10 May 2021 07:46:46 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id l129so15518601qke.8 for ; Mon, 10 May 2021 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KiiOa6nd/vOHihbGTf7KNAR9NwoIuL1OPdIFeMTzX7I=; b=UINqCg3C4ywbCix6cjo19Nh9iYlIBnNss211OcKFTemwQeuhfGYHx+Ix2ajQkbkod1 FMQ6NZjMAgjTymHut/lJ2TgL0K5lc3wCeuqtUm+GvT+9rp/wMwbqN6KViPbuLe7l15Yn RkDS1NcUunf7IiI4v1wtlvutZQv5btCjR5XMD38FSwNbKHfFNsLA2REvNoIUCMlsi+U/ 0Muo/EyIvCD8PtrKvg76RN5V8nh/rlRBgKjLVybOZCTYfAG+BFFNqKp1p3c3Y8RF4fq7 5WhV7Y9hRyhCa+DhnPYyl7rByLnOH6Trp0h+06rPGggplFdAgecFUeo/P95PDLBEEnnW GByA== 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=KiiOa6nd/vOHihbGTf7KNAR9NwoIuL1OPdIFeMTzX7I=; b=fTewD0Cx9gnUyw3TAU3tjoltz1/prXAiOlEgAOiBYTwsG07QiRp4hKuzV8+edXPy+P mzDAz95sptHINmT9rhBlVtjiNKQpnHCbXkN1viTnlPxlfzAGQUPSyXAy225NXZKu3otb NSKEFYITr68gBSTqSEfgna6+fk/eoicGX1mp9MKpipgpNA3qRO1OJRST30dpqWb80GUL D6VTen6OIPBXafvZYEHkb33vRdyZa7vAckNmK+I2gOp+QoazXYS0CKFYv6RTZgeaoBGz P0OEke6KQycSu3qtVevcRTp6mkN3kWRuiQI6J4zeyaTiW0zRKEZYB8TQlGPACwFBm4A5 uzRw== X-Gm-Message-State: AOAM531iCg2M1ix5p6aMg/VT4NMutLIsRhK7EtybwPCR0B1lCCcEBg5N 6VWH719VuiihA9msgoZsBov+0diC1qIa59yc7f01pqGtMTkMGw== X-Google-Smtp-Source: ABdhPJykNQ1o+W8UU9lL309czlBIZKDoEAV5pbgAt3ZUmSfjPKulmUepDGaLhbeYXXNNef7GApQ1Egasf4T55KjKvvk= X-Received: by 2002:a05:620a:127b:: with SMTP id b27mr22241046qkl.104.1620658005060; Mon, 10 May 2021 07:46:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Mon, 10 May 2021 15:46:08 +0100 Message-ID: To: Mallory Knodel Cc: Raphael Robert , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000b1bc1805c1fad84b" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 14:46:53 -0000 --000000000000b1bc1805c1fad84b Content-Type: text/plain; charset="UTF-8" On Mon, 10 May 2021 at 14:45, Mallory Knodel wrote: > We just added a new section to accommodate for this. It's particularly > important because if you look at the various attempts to modify e2ee such > that third parties can know things about the messages, there is play with > the notion of end. Client-side scanning is a real proposal and putting that > feature within an app would be awful, but better than putting it in the OS, > for example. > > But we still need to improve this section. I would really love for someone > to propose some text changes here to make it as strong as it can be. > Hey Mallory! I would be delighted to help your effort, too - but to do that I would need to better understand what the intention or threat model is - what it is meant to be "strong" against? My work is focused upon building a metric which can be used to measure any communications service which claims to offer end-to-end security, whether or not the service uses content encryption or alternately strong direct peer-to-peer transport encryption. My goal is to hold yardstricks up against applications and services and provide a "yes/no" regarding whether the service is end-to-end secure; and also to speak to whether a proposed government intervention would cause it to no longer be "end-to-end secure". I've been working on this blindly, but having finally circulated this draft I am pleased to learn that the concepts line up quite well with a 2011 paper from David Clark & Marjory Blumenthal: *"The End-to-End Argument and Application Design: The Role of Trust":* https://www.repository.law.indiana.edu/cgi/viewcontent.cgi?article=1585&context=fclj ...and also an earlier (and less relevant) work by the same: *"Rethinking the design of the Internet: The end to end arguments vs. the brave new world"* https://cyberlaw.stanford.edu/e2e/papers/TPRC-Clark-Blumenthal.pdf Quoting the former: *The original paper provides a hint as to the importance of this distinction. Using a telephone call as an example, it points out that the ultimate end points are not the computers, but the humans they serve.8 As an illustration of human-level end-to-end error recovery, one person might say to another: "[E]xcuse me, someone dropped a glass. Would you please say that again?"9 The humans are the prime movers in the activity, the ultimate end points. The computers are just their agents in carrying out this objective.* ...and... *There is an explicit assumption in the original paper that the communications subsystem is unreliable.'3 This assumption is justified (both then and now) for the reasons listed above. But there is an implicit assumption that the end node is reliable and trustworthy. The example of "careful file transfer" in the original paper 4 assumes that the end node can compute a checksum reliably and perform other actions designed to compensate for the unreliability of the communications. It also assumes, implicitly, that the two ends trust each other. * ...and... *The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at apoint where it can be trusted to do its job in a reliable and trustworthy fashion. Trust, in this context, should be determined by the ultimate end points-the principals that use the application to fulfill their purposes. Because the locus of trust is naturally at the ends, where the various principals are found, "trust-to-trust" is preferable to "end-to-end" from the point of view of the principals, because it more directly invites the important question of "trusted by whom?" That question, in turn, relates to questions that implicate application design, notably "who gets to choose which service is used?" or "which parts of an application are in which service modules?" Answers to these questions illuminate who controls what aspects of an application.* ...all of which resonate extraordinarily loudly with the thinking in my draft. Dan Geer pointed me at them this morning, and I am still inhaling the papers excitedly. I am particularly enamoured of the *"trust-to-trust is preferable to end-to-end"* concept, because it so neatly encapsulates the issues that I want to communicate and build upon: that each {participant or end} is a little universe of self-trust, and that the purpose of *end-to-end secure messaging* is to build a virtual, private, tamperproof "series of tubes" between them, irrespective of implementation technology. :-) In comparison draft-knodel-e2ee-definition - according to the introduction - "defines end-to-end encryption (E2EE) using three different dimensions that together comprise a full definition of E2EE, which can be applied in a variety of contexts", which is a different goal to my "metricate end-to-end"; I am reading it as a sequence of features, definitions and user-expectations, but am not yet seeing what is meant to happen when those expectations are broken, and I don't know if you're interested in seeing that suggested and/or against whom that sanction will need to stand? - Alec -- https://alecmuffett.com/about --000000000000b1bc1805c1fad84b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 10 May 2021 at 14:45, Mallory = Knodel <mknodel@cdt.org> wrote= :
=20 =20 =20

We just added a new section to accommodate for this. It's particularly important because if you look at the various attempts to modify e2ee such that third parties can know things about the messages, there is play with the notion of end. Client-side scanning is a real proposal and putting that feature within an app would be awful, but better than putting it in the OS, for example.

But we still need to improve this section. I would really love for someone to propose some text changes here to make it as strong as it can be.


Hey Mallory!<= /div>

I would be delighted to help your effort, too - bu= t to do that I would need to better understand what the intention or threat= model is - what it is meant to be "strong" against?
My work is focused upon building a metric which can be used to= measure any communications service which claims to offer end-to-end securi= ty, whether or not the service uses content encryption or alternately stron= g direct peer-to-peer transport encryption. My goal is to hold yardstricks = up against applications and services and provide a "yes/no" regar= ding whether the service is end-to-end secure; and also to speak to whether= a proposed=C2=A0government intervention would cause it to no longer be &qu= ot;end-to-end secure".

I've been working = on this blindly, but having finally circulated this draft I am pleased to l= earn that the concepts line up quite well with a 2011 paper from David Clar= k & Marjory Blumenthal:=C2=A0

"The End= -to-End Argument and Application Design: The Role of Trust":
=

=
...and also an earlier (and less relevant) work by the same:

"Rethinking the design of the Internet: = The end to end arguments vs. the brave new world"

Quoting the former:

<= div>The original paper provides a hint as to the importance of this dist= inction. Using a telephone call as an example, it points out that the ultim= ate end points are not the computers, but the humans they serve.8 As an ill= ustration of human-level end-to-end error recovery, one person might say to= another: "[E]xcuse me, someone dropped a glass. Would you please say = that again?"9 The humans are the prime movers in the activity, the ult= imate end points. The computers are just their agents in carrying out this = objective.

...and...

There i= s an explicit assumption in the original paper that the communications subs= ystem is unreliable.'3 This assumption is justified (both then and now)= for the reasons listed above. But there is an implicit assumption that the= end node is reliable and trustworthy. The example of "careful file tr= ansfer" in the original paper 4 assumes that the end node can compute = a checksum reliably and perform other actions designed to compensate for th= e unreliability of the communications. It also assumes, implicitly, that th= e two ends trust each other.

...and...
The function in question can completely and correctly = be implemented only with the knowledge and help of the application standing= at apoint where it can be trusted to do its job in a reliable and trustwor= thy fashion. Trust, in this context, should be determined by the ultimate e= nd points-the principals that use the application to fulfill their purposes= . Because the locus of trust is naturally at the ends, where the various pr= incipals are found, "trust-to-trust" is preferable to "end-t= o-end" from the point of view of the principals, because it more direc= tly invites the important question of "trusted by whom?" That que= stion, in turn, relates to questions that implicate application design, not= ably "who gets to choose which service is used?" or "which p= arts of an application are in which service modules?" Answers to these= questions illuminate who controls what aspects of an application.

...all of which resonate extraordinarily loudly = with the thinking in my=C2=A0draft. Dan Geer pointed me at them this mornin= g, and I am still inhaling the papers excitedly.=C2=A0 I am particularly en= amoured of the "trust-to-trust is preferable to end-to-end"=C2=A0concept,=C2=A0because it so neatly encapsulates the issues that I wa= nt to communicate and build upon: that each {participant or end} is a littl= e universe of self-trust, and that the purpose of end-to-end secure mess= aging is to build a virtual, private, tamperproof "series of tubes= " between them, irrespective of implementation technology. :-)


In comparison draft-knodel-e2ee-definition - ac= cording to the introduction - "defines end-to-end encryption (E2EE) us= ing three different dimensions that together comprise a full definition of = E2EE, which can be applied in a variety of contexts", which is a diffe= rent goal to my "metricate end-to-end"; I am reading it as a sequ= ence of features, definitions and user-expectations, but am not yet seeing = what is meant to happen when those expectations are broken, and I don't= know if you're interested in seeing that suggested and/or against whom= that sanction will need to stand?
=C2=A0 =C2=A0 - Alec
=C2=A0
--
=
--000000000000b1bc1805c1fad84b-- From nobody Mon May 10 09:01:43 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 5D6BA3A21D9 for ; Mon, 10 May 2021 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=cdt.org 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 y-g3h8mXXogq for ; Mon, 10 May 2021 09:01:36 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 B1B803A21D6 for ; Mon, 10 May 2021 09:01:36 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id c20so4822998qkm.3 for ; Mon, 10 May 2021 09:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to; bh=GfU+YTPFu906on5PaPcjrrv8VZpxUy/90TrTUgpyJkI=; b=MmVriVO3Nxx1cmY/ivbSjObp/CSTn27YPaiKV0J2Yn80Wp7ptbBpQknKJAUMRRNvSR wsKY0CM4MX2oh/xZMJXh2dq7tcFnWVk3975Hte52FvgZCXXPeefk7wS73gjFmg+N4MJf B3NAjwrf0mP8pjfEOUvCgDGqSX7hUcsi8JtbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to; bh=GfU+YTPFu906on5PaPcjrrv8VZpxUy/90TrTUgpyJkI=; b=fREveJN9V4OyFTBc6H2Vw3MdOatc0JxNc+kuLKPIdVf6EkXof+IaIl6IfXz+A6qTki 6ykqVFWebVw2128ZCFk/NzMa2UWilDcXY9gAi/imzgDmMLfCGUWnnK2H3k5lPQVQqo8B j/xWx5Xxnwws20XKS1lvvUKnyaI8C8TMGHEXMxoNLbY8JvKj5GFqAEg8YCYakHQfXCtS oKfDAvYICUuZ4nBxTQY574o1gXsudUCu4Ugy1UtH9FXqMeZ3X4ETDc1ATk4xY94CbVcV KAKahOxOrR35aL0VjVMnFEtf5I8sBE5otC00z0OGPdLvzeggBMcYBVRctMFMxHV+Gx/d 2TAQ== X-Gm-Message-State: AOAM531ej7VcfiKC5oB+qPeQBhWTeMDyqrO+b15qmlN9ihXRaRhlcJ6y MnoQEHthUrMmUDOUynCsaCI7NXHhahz+MLDC X-Google-Smtp-Source: ABdhPJz5DTIv/05Y0VYQn8MkYey8+pDBOuTy7rjTl7swYHFG/HnW5OqBdySlqBd9QcdAUblxGh4PqQ== X-Received: by 2002:a37:9547:: with SMTP id x68mr22952969qkd.474.1620662494610; Mon, 10 May 2021 09:01:34 -0700 (PDT) Received: from ?IPV6:2601:140:8680:4c40:3161:a834:2760:43ad? ([2601:140:8680:4c40:3161:a834:2760:43ad]) by smtp.gmail.com with UTF8SMTPSA id m10sm10025441qtq.83.2021.05.10.09.01.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 09:01:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------zEuoJg0Ywb5rUbXlL0m0DuXY" Message-ID: Date: Mon, 10 May 2021 12:01:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: mls@ietf.org References: From: Mallory Knodel In-Reply-To: Archived-At: Subject: [MLS] secure & end Re: Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 16:01:42 -0000 This is a multi-part message in MIME format. --------------zEuoJg0Ywb5rUbXlL0m0DuXY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, On 5/7/21 9:49 AM, Alec Muffett wrote: > > The primary objection I have here is that people will make the > assumption that any system that does not conform to your arbitrary > definition of "Secure" is, by inference, "Insecure". > > > That *is* an objection, however it pivots on the assertion that I am > somehow attempting to define "secure" - but I am not. Alec, I thought I'd respond to your points about adversaries and security in my draft by picking up on this theme further up in the thread on your draft. This highlights a fundamental difference in approach. And there are two ways I look at it: The first is how tech is defined. Is a technological thing defined by its features, or should we describe outputs that can be achieved by the technology we use? Both are fine. But in draft-knodel-e2ee we take the former approach. And if you're trying to define security, or what it means to be secure, in your draft then you're clearly taking the latter approach. Again, the former is meant to be rather objective, for users to do with it what they will (eg here's what it does, determine if this will give you the output/security that you want). The latter approach means you're describing utopia and maybe that gives developers some ability to navigate towards that ideal, which is why its a valuable approach but a different one. Certainly harder! The second is specifically concerning tech that is built for security and/or privacy by design. We don't need to rely on the idea of an adversary in order to make, and therefore describe, a technology. Privacy and security, and other side benefits like access to info, are fundamental for all people. That intersection happens at technology use, which certainly has its place within the realm of technology development in terms of feedback loops between developers and users (ideally this loop is as tight as possible). But we are talking at the level of definitions, not implementations. This is very far from use. We should be able to define what is a technology (eg secure messaging or encryption) without invoking specific threats, and rather using threat modeling to trouble our definitions and designs. I would threat models help to problematise designs and definitions, rather than explicitly centering them in the description. In draft-knodel-e2ee we intentionally chose not to invoke an adversary but rely instead on lessons learned from encryption technologies that have modeled threats. Before I close, in general I've been waiting to make a comment about the choice to define secure messaging instead of encryption, because I think these previous two analyses lay the groundwork for what I'm about to say. That is: from a user perspective, having the two terms coexist is the first problem. Say there are apps that successfully implement something like client-side scanning or traceable messages. Which is that app-- secure messaging or encryption? It's not easily discernible for the user. There's too much parity between them for any meaningful distinction to be possible with basic inference. "Secure messaging" at the moment in the industry is simply a descriptive phrase, not a rigorously defined technology and I think it should stay that way. OTOH encryption is specific. Encryption means something and it needs a rigorous definition in order to not have the meaning of e2ee broadened to include things that it really shouldn't include. This is the second problem, that the lack of clarity be used as a vector for attack on the integrity of an important technology: encryption. -Mallory -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------zEuoJg0Ywb5rUbXlL0m0DuXY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi all,

On 5/7/21 9:49 AM, Alec Muffett wrote:
The primary objection I have here is that people will make the assumption that any system that does not conform to your arbitrary definition of "Secure" is, by inference, "Insecure".

That *is* an objection, however it pivots on the assertion that I am somehow attempting to define "secure" - but I am not.

Alec, I thought I'd respond to your points about adversaries and security in my draft by picking up on this theme further up in the thread on your draft.

This highlights a fundamental difference in approach. And there are two ways I look at it:

The first is how tech is defined. Is a technological thing defined by its features, or should we describe outputs that can  be achieved by the technology we use? Both are fine. But in draft-knodel-e2ee we take the former approach. And if you're trying to define security, or what it means to be secure, in your draft then you're clearly taking the latter approach. Again, the former is meant to be rather objective, for users to do with it what they will (eg here's what it does, determine if this will give you the output/security that you want). The latter approach means you're describing utopia and maybe that gives developers some ability to navigate towards that ideal, which is why its a valuable approach but a different one. Certainly harder!

The second is specifically concerning tech that is built for security and/or privacy by design. We don't need to rely on the idea of an adversary in order to make, and therefore describe, a technology. Privacy and security, and other side benefits like access to info, are fundamental for all people. That intersection happens at technology use, which certainly has its place within the realm of technology development in terms of feedback loops between developers and users (ideally this loop is as tight as possible). But we are talking at the level of definitions, not implementations. This is very far from use. We should be able to define what is a technology (eg secure messaging or encryption) without invoking specific threats, and rather using threat modeling to trouble our definitions and designs. I would threat models help to problematise designs and definitions, rather than explicitly centering them in the description. In draft-knodel-e2ee we intentionally chose not to invoke an adversary but rely instead on lessons learned from encryption technologies that have modeled threats.

Before I close, in general I've been waiting to make a comment about the choice to define secure messaging instead of encryption, because I think these previous two analyses lay the groundwork for what I'm about to say. That is: from a user perspective, having the two terms coexist is the first problem. Say there are apps that successfully implement something like client-side scanning or traceable messages. Which is that app-- secure messaging or encryption? It's not easily discernible for the user. There's too much parity between them for any meaningful distinction to be possible with basic inference. "Secure messaging" at the moment in the industry is simply a descriptive phrase, not a rigorously defined technology and I think it should stay that way. OTOH encryption is specific. Encryption means something and it needs a rigorous definition in order to not have the meaning of e2ee broadened to include things that it really shouldn't include. This is the second problem, that the lack of clarity be used as a vector for attack on the integrity of an important technology: encryption.

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------zEuoJg0Ywb5rUbXlL0m0DuXY-- From nobody Mon May 10 09:30:11 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 372D33A22DE for ; Mon, 10 May 2021 09:30:08 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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=cdt.org 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 ivcOgBx5jY6x for ; Mon, 10 May 2021 09:30:03 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 1769C3A22B7 for ; Mon, 10 May 2021 09:30:02 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id t20so8078084qtx.8 for ; Mon, 10 May 2021 09:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=WxwucD0KPO8I5lbVAykVUBTH0YCpw6MXsKFT1lZj2uo=; b=ctWTYZ14dWv0oZoRSWASj+JL10EoTJ0NkI8LSxcaudlVE5LCwA95a/C7/phOS1kd87 FaEew7FUdlu+RrJjNM3exQKg5l4foHLPoHr2F/fbix2wO3wG6FLmVYJFHZCwiVhpFwx8 qr9mst5RSjpiAswXiySp/BAKpOSyOIVlBgHEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=WxwucD0KPO8I5lbVAykVUBTH0YCpw6MXsKFT1lZj2uo=; b=ZSlNRe3hLRZ/A4dvCXPs0wtKPgAouQZu1qDf+DfAMAdcnCAKH+g9VXXE1EhkdwX4is zRSiYcyofk6ngbB5vLndJJPQZCvbXIqOx6xIoI3n1/PAgCfrAynKlfKvZEd6cJEt+nwW NS0PsdvcyflsAqixLTeyTovMfQDfGV7RXo7Jnor9vf2L5TMSntcSAcj2TOF4JPfvvRLI 5H1k9/qIjDYi54RnqMO4odOdkPzlVu1cwQ1JubKCAEszfODE3h6zVZyKHes0SgLOH7X7 UDap8pNKRqwi6rXxKcUI+7yZgVyxFxpCKbEYXdxmNumjh2JltXrxsXTdQik0ro0jBJr2 mk3A== X-Gm-Message-State: AOAM532N1HveDmvyel9KcNyQT7GaKAROhxpXXTrQi/S7TBO2Se3UVS3M NosikYOQBuv3082gsG4be7eVNw== X-Google-Smtp-Source: ABdhPJxvff66d0EyjTgsr8lAM49YFFUcqsfnGcuHZGoRVCN1bmYTf/KY01FaDIVE8omJrYtvfLwPEQ== X-Received: by 2002:ac8:5649:: with SMTP id 9mr23399199qtt.148.1620664201514; Mon, 10 May 2021 09:30:01 -0700 (PDT) Received: from ?IPV6:2601:140:8680:4c40:3161:a834:2760:43ad? ([2601:140:8680:4c40:3161:a834:2760:43ad]) by smtp.gmail.com with UTF8SMTPSA id b8sm12036115qtj.37.2021.05.10.09.30.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 09:30:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------k1Md3frh1vb79yb8uHtBNhP0" Message-ID: <722c95d5-43c9-880a-3765-3d2be65d8210@cdt.org> Date: Mon, 10 May 2021 12:30:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Raphael Robert Cc: Messaging Layer Security WG References: <162039893366.31953.3182470506238059389@ietfa.amsl.com> <818a638a-a687-5fb2-0f93-9654f4a1d9e9@cdt.org> From: Mallory Knodel In-Reply-To: Archived-At: Subject: Re: [MLS] New Version Notification for draft-knodel-e2ee-definition-01.txt 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, 10 May 2021 16:30:10 -0000 This is a multi-part message in MIME format. --------------k1Md3frh1vb79yb8uHtBNhP0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Raphael, those are all excellent suggestions. I think Gurshabad and I have a grip on their essence, so will make an attempt at -02 for the second points and I'll re-review draft-architecture with your first question in mind. Perhaps at the next MLS meeting we can as a group spend some time together to think about scope wrt other wg drafts. -Mallory On 5/7/21 5:06 PM, Raphael Robert wrote: > Thanks for sharing Mallory! > > I like that it has a wholistic approach and that it is based on prior > research. > I need to think a bit more about it in general, what comes to mind > right now in no particular order: > >  - What are the possible synergies between your draft and the MLS > architecture draft > (https://tools.ietf.org/html/draft-ietf-mls-architecture-06)? >  - Topics that could possibly be expanded: authentication, metadata > (e.g. persisted metadata vs. observable metadata) >  - End user expectations: As mentioned for Alec’s draft as well, I > think end user expectations are the center piece. Bridging the gap > between academic definitions and the UX of secure messengers would > provide some real value in my mind. > > In essence, it’s great to have this draft and it is relevant for MLS > in my mind. Thanks again for sharing! > > Raphael > >> On 7. May 2021, at 16:59, Mallory Knodel wrote: >> >> Hi all, >> >> There's been oblique discussion of this draft, thanks to Alec's >> citation in his recent effort. >> >> My co-authors and I thought we should go ahead and share a -01 >> version with the group. Most of our feedback so far has been around >> better definition of an end, so we broke that into its own sub-section. >> >> The goal is to clearly define e2ee in three different ways: >> constituent formal definition, functionalities, and user >> expectations. This assumes a technology is defined by its properties. >> Conversely, we are not trying to define properties by the technology >> in use, eg "this app is secure because it's e2ee", which is totally >> valid. But without our effort, it's becomes circular. >> >> Lastly I'll just mention that while we aim to define e2ee, we also >> end up defining a few other terms as well. It's perhaps worth >> considering this a terminology draft for the mls working group, as >> Raphael just suggested. We are certainly open to that, so please help >> us by opening issues or sending pull requests to help solidify those >> terms: https://github.com/mallory/e2ee/edit/main/draft-e2ee.md. >> >> Any and all reviews welcome, >> >> -Mallory >> >> >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for >> draft-knodel-e2ee-definition-01.txt >> Date: Fri, 07 May 2021 07:48:53 -0700 >> From: internet-drafts@ietf.org >> To: Sofía Celi , Fred Baker >> , Fred Baker , >> Gurshabad Grover , Mallory Knodel >> , Olaf Kolkman , Sofia Celi >> >> >> >> >> >> A new version of I-D, draft-knodel-e2ee-definition-01.txt >> has been successfully submitted by Mallory Knodel and posted to the >> IETF repository. >> >> Name: draft-knodel-e2ee-definition >> Revision: 01 >> Title: Definition of End-to-end Encryption >> Document date: 2021-05-07 >> Group: Individual Submission >> Pages: 12 >> URL: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt >> Status: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/ >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition >> Htmlized: https://tools.ietf.org/html/draft-knodel-e2ee-definition-01 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-knodel-e2ee-definition-01 >> >> Abstract: >> End-to-end encryption (E2EE) is an application of cryptography in >> communications systems between endpoints. E2EE systems are unique in >> providing features of confidentiality, integrity and authenticity for >> users. Improvements to E2EE strive to maximise the system's security >> while balancing usability and availability. Users of E2EE >> communications expect trustworthy providers of secure implementations >> to respect and protect their right to whisper. >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls > -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --------------k1Md3frh1vb79yb8uHtBNhP0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Thanks Raphael, those are all excellent suggestions. I think Gurshabad and I have a grip on their essence, so will make an attempt at -02 for the second points and I'll re-review draft-architecture with your first question in mind. Perhaps at the next MLS meeting we can as a group spend some time together to think about scope wrt other wg drafts.

-Mallory

On 5/7/21 5:06 PM, Raphael Robert wrote:
Thanks for sharing Mallory!

I like that it has a wholistic approach and that it is based on prior research.
I need to think a bit more about it in general, what comes to mind right now in no particular order:

 - What are the possible synergies between your draft and the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-architecture-06)?
 - Topics that could possibly be expanded: authentication, metadata (e.g. persisted metadata vs. observable metadata)
 - End user expectations: As mentioned for Alec’s draft as well, I think end user expectations are the center piece. Bridging the gap between academic definitions and the UX of secure messengers would provide some real value in my mind.

In essence, it’s great to have this draft and it is relevant for MLS in my mind. Thanks again for sharing!

Raphael

On 7. May 2021, at 16:59, Mallory Knodel <mknodel@cdt.org> wrote:

Hi all,

There's been oblique discussion of this draft, thanks to Alec's citation in his recent effort.

My co-authors and I thought we should go ahead and share a -01 version with the group. Most of our feedback so far has been around better definition of an end, so we broke that into its own sub-section.

The goal is to clearly define e2ee in three different ways: constituent formal definition, functionalities, and user expectations. This assumes a technology is defined by its properties. Conversely, we are not trying to define properties by the technology in use, eg "this app is secure because it's e2ee", which is totally valid. But without our effort, it's becomes circular.

Lastly I'll just mention that while we aim to define e2ee, we also end up defining a few other terms as well. It's perhaps worth considering this a terminology draft for the mls working group, as Raphael just suggested. We are certainly open to that, so please help us by opening issues or sending pull requests to help solidify those terms: https://github.com/mallory/e2ee/edit/main/draft-e2ee.md.

Any and all reviews welcome,

-Mallory



-------- Forwarded Message --------
Subject: New Version Notification for draft-knodel-e2ee-definition-01.txt
Date: Fri, 07 May 2021 07:48:53 -0700
From: internet-drafts@ietf.org
To: Sofía Celi <cherenkov@riseup.net>, Fred Baker <fredbaker.IETF@gmail.com>, Fred Baker <fredbaker.ietf@gmail.com>, Gurshabad Grover <gurshabad@cis-india.org>, Mallory Knodel <mknodel@cdt.org>, Olaf Kolkman <kolkman@isoc.org>, Sofia Celi <cherenkov@riseup.net>



A new version of I-D, draft-knodel-e2ee-definition-01.txt
has been successfully submitted by Mallory Knodel and posted to the
IETF repository.

Name: draft-knodel-e2ee-definition
Revision: 01
Title: Definition of End-to-end Encryption
Document date: 2021-05-07
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt
Status: https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/
Htmlized: https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition
Htmlized: https://tools.ietf.org/html/draft-knodel-e2ee-definition-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-knodel-e2ee-definition-01

Abstract:
End-to-end encryption (E2EE) is an application of cryptography in
communications systems between endpoints. E2EE systems are unique in
providing features of confidentiality, integrity and authenticity for
users. Improvements to E2EE strive to maximise the system's security
while balancing usability and availability. Users of E2EE
communications expect trustworthy providers of secure implementations
to respect and protect their right to whisper.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
--------------k1Md3frh1vb79yb8uHtBNhP0-- From nobody Mon May 10 12:50:53 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 35C593A2902 for ; Mon, 10 May 2021 12:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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=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 qqPQtLHWQzpy for ; Mon, 10 May 2021 12:50:46 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 EDA103A28FD for ; Mon, 10 May 2021 12:50:45 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id f24so26317708ejc.6 for ; Mon, 10 May 2021 12:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rpkxUdb1Eqw/xT5QHaF9IKm6miasqIEdrd8htfcEjoo=; b=Aah1cTi35UqY48IhaCMlqA8oJvK5VcBTLrhmp43mDX0iEpCcKprcMd19InXIOW12zy JFXMz7OyjxPKScUGVOgmBVYmRoB/MtIyr4V7T75lGw4NfsmgbyWMN2Y724bvA42LOhzi htucCySofJkNbwUtfQrf38Eojsw7EnI0GUZk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rpkxUdb1Eqw/xT5QHaF9IKm6miasqIEdrd8htfcEjoo=; b=muU2ZOMwA/L9mxTp0tDOLBYHQ9jHtDY/fdVdW/pg85ZRNyz4wcfoZlakWC3kJlcPr7 L69atu0sc9rI6vhWLB6s2yR9JPm1XKwbuiL8dudknuYG2s2OJwulq0NoGIE3QumdhszJ RYw05lJLyZDbZ3QBrv5zX76sQZ8IPkKwVXpypQXkSTCusqSypLqnDadiSZ9Ua3jQcBMv ySVAIqLllpLUkr/41kCCbuUF79BUiaYdz66ikY5iVM8U+DUgEKfx01qa/5BNupEKdXbC mCWV1TlhA2DaGVr2yFS5F7sN1lwtaHz7cDDqmi6/yv9J32okOPrBgLALkbsdJNv+NpKd cM6g== X-Gm-Message-State: AOAM531wBDIVKAzSGMNe39sc3Ho400Z9vmknZsAaIO/yfp1qMgbmnlhC 3/Mrk1ukhvYxmypd83dEY/FJWe7abHnAvnlFE7I= X-Google-Smtp-Source: ABdhPJyPY33osE4btYA9Z8HGdepwJA+Xh77YXj0zDPlvJrAQ4jw0HvHHR26rLUBAuuxUuAPN6sbKuw== X-Received: by 2002:a17:906:3385:: with SMTP id v5mr27277406eja.539.1620676243243; Mon, 10 May 2021 12:50:43 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id r16sm12408319edq.87.2021.05.10.12.50.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 12:50:42 -0700 (PDT) From: Raphael Robert Message-Id: <27F22D05-DE0C-4814-91D6-1901B93176D6@raphaelrobert.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_035B5727-9CC8-44BF-A0B0-DE74736965AB" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 10 May 2021 21:50:41 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Alec Muffett References: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 19:50:51 -0000 --Apple-Mail=_035B5727-9CC8-44BF-A0B0-DE74736965AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10. May 2021, at 08:30, Alec Muffett = wrote: >=20 >=20 >=20 > On Sun, 9 May 2021 at 18:58, Raphael Robert > wrote: > Yeah, that=E2=80=99s not how I remember it. I=E2=80=99m pretty sure = the gist of it was that the vendor (or an actor controlling the = vendor=E2=80=99s infrastructure) could convince WA clients to re-encrypt = messages to a different cryptographic identity. No SIM-card cloning was = required.=20 >=20 > Mm; there's a very simple proof of my point: in order to add a new = device and to steal these messages, it is first necessary for the = malicious actor to successfully impersonate a new user device, in order = to subvert the trust that WhatsApp has in the integrity of the user. >=20 > To perform this subversion requires SIM-cloning, some form of = phone-jacking, or - in the very simplest circumstance, as happened to = one of my family last week - socially engineering the user to forward = the confirmatory SMS/nonce for new device setup, *to* the malicious = actor. >=20 > The proof is: this is an abnormal activity. It mostly does not happen, = otherwise far more WhatsApp account theft would occur, enabled by = malicious actors simply connecting a new device and saying "Hey, I am = Raphael Robert, please send me anything addressed to him." >=20 > *This* is the concept of a Trusted Compute Base. I think we need to dial back a bit here. TCB works like a framework, = which means it needs a security policy that is clearly defined = (Wikipedia article: "the boundaries of the TCB depend closely upon the = specifics of how the security policy is fleshed out.=E2=80=9D). I = don=E2=80=99t see that in the draft yet, except for some provisions in = 5. =46rom your answer it looks like you exclude the vendor as a threat = actor, which strikes me as odd since the very essence of E2EE is to = protect users against attacks where the vendor is a threat actor. But I don=E2=80=99t want to jump to conclusions, I=E2=80=99ll wait for a = more clearly defined security policy first. > If rubber-stamping some of FB=E2=80=99s poorer decisions with that = draft is a desired goal, it changes the optics quite a bit.=20 > draft-knodel-e2ee-definition-01 has a much higher degree of = independence. >=20 > That's a tragic strawman; to repeat, the goal is to provide a metric = for judging the "minimally viable product behaviour" for something to be = worthy of being called "end-to-end secure"; it's also short, and = measurable against an implementation. >=20 >=20 >> I was more thinking about the authentication on a cryptographic level = between =E2=80=9Cends=E2=80=9D. The user-level identifier is a whole = other dimension (and probably out-of-scope). >>=20 >> So, notification regarding surprise key changes, that sort of thing, = perhaps as an addition to Section 3.2? >=20 > It really falls in under =E2=80=9Cauthentication=E2=80=9D in general. = draft-knodel-e2ee-definition-01 has the nice concept of encrypted = channels (although it contradicts the MLS notion of groups a bit). > It should be clear to the user at the time of encryption who the = participants are >=20 > For me, that's Sections 3.1 and 3.2. >=20 > =20 > and there should be a way to verify the participants and their = cryptographic identity. >=20 > Yes, but "verify them against... what?" [explanation follows below, = after joke] > =20 > I know this pretty much excludes iMessage. But if we want a definition = of E2ESM that covers iMessage, >=20 > Rubber-stamping some of Apple's decisions? [joke] > =20 > we need to drop authentication completely and that=E2=80=99s = definitely weak sauce. >=20 > The word "authentication" is only meaningful within two - what shall = we call them, "frames"? >=20 > 1/ that the "participant" is-or-is-not part of the conversation; but = that's the very *definition* of an end-to-end-secure conversation: that = "the only people who can read are participants, and participants are = those who can read", and it is the trusted-compute-base of each = participant-entity which defines their participation >=20 > 2/ that the "participant" somehow relates to some external identity = framework, for instance a PKI or a Driving License Number. >=20 > ...however I suspect that you may mean: >=20 > 3/ that the "participant" is fully in control of their devices and = endpoints, and that one of them has not been subverted or inserted by a = malicious actor; but this (again) eventually requires the E2ESM client = to perform a security audit of the device that it's hosted on, etc. = This one is hard, and possibly illiberal/unwise. >=20 > I would like to check please whether I am correctly reflecting your = wants for authentication? 1, 2, 3, or other? If anything, it would be closest to 2. In all usual protocols like PGP, = MLS, OTR, Signal, TLS, Wireguard, etc. the endpoints have a public = identity key. Whether this key is part of a larger PKI or is otherwise = associated with another identifier (e.g. a phone number) is very vendor = specific and should be out-of-scope. But the key itself should be part = of the system. In more abstract terms, the key is referred to as a = =E2=80=9Ccryptographic identity=E2=80=9D. This is the base layer of E2E = authentication. How exactly the key is verified is again vendor specific. The important = part is that the key can be verified and that you don=E2=80=99t have to = blindly trust the vendor. Raphael --Apple-Mail=_035B5727-9CC8-44BF-A0B0-DE74736965AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10. May 2021, at 08:30, Alec Muffett <alec.muffett@gmail.com> wrote:



On Sun, 9 May 2021 at 18:58, Raphael Robert <ietf@raphaelrobert.com> wrote:
Yeah, that=E2=80=99s not how I remember it. = I=E2=80=99m pretty sure the gist of it was that the vendor (or an actor = controlling the vendor=E2=80=99s infrastructure) could convince WA = clients to re-encrypt messages to a different cryptographic identity. No = SIM-card cloning was required. 

Mm; there's a very = simple proof of my point: in order to add a new device and to steal = these messages, it is first necessary for the malicious actor to = successfully impersonate a new user device, in order to subvert the = trust that WhatsApp has in the integrity of the user.

To perform this = subversion requires SIM-cloning, some form of phone-jacking, or - in the = very simplest circumstance, as happened to one of my family last = week - socially engineering the user to forward the confirmatory = SMS/nonce for new device setup, *to* the malicious actor.

The proof is: this is an = abnormal activity. It mostly does not happen, otherwise far more = WhatsApp account theft would occur, enabled by malicious actors simply = connecting a new device and saying "Hey, I am Raphael Robert, please = send me anything addressed to him."

*This* is the concept of a Trusted = Compute Base.

I think we need to dial back a bit here. TCB works like = a framework, which means it needs a security policy that is clearly = defined (Wikipedia article: "the boundaries of the TCB depend closely = upon the specifics of how the security policy is fleshed out.=E2=80=9D). = I don=E2=80=99t see that in the draft yet, except for some provisions in = 5.

=46rom your answer it looks like = you exclude the vendor as a threat actor, which strikes me as odd since = the very essence of E2EE is to protect users against attacks where the = vendor is a threat actor.
But I don=E2=80=99t want to jump to = conclusions, I=E2=80=99ll wait for a more clearly defined security = policy first.

If rubber-stamping some of = FB=E2=80=99s poorer decisions with that draft is a desired goal, it = changes the optics quite a bit. 
draft-knodel-e2ee-definition-01 has a much higher degree of = independence.

That's a tragic strawman; to = repeat, the goal is to provide a metric for judging the "minimally = viable product behaviour" for something to be worthy of being called = "end-to-end secure"; it's also short, and measurable against an = implementation.


I was more thinking about the authentication = on a cryptographic level between =E2=80=9Cends=E2=80=9D. The user-level = identifier is a whole other dimension (and probably = out-of-scope).

So, notification regarding surprise key = changes, that sort of thing, perhaps as an addition to Section = 3.2?

It really falls in = under =E2=80=9Cauthentication=E2=80=9D in = general. draft-knodel-e2ee-definition-01 has the nice concept of = encrypted channels (although it contradicts the MLS notion of groups a = bit).
It should be clear to the user at the time of = encryption who the participants are

For me, that's Sections = 3.1 and 3.2.

 
and there should be a way to verify the = participants and their cryptographic = identity.

Yes, but "verify them against... what?" = [explanation follows below, after joke]
 
I know this pretty much excludes iMessage. = But if we want a definition of E2ESM that covers iMessage, =

Rubber-stamping some of Apple's decisions? [joke]
 
we need to drop authentication completely and = that=E2=80=99s definitely weak sauce.

The word = "authentication" is only meaningful within two - what shall we call = them, "frames"?

1/ that the "participant" is-or-is-not part of the = conversation; but that's the very *definition* of an end-to-end-secure = conversation: that "the only people who can read are participants, and = participants are those who can read", and it is the trusted-compute-base = of each participant-entity which defines their participation

2/ that the = "participant" somehow relates to some external identity framework, for = instance a PKI or a Driving License Number.

...however I suspect that you may = mean:

3/ that = the "participant" is fully in control of their devices and endpoints, = and that one of them has not been subverted or inserted by a malicious = actor; but this (again) eventually requires the E2ESM client to perform = a security audit of the device that it's hosted on, etc.  This one = is hard, and possibly illiberal/unwise.

I would like to check please whether I = am correctly reflecting your wants for authentication? 1, 2, 3, or = other?

If = anything, it would be closest to 2. In all usual protocols like PGP, = MLS, OTR, Signal, TLS, Wireguard, etc. the endpoints have a public = identity key. Whether this key is part of a larger PKI or is otherwise = associated with another identifier (e.g. a phone number) is very vendor = specific and should be out-of-scope. But the key itself should be part = of the system. In more abstract terms, the key is referred to as a = =E2=80=9Ccryptographic identity=E2=80=9D. This is the base layer of E2E = authentication.
How exactly the key is verified is again = vendor specific. The important part is that the key can be verified and = that you don=E2=80=99t have to blindly trust the vendor.

Raphael


= --Apple-Mail=_035B5727-9CC8-44BF-A0B0-DE74736965AB-- From nobody Mon May 10 12:52:45 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 1EA6E3A290A for ; Mon, 10 May 2021 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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=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 MsZK7ONNuuUc for ; Mon, 10 May 2021 12:52:38 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 9D9133A2906 for ; Mon, 10 May 2021 12:52:37 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id t4so26398323ejo.0 for ; Mon, 10 May 2021 12:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Jpp3ANZFUQD/wXQOOVZ/zA9sqR0QUU0Er6ZXSO4dbSo=; b=w1wEWfltM6gK3MVUTwk70hQPKtunH8GT1iWJetglyctlgHlbWnlLjxh894xg/2Fot5 OrCNjiWUyFqzzT50YLl2y5Y5PFHxNO5bQxFpY+Y8/SLgmNQfM0UKN/Y/xSSaC6V4r9Od gGmUa/ekrSoHIdtAwEUv8442APbVIDLJ5xaco= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Jpp3ANZFUQD/wXQOOVZ/zA9sqR0QUU0Er6ZXSO4dbSo=; b=hl892DObmsrcU1DXQ7iRrynce8SCVRvdFvas7Mp4qu4+1xYTuEWwmRgvrJC7RHuKg1 18tu5tjZAXUp2Lz3ZyAe6BhlVN8FLP+6ilyyMrISNmP6FFWWErVSwsDkfOCdGD/J+8++ sBJ1jwi/IL/OUavj05VrbSq9wlfrC7rMd+g6Ro4+YvadTfzxigOoYM5f17BEMEyA8m4g sDUVSI7FJTq0PkEkVhlLrM35rwRnIAnfWeEDAyq+jD3lO5UH3qadvft7MEFde6KUuRn4 T07oCXD8aqn0uQn50k26Tq8/kD5ohkaYAxCRnklnboIVkWMiKKmCIc8rLnWkmW1jNuJ8 CSiw== X-Gm-Message-State: AOAM532CvsNhxXHFDlJAoH4TYk3B/GS3qv8yLnToCVCv/Wd2MizETZWd aKZcEOkEj4f6XZtvmO5XdZ7L2Q== X-Google-Smtp-Source: ABdhPJwuPdbr7noFr7ZxT7UEzJRDpNzY+X69X+F8mrpAKq1FBYxBCkh/Q46rRx2Kq5I4noitjZlRsw== X-Received: by 2002:a17:906:6b8d:: with SMTP id l13mr27126137ejr.169.1620676354697; Mon, 10 May 2021 12:52:34 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id p9sm12113513edu.79.2021.05.10.12.52.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 May 2021 12:52:34 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0C424C7A-3BE4-46FB-923D-389EEC839E5B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 10 May 2021 21:52:33 +0200 In-Reply-To: <722c95d5-43c9-880a-3765-3d2be65d8210@cdt.org> Cc: Messaging Layer Security WG To: Mallory Knodel References: <162039893366.31953.3182470506238059389@ietfa.amsl.com> <818a638a-a687-5fb2-0f93-9654f4a1d9e9@cdt.org> <722c95d5-43c9-880a-3765-3d2be65d8210@cdt.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] New Version Notification for draft-knodel-e2ee-definition-01.txt 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, 10 May 2021 19:52:43 -0000 --Apple-Mail=_0C424C7A-3BE4-46FB-923D-389EEC839E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Mallory, I=E2=80=99d be up for that! I definitely need to carve = out some more time in order to provide some more concrete feedback until = then. Raphael > On 10. May 2021, at 18:30, Mallory Knodel wrote: >=20 > Thanks Raphael, those are all excellent suggestions. I think Gurshabad = and I have a grip on their essence, so will make an attempt at -02 for = the second points and I'll re-review draft-architecture with your first = question in mind. Perhaps at the next MLS meeting we can as a group = spend some time together to think about scope wrt other wg drafts. >=20 > -Mallory >=20 > On 5/7/21 5:06 PM, Raphael Robert wrote: >> Thanks for sharing Mallory! >>=20 >> I like that it has a wholistic approach and that it is based on prior = research. >> I need to think a bit more about it in general, what comes to mind = right now in no particular order: >>=20 >> - What are the possible synergies between your draft and the MLS = architecture draft = (https://tools.ietf.org/html/draft-ietf-mls-architecture-06 = )? >> - Topics that could possibly be expanded: authentication, metadata = (e.g. persisted metadata vs. observable metadata) >> - End user expectations: As mentioned for Alec=E2=80=99s draft as = well, I think end user expectations are the center piece. Bridging the = gap between academic definitions and the UX of secure messengers would = provide some real value in my mind. >>=20 >> In essence, it=E2=80=99s great to have this draft and it is relevant = for MLS in my mind. Thanks again for sharing! >>=20 >> Raphael >>=20 >>> On 7. May 2021, at 16:59, Mallory Knodel > wrote: >>>=20 >>> Hi all, >>>=20 >>> There's been oblique discussion of this draft, thanks to Alec's = citation in his recent effort. >>>=20 >>> My co-authors and I thought we should go ahead and share a -01 = version with the group. Most of our feedback so far has been around = better definition of an end, so we broke that into its own sub-section. >>>=20 >>> The goal is to clearly define e2ee in three different ways: = constituent formal definition, functionalities, and user expectations. = This assumes a technology is defined by its properties. Conversely, we = are not trying to define properties by the technology in use, eg "this = app is secure because it's e2ee", which is totally valid. But without = our effort, it's becomes circular. >>>=20 >>> Lastly I'll just mention that while we aim to define e2ee, we also = end up defining a few other terms as well. It's perhaps worth = considering this a terminology draft for the mls working group, as = Raphael just suggested. We are certainly open to that, so please help us = by opening issues or sending pull requests to help solidify those terms: = https://github.com/mallory/e2ee/edit/main/draft-e2ee.md = . >>>=20 >>> Any and all reviews welcome, >>>=20 >>> -Mallory >>>=20 >>>=20 >>>=20 >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for = draft-knodel-e2ee-definition-01.txt >>> Date: Fri, 07 May 2021 07:48:53 -0700 >>> From: internet-drafts@ietf.org = >>> To: Sof=C3=ADa Celi = , Fred Baker = , Fred Baker = , Gurshabad Grover = , Mallory = Knodel , Olaf Kolkman = , Sofia Celi = >>>=20 >>>=20 >>> A new version of I-D, draft-knodel-e2ee-definition-01.txt >>> has been successfully submitted by Mallory Knodel and posted to the >>> IETF repository. >>>=20 >>> Name: draft-knodel-e2ee-definition >>> Revision: 01 >>> Title: Definition of End-to-end Encryption >>> Document date: 2021-05-07 >>> Group: Individual Submission >>> Pages: 12 >>> URL: = https://www.ietf.org/archive/id/draft-knodel-e2ee-definition-01.txt = >>> Status: = https://datatracker.ietf.org/doc/draft-knodel-e2ee-definition/ = >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-knodel-e2ee-definition = >>> Htmlized: = https://tools.ietf.org/html/draft-knodel-e2ee-definition-01 = >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-knodel-e2ee-definition-01 = >>>=20 >>> Abstract: >>> End-to-end encryption (E2EE) is an application of cryptography in >>> communications systems between endpoints. E2EE systems are unique in >>> providing features of confidentiality, integrity and authenticity = for >>> users. Improvements to E2EE strive to maximise the system's security >>> while balancing usability and availability. Users of E2EE >>> communications expect trustworthy providers of secure = implementations >>> to respect and protect their right to whisper. >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>=20 > --=20 > Mallory Knodel > CTO, Center for Democracy and Technology > gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 --Apple-Mail=_0C424C7A-3BE4-46FB-923D-389EEC839E5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Mallory, I=E2=80=99d be up for that! I definitely need = to carve out some more time in order to provide some more concrete = feedback until then.

Raphael

On 10. May 2021, at 18:30, = Mallory Knodel <mknodel@cdt.org> wrote:

=20 =20

Thanks Raphael, those are all excellent = suggestions. I think Gurshabad and I have a grip on their essence, so will make an attempt at -02 for the second points and I'll re-review draft-architecture with your first question in mind. Perhaps at the next MLS meeting we can as a group spend some time together to think about scope wrt other wg drafts.

-Mallory

On 5/7/21 5:06 PM, Raphael Robert wrote:
Thanks for sharing Mallory!

I like that it has a wholistic approach and that = it is based on prior research.
I need to think a bit more about it in general, = what comes to mind right now in no particular order:

 - What are the possible synergies between = your draft and the MLS architecture draft (https://tools.ietf.org/html/draft-ietf-mls-archit= ecture-06)?
 - Topics that could possibly be expanded: authentication, metadata (e.g. persisted metadata vs. observable metadata)
 - End user expectations: As mentioned for = Alec=E2=80=99s draft as well, I think end user expectations are the center piece. Bridging the gap between academic definitions and the UX of secure messengers would provide some real value in my = mind.

In essence, it=E2=80=99s great to have this draft = and it is relevant for MLS in my mind. Thanks again for sharing!

Raphael

On 7. May 2021, at 16:59, Mallory Knodel = <mknodel@cdt.org> wrote:

Hi all,

There's been oblique discussion of this draft, thanks to Alec's citation in his recent = effort.

My co-authors and I thought we should go ahead and share a -01 version with the group. Most of our feedback so far has been around better definition of an end, so we broke that into its own = sub-section.

The goal is to clearly define e2ee in = three different ways: constituent formal definition, functionalities, and user expectations. This assumes a technology is defined by its properties. Conversely, we are not trying to define properties by the technology in use, eg "this app is secure because it's e2ee", which is totally valid. But without our effort, it's becomes circular.

Lastly I'll = just mention that while we aim to define e2ee, we also end up defining a few other terms as well. It's perhaps worth considering this a terminology draft for the mls working group, as Raphael just suggested. We are certainly open to that, so please help us by opening issues or sending pull requests to help solidify those terms: https://github.com/mallory/e2ee/edit/main/draft-e= 2ee.md.

Any and all reviews welcome,

-Mallory



-------- Forwarded Message --------
Subject: New Version Notification for draft-knodel-e2ee-definition-01.txt
Date: Fri, 07 May 2021 07:48:53 = -0700
From: internet-drafts@ietf.org
To: Sof=C3=ADa Celi <cherenkov@riseup.net>, Fred Baker <fredbaker.IETF@gmail.com>, Fred Baker <fredbaker.ietf@gmail.com>, Gurshabad Grover <gurshabad@cis-india.org>, Mallory Knodel <mknodel@cdt.org>, Olaf Kolkman <kolkman@isoc.org>, Sofia Celi <cherenkov@riseup.net>



A new version of I-D, draft-knodel-e2ee-definition-01.txt
has been successfully submitted by Mallory Knodel and posted to the
IETF repository.

Name: draft-knodel-e2ee-definition
Revision: 01
Title: Definition of End-to-end Encryption
Document date: 2021-05-07
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/archive/id/draft-knodel-e2ee= -definition-01.txt
Status: https://datatracker.ietf.org/doc/draft-knodel-e2e= e-definition/
Htmlized: https://datatracker.ietf.org/doc/html/draft-knode= l-e2ee-definition
Htmlized: https://tools.ietf.org/html/draft-knodel-e2ee-def= inition-01
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-knodel-= e2ee-definition-01

Abstract:
End-to-end encryption (E2EE) is an application of cryptography in
communications systems between endpoints. E2EE systems are unique in
providing features of confidentiality, integrity and authenticity for
users. Improvements to E2EE strive to maximise the system's security
while balancing usability and availability. Users of E2EE
communications expect trustworthy providers of secure implementations
to respect and protect their right to whisper.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

The IETF Secretariat


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mls

--=20
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C =
C780

= --Apple-Mail=_0C424C7A-3BE4-46FB-923D-389EEC839E5B-- From nobody Mon May 10 13:49: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 90E3D3A2A8C for ; Mon, 10 May 2021 13:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 (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 4gAcjBY9Gs6h for ; Mon, 10 May 2021 13:49:23 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 374273A2A8A for ; Mon, 10 May 2021 13:49:23 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id h21so9282808qtu.5 for ; Mon, 10 May 2021 13:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p8bwUTCsMGX9r5a+sEOZTBMfARwHMuaWVnBYLAdhWB0=; b=UrFTeh26X9Z62P0a+y3+iie06iPBQvwhpuxtFpjXgYCTSS/T2HWdLMej8kvk6UAszr upcNdaNtQNe4NNnY7UK+MgxJz8JBWaBVP4Lg5blrpTCCqtr7UVksf6uHMUsswXfL4eiL CeOiJA3/q6Bgm/1jmzSEVgprm9lQMezpADxc4F4lrGykCNrGdv+IEB2eOaMhUWs7PGKn WFOia9jXH9dS/AbVnFEWzycKKlgqeAGKMD8xC6QVuioIqfh1F76ZVBGpf9wpvXRCkMFJ Gk5JgXOxB71NW+37KeUC3a6d8U5VRtHO+By3T7GfsKCXYHUHeeJWV+1lbzBgX+1yAiMJ 8AYg== 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=p8bwUTCsMGX9r5a+sEOZTBMfARwHMuaWVnBYLAdhWB0=; b=ce0GIuDwuBfKATy9y5WgtBsMIe5iMPl2J0adf8VzJhrdvtnUxN8sddHLrZMr6UsNHz W97kKtizroHJIOUs5d0KSYmvSbScAUrt+ijeLxswwHozEf7hgmV7AlBOlPvlJ48DJTtK M7h2YTGVK2b7LmZIYQoi7VsaVKUiGENM7HsH59L2EZgFDrzBnZRup9PGTCp/odLAdLqg yIuKdkNhjx2b4HHPeuCbOpzj9Qacshz4/qrD/SEuHydKe9BL4Cd8Jh8cng4J64aZiPFa nFQgXzHvALsAECHNIDdvZSvAmE9IbSWP90T/BpVq7FxFkAM4tVy1qbjd7bzLfNUPiRAN 3zgw== X-Gm-Message-State: AOAM532qQtcFvUXEBHmbpiY+V64vDiYL3moVt5X2W9Wq0EcvGAab8UzV h6UItyIKTGOIwwNedoGRgVuYAYsMce+jFF8CA2o793FdTRG5gQ== X-Google-Smtp-Source: ABdhPJxMz9IGiOq4qcU1bfbf4mNcF4g1DDL/kHFg/MQucvO7YzqK0zfkj+4DFTFgODQuc671Utaj5ty1lItNlx06ABc= X-Received: by 2002:ac8:72d8:: with SMTP id o24mr14966846qtp.321.1620679760914; Mon, 10 May 2021 13:49:20 -0700 (PDT) MIME-Version: 1.0 References: <7FAF6BF0-483D-4AE8-BD35-A845DC1B229D@raphaelrobert.com> <27F22D05-DE0C-4814-91D6-1901B93176D6@raphaelrobert.com> In-Reply-To: <27F22D05-DE0C-4814-91D6-1901B93176D6@raphaelrobert.com> From: Alec Muffett Date: Mon, 10 May 2021 21:48:44 +0100 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000071ab5e05c1ffe935" Archived-At: Subject: Re: [MLS] Functional Definition of End-to-End Secure Messaging 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, 10 May 2021 20:49:29 -0000 --00000000000071ab5e05c1ffe935 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 10 May 2021 at 20:50, Raphael Robert wrote= : > I think we need to dial back a bit here. TCB works like a framework, whic= h > means it needs a security policy that is clearly defined (Wikipedia > article: "the boundaries of the TCB depend closely upon the specifics of > how the security policy is fleshed out.=E2=80=9D). I don=E2=80=99t see th= at in the draft > yet, except for some provisions in 5. > Correct. It's not possible for an app to tell a user what their security policy can or should be. That would be like the tail wagging the dog. The user has (whether they realise it or not) a security policy and threat model. They trust some devices, some services, not others. They choose to use an app and to trust it. They add it to their TCB. Who are we to tell them that they have everything wrong? > > From your answer it looks like you exclude the vendor as a threat actor, > which strikes me as odd since the very essence of E2EE is to protect user= s > against attacks where the vendor is a threat actor. > Again, I frame it this way: the user chooses to trust a vendor. That's how TCBs and users work. > But I don=E2=80=99t want to jump to conclusions, I=E2=80=99ll wait for a = more clearly > defined security policy first. > It's not up to me to deliver one - although to be fair, one can see *hints* of this in (say) Signal, where it attempts to block itself from being run on "rooted" Android systems; however one can't put stuff like that into a communications standard. It belongs instead in an "application value proposition". It's part of Signal's sales pitch. > The word "authentication" is only meaningful within two - what shall we > call them, "frames"? > > 1/ that the "participant" is-or-is-not part of the conversation; but > that's the very *definition* of an end-to-end-secure conversation: that > "the only people who can read are participants, and participants are thos= e > who can read", and it is the trusted-compute-base of each > participant-entity which defines their participation > > 2/ that the "participant" somehow relates to some external identity > framework, for instance a PKI or a Driving License Number. > > ...however I suspect that you may mean: > > 3/ that the "participant" is fully in control of their devices and > endpoints, and that one of them has not been subverted or inserted by a > malicious actor; but this (again) eventually requires the E2ESM client to > perform a security audit of the device that it's hosted on, etc. This on= e > is hard, and possibly illiberal/unwise. > > I would like to check please whether I am correctly reflecting your wants > for authentication? 1, 2, 3, or other? > > > If anything, it would be closest to 2. > Wow. You want to tie communications to real-life identities? > In all usual protocols like PGP, MLS, OTR, Signal, TLS, Wireguard, etc. > the endpoints have a public identity key. Whether this key is part of a > larger PKI or is otherwise associated with another identifier (e.g. a pho= ne > number) is very vendor specific and should be out-of-scope. But the key > itself should be part of the system. In more abstract terms, the key is > referred to as a =E2=80=9Ccryptographic identity=E2=80=9D. This is the ba= se layer of E2E > authentication. > Oh, okay, so maybe you don't want to tie communications to real-life identities, you're just saying that there's one principal-key-or-identity per participant? That would be fine, but then... How exactly the key is verified is again vendor specific. > The important part is that the key can be verified and that you don=E2=80= =99t have > to blindly trust the vendor. > Okay, so what you're asking for is that an E2ESM must surface some individual or joint identity token with which Alice can prove herself to Bob, out of band, to assure trust? That seems reasonable, but in some cases redundant - like, for instance, Ricochet, where in order for Bob to communicate at all with Alice, he must already have her Onion Address. There's no other cryptography involved, and the Onion Address is also a network endpoint. There would be no other token, but then there would also be no intermediary "vendor". This sounds good. However: anyone who follows / is aware of Darkweb markets will also know that they are regularly faked. The Onion Address - or indeed any static per-client "identity key" for any participant - can and will be spoofed by AliceFake1, AliceFake2 (etc) - so long as the Fake Alices do a good job of social-engineering themselves into public awareness. So such keys are a nice-to-have and will add a little extra assurance, but I don't see mandating this as achieving anything other than an "extra layer of indirection"? The additional trust they provide is not quantifiable? If it is, how is it measured? - alec --=20 https://alecmuffett.com/about --00000000000071ab5e05c1ffe935 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 10 May 2021 = at 20:50, Raphael Robert <ietf= @raphaelrobert.com> wrote:
I think we need to dial = back a bit here. TCB works like a framework, which means it needs a securit= y policy that is clearly defined (Wikipedia article: "the boundaries o= f the TCB depend closely upon the specifics of how the security policy is f= leshed out.=E2=80=9D). I don=E2=80=99t see that in the draft yet, except fo= r some provisions in 5.

Correct= .=C2=A0 It's not possible for an app to tell a user what their security= policy can or should be. =C2=A0

That would be lik= e the tail wagging the dog.

The user has (whether = they realise it or not) a security policy and threat model.=C2=A0 They trus= t some devices, some services, not others.=C2=A0 They choose to use an app = and to trust it.=C2=A0 They add it to their TCB.

W= ho are we to tell them that they have everything wrong?


=C2=A0

From your answe= r it looks like you exclude the vendor as a threat actor, which strikes me = as odd since the very essence of E2EE is to protect users against attacks w= here the vendor is a threat actor.

<= div>Again, I frame it this way: the user chooses to trust a vendor.=C2=A0 T= hat's how TCBs and users work.

=C2=A0
But I don=E2=80=99t want to jump to conclusions, I=E2=80=99ll wait= for a more clearly defined security policy first.
=

It's not up to me to deliver one - although to be f= air, one can see *hints* of this in (say) Signal, where it attempts to bloc= k itself from being run on "rooted" Android systems; however one = can't put stuff like that into a communications standard.=C2=A0 It belo= ngs instead in an "application value proposition".=C2=A0 It's= part of Signal's sales pitch.


= =C2=A0
The word "authentication" is only meaningful within two - what = shall we call them, "frames"?

1/ that th= e "participant" is-or-is-not part of the conversation; but that&#= 39;s the very *definition* of an end-to-end-secure conversation: that "= ;the only people who can read are participants, and participants are those = who can read", and it is the trusted-compute-base of each participant-= entity which defines their participation

2/ that t= he "participant" somehow relates to some external identity framew= ork, for instance a PKI or a Driving License Number.

...however I suspect that you may mean:

3/ that= the "participant" is fully in control of their devices and endpo= ints, and that one of them has not been subverted or inserted by a maliciou= s actor; but this (again) eventually requires the E2ESM client to perform a= security audit of the device that it's hosted on, etc.=C2=A0 This one = is hard, and possibly illiberal/unwise.

I would li= ke to check please whether I am correctly reflecting your wants for authent= ication? 1, 2, 3, or other?

If= anything, it would be closest to 2.


Wow.=C2=A0 You want to tie communications to real-lif= e identities? =C2=A0
=C2=A0
In all usual pr= otocols like PGP, MLS, OTR, Signal, TLS, Wireguard, etc. the endpoints have= a public identity key. Whether this key is part of a larger PKI or is othe= rwise associated with another identifier (e.g. a phone number) is very vend= or specific and should be out-of-scope. But the key itself should be part o= f the system. In more abstract terms, the key is referred to as a =E2=80=9C= cryptographic identity=E2=80=9D. This is the base layer of E2E authenticati= on.

Oh, okay, so maybe you don&= #39;t want to tie communications to real-life identities, you're just s= aying that there's one principal-key-or-identity per participant?=C2=A0= That would be fine, but then...

How exactl= y the key is verified is again vendor specific.=C2=A0
The important part is that the key can be verified and that = you don=E2=80=99t have to blindly trust the vendor.

Okay, so what you're asking for is that a= n E2ESM must surface some individual or joint identity token with which Ali= ce can prove herself to Bob, out of band, to assure trust?=C2=A0
=
That seems reasonable, but in some cases redundant - like, f= or instance, Ricochet, where in order for Bob to communicate at all with Al= ice, he must already have her Onion Address.=C2=A0 There's no other cry= ptography involved, and the Onion Address is also a network endpoint.=C2=A0=

There would be no other token, but then there wou= ld also be no intermediary "vendor". This sounds good.=C2=A0

However: anyone who follows / is aware of Darkweb=C2= =A0markets will also know that they are regularly faked. The Onion Address = - or indeed any static per-client "identity key" for any particip= ant - can and will be spoofed by AliceFake1, AliceFake2 (etc) - so long as = the Fake Alices do a good=C2=A0job of social-engineering themselves into pu= blic awareness.

So such keys are=C2=A0a nice-to-ha= ve=C2=A0and will add a little extra assurance, but I don't see mandatin= g this as achieving anything other than an "extra layer of indirection= "?=C2=A0 The additional trust they provide is not quantifiable? =C2=A0=

If it is, how is it measured?

=C2=A0 =C2=A0 - alec

--
--00000000000071ab5e05c1ffe935-- From nobody Mon May 10 23:12:05 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 A00263A0FDC for ; Mon, 10 May 2021 23:12:03 -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, FREEMAIL_FROM=0.001, 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 (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 2h0UJYZob5Fy for ; Mon, 10 May 2021 23:11:58 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 56DC33A0FD9 for ; Mon, 10 May 2021 23:11:58 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id h21so10083587qtu.5 for ; Mon, 10 May 2021 23:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FS8ko8ZsUdHBrDB5fanFJAucbltwRkj0jK09ro7LHEI=; b=jpIXuHKzdvcsRRgJf52zYxHiokX9k4+zJSOEpHYSpuplSJeLTiI8WMSKHbbiw3Okyz bSNQ5m6IeQDfyXHKqA7vsuI8PLFRQR/Cb0LNMbStRV9L7EU65ziigGox5cR1l7pRH8jj a/XmpI920NoVG9jHmHLbHEFFEAOnIXE+X7+qnG1FSq851lsYv2H1CDHEEK23TXGeD0dP dakPwGu3t5BWmQmIwy5JODftncc2Ehrguo5wHFckD4IgeUhLFT+dVc3ifclw17PRXTTL oODiluHopsvf6VjzZ1nbxB3VxKI7OiQFoyrwhQCWUJDYsrE2blBa13rUShjhhjoYDqz0 uRWA== 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=FS8ko8ZsUdHBrDB5fanFJAucbltwRkj0jK09ro7LHEI=; b=Sq2rI89wAbEuEfEr7T+8J1S28BPhpiIjz/hfjmfw/X2PlyuWz7GGMYwSgVMg6tRYDn qw4UbyffvDpMIY5FaVV/d2G1b47txnMVFNCauf0nfPXPAlvJq8LfDFy/tzV776Ch+mxg J6JDxJozT3pkN2hg6A/YQnhyQs04Qg2rrgRSm8iI2uI0w61rr07iusH8m6NsEtNrLNo5 9LNt1AZvzpHFeT0tTzH8oK1NAa52/2WqsSEFKhb57jkR2KZcCSFs+AoRLp0voTfNJNIW 3cvbH302y7y4YbDU8lb4z7Bqe5RJmZ+fF/TujmPuD2azea0Nc365H6aA73aE1J1gUxvc d1Bg== X-Gm-Message-State: AOAM532LGYjMuxkYpztqMhE3qzsKYNTU23uLkgRpSTfE4gIyIjCvEXpr z2MY5bOrrRf/MJBbzQMO2ApC1Vf7wHqzOLURGoknjMwL4493lg== X-Google-Smtp-Source: ABdhPJy6UdVLNIC5Saq5mhgwnvg70+sCkDloL8dDpjej65pcToRZ9LF3Jk7ZJhkMuSK7wtvjmja7NcG5lS7Veg1YZXU= X-Received: by 2002:ac8:4d43:: with SMTP id x3mr27209375qtv.326.1620713516280; Mon, 10 May 2021 23:11:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alec Muffett Date: Tue, 11 May 2021 07:11:19 +0100 Message-ID: To: Mallory Knodel Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000006bb08805c207c596" Archived-At: Subject: Re: [MLS] secure & end Re: Functional Definition of End-to-End Secure Messaging 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, 11 May 2021 06:12:04 -0000 --0000000000006bb08805c207c596 Content-Type: text/plain; charset="UTF-8" On Mon, 10 May 2021 at 17:01, Mallory Knodel wrote: > Alec, I thought I'd respond to your points about adversaries and security > in my draft by picking up on this theme further up in the thread on your > draft. > Hey Mallory! Thank you! This highlights a fundamental difference in approach. And there are two > ways I look at it: > > The first is how tech is defined. Is a technological thing defined by its > features, or should we describe outputs that can be achieved by the > technology we use? > This is also how I am looking at it - to rephrase: your draft pursues whether something *looks* like E2E, and mine is busy with whether it *swims and quacks * like E2E; and I am trying to formalise what swimming and quacking entail. Both are fine. But in draft-knodel-e2ee we take the former approach. And if > you're trying to define security, or what it means to be secure, in your > draft then you're clearly taking the latter approach. Again, the former is > meant to be rather objective, for users to do with it what they will (eg > here's what it does, determine if this will give you the output/security > that you want). > There's the rub: just because it has confidential feet and trustworthy feathers, doesn't make it an E2E duck in the modern era; the folks at GCHQ love to say stuff like "of course the messages are confidential; people can have *confidence* in them, we just need to be able to get at them" - and other games like that (ref: https://www.lawfareblog.com/principles-more-informed-exceptional-access-debate ) > The latter approach means you're describing utopia > Ha! I seem to be describing the norm, rather than some utopian ideal - as suggested by work in progress at: https://docs.google.com/spreadsheets/d/1UjZhZjq-Afg0ZPrEUcvmVRYDDIrPH77PVyEJHRUZyqQ/edit#gid=0 The definition even fits both Signal *and* PGP-over-Email, which latter does not suit the modern era but there's nothing to be done about that. The point of the draft-muffett-e2esm definition is to be precise, not "appropriate". and maybe that gives developers some ability to navigate towards that > ideal, which is why its a valuable approach but a different one. Certainly > harder! > Developers are not my target market; if anything I think that draft-knodel-e2ee-definition-01 is better for developers, highlighting abstract concepts like: *"A system provides message confidentiality if only the sender and intended > recipient(s) can read the message plaintext" * ...yet leaving open the concepts of "intended recipients" (GCHQ love to play with this) and "what does 'read' mean?" and "is the writer a reader?" and "whether the 'intended recipients' *really* need to see each other?" and "whether an additional intended recipient can be silently added?" and "do we need to hide the plaintext size? Yes(3) or No(2)?" There is space for defining principles, and there is also space for fitness testing. I am aiming for the latter. > The second is specifically concerning tech that is built for security > and/or privacy by design. We don't need to rely on the idea of an adversary > in order to make, and therefore describe, a technology. > Slightly disagree. What we need is a threat model, and fortunately one can be straightforwardly extrapolated from the concept of "end to end". The concepts of security and privacy are meaningless without a threat model, and a threat model is informed by understanding the motivations of a threat actor.... but it appears that you *agree* with me on this, maybe: > We should be able to define what is a technology (eg secure messaging or > encryption) without invoking specific threats, and rather using threat > modeling to trouble our definitions and designs. I would threat models help > to problematise designs and definitions, rather than explicitly centering > them in the description > I'm not quite sure of your meaning here, but... direct threat modeling works for me, including the "meta" threat-modelling: - there are people who will try to bend this definition for political aims - there are people who will redefine words in this definition for political aims - there are people who will use any crack in this definition, for political aims This is why draft-muffett-e2esm attempts to lock down terminology at a technical (not "intentional") level of "what this means", because such is *measurable*. Before I close, in general I've been waiting to make a comment about the > choice to define secure messaging instead of encryption, because I think > these previous two analyses lay the groundwork for what I'm about to say. > That is: from a user perspective, having the two terms coexist is the first > problem. Say there are apps that successfully implement something like > client-side scanning or traceable messages. Which is that app-- secure > messaging or encryption? It's not easily discernible for the user. There's > too much parity between them for any meaningful distinction to be possible > with basic inference. "Secure messaging" at the moment in the industry is > simply a descriptive phrase, not a rigorously defined technology and I > think it should stay that way. OTOH encryption is specific. Encryption > means something and it needs a rigorous definition in order to not have the > meaning of e2ee broadened to include things that it really shouldn't > include. This is the second problem, that the lack of clarity be used as a > vector for attack on the integrity of an important technology: encryption. > My intent is to rigorously and clearly define end-to-end secure messaging, and my solution to "E2E brand dilution" has been improved in section 2 of Draft-01, as a flat statement: *2. Requirements for an End-to-End Secure Messenger* *Software which functions as an End-to-End Secure Messenger MUST satisfy the following principles, and MUST satisfy these principles in respect of the provided definitions for all forms of communication and data-sharing that the software offers. The software MAY comprise either a complete application, or a clearly defined subset of functionality within a larger application. Any software that does not satisfy these requirements is not an End- to-End Secure Messenger, and it does not implement End-to-End Secure Messaging, nor does it implement End-to-End Encrypted Messaging.* Which I think is clear enough. E2ESM is a superset of E2EM, and I am sure that over time, Ricochet will not be the only messenger that implements E2ESM without requiring a central (or, distributed) "provider". Briar kinda does, too, and I am not sure about Cwtch yet. Optimistically, though: all these challenges are addressable. Perhaps the greatest challenge is obtaining consensus regarding the importance of "quacking". - alec -- https://alecmuffett.com/about --0000000000006bb08805c207c596 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, 10 May 2021 at 17:01, Mall= ory Knodel <mknodel@cdt.org> w= rote:
=20 =20 =20

Alec, I thought I'd respond to your points about adversaries and security in my draft by picking up on this theme further up in the thread on your draft.

Hey Mallory! Tha= nk you!

This highlights a fundamental difference in approach. And there are two ways I look at it:

The first is how tech is defined. Is a technological thing defined by its features, or should we describe outputs that can=C2=A0 be achieved by the technology we use?

Thi= s is also how I am looking at it - to rephrase: your draft pursues whether = something looks=C2=A0like E2E, and mine is busy with whether it <= a href=3D"https://en.wikipedia.org/wiki/Duck_test">swims and quacks= like E2E; and I am trying=C2=A0to formalise what swimming and quacking ent= ail.

Both are fine. But in draft-knodel-e2ee we take the former approach. And if you're trying to define security, or what it means to be secure, in your draft then you're clearly taking the latter approach. Again, the former is meant to be rather objective, for users to do with it what they will (eg here's what it does, determine if this will give you the output/security that you want).

There's the rub: just because it has confidential feet and trustwort= hy feathers, doesn't make it an E2E duck in the modern era; the folks a= t GCHQ love to say stuff like "of course the messages are confidential= ; people can have confidence in them, we just need to be able to get= at them" - and other games like that (ref: https://ww= w.lawfareblog.com/principles-more-informed-exceptional-access-debate)
=C2=A0

The latter approach means you're describing utopia

Ha! I = seem to be describing the norm, rather than some utopian ideal - as suggest= ed by work in progress at:


The definitio= n even fits both Signal *and* PGP-over-Email, which latter does not suit th= e modern era but there's nothing to be done about that. The point of th= e draft-muffett-e2esm definition is to be precise, not "appropriate&qu= ot;.

and maybe that gives deve= lopers some ability to navigate towards that ideal, which is why its a valuable approach but a different one. Certainly harder!

Developers are not my target market; if anything I think= that draft-knodel-e2ee-definition-01 is better for developers, highlightin= g abstract concepts like:

"A s= ystem provides message confidentiality if only the sender and intended reci= pient(s) can read the message plaintext"=C2=A0
...yet leaving open the concepts of "intended recipients&= quot; (GCHQ love to play with this) and "what does 'read' mean= ?" and "is the writer a reader?" and "whether the '= intended recipients' *really* need to see each other?" and "w= hether an additional intended recipient can be silently added?" and &q= uot;do we need to hide the plaintext size? Yes(3) or No(2)?"
=

There is space for defining principles, and there is al= so space for fitness testing.=C2=A0 I am aiming for the latter.
= =C2=A0

The second is specifically concerning tech that is built for security and/or privacy by design. We don't need to rely on the idea of an adversary in order to make, and therefore describe, a technology.

Slightly disagree.=C2=A0 What= we need is a threat model, and fortunately one can be straightforwardly ex= trapolated from the concept of "end to end". The concepts of secu= rity and privacy are meaningless without a threat model, and a threat model= is informed by understanding the motivations of a threat actor.... but it = appears that you agree with me on this, maybe:

We should be able to define what is a technology (eg secure messaging or encryption) without invoking specific threats, and rather using threat modeling to trouble our definitions and designs. I would threat models help to problematise designs and definitions, rather than explicitly centering them in the description

I'm not quite sure of your meaning here, but... direct threat modeli= ng works for me, including the "meta" threat-modelling:

- there are people who will try to bend this definition for= political aims

- there are people who will redefi= ne words in this definition for political aims

- t= here are people who will use any crack in this definition, for political ai= ms

This is why draft-muffett-e2esm attempts to loc= k down terminology at a technical (not "intentional") level of &q= uot;what this means", because such is measurable.

Before I close, in general I've been wa= iting to make a comment about the choice to define secure messaging instead of encryption, because I think these previous two analyses lay the groundwork for what I'm about to say. That is: from a user perspective, having the two terms coexist is the first problem. Say there are apps that successfully implement something like client-side scanning or traceable messages. Which is that app-- secure messaging or encryption? It's not easily discernible for the user. There's= too much parity between them for any meaningful distinction to be possible with basic inference. "Secure messaging" at the mo= ment in the industry is simply a descriptive phrase, not a rigorously defined technology and I think it should stay that way. OTOH encryption is specific. Encryption means something and it needs a rigorous definition in order to not have the meaning of e2ee broadened to include things that it really shouldn't include. Thi= s is the second problem, that the lack of clarity be used as a vector for attack on the integrity of an important technology: encryption.

My intent is to rigorously and clea= rly define end-to-end secure messaging, and my solution to "E2E brand = dilution" has been improved in section 2 of Draft-01, as a flat statem= ent:

2. Requirements for a= n End-to-End Secure Messenger
Software which functions as = an End-to-End Secure Messenger MUST satisfy the following principles, and M= UST satisfy these principles in respect of the provided definitions for all= forms of communication and data-sharing that the software offers. The soft= ware MAY comprise either a complete application, or a clearly defined subse= t of functionality within a larger application. Any software that does not = satisfy these requirements is not an End- to-End Secure Messenger, and it d= oes not implement End-to-End Secure Messaging, nor does it implement End-to= -End Encrypted Messaging.

Which I think is cle= ar enough. E2ESM is a superset of E2EM, and I am sure that over time, Ricoc= het will not be the only messenger that implements E2ESM without requiring = a central (or, distributed) "provider".=C2=A0 Briar kinda does, t= oo, and I am not sure about Cwtch yet.

Optim= istically, though: all these challenges are addressable.

Perhaps the greatest challenge is obtaining consensus regarding the = importance=C2=A0of "quacking".

=C2=A0 = =C2=A0 - alec
--
--0000000000006bb08805c207c596-- From nobody Wed May 12 05:27:09 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 4545C3A0CFC for ; Wed, 12 May 2021 05:27:07 -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=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 Rm8kL6_niTp7 for ; Wed, 12 May 2021 05:27:02 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 693A63A0D2A for ; Wed, 12 May 2021 05:27:02 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id g5so6232398qvk.1 for ; Wed, 12 May 2021 05:27:02 -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:date:references :to:in-reply-to:message-id; bh=pKTND2rPE27Xdil/Jo9+LovgNElvg63ABaMtzIuxnEc=; b=KS8wic6NYD6jFVwcV8zLWYWNcUusJZLVI0ojcI5tNmtkaib1nPjxz5SBvBIN6Bs1P7 jRUz2M7HBapM+Y9C+KvPtwqekPeQesV/QR8dsIILjmljNO8P/e+cgZcIf9ct6BCHwOb9 YCnDxmyPmYM+tFityoDcghPpOrln/5f9+IdjU= 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:date:references:to:in-reply-to:message-id; bh=pKTND2rPE27Xdil/Jo9+LovgNElvg63ABaMtzIuxnEc=; b=UrPDMPF9gi5IQuWhLIKey1K4DNP/mdnpaPZC50nCjpKx53E0SvndF5Ssb55w7cXRxO eNzea2Idhne6fVzK4orPJdaMuUpz2TcGpeeZ3LumBnztP5fIAYaT1Wp5JLrWOTJeJgXf /J6LncFQgPH55LR+taWNmCsOcrXJXS3yigwmibYwhNsYt2I6tpckNpRT+aMWCq1S0UoY Er9E67NeiLcevhs6Vel6NtCDkX0r49gswHBCnCgZJuH5WZNnn1oCWJfEC5UpLzblL6UO Esm7Jw1LrulPhwy56FpWjkrxRXxknTmvxigJOxx4mK3rsjwJAvFWqdmiLYehQ60Sjs69 i+Lw== X-Gm-Message-State: AOAM532W0sxmAHZnauvbuxu3MO0ohk9MjuVYfno1/M6CmIyAc+R/Uqfm XJsXYMBfIQjUOrPlWBEuY+ZhVC/OeBcRbg== X-Google-Smtp-Source: ABdhPJzxWYtSUYKsOBdfovnFg3W2InCq2ienKxJ5Jc7IrmhbZx9mct15LDkSyFWAtU4ESOdjl2mDcQ== X-Received: by 2002:a0c:f0c9:: with SMTP id d9mr35214144qvl.3.1620822420216; Wed, 12 May 2021 05:27:00 -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 x28sm8852673qtm.71.2021.05.12.05.26.59 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 May 2021 05:26:59 -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.80.0.2.43\)) Date: Wed, 12 May 2021 08:26:58 -0400 References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> To: MLS List In-Reply-To: Message-Id: <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [MLS] Reminder: Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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: Wed, 12 May 2021 12:27:07 -0000 Just an FYI that we have a meeting scheduled for next week. spt > On May 7, 2021, at 13:33, Sean Turner wrote: >=20 > Meeting Scheduled! >=20 > More information can also be found here: > https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls >=20 > spt >=20 >> On May 7, 2021, at 12:39, IESG Secretary = wrote: >>=20 >> The Messaging Layer Security (mls) WG will hold >> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>=20 >> Agenda: >> GitHub issues and pull requests related to -protocol and = -architecture. >>=20 >> Information about remote participation: >> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From nobody Sun May 16 15:56: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 8D7D63A1C48 for ; Sun, 16 May 2021 15:56:04 -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_H3=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=Vb4Zcoym; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JBOCMTaC 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 4_iiT1kYLsZr for ; Sun, 16 May 2021 15:55:59 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CD93A1C4C for ; Sun, 16 May 2021 15:55:58 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A23765C01CF for ; Sun, 16 May 2021 18:19:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 16 May 2021 18:19:52 -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=Gnju2gqkljE kqjeaQ/fwfvNfZZW63XV1jRLBJAeOeCk=; b=Vb4ZcoymAZsCEij6m52uR+06N3m z/EbaRFPFXQftVuLJD8HrRjhMlRG9U8u3vpy6W3Qc9UxCy8tqWQTG/q5RGqw+fzu tUiRYP3wQ1pb5GrwWdxXtkPf17dgFAhLUtjhaeTDbalYB/Oq3hDoR1D37uPnHZgO niu/RvYzTQzZB0feD05KZCS680c19zZXR56jovWy4a7PIexKlZjM5hf869vh+XkW ydJ82KDPyn5AJ/4oAZMVfcjc9mL6y3XNm3gGOZyCgKl59eH16XwQOOEnDIPmPAb0 EeDmsBsqwQ8wA8Ffsl+1xFAyKvnRTFQTgGy2K7sHhBv9CsBt8+3VKJEubHQ== 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= fm2; bh=Gnju2gqkljEkqjeaQ/fwfvNfZZW63XV1jRLBJAeOeCk=; b=JBOCMTaC ZgobrnqRIVqvwQ9W4n14lGbvBeNR0oZHNpRoWtekjoBhe5JW3allqOkzisHhhjvU 8nQ7Ffm9iWgE3FJTeRPZ4CYCS8bE7CWTj1h2qvy+dTcvQ4cP2hJUB/32IVboOKDO iviwNKJkUv005ZPb9q1fY1tf0W8oYoDzyWxx39rmujDqR2My6b2HY29+ExAHq+4f 9xfeXfoOLc6nxEAouFyCjf2X4y4fDHZH0Wz6xS8HGAB2Zh6Nl4F0fchRvp+mjrh/ 1XB9W6oBgRAw6W7fnmQ0E/Puw8ZqbFt+ZWXZVfvwV+qae///zmTqR+ZWuE/9TPZd ZLkU78trK8N6Gw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepuddtgedrvddugedrfeekrddvvdenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrd hnvght X-ME-Proxy: Received: from fv-az290-521.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net (unknown [104.214.38.22]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 16 May 2021 18:19:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2362252156603564825==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210516225558.D0CD93A1C4C@ietfa.amsl.com> Date: Sun, 16 May 2021 15:55:58 -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, 16 May 2021 22:56:05 -0000 --===============2362252156603564825== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 issues created: - group_context is passed into HPKE's aad instead of info (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/470=20 Pull requests ------------- * mlswg/mls-architecture (+2/-1/=F0=9F=92=AC0) 2 pull requests submitted: - Fixing outdated affiliation for contributor. (by cascremers) https://github.com/mlswg/mls-architecture/pull/79=20 - Reorganize section 3 (by cascremers) https://github.com/mlswg/mls-architecture/pull/78=20 1 pull requests merged: - Fixing outdated affiliation for contributor. https://github.com/mlswg/mls-architecture/pull/79=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2362252156603564825== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday May 16, 2021

Issues

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

1 issues created:

Pull requests

mlswg/mls-architecture (+2/-1/=F0=9F=92=AC0)

2 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============2362252156603564825==-- From nobody Wed May 19 05:56:07 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 2A7F13A0D1C for ; Wed, 19 May 2021 05:56:05 -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 XUHY5lZTcQF8 for ; Wed, 19 May 2021 05:56:00 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 F33D13A0D0B for ; Wed, 19 May 2021 05:55:59 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id l7so17912741ybf.8 for ; Wed, 19 May 2021 05:55:59 -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=g7c/L9biuaYHL8mMLs5WQbMfimJkO4PUMHi44BCdKqw=; b=gz//mR9MSZHiRuZlAuYkL5HwcUyMHeXV+3KIF5xLqZ6oEUeCBeegSTq0iGxLqKLlgh uYK9D/b41G6wUYQKBowjUO3FbpM4EoN0do58SyLO53vdncdcaxfAQR4yzQdZ46fZaCey a9LdsnHDZCzQ0GYtBH64CD4yfoy/h+padtltVOvKS/KZxawKopj7bMQn+cNRhKH9rjd4 TCwiUV8CGCO4QEevPVl03iTP12g1o93nk0gaQUTrJb4dI5tb1p7CY+Mn7w5cYoBFqkvH if3gdIUShfh4vTWlHzY6uLfdR7mPSzBqS5OVVpla1YBuvB4vpOL/thyRHop78KTpJ6hZ xh0g== 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=g7c/L9biuaYHL8mMLs5WQbMfimJkO4PUMHi44BCdKqw=; b=FIsWUN9Aoq+nWKHiNyc+mI9hCzVsVlbI7uFLz5FfVok23YK6E+GcpJ7bhS83SqZU6r 7lYoIfU8WvbB0ABmOpFW2PI8crDeVU2H4lHc59EeTm9ZXnf74xcm/QLw8NekNUIiSQxj Lw0LGnIjnImW9nE4bmqEi5GuDNsFzulYr4oxUeFJk/Qm9hr9/S8CnqsFmw6prvLBNIyE VVQMeRY+2QvbmaC/RZrFrYMd9mlgnRIcJX8RtdHSCd6c8mejALQBTb/5vcKsBlorWiCs sOFJ9eyS8ws7k1Kig0HT94FUqFfhRrkGUc/4TqRwtUQwDKDODtjWyAUpqcKu7kiRrF4N xfzA== X-Gm-Message-State: AOAM531Be5SKq/Z0eJrV6jwDsn9e5qtDV3XpJakZo7ypM5SQ+Nm506A1 abFvR/xUkN/TA+qSHOti///fWqdJB1mf1TJRqnBqgb0r4dxPlA== X-Google-Smtp-Source: ABdhPJxtpfgGiNz+aa9iw1UMiNREfTmMKrrEJrcMnfq/lWIaLRyQ6h4oOqERmmy2qwLjr/htA8EfqI6phYcts3H4JNM= X-Received: by 2002:a25:7382:: with SMTP id o124mr15012568ybc.112.1621428958180; Wed, 19 May 2021 05:55:58 -0700 (PDT) MIME-Version: 1.0 From: Tijana Klimovic Date: Wed, 19 May 2021 14:55:48 +0200 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000014b7f105c2ae593f" Archived-At: Subject: [MLS] RT array implementation motivation 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: Wed, 19 May 2021 12:56:05 -0000 --00000000000014b7f105c2ae593f Content-Type: text/plain; charset="UTF-8" Hello, I have only recently started to look into the MLS specification, and was wondering why the ratchet tree (RT) structure is chosen to be implemented with an array. From what I understand, the pointer-based tree where each node would contain the following information: struct { Node* sibling; Node* parent; Node* left_child; Node* right_child; Optional hpke_enc_pk; Optional hpke_enc_sk; Optional credential; Optional> parent_hash; Optional> unmerged_leaves; } Node would be more efficient than an array w.r.t. all operations supported by the RT. Many thanks. Tijana --00000000000014b7f105c2ae593f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have only recently started to = look into the MLS specification, and was wondering why the ratchet tree (RT= ) structure is chosen to be implemented with an array. From what I understa= nd, the pointer-based tree where each node would contain the following info= rmation:=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Node* sibling;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Node* parent;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Node* left_child;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Node* right_child;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = Optional<HPKEPublicEncKey> hpke_enc_pk;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Optional<HPKESecretEncKey> hpke_enc_sk;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Optional<Credential> credential;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Optional<vector<byte>> parent_hash;
=C2=A0 =C2=A0 =C2=A0= =C2=A0 Optional<vector<Node*>> unmerged_leaves;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 } Node=C2=A0

would be more e= fficient than an array w.r.t. all operations supported by the RT.=C2=A0

Many thanks.
Tijana
--00000000000014b7f105c2ae593f-- From nobody Wed May 19 06:25: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 3CB9E3A0E72 for ; Wed, 19 May 2021 06:25:16 -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, 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 w3ivWbphhssC for ; Wed, 19 May 2021 06:25:11 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 B25113A0E74 for ; Wed, 19 May 2021 06:25:11 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id k19so10069312qta.2 for ; Wed, 19 May 2021 06:25:11 -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=BpImCsU5Sh+NiP9yYeht6AMarYLGhgm7liKYwGCpv2Y=; b=Q2lnaaWiOLx2FfIc5dMlKOVFXCH4vhSx5sVz4v1O64RTz50B/dOjNH2N0uieCeuRx4 5g29OiRoJObpjxyC24ahAfDz0EpfD2bGo6dT2syqyH6m5Bi+vDtS1k5vMSuS0QstIGAX yKdxkJbMhU1sBvzxhxEytvpI6leldYQuwpzfk9+NoxqOjtrwBgQJsIKNpcxMcGl4DV/f 1uwb5iRBBG73piBSmz+pY5Vfatp9lzJMvlaG7gkfqTWU82bZyR3R8/JqpFzsv1xQmpJk zd4gPMz2YRtGtTfZbZYStwyqlkV5hlCn3yGyRL+0Tb/7Bs2PRIFaIN51fogmUqt8LYCx zEJg== 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=BpImCsU5Sh+NiP9yYeht6AMarYLGhgm7liKYwGCpv2Y=; b=mJTsZ5rw5vSGzEmZMPdbWjmY4jJM/0762JJP/rlXyqR5RJouVrDXUVTXIaWR0x1u3l 5vpXjiFh8J84bLJjJUlwKKqAIXxuQ90ehmfYqqBHmd35yj4H18E5ayhGiUidYdLfW8Y1 i3Yn8ACi+BI1wqganFHbRX5UjyzYtav2Tx7E/pP0AS+dF2MzwtO9ArQb6NPVwC5Dq1K3 nIFsMyOKkysl7R0P8cu3BJlvoUbBC39+iXT6lz12NfcPitS/RQLbgFD4mFpFE1uBuX1V iM4rPEUtiNyuvA3gc8M9i4y74i0M3FUzuuisFRR8VloVVK6N7ejX2tKengk0Il8wQMlh 5+Rw== X-Gm-Message-State: AOAM531PLRR02ctqEQ4koEAee39wqgSfH5fVzBLVaJU/+ClTeIYtA//3 cCktLb54ZFIsqhJ85L3ropY9uILsefyQO9GkrKqXct9TWI155w== X-Google-Smtp-Source: ABdhPJwHTZPE9r3ouZYln7l33N6cH9512eUz4C6KoUp26j3bKkh2394rzUVtDSAYtpah5Ol8ZJK7KmoFFahDi03Z6bM= X-Received: by 2002:ac8:574e:: with SMTP id 14mr11262313qtx.191.1621430710235; Wed, 19 May 2021 06:25:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 19 May 2021 09:24:59 -0400 Message-ID: To: Tijana Klimovic Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000083092005c2aec1c0" Archived-At: Subject: Re: [MLS] RT array implementation motivation 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: Wed, 19 May 2021 13:25:16 -0000 --00000000000083092005c2aec1c0 Content-Type: text/plain; charset="UTF-8" Hi Tijana, The specification doesn't require that the tree be implemented in a given way. Implementations are free to arrange their memory however they like. The array notation just gives us a simple way to assign each node in the tree an index. --Richard On Wed, May 19, 2021 at 8:56 AM Tijana Klimovic wrote: > Hello, > > I have only recently started to look into the MLS specification, and was > wondering why the ratchet tree (RT) structure is chosen to be implemented > with an array. From what I understand, the pointer-based tree where each > node would contain the following information: > > struct { > Node* sibling; > Node* parent; > Node* left_child; > Node* right_child; > Optional hpke_enc_pk; > Optional hpke_enc_sk; > Optional credential; > Optional> parent_hash; > Optional> unmerged_leaves; > } Node > > would be more efficient than an array w.r.t. all operations supported by > the RT. > > Many thanks. > Tijana > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000083092005c2aec1c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tijana,

The specification= doesn't require that the tree be implemented in a given way.=C2=A0 Imp= lementations are free to arrange their memory however they like.=C2=A0 The = array notation just gives us a simple way to assign each node in the tree a= n index.

--Richard

On Wed, May 19, 20= 21 at 8:56 AM Tijana Klimovic <tijana.klimovic97@gmail.com> wrote:
Hello,

I have only recently started to look into the MLS specification, and was w= ondering why the ratchet tree (RT) structure is chosen to be implemented wi= th an array. From what I understand, the pointer-based tree where each node= would contain the following information:=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Node* s= ibling;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Node* parent;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Node* left_child;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Node* right_chi= ld;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional<HPKEPublicEncKey> hpke_en= c_pk;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional<HPKESecretEncKey> hpke_= enc_sk;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional<Credential> credentia= l;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional<vector<byte>> parent= _hash;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Optional<vector<Node*>> u= nmerged_leaves;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } Node=C2=A0
<= br>
would be more efficient than an array w.r.t. all operations s= upported by the RT.=C2=A0

Many thanks.
T= ijana
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000083092005c2aec1c0-- From nobody Wed May 19 06:25:51 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 8829B3A0E7C for ; Wed, 19 May 2021 06:25:49 -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 8MMs10YSXOcO for ; Wed, 19 May 2021 06:25:44 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 A6F8F3A0E79 for ; Wed, 19 May 2021 06:25:44 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id b17so15379037ede.0 for ; Wed, 19 May 2021 06:25:44 -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=tpAuOZLZJhcOaWsGI3tjj+ZC9hKgwdqSli+nwx9XHJA=; b=aNYi9N+51XihMA1+fqAWfZdHB4IG15OPMoaeaZgnOl4eGVv2H0Un/06vcKUtk6ewGd PrPTKpzl32Bt3/77/dDw07O5UcE/wqaS4IGlAqQfh9qwBQy/ZnNnig55nfmkpaSO9RSl FTlL0Be7NN9kbS+64bUiTDEwQi25p7pYPFEV0= 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=tpAuOZLZJhcOaWsGI3tjj+ZC9hKgwdqSli+nwx9XHJA=; b=bQdWAOo0//zqjdaL5Sw5XmIMm2a0wlTNqxcTDVxh5hDKirUtdPBflZ5W9zB2zfEnCX fIvaQezbp4YkJwxlmhI2/Z7buqIx+gygCSSflMRG7E6VmPSfNovNYUs2IDBPxpyQo1mr ypVZzXvKYye1iycSLeaFMxeXMAttNgCwsX3j9CtkUvwLfV+LKY+ESGAqyGADsc7QvP6Y 0NHY1apbowuPLKQWTYOLNyUAXk+JZP4XJTolALVou9fweWe6XydcjE6vZtxZNyXoVnJc Q+A5d1halfuy1a+OxdtN1xp8+vVDqBTj3bb92yNkuzIesbNu/r1tjhRTRX1+89wdFq/A dWqQ== X-Gm-Message-State: AOAM533/8v9G1c2kD/I27o6fsv0gHbbeEK53pHflvKMLD3Q0EabLs4b2 F8CDpcV4hwXEPdT8M4gG/GMUrg== X-Google-Smtp-Source: ABdhPJxGw9IlUDdYXhJKZoynrUczMCmvsFXONjMl22V0r+W0yKvz/WiqcfrhPqt6oX6U8sCi882P6Q== X-Received: by 2002:a05:6402:50cd:: with SMTP id h13mr13179779edb.111.1621430742279; Wed, 19 May 2021 06:25:42 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id c10sm8936797eds.90.2021.05.19.06.25.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 May 2021 06:25:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Raphael Robert In-Reply-To: Date: Wed, 19 May 2021 15:25:40 +0200 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tijana Klimovic X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] RT array implementation motivation 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: Wed, 19 May 2021 13:25:50 -0000 Hi Tijana, At the end of the day you can use whatever implementation works best of = course. The array approach has a few benefits though: - it=E2=80=99s language agnostic, something that=E2=80=99s important = for IETF - it gives you a serialisation format for free (quite practical for the = ratchet tree extension) - it let=E2=80=99s you use references to nodes in the tree that are = used in the Secret Tree to derive secrets for example - it makes it easy to add and remove nodes without having to change = anything in neighbouring nodes =46rom a performance standpoint, using the tree math provided should = also be reasonably fast. If you have some benchmarks to share that prove = otherwise, it would be interesting to look into it. Lastly, pointers can be great, but they can also be quite dangerous if = implemented wrongly. Hope this helps, Raphael > On 19. May 2021, at 14:55, Tijana Klimovic = wrote: >=20 > Hello, >=20 > I have only recently started to look into the MLS specification, and = was wondering why the ratchet tree (RT) structure is chosen to be = implemented with an array. =46rom what I understand, the pointer-based = tree where each node would contain the following information:=20 >=20 > struct { > Node* sibling; > Node* parent; > Node* left_child; > Node* right_child; > Optional hpke_enc_pk; > Optional hpke_enc_sk; > Optional credential; > Optional> parent_hash; > Optional> unmerged_leaves; > } Node=20 >=20 > would be more efficient than an array w.r.t. all operations supported = by the RT.=20 >=20 > Many thanks. > Tijana > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed May 19 08:12:04 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 885C43A13D5 for ; Wed, 19 May 2021 08:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 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, URIBL_BLOCKED=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 SMG78FDI2Sne for ; Wed, 19 May 2021 08:11:54 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 3C1193A13D3 for ; Wed, 19 May 2021 08:11:49 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id b13so17153657ybk.4 for ; Wed, 19 May 2021 08:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vUGwzibPodRrLRLDYB2YSSc3CoqmcIwQ3kjfn1TO/Xg=; b=ijQXIMJumcNS4262u3eXq4wPTwWq9DUh2XJDiot3AogDbZu5uOzgSowrE8wssy/7J6 zVe0f1kV6R6sYyh4pJ+u9KPK6wocbj53iJsrD6crXTv5pTrGaCx/0JjzE6Q5Wk9/tttL iu0h02lENoVyytw26DU9IS0ZyGGV75of/0GLHZOxw6Jiy0ms5feOwa2Pa0hydHzPQYI9 mTWjpLIuu83hoeNDNac0HHWPOLZPdfHv4BjOxzONHnOKcTBym+hQN90F+lm7UcMJOfUw 0rYv4h1Psi16ZDMW+DK55lsD1pmRg42DPFYH5gHlvzDgt9NPUGpzh2qJex4wmyz/4pvO CO4g== 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=vUGwzibPodRrLRLDYB2YSSc3CoqmcIwQ3kjfn1TO/Xg=; b=Ig2SElAw4E8tQD9MFCALJqajFj4fs6ozVXAEbkLcUEupucRHufH/tYKPZYuHB5Gewv Y9fxwi0RC8NObrjZHA2+TMujc1PZ9fHAIahxY8eS07ig7wsLtv3kcNizKRxOSQQd6wRI xZDtymd9BgL0FnSjZFMSKQFQVQU3m9+RsrLLd6koenHTW3tsvLh5M/u2wEN1fPFpXmV1 k9trEwsJOsVBibaQg78qnFmvxS4eCfcynTFtDAvUbbLVPfPcpU+szAscP7B5PSVCvfWd Ad1yjjNsh8hNqCVJAv4KEq8TahzAWec6tzhd6H6IHl5ES19gPiserd2WocZXIgXYszBy ArDw== X-Gm-Message-State: AOAM53267OcqNxcMBFHe31j8Xln+vp13cZfaCAzRrCMaiuAXXin7xeUR WYWndPvfM2DU36X4dBaKqa9LUYs8RuBc7/AeKyg= X-Google-Smtp-Source: ABdhPJy3TA+OAo+Tko7xdSBVXCSvgpxWPnxHyszwoHbTwbV5lqaJPYKzbFxA8fj3pb/jRyVwO40m+oPwLxwrTe494Tg= X-Received: by 2002:a25:5d0b:: with SMTP id r11mr15728997ybb.380.1621437107812; Wed, 19 May 2021 08:11:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tijana Klimovic Date: Wed, 19 May 2021 17:11:37 +0200 Message-ID: To: Raphael Robert Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d63c5d05c2b03eb1" Archived-At: Subject: Re: [MLS] RT array implementation motivation 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: Wed, 19 May 2021 15:12:00 -0000 --000000000000d63c5d05c2b03eb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Thank you for your answers to the question about RT. I do have some more questions about the choice of framing if you don't mind me asking. I tried to find answers to them in the group but didn't have much luck. Namely, in the MLSPlaintext structure, you have the membership_tag included that MACs everything above it in the MLSPlaintext structure with the membership_key. I don't see how the framing is any less secure without it being there, since the signature covers everything above itself, hence only not including the two mac tags. Furthermore, it's not clear to me which membership_key is used to construct it in case of commit messages. I would think that it would be the membership_key deduced from the GroupContext for the new epoch, after the proposals and UpdatePath have been applied so that joiners can compute the epoch_secret. Is this correct? Lastly, I wanted to ask what is the purpose of having the parent_hash extension? As far as I understand, it only must be included in the leafKeyPackage of the UpdatePath structure and it serves to bind the new HPKE public keys of all nodes on the path from the leaf(committer) with the leafKeyPackage to the root and the set of HPKE public keys to which PK's secret key was encrypted. But the commit contains the confirmation_tag that confirms that the members of the group have arrived at the same state of the group. So the confirmation_tag would bind the same as the parent_hash and even more. Many thanks. Tijana On Wed, 19 May 2021 at 15:25, Raphael Robert wrote= : > Hi Tijana, > > At the end of the day you can use whatever implementation works best of > course. The array approach has a few benefits though: > - it=E2=80=99s language agnostic, something that=E2=80=99s important for= IETF > - it gives you a serialisation format for free (quite practical for the > ratchet tree extension) > - it let=E2=80=99s you use references to nodes in the tree that are used= in the > Secret Tree to derive secrets for example > - it makes it easy to add and remove nodes without having to change > anything in neighbouring nodes > > From a performance standpoint, using the tree math provided should also b= e > reasonably fast. If you have some benchmarks to share that prove otherwis= e, > it would be interesting to look into it. > > Lastly, pointers can be great, but they can also be quite dangerous if > implemented wrongly. > > Hope this helps, > > Raphael > > > On 19. May 2021, at 14:55, Tijana Klimovic > wrote: > > > > Hello, > > > > I have only recently started to look into the MLS specification, and wa= s > wondering why the ratchet tree (RT) structure is chosen to be implemented > with an array. From what I understand, the pointer-based tree where each > node would contain the following information: > > > > struct { > > Node* sibling; > > Node* parent; > > Node* left_child; > > Node* right_child; > > Optional hpke_enc_pk; > > Optional hpke_enc_sk; > > Optional credential; > > Optional> parent_hash; > > Optional> unmerged_leaves; > > } Node > > > > would be more efficient than an array w.r.t. all operations supported b= y > the RT. > > > > Many thanks. > > Tijana > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > --000000000000d63c5d05c2b03eb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for your answers to th= e question about RT. I do have some more questions about the choice of fram= ing if you don't mind me asking. I tried to find answers to them in the= group but didn't have much luck.=C2=A0

Namely= , in the MLSPlaintext structure, you have the membership_tag included that = MACs everything above it in the MLSPlaintext structure with the membership_= key. I don't see how the framing is any less secure without it being th= ere, since the signature covers everything=C2=A0above itself, hence only no= t including the two mac tags.=C2=A0

Furthermore, i= t's not clear to me which membership_key is used to construct it in cas= e of commit messages. I would think that it would be the membership_key ded= uced from the GroupContext for the new epoch, after the proposals and Updat= ePath have been applied so that joiners can compute the epoch_secret. Is th= is correct?

Lastly, I wanted to ask what is the pu= rpose of having the parent_hash extension?=C2=A0

A= s far as I understand, it only must be included in the leafKeyPackage of th= e UpdatePath structure and it serves to bind=C2=A0the new HPKE public keys = of all nodes on the path from the leaf(committer) with the leafKeyPackage t= o the root and the set of HPKE public keys to which PK's secret key was= encrypted. But the commit contains the confirmation_tag that=C2=A0confirms= that the members of the group have arrived at the same state of the group.= So the confirmation_tag would bind the same as the parent_hash and even mo= re.

Many thanks.
Tijana

<= div class=3D"gmail_quote">
On Wed, 19 = May 2021 at 15:25, Raphael Robert <ietf@raphaelrobert.com> wrote:
Hi Tijana,

At the end of the day you can use whatever implementation works best of cou= rse. The array approach has a few benefits though:
=C2=A0- it=E2=80=99s language agnostic, something that=E2=80=99s important = for IETF
=C2=A0- it gives you a serialisation format for free (quite practical for t= he ratchet tree extension)
=C2=A0- it let=E2=80=99s you use references to nodes in the tree that are u= sed in the Secret Tree to derive secrets for example
=C2=A0- it makes it easy to add and remove nodes without having to change a= nything in neighbouring nodes

>From a performance standpoint, using the tree math provided should also be = reasonably fast. If you have some benchmarks to share that prove otherwise,= it would be interesting to look into it.

Lastly, pointers can be great, but they can also be quite dangerous if impl= emented wrongly.

Hope this helps,

Raphael

> On 19. May 2021, at 14:55, Tijana Klimovic <tijana.klimovic97@gmail.com&g= t; wrote:
>
> Hello,
>
> I have only recently started to look into the MLS specification, and w= as wondering why the ratchet tree (RT) structure is chosen to be implemente= d with an array. From what I understand, the pointer-based tree where each = node would contain the following information:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Node* sibling;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Node* parent;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Node* left_child;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Node* right_child;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional<HPKEPublicEncKey> hpke= _enc_pk;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional<HPKESecretEncKey> hpke= _enc_sk;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional<Credential> credential= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional<vector<byte>> pa= rent_hash;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional<vector<Node*>> u= nmerged_leaves;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} Node
>
> would be more efficient than an array w.r.t. all operations supported = by the RT.
>
> Many thanks.
> Tijana
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

--000000000000d63c5d05c2b03eb1-- From nobody Thu May 20 07:33:09 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 87D3A3A18D8 for ; Thu, 20 May 2021 07:33:07 -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_DNSWL_BLOCKED=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=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 YlpZFrNx4Skc for ; Thu, 20 May 2021 07:33:01 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 732663A18D6 for ; Thu, 20 May 2021 07:33:01 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id et19so18596001ejc.4 for ; Thu, 20 May 2021 07:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AaLGr9Z1fcvz3apFiJkodCxXvo1jWJTgNpSm4DrFvms=; b=O4AkeOl5nbr48gYlh95yzSRysxnFF7UqaLy7l6JzA6NtTMPiuMqzrwNw2n7+qhDbdW d63Fw0Du4bQd52rfMaptEJ8iqMYI1jw/3+GMAyu86tI3fobMLzYQYpYb8PGomV9xrWTY lzc0ZPRV4rA9ucOreOD2nhy13874KfXzG7oYE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AaLGr9Z1fcvz3apFiJkodCxXvo1jWJTgNpSm4DrFvms=; b=XygSNjtQdL6SkzFE1wdQ1M0jNOx0p5HcPq8rFRO44miF8BDzj85IJTm6ps+/HQOBS2 TlGgj/U1DR3m5puZ5/wOGwOrU826AbL6UExUo6TEmlsOfp+5sE7ZkUOHhn/kp8y4bv2a 14cU36NRRjU9uplycaYrclp5b9LsAUk+tp+FBl6QHgMfjsY+XglPHvfjQDg3R2kI6xjs Gg5C3rXt/KToay8RSt1W1pWmhePk6G7M822Vx80rEPRm0BfRw7Eh8w+WA2keTWpwmlKy un7ycXYs1CCAJaW69I8C3aSD3ShA+j0o18YJ74CxCj6PnJKksyKMAcDbW2drWm0hewRw KqLA== X-Gm-Message-State: AOAM530KJo3fWxgT6JG1Gbffc2KRaSNHUeTcypJifSXCWeLHsNB4UmJ0 FU1JK/s3rUS9SRJl1xdmUsckPg== X-Google-Smtp-Source: ABdhPJzeIzkBGEuKmNtEHEFFMKJJc+/pK5ML8fo8A2w+bNlMR53Eb8M9MILhwVT7VlICKgDcR8SK1g== X-Received: by 2002:a17:906:c211:: with SMTP id d17mr5003453ejz.247.1621521174507; Thu, 20 May 2021 07:32:54 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id u14sm1664159edy.47.2021.05.20.07.32.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 May 2021 07:32:53 -0700 (PDT) From: Raphael Robert Message-Id: <9366F236-5BE1-463A-8B88-E3B52894BEA3@raphaelrobert.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_38AE23C4-4891-45BB-8B44-6C5EBFBE83DB" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Thu, 20 May 2021 16:32:52 +0200 In-Reply-To: Cc: mls@ietf.org To: Tijana Klimovic References: X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] RT array implementation motivation 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, 20 May 2021 14:33:08 -0000 --Apple-Mail=_38AE23C4-4891-45BB-8B44-6C5EBFBE83DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Namely, in the MLSPlaintext structure, you have the membership_tag = included that MACs everything above it in the MLSPlaintext structure = with the membership_key. I don't see how the framing is any less secure = without it being there, since the signature covers everything above = itself, hence only not including the two mac tags.=20 The signature only proves the signer is in possession of the private = signature key. The membership_tag also proves that the member has access = to group secrets and that means that it is a member of the group from a = cryptographic standpoint. > Furthermore, it's not clear to me which membership_key is used to = construct it in case of commit messages. I would think that it would be = the membership_key deduced from the GroupContext for the new epoch, = after the proposals and UpdatePath have been applied so that joiners can = compute the epoch_secret. Is this correct? The membership_key is an output of the key schedule as described in 8. = It is used to compute the membership_tag as described in 9.1. > Lastly, I wanted to ask what is the purpose of having the parent_hash = extension?=20 >=20 > As far as I understand, it only must be included in the leafKeyPackage = of the UpdatePath structure and it serves to bind the new HPKE public = keys of all nodes on the path from the leaf(committer) with the = leafKeyPackage to the root and the set of HPKE public keys to which PK's = secret key was encrypted. But the commit contains the confirmation_tag = that confirms that the members of the group have arrived at the same = state of the group. So the confirmation_tag would bind the same as the = parent_hash and even more. The parent_hash is intended to be checked by new joiners. This way new = joiners can come to the conclusion that existing members agreed on (some = of) the public tree in the past. New joiners cannot derive that from the = confirmation_tag when they process a Welcome message, because they = don=E2=80=99t have all of the past transcript. Raphael >=20 > Many thanks. > Tijana >=20 > On Wed, 19 May 2021 at 15:25, Raphael Robert > wrote: > Hi Tijana, >=20 > At the end of the day you can use whatever implementation works best = of course. The array approach has a few benefits though: > - it=E2=80=99s language agnostic, something that=E2=80=99s important = for IETF > - it gives you a serialisation format for free (quite practical for = the ratchet tree extension) > - it let=E2=80=99s you use references to nodes in the tree that are = used in the Secret Tree to derive secrets for example > - it makes it easy to add and remove nodes without having to change = anything in neighbouring nodes >=20 > =46rom a performance standpoint, using the tree math provided should = also be reasonably fast. If you have some benchmarks to share that prove = otherwise, it would be interesting to look into it. >=20 > Lastly, pointers can be great, but they can also be quite dangerous if = implemented wrongly. >=20 > Hope this helps, >=20 > Raphael >=20 > > On 19. May 2021, at 14:55, Tijana Klimovic = > = wrote: > >=20 > > Hello, > >=20 > > I have only recently started to look into the MLS specification, and = was wondering why the ratchet tree (RT) structure is chosen to be = implemented with an array. =46rom what I understand, the pointer-based = tree where each node would contain the following information:=20 > >=20 > > struct { > > Node* sibling; > > Node* parent; > > Node* left_child; > > Node* right_child; > > Optional hpke_enc_pk; > > Optional hpke_enc_sk; > > Optional credential; > > Optional> parent_hash; > > Optional> unmerged_leaves; > > } Node=20 > >=20 > > would be more efficient than an array w.r.t. all operations = supported by the RT.=20 > >=20 > > Many thanks. > > Tijana > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls = >=20 --Apple-Mail=_38AE23C4-4891-45BB-8B44-6C5EBFBE83DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Namely, in the MLSPlaintext = structure, you have the membership_tag included that MACs everything = above it in the MLSPlaintext structure with the membership_key. I don't = see how the framing is any less secure without it being there, since the = signature covers everything above itself, hence only not including = the two mac tags. 

The signature only proves the signer is in possession = of the private signature key. The membership_tag also proves that the = member has access to group secrets and that means that it is a member of = the group from a cryptographic standpoint.

Furthermore, it's not clear to me which = membership_key is used to construct it in case of commit messages. I = would think that it would be the membership_key deduced from the = GroupContext for the new epoch, after the proposals and UpdatePath have = been applied so that joiners can compute the epoch_secret. Is this = correct?

The = membership_key is an output of the key schedule as described in 8. It is = used to compute the membership_tag as described in 9.1.

Lastly, I wanted to ask what is the purpose = of having the parent_hash extension? 

As far as I understand, it only must be = included in the leafKeyPackage of the UpdatePath structure and it serves = to bind the new HPKE public keys of all nodes on the path from the = leaf(committer) with the leafKeyPackage to the root and the set of HPKE = public keys to which PK's secret key was encrypted. But the commit = contains the confirmation_tag that confirms that the members of the = group have arrived at the same state of the group. So the = confirmation_tag would bind the same as the parent_hash and even = more.

The parent_hash = is intended to be checked by new joiners. This way new joiners can come = to the conclusion that existing members agreed on (some of) the public = tree in the past. New joiners cannot derive that from the = confirmation_tag when they process a Welcome message, because they = don=E2=80=99t have all of the past transcript.

Raphael


Many thanks.
Tijana

On Wed, 19 = May 2021 at 15:25, Raphael Robert <ietf@raphaelrobert.com> wrote:
Hi Tijana,

At the end of the day you can use whatever implementation works best of = course. The array approach has a few benefits though:
 - it=E2=80=99s language agnostic, something that=E2=80=99s = important for IETF
 - it gives you a serialisation format for free (quite practical = for the ratchet tree extension)
 - it let=E2=80=99s you use references to nodes in the tree that = are used in the Secret Tree to derive secrets for example
 - it makes it easy to add and remove nodes without having to = change anything in neighbouring nodes

=46rom a performance standpoint, using the tree math provided should = also be reasonably fast. If you have some benchmarks to share that prove = otherwise, it would be interesting to look into it.

Lastly, pointers can be great, but they can also be quite dangerous if = implemented wrongly.

Hope this helps,

Raphael

> On 19. May 2021, at 14:55, Tijana Klimovic <tijana.klimovic97@gmail.com> wrote:
>
> Hello,
>
> I have only recently started to look into the MLS specification, = and was wondering why the ratchet tree (RT) structure is chosen to be = implemented with an array. =46rom what I understand, the pointer-based = tree where each node would contain the following information:
>
>         struct {
>         Node* sibling;
>         Node* parent;
>         Node* left_child;
>         Node* right_child;
>         Optional<HPKEPublicEncKey> = hpke_enc_pk;
>         Optional<HPKESecretEncKey> = hpke_enc_sk;
>         Optional<Credential> = credential;
>         Optional<vector<byte>> = parent_hash;
>        =  Optional<vector<Node*>> unmerged_leaves;
>         } Node
>
> would be more efficient than an array w.r.t. all operations = supported by the RT.
>
> Many thanks.
> Tijana
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls


= --Apple-Mail=_38AE23C4-4891-45BB-8B44-6C5EBFBE83DB-- From nobody Fri May 21 07:05:46 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 414443A114B for ; Fri, 21 May 2021 07:05:44 -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 G7XVI_Sne9CU for ; Fri, 21 May 2021 07:05:39 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 CE7BF3A114C for ; Fri, 21 May 2021 07:05:38 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id t20so15327482qtx.8 for ; Fri, 21 May 2021 07:05:38 -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:date:references :to:in-reply-to:message-id; bh=hEjee+DyFYzVhLJzIrUqX+5joEfzCM2OiLxS5d2zjFU=; b=VlWKGI7FFJFSi0HlkCzvLaUC/sNT1BY9kVmj/7FEU8nZ9CyYiT/a/OPxpypVTKjm5n hzmcEaNblea504yfgi2y++6L1+KjLKF4y6/w9f9wRwMNoDb7NutGGgdRabcIGWrHMS6c gtmB6bi8yMr7wbz0RrOp1a7wkzgztL5juYzZQ= 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:date:references:to:in-reply-to:message-id; bh=hEjee+DyFYzVhLJzIrUqX+5joEfzCM2OiLxS5d2zjFU=; b=N962ddxSrbuzuGwLcBiMQdg5G2rlug487LPgq9BLwSIuQBz4i/NCKVdUkijqtRzhoJ drfEAfE3/ZqXCnLT9+qIt2yjX4xBc+57aAAt8VRNPaaArLz9rEw2NVnPV7OlcSFXkBsm gKNiV5NdbiyK6d8uobXvGGEx096aw/KDvuY/hNJkQf7EuDAGcSrST1h/RadLWel2rwZ/ s7sm0+hyowbmShK1ASmmFLYEJMN8ZZxH3YCXLr7V02olYJ4rrOvUjXLPAwjNvi03x9aX aXFAFYwyBXHj+d2vHuFfiLM4+aGsJDYabqzqacaU3vn4/7QqRw/UfQynu1Gw1fyXJKDW sVkA== X-Gm-Message-State: AOAM533xJIjXycascLMwc+YSERszNoXW4bhjpGb+tFNLf5Q//fUtGAVB 8UZTZivFDlmaw397O/kWcRsCrQ5gJ9/PXw== X-Google-Smtp-Source: ABdhPJwXKTA8gvwveMdoYQ4d2yvbujexVExO1Xo9+fiuvcX3YUO6vRPDcGb1H3t4TSYG8K1vnfN78Q== X-Received: by 2002:ac8:574e:: with SMTP id 14mr11685843qtx.191.1621605936009; Fri, 21 May 2021 07:05:36 -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 h5sm3689796qkl.83.2021.05.21.07.05.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 May 2021 07:05:35 -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.80.0.2.43\)) Date: Fri, 21 May 2021 10:05:34 -0400 References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> To: MLS List In-Reply-To: <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> Message-Id: <4614A3C1-8461-48F8-AD53-C1399BC5F673@sn3rd.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Reminder: Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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, 21 May 2021 14:05:44 -0000 Just another FYI! > On May 12, 2021, at 08:26, Sean Turner wrote: >=20 > Just an FYI that we have a meeting scheduled for next week. >=20 > spt >=20 >> On May 7, 2021, at 13:33, Sean Turner wrote: >>=20 >> Meeting Scheduled! >>=20 >> More information can also be found here: >> https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls >>=20 >> spt >>=20 >>> On May 7, 2021, at 12:39, IESG Secretary = wrote: >>>=20 >>> The Messaging Layer Security (mls) WG will hold >>> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>>=20 >>> Agenda: >>> GitHub issues and pull requests related to -protocol and = -architecture. >>>=20 >>> Information about remote participation: >>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >>>=20 >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>=20 >=20 From nobody Fri May 21 07:59:54 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 37E923A13A7 for ; Fri, 21 May 2021 07:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 0mJhlioBfKgj for ; Fri, 21 May 2021 07:59:47 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 631863A13A6 for ; Fri, 21 May 2021 07:59:45 -0700 (PDT) IronPort-Data: =?us-ascii?q?A9a23=3AUO/Bt6yygUSrudKaovx6t+cAxCrEfRIJ4+MujC/?= =?us-ascii?q?XYbTApG9wgzFVyGEbCG6FMvnYNmD1fIt3bo2w9UMA6pTczYdiHQtv/xmBbVoa8?= =?us-ascii?q?JufXYzxwmTYZn7JcJWbFCqL1yivAzX5BJhcokT0+1H9aNANkVEmjfvRHuemUba?= =?us-ascii?q?dUsxMbVQMpBkJ2EsLd9ER0tYAbeiRW2thiPuqyyHtEAfNNw1cbgr435m+RCZH5?= =?us-ascii?q?5wejt+3UmsWPpintHeG/5Uc4Ql2yauZdxMUSaEMdgK2qnqq8V23wo/Z109F5tK?= =?us-ascii?q?NibPnakYOQ7PUIU6HkmJSVsBOgDAS92prj/h9baJFLx4J011lnPgooDlJnZ+5U?= =?us-ascii?q?xspP67Bie0bFRNYGjtxNLNP/pfGJ2K+uIqd1SUqdlOxm6QyVBpoYN1wFuFfRDs?= =?us-ascii?q?mGeYjADUJdTiCiv64hrWhRYFRam4LRCXwFNNO/yg9k3SAVa9jGM6bBb/H+5lew?= =?us-ascii?q?TI9nMFFFPzaaowXc1JSgN37S0UnEj8q5FgWwI9EXkXCTgA=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Af+uAKq8C3jjPW9HlPL5uk+DjI+orL9Y04lQ7?= =?us-ascii?q?vn2ZKCYlEPBw8vrFoB11726TtN98YgBCpTn/AtjmfZqsz+8R3WB5B97LN2nbUQ?= =?us-ascii?q?OTTb2KhrGSpwEIdReOj9K1Fp0NT0G9MrDN5JRB4voSmDPIa+rICePozJyV?= X-IronPort-AV: E=Sophos;i="5.82,319,1613430000"; d="scan'208,217";a="509403658" Received: from 89-156-101-160.rev.numericable.fr (HELO smtpclient.apple) ([89.156.101.160]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2021 16:59:42 +0200 From: Karthik Bhargavan Content-Type: multipart/alternative; boundary="Apple-Mail=_015259A4-CBA8-4492-B018-6766EDC48C32" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 21 May 2021 16:59:41 +0200 References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> <4614A3C1-8461-48F8-AD53-C1399BC5F673@sn3rd.com> To: MLS List In-Reply-To: <4614A3C1-8461-48F8-AD53-C1399BC5F673@sn3rd.com> Message-Id: <6B8101F5-A54A-429A-82B0-5386E321F525@inria.fr> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [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: Fri, 21 May 2021 14:59:52 -0000 --Apple-Mail=_015259A4-CBA8-4492-B018-6766EDC48C32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello All, Th=C3=A9ophile, Benjamin, and I have been writing a formal specification = of MLS in F* and we=E2=80=99re happy to report a compleger interoperable = spec that (with Franziskus=E2=80=99 help) shares test vectors with = OpenMLS. In the course of writing this specification, we observed several = potential improvements in the way MLS does things, and this email is = about the first of these. Subsequent emails will have other = questions/comments. The way we store unmerged leaves in the ratchet tree is sub-optimal = since it stores a lot of redundant information. In the worst case, a tree can have n/2 unmerged leaves (read the end of = this email to see how we obtained this number). Consequently, the total size of the ratchet tree can be as big as = 2*n*log(n) + 4*n bytes (for n participants), and is never lower than 4*n = bytes. This is unfortunate, since the unmerged nodes optimization has now = bloated our tree to O(n logn) from O(n). Consequently, the welcome message/initial tree and local storage is now = O(n log n). For more precision, in the rest of this email, we won't say that "a leaf = l is unmerged", but "a leaf l is unmerged at a node n", meaning that = `n` is an ancestor of the leaf `l` and the member at the leaf `l` = doesn't know the node secret at `n`. Then, a leaf `l` is "unmerged=E2=80=9D (in the sense of the MLS spec) = iff. there exists a node `n` such that this leaf `l` is unmerged for = `n`. In the current MLS spec, we store the index of a leaf `l` at each = ancestor node `n` such that `l` is unmerged for `n`. To see why this results in quite a bit of storage redundancy, observe = the following property: If a leaf `l` is unmerged for the parent of a = node `n`, then `l` is also unmerged for `n`. Given this observation, we can optimize the unmerged leaves design to = bring the tree size back to O(n). Solution 1 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 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) =3D 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. Solution 2 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 An alternative, which we prefer, is to get rid of the unmerged leaves = array entirely and replace them by epoch numbers: - for each leaf, store the epoch of its creation in the tree (when the = leaf was added), - for each parent node, store the epoch at which it was last updated. Then, a leaf `l` is unmerged for node `n` iff. n.last_update_epoch < = l.creation_epoch. Finding the list of unmerged leaves at a node then becomes part of tree = resolution, and a member can pre-compute and store this array if it = likes. In this design, we will store a 64-bit epoch number at each leaf and = each parent node, thus it uses 8*2*n =3D 16*n bytes. We believe that having an epoch number documenting the last update time = of each node is in itself a useful feature for debugging and for = security analysis. In our model, it makes stating secrecy and authentication invariants = easier. Solution 2+ =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 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 =3D = 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 =3D 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 =3D l.last_update_epoch, - if `l` is not unmerged for `n`, then n.last_update_epoch >=3D = l.last_update_epoch (because when `l` is updated, it updates all the = nodes above it). This uses 8*n + 1*n =3D 9*n bytes for the whole tree. Comments are welcome, and do please correct us if we misunderstood = something. In our opinion, it would be great to simplify the tree data structure = and compress its size back to O(n) at the same time. Best regards, Th=C3=A9ophile, Benjamin, and Karthik Appendix : How to create a tree with n/2 unmerged leaves? First, add n participants to the tree. Then, remove the participants with odd leaf index. Then, generate an update path from every participant with even leaf = index (this ensures that there are no blank nodes) Then, add new participants in leaves with odd leaf index, without = regenerating the group secret. Every leaf with odd leaf index will be present in the `unmerged_leaves` = array on all the nodes above it, so at each level of the tree there are = n/2 unmerged leaves stored, so the whole tree will store 4*(n/2)*log(n) = =3D 2*n*log(n) bytes of information. We can=E2=80=99t have a tree with more unmerged leaves, because a node = at level 1 can't have both its children is its `unmerged_leaves` array, = otherwise this node would be blank. > On 21 May 2021, at 16:05, Sean Turner wrote: >=20 > Just another FYI! >=20 >> On May 12, 2021, at 08:26, Sean Turner wrote: >>=20 >> Just an FYI that we have a meeting scheduled for next week. >>=20 >> spt >>=20 >>> On May 7, 2021, at 13:33, Sean Turner wrote: >>>=20 >>> Meeting Scheduled! >>>=20 >>> More information can also be found here: >>> https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls >>>=20 >>> spt >>>=20 >>>> On May 7, 2021, at 12:39, IESG Secretary = wrote: >>>>=20 >>>> The Messaging Layer Security (mls) WG will hold >>>> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>>>=20 >>>> Agenda: >>>> GitHub issues and pull requests related to -protocol and = -architecture. >>>>=20 >>>> Information about remote participation: >>>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >>>>=20 >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>=20 >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_015259A4-CBA8-4492-B018-6766EDC48C32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hello All,

Th=C3=A9ophile, Benjamin, and I have been writing = a formal specification of MLS in F* and we=E2=80=99re happy to report a = compleger interoperable spec that (with Franziskus=E2=80=99 help) shares = test vectors with OpenMLS.
In the course of writing this = specification, we observed several potential improvements in the way MLS = does things, and this email is about the first of these. Subsequent = emails will have other questions/comments.

The way we store unmerged leaves in the ratchet = tree is sub-optimal since it stores a lot of redundant = information.
In the worst case, a tree can = have n/2 unmerged leaves  (read the end of this email to see how we = obtained this number).
Consequently, the = total size of the ratchet tree can be as big as 2*n*log(n) + 4*n bytes = (for n participants), and is never lower than 4*n = bytes.
This is unfortunate, since the = unmerged nodes optimization has now bloated our tree to O(n logn) from = O(n).
Consequently, the welcome = message/initial tree and local storage is now O(n log = n).

For more precision, in the rest of this email, we won't say = that "a leaf  l is unmerged", but "a leaf l is unmerged at a node = n", meaning that `n` is an ancestor of the leaf `l` and the member at = the leaf `l` doesn't know the node secret at `n`.
Then, a leaf `l` is "unmerged=E2=80=9D (in = the sense of the MLS spec) iff. there exists a node `n` such that this = leaf `l` is unmerged for `n`.

In the current MLS spec, we store the index of a = leaf `l` at each ancestor node `n` such that `l` is unmerged for = `n`.
To see why this results in quite a bit = of storage redundancy, observe the following property:  If a leaf `l` is unmerged for the parent of a node `n`, = then `l` is also unmerged for `n`.
Given this = observation, we can optimize the unmerged leaves design to bring the = tree size back to O(n).

Solution = 1
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

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) =3D= 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.

Solution 2
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

An alternative, which we prefer, is to get = rid of the unmerged leaves array entirely and replace them by epoch = numbers:
 - for each = leaf, store the epoch of its creation in the tree (when the leaf was = added),
 - for each parent = node, store the epoch at which it was last updated.
Then, a leaf `l` is unmerged for node `n` = iff. n.last_update_epoch < l.creation_epoch.
Finding the list of unmerged leaves at a = node then becomes part of tree resolution, and a member can pre-compute = and store this array if it likes.

In this design, we will store a 64-bit = epoch number at each leaf and each parent node, thus it uses 8*2*n =3D = 16*n bytes.
We believe that having an epoch = number documenting the last update time of each node is in itself a = useful feature for debugging and for security analysis.
In our model, it makes stating secrecy and authentication = invariants easier.

Solution 2+
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94<= /font>

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 =3D = 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 =3D = 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 =3D = l.last_update_epoch,
- if `l` is = not unmerged for `n`, then n.last_update_epoch >=3D = l.last_update_epoch (because when `l` is updated, it updates all the = nodes above it).
This uses 8*n + = 1*n =3D 9*n bytes for the whole tree.

Comments are welcome, and do please = correct us if we misunderstood something.
In our = opinion, it would be great to simplify the tree data structure and = compress its size back to O(n) at the same time.

Best regards,
Th=C3=A9ophile, Benjamin, and Karthik

Appendix : How to = create a tree with n/2 unmerged leaves?

First, add n participants to the = tree.
Then, remove the = participants with odd leaf index.
Then, generate an update path from every participant with = even leaf index (this ensures that there are no blank nodes)
Then, add new participants in leaves with = odd leaf index, without regenerating the group secret.
Every leaf with odd leaf index will be = present in the `unmerged_leaves` array on all the nodes above it, so at = each level of the tree there are n/2 unmerged leaves stored, so the = whole tree will store 4*(n/2)*log(n) =3D 2*n*log(n) bytes of = information.

We = can=E2=80=99t have a tree with more unmerged leaves, because a node at = level 1 can't have both its children is its `unmerged_leaves` array, = otherwise this node would be blank.


On 21 = May 2021, at 16:05, Sean Turner <sean@sn3rd.com> wrote:

Just = another FYI!

On May 12, 2021, at 08:26, Sean Turner <sean@sn3rd.com> = wrote:

Just an FYI that we have a meeting = scheduled for next week.

spt

On May 7, = 2021, at 13:33, Sean Turner <sean@sn3rd.com> wrote:

Meeting Scheduled!

More = information can also be found here:
https://datatracker.ietf.org/meeting/interim-2021-mls-01/sessio= n/mls

spt

On May 7, 2021, at = 12:39, IESG Secretary <iesg-secretary@ietf.org> wrote:

The Messaging Layer Security (mls) WG will = hold
a virtual interim meeting on 2021-05-26 from 10:00 to = 12:00 America/New_York (14:00 to 16:00 UTC).

Agenda:
GitHub issues and pull requests related = to -protocol and -architecture.

Information = about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b1= 1d4d7dfa487

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce



_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_015259A4-CBA8-4492-B018-6766EDC48C32-- From nobody Fri May 21 14:04:06 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 815763A207E for ; Fri, 21 May 2021 14:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 REEMuLV9FKQV for ; Fri, 21 May 2021 14:03:59 -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 DD50D3A2084 for ; Fri, 21 May 2021 14:03:58 -0700 (PDT) IronPort-Data: =?us-ascii?q?A9a23=3ApmrETqJeVSCdRLeQFE+RzpclxSXFcZb7ZxGrkP8?= =?us-ascii?q?bfHC81D1w0zNVmGNLW22DPvjYMWD3Kd9wbYi18xxU7J7Vm4NqS1BcGVNFHysb8?= =?us-ascii?q?5KdbTi6Bh6tZH3KdpWroHqKXqzyU/GYRCwPZiKa9k3F3oTJ9yEmjPnVHOOkUYY?= =?us-ascii?q?oBwgqLeNaYHZ44f5cs75h6mJYqYDR7zKl4bsekeWHULOW82Ic3lYv1k62gEgHU?= =?us-ascii?q?MIeF98vlgdWifhj5DcynpSOZX4VDfnZw3DQGuG4EgMmLtsvwo1V/kuBl/ssIuD?= =?us-ascii?q?8yvCiLR1MG+KCe1LV1E8+t6qK2UcE/3NolPxhb7xGMhk/ZzahxridzP1RtZG3U?= =?us-ascii?q?QcoOqCKh+0ZVxRKOyB4J6xPvrHdSZS6mZfDlRSbKiW0mp2CC2lzZ+X04N1fBGV?= =?us-ascii?q?V3f0VND5LaQqM799aaprTpvJE3ZtldZaxetlF4Tc6lm+xMBrveribK42i2DOS9?= =?us-ascii?q?G5YahhyIMvj?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ATQtjR6tQ/8jxt9FZw3U13EQN7skDb9V00zEX?= =?us-ascii?q?/kB9WHVpm6uj+PxG/c526faasl0ssR0b+exoW5PsfZq/z+8X3WB5B97LYOCMgg?= =?us-ascii?q?WVxe9ZjLcKjweLJxHD?= X-IronPort-AV: E=Sophos;i="5.82,319,1613430000"; d="scan'208";a="382151601" Received: from unknown (HELO [10.178.148.236]) ([37.172.223.236]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 21 May 2021 23:03:55 +0200 Date: Fri, 21 May 2021 23:03:56 +0200 User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TRMF0O7SG1WVDRR2M0HO1OKXXP0DWJ" Content-Transfer-Encoding: 7bit To: mls@ietf.org From: =?ISO-8859-1?Q?Th=E9ophile_Wallez?= Message-ID: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> Archived-At: Subject: [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, 21 May 2021 21:04:05 -0000 ------TRMF0O7SG1WVDRR2M0HO1OKXXP0DWJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello All, The MLS spec includes some extensions that are mandatory=2E Considering that this is v1 of the spec, why not just make these into fiel= ds 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=2E 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=2E Also, it is a bit weird that parent_hash is a field in ParentNode, and it = is an extension in KeyPackage=2E We propose the following changes: > New structure: > struct { > opaque parent_hash_value<0=2E=2E255>; > } ParentHash; > > New field in KeyPackage: > optional parent_hash; > > This optional field must be present in the `leaf_key_package` of an Upda= tePath (same constraints as the current extension)=2E Or: > New field in KeyPackage: > opaque parent_hash<0=2E=2E255>; > > `parent_hash` must be non-empty in the `leaf_key_package` of an UpdatePa= th (same constraints as the current extension)=2E Best regards, Th=C3=A9ophile, Benjamin, and Karthik ------TRMF0O7SG1WVDRR2M0HO1OKXXP0DWJ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello All,

The MLS spec includes some extensions that are mandatory= =2E
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 curr= ent draft, the parent hash is only an extension, but it is mandatory when t= he leaf is generating an UpdatePath=2E
Let us make it a field in KeyPack= age?
Having it as an extension hides its importance for security, and ma= kes the draft confusing to read=2E
Also, it is a bit weird that parent_h= ash is a field in ParentNode, and it is an extension in KeyPackage=2E
We propose the following changes:

> New structure:
> stru= ct {
> opaque parent_hash_value<0=2E=2E255>;
> } Pare= ntHash;
>
> New field in KeyPackage:
> optional<Parent= Hash> parent_hash;
>
> This optional field must be present i= n the `leaf_key_package` of an UpdatePath (same constraints as the current = extension)=2E

Or:

> New field in KeyPackage:
> opaqu= e parent_hash<0=2E=2E255>;
>
> `parent_hash` must be non-= empty in the `leaf_key_package` of an UpdatePath (same constraints as the c= urrent extension)=2E

Best regards,
Th=C3=A9ophile, Benjamin, and = Karthik ------TRMF0O7SG1WVDRR2M0HO1OKXXP0DWJ-- From nobody Sat May 22 03:14:21 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 891C03A1F01 for ; Sat, 22 May 2021 03:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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=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 EklKKE9POVsP for ; Sat, 22 May 2021 03:14:14 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 E8AEF3A1F00 for ; Sat, 22 May 2021 03:14:13 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id j10so8576760edw.8 for ; Sat, 22 May 2021 03:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sRRozJW+uQcyZPse8rlxxhqiSzzEoPmkTVsSHp354MM=; b=lI9zmt7fzoPSYBQJb+H4pI1A6kPcUgiQGevDME+C3WLDOD1B74ZvM5FDZEfRSYLTIK /cY4TcoIP4RfJrCrg3lkj0rSAce8NjbYU08OJUDoLyjnwIHOj6+EGC9RMyuXhYWZCELl RXsUyYuvmo2BwKiiNvfF45F/C9QhGEeAuJjIk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sRRozJW+uQcyZPse8rlxxhqiSzzEoPmkTVsSHp354MM=; b=Vn66xanMxzm9gNtvxvFn7o7sf9VQ9gCdMGtHZJ19B476bBEf9Fw/939jCZjNQfcryC eTPJhV5Vh/nC19LAp7lsi/+toYclDVKYotoWAOxMVxkzy3oq4cE0zQOH2kEAFxCfz62V 4b6SLVHgBI+X0nZgOUa9xuNLgYzOUqou8rhXNUBiWCGQhk2zMdWyer5VkYVCJyk2fqF3 dtjnnXIRznpE+Umne9w7Yic6pQrGu+h9+GIdns3Wwjs88pBa+EKK2r3c6wlVQD770OAK cco1xfYMWMeQ93ak3Qssa6LearXD7BU8HuF5csPf3xLCT/w2hr7Ja/5upoAj+AfcHjFl Pmkw== X-Gm-Message-State: AOAM532SuGHNnSO0apoyXRrxk38baYExmUxn9gQ7yajgZnJ7fFTDVerM 6sh5eA9as1du8NqKgAI1mexM9VFeW2um2ZngcRI= X-Google-Smtp-Source: ABdhPJydtvS2sZugXULEWA0NX3CEZ705pY9M4RnM0hQWtRrZbkVi+tArr2B3J61krIuesbav5JKPOQ== X-Received: by 2002:a05:6402:190e:: with SMTP id e14mr15755596edz.146.1621678451910; Sat, 22 May 2021 03:14:11 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id e22sm6434265edu.35.2021.05.22.03.14.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 May 2021 03:14:11 -0700 (PDT) From: Raphael Robert Message-Id: <8E5EC435-7B97-4852-AB90-F4E501ACDEDA@raphaelrobert.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FFA2C19F-4129-4B33-ABDD-345BF4ABFC04" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Sat, 22 May 2021 12:14:10 +0200 In-Reply-To: <6B8101F5-A54A-429A-82B0-5386E321F525@inria.fr> Cc: MLS List To: Karthik Bhargavan 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> X-Mailer: Apple Mail (2.3654.80.0.2.43) 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: Sat, 22 May 2021 10:14:20 -0000 --Apple-Mail=_FFA2C19F-4129-4B33-ABDD-345BF4ABFC04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Karthik, Thanks for sharing your findings! Just for context (for those who were not at the Paris interim meeting in = 2018), the fact that =E2=80=9Cunmerged leaves=E2=80=9D exist is because = it gives us a mechanism to do Adds in O(1) instead of O(log n). This = benefit does however come at the cost having to do this =E2=80=9Cbook = keeping=E2=80=9D (storage cost) and more KEM operations during = subsequent updates (computation cost). It also delays PCS for the adder. I think the question is worth investigating and I am commenting inline: > On 21. May 2021, at 16:59, Karthik Bhargavan = > = wrote: >=20 >=20 > Hello All, >=20 > Th=C3=A9ophile, Benjamin, and I have been writing a formal = specification of MLS in F* and we=E2=80=99re happy to report a compleger = interoperable spec that (with Franziskus=E2=80=99 help) shares test = vectors with OpenMLS. > In the course of writing this specification, we observed several = potential improvements in the way MLS does things, and this email is = about the first of these. Subsequent emails will have other = questions/comments. >=20 > The way we store unmerged leaves in the ratchet tree is sub-optimal = since it stores a lot of redundant information. > In the worst case, a tree can have n/2 unmerged leaves (read the end = of this email to see how we obtained this number). I agree with the extreme case, but I think it is very unlikely to happen = frequently =E2=80=9Cin the wild=E2=80=9D. Trees that are quite sparse = are problematic in general, doing frequent updates is still the = recommended way to go both for PCS and efficiency. > Consequently, the total size of the ratchet tree can be as big as = 2*n*log(n) + 4*n bytes (for n participants), and is never lower than 4*n = bytes. > This is unfortunate, since the unmerged nodes optimization has now = bloated our tree to O(n logn) from O(n). > Consequently, the welcome message/initial tree and local storage is = now O(n log n). I=E2=80=99d like to add the these considerations in big O notation that = an index is 4 bytes long, while the public keys in the nodes are at = least 32 bytes long. So there is an order of magnitude of difference at = least in lower intermediary nodes of the tree. > For more precision, in the rest of this email, we won't say that "a = leaf l is unmerged", but "a leaf l is unmerged at a node n", meaning = that `n` is an ancestor of the leaf `l` and the member at the leaf `l` = doesn't know the node secret at `n`. > Then, a leaf `l` is "unmerged=E2=80=9D (in the sense of the MLS spec) = iff. there exists a node `n` such that this leaf `l` is unmerged for = `n`. >=20 > In the current MLS spec, we store the index of a leaf `l` at each = ancestor node `n` such that `l` is unmerged for `n`. > To see why this results in quite a bit of storage redundancy, observe = the following property: If a leaf `l` is unmerged for the parent of a = node `n`, then `l` is also unmerged for `n`. > Given this observation, we can optimize the unmerged leaves design to = bring the tree size back to O(n). >=20 > Solution 1 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > 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) =3D 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 =E2=80=9Cpush down=E2=80=9D 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. > Solution 2 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > An alternative, which we prefer, is to get rid of the unmerged leaves = array entirely and replace them by epoch numbers: > - for each leaf, store the epoch of its creation in the tree (when = the leaf was added), > - for each parent node, store the epoch at which it was last updated. > Then, a leaf `l` is unmerged for node `n` iff. n.last_update_epoch < = l.creation_epoch. > Finding the list of unmerged leaves at a node then becomes part of = tree resolution, and a member can pre-compute and store this array if it = likes. >=20 > In this design, we will store a 64-bit epoch number at each leaf and = each parent node, thus it uses 8*2*n =3D 16*n bytes. > We believe that having an epoch number documenting the last update = time of each node is in itself a useful feature for debugging and for = security analysis. > In our model, it makes stating secrecy and authentication invariants = easier. I like this approach for being more explicit and thus maybe increasing = the security/level of agreement. It also helps members determining when = they should evict a stale member for being inactive for too long without = any extra book keeping. Some counter arguments: - Since public trees might actually be really public in some scenarios, = this might give attackers better indications about which client is most = interesting to compromise. - I think the payload is only smaller for groups with more than 2 ^ 5 =3D= 32 members. For smaller groups it actually makes the stored payload = bigger (when we consider exactly one unmerged leaf, more unmerged leaves = shift the break even point down). > Solution 2+ > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > 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 =3D = 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). >=20 > 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 =3D 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 =3D l.last_update_epoch, > - if `l` is not unmerged for `n`, then n.last_update_epoch >=3D = l.last_update_epoch (because when `l` is updated, it updates all the = nodes above it). > This uses 8*n + 1*n =3D 9*n bytes for the whole tree. I didn=E2=80=99t check all the ramifications here tbh. I think it is = similar to solution 1 in terms of increased I/O cost. > Comments are welcome, and do please correct us if we misunderstood = something. > In our opinion, it would be great to simplify the tree data structure = and compress its size back to O(n) at the same time. I think all 3 solutions are generally valid. But it also becomes clear = that saving in one place introduces cost (or security/privacy = degradation) at another. That=E2=80=99s always been the case with all = changes we made in MLS though :) =46rom an implementor=E2=80=99s perspective I wouldn=E2=80=99t say that = the current suboptimal payload poses a big problem. But I=E2=80=99d like = to hear from other on that as well. Thanks Raphael > Best regards, > Th=C3=A9ophile, Benjamin, and Karthik >=20 > Appendix : How to create a tree with n/2 unmerged leaves? >=20 > First, add n participants to the tree. > Then, remove the participants with odd leaf index. > Then, generate an update path from every participant with even leaf = index (this ensures that there are no blank nodes) > Then, add new participants in leaves with odd leaf index, without = regenerating the group secret. > Every leaf with odd leaf index will be present in the = `unmerged_leaves` array on all the nodes above it, so at each level of = the tree there are n/2 unmerged leaves stored, so the whole tree will = store 4*(n/2)*log(n) =3D 2*n*log(n) bytes of information. >=20 > We can=E2=80=99t have a tree with more unmerged leaves, because a node = at level 1 can't have both its children is its `unmerged_leaves` array, = otherwise this node would be blank. >=20 >=20 >> On 21 May 2021, at 16:05, Sean Turner > wrote: >>=20 >> Just another FYI! >>=20 >>> On May 12, 2021, at 08:26, Sean Turner > wrote: >>>=20 >>> Just an FYI that we have a meeting scheduled for next week. >>>=20 >>> spt >>>=20 >>>> On May 7, 2021, at 13:33, Sean Turner > wrote: >>>>=20 >>>> Meeting Scheduled! >>>>=20 >>>> More information can also be found here: >>>> = https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls = >>>>=20 >>>> spt >>>>=20 >>>>> On May 7, 2021, at 12:39, IESG Secretary > wrote: >>>>>=20 >>>>> The Messaging Layer Security (mls) WG will hold >>>>> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>>>>=20 >>>>> Agenda: >>>>> GitHub issues and pull requests related to -protocol and = -architecture. >>>>>=20 >>>>> Information about remote participation: >>>>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= = >>>>>=20 >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_FFA2C19F-4129-4B33-ABDD-345BF4ABFC04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Karthik,

Thanks for sharing your = findings!

Just = for context (for those who were not at the Paris interim meeting in = 2018), the fact that =E2=80=9Cunmerged leaves=E2=80=9D exist is because = it gives us a mechanism to do Adds in O(1) instead of O(log n). This = benefit does however come at the cost having to do this =E2=80=9Cbook = keeping=E2=80=9D (storage cost) and more KEM operations during = subsequent updates (computation cost). It also delays PCS for the = adder.

I think = the question is worth investigating and I am commenting inline:

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


Hello All,

Th=C3=A9ophile, Benjamin, and I = have been writing a formal specification of MLS in F* and we=E2=80=99re = happy to report a compleger interoperable spec that (with Franziskus=E2=80= =99 help) shares test vectors with OpenMLS.
In the course of writing this = specification, we observed several potential improvements in the way MLS = does things, and this email is about the first of these. Subsequent = emails will have other questions/comments.

The way we store unmerged leaves in = the ratchet tree is sub-optimal since it stores a lot of redundant = information.
In the worst case, a tree can have n/2 unmerged = leaves  (read the end of this email to see how we obtained this = number).

I agree with the extreme case, but I think it is very = unlikely to happen frequently =E2=80=9Cin the wild=E2=80=9D. Trees that = are quite sparse are problematic in general, doing frequent updates is = still the recommended way to go both for PCS and efficiency.

Consequently, the = total size of the ratchet tree can be as big as 2*n*log(n) + 4*n bytes = (for n participants), and is never lower than 4*n = bytes.
This is unfortunate, since the unmerged nodes = optimization has now bloated our tree to O(n logn) from = O(n).
Consequently, the welcome message/initial tree and = local storage is now O(n log = n).

I=E2=80=99d like to add the these considerations in big = O notation that an index is 4 bytes long, while the public keys in the = nodes are at least 32 bytes long. So there is an order of magnitude of = difference at least in lower intermediary nodes of the tree.

For more = precision, in the rest of this email, we won't say that "a leaf  l = is unmerged", but "a leaf l is unmerged at a node n", meaning that `n` = is an ancestor of the leaf `l` and the member at the leaf `l` doesn't = know the node secret at `n`.
Then, a leaf `l` = is "unmerged=E2=80=9D (in the sense of the MLS spec) iff. there = exists a node `n` such that this leaf `l` is unmerged for = `n`.

In the current MLS spec, we store the index of a leaf `l` at = each ancestor node `n` such that `l` is unmerged for `n`.
To see = why this results in quite a bit of storage redundancy, observe the = following property:  If a leaf `l` is = unmerged for the parent of a node `n`, then `l` is also unmerged for = `n`.
Given this observation, we can optimize the unmerged leaves design = to bring the tree size back to O(n).

Solution 1
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

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) =3D 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 =E2=80=9Cpush = down=E2=80=9D 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.

Solution 2
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94

An = alternative, which we prefer, is to get rid of the unmerged leaves array = entirely and replace them by epoch numbers:
 - for each leaf, store the epoch of = its creation in the tree (when the leaf was added),
 - for each parent node, store the = epoch at which it was last updated.
Then, a leaf `l` is unmerged for node `n` iff. = n.last_update_epoch < l.creation_epoch.
Finding the list of unmerged leaves at a = node then becomes part of tree resolution, and a member can pre-compute = and store this array if it likes.

In this design, we will store = a 64-bit epoch number at each leaf and each parent node, thus it uses = 8*2*n =3D 16*n bytes.
We believe that having = an epoch number documenting the last update time of each node is in = itself a useful feature for debugging and for security = analysis.
In our model, it makes stating secrecy = and authentication invariants = easier.

I like this approach for being more explicit and thus = maybe increasing the security/level of agreement. It also helps members = determining when they should evict a stale member for being inactive for = too long without any extra book keeping.

Some counter arguments:
 - Since public trees might actually be really public in = some scenarios, this might give attackers better indications about which = client is most interesting to compromise.
 - I = think the payload is only smaller for groups with more than 2 ^ 5 =3D 32 = members. For smaller groups it actually makes the stored payload bigger = (when we consider exactly one unmerged leaf, more unmerged leaves shift = the break even point down).

Solution = 2+
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

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 =3D 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 =3D 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 = =3D l.last_update_epoch,
- if `l` = is not unmerged for `n`, then n.last_update_epoch >=3D = l.last_update_epoch (because when `l` is updated, it updates all the = nodes above it).
This uses 8*n + = 1*n =3D 9*n bytes for the whole = tree.

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

Comments = are welcome, and do please correct us if we misunderstood = something.
In our opinion, it would be great to = simplify the tree data structure and compress its size back to O(n) at = the same time.

I think all 3 solutions are generally valid. But it = also becomes clear that saving in one place introduces cost (or = security/privacy degradation) at another. That=E2=80=99s always been the = case with all changes we made in MLS though :)

=46rom an implementor=E2=80=99s = perspective I wouldn=E2=80=99t say that the current suboptimal payload = poses a big problem. But I=E2=80=99d like to hear from other on that as = well.

Thanks

Raphael

Best regards,
Th=C3=A9ophile, Benjamin, = and Karthik

Appendix : How to create a tree with n/2 = unmerged leaves?

First, add n participants to the tree.
Then, remove the participants with odd leaf = index.
Then, generate an update = path from every participant with even leaf index (this ensures that = there are no blank nodes)
Then, = add new participants in leaves with odd leaf index, without regenerating = the group secret.
Every leaf with = odd leaf index will be present in the `unmerged_leaves` array on all the = nodes above it, so at each level of the tree there are n/2 unmerged = leaves stored, so the whole tree will store 4*(n/2)*log(n) =3D = 2*n*log(n) bytes of information.

We can=E2=80=99t have a tree with more unmerged leaves, = because a node at level 1 can't have both its children is its = `unmerged_leaves` array, otherwise this node would be = blank.


On 21 May 2021, at 16:05, Sean = Turner <sean@sn3rd.com> wrote:

Just = another FYI!

On May 12, 2021, at 08:26, Sean Turner <sean@sn3rd.com> = wrote:

Just an FYI that we have a meeting = scheduled for next week.

spt

On May 7, = 2021, at 13:33, Sean Turner <sean@sn3rd.com> wrote:

Meeting Scheduled!

More = information can also be found here:
https://datatracker.ietf.org/meeting/interim-2021-mls-01/sessio= n/mls

spt

On May 7, 2021, at = 12:39, IESG Secretary <iesg-secretary@ietf.org> wrote:

The Messaging Layer Security (mls) WG will hold
a= virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC).

Agenda:
GitHub issues and pull requests related = to -protocol and -architecture.

Information = about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b1= 1d4d7dfa487

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce



_______________________________________________
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

= --Apple-Mail=_FFA2C19F-4129-4B33-ABDD-345BF4ABFC04-- From nobody Sat May 22 03:20:20 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 06F5A3A1F32 for ; Sat, 22 May 2021 03:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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=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 6HlF2XdCd89z for ; Sat, 22 May 2021 03:20:14 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 3836B3A1F2E for ; Sat, 22 May 2021 03:20:14 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id f18so3935661ejq.10 for ; Sat, 22 May 2021 03:20:14 -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=xLhjcoAw1sEJK0xTvgJvuHYsv7q6IgqdCWN1XzS9AJo=; b=t0ZL9I/c1RwWPTEhULtp/AkCn3egYnCk+vNzRWOa/jGHcz8DPjl37LGQNTBFk7ryoz 4xqZJU7OKMseuB3+qE+xGN5oBSCi8dE5i9Qs+9hTVm801c6jBuvGyGSj1KzWXTeLlajZ wo1qZ3krAsHgtIAkzqvYORH/vWXUjFbtoITKE= 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=xLhjcoAw1sEJK0xTvgJvuHYsv7q6IgqdCWN1XzS9AJo=; b=WMFNjsNVEjJmrgrO79KTrA5DisCSyi83HWtcJzeuFeWFf0mGVwTIOrARn9VjjS64ii 2FTRLnfnraWZoEAb+gsqzn4GRMxKK34QMLTmgSF3PxJ0JFnZPzT7VBfEer9o7cSv5Ilk igSgCqvxHoMRneOnZMBL6Q0tmchCXe5AfmytHG7petZ8SGo23Ez1kjBIT++f6/PoG18X 3bBglYj6taGtUhgwa/OAhZ78onj6fWO21lO7XwxCr03sZ2fLPQE6B9MAFFkQSUkDl23l EZ0pgUMmmbjeJfQq1l/tIJIp5nbybKC3yCLsus9fiLsIIP0edde9s+yzWYOvDlLBsJ6A 1MzQ== X-Gm-Message-State: AOAM531LiMDjmQHLDDCkyrDSaQfh/VJGUh+NszKW0sS4MVGow58mSsgt ZJElgN1++pCIvEh/31ZCKysaCQ== X-Google-Smtp-Source: ABdhPJyOA1mi2vePKLtmQUNybYaqkM2BxXY6Mgw7VxRZ9t/+GDK1t/gTfjZq2KO+LJYvzUh9c48brA== X-Received: by 2002:a17:906:a294:: with SMTP id i20mr14617902ejz.86.1621678812055; Sat, 22 May 2021 03:20:12 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id z7sm1059944ejm.122.2021.05.22.03.20.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 May 2021 03:20:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Raphael Robert In-Reply-To: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> Date: Sat, 22 May 2021 12:20:10 +0200 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C0AD1D0-B644-43C9-A4DD-3635DD1F4DF5@inria.fr> To: =?utf-8?Q?Th=C3=A9ophile_Wallez?= X-Mailer: Apple Mail (2.3654.80.0.2.43) 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: Sat, 22 May 2021 10:20:19 -0000 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 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 = wrote: >=20 > Hello All, >=20 > 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? >=20 > 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. >=20 > We propose the following changes: >=20 > > 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). >=20 > Or: >=20 > > 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). >=20 > Best regards, > Th=C3=A9ophile, Benjamin, and = Karthik_______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Sat May 22 03:24:00 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 A00663A1F53 for ; Sat, 22 May 2021 03:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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=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 GiZ-JshE902S for ; Sat, 22 May 2021 03:23:53 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 88C2D3A1F52 for ; Sat, 22 May 2021 03:23:52 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id j10so8598632edw.8 for ; Sat, 22 May 2021 03:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raphaelrobert.com; s=rr; h=from:mime-version:subject:message-id:date:to; bh=qcfPgH49qOKHfXC3SVQvgCtCacPTWiThAUAMTnDQOt4=; b=l7t52j1M7f5QL67KkK3+1LlkHMog+RRNCOj9IE5ewNd5Q7OtccKJLPmTfkwiNbUxtJ s62WKnY7mEbbgV//YKSDvqneBJACiBR+ddkPgjuA7zPse/yj0Q/cuZ1xG0J5w2sRINiN ChpLuUqY05DTLkmkbeAhhksF/IkwmH5bcs504= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=qcfPgH49qOKHfXC3SVQvgCtCacPTWiThAUAMTnDQOt4=; b=S9Gvk4p8RQ5yhSDf/yBE159IKWqUw5oXw0iiP3ym9YXDu6QY/vsVPjM4+H8+TT8CWv Gl2wUQ3GJOF3qqnVn3UwomXAtqwyEQg2jH2l06XTfgo6EEgyw0rLzrYzhIhsXXe4IsLd BMA+atzNPnt6dCBLtLbSM9RZ5t6vFkU1ruiZptBI8JVl7Q8KNUlhkFKJBvwFGJ8dbcO1 qhLO/VFa7nQZ5j20N/kc67siM1ZZaMd6nV7/nDcB/6qXG51VdfDIGCrvLI0n1qL77DR/ vqxwSj4ovgMCf+JcaKF1DzdWnDeCGBNyt5OKKDyzEth6DIJ+E2iF/69CMvVbLtcD3Ilc Ma/g== X-Gm-Message-State: AOAM531UgkX+gMstCKpw6rrcU2K6vU06Tb7qpWdwZpBD6icj8Ay/YdLr b3PZzW6trJd5vhZYe7733Tp11nNnqrJ/bGIvGuc= X-Google-Smtp-Source: ABdhPJyMt1iFyaTStlCqIUWL/c0TDFvSXNTHc7peypyOlWK82FPpLdPTGVWpMJuVt/gsZm/3uxVsBg== X-Received: by 2002:aa7:c1c9:: with SMTP id d9mr16242435edp.308.1621679025628; Sat, 22 May 2021 03:23:45 -0700 (PDT) Received: from smtpclient.apple ([37.49.18.137]) by smtp.gmail.com with ESMTPSA id w14sm6252971edj.6.2021.05.22.03.23.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 May 2021 03:23:45 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_8348B84C-6967-42D5-AE22-6EE5BC4307DE" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: Date: Sat, 22 May 2021 12:23:44 +0200 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [MLS] Extensions 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: Sat, 22 May 2021 10:23:59 -0000 --Apple-Mail=_8348B84C-6967-42D5-AE22-6EE5BC4307DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I would like to draw your attention at an issue Konrad and I posted as a = GitHub issue: https://github.com/mlswg/mls-protocol/issues/473 = In essence, we think we the way extensions are currently described in = the spec raise some questions and we propose some improvements. Thanks Raphael= --Apple-Mail=_8348B84C-6967-42D5-AE22-6EE5BC4307DE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,

I would like to draw your attention at an issue Konrad and I posted as a GitHub issue: https://github.com/mlswg/mls-protocol/issues/473

In essence, we think we the way extensions are currently described in the spec raise some questions and we propose some improvements.

Thanks

Raphael
--Apple-Mail=_8348B84C-6967-42D5-AE22-6EE5BC4307DE-- From nobody Sun May 23 01:46:25 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 4D8843A0A87 for ; Sun, 23 May 2021 01:46:11 -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=BL84uW9Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KId7yiRm 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 SBXxl33vY8Xi for ; Sun, 23 May 2021 01:46:06 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79DFC3A0A6F for ; Sun, 23 May 2021 01:46:06 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 502A31135 for ; Sun, 23 May 2021 03:46:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 23 May 2021 03:46:21 -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=5ykwIEf/AAC J4KMFaPiSfr+7trjigzhaHn5kGJxVNjU=; b=BL84uW9QmzFlE8EK0/S1Urppk+T Ll61owUtmkMblqxo5L1OXvwQi2fWax7NMFI4u/emx4gm/6rWJBDpbLqsCZ6XUnVN +gSco/7jh6ayP38hGSwoUq5vTrwZi0bXLnFClJvYVeXgQqK05FtX/ESOMp+dkW18 yRIPamvcZ5wcAdSpqpKyBpN0FY8rvQNLU6UHr8T1PmYsCqEXg8vNfCD+h53wWb8M AOpHkQOZI9jxrYDQk+FAotOJWR91Y8X6JV9QYokKJ3TrwmFLCM0oWBbIXUSBSHk0 LnK6sA+2EXgCUIlI92tt82SXeQ2loAb3WKN1+KQXd0SKRtMG+kqknsgx6TA== 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= fm2; bh=5ykwIEf/AACJ4KMFaPiSfr+7trjigzhaHn5kGJxVNjU=; b=KId7yiRm K3xdZfOE2DEA93TYpiYdS1rQyCBQRaKPyWNG4eIYZacidn1FmSfRRYQDFaQTQBD9 /9Bjnln9rv45l9WimrJRJwOnnEzCU3rG3LKREcQdQDK/lWwwdDjRsXbGYsLfAN7T rOgODY5j89jz5v8ivPq9g+X6j3JCc8T9PQ8QUN6y60lAUEoo0AB55b57IL44S8qq zdj3NLj1MI2ihkta2cT9/VrZQxahzxy0LbSdcgoaeZegczmzONLwRQMpYH3DEMq1 6MZYXicuFl6zWMInXagDD4DKh+rVaII7MQyvm7eQOsY2h82JimJzg/jkGAI24Wr2 stRictHyFptLSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejiedguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecukfhppedvfedruddtvddrudekiedrudehheenucevlhhushhtvghrufhiiigv pedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnoh htrdhnvght X-ME-Proxy: Received: from fv-az290-665.z45yk40qnouupoc55gb0v1wkoc.jx.internal.cloudapp.net (unknown [23.102.186.155]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 23 May 2021 03:46:20 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7872808960395510116==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210523084606.79DFC3A0A6F@ietfa.amsl.com> Date: Sun, 23 May 2021 01:46:06 -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, 23 May 2021 08:46:20 -0000 --===============7872808960395510116== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+2/-1/=F0=9F=92=AC1) 2 issues created: - Extensions (by raphaelrobert) https://github.com/mlswg/mls-protocol/issues/473=20 - Make extensions more powerful (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/472=20 1 issues received 1 new comments: - #472 Make extensions more powerful (1 by kkohbrok) https://github.com/mlswg/mls-protocol/issues/472=20 1 issues closed: - Make extensions more powerful https://github.com/mlswg/mls-protocol/iss= ues/472=20 Pull requests ------------- * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Rewrite AS definition to reflect its role in the Spec (by kkohbrok) https://github.com/mlswg/mls-architecture/pull/80=20 1 pull requests received 1 new comments: - #78 Reorganize section 3 (1 by beurdouche) https://github.com/mlswg/mls-architecture/pull/78=20 1 pull requests merged: - Reorganize section 3 https://github.com/mlswg/mls-architecture/pull/78=20 * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Use HPKE draft-08 (by franziskuskiefer) https://github.com/mlswg/mls-protocol/pull/471=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============7872808960395510116== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday May 23, 2021

Issues

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

2 issues created:

1 issues received 1 new comments:

1 issues closed:

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

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

1 pull requests submitted:

Repositories tracked by this digest:

--===============7872808960395510116==-- From nobody Tue May 25 07:27:58 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 059EA3A0CC1 for ; Tue, 25 May 2021 07:27:56 -0700 (PDT) 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, 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 xKX6Rys62gqA for ; Tue, 25 May 2021 07:27:51 -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 43C1B3A0CC8 for ; Tue, 25 May 2021 07:27:50 -0700 (PDT) IronPort-Data: =?us-ascii?q?A9a23=3A249wzauUSu9yqAanxro6sdJnwOfnVJFcMUV32f8?= =?us-ascii?q?akzHdYEJGY0x3m2AbC23TOfrZM2r1e9Ekbo+//U4AucPSzd5jHFQ++H1gHilAw?= =?us-ascii?q?SbnLYTAfx2oZ0t+DeWaERk5t51GAjX4wXFdokb0/n9BCZC86ykmvU20buCkUre?= =?us-ascii?q?cZ3osHVUMpBoJ0nqPpcZo2+aEvvDpW2thifuqyyHuEAfNNwxcagr42IrfwP9bh?= =?us-ascii?q?8kejRtD1rAIiV+ni3eF/5UdJMp3yahctBIUSKEMdgKxb76rIL1UYgrkExkR5tO?= =?us-ascii?q?Nyt4Xc2URR6LKNgyPh3xKHaG6mhxPzsAw+vZqcqNBNwEO02zPxo4poDlOncXYp?= =?us-ascii?q?QMBPaTWhOQcUBRJGic4N61P4rDOP3G5mc2V1UzPNXX2qxlrJBpmZ9FBpLkoWgm?= =?us-ascii?q?i8tRdcljhdCurnO+/xpqgTLJ2ioIoK8yDFIYboVlhwC3XS/E8Tvj+rw/ijTND9?= =?us-ascii?q?Gdhw5kTQ7OHP5NcMGQ3Kg7NfVtJJ1IaEpM1le2siz/xaVVlRJuujfJfywDuIMZ?= =?us-ascii?q?ZitAB6OboR+E=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A9UlCo67Fov6A0sVVIAPXwMPXdLJyesId70hD?= =?us-ascii?q?6qm+c31om6uj9/xG/c5x6faaslgssR0b9exofZPufZqjz+8X3WBhB92ftWDd0Q?= =?us-ascii?q?OVxcNZnOnfKlbbdhEWmNQtsJuIC5IObOHNMQ=3D=3D?= X-IronPort-AV: E=Sophos;i="5.82,328,1613430000"; d="scan'208";a="382416773" Received: from 89-156-101-160.rev.numericable.fr (HELO smtpclient.apple) ([89.156.101.160]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2021 16:27:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Karthik Bhargavan In-Reply-To: <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> Date: Tue, 25 May 2021 16:27:47 +0200 Cc: MLS List Content-Transfer-Encoding: quoted-printable Message-Id: References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Reminder: Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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, 25 May 2021 14:27:56 -0000 If possible, we=E2=80=99d like a slot to discuss some new suggestions = and comments that came up during the F* formalization. -Karthik > On 12 May 2021, at 14:26, Sean Turner wrote: >=20 > Just an FYI that we have a meeting scheduled for next week. >=20 > spt >=20 >> On May 7, 2021, at 13:33, Sean Turner wrote: >>=20 >> Meeting Scheduled! >>=20 >> More information can also be found here: >> https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls >>=20 >> spt >>=20 >>> On May 7, 2021, at 12:39, IESG Secretary = wrote: >>>=20 >>> The Messaging Layer Security (mls) WG will hold >>> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>>=20 >>> Agenda: >>> GitHub issues and pull requests related to -protocol and = -architecture. >>>=20 >>> Information about remote participation: >>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >>>=20 >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue May 25 19:42: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 A0A983A19EB for ; Tue, 25 May 2021 19:42:27 -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 nA25W_WT9iK7 for ; Tue, 25 May 2021 19:42:22 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 96BF63A19EA for ; Tue, 25 May 2021 19:42:22 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id 1so24708758qtb.0 for ; Tue, 25 May 2021 19:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N3+RQZ5QJ7vKGew40UvM9U3AK+8na9ik8GSxpm8MwLQ=; b=MX+5bK3/PccHa5nbkdY9GE5syqXBFEAtEPGOZ/6PkXy+nroJCxgyr3hwej+o0zSdxj QZlaW3yKUugauwgH3/LhOcoR4rh5fGuHhgzDbZrBhZ5Q2FJovArUp+cQbd3aOL3zAUAE AXlRB/fqnRq99bFfkLeMkFf5TKS8BL4DWupAQ= 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=N3+RQZ5QJ7vKGew40UvM9U3AK+8na9ik8GSxpm8MwLQ=; b=ofYBzKNojeOuCXILOYpmFNS9pQPHAllx3eKRNZr0Cr41lONt72ejZNz+ryoUKX4hnZ KxtS5CsHhkK2YsN91MqLQcvtYpwg6L1bZN3/PNkHrNnyo2F72fuXj43k1XodU/q52KO+ 5W6oI8b0JBISL6CZ42ZWDCkcqi5CVdztLATsMtNXs4RWCnZHK430FXB1xRlIH/Pv1g4o Uye7XrXd+lTbxr3RgeE7xUW1gNW0jtQmdcny+3htOh6w5DXSj6pwOJo6c2P8G5raDKQJ gf4ZLm2a1BrMHNzrhlarXizTFo5h/ms+VGhbVGNPtiygmWDEQQMmP53IHNLd9hDEB03Q tnyQ== X-Gm-Message-State: AOAM5336sHggCeN0RAOvvxlKl394OLumqzoB2AwEAQ8S0hHbyBg7Z6eW QBX8xF8gPySVwTKTvyphdVsZ/w== X-Google-Smtp-Source: ABdhPJxLAWcs1WCKxY0FZym8njDQ18tA9iKCSuHYqSC/dde5cVW6bad7NZqP2o3JFM+rzKQhM1+6EQ== X-Received: by 2002:a05:622a:40f:: with SMTP id n15mr7061631qtx.27.1621996941106; Tue, 25 May 2021 19:42: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 w7sm638514qtn.91.2021.05.25.19.42.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 May 2021 19:42:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Sean Turner In-Reply-To: Date: Tue, 25 May 2021 22:42:20 -0400 Cc: MLS List Content-Transfer-Encoding: quoted-printable Message-Id: <422CB9FA-8AA8-4A50-8EE9-3E0A8B8C87DC@sn3rd.com> References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> To: Karthik Bhargavan X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Reminder: Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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: Wed, 26 May 2021 02:42:28 -0000 I was hoping you would ask for some time! spt > On May 25, 2021, at 10:27, Karthik Bhargavan = wrote: >=20 > If possible, we=E2=80=99d like a slot to discuss some new suggestions = and comments that came up during the F* formalization. >=20 > -Karthik >=20 >> On 12 May 2021, at 14:26, Sean Turner wrote: >>=20 >> Just an FYI that we have a meeting scheduled for next week. >>=20 >> spt >>=20 >>> On May 7, 2021, at 13:33, Sean Turner wrote: >>>=20 >>> Meeting Scheduled! >>>=20 >>> More information can also be found here: >>> https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls >>>=20 >>> spt >>>=20 >>>> On May 7, 2021, at 12:39, IESG Secretary = wrote: >>>>=20 >>>> The Messaging Layer Security (mls) WG will hold >>>> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>>>=20 >>>> Agenda: >>>> GitHub issues and pull requests related to -protocol and = -architecture. >>>>=20 >>>> Information about remote participation: >>>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >>>>=20 >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Tue May 25 19:58:04 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 9770E3A1A6A for ; Tue, 25 May 2021 19:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=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=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 o-shYXaJ3Cqr for ; Tue, 25 May 2021 19:57:57 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 3D9FA3A1A67 for ; Tue, 25 May 2021 19:57:57 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id j189so11825446qkf.2 for ; Tue, 25 May 2021 19:57:56 -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:date:references :to:in-reply-to:message-id; bh=NxpGHden0zEkuQiuKwBUd/TH0YgANZhyLCqhoPR9wfo=; b=IEgzA0s4UuNUD5RP9GR78aFhs1ua7K4Usmgzfn63T6EjgjAXyisZC999ErTMu4Wpew Msq/NJheKp9QkCBksBOLolvUV5xL1/oJb/xP6fbhKKvzaBUv48wMVY9vKqiBR2mOy7vb Wzg+S3+Ej4E5rekaAFMa1SQuHB5EK0CEhJjmQ= 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:date:references:to:in-reply-to:message-id; bh=NxpGHden0zEkuQiuKwBUd/TH0YgANZhyLCqhoPR9wfo=; b=RE4fKocDHkWKGhh5j3vTGUIyB9GH0J0Ea9T57J4LI7jrl/JG+2ObixV0enPSEBb+nH 5bCUFHVU6uyf94ma5IvWiBVgqywBVrQXvT3fvd/0TiuIXkd3X1kibMya/yxfm6V75obl kFCHzjrsw8GkFAvuzmsSxrAVcLRqElCkSuL97TaxKAR0FebcfLAk9+AFKdNGjqK24H9l 1FEl2ASpfVk4/LmHryRiTKxX8ZoNthXsbl1rKpXzE4FvtKEqg4bl6fXvcBVDi+oiB3En 5oH5QyE4BroHLB6DuvdPKImgzY87HU1nAO//IehgiRRO+HAuHe8bUfvbJYfGqnV4tATb 515w== X-Gm-Message-State: AOAM530SNdpR+R3ixlM2ILAU6X98oSP/Su5pWKSzMnZz73+je/KFmWdF G4cuNCcVtolpOzz03bB+8BiR6yo2p7i40A== X-Google-Smtp-Source: ABdhPJz68oxuCvX6kA1alDnjQ4LWogW3EEOooXOjN5QuCJvBS1I8MI7+4tGLht3Lf3RrgSN2NkgGGw== X-Received: by 2002:a37:c20b:: with SMTP id i11mr40254750qkm.222.1621997874796; Tue, 25 May 2021 19:57:54 -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 v18sm756523qkv.34.2021.05.25.19.57.54 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 May 2021 19:57:54 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 25 May 2021 22:57:53 -0400 References: <162040556024.10515.18434867074453969330@ietfa.amsl.com> <81ED88F6-16A8-45C4-A9B9-FD6659CB68FB@sn3rd.com> <4614A3C1-8461-48F8-AD53-C1399BC5F673@sn3rd.com> To: MLS List In-Reply-To: <4614A3C1-8461-48F8-AD53-C1399BC5F673@sn3rd.com> Message-Id: <7EA13E9C-C30C-42BC-8F68-37D8892FA02D@sn3rd.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [MLS] Reminder: Messaging Layer Security (mls) WG Virtual Meeting: 2021-05-26 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: Wed, 26 May 2021 02:58:03 -0000 Meeting is tomorrow (maybe today in your time zone). Info can be found = here: https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls The webex link is in the upper right quadrant. I uploaded some slides, but assumed that we would bash them at the = beginning of the call. I will note that I would like to keep Joel=E2=80=99= s topic near the beginning of the session to accommodate his schedule. spt > On May 21, 2021, at 10:05, Sean Turner wrote: >=20 > Just another FYI! >=20 >> On May 12, 2021, at 08:26, Sean Turner wrote: >>=20 >> Just an FYI that we have a meeting scheduled for next week. >>=20 >> spt >>=20 >>> On May 7, 2021, at 13:33, Sean Turner wrote: >>>=20 >>> Meeting Scheduled! >>>=20 >>> More information can also be found here: >>> https://datatracker.ietf.org/meeting/interim-2021-mls-01/session/mls >>>=20 >>> spt >>>=20 >>>> On May 7, 2021, at 12:39, IESG Secretary = wrote: >>>>=20 >>>> The Messaging Layer Security (mls) WG will hold >>>> a virtual interim meeting on 2021-05-26 from 10:00 to 12:00 = America/New_York (14:00 to 16:00 UTC). >>>>=20 >>>> Agenda: >>>> GitHub issues and pull requests related to -protocol and = -architecture. >>>>=20 >>>> Information about remote participation: >>>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm0e7f495c200143a9f02b11d4d7dfa487= >>>>=20 >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>=20 >>=20 >=20 From nobody Sun May 30 01:36:17 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 900173A3469 for ; Sun, 30 May 2021 01:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_BLOCKED=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=dEYb8ktF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hMIx6IJZ 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 lkTgAHNE9LZW for ; Sun, 30 May 2021 01:36:05 -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 CA7793A346C for ; Sun, 30 May 2021 01:36:05 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B0A98E14 for ; Sun, 30 May 2021 04:26:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 30 May 2021 04:26:45 -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=HJyrB3d3k5z AjMRXq5XvATrNV8XMQnBecR2x9RR/LJE=; b=dEYb8ktFT6y1G/YscpMrwahTXC0 dSSWnd5PUNMHF2PYlxqj6X3xVNG9U7MtVpGqwWQl9Ftn2+G6o1mq4HGkODCapjbo JSRzFFS3fp1Z2fHZeW9cW1IfoVYdBnpCBTYAQ1PlMRPsL3w1a/lHoM/Id6hHyDRh DcDW6TVSFDxErIKrKbf4+LZQwXySJtvaxVBQrUBTSL595OE0AXntNFPKCcQtxzYM EfKWwxUVGVlAUWXB8cGCOYWFY76NQTBCT+YXyaH0N7zltjDwKwYEbAwP89g18Gp9 QmiQHoMdyNH+iIHsk0CpqyQl1lDfsTAXGViI4yYRai5l+0fFK3NimniS/OA== 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= fm2; bh=HJyrB3d3k5zAjMRXq5XvATrNV8XMQnBecR2x9RR/LJE=; b=hMIx6IJZ 4tLEPOSkfAScYEJD4KH7C6IlHFOnaTOKzaUDulk7Bi7VcWN0tyJa8RzQMOIrAidB w2XwTwCmV9sMRM12WI9YjCRLhZMIMle5E1iONvsr9O8TsEb3mRFF9q4LGXp76VrU WzSCKJMtMM8EIDcrc69u/DboAPhTcKZFXgwwXM1dMfSxih0e3u+V08DqXrNThcCJ QwgIsZaAegKI2Y3y1T/M8ja0/+j4H/iL9k28YpVlnhMtsvxDbnsGq+LXZifpWF7p goudp73iel2sKEaE6vevKNdcUK5V2Z3ntkch2Y0iDjX0veOQjr/eatngI0s9vpxQ qm/8HTsoMriGwA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeluddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucfkphepudefrdekvddrkeefrddvvdeknecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhothdrnh gvth X-ME-Proxy: Received: from fv-az201-811.ett4tu3jvdse5ovc2mkgjqcs5a.bx.internal.cloudapp.net (unknown [13.82.83.228]) by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 30 May 2021 04:26:44 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3810421478931417925==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20210530083605.CA7793A346C@ietfa.amsl.com> Date: Sun, 30 May 2021 01:36: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, 30 May 2021 08:36:12 -0000 --===============3810421478931417925== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+0/-4/=F0=9F=92=AC6) 5 issues received 6 new comments: - #76 Client-side fanout (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/76 [question]=20 - #75 Track Expected Types of Deployments (2 by beurdouche) https://github.com/mlswg/mls-architecture/issues/75 [editorial] [help w= anted]=20 - #54 Review from Joel Alwen (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/54 [editorial]=20 - #49 Provide recommandations for Key Update (1 by seanturner) https://github.com/mlswg/mls-architecture/issues/49 [recommendation]=20 - #48 Description of the formal security guarantees that the protocol MUS= T provide (1 by beurdouche) https://github.com/mlswg/mls-architecture/issues/48 [work in progress] = 4 issues closed: - Provide recommandations for Key Update https://github.com/mlswg/mls-arc= hitecture/issues/49 [recommendation]=20 - Client-side fanout https://github.com/mlswg/mls-architecture/issues/76 = [question]=20 - Review from Joel Alwen https://github.com/mlswg/mls-architecture/issues= /54 [editorial]=20 - Description of the formal security guarantees that the protocol MUST pr= ovide https://github.com/mlswg/mls-architecture/issues/48 [work in progress= ]=20 Pull requests ------------- * mlswg/mls-architecture (+0/-1/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #80 Rewrite AS definition to reflect its role in the Spec (1 by beurdou= che) https://github.com/mlswg/mls-architecture/pull/80=20 1 pull requests merged: - Rewrite AS definition to reflect its role in the Spec https://github.com/mlswg/mls-architecture/pull/80=20 * mlswg/mls-protocol (+0/-4/=F0=9F=92=AC12) 11 pull requests received 12 new comments: - #471 Use HPKE draft-08 (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/471=20 - #469 Fix typos in the "IANA Considerations" section (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/469=20 - #466 Minor fixes to message formats (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/466=20 - #465 Rename add-only Commit to partial Commit. (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/465=20 - #464 Clarify which extensions should go into the group context (1 by kk= ohbrok) https://github.com/mlswg/mls-protocol/pull/464=20 - #463 Remove AppAck proposal. (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/463=20 - #462 Make ratchet tree section clearer. (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/462=20 - #455 Make PreSharedKeys non optional in GroupSecrets (2 by seanturner) https://github.com/mlswg/mls-protocol/pull/455=20 - #454 more editorial changes (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/454=20 - #453 Use the GroupContext to derive the joiner_secret (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/453=20 - #439 Identities SHOULD be unique per group (1 by seanturner) https://github.com/mlswg/mls-protocol/pull/439=20 4 pull requests merged: - Use HPKE draft-08 https://github.com/mlswg/mls-protocol/pull/471=20 - Minor fixes to message formats https://github.com/mlswg/mls-protocol/pull/466=20 - Rename add-only Commit to partial Commit. https://github.com/mlswg/mls-protocol/pull/465=20 - Make PreSharedKeys non optional in GroupSecrets https://github.com/mlswg/mls-protocol/pull/455=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============3810421478931417925== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday May 30, 2021

Issues

mlswg/mls-architecture (+0/-4/=F0=9F=92=AC6)

5 issues received 6 new comments:

4 issues closed:

Pull requests

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

1 pull requests received 1 new comments:

1 pull requests merged:

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

11 pull requests received 12 new comments:

4 pull requests merged:

Repositories tracked by this digest:

--===============3810421478931417925==--