From nobody Mon Aug 5 04:28:07 2019 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 632A9120192 for ; Mon, 5 Aug 2019 04:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 ZUOb7Wd-zwJS for ; Mon, 5 Aug 2019 04:28:04 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 1580512018A for ; Mon, 5 Aug 2019 04:28:04 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id y26so80523066qto.4 for ; Mon, 05 Aug 2019 04:28:04 -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=sO9s2zja3f8MTBeuzx+n651w6IeXOEePPqOLvQHg4PE=; b=XhP9GQE7ZH77+r836ns51JPqacL3nKsg1cX/mN1sL1WSqo1SwKSQwUrMzAIseQGJ1m xXR6afVwfEjmFUGPSVbnfgJEZkTkZT7nBR+mVizcSdYEX43UgnYox4A1iaA6yl11/8mJ PXhEjR3MqYtzy9eeyo96kT1K1hia+VZedn0Bs= 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=sO9s2zja3f8MTBeuzx+n651w6IeXOEePPqOLvQHg4PE=; b=BpuBtxGRDwo00/4qjQTcyrLTY07k1pn+f8fTY13xO/g4jgqt7/KcsiKMVpc7evbSUr eAPoAbAehvmhyNKiBgZcCFrfGfa7TArsnHE9Ylul2PtOIfusilBtNjhuObBrvEz5U3bs 81kyYdJQy3tvcUxyzMNwG03+Jde+OWlOe6EVUmdYO692dzdnWgOCFQ6qCm2j9A89uk7y WU5n4M2J5WDtfrQEHAsJbjXdKo2V897r1uhyE6RrEfSCr/M0tfduTWuGtcrH2n3IU/ce 2J4nq4JeR7bFtzu7tc8POqqk87nQdkjWkeA9RO5MVkXwhUMQQVhUhh7eqJQOjMUb3hNG QuWg== X-Gm-Message-State: APjAAAXU/rFlXTPJ1Lu4xfDDuZof5dfnzF801TQlVNXPv1aG6hS7In8v 4ESBlL8urOefqZSeT7/hIEn3pXr4 X-Google-Smtp-Source: APXvYqxdwQBCQDjTNDSc0UW2Ci1Vu0Up21CZkoPF77c20pTOatJNaPUvlu2e1JFP4vyUIF+HqHf5Ww== X-Received: by 2002:ac8:4084:: with SMTP id p4mr106272565qtl.172.1565004483071; Mon, 05 Aug 2019 04:28:03 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id g10sm33312726qki.37.2019.08.05.04.28.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Aug 2019 04:28:02 -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 12.4 \(3445.104.11\)) Message-Id: <31DF7C54-7D2C-4A1A-8FA7-8199BD3DCE59@sn3rd.com> Date: Mon, 5 Aug 2019 07:28:01 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] MLS@IET105: draft minutes 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, 05 Aug 2019 11:28:05 -0000 Draft minutes have been posted to: https://github.com/mlswg/wg-materials/blob/master/ietf105/minutes.md Please let the chairs know if you would like to make any corrections by = 9 August. spt= From nobody Wed Aug 7 10:58:47 2019 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 9E5A6120690 for ; Wed, 7 Aug 2019 10:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=dC+kmXl9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Uib3G4Ek 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 zUY19R8YNpGl for ; Wed, 7 Aug 2019 10:58:43 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DAB0120284 for ; Wed, 7 Aug 2019 10:58:43 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AE8742013C for ; Wed, 7 Aug 2019 13:58:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 07 Aug 2019 13:58:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm3; bh=0aNaLHBdK0nnARasvsqcFdiryONHd4QjE 0Z1xnZE+aY=; b=dC+kmXl9iyI3vYSAT9cZsDKtCvgNLKNohRys8PF3Pjvw/K3LV h57lIkepN5cIJx+j6kT8V4XkGf2tCveGNoTPFcdUiIIATu7Q3XNVc/QOI04HbNrR OXSTb3SCCLQXeLrLt0fG2P41AJafwoOaVto23Qo2IMymSxn02yW8YwSPvlcMfz4w wsYt931LpkWEoGrc9guNsdQdEdvPhnmKPCPq2kAU4UNcKsBFu0lSpuaIE974X5k8 74b/J1Azm8jvJxRU7BD5a5m95Oh8p5AYipvMj1WGD9SctewxQ3Q3BpeXy+KinWSX Zk2JsMrmsldFe0b3qq/lxZ7l4RLiM7OdOUS6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=0aNaLH BdK0nnARasvsqcFdiryONHd4QjE0Z1xnZE+aY=; b=Uib3G4EkPF8TtmU+cLoh7o 8P+SnEg2+HbhNPVFkyf4JTfpTT8hYakqit5rq13NXo0U8j4cRZ4nIIhCfWpgckgF AmwuCt0yQPy4jEnT/aox4Y6aIeVL7IMTfE/f2gwS091mfN9R0uXvlwi+ekcUT9Xq wssN1+xg54C2SrcCGA48MOjG06XUqLbw89HJLeldPOtHsiPEj7iXRIetkZdQdr9k EuL3nNqZSjxYyDms3d2ibJHmtt/4UBOrIAZyBTvdCbmDJGQJJmJ+ENIPJI3OSBnZ ivzhDJ9a0WCO+Md6FJerWpL5YHYTnC9/6jEpifRJz+Iai0v/aEtgZYZS8IsKmamg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephfgtgfgguffkfffvofesthhqmh dthhdtvdenucfhrhhomhepofhitghhrggvlhcutfhoshgvnhgsvghrghcuoehmihgtrhho sehfrghsthhmrghilhdrtghomheqnecukfhppedvtdegrddugeekrdegvddrudegvdenuc frrghrrghmpehmrghilhhfrhhomhepmhhitghrohesfhgrshhtmhgrihhlrdgtohhmnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from [192.168.7.172] (unknown [204.148.42.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F850380075 for ; Wed, 7 Aug 2019 13:58:42 -0400 (EDT) From: Michael Rosenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <13C4667A-7D07-4E67-B762-9EF13723160C@fastmail.com> Date: Wed, 7 Aug 2019 13:58:41 -0400 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] Sending secrets in WelcomeInfo instead of keys 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, 07 Aug 2019 17:58:46 -0000 Problem ------- The special-casing required to use WelcomeInfo::add_key_nonce in = unframing Add messages nontrivially increases code complexity. Framing ordinarily depends on just a handshake_secret and = sender_data_secret. =46rom those, the framer/unframer derives the = handshake key/nonce and sender data key/nonce. But in the case of an Addee processing an incoming Add, the Addee's = unframer needs to be told to use the handshake key / nonce from the = previous WelcomeInfo, and be told to not attempt to decrypt = MLSCiphertext::encrypted_sender_data, because 1) The only reason it would need to do this is to derive the handshake = key/nonce, which it already has, and 2) the Addee doesn't even know sender_data_key. This is complex enough that it becomes hard to reason about and painful = to implement. Proposal -------- To reduce the amount of special casing necessary, the handshake_secret = and sender_data_secret be included in WelcomeInfo instead of = handshake_key and handshake_nonce. This way, the only steps in the = algorithm that differ between the Addee and non-Addees is where the = inputs to the unframer's constructor come from, i.e., = Unframer(group_ctx.handshake_secret, group_ctx.sender_data_secret) = versus Unframer(welcome_info.handshake_secret, = welcome_info.sender_data_secret). Benjamin mentioned that this is technically a violation of the secrecy = invariant of TreeKEM: a user who is not a member of a group at epoch n = cannot know secrets from epoch n. It should be noted though that this is = already violated by the existence of WelcomeInfo::init_secret and = WelcomeInfo::add_key_nonce. -Michael= From nobody Wed Aug 7 11:13:58 2019 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 281C51204D1 for ; Wed, 7 Aug 2019 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=fastmail.com header.b=oSMVtBzN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BXUHqG7v 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 GCKaHJcpelny for ; Wed, 7 Aug 2019 11:13:55 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2F21202E1 for ; Wed, 7 Aug 2019 11:13:54 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 256062208C for ; Wed, 7 Aug 2019 14:13:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 07 Aug 2019 14:13:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm3; bh=+lQX8UwCTo8dk1nolvCC4OmwoXL3d2bRq e9v/1QgV5Y=; b=oSMVtBzN5WRd42qIgVhCmHMgZFddFlAkKnfnl6zG3GfvzGQmv EB4rfUzKPH8mp9MR1BegB3vuQ9CnXYaVhV14Ghq7+E+ObbrngNf9+/ntDOS9V47a F9RFOTx8xFmQJP/8G9OZLi3TG9LIWNITlOEGDAyk1yUG71J4R+C0PzsjiC7XK9el NdEiRzo3zWZsfxArHzthiIDGGZ6VrkusRxH6rbAv+0libaZn4aOHJwtNyF/7jZPn itzss0VOqgv8EdMsJwkPR8haz2dR8fwKbAAx/i7HUWYEQAJeNOCz9SnDpJezxCDb zp9a7UwvB4Q8cTVv7XdoigmhfK4k7ZFHawTzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+lQX8U wCTo8dk1nolvCC4OmwoXL3d2bRqe9v/1QgV5Y=; b=BXUHqG7vE5fZRslfy3LhZs mOPt9Mn8J3qto6kMIw1ExD5kzH5Pu27NGtk7SFMwBY721lcGVgDTlQB+vkb+Iv/O xdQolByZxqfbnnsfbirhar1YV5h6WDKPsqbUDCNromWu1BtcTce0cVYNeiDf60GM WNZgTMD3/Wg+fWzEtRiFkNehQNAIiSEqAmzbdlzo41R8nH3oD6JQKgrZY7+VpoLo lkLfwjAezjiLi1mLIsOaW02PweNZhHLj3dVTKVU4/Ow6fr21YvVCGI8XB3RWr/uh XlF8s25dQZKNEIchtR8VcWhTikZ4y7beE4DDGhU5qqHuxt5GdKM1R/729zE3yprQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduvddguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephfgtgfgguffkfffvofesthhqmh dthhdtvdenucfhrhhomhepofhitghhrggvlhcutfhoshgvnhgsvghrghcuoehmihgtrhho sehfrghsthhmrghilhdrtghomheqnecuffhomhgrihhnpehtrhgrihhlohhfsghithhsrd gtohhmnecukfhppedvtdegrddugeekrdegvddrudegvdenucfrrghrrghmpehmrghilhhf rhhomhepmhhitghrohesfhgrshhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: from [192.168.7.172] (unknown [204.148.42.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D63C80063 for ; Wed, 7 Aug 2019 14:13:53 -0400 (EDT) From: Michael Rosenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <397DC837-51D5-4456-8234-80778E211CE7@fastmail.com> Date: Wed, 7 Aug 2019 14:13:52 -0400 To: Messaging Layer Security WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] Blog post on MLS and molasses 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, 07 Aug 2019 18:13:56 -0000 Hi all, I made a post about MLS and my Rust implementation. The = intention was to make an argument for why we need MLS and explain how it = differs from prior art. It's meant to be approachable for those with = just a little bit of background knowledge in crypto. Please yell at me = if I got something wrong :) https://blog.trailofbits.com/2019/08/06/better-encrypted-group-chat/ -Michael= From nobody Wed Aug 7 11:50:31 2019 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 EDA4E12071E for ; Wed, 7 Aug 2019 11:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUT977zSl5W9 for ; Wed, 7 Aug 2019 11:50:15 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 03DCC1206A7 for ; Wed, 7 Aug 2019 11:50:15 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id z23so180659ote.13 for ; Wed, 07 Aug 2019 11:50:14 -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=RU1NDX6KLqc44YNOykakNF8h18ms1YvMlcJGmHF9POY=; b=RVvBV5pKHTxImYPjTRR5n8dFTPw7JFlzc1+eOjS/USSQoadfPlCmBOy9l59KRk7/tZ X/vc+OXB52gVCrPBHCk9inSjBS0LCmqDFYYQfZ7XT8+wQxPalaUmeKPTznGdUFFwIYaq F6DrQQsMTfUqg/53xQ6YhaFTZxhuIJyELCskv/ZXkAlOeHc5ZKpqiokqPep/2lIVBTJz JeCHtp1dXWws753yRc6zlLLzeG/sk+6x+tbil34p8aCwsXUKtJnjZDZrinTwaVed1QRX 95qyXccTDjdRJ9nyhnoUYG+NpjjD+VR/rCTBPFnL3uHCgF3+VTAQplLq04cRWyr0VWvP tMQQ== 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=RU1NDX6KLqc44YNOykakNF8h18ms1YvMlcJGmHF9POY=; b=Rv6kGCj7+gfP6ETJKbUCoIK2X/Mzgn/GLzW1VKNUdkyyLStyodChKFp+L9O5YIQc+D P++AW+QRrfiuWCFBkoYhJKFscV9bzmy1VZVAnQ8JHRoKF1+LCUviIlXoEub/1BSXkxR3 Auf5t5dFkmi0+bWdwrVh4WfiFP1u+s/4vvIq4aq6lypdwLUkrpH7egsFRVTQHa1CfTIf fU05WYiSQyz4ZlIJph4c2TM+OhMODE12/NCbthHy9H9GEC67zCPryqQRtMfc5urw5YhN yzxB/u8fxnMNLiERVXPz3FRdzCF1cMjVc7PAp9dx1G3cuI2IowfCgKfwFI/Jb1A130eE B73A== X-Gm-Message-State: APjAAAWk1FjHVZWCWI27yF9ZbvMP7ftI73edgyMqG8MPSkfchiC9ltvh svcLFqazt75fsggR1HrkAf/cMv5RsQNP6288ByXOYw== X-Google-Smtp-Source: APXvYqzEmYXgRKFoLxHETQX25R+O8y3IHcDBfVA5XJ15o8CyWkHBWarEVBAuFgoTXlnxBplgAb7PugTk/jD/0h71K+0= X-Received: by 2002:a9d:390:: with SMTP id f16mr9451522otf.93.1565203814167; Wed, 07 Aug 2019 11:50:14 -0700 (PDT) MIME-Version: 1.0 References: <13C4667A-7D07-4E67-B762-9EF13723160C@fastmail.com> In-Reply-To: <13C4667A-7D07-4E67-B762-9EF13723160C@fastmail.com> From: Richard Barnes Date: Wed, 7 Aug 2019 14:49:14 -0400 Message-ID: To: Michael Rosenberg Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000584961058f8b697a" Archived-At: Subject: Re: [MLS] Sending secrets in WelcomeInfo instead of keys 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, 07 Aug 2019 18:50:26 -0000 --000000000000584961058f8b697a Content-Type: text/plain; charset="UTF-8" Hey Michael, Thanks for bringing this issue up. WelcomeInfo::add_key_nonce does seem like kind of a hack. The change you propose seems sensible to me. It's also coherent with the "lazy operations" proposal I presented at IETF 105. EKR asked there how one does encrypted Add messages in that context. After thinking about it for a bit, the only approach that seems workable to me is to provide the new joiner with the init_secret, sender_data_secret, and handshake_secret for the epoch in which he is added. That would enable the new joiner to decrypt and process all of the handshake messages since the last Ratchet message, and thus be joined to the group on the next Ratchet message. Obviously, this aligns exactly with your proposal. Benjamin's objection seems to reflect a problem in the invariant rather than the solution here. We have always leaked at least the init_secret for an epoch to a new joiner; this proposal just expands that boundary a bit. It seems like the right way to arrange this is to clarify which secrets logically "belong" to which epoch. The init_secret derived from an epoch_secret, for example, would belong to the epoch after the epoch_secret. (And in your proposal, the handshake_secret and sender_data_secret would also move to that side of the line.) Then you could properly require that the secrets in a given epoch are known only to the members of the group in that epoch. --Richard On Wed, Aug 7, 2019 at 1:58 PM Michael Rosenberg wrote: > Problem > ------- > > The special-casing required to use WelcomeInfo::add_key_nonce in unframing > Add messages nontrivially increases code complexity. > > Framing ordinarily depends on just a handshake_secret and > sender_data_secret. From those, the framer/unframer derives the handshake > key/nonce and sender data key/nonce. > > But in the case of an Addee processing an incoming Add, the Addee's > unframer needs to be told to use the handshake key / nonce from the > previous WelcomeInfo, and be told to not attempt to decrypt > MLSCiphertext::encrypted_sender_data, because > > 1) The only reason it would need to do this is to derive the handshake > key/nonce, which it already has, and > 2) the Addee doesn't even know sender_data_key. > > This is complex enough that it becomes hard to reason about and painful to > implement. > > > Proposal > -------- > > To reduce the amount of special casing necessary, the handshake_secret and > sender_data_secret be included in WelcomeInfo instead of handshake_key and > handshake_nonce. This way, the only steps in the algorithm that differ > between the Addee and non-Addees is where the inputs to the unframer's > constructor come from, i.e., Unframer(group_ctx.handshake_secret, > group_ctx.sender_data_secret) versus > Unframer(welcome_info.handshake_secret, welcome_info.sender_data_secret). > > Benjamin mentioned that this is technically a violation of the secrecy > invariant of TreeKEM: a user who is not a member of a group at epoch n > cannot know secrets from epoch n. It should be noted though that this is > already violated by the existence of WelcomeInfo::init_secret and > WelcomeInfo::add_key_nonce. > > -Michael > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000584961058f8b697a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Michael,

Thanks for brin= ging this issue up.=C2=A0 WelcomeInfo::add_key_nonce does seem like kind of= a hack.

The change you propose seems sensible to = me.=C2=A0 It's also coherent with the "lazy operations" propo= sal I presented at IETF 105.=C2=A0 EKR asked there how one does encrypted A= dd messages in that context.=C2=A0 After thinking about it for a bit, the o= nly approach that seems workable to me is to provide the new joiner with th= e init_secret, sender_data_secret, and handshake_secret for the epoch in wh= ich he is added.=C2=A0 That would enable the new joiner to decrypt and proc= ess all of the handshake messages since the last Ratchet message, and thus = be joined to the group on the next Ratchet message.=C2=A0 Obviously, this a= ligns exactly with your proposal.

Benjamin'= ;s objection seems to reflect a problem in the invariant rather than the so= lution here.=C2=A0 We have always leaked at least the init_secret for an ep= och to a new joiner; this proposal just expands that boundary a bit.=C2=A0 = It seems like the right way to arrange this is to clarify which secrets log= ically "belong" to which epoch.=C2=A0 The init_secret derived fro= m an epoch_secret, for example, would belong to the epoch after the epoch_s= ecret.=C2=A0 (And in your proposal, the handshake_secret and sender_data_se= cret would also move to that side of the line.)=C2=A0 Then you could proper= ly require that the secrets in a given epoch are known only to the members = of the group in that epoch.

--Richard


On Wed, Aug 7, 2019 at 1:58 PM Michael Rosenberg <micro@fastmail.com> wrote:
Problem
-------

The special-casing required to use WelcomeInfo::add_key_nonce in unframing = Add messages nontrivially increases code complexity.

Framing ordinarily depends on just a handshake_secret and sender_data_secre= t. From those, the framer/unframer derives the handshake key/nonce and send= er data key/nonce.

But in the case of an Addee processing an incoming Add, the Addee's unf= ramer needs to be told to use the handshake key / nonce from the previous W= elcomeInfo, and be told to not attempt to decrypt MLSCiphertext::encrypted_= sender_data, because

1) The only reason it would need to do this is to derive the handshake key/= nonce, which it already has, and
2) the Addee doesn't even know sender_data_key.

This is complex enough that it becomes hard to reason about and painful to = implement.


Proposal
--------

To reduce the amount of special casing necessary, the handshake_secret and = sender_data_secret be included in WelcomeInfo instead of handshake_key and = handshake_nonce. This way, the only steps in the algorithm that differ betw= een the Addee and non-Addees is where the inputs to the unframer's cons= tructor come from, i.e., Unframer(group_ctx.handshake_secret, group_ctx.sen= der_data_secret) versus Unframer(welcome_info.handshake_secret, welcome_inf= o.sender_data_secret).

Benjamin mentioned that this is technically a violation of the secrecy inva= riant of TreeKEM: a user who is not a member of a group at epoch n cannot k= now secrets from epoch n. It should be noted though that this is already vi= olated by the existence of WelcomeInfo::init_secret and WelcomeInfo::add_ke= y_nonce.

-Michael
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000584961058f8b697a-- From nobody Mon Aug 12 16:15:37 2019 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 CE06A120047 for ; Mon, 12 Aug 2019 16:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17 X-Spam-Level: X-Spam-Status: No, score=-17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oQkvEnbwebIS for ; Mon, 12 Aug 2019 16:15:29 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 DFBD812000E for ; Mon, 12 Aug 2019 16:15:28 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id r6so78358473qkc.0 for ; Mon, 12 Aug 2019 16:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Qn/lkJCnXG3DyduVw91wg3yKEkGVDf6n3nmMtY623yM=; b=TeWrPjFxuaFeF9sXlo9oDenSO2KCM4120uLpdopL9ceWmc2GQPkaE5hPgacCzrEIFa rF1zniKt+zYl12tulrXSB6pFAIBxbZmxFF2xMpE9Q9QyIeZZL+fTAHJjOd9Fp/i74PP8 9HQKoZ4HKhx+ioqBEcLfilOZODt3jHwQ/eHoDOadFAHWjgel2QUzGqzG1vU+sBQ5lORB 7hV0Nh9XlrKMsj+LFERSHQmF34o3Yv/BmR5WtPFsDCVpmLnvOfhSLrGha3BMZTug8+VU ddkqw/qTrMAGw3oO8Y/xUiKX0+F9BE0nyXOFe04C3Y/63QhqixPBCNQSVCCW7KI8NXkl yDFw== 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=Qn/lkJCnXG3DyduVw91wg3yKEkGVDf6n3nmMtY623yM=; b=jl/kUyyQmp3J3mtCF6sQOHGCvR0840mCqrWAglFRy3z6EKzzjr0+Nax2Ovl1MmOzYp EGeEDN+vH1WEsbk0SkAHTbkLtip0sVPW81Tw7uLPfbYmHXmiv5BxfMEmV4AuWWRIMVgE avELNgatQbacXXAqiGjNRO36bkL4rtnMrPfylIvN1mJ19LZHWzog1Aj9wzMHg2lx35/q HsAO+5YlokZKfclgVB96Y5OOJlzRK90/4NBI8Mk8wRz5Ut8JeE3LPMHh/PHe/4B4kppB vv5TqZGz4q8mOW3dTjSPG73EGgXSR3wA0Ly73/IG5z4gh7l65EdbEl0amzsStXUVATAv voxg== X-Gm-Message-State: APjAAAUpAHwIlTUJghLlY2hyZSeFvu0cMjla8gpi1fqxNNyQuIkhwPg3 kUukRmXO3Jz4XTUsRRr6NTXAsSv1MQktpsk31XrMPvzBFApKvA== X-Google-Smtp-Source: APXvYqwDr7GYTuO30WKk0+E9tSNSp0mHC/RYiBYU/5wGIiRJIXFSbYIRHFCHZtykbe05DO8Ud4ID/BsWujKM1c6T2Vw= X-Received: by 2002:a37:7c46:: with SMTP id x67mr5920563qkc.78.1565651727431; Mon, 12 Aug 2019 16:15:27 -0700 (PDT) MIME-Version: 1.0 From: Peter Slatala Date: Mon, 12 Aug 2019 16:15:01 -0700 Message-ID: To: mls@ietf.org, Benjamin Beurdouche Content-Type: multipart/alternative; boundary="0000000000000ec623058ff3b3f5" Archived-At: Subject: [MLS] AEAD data in messages 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, 12 Aug 2019 23:15:35 -0000 --0000000000000ec623058ff3b3f5 Content-Type: text/plain; charset="UTF-8" Hello! I was wondering if you considered allowing additional plaintext but authenticated data in MLS messages. While I can't think of immediate, compelling use cases right now, I am wondering if such extensibility wouldn't be desired. For example, in encrypted video calls, resolution, framerate, or audio volume can be put in plaintext so that the selective forwarding unit can decide which streams to forward to the group members (and the recipient also uses this data). Here are some use-cases for MLS that I can think of: * sending a 'sending device identifier' in case if delivery service can't differentiate different user devices from each other. * sending 'message type' that server can act upon. For example, delivery report sent by the recipient to the sender, which also acts as an ACK to the server that the message was persisted. * authenticating message id (but make it visible to server to avoid redelivery), * other use cases that I can't think of right now. Have you considered supporting AEAD, or is it already supported and I missed it? Thanks, Peter --0000000000000ec623058ff3b3f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!
I was wondering if you considered allowing addi= tional plaintext but authenticated data in MLS messages.

While I can't think of immediate, compelling use cases right now= , I am wondering if such extensibility wouldn't be desired. For example= , in encrypted video calls, resolution, framerate, or audio volume can be p= ut in plaintext so that the selective forwarding unit can decide which stre= ams to forward to the group members (and the recipient also uses this data)= .

Here are some use-cases for MLS that I can think= of:
* sending a 'sending device identifier' in case if d= elivery service can't differentiate different user devices from each ot= her.=C2=A0
* sending 'message type' that serve= r can act upon. For example, delivery report sent by the recipient=C2=A0to = the sender, which also acts as an ACK to the server that the message was pe= rsisted.
* authenticating message id (but make it visible to serv= er to avoid redelivery),
* other use cases that I can't t= hink of right now.

Have you considered supporting = AEAD, or is it already supported and I missed it?

= Thanks,
Peter
--0000000000000ec623058ff3b3f5-- From nobody Mon Aug 12 23:24:51 2019 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 22F8712008B for ; Mon, 12 Aug 2019 23:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 OKv4CWE6Ok65 for ; Mon, 12 Aug 2019 23:24:46 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A331B12008A for ; Mon, 12 Aug 2019 23:24:46 -0700 (PDT) Received: from [127.0.0.1] (sam.net.in.tum.de [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by sam.net.in.tum.de (Postfix) with ESMTP id 574241C00D2; Tue, 13 Aug 2019 08:26:06 +0200 (CEST) From: Jeff Burdges Message-Id: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> Content-Type: multipart/signed; boundary="Apple-Mail=_68403F65-6EA3-4A07-9682-33EB1776E429"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 13 Aug 2019 08:24:37 +0200 In-Reply-To: Cc: mls@ietf.org To: Peter Slatala References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 06:24:49 -0000 --Apple-Mail=_68403F65-6EA3-4A07-9682-33EB1776E429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Aug 2019, at 01:15, Peter Slatala = wrote: > I was wondering if you considered allowing additional plaintext but = authenticated data in MLS messages. It=E2=80=99d be outside the header encryption, making the AEAD would be = the header encryption? How would the delivery service authenticate it? > Here are some use-cases for MLS that I can think of: > * sending a 'sending device identifier' in case if delivery service = can't differentiate different user devices from each other. I=E2=80=99d hope the delivery service does not care too much to which = device it communicates. > * sending 'message type' that server can act upon. For example, = delivery report sent by the recipient to the sender, which also acts as = an ACK to the server that the message was persisted. > * authenticating message id (but make it visible to server to avoid = redelivery), ACKs and message ids should often be done fully encrypted, but yeah = making one ACK or message id notify both the delivery service and the = end user makes sense in some use cases. Jeff --Apple-Mail=_68403F65-6EA3-4A07-9682-33EB1776E429 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEBA1bLpAiCdPXvXG3q6x/0cwQCnQFAl1SV6UACgkQq6x/0cwQ CnTWnxAAwnpOdCkdDByK7wDKXg4lAdb02LVyrgxp+dchwfPGXyOdqVOfi1W4qlBy B3yQaN8LdIzE9eklZI72ASLsn7vTdNjXk/2BxQWUGLe34woTS9O1SBYzIqm153Eg 9MkDICURp2aBlg+enA6fLMMDAxJCR/wyGs7KhEms5eD7DGmvtKqXDO0YQV01qtKr ANmXS9eue3uJbZmQI+ypbRBzGUMt7gLdt6rs24MypjvnPCwGYJe22OO9tgYmLfvX I6VGWV642UT9Qs0xVbZiN2Q1DwBXm3SBLQCaUykbrE1jBQk3+N3wy1+BC43v+oRC cxKnebSb3DlEtl4hZu1nLxuytQZ6ssZrzXLs8NuiPABqikg19ukv9cKoKy7pXoPf QtkprHxEUJZBiXeMAZRDOpjla6t1QkUAw3XLiM0l8U72/w4w1KPJn+xeOnzW76O2 44zGDtzXeX9GwJ2x+DmZ2cCdCu4k/OGIe3bHXC9jqjkwB+kxyGaMMnaCI5XN+tUW Oid5PR0uslxGPDfTXfazq3bGNtBMIGeaOIvZhJ8ICG+cFotYB4c2FIgazfNq/jQw EHoMZ/Q7DTGxWR4/u7WSX6l3W3nzibimuR5rO9qyYafv0sIK2DK6xdl1fMSwFRqX rFVttuvJgixZNgA5tVhewfrxrVgTc4s6ZvZx55kDQhOSNrtj4M8= =/lQL -----END PGP SIGNATURE----- --Apple-Mail=_68403F65-6EA3-4A07-9682-33EB1776E429-- From nobody Tue Aug 13 07:20:20 2019 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 10A9A120865 for ; Tue, 13 Aug 2019 07:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17 X-Spam-Level: X-Spam-Status: No, score=-17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 BuICDlyC1M2n for ; Tue, 13 Aug 2019 07:20:17 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 4C8A8120864 for ; Tue, 13 Aug 2019 07:20:17 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id s14so9332440qkm.4 for ; Tue, 13 Aug 2019 07:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uCbISVZSjyqu8b3EBAp09Y8fgso5bbOqeJWuzN/l2MQ=; b=G69uf6x9ZWIpo2SjhHCTDBp5RkudgWZEM80nlLMi7q/EALH/pUZlXwcXM9m2iRGUU0 KzqogN1ucT5p47yJheGKN5zYRp1tSckMLHVwCLVQXu+ZQR85BACSP6Wd6esdoO/BTfYe nXJ9s37nPPSKn7zmH+FXq4W3jfiDul8YdOXp214OC6T+7QYQktP3WtOVOSxZRpoGyyUK lEVyUDI2sb/kssBFWhOB9Wpgu/5Q++6PHg4iNrK63JC0IJstqcQfX1oJ4gyGNGpmtYh/ gfVgNhHDYVNmyvJ5sn5C1P7K2Okygoe0bI+vrrjgjQL81cSg5GjGASZRZvhKqVJ/fe41 NwlQ== 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=uCbISVZSjyqu8b3EBAp09Y8fgso5bbOqeJWuzN/l2MQ=; b=OcHXrqle8i+ocaACgCwi52hJ2VYMrhZhQrE6uMfz/McamuJWhl76Ly2E6EKlmSCZrQ LqzAJQguf8oiInl42iW4HorrRNdxyl8MzHiXyBPh3cfHM3BtXEXv7sinFZ2NeK2gZ1Wt rtB0EY+yV0F+PvH3f62TJawH+2tnKdVNPV+XKLL+hAaRvs4ixuviaE4tggHMYsvfidcQ S8EEk/HFN+FK8WPO5Y2XryFmOrqFL+DkivNyG7MsvUjUa/a5J84g8BtE5ZBLXBvpBsY/ yK31ROkVVWMXn2sbRMRi+B0ynQQqS3PCxixlHc9ER/R0CwVi78zbY7yC8LDbbnaVOIAs LM7g== X-Gm-Message-State: APjAAAVlgpRX+JfG92/QuI5Knp9GhV69WnOUxTk1MM04OLEQfTM0Klpt 2dhom0CTMCLjvCg+cuN3Qkhuh9aQlNlmkSsryJpls6s0oAu24w== X-Google-Smtp-Source: APXvYqxG0pzm1IZs6Ca+NMlnnM05hy5KZsqUQo3UmBwUkYG3FPcrOqVy5g8YzWLRI54D1bBfI2Mtek6yubC5hGmOEM0= X-Received: by 2002:a37:ad09:: with SMTP id f9mr4852779qkm.263.1565706016063; Tue, 13 Aug 2019 07:20:16 -0700 (PDT) MIME-Version: 1.0 References: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> In-Reply-To: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> From: Peter Slatala Date: Tue, 13 Aug 2019 07:19:50 -0700 Message-ID: To: Jeff Burdges Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000e970b8059000569f" Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 14:20:19 -0000 --000000000000e970b8059000569f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges wrote: > > > > On 13 Aug 2019, at 01:15, Peter Slatala 40google.com@dmarc.ietf.org> wrote: > > I was wondering if you considered allowing additional plaintext but > authenticated data in MLS messages. > > It=E2=80=99d be outside the header encryption, making the AEAD would be t= he header > encryption? > > How would the delivery service authenticate it? Delivery service is often TLS encrypted so client-server connection should be secure. > > Here are some use-cases for MLS that I can think of: > > * sending a 'sending device identifier' in case if delivery service > can't differentiate different user devices from each other. > > I=E2=80=99d hope the delivery service does not care too much to which dev= ice it > communicates. > > > * sending 'message type' that server can act upon. For example, deliver= y > report sent by the recipient to the sender, which also acts as an ACK to > the server that the message was persisted. > > > * authenticating message id (but make it visible to server to avoid > redelivery), > > ACKs and message ids should often be done fully encrypted, but yeah makin= g > one ACK or message id notify both the delivery service and the end user > makes sense in some use cases. > > Jeff > > > --000000000000e970b8059000569f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 12, 2019 at 11:24 PM Jeff= Burdges <burdges@gnunet.org&g= t; wrote:


> On 13 Aug 2019, at 01:15, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ie= tf.org> wrote:
> I was wondering if you considered allowing additional plaintext but au= thenticated data in MLS messages.

It=E2=80=99d be outside the header encryption, making the AEAD would be the= header encryption?

How would the delivery service authenticate it?
=C2=A0Deli= very service is often TLS encrypted so client-server connection should be s= ecure.

Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 14:22:54 -0000 --000000000000298cf90590006027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think we have a slot for this, but it seems sensible enough. Basically you'd just be changing the API from session.encrypt(application_data) to session.encrypt(aad, application_data). I'd be happy to review a PR. --Richard On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala wrote: > > > On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges wrote: > >> >> >> > On 13 Aug 2019, at 01:15, Peter Slatala > 40google.com@dmarc.ietf.org> wrote: >> > I was wondering if you considered allowing additional plaintext but >> authenticated data in MLS messages. >> >> It=E2=80=99d be outside the header encryption, making the AEAD would be = the >> header encryption? >> >> How would the delivery service authenticate it? > > Delivery service is often TLS encrypted so client-server connection > should be secure. > > >> > Here are some use-cases for MLS that I can think of: >> > * sending a 'sending device identifier' in case if delivery service >> can't differentiate different user devices from each other. >> >> I=E2=80=99d hope the delivery service does not care too much to which de= vice it >> communicates. >> >> > * sending 'message type' that server can act upon. For example, >> delivery report sent by the recipient to the sender, which also acts as = an >> ACK to the server that the message was persisted. >> >> > * authenticating message id (but make it visible to server to avoid >> redelivery), >> >> ACKs and message ids should often be done fully encrypted, but yeah >> making one ACK or message id notify both the delivery service and the en= d >> user makes sense in some use cases. >> >> Jeff >> >> >> _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000298cf90590006027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we have a slot for this, but it see= ms sensible enough.=C2=A0 Basically you'd just be changing the API from= session.encrypt(application_data) to session.encrypt(aad, application_data= ).=C2=A0 I'd be happy to review a PR.

--Richar= d

On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala <psla=3D2Bmls= =3D40google.com@dmarc.ietf.o= rg> wrote:


On Mon, Aug 12, 2019 at 11:24 PM Je= ff Burdges <burd= ges@gnunet.org> wrote:


> On 13 Aug 2019, at 01:15, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ie= tf.org> wrote:
> I was wondering if you considered allowing additional plaintext but au= thenticated data in MLS messages.

It=E2=80=99d be outside the header encryption, making the AEAD would be the= header encryption?

How would the delivery service authenticate it?
=C2=A0Deli= very service is often TLS encrypted so client-server connection should be s= ecure.

MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000298cf90590006027-- From nobody Tue Aug 13 07:43:53 2019 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 9800B12022D for ; Tue, 13 Aug 2019 07:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 7KYpyKmJ7AZ2 for ; Tue, 13 Aug 2019 07:43:49 -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 08770120219 for ; Tue, 13 Aug 2019 07:43:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,381,1559512800"; d="p7s'?scan'208,217";a="395298143" Received: from wifi-pro-83-067.paris.inria.fr ([128.93.83.67]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Aug 2019 16:43:11 +0200 From: Benjamin Beurdouche Message-Id: <53E54F3E-6D9B-4CFF-A13A-F60CB171EE71@inria.fr> Content-Type: multipart/signed; boundary="Apple-Mail=_891F48E3-28C6-44EA-AA5C-A6A94A0899C7"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 13 Aug 2019 16:43:05 +0200 In-Reply-To: Cc: Peter Slatala , ML Messaging Layer Security , Jeff Burdges To: Richard Barnes References: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 14:43:51 -0000 --Apple-Mail=_891F48E3-28C6-44EA-AA5C-A6A94A0899C7 Content-Type: multipart/alternative; boundary="Apple-Mail=_05D5BC68-A1F5-4D46-BAA2-15A1A45863FF" --Apple-Mail=_05D5BC68-A1F5-4D46-BAA2-15A1A45863FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I gave quite a lot of thoughts to this since my last discussion with = Peter but I am going back and forth on this. 1. We can provide a very simple API at the MLS layer that gives weak group membership authentication as you suggest, the danger being = applications sending plaintext instead of ciphertext or confusing authentication = guarantees. 2. The alternative, which I find more flexible but also more dangerous, = would be for the application to use the exporter to externally authenticate = messages which would not got through the MLS secure channel at all; the danger being to have = people doing completely broken stuff. I think I would prefer 1. but I would be curious to know what people = think=E2=80=A6 Ben > On Aug 13, 2019, at 4:21 PM, Richard Barnes wrote: >=20 > I don't think we have a slot for this, but it seems sensible enough. = Basically you'd just be changing the API from = session.encrypt(application_data) to session.encrypt(aad, = application_data). I'd be happy to review a PR. >=20 > --Richard >=20 > On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala = > wrote: >=20 >=20 > On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges > wrote: >=20 >=20 > > On 13 Aug 2019, at 01:15, Peter Slatala = > wrote: > > I was wondering if you considered allowing additional plaintext but = authenticated data in MLS messages. >=20 > It=E2=80=99d be outside the header encryption, making the AEAD would = be the header encryption? >=20 > How would the delivery service authenticate it? > Delivery service is often TLS encrypted so client-server connection = should be secure. >=20 >=20 > > Here are some use-cases for MLS that I can think of: > > * sending a 'sending device identifier' in case if delivery service = can't differentiate different user devices from each other. >=20 > I=E2=80=99d hope the delivery service does not care too much to which = device it communicates. >=20 > > * sending 'message type' that server can act upon. For example, = delivery report sent by the recipient to the sender, which also acts as = an ACK to the server that the message was persisted. >=20 > > * authenticating message id (but make it visible to server to avoid = redelivery), >=20 > ACKs and message ids should often be done fully encrypted, but yeah = making one ACK or message id notify both the delivery service and the = end user makes sense in some use cases. >=20 > Jeff >=20 >=20 > _______________________________________________ > 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=_05D5BC68-A1F5-4D46-BAA2-15A1A45863FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = gave quite a lot of thoughts to this since my last discussion with Peter = but I am going back and forth on this.

1. We can provide a very simple API at = the MLS layer that gives
weak group membership = authentication as you suggest, the danger being applications
sending plaintext instead of ciphertext or confusing = authentication guarantees.

2. The alternative, which I find more flexible but also more = dangerous, would be
for the application to use the = exporter to externally authenticate messages which would
not got through the MLS secure channel at all; the danger = being to have people
doing completely broken = stuff.

I think = I would prefer 1. but I would be curious to know what people = think=E2=80=A6

Ben



On Aug = 13, 2019, at 4:21 PM, Richard Barnes <rlb@ipv.sx> wrote:

I don't think we have a slot for this, but it = seems sensible enough.  Basically you'd just be changing the API = from session.encrypt(application_data) to session.encrypt(aad, = application_data).  I'd be happy to review a PR.

--Richard

On Tue, Aug 13, 2019 at 10:20 AM Peter = Slatala <psla=3D2Bmls=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug = 12, 2019 at 11:24 PM Jeff Burdges <burdges@gnunet.org> wrote:


> On 13 Aug 2019, at 01:15, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ietf.org> wrote:
> I was wondering if you considered allowing additional plaintext but = authenticated data in MLS messages.

It=E2=80=99d be outside the header encryption, making the AEAD would be = the header encryption?

How would the delivery service authenticate it?
 Delivery service is often TLS encrypted so = client-server connection should be secure.


> Here are some use-cases for MLS that I can think of:
> * sending a 'sending device identifier' in case if delivery service = can't differentiate different user devices from each other.
=
I=E2=80=99d hope the delivery service does not care too much to which = device it communicates.

> * sending 'message type' that server can act upon. For example, = delivery report sent by the recipient to the sender, which also acts as = an ACK to the server that the message was persisted.

> * authenticating message id (but make it visible to server to avoid = redelivery),

ACKs and message ids should often be done fully encrypted, but yeah = making one ACK or message id notify both the delivery service and the = end user makes sense in some use cases.

Jeff


_______________________________________________
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=_05D5BC68-A1F5-4D46-BAA2-15A1A45863FF-- --Apple-Mail=_891F48E3-28C6-44EA-AA5C-A6A94A0899C7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC2Yw ggUAMIID6KADAgECAhADS+4XH7fhBjcv1HJCQL0qMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgxMjAwMDBaFw0yNDEx MTgxMjAwMDBaMGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENB IDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGpbsfVYL0pTRyFHJlm1/V6qBo2JuC iU9TYpx7jM4O2tQyDq8bjMum69vg6wM0lMGHflMgqB75GxeKfQFmEldoXi2cLishqFUvU2cJeM3S aRsLk2BsuCgTzh9NsYgmrUX60KHOq7eYKVZxbPFWJF2nMOBuMXNu2qBXTGSLeLXHnNvG3r7TLzGg 1oA5teAxQE6Eo8ySSeIXbP7wZB76urwlh51PIbrJZjkDjdQVELh7OlTP1WO6T/Hf6BsEfeFcpoa1 e+MW/lw0VetTPPHQ15HYKYP2WYohHxzDiC+QUwE7UZVBlp9cXIpwHuDzSibc5RG3z0n/j2SQCx0D k5FMAUErAgMBAAGjggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5 BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggr BgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9v dENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQU8CHpSXdzn4WuGDvoUnAU Bu1C7sowHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEB ADrCGyv+Y967YbS5R6j8fAWxJiAiUZvIPfn1xVgesF6jspwCQY8xGn/MG04d+Jh97I8I/Xfx29JE EFq2rQmw4PxiO9RiDZ7xoDxNd4rrRDR7jrtOKQP8J+o+ah0vSOP62hnD/zPS7NRMtIyVS2G277KA L5fIR62ngr984fmJghDv0bsjGAmeu3EP0xhUsDJT61IoAGoKBnxBPAeg3WXsdSm4Gn7btyvakeyF tYebr2KmOBSa28PRqGSDur56aZhJoM2eMzc6prmvGwwtAzRsc5t2OsKRuHWV6O3anP2K27jGZR2b i1VX1NQUvIbpVNTuwjm+XcZtsa/AAJF9KGkEseAwggZeMIIFRqADAgECAhAOBcSAioTLk3iEOCnT FJ4lMA0GCSqGSIb3DQEBCwUAMGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k MRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBl cnNvbmFsIENBIDMwHhcNMTgwNTI5MDAwMDAwWhcNMjEwNTI5MTIwMDAwWjCBjTELMAkGA1UEBhMC RlIxFTATBgNVBAcTDFJvY3F1ZW5jb3VydDFJMEcGA1UEChNASW5zdGl0dXQgTmF0aW9uYWwgZGUg UmVjaGVyY2hlIGVuIEluZm9ybWF0aXF1ZSBldCBlbiBBdXRvbWF0aXF1ZTEcMBoGA1UEAxMTQmVu amFtaW4gQkVVUkRPVUNIRTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANrsbYjccHUi gIc0gRS98dZ7UWPChTEDITyXfXST6Q4/VxfELVLb8O//z/S1UaHMRJR0KEUvzGOQqolsn1bS7SOv f0aQwIV1paBOj9B1X9ID8iGazy9P4jRqSW+cQM49qDrXSkfjOfeHo/BhSD+b2T6DVwEArg/sdvfs Zv5h6YwEZEhymJCiYASH3SIANYdF61TteDC4G+QMbK3I+xtixD1AgBC2sVtTGh+zTWMVA89zNJdw 3eq34jvodmM7kz0RmNHDnRqhPyl2BEKxTrzBJmUoa4uSkpsJAcWqwG4PTnb4E1VIz+xk4smgVx0U 1t3NhmQffO6rbCGAvUnctL6QK9ss5MoxDuDMoIdy0ZJyvUcfUkV/iELWVDRsvd1neBz5dmQL7RSt ug/2qcQgqWeiCVtxauLALj3W4QPvRS2qnlMBtznuFulnn0R7CMt8ZRmvYOgqcDBRKeJhiuuFoIYr xRTtTr6X0HiMNtVSY90wWZAaRXMsS1YRhtxj2xlmJs5u+gd7utDf7RvcNlFzsJSsPQya2VgEPv9z oT+S3jT/YRUGl1P3ZnGr0TqbvDSqUGr41N5fniSbb8Dozr23kfCimxMQNjQ7H57P4p+kKMpFny8D vJauxVnev0w9Bj3cxHbe+FIsMEhoBy7+71FNFnHCpPeRNRlpEn8G/Sl+ggdQJRMVAgMBAAGjggHb MIIB1zAfBgNVHSMEGDAWgBTwIelJd3Ofha4YO+hScBQG7ULuyjAdBgNVHQ4EFgQUAjRpJb6H5V8n D+QmU8ig6EyolewwDAYDVR0TAQH/BAIwADAnBgNVHREEIDAegRxiZW5qYW1pbi5iZXVyZG91Y2hl QGlucmlhLmZyMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw QwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj ZXJ0LmNvbS9DUFMwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL1RF UkVOQVBlcnNvbmFsQ0EzLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL1RFUkVO QVBlcnNvbmFsQ0EzLmNybDBzBggrBgEFBQcBAQRnMGUwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTA9BggrBgEFBQcwAoYxaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1RF UkVOQVBlcnNvbmFsQ0EzLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqC8HmYBBFsSHs0mxb+5CxQRR SJKCe76YfYVhb6sM4bIT96myi8pQhdnP4MbBSyEq+FlQUIxUDLhbn3YyBKFRJIOrDbVWCFi32DPW YSXO420F0M3O4LMbjJYpC2BdkxmtH5ovTbm8HjvZGHdRruEVe7JKL/o9yc9smFq0cSAzXjLEWugh hzrfYjewI+PLwbHvcJ2c8UULvYN+jULIbj+sIs/2TjhlAzwNOHKHK2J7Y/1cr/9nrTN9BAiU7YcL Pr+UFstvYY9UQx7GE8aRJCkQCq+G37n/Tp07VGe5nVwoqoCyNCajJb4rVZv/0MEqCt3ZPKvSMRXA ivjo9D/3FNqjzTGCBDUwggQxAgEBMH0waTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhv bGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJF TkEgUGVyc29uYWwgQ0EgMwIQDgXEgIqEy5N4hDgp0xSeJTANBglghkgBZQMEAgEFAKCCAYkwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwODEzMTQ0MzA1WjAvBgkq hkiG9w0BCQQxIgQg7Q9x0uRldo7W2dMaIeTzHz6EngqD8WBYx+QsQM/HKGYwgYwGCSsGAQQBgjcQ BDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMwIQ DgXEgIqEy5N4hDgp0xSeJTCBjgYLKoZIhvcNAQkQAgsxf6B9MGkxCzAJBgNVBAYTAk5MMRYwFAYD VQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEd MBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMCEA4FxICKhMuTeIQ4KdMUniUwDQYJKoZIhvcN AQEBBQAEggIAGkZEdS1VR2NJTcGvVskcY9bPm2fVifFjMyk5E3ZwIKVqVUF0LYenEwDNkRBF4lF6 Gm0ixHZUZ29wnC4OTgOBh8+GnXQQqbwQjdrjLM0eyMUCs3E8msNG+Y47/gKucibH1jM79csIQV8v mtLsX33XxnjTkL7lBQ/vKmFSk8t/6egUBsqf3tfiJR+moqwtXCmXmKP0qTimY7xlwINzKSBN/8DN rEnUZFny754dzFtGiSEH8/ja3qmbMdEehQUcdO6BM4Zu2Vl8OXnuuPl+6YY4NP4/Brlo+WYjoVAm yrntHxzgCgNh0E/brKYwqqlrawqRe5LueEtDYJneyIqjjCPWhjuVNB7Kxb3aegH9W4gzvPrGQXe2 aj5qxreGH33Z2yS6q3Dtho9EnYqIOg4B2AcRjtZDer7uxWwdCespSRw7Kx+U/9wO6oGY6vr5WePZ yy+2e9pTXaHc48eYaIrcXz7+NF8tFdPdMaMVDP5klHv05FvX4+CFyYTRQTOUtivg58RaFmGymVGs fvv60fIg0oRL4eXXjwepbB9rgoi2IuyRizXcWxRpNKNJWzvoV0g6J9ZK5igGVekOkARIhnLsuKsP yGnUNuCZM9FpVzjPTK0Hi26zDSybkjIpGVicDCXt+l2F/Fp4bdlV1Rp2U6tbIvmjAleGrXYC+gt6 Rs/1M0ZnzUoAAAAAAAA= --Apple-Mail=_891F48E3-28C6-44EA-AA5C-A6A94A0899C7-- From nobody Tue Aug 13 07:47:49 2019 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 BA73412082C for ; Tue, 13 Aug 2019 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 7rWJlIEWtjoi for ; Tue, 13 Aug 2019 07:47:40 -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 7E6F7120251 for ; Tue, 13 Aug 2019 07:47:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,381,1559512800"; d="p7s'?scan'208,217";a="395298523" Received: from wifi-pro-83-067.paris.inria.fr ([128.93.83.67]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Aug 2019 16:47:37 +0200 From: Benjamin Beurdouche Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9F22962F-AF41-441D-85AB-9D1CD7EC70F1"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 13 Aug 2019 16:47:32 +0200 In-Reply-To: <53E54F3E-6D9B-4CFF-A13A-F60CB171EE71@inria.fr> Cc: ML Messaging Layer Security , Jeff Burdges , Peter Slatala To: Richard Barnes References: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> <53E54F3E-6D9B-4CFF-A13A-F60CB171EE71@inria.fr> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 14:47:48 -0000 --Apple-Mail=_9F22962F-AF41-441D-85AB-9D1CD7EC70F1 Content-Type: multipart/alternative; boundary="Apple-Mail=_07018C85-ACF8-442B-B4D9-052E24C60B29" --Apple-Mail=_07018C85-ACF8-442B-B4D9-052E24C60B29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 13, 2019, at 4:43 PM, Benjamin Beurdouche = wrote: >=20 > I gave quite a lot of thoughts to this since my last discussion with = Peter but I am going back and forth on this. >=20 > 1. We can provide a very simple API at the MLS layer that gives > weak group membership authentication as you suggest, the danger being = applications > sending plaintext instead of ciphertext or confusing authentication = guarantees. Well, actually the inner signature should still be there and cover the = prefix of the ciphertext (including the AAD) so, you would have strong authentication after = decrypting and checking the signature=E2=80=A6 That makes me go towards 1. even more=E2=80=A6 B. > 2. The alternative, which I find more flexible but also more = dangerous, would be > for the application to use the exporter to externally authenticate = messages which would > not got through the MLS secure channel at all; the danger being to = have people > doing completely broken stuff. >=20 > I think I would prefer 1. but I would be curious to know what people = think=E2=80=A6 >=20 > Ben >=20 >=20 >=20 >> On Aug 13, 2019, at 4:21 PM, Richard Barnes > wrote: >>=20 >> I don't think we have a slot for this, but it seems sensible enough. = Basically you'd just be changing the API from = session.encrypt(application_data) to session.encrypt(aad, = application_data). I'd be happy to review a PR. >>=20 >> --Richard >>=20 >> On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala = > wrote: >>=20 >>=20 >> On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges > wrote: >>=20 >>=20 >> > On 13 Aug 2019, at 01:15, Peter Slatala = > wrote: >> > I was wondering if you considered allowing additional plaintext but = authenticated data in MLS messages. >>=20 >> It=E2=80=99d be outside the header encryption, making the AEAD would = be the header encryption? >>=20 >> How would the delivery service authenticate it? >> Delivery service is often TLS encrypted so client-server connection = should be secure. >>=20 >>=20 >> > Here are some use-cases for MLS that I can think of: >> > * sending a 'sending device identifier' in case if delivery service = can't differentiate different user devices from each other. >>=20 >> I=E2=80=99d hope the delivery service does not care too much to which = device it communicates. >>=20 >> > * sending 'message type' that server can act upon. For example, = delivery report sent by the recipient to the sender, which also acts as = an ACK to the server that the message was persisted. >>=20 >> > * authenticating message id (but make it visible to server to avoid = redelivery), >>=20 >> ACKs and message ids should often be done fully encrypted, but yeah = making one ACK or message id notify both the delivery service and the = end user makes sense in some use cases. >>=20 >> Jeff >>=20 >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_07018C85-ACF8-442B-B4D9-052E24C60B29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 13, 2019, at 4:43 PM, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:

I gave quite a lot of = thoughts to this since my last discussion with Peter but I am going back = and forth on this.

1. = We can provide a very simple API at the MLS layer that gives
weak group membership authentication as you suggest, the = danger being applications
sending plaintext instead = of ciphertext or confusing authentication = guarantees.

Well, actually the inner signature should still be = there and cover the prefix of the ciphertext
(including the = AAD) so, you would have strong authentication after decrypting and = checking the signature=E2=80=A6

That = makes me go towards 1. even more=E2=80=A6
B.

2. The alternative, which = I find more flexible but also more dangerous, would be
for the application to use the exporter to externally = authenticate messages which would
not got through = the MLS secure channel at all; the danger being to have people
doing completely broken stuff.

I think I would prefer 1. but I would = be curious to know what people think=E2=80=A6

Ben



On Aug 13, 2019, at 4:21 PM, Richard Barnes <rlb@ipv.sx> wrote:

I don't think we have a slot for this, but it = seems sensible enough.  Basically you'd just be changing the API = from session.encrypt(application_data) to session.encrypt(aad, = application_data).  I'd be happy to review a PR.

--Richard

On Tue, Aug 13, 2019 at 10:20 AM Peter = Slatala <psla=3D2Bmls=3D40google.com@dmarc.ietf.org> wrote:


On Mon, Aug = 12, 2019 at 11:24 PM Jeff Burdges <burdges@gnunet.org> wrote:


> On 13 Aug 2019, at 01:15, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ietf.org> wrote:
> I was wondering if you considered allowing additional plaintext but = authenticated data in MLS messages.

It=E2=80=99d be outside the header encryption, making the AEAD would be = the header encryption?

How would the delivery service authenticate it?
 Delivery service is often TLS encrypted so = client-server connection should be secure.


> Here are some use-cases for MLS that I can think of:
> * sending a 'sending device identifier' in case if delivery service = can't differentiate different user devices from each other.
=
I=E2=80=99d hope the delivery service does not care too much to which = device it communicates.

> * sending 'message type' that server can act upon. For example, = delivery report sent by the recipient to the sender, which also acts as = an ACK to the server that the message was persisted.

> * authenticating message id (but make it visible to server to avoid = redelivery),

ACKs and message ids should often be done fully encrypted, but yeah = making one ACK or message id notify both the delivery service and the = end user makes sense in some use cases.

Jeff


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

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

= --Apple-Mail=_07018C85-ACF8-442B-B4D9-052E24C60B29-- --Apple-Mail=_9F22962F-AF41-441D-85AB-9D1CD7EC70F1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC2Yw ggUAMIID6KADAgECAhADS+4XH7fhBjcv1HJCQL0qMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgxMjAwMDBaFw0yNDEx MTgxMjAwMDBaMGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENB IDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGpbsfVYL0pTRyFHJlm1/V6qBo2JuC iU9TYpx7jM4O2tQyDq8bjMum69vg6wM0lMGHflMgqB75GxeKfQFmEldoXi2cLishqFUvU2cJeM3S aRsLk2BsuCgTzh9NsYgmrUX60KHOq7eYKVZxbPFWJF2nMOBuMXNu2qBXTGSLeLXHnNvG3r7TLzGg 1oA5teAxQE6Eo8ySSeIXbP7wZB76urwlh51PIbrJZjkDjdQVELh7OlTP1WO6T/Hf6BsEfeFcpoa1 e+MW/lw0VetTPPHQ15HYKYP2WYohHxzDiC+QUwE7UZVBlp9cXIpwHuDzSibc5RG3z0n/j2SQCx0D k5FMAUErAgMBAAGjggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5 BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggr BgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9v dENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQU8CHpSXdzn4WuGDvoUnAU Bu1C7sowHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEB ADrCGyv+Y967YbS5R6j8fAWxJiAiUZvIPfn1xVgesF6jspwCQY8xGn/MG04d+Jh97I8I/Xfx29JE EFq2rQmw4PxiO9RiDZ7xoDxNd4rrRDR7jrtOKQP8J+o+ah0vSOP62hnD/zPS7NRMtIyVS2G277KA L5fIR62ngr984fmJghDv0bsjGAmeu3EP0xhUsDJT61IoAGoKBnxBPAeg3WXsdSm4Gn7btyvakeyF tYebr2KmOBSa28PRqGSDur56aZhJoM2eMzc6prmvGwwtAzRsc5t2OsKRuHWV6O3anP2K27jGZR2b i1VX1NQUvIbpVNTuwjm+XcZtsa/AAJF9KGkEseAwggZeMIIFRqADAgECAhAOBcSAioTLk3iEOCnT FJ4lMA0GCSqGSIb3DQEBCwUAMGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5k MRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBl cnNvbmFsIENBIDMwHhcNMTgwNTI5MDAwMDAwWhcNMjEwNTI5MTIwMDAwWjCBjTELMAkGA1UEBhMC RlIxFTATBgNVBAcTDFJvY3F1ZW5jb3VydDFJMEcGA1UEChNASW5zdGl0dXQgTmF0aW9uYWwgZGUg UmVjaGVyY2hlIGVuIEluZm9ybWF0aXF1ZSBldCBlbiBBdXRvbWF0aXF1ZTEcMBoGA1UEAxMTQmVu amFtaW4gQkVVUkRPVUNIRTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANrsbYjccHUi gIc0gRS98dZ7UWPChTEDITyXfXST6Q4/VxfELVLb8O//z/S1UaHMRJR0KEUvzGOQqolsn1bS7SOv f0aQwIV1paBOj9B1X9ID8iGazy9P4jRqSW+cQM49qDrXSkfjOfeHo/BhSD+b2T6DVwEArg/sdvfs Zv5h6YwEZEhymJCiYASH3SIANYdF61TteDC4G+QMbK3I+xtixD1AgBC2sVtTGh+zTWMVA89zNJdw 3eq34jvodmM7kz0RmNHDnRqhPyl2BEKxTrzBJmUoa4uSkpsJAcWqwG4PTnb4E1VIz+xk4smgVx0U 1t3NhmQffO6rbCGAvUnctL6QK9ss5MoxDuDMoIdy0ZJyvUcfUkV/iELWVDRsvd1neBz5dmQL7RSt ug/2qcQgqWeiCVtxauLALj3W4QPvRS2qnlMBtznuFulnn0R7CMt8ZRmvYOgqcDBRKeJhiuuFoIYr xRTtTr6X0HiMNtVSY90wWZAaRXMsS1YRhtxj2xlmJs5u+gd7utDf7RvcNlFzsJSsPQya2VgEPv9z oT+S3jT/YRUGl1P3ZnGr0TqbvDSqUGr41N5fniSbb8Dozr23kfCimxMQNjQ7H57P4p+kKMpFny8D vJauxVnev0w9Bj3cxHbe+FIsMEhoBy7+71FNFnHCpPeRNRlpEn8G/Sl+ggdQJRMVAgMBAAGjggHb MIIB1zAfBgNVHSMEGDAWgBTwIelJd3Ofha4YO+hScBQG7ULuyjAdBgNVHQ4EFgQUAjRpJb6H5V8n D+QmU8ig6EyolewwDAYDVR0TAQH/BAIwADAnBgNVHREEIDAegRxiZW5qYW1pbi5iZXVyZG91Y2hl QGlucmlhLmZyMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw QwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2lj ZXJ0LmNvbS9DUFMwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL1RF UkVOQVBlcnNvbmFsQ0EzLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL1RFUkVO QVBlcnNvbmFsQ0EzLmNybDBzBggrBgEFBQcBAQRnMGUwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTA9BggrBgEFBQcwAoYxaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1RF UkVOQVBlcnNvbmFsQ0EzLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAqC8HmYBBFsSHs0mxb+5CxQRR SJKCe76YfYVhb6sM4bIT96myi8pQhdnP4MbBSyEq+FlQUIxUDLhbn3YyBKFRJIOrDbVWCFi32DPW YSXO420F0M3O4LMbjJYpC2BdkxmtH5ovTbm8HjvZGHdRruEVe7JKL/o9yc9smFq0cSAzXjLEWugh hzrfYjewI+PLwbHvcJ2c8UULvYN+jULIbj+sIs/2TjhlAzwNOHKHK2J7Y/1cr/9nrTN9BAiU7YcL Pr+UFstvYY9UQx7GE8aRJCkQCq+G37n/Tp07VGe5nVwoqoCyNCajJb4rVZv/0MEqCt3ZPKvSMRXA ivjo9D/3FNqjzTGCBDUwggQxAgEBMH0waTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhv bGxhbmQxEjAQBgNVBAcTCUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJF TkEgUGVyc29uYWwgQ0EgMwIQDgXEgIqEy5N4hDgp0xSeJTANBglghkgBZQMEAgEFAKCCAYkwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwODEzMTQ0NzMyWjAvBgkq hkiG9w0BCQQxIgQgasERu8kRg/OBZCCaq2ZVcbeJvw8B65/6Bg9dmnv6+04wgYwGCSsGAQQBgjcQ BDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwgQ0EgMwIQ DgXEgIqEy5N4hDgp0xSeJTCBjgYLKoZIhvcNAQkQAgsxf6B9MGkxCzAJBgNVBAYTAk5MMRYwFAYD VQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEd MBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMCEA4FxICKhMuTeIQ4KdMUniUwDQYJKoZIhvcN AQEBBQAEggIAUtyQjLltxLZAZUek9Vt0T4gGSscTJZ3m+21s7KSIuJFROrH1kO8ekmixYkMvrwAt hhMddgT6hC7fGdFqA1pc4dmJgdDbKtGSAuFnOsEwz2MeByOjhc//vS88StC5z5O1PIZq0xDL3o/c WlG/792kCkCuguYixEflHaEc2kKKAzFOSfhyJcsq39afqCcxR6pZzigYlyv/TexIWP7zNBXzVvdO q4WXgKguRNO6fGF30o4UflXCtXukc78C2vro3o558Y35hwDO6BqDBv1okKW5t1w/NcDNKQ69X4A4 0ksd8rkQqhcvk/7o2Uw9moBPDsxz883CK7lhQc1A+rfYoy6xV0EkaZFzSdk854QLk8iFd6DUjf/0 J6kzkaqdPXXLvhiZZ5WNPPedMmc7DE4f/dr1N5l59CWMiKz3SPPxyz2dVaaDiIhQSBnbleekoZ1V nXp8w48oSrFHOH83GHFmrE4dRFPjGCxzNw9rfb1RX7PocuKf1EYzYNZLJ1LGTH2CaTP9mB1n3sCZ HUWNv16no5i2fVXIofGlYu5P1VK9JQy9PChmpl9dqtnv+bSXUv0tfOSSm8vfsuEZYlPI4350iXuk wk1Ezjknwp1o8gKH6kvjf7FLDNmObzyVjrm7mDHZ/NN/EhLrfaWXp2GZKKALa9r16nq8pVtghroA Df6p9PHxC90AAAAAAAA= --Apple-Mail=_9F22962F-AF41-441D-85AB-9D1CD7EC70F1-- From psla@google.com Mon Aug 12 15:36:07 2019 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 28C981208D9 for ; Mon, 12 Aug 2019 15:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 IPxvCZJDukkv for ; Mon, 12 Aug 2019 15:36:05 -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 147B9120AD0 for ; Mon, 12 Aug 2019 12:07:10 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id u34so4649336qte.2 for ; Mon, 12 Aug 2019 12:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=BrWBTBrDMB0igMb2FDXu0PHjGxQmXxHXJJPYl3wgfGY=; b=QoA/Eew49ENcZnQ5PCC42W4wUIGUtJ5SBg/vejgCbTa+VGmYnEVJqxP5tPOLZ//+OS 5rDO+3wAKeYpr6nN2KKIvfwdMoTNdz6MbvxKycrCaAAZ+p4W88JFJdZvjlEBsqrz55Ip Cvzc7wo/AvM1cMc/NP9dCOXuCHor3yfwiTbnDBzCoZA8i5a0CwcxkpmOSRSj/XPCDwLt kQ24wcD3euuMUMcuY82pIhgl7uSYgQ3Y8klIKTJoe1KOF4MJWzDqdCVvsEZwsPb2t1CV xLC6TmO7RRmMJPehGRjQsgy0rrwUGDvZjwfB/9+pOqL/j/6kulb/LBGYcwOTktXpzCn9 1Myw== 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:cc; bh=BrWBTBrDMB0igMb2FDXu0PHjGxQmXxHXJJPYl3wgfGY=; b=jCejbbC5ipk/6bDjtDcyIDo4V3OMwewmYdHYkNbjDAmtmtkE79aqaesHswE2MITSVT 72+aZXIsrIqYc3Ugu4fnk3+xwr/u4i0ngF0ntqu0fkeZEtT5HteacTOUq9cV+6ThCSr6 YqcC0Y/tjjIFHZWTR27ia79CdDR6z7I9Tol0Z15itG63rPR1O1J602THAR1jq8P/mWCe aFVwT4kyNAioKggxOVUCRiMsDuKDBaFpSrRpUB2ZqsIuq05OSW23bF/gkaJPXra6qgTS SMDq9z5YG0015XwyEtj7QaZ2ZvLz6ymb+/3akShegc+MsFNlyc515eqcA0tNDEPTKavh GFqg== X-Gm-Message-State: APjAAAWx1HFgg6hNRVlN3vV/hodzUhuRWjkLawXyWlxD1+BGeWPJNXdT clb78RrF+cu288EmHir8/xnacNp466y8eTPqtjFR1vNeS7h2yg== X-Google-Smtp-Source: APXvYqwSPHcmAV+U5emTfO5OIlHuFwBkJCXy5nZr0RSdAYmLjfNadLCNrBT3467luUyqRgRDFCNl+IVV80ZOT29Ch7Q= X-Received: by 2002:ac8:41d1:: with SMTP id o17mr28088565qtm.383.1565636828600; Mon, 12 Aug 2019 12:07:08 -0700 (PDT) MIME-Version: 1.0 From: Peter Slatala Date: Mon, 12 Aug 2019 12:06:42 -0700 Message-ID: To: mls@ietf.org Cc: Benjamin Beurdouche Content-Type: multipart/alternative; boundary="00000000000004ceab058ff03ba9" Archived-At: X-Mailman-Approved-At: Tue, 13 Aug 2019 08:29:16 -0700 Subject: [MLS] AEAD data in messages 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, 12 Aug 2019 23:01:00 -0000 --00000000000004ceab058ff03ba9 Content-Type: text/plain; charset="UTF-8" Hello! I was wondering if you considered allowing additional plaintext but authenticated data in MLS messages. While I can't think of immediate, compelling use cases right now, I am wondering if such extensibility wouldn't be desired. For example, in encrypted video calls, resolution, framerate, or audio volume can be put in plaintext so that the selective forwarding unit can decide which streams to forward to the group members (and the recipient also uses this data). Here are some use-cases for MLS that I can think of: * sending a 'sending device identifier' in case if delivery service can't differentiate different user devices from each other. * sending 'message type' that server can act upon. For example, delivery report sent by the recipient to the sender, which also acts as an ACK to the server that the message was persisted. * authenticating message id (but make it visible to server to avoid redelivery), * other use cases that I can't think of right now. Have you considered supporting AEAD, or is it already supported and I missed it? Thanks, Peter --00000000000004ceab058ff03ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!
I was wondering if you considered allowing addi= tional plaintext but authenticated data in MLS messages.

While I can't think of immediate, compelling use cases right now= , I am wondering if such extensibility wouldn't be desired. For example= , in encrypted video calls, resolution, framerate, or audio volume can be p= ut in plaintext so that the selective forwarding unit can decide which stre= ams to forward to the group members (and the recipient also uses this data)= .

Here are some use-cases for MLS that I can think= of:
* sending a 'sending device identifier' in case if d= elivery service can't differentiate different user devices from each ot= her.=C2=A0
* sending 'message type' that serve= r can act upon. For example, delivery report sent by the recipient=C2=A0to = the sender, which also acts as an ACK to the server that the message was pe= rsisted.
* authenticating message id (but make it visible to serv= er to avoid redelivery),
* other use cases that I can't t= hink of right now.

Have you considered supporting = AEAD, or is it already supported and I missed it?

= Thanks,
Peter
--00000000000004ceab058ff03ba9-- From nobody Tue Aug 13 08:29:27 2019 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 609101201E4 for ; Tue, 13 Aug 2019 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 JcHUAEFLhSLz for ; Tue, 13 Aug 2019 07:13:51 -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 6D6F61201DE for ; Tue, 13 Aug 2019 07:13:51 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id d17so27501650qtj.8 for ; Tue, 13 Aug 2019 07:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S1OftiizSMqrS3USoEHqWw56yKZN9oFc9qactPS0WGU=; b=YabdANvKuj197D2BbHjPu6zoxZVCwxVytm8/6CQR9W5NhjUuahee/oYGu4P4r+5yLZ 1x9dwVef3SJorrq3otIPvfqfI2uWhLRtPXNfkLJsC5SXSV3aRsU06H1481RjRVjftF0H PFUMgWKsKLMScb9WlR+G7SmOWPLA0+SkBX6NDLeIUgnFOUppN6jFdVIY6iYqv+Xe4pbf 4lr8QHeWkjXRHaWHBPt6O5tVIy/Ah3AYkoXiXzLpgf3JoHNOrCpRFkHQDvj2LIBPZflv ExspL3bX5dEJc3kingUNjGgbCi8cB9B9e9Y2TFVwS9dA4+3hIZGTtnuC0ad6Jhxx5WFD a/+g== 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=S1OftiizSMqrS3USoEHqWw56yKZN9oFc9qactPS0WGU=; b=psqBq6UIOohxYvmkcmcVYvlMBQg8SkJscAbPdjkb6u7YnGvDoSChY7WM2PI4m/gwvk boUEdAWj3uKESp2X17LiVaeBMF78PaZcPbeIUJyTITmudlHNIlQqaR0tIeaw+kGds6fU TCZDiW0iPmQUmZO7vonlNRoRxGrE3umwMx9PSqOVcceQgJ1uQuon0k5fKSL22upv9NtO TFB34NgVFUxXC7fhWmiWAb2tAHSoN4RSSzWMojTGCRB3KZI0XI+F5FaLA8TzcjMkIwkb V97ModHpwOk85Xzrw57JTczolTk60mwkNf4SzX4CboNcFHUnH1T5Os2f4zvyQzS3V+vi jYjQ== X-Gm-Message-State: APjAAAUv79jablDcwN19ZB/U0Z2EnHAAWzji464nJvavUOaqddiT2C4l /LBrdZN3u/VEMDGeARgUiVxzeEMQrvPvtVQ7n75CN46VCoQ= X-Google-Smtp-Source: APXvYqzJd5VNGyjvEzcGyUiLe4qiar7zZmrpCc7di/H6SIWNifMLx2ceq3jPziT0oouRsIF8eMKvP+k6G8uCHh9toLA= X-Received: by 2002:ac8:41d1:: with SMTP id o17mr31084888qtm.383.1565705630093; Tue, 13 Aug 2019 07:13:50 -0700 (PDT) MIME-Version: 1.0 References: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> In-Reply-To: <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> From: Peter Slatala Date: Tue, 13 Aug 2019 07:13:24 -0700 Message-ID: To: Jeff Burdges Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000e7f3cb0590003fd6" Archived-At: X-Mailman-Approved-At: Tue, 13 Aug 2019 08:29:16 -0700 Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 14:13:53 -0000 --000000000000e7f3cb0590003fd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges wrote: > > > > On 13 Aug 2019, at 01:15, Peter Slatala 40google.com@dmarc.ietf.org> wrote: > > I was wondering if you considered allowing additional plaintext but > authenticated data in MLS messages. > > It=E2=80=99d be outside the header encryption, making the AEAD would be t= he header > encryption? > > How would the delivery service authenticate it? > Delivery service is often TLS encrypted so client-server connection should be secure. > > Here are some use-cases for MLS that I can think of: > > * sending a 'sending device identifier' in case if delivery service > can't differentiate different user devices from each other. > > I=E2=80=99d hope the delivery service does not care too much to which dev= ice it > communicates. > > * sending 'message type' that server can act upon. For example, deliver= y > report sent by the recipient to the sender, which also acts as an ACK to > the server that the message was persisted. > > > * authenticating message id (but make it visible to server to avoid > redelivery), > > ACKs and message ids should often be done fully encrypted, but yeah makin= g > one ACK or message id notify both the delivery service and the end user > makes sense in some use cases. > > Jeff > > > --000000000000e7f3cb0590003fd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 12, 2019 at 11:24 PM Jeff= Burdges <burdges@gnunet.org&g= t; wrote:


> On 13 Aug 2019, at 01:15, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ie= tf.org> wrote:
> I was wondering if you considered allowing additional plaintext but au= thenticated data in MLS messages.

It=E2=80=99d be outside the header encryption, making the AEAD would be the= header encryption?

How would the delivery service authenticate it?
Delive= ry service is often TLS encrypted so client-server connection should be sec= ure.


> Here are some use-cases for MLS that I can think of:
> * sending a 'sending device identifier' in case if delivery se= rvice can't differentiate different user devices from each other.

I=E2=80=99d hope the delivery service does not care too much to which devic= e it communicates.=C2=A0

> * sending 'message type' that server can act upon. For example= , delivery report sent by the recipient to the sender, which also acts as a= n ACK to the server that the message was persisted.

> * authenticating message id (but make it visible to server to avoid re= delivery),

ACKs and message ids should often be done fully encrypted, but yeah making = one ACK or message id notify both the delivery service and the end user mak= es sense in some use cases.

Jeff


--000000000000e7f3cb0590003fd6-- From nobody Tue Aug 13 15:03:41 2019 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 DE6E01208C2 for ; Tue, 13 Aug 2019 15:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=callas.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 Rk3CfdaK4Lpg for ; Tue, 13 Aug 2019 15:03:37 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 601511208E6 for ; Tue, 13 Aug 2019 15:03:37 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id gn20so576798plb.2 for ; Tue, 13 Aug 2019 15:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QY/06HHj1MnLVpwdyyICxSlwuOCXSyvDH28p1KmSdTY=; b=HcIu3fARartHMMpWQoMN58NjeiCaSxJAJuJ/QNawmpEO6Nn6oiHfiJed1SWI3xox8i PXVo6eCEkH5VjdZqKLhwfIqQmc/lDUH/6Qg/OpGakiEQxdExJVLteodHdmZ/6GvxMRbL 4ggyvc7ihOiz1VxCaUGt4+h0nnUf1zSS91xC+9yqqvhciezsx9H6Cyx1NcGtu7LQMD0S Rfsoe0GKZzePsgIV6Wsvk+gL2V4efx7ZOpZ2QO2kG3dPot3Fxu6uC+Cg6gkLsMsiT07a 4OcuR7Up+LUFfRaoMrpJrCTCOzT66IzXYLYn+JrKMKijRCmOxeF7myeLqjfkCuNc8Ara nmpA== 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=QY/06HHj1MnLVpwdyyICxSlwuOCXSyvDH28p1KmSdTY=; b=OJ82dQOIi6ivzufaXzYEoDxlXyqxEHheISQXnthMvgMqJLFu2oV0Re/n+CbSBp+mdY h/rtIElWQlabhxV0vtQaoRrdw2yOuwkeWZesoLzxqfxEMjea/PaIJmEt5cIVryOrJ5KD Y/i1pheK9nUtvjLAqfHnGroicYzgyc+3HXkgE/bn2JpA48vvp+Tp88VMZrryzydPHFLq 0F1eFM5udafr4luYaMBSuhffMswfGaocQiLF9OfYzzPz9wlPQ5M9ZEzEMCTCTkbnYKnN nmtlkXcAg7LzrJeXd042xEu7TpFHIxSEz9MASbErONUF542NzAN46QWvaZrTcbHXTk/b vOkg== X-Gm-Message-State: APjAAAUwNj8JPzF4ijkz19WbhXYOS6SQWrIdJVCx8suTvPVrcbAErzX6 l7yBjN0pr4D6gm4gohSSPOLR4A== X-Google-Smtp-Source: APXvYqy+miq2vyzxf17tFkN7R6N2KA1JOMBHabkfHSUFz1z5fD20edG/tLyKaCdASDPB/N9OGF2BPw== X-Received: by 2002:a17:902:20ec:: with SMTP id v41mr19108264plg.117.1565733816712; Tue, 13 Aug 2019 15:03:36 -0700 (PDT) Received: from [10.125.12.150] (67-207-120-150.static.wiline.com. [67.207.120.150]) by smtp.gmail.com with ESMTPSA id m7sm3833124pfb.99.2019.08.13.15.03.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 15:03:35 -0700 (PDT) From: Jon Callas Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1AFFAA80-6D4F-40B8-AB52-06575D622D67" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 13 Aug 2019 15:03:34 -0700 In-Reply-To: Cc: Jon Callas , mls@ietf.org, Benjamin Beurdouche To: Peter Slatala References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 13 Aug 2019 22:03:40 -0000 --Apple-Mail=_1AFFAA80-6D4F-40B8-AB52-06575D622D67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 12, 2019, at 4:15 PM, Peter Slatala = wrote: >=20 > Hello! > I was wondering if you considered allowing additional plaintext but = authenticated data in MLS messages. I have a small raised eyebrow about this. Similar to rlb's comment, it's = not hard. My primary concern is that any AAD in the message is ripe for putting in = things that are side-channel or traffic analysis leaks. I have a = secondary concern that if one uses this to talk to the delivery service, = it's unauthenticated from the service's viewpoint, and consequently = creates an opportunity for an attacker to fuzz the delivery service. = Moreover that attacker could be a legitimate user of the service. I note that you said, "Delivery service is often TLS encrypted so = client-server connection should be secure" in follow-on discussion, but = that's in my opinion a reason *not* to have this feature. That's either = a layering violation or you could achieve the same effect by just = sending an unauthenticated message to the service that is protected by = TLS. By putting a server message in the AAD of an AEAD message,=20 >=20 > While I can't think of immediate, compelling use cases right now, That strikes me as a reason *not* to do it, but again, along with rlb, = I'm willing to look at a proposal. Note that my concerns here suggest = things you should address in that proposal. > I am wondering if such extensibility wouldn't be desired. For example, = in encrypted video calls, resolution, framerate, or audio volume can be = put in plaintext so that the selective forwarding unit can decide which = streams to forward to the group members (and the recipient also uses = this data).. Here's a sample attack. In this, Alice and Bob are communicating over = the service and Harry the Hacker has compromised the router nearest = Alice and thus can see or modify all messages. Harry modifies one of = Alice's messages, changing the volume field to maximum volume. The = server acts on the changed volume, but Bob drops the message, because = the MAC fails. If the message gets retransmitted, Harry doesn't change = the volume. Alice and Bob likely see the volume of the call going to max = for no readily understandable reason. As you note, using TLS is a quick = mitigation. Another attack uses Gary the Griefer instead of Harry. Gary is an = authenticated used of the service and is in a session with Alice and = Bob. Gary does exactly what Harry did above -- send a message that the = server will act on, setting the volume to max -- but knows that this = message will dropped by Alice and Bob. I believe that if someone wants to send a command to the service, then = it shouldn't be piggybacked inside the normal messages, but that there = needs to be a separate edge-to-service key and command set. >=20 > Here are some use-cases for MLS that I can think of: > * sending a 'sending device identifier' in case if delivery service = can't differentiate different user devices from each other.=20 This is a traffic-analysis data leak. > * sending 'message type' that server can act upon. For example, = delivery report sent by the recipient to the sender, which also acts as = an ACK to the server that the message was persisted. Again, this should be done under the aegis of an edge-to-service key. > * authenticating message id (but make it visible to server to avoid = redelivery), That's also an information leak. > * other use cases that I can't think of right now. >=20 I have one more that's perhaps at least mildly paranoid and perhaps not = entirely fair. * sending information needed for "exceptional access" such as the GCHQ = Ghost User proposal. This could put in trap/trace data, copies of the = messages encrypted to access keys, etc.=20 That's not fair because if we presume government-compelled software = mods, they could mandate a lot of things. However, this provides a = mechanism that could enable a single gimmicked client to undermine the = security of the whole system transparently. This would really be true of = the plaintext AAD was typically ignored by the client. Preventing this = is thorny, because it would require defining what the syntax of the AAD = is, and mandating some dramatic failure if unknown AAD is present. Despite this, I'd love to see a proposal. It could be useful. It could = also be a major flaw, and this is why I would like to see a real use = case as well as mitigations against abuse in the proposal. Jon= --Apple-Mail=_1AFFAA80-6D4F-40B8-AB52-06575D622D67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 12, 2019, at 4:15 PM, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ietf.org> = wrote:

Hello!
I was wondering if you = considered allowing additional plaintext but authenticated data in MLS = messages.

I = have a small raised eyebrow about this. Similar to rlb's comment, it's = not hard.

My primary concern is that = any AAD in the message is ripe for putting in things that are = side-channel or traffic analysis leaks. I have a secondary concern that = if one uses this to talk to the delivery service, it's unauthenticated = from the service's viewpoint, and consequently creates an opportunity = for an attacker to fuzz the delivery service. Moreover that attacker = could be a legitimate user of the service.

I note that you said, "Delivery service is often TLS encrypted so = client-server connection should be secure" in follow-on discussion, = but that's in my opinion a reason *not* to have this feature. That's = either a layering violation or you could achieve the same effect by just = sending an unauthenticated message to the service that is protected = by TLS. By putting a server message in the AAD of an AEAD = message, 


While I can't think of = immediate, compelling use cases right now, =

That = strikes me as a reason *not* to do it, but again, along with rlb, I'm = willing to look at a proposal. Note that my concerns here suggest things = you should address in that proposal.

I am wondering if such extensibility wouldn't be desired. For = example, in encrypted video calls, resolution, framerate, or audio = volume can be put in plaintext so that the selective forwarding unit can = decide which streams to forward to the group members (and the recipient = also uses this data)..

Here's a sample attack. In this, Alice and Bob are = communicating over the service and Harry the Hacker has compromised the = router nearest Alice and thus can see or modify all messages. Harry = modifies one of Alice's messages, changing the volume field to maximum = volume. The server acts on the changed volume, but Bob drops the = message, because the MAC fails. If the message gets retransmitted, Harry = doesn't change the volume. Alice and Bob likely see the volume of the = call going to max for no readily understandable reason. As you note, = using TLS is a quick mitigation.

Another attack uses Gary the Griefer instead of = Harry. Gary is an authenticated used of the service and is in a session = with Alice and Bob. Gary does exactly what Harry did above -- send a = message that the server will act on, setting the volume to max -- but = knows that this message will dropped by Alice and Bob.

I believe that if someone wants to send a command = to the service, then it shouldn't be piggybacked inside the normal = messages, but that there needs to be a separate edge-to-service key and = command set.


Here are some use-cases for MLS that I = can think of:
* sending a 'sending device = identifier' in case if delivery service can't differentiate different = user devices from each = other. 

This is a traffic-analysis data leak.

* sending = 'message type' that server can act upon. For example, delivery report = sent by the recipient to the sender, which also acts as an ACK to = the server that the message was = persisted.

Again, this should be done under the aegis of an = edge-to-service key.

* = authenticating message id (but make it visible to server to avoid = redelivery),

That's also an information leak.

* other use cases that I can't = think of right now.


I = have one more that's perhaps at least mildly paranoid and perhaps not = entirely fair.

* sending information = needed for "exceptional access" such as the GCHQ Ghost User proposal. = This could put in trap/trace data, copies of the messages encrypted to = access keys, etc. 

That's not fair = because if we presume government-compelled software mods, they could = mandate a lot of things. However, this provides a mechanism that could = enable a single gimmicked client to undermine the security of the whole = system transparently. This would really be true of the plaintext AAD was = typically ignored by the client. Preventing this is thorny, because it = would require defining what the syntax of the AAD is, and mandating some = dramatic failure if unknown AAD is present.

Despite this, I'd love to see a = proposal. It could be useful. It could also be a major flaw, and this is = why I would like to see a real use case as well as mitigations against = abuse in the proposal.

= Jon
= --Apple-Mail=_1AFFAA80-6D4F-40B8-AB52-06575D622D67-- From nobody Thu Aug 15 09:04:37 2019 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 25EA81200DB for ; Thu, 15 Aug 2019 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17 X-Spam-Level: X-Spam-Status: No, score=-17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Og-Jcp41PeSf for ; Thu, 15 Aug 2019 09:04:33 -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 BF630120105 for ; Thu, 15 Aug 2019 09:04:24 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id p13so2185682qkg.13 for ; Thu, 15 Aug 2019 09:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X+g568yaxGEsk2/ZZqxb/N8uqZuEa4Mfhv/gEGDT4t0=; b=aXQCj5t8luuOfiIFFW7gsPtk8qEZSr7jsp7mE3ZYqfRs/4IhSl91OHeNOvPPzzfUtg 2H32uOB5FVJn5ZaoYMDDF1lmhxAZobxBhMI7M/EWWC5D1fMTg8QgjnIpLmEa1hDwQQdr F5GXNeifutjmX0xCHS9ySTc3V1rN4LHyTsMz8WhTEUgEPHvA310hVeRB8XBLjWlXOuy7 HVGrLwL8FPEv4caJsviO9Mjo2COh15vIiffEti/52U3CnwTRea+z+ju+lfyAZQhc6BDV VtZNOSTtSSaiksFihcEDtW25eCLJQJtaq3ZiUho4LnEN8qTOXiifHV3wOl+Xe3w3VrEC 4U6A== 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=X+g568yaxGEsk2/ZZqxb/N8uqZuEa4Mfhv/gEGDT4t0=; b=GzhEehU8/QQpK0AgtmHpIikYFpOUG+/UY5tyQCKGEm28KkIS5tyQCYWqgLy7w29IoM dCl+9YHzhPzm3JdEYAG1k/tk6wVe4h+XTuj1ysQqRqgBX0z9veDl9jajJTIQSjijrkr7 KW8oZ5eNFINXeSK8F0kBHtjq9Hka5Qrou9Lr/KqxwgA5r93iFJpPXxpkgVTQ+6s75An0 5da+fhyeI6+fhqdjwzxe7uxYg53xbs9uSIPRs/1MWsLWGg2oWeszAPiFVrtqOL4OOvKP +XcITfuPEZgxU2LIG7Mv+7MgXM/Dyrf+nWVUZh22+RPvMRIyANTGQVllr4jaF5UdTJJF bXQA== X-Gm-Message-State: APjAAAVtaItRKMfz0EjkA58qesXkiqoFp3abdUiJs+xnTfPhX6nR/W2y Qojv8Y/++R8QbGDYndPdti7dI5cYMYrKyzdH9KneMrL1BE9bbw== X-Google-Smtp-Source: APXvYqzIfZwT9jqhPOVXKhYVKHsOZwOv5XCzU4d+VtG6lwmfnAZP7WyXS0j4NIYYSRsesaDk+orEdGJS/J8MTdzB1u8= X-Received: by 2002:ae9:ed94:: with SMTP id c142mr4760791qkg.70.1565885063579; Thu, 15 Aug 2019 09:04:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Slatala Date: Thu, 15 Aug 2019 09:03:57 -0700 Message-ID: To: Jon Callas Cc: mls@ietf.org, Benjamin Beurdouche Content-Type: multipart/alternative; boundary="000000000000f9a5d205902a0655" Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 15 Aug 2019 16:04:36 -0000 --000000000000f9a5d205902a0655 Content-Type: text/plain; charset="UTF-8" Thanks Jon! This is a lot of good feedback. As you mentioned, a lot of this AAD can be addressed by a separate edge-to-service key; what we optimize for here is message overhead. Overhead is less of a concern for messaging (unlike for real-time media), so it may be fine to have TLS + edge-to-service + encrypted message itself. The quirk is that some of the metadata would then have to be repeated in both delivery service encrypted message & e2ee encrypted message, which is what I wanted to optimize. By putting the info in AAD & using TLS we essentially save overhead (from duplicating data, and from extra encryption overhead to the server). I'll think about it more and see if I can come up with a reasonable proposal, but I am afraid I won't be able to come up with a solution that will address all of your concerns. > Actually the header encryption exists to protect MLS metadata from the delivery service, so ideally most systems should deploy it. When you say header encryption, what exactly do you mean? (I don't believe draft mentions this). Peter On Tue, Aug 13, 2019 at 3:03 PM Jon Callas wrote: > > > On Aug 12, 2019, at 4:15 PM, Peter Slatala < > psla=2Bmls=40google.com@dmarc.ietf.org> wrote: > > Hello! > I was wondering if you considered allowing additional plaintext but > authenticated data in MLS messages. > > > I have a small raised eyebrow about this. Similar to rlb's comment, it's > not hard. > > My primary concern is that any AAD in the message is ripe for putting in > things that are side-channel or traffic analysis leaks. I have a secondary > concern that if one uses this to talk to the delivery service, it's > unauthenticated from the service's viewpoint, and consequently creates an > opportunity for an attacker to fuzz the delivery service. Moreover that > attacker could be a legitimate user of the service. > > I note that you said, "Delivery service is often TLS encrypted so > client-server connection should be secure" in follow-on discussion, but > that's in my opinion a reason *not* to have this feature. That's either a > layering violation or you could achieve the same effect by just sending > an unauthenticated message to the service that is protected by TLS. By > putting a server message in the AAD of an AEAD message, > > > While I can't think of immediate, compelling use cases right now, > > > That strikes me as a reason *not* to do it, but again, along with rlb, I'm > willing to look at a proposal. Note that my concerns here suggest things > you should address in that proposal. > > I am wondering if such extensibility wouldn't be desired. For example, in > encrypted video calls, resolution, framerate, or audio volume can be put in > plaintext so that the selective forwarding unit can decide which streams to > forward to the group members (and the recipient also uses this data).. > > > Here's a sample attack. In this, Alice and Bob are communicating over the > service and Harry the Hacker has compromised the router nearest Alice and > thus can see or modify all messages. Harry modifies one of Alice's > messages, changing the volume field to maximum volume. The server acts on > the changed volume, but Bob drops the message, because the MAC fails. If > the message gets retransmitted, Harry doesn't change the volume. Alice and > Bob likely see the volume of the call going to max for no readily > understandable reason. As you note, using TLS is a quick mitigation. > > Another attack uses Gary the Griefer instead of Harry. Gary is an > authenticated used of the service and is in a session with Alice and Bob. > Gary does exactly what Harry did above -- send a message that the server > will act on, setting the volume to max -- but knows that this message will > dropped by Alice and Bob. > > I believe that if someone wants to send a command to the service, then it > shouldn't be piggybacked inside the normal messages, but that there needs > to be a separate edge-to-service key and command set. > > > Here are some use-cases for MLS that I can think of: > * sending a 'sending device identifier' in case if delivery service can't > differentiate different user devices from each other. > > > This is a traffic-analysis data leak. > > * sending 'message type' that server can act upon. For example, delivery > report sent by the recipient to the sender, which also acts as an ACK to > the server that the message was persisted. > > > Again, this should be done under the aegis of an edge-to-service key. > > * authenticating message id (but make it visible to server to avoid > redelivery), > > > That's also an information leak. > > * other use cases that I can't think of right now. > > > I have one more that's perhaps at least mildly paranoid and perhaps not > entirely fair. > > * sending information needed for "exceptional access" such as the GCHQ > Ghost User proposal. This could put in trap/trace data, copies of the > messages encrypted to access keys, etc. > > That's not fair because if we presume government-compelled software mods, > they could mandate a lot of things. However, this provides a mechanism that > could enable a single gimmicked client to undermine the security of the > whole system transparently. This would really be true of the plaintext AAD > was typically ignored by the client. Preventing this is thorny, because it > would require defining what the syntax of the AAD is, and mandating some > dramatic failure if unknown AAD is present. > > Despite this, I'd love to see a proposal. It could be useful. It could > also be a major flaw, and this is why I would like to see a real use case > as well as mitigations against abuse in the proposal. > > Jon > --000000000000f9a5d205902a0655 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jon! This is a lot of good feedbac= k. As you mentioned, a lot of this AAD can be addressed by a separate edge-= to-service key; what we optimize for here is message overhead. Overhead is = less of a concern for messaging (unlike for real-time media), so it may be = fine to have TLS=C2=A0+= edge-to-service=C2=A0+ encrypted message itself. The quirk is that som= e of the metadata would then have to be repeated in both delivery service e= ncrypted message & e2ee encrypted message, which is what I wanted to op= timize. By putting the info in AAD & using TLS we essentially save over= head (from duplicating data, and from extra encryption overhead to the serv= er).

I'll think about it more and = see if I can come up with a reasonable proposal, but I am afraid I won'= t be able to come up with a solution that will address all of your concerns= .

> Actually the header encryption exists to pr= otect=C2=A0MLS=C2=A0metadata from the deliv= ery service, so ideally most systems should deploy it.
When you s= ay header encryption, what exactly do you mean? (I don't believe draft = mentions this).

Peter

On Tue, Aug 13, 2019 at 3:03 = PM Jon Callas <jon@c= allas.org> wrote:


On Aug 12, 2019= , at 4:15 PM, Peter Slatala <psla=3D2Bmls=3D40google.com@dmarc.ietf= .org> wrote:

Hello!
I was wonderi= ng if you considered allowing additional plaintext but authenticated data i= n MLS messages.

I have a = small raised eyebrow about this. Similar to rlb's comment, it's not= hard.

My primary concern is that any AAD in the m= essage is ripe for putting in things that are side-channel or traffic analy= sis leaks. I have a secondary concern that if one uses this to talk to the = delivery service, it's unauthenticated from the service's viewpoint= , and consequently creates an opportunity for an attacker to fuzz the deliv= ery service. Moreover that attacker could be a legitimate user of the servi= ce.

I note that you said, "Delivery service is often TLS encrypte= d so client-server connection should be secure" in=C2=A0follow-on disc= ussion, but that's in my opinion a reason *not* to have this feature. T= hat's either a layering violation or you could achieve the same effect = by just sending an=C2=A0unauthenticated message to the service that is prot= ected by TLS. By putting a server message in the AAD of an AEAD message,=C2= =A0

=

While I can't think of immediate, compelling use ca= ses right now,

That stri= kes me as a reason *not* to do it, but again, along with rlb, I'm willi= ng to look at a proposal. Note that my concerns here suggest things you sho= uld address in that proposal.

I am wondering if such extensibility wouldn't be desir= ed. For example, in encrypted video calls, resolution, framerate, or audio = volume can be put in plaintext so that the selective forwarding unit can de= cide which streams to forward to the group members (and the recipient also = uses this data)..

Here= 9;s a sample attack. In this, Alice and Bob are communicating over the serv= ice and Harry the Hacker has compromised the router nearest Alice and thus = can see or modify all messages. Harry modifies one of Alice's messages,= changing the volume field to maximum volume. The server acts on the change= d volume, but Bob drops the message, because the MAC fails. If the message = gets retransmitted, Harry doesn't change the volume. Alice and Bob like= ly see the volume of the call going to max for no readily understandable re= ason. As you note, using TLS is a quick mitigation.

Another attack uses Gary the Griefer instead of Harry. Gary is an authent= icated used of the service and is in a session with Alice and Bob. Gary doe= s exactly what Harry did above -- send a message that the server will act o= n, setting the volume to max -- but knows that this message will dropped by= Alice and Bob.

I believe that if someone wants to= send a command to the service, then it shouldn't be piggybacked inside= the normal messages, but that there needs to be a separate edge-to-service= key and command set.


Here are some use-cases for MLS that I can think of= :
* sending a 'sending device identifier' in case if deli= very service can't differentiate different user devices from each other= .=C2=A0

This is a traffic= -analysis data leak.

* sending 'message type' that server can act upo= n. For example, delivery report sent by the recipient=C2=A0to the sender, w= hich also acts as an ACK to the server that the message was persisted.

Again, this should be done un= der the aegis of an edge-to-service key.

* authenticating message id (but make it visibl= e to server to avoid redelivery),
That's also an information leak.

* other use cases that I can't thi= nk of right now.


I have one more that's perhaps at least mildly paranoid and perhaps n= ot entirely fair.

* sending information needed for= "exceptional access" such as the GCHQ Ghost User proposal. This = could put in trap/trace data, copies of the messages encrypted to access ke= ys, etc.=C2=A0

That's not fair because if we presum= e government-compelled software mods, they could mandate a lot of things. H= owever, this provides a mechanism that could enable a single gimmicked clie= nt to undermine the security of the whole system transparently. This would = really be true of the plaintext AAD was typically ignored by the client. Pr= eventing this is thorny, because it would require defining what the syntax = of the AAD is, and mandating some dramatic failure if unknown AAD is presen= t.

Despite this, I'd love to see a proposal. It coul= d be useful. It could also be a major flaw, and this is why I would like to= see a real use case as well as mitigations against abuse in the proposal.<= /div>

Jon
--000000000000f9a5d205902a0655-- From nobody Fri Aug 16 12:51:45 2019 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 3AB8D120824 for ; Fri, 16 Aug 2019 12:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cloudflare.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 GAiKkqnTwhhY for ; Fri, 16 Aug 2019 12:51:42 -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 4636E1200D6 for ; Fri, 16 Aug 2019 12:51:41 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id v38so7410037qtb.0 for ; Fri, 16 Aug 2019 12:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=5sI3Hoi1po77947wWAKHUgj8ZjUFpTkGdPMyNyBsngU=; b=jHZyG+Gi4zTHKLEpjXbefpjVhOsAwpUDfL5a0tHyDY+ucNqWF5FK3WEAvby9VqHh60 yPvn1gcUSKQepF7REEpbYhXgc6CQUNn6glte+vUeJuwG3ZzzWOQKm9dFf2T8j6bs63kC 3YnLFVBB+szI7Yv5zODztKfY1FvfKfrU15IfE= 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=5sI3Hoi1po77947wWAKHUgj8ZjUFpTkGdPMyNyBsngU=; b=CVjajEMVhPGRn0QY0m1OS7qb1tIcP6DwX0OMrS9CrIIkbU6UodTY+bhz7CuWh4pO5F 7Zbx57ju0zQW+TRlGS7gVDMdKTsDi+DiYACElcABg2ipHhStwIHGTMWY0VGUeb44PFmP F7Dw2jmYirCJ1o++rL3AUsUzq44twZXOrRwrUBtoIABzeC4UZvpbv1Ld7m/aUKAp6Ult FxZHaPqSQBJ6z+fOthnfYAIJm4UaGdKTFYbklbGLT7MTihZxHCuqewyNyn5zBuYhnFwz vl9oeUtinktfNl0ejLJ6mOgTUhfnnXw9GH2KFLUQbSKesLtej3iH6Yb1hBdxFfzshZhZ mM9w== X-Gm-Message-State: APjAAAXatE2Oc5NIadIEoy+dZuWl7ck4ot16ZVsdRxav+hwus0d8HU/2 ms6SKTw/Ty1xkCeQfSZJ4NAFWZPKj0xI8Fpncb3ySJH7OyE= X-Google-Smtp-Source: APXvYqy47M4qYFbsDIz6bIF19zpDrkUZqBPbzVPBzIW1XMmRT9eiFXVvz/UgFPsHmXL1fe+GGEjOtHO/B7Z78sAiSBM= X-Received: by 2002:a0c:8695:: with SMTP id 21mr3120486qvf.166.1565985098992; Fri, 16 Aug 2019 12:51:38 -0700 (PDT) MIME-Version: 1.0 From: Brendan McMillion Date: Fri, 16 Aug 2019 12:51:27 -0700 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000008cc0c805904151fb" Archived-At: Subject: [MLS] ClientInitKey Ambiguity 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, 16 Aug 2019 19:51:44 -0000 --0000000000008cc0c805904151fb Content-Type: text/plain; charset="UTF-8" Hello mls@ The definition of ClientInitKey in the spec currently has it contain several protocol versions, ciphersuites, and public keys. However, ClientInitKey objects are embedded into Init and Add messages, sent to many people, and all of these people must choose the same public key from the ClientInitKey for their ratchet tree. Sending multiple public keys wastes bandwidth and could cause synchronization issues, if different members choose different public keys from the ClientInitKey. In particular, if the same ciphersuite is provided twice, which I think is allowed. The set of supported versions in the ClientInitKey is also an array, but it doesn't seem to have the same 1-to-1 correspondence that the ciphersuite and public key arrays do. Not clearly denoting which ciphersuite corresponds to which protocol version seems like it also causes synchronization issues. If people agree, I'd like to open a PR changing ClientInitKey to contain only one protocol version, selected ciphersuite, and public key. Clients can generate many ClientInitKeys if they wish to support many versions and ciphersuites. --0000000000008cc0c805904151fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello mls@

The definition of= ClientInitKey in the spec currently has it contain several protocol versio= ns, ciphersuites, and public keys. However, ClientInitKey objects are embed= ded into Init and Add messages, sent to many people, and all of these peopl= e must choose the same public key from the ClientInitKey for their ratchet = tree.

Sending multiple public keys wastes bandwidt= h and could cause synchronization issues, if different members choose diffe= rent public keys from the ClientInitKey. In particular, if the same ciphers= uite is provided twice, which I think is allowed.

= The set of supported versions in the ClientInitKey is also an array, but it= doesn't seem to have the same 1-to-1 correspondence that the ciphersui= te and public key arrays do. Not clearly denoting which ciphersuite corresp= onds to which protocol version seems like it also causes synchronization is= sues.

If people agree, I'd like to open a PR c= hanging ClientInitKey to contain only one protocol version, selected cipher= suite, and public key. Clients can generate many ClientInitKeys if they wis= h to support many versions and ciphersuites.
--0000000000008cc0c805904151fb-- From nobody Sat Aug 17 14:37:24 2019 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 42A97120164 for ; Sat, 17 Aug 2019 14:37:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOSqY3wc68mU for ; Sat, 17 Aug 2019 14:37:19 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 BA593120118 for ; Sat, 17 Aug 2019 14:37:19 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id q10so3732416oij.0 for ; Sat, 17 Aug 2019 14:37:19 -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=j4B++2G67chkhTvvpVde+2nbUqlsEbfIidUPJjvTryM=; b=WOT/JC+b3X0jJsBW2ooSZ9vrngEnpAJWjp/DKYmK3FekV2OxifQZ8nmLZW+ccfoZPk FQBfr+ji1qT2nH9q+DxBT0yMqXck37qpP93DGzCGP6CyLKum2pdVBS76T9wa5JJay5rB P8t6PFbgdJEueCA+Lagm2vWkEDPeOhx1TBVXZ8Pvc2Fjn7W5++VZGPR3aLXBSFwpGo3E VPKWtgEJ3jdu9hAeFWzUnSsaFGoQLiFMcP9863tcX5AR7N8YAxWphxwanlVDq3VHgjUC Ic3u4BPgmVPuX0Tat69j2/nqUYHsHqNwhMRrNhKCo/TPl94TWWh9k8vUoD/fJtcaiZ5+ /l0A== 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=j4B++2G67chkhTvvpVde+2nbUqlsEbfIidUPJjvTryM=; b=sNirbo5aevxw0N4zkoksYhRgm01oQYWI5z0WfwvLOBAO4GLlWpd0akioSKyH3IEuXi R9/aGH6oP5Yiu4MVRu4FMxMzsEXpwhXWBjFum+/mrr1MA644e+B6hWHVVXKSi7aH0kOO KlH5R6Xkkv5uRx1FyIWBTOxuaBYQJ0jERINEES5vcJXLhkb35AWmqvs80RxUFNGkXFnw X6wE8BvJIaTtl3C5NKHHlwOrvszdTGEqraXxFLIc8d+nRfsM63jPOdqEdZNoqLavBVSU 7x7CCsSL/2bndAlxpIa2KKHmGHlF1jui9qpsCXKImFp6VRR8B5o/xTeNsJy1qPlxd9EO dQBg== X-Gm-Message-State: APjAAAWET9vuI4ek6UBurXwCWGYR04Xw9VWh9EAs9Jj1h/1TiJ/6gi8C 7ZCTa/dXtSncJV1+uvQcjl3zOcG1/lmRHTZGte5BKg== X-Google-Smtp-Source: APXvYqzYipJQMdspU4ntzajYfEyx6g1Vx+RVwt0c3Zzw/XRljbBLHpXZ/tDMi9MlkM315Th1bx9z82VAycvOzy//yvA= X-Received: by 2002:aca:d08:: with SMTP id 8mr8660844oin.51.1566077838755; Sat, 17 Aug 2019 14:37:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sat, 17 Aug 2019 17:37:07 -0400 Message-ID: To: Brendan McMillion Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="00000000000045200b059056e984" Archived-At: Subject: Re: [MLS] ClientInitKey Ambiguity 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, 17 Aug 2019 21:37:22 -0000 --00000000000045200b059056e984 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brendan, I don=E2=80=99t think there=E2=80=99s an ambiguity here; IIRC, the spec req= uires that public keys match ciphersuites, and that each ciphersuite appear once. So =E2=80=9Cthe public key for the group=E2=80=99s ciphersuite=E2=80=9D should= be well defined. I agree that it=E2=80=99s inefficient, though. The main difference between the current scheme and your proposal is that the full list of supported suites never appears, so the server can downgrade a group to the lowest suite supported by its initial set of clients. Personally, that risk doesn=E2=80=99t seem awful to me, since I don=E2=80= =99t expect a ton of variability in client capabilities, at least in the short run. But it would be a different guarantee than you get out of TLS. What do other folks think? =E2=80=94Richard On Fri, Aug 16, 2019 at 15:51 Brendan McMillion wrote: > Hello mls@ > > The definition of ClientInitKey in the spec currently has it contain > several protocol versions, ciphersuites, and public keys. However, > ClientInitKey objects are embedded into Init and Add messages, sent to ma= ny > people, and all of these people must choose the same public key from the > ClientInitKey for their ratchet tree. > > Sending multiple public keys wastes bandwidth and could cause > synchronization issues, if different members choose different public keys > from the ClientInitKey. In particular, if the same ciphersuite is provide= d > twice, which I think is allowed. > > The set of supported versions in the ClientInitKey is also an array, but > it doesn't seem to have the same 1-to-1 correspondence that the ciphersui= te > and public key arrays do. Not clearly denoting which ciphersuite > corresponds to which protocol version seems like it also causes > synchronization issues. > > If people agree, I'd like to open a PR changing ClientInitKey to contain > only one protocol version, selected ciphersuite, and public key. Clients > can generate many ClientInitKeys if they wish to support many versions an= d > ciphersuites. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000045200b059056e984 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brendan,

<= div dir=3D"auto">I don=E2=80=99t think there=E2=80=99s an ambiguity here; I= IRC, the spec requires that public keys match ciphersuites, and that each c= iphersuite appear once.=C2=A0 So =E2=80=9Cthe public key for the group=E2= =80=99s ciphersuite=E2=80=9D should be well defined. =C2=A0

I agree that it=E2=80=99s inefficient= , though.=C2=A0

The main= difference between the current scheme and your proposal is that the full l= ist of supported suites never appears, so the server can downgrade a group = to the lowest suite supported by its initial set of clients.

Personally, that risk doesn=E2=80=99t= seem awful to me, since I don=E2=80=99t expect a ton of variability in cli= ent capabilities, at least in the short run.=C2=A0 But it would be a differ= ent guarantee than you get out of TLS.=C2=A0

What do other folks think?

=
=E2=80=94Richard

On Fri, Aug 16, 2019 at 15:51 = Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
Hello mls@

The definition of ClientInitKey in the spec currently has it contain sev= eral protocol versions, ciphersuites, and public keys. However, ClientInitK= ey objects are embedded into Init and Add messages, sent to many people, an= d all of these people must choose the same public key from the ClientInitKe= y for their ratchet tree.

Sending multiple public = keys wastes bandwidth and could cause synchronization issues, if different = members choose different public keys from the ClientInitKey. In particular,= if the same ciphersuite is provided twice, which I think is allowed.
=

The set of supported versions in the ClientInitKey is a= lso an array, but it doesn't seem to have the same 1-to-1 correspondenc= e that the ciphersuite and public key arrays do. Not clearly denoting which= ciphersuite corresponds to which protocol version seems like it also cause= s synchronization issues.

If people agree, I'd= like to open a PR changing ClientInitKey to contain only one protocol vers= ion, selected ciphersuite, and public key. Clients can generate many Client= InitKeys if they wish to support many versions and ciphersuites.
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000045200b059056e984-- From nobody Sat Aug 17 16:58:50 2019 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 325B012007C for ; Sat, 17 Aug 2019 16:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=callas.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 4wA1_E3Qe2eb for ; Sat, 17 Aug 2019 16:58:47 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0: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 04F3C12006D for ; Sat, 17 Aug 2019 16:58:47 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id i30so5018392pfk.9 for ; Sat, 17 Aug 2019 16:58:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i/DXl2NCXBTAzdiRHGbXrd4lAsUOG9iVnUsYp2b1qLM=; b=FHUN3cvrXX6WtgQsfsu2SzRTEPG68WNZy2qkxKQhdvmp4Yf91kWfnHWIjd42Y/lHRb KFvE8eBwUz8zsVRe6ui2va4BjBcfMOgXN1VDkxBZVt78BDwv5ZOXlryW+dvSf169VokZ uOG+btsivFWklmtR/sm0uE3QS37zTk6zeryJr4VG+VkVDec0zj+VES4KxmDkYHF/+acD Q/9vu5yTO30sO/Zziw57725W5F7zZ2NHtqoZ19yzT+9xlOF/BJJKWdwfIgxTj4Afg2wC JwRDDi1yRZhgRcbA6glkeZoIbBuCAtfOWkCNSybK1RzLEJhFvtuCS/TIET5A5076tnz/ uuNQ== 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=i/DXl2NCXBTAzdiRHGbXrd4lAsUOG9iVnUsYp2b1qLM=; b=ua8IQykX+CxGClamdgLTcLyKOq9NU1C1VCfDo3x/PHprZSVcshbMhky+eQLJE2UxDG zf9gy5CmNUfhFtj9G6ixoYBTlnpHdYxrj2nudInE4kXVpl/f+DUNeuLUDyeP89jIZEgB BWq2QbGK4KcQKwVsmZUZ3ne+ASwPvDP+rFYWL3IAlDVM221xG83TVyj3Fo4BxMkWMe9y zjHrBLdqrbgst/z/2mgmk2oRWwmY9jRp7q1S3sWV9/UF1E8h1dO5L+TG4UoCCdOAq3qZ c/LaknqikA6gw0aFJI5OFeg9hlRlqcCEzDQc3i7ZQJ4o5GrNnEDAJq2PpoVp9sZMqmo9 mIlw== X-Gm-Message-State: APjAAAVvY7MdvDhI6h5b7QebyOG1K6rkU8rmA8sTxYkmPgTdjp06/HmX 0GwbOsOMl/ZBxNVMuy2YhYJrpg== X-Google-Smtp-Source: APXvYqxBigcAISDoPIqgWtTzfUHnABr9CP8MW6z9wRQHJlnIeAUylGhlhysLQZby4BFr+hM8F8rcgw== X-Received: by 2002:a17:90a:224e:: with SMTP id c72mr14301786pje.9.1566086326381; Sat, 17 Aug 2019 16:58:46 -0700 (PDT) Received: from [10.137.59.86] (fa.c7.0bc6.ip4.static.sl-reverse.com. [198.11.199.250]) by smtp.gmail.com with ESMTPSA id k6sm10698248pfi.12.2019.08.17.16.58.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Aug 2019 16:58:45 -0700 (PDT) From: Jon Callas Message-Id: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_2C9095E9-3172-4410-BC5D-07D1A4D56463" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 17 Aug 2019 16:58:42 -0700 In-Reply-To: Cc: Jon Callas , Messaging Layer Security WG , Benjamin Beurdouche To: Peter Slatala References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] AEAD data in messages 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, 17 Aug 2019 23:58:49 -0000 --Apple-Mail=_2C9095E9-3172-4410-BC5D-07D1A4D56463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 15, 2019, at 9:03 AM, Peter Slatala = wrote: >=20 > Thanks Jon! This is a lot of good feedback. As you mentioned, a lot of = this AAD can be addressed by a separate edge-to-service key; what we = optimize for here is message overhead. Overhead is less of a concern for = messaging (unlike for real-time media), so it may be fine to have TLS + = <> edge-to-service + encrypted message itself. The quirk is that some of = the metadata would then have to be repeated in both delivery service = encrypted message & e2ee encrypted message, which is what I wanted to = optimize. By putting the info in AAD & using TLS we essentially save = overhead (from duplicating data, and from extra encryption overhead to = the server). >=20 > I'll think about it more and see if I can come up with a reasonable = proposal, but I am afraid I won't be able to come up with a solution = that will address all of your concerns. Come up with the proposal.=20 In general, I'm not opposed to features. Features are good and features = are bad. Too few makes a system brittle, too many makes it hard to = assess overall security and might introduce problems. Putting in a feature ought to do one of two things: enable something = that is reasonable for someone to do, but no one is doing it yet (future = expansion) or to head off a potential problem. On its surface, putting in AEAD doesn't sound bad, but we should avoid a = situation where when Alice sends a message to Bob, there's something in = there that is not directly relevant to that. A server in the middle = ideally is just routing cipher text that is interpreted when Bob gets = it, or is a message from Alice to the server. You gave lots of examples = of things Alice might want to say to the server. I think it's a bad idea = to conflate those into a single message. I also think it's a bad idea to = have plaintext metadata in a message. A server can be compromised in = subtle ways, like exceptional access, and making the protocol = access-ready with metadata seems suboptimal. Without an obvious upside to an AEAD message -- meaning something that = the AAD does that can't be done another way, my intuition is to leave it = out. We have scenarios that are downside, with no obvious upside, so the = risk calculus says to leave it out in my thinking. Obviously, with a use case for the AAD, that changes. That means = describing something where the AAD permits us to do X that we couldn't = do any other way. >=20 > > Actually the header encryption exists to protect MLS metadata from = the delivery service, so ideally most systems should deploy it. > When you say header encryption, what exactly do you mean? (I don't = believe draft mentions this). I searched through this thread, and I haven't found where I said "header = encryption." The first mention is from Jeff Burdges; perhaps he's the = best one to define it. Jon --Apple-Mail=_2C9095E9-3172-4410-BC5D-07D1A4D56463 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 15, 2019, at 9:03 AM, Peter Slatala <psla+mls@google.com>= wrote:

Thanks Jon! This is a = lot of good feedback. As you mentioned, a lot of this AAD can be = addressed by a separate edge-to-service key; what we optimize for here = is message overhead. Overhead is less of a concern for messaging (unlike = for real-time media), so it may be fine to have TLS + = edge-to-service + encrypted message itself. The quirk is that some = of the metadata would then have to be repeated in both delivery service = encrypted message & e2ee encrypted message, which is what I wanted = to optimize. By putting the info in AAD & using TLS we essentially = save overhead (from duplicating data, and from extra encryption overhead = to the server).

I'll think about it more and see if I can come up with a = reasonable proposal, but I am afraid I won't be able to come up with a = solution that will address all of your = concerns.

Come up with the proposal. 

In general, I'm not opposed to features. Features = are good and features are bad. Too few makes a system brittle, too many = makes it hard to assess overall security and might introduce = problems.

Putting in a feature ought = to do one of two things: enable something that is reasonable for someone = to do, but no one is doing it yet (future expansion) or to head off a = potential problem.

On its surface, = putting in AEAD doesn't sound bad, but we should avoid a situation where = when Alice sends a message to Bob, there's something in there that is = not directly relevant to that. A server in the middle ideally is just = routing cipher text that is interpreted when Bob gets it, or is a = message from Alice to the server. You gave lots of examples of things = Alice might want to say to the server. I think it's a bad idea to = conflate those into a single message. I also think it's a bad idea to = have plaintext metadata in a message. A server can be compromised in = subtle ways, like exceptional access, and making the protocol = access-ready with metadata seems suboptimal.

Without an obvious upside to an AEAD message -- = meaning something that the AAD does that can't be done another way, my = intuition is to leave it out. We have scenarios that are downside, with = no obvious upside, so the risk calculus says to leave it out in my = thinking.

Obviously, with a use case = for the AAD, that changes. That means describing something where the AAD = permits us to do X that we couldn't do any other way.


> Actually the header encryption exists to = protect MLS metadata from the = delivery service, so ideally most systems should deploy it.
When you say header encryption, what exactly do you mean? (I = don't believe draft mentions this).

I searched through this thread, and I haven't = found where I said "header encryption." The first mention is from Jeff = Burdges; perhaps he's the best one to define it.

Jon


= --Apple-Mail=_2C9095E9-3172-4410-BC5D-07D1A4D56463-- From nobody Mon Aug 19 10:16:50 2019 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 151F912004C for ; Mon, 19 Aug 2019 10:16:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZUJ6XD-iD4x for ; Mon, 19 Aug 2019 10:16:47 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 4081F120089 for ; Mon, 19 Aug 2019 10:16:47 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id w4so2356860ote.11 for ; Mon, 19 Aug 2019 10:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=lDiL+e/sOUvtJC+ps0ILLlppdFek4ofDZ2Rqo+IIDxQ=; b=kdHxBnTHI/V5RZ4jFq58FM/Ild9fKK1WaPPSfahT9i5TM+aQGK0+5o4XolaVLH2KQy a93QibVUhVmR2pkzRNjQVocY2e+XaRFoYENnY62agygc8nJGYZwEGES7byDiHsW05xsY MJLk65Pir4RgK88aTUP3CyTuIs/kEtxr2ZjCAbX1cMcpYFlh2BAxm+cNn6BZkbdEnTnr qekH4N5buBHEcO8clwNGEwTNTJlK9BFd2SJIOA4PGby/u0GKgfUuxk6nHPGz+eyLDfug RthJmi7ELUCmDtiOqxRbO3tuSUS54ZVoS9qhRoCaVdZCo7BetRI+7eut/3t89jEvCZjC lwog== 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:cc; bh=lDiL+e/sOUvtJC+ps0ILLlppdFek4ofDZ2Rqo+IIDxQ=; b=PndwdlpMswcvApohzX/FpzCcqA8C32WaZ9UWETOIIPD0T5FOPIvzc5PzM2+b5AQ6wR heGJEohnNBH/4Mnx76gyApYx0NyL1I5+x2QDpfvhxetWcy/tQc1jn64P/zCC2GvWA/no M9VYPF/tDd3KMnHTpsJXB5/HhFMk/rVQm0GztC6V9mVsavJdG2JZ3SpQH/7WmZoZg+QX WSgIBG5Qy2/G8DrKHSPbv37wj0nfHLemuSdEVjOiP9iYefLiyDGcP0hLLglDOsfbxnW/ rVh8VVxm6k1/B/iu3pnidlMDKv8VFUYIiYOKeGw0LCsA/SLauaDlrF6OaaVVuDBO8Wxi v7/g== X-Gm-Message-State: APjAAAW3aE4pFC67uvOrRdazszlavg3gtSDniZUyGFGfAVr+2iobafxp u4greFstlOuY+PUeh8GYv07A2q0+vADcWI7+rLuH/A== X-Google-Smtp-Source: APXvYqxydAKfqXnNEjX5WSk9xLwZGO7ZiB6FkElZwQaC50LSomJPtODNjf0kHKPvtOd7RZBNgtr6OjXfCDcjVGNm7MM= X-Received: by 2002:a05:6830:1159:: with SMTP id x25mr645416otq.237.1566235006208; Mon, 19 Aug 2019 10:16:46 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 19 Aug 2019 13:16:27 -0400 Message-ID: To: Benjamin Beurdouche Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000002e3d0805907b81af" Archived-At: Subject: [MLS] Exporters 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, 19 Aug 2019 17:16:49 -0000 --0000000000002e3d0805907b81af Content-Type: text/plain; charset="UTF-8" Hi Benjamin, (Note: MLS list CC'ed) Thanks for filing a PR starting work on defining an exporter for MLS [1]. In addition to the specific comments there, I wanted to raise some general questions here on the mailing list. Basically, what I'm wondering is at what point it makes sense to export stuff from MLS -- effectively, what the "API" of an MLS epoch is. It seems like there are a couple of approaches you could take here: 1. "Group secret" -- For each epoch, MLS provides: - An authenticated list of (identity, signing key) pairs for members in the group - A secret known to the members of the group 2. "Sender secrets" -- For each epoch, MLS provides the following for each member of the group: - An authenticated identity - A symmetric key that the participant uses to send messages - A signing key #1 is lower-level, and thus more flexible, but requires the application to arrange things like per-sender keys. #2 is closer to application semantics, but makes life unnecessarily difficult for applications that just need one key for the whole group. Personally, I'm inclined toward a "#1+", in the following sense: We define the exporter as the main way applications access key material, but since we need a message protection scheme for handshake messages, we also define an application that uses that scheme to send application data. Which is maybe just a fancy way of saying, "remove the `app_secret` and derive it from the exporter". If we can come to agreement on the right shape here, it would be good to update the architecture document to reflect it. In addition to making the documents a bit clearer, I think we'd end up with more consistency in MLS libraries. --Richard [1] https://github.com/mlswg/mls-protocol/pull/198 --0000000000002e3d0805907b81af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

(Note: MLS list= CC'ed)

Thanks for filing a PR starting work o= n defining an exporter for MLS [1].=C2=A0 In addition to the specific comme= nts there, I wanted to raise some general questions here on the mailing lis= t.

Basically, what I'm wondering is at what po= int it makes sense to export stuff from MLS -- effectively, what the "= API" of an MLS epoch is.=C2=A0 It seems like there are a couple of app= roaches you could take here:

1. "Group secret= " -- For each epoch, MLS provides:
=C2=A0 - An authenticated= list of (identity, signing key) pairs for members in the group
=C2=A0 - A secret known to the members of the group

=
2. "Sender secrets" -- For each epoch, MLS provides the foll= owing for each member of the group:
=C2=A0 - An authenticated ide= ntity
=C2=A0 - A symmetric key that the participant uses to s= end messages
=C2=A0 - A signing key

#1 i= s lower-level, and thus more flexible, but requires the application to arra= nge things like per-sender keys.=C2=A0 #2 is closer to application semantic= s, but makes life unnecessarily difficult for applications that just need o= ne key for the whole group.

Personally, I'm in= clined toward a "#1+", in the following sense: We define the expo= rter as the main way applications access key material, but since we need a = message protection scheme for handshake messages, we also define an applica= tion that uses that scheme to send application data.=C2=A0 Which is maybe j= ust a fancy way of saying, "remove the `app_secret` and derive it from= the exporter".

If we can come to agreeme= nt on the right shape here, it would be good to update the architecture doc= ument to reflect it.=C2=A0 In addition to making the documents a bit cleare= r, I think we'd end up with more consistency in MLS libraries.

--Richard

--0000000000002e3d0805907b81af-- From nobody Tue Aug 20 08:45:06 2019 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 382C9120966 for ; Tue, 20 Aug 2019 08:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=QXkVqxcR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fVuiR02z 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 BAMchSKXsfgt for ; Tue, 20 Aug 2019 08:45:01 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BD412095E for ; Tue, 20 Aug 2019 08:45:01 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 188EB495; Tue, 20 Aug 2019 11:45:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 20 Aug 2019 11:45:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=P FCdeqob4qEwj5OTGVpXHykQlwj6PxRJFSCgCMHnypE=; b=QXkVqxcRoaMJi3sFK zC4AnzCpg7GxtLvAjZkTJgticajeIMP3J4Ec7IVn7YentW27FVYgrryMab7clRiC de2gmAbNlZPS+HO7hLpt72G+9AsXPRu8odLKq3RrYiiZeQjDP7DHOM6ns8CSUCVX yziSiZ9QH3xTmETjhJri7paPhnyRrtdiTNF0XxA8cuIqkwwgmkstqpERXGx4og9Q IUKoX0rZPA6k+mbmUNBW91J1bN/W1at0hfE9K2dFSOxJE8teDFqp1ppjnfrughTG h9Z0JOg0mJSdpmYuYb6Z5XglHHkdY5LEv+6U6uXr/RCJ37xJdqUviTRLpoIMMl6r xaW+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=PFCdeqob4qEwj5OTGVpXHykQlwj6PxRJFSCgCMHny pE=; b=fVuiR02z7T7QVSY/tV1sOZZwl2kAjLwhRazOnF6NoYz+SgHfZJ4bueint CsbIbjtgV1lRjh08UFlKA4H1D75H17iK9smNLMK6SzxZwYAGklzTx7nh3/CH+MNS mFkI0DoXIre1WcaFMbXEauCS0cIaGH2DIDBnRJK9Qu+FMcR/ovxcp760TKXshrgA KSNwU+LNu2PfCfhPWWorBUEzOw3l0cF72L3iHvKfazMmwa1b6Y6BRTKb7iGaIIoS ZjLUsIzZMcdJ5/dk9b9u4WpFeoISqyL1RKirzmVcxs9yOw4KszmURW7AFyIjj4YW KfvLPOQRYYKDqbLq//KM73JRfpLEw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeguddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpefoihgthhgrvghlucftohhsvghnsggvrhhguceomhhitghr ohesfhgrshhtmhgrihhlrdgtohhmqeenucfkphepvddtgedrudegkedrgedvrddugedvne curfgrrhgrmhepmhgrihhlfhhrohhmpehmihgtrhhosehfrghsthhmrghilhdrtghomhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.7.172] (unknown [204.148.42.142]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B88E380075; Tue, 20 Aug 2019 11:44:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Rosenberg In-Reply-To: Date: Tue, 20 Aug 2019 11:44:58 -0400 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <0A680A2D-06CC-44BD-B14A-E48FD0E29188@fastmail.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] ClientInitKey Ambiguity 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, 20 Aug 2019 15:45:03 -0000 > IIRC, the spec requires...that each ciphersuite appear once. So = =E2=80=9Cthe public key for the group=E2=80=99s ciphersuite=E2=80=9D = should be well defined. =20 I don't see this in the spec. I think this should be a requirement = though: if a ciphersuite is defined in an MLS version that appears in = ClientInitKey::supported_versions, it MUST appear in = ClientInitKey::cipher_suites precisely once.= From nobody Wed Aug 21 20:11:11 2019 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 4891B12006A for ; Wed, 21 Aug 2019 20:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 pGV-VmHiUwAM for ; Wed, 21 Aug 2019 20:11:07 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 A48ED12003F for ; Wed, 21 Aug 2019 20:11:07 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id l9so5845338qtu.6 for ; Wed, 21 Aug 2019 20:11:07 -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=jRQ5EV8u6zw+DM8PZElKRvZQDto/svXoFbejvclONJs=; b=T/kVy73f+/5+cE59xTqwrE9nvvHbPA7vi6igGs0YdymzkwL5w6SD2/eKcKPyDqDbJ2 MeumTaQGF0NNlGX2dR4NAdcyj5/21jwZiJMBbFSUSMGWIav4eXqcg+ywuelCyuKoWvIY CURNvz9547eKWEMXjjcYmagvcG5UC8UT9cO3k= 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=jRQ5EV8u6zw+DM8PZElKRvZQDto/svXoFbejvclONJs=; b=NoiGm8qglADcVcgOuD38z81eVbcAGKEy+N8pG9faGTrwuCFzIq0L6CKYr/9dcqtkLZ zYeNiO+CRdUrikh7S+OwWNBcGztUsmZDVQQNW+04QvJNKrjFYMkSExvbZ3do9rRK6gNs oyXk/pQTspc0/zQF7giEVuzxJPPGJkGV+EgE251NmX59Gn8rRCRVky1Z8t1O4W/EqoX4 SbTeQIbTgx9MY0iGLCrMJdrDZ1Fa5i6BMl2xPcPWHPA8Kw+U10koRgl1EmVVOL9Y0A1Z CajbbxfZdnZcgP+etNwBJl0RqABTzFXkJs3insIvXc7fqmODcBYKWeIv97pkY9/r4ClF aZUg== X-Gm-Message-State: APjAAAXKLd2NTuwSE9/2s3ct+7n7hZh32FuJSLMdsMawdNWrVALHJpPG j8q+RG+w+zp1E/rh4OhJ4ugHoyp7GR8= X-Google-Smtp-Source: APXvYqxUWut2fDCGkA381nDmKZ98ZfQqSqV5MAlCwIWXpv8PHSjxtjnAzRf9el7L0GTbm4/byo3wcg== X-Received: by 2002:ac8:6890:: with SMTP id m16mr35270829qtq.377.1566443466704; Wed, 21 Aug 2019 20:11:06 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id z186sm11604447qkb.2.2019.08.21.20.11.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 20:11:06 -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 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 21 Aug 2019 23:11:05 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] MLS 2019 Fall Interim 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, 22 Aug 2019 03:11:09 -0000 All, We are planning to have an MLS 2019 Fall F2F Interim. Please fill out = the following doodle poll to indicate your preference by 2359 UTC = 28-AUG-2019: https://doodle.com/poll/5ri8n2uct2vyicka Currently, it looks very likely to be 1-2 October. The location is London, but the location is still TBD. Cheers, Nick & Sean= From nobody Thu Aug 22 15:17:05 2019 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 94C02120C3F for ; Thu, 22 Aug 2019 15:17:03 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TigEzkuJc3ZJ for ; Thu, 22 Aug 2019 15:17:01 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 7CE2B120227 for ; Thu, 22 Aug 2019 15:17:01 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id o6so5565733oic.9 for ; Thu, 22 Aug 2019 15:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=7PUDpTcIPP2NUaFwT/AOwuDPf7WcIbBfPNw6wWxWcFA=; b=InxrejCRELhSiRWhFtgp9WhWT2oCL6ioTSyDA4BCqO8xTJGdABypGez0UJIVFHTyOx 62aXvJq+4sN9tt9/5zxUlYlQKx/xa2mMgQU9dzgLKpo+IyVwQ2uqNxae9GOCjouz2/gg bR7emvlw+uU4hTNtDSzb8Tin/V1TVRSFIpOh/284z3traO2lIpq1XzqY0bZgP2nDY2Tm gIoRt3XOXacNtUl0l+Ub2CuOuZP7qt6ZxZCfPqmT1cZ3gF4U2vSxvChAv2vmI/jDKHTi Q5pc5bVC1dpQNw4vHNSFKViDIlf0i7zJAZ1orHEGgwlW/2WfWCdkxUPD8i0n7ySsFPzN CUAw== 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=7PUDpTcIPP2NUaFwT/AOwuDPf7WcIbBfPNw6wWxWcFA=; b=EeIpns7f+M7gwAYDxn5+uRTEF7E5GCnWThSAW0I5xfErvUPwnfZTGkfHuxEXU61Shg XApqtX1sBVmeWCPDk7pn0xTdvWPXi8mGvXLUvsaCNm4qW0eZ5Vxp6RBQ+K2Irz6bynNN oqRsArQnUiQOPvJh8uZRRC8RGQLu7r+HSCE3dfOWanj8GQQcbAMXcJkr8l31jLjVpO2a o7dFOwOwX84a7mdgcSuAEvZHfqvrR7SFhCXIO7Ep7MNUJ83IhNdtaoszqaLmZ5/l7Edd IxeDgAh5rSaHMWTqljNC064pAa8ixm4XztUPRLqeJLjwC0qL+B1PPX/QijVM6G7TD8UT w49A== X-Gm-Message-State: APjAAAWmDYl9awFrE8PA5xf+8N32lyz9/V+W90F/DreP3mLBVDTCQjOU A9pFKG0E5YcI/GBjU3VvJhdioA6IxKmiIJN5ZLa8jYmo/4NgLg== X-Google-Smtp-Source: APXvYqwClhD/GxrPo1a8+lF0u7Anhe8HLSNHOGJeyU/l1jFv3PV7Q0bfUCL7S6bTSNxdH2mjAFLYiLBzZEv3J8rrQIU= X-Received: by 2002:aca:d08:: with SMTP id 8mr959768oin.51.1566512220400; Thu, 22 Aug 2019 15:17:00 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 22 Aug 2019 18:16:43 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000006f06290590bc0c2b" Archived-At: Subject: [MLS] Proposal: Proposals (was: Laziness) 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, 22 Aug 2019 22:17:03 -0000 --0000000000006f06290590bc0c2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, I=E2=80=99d like to pose a question to the group of whether we should do = =E2=80=9Claziness=E2=80=9D or not. The complete form will be long, but the short version is: Do we care enough about DH overhead and server-initiated operations to do a pretty significant refactor and possibly add some complexity to the protocol? I would like to get a go/no-go on this idea before writing a PR, since it's going to be a big PR. And it would be helpful to make that decision in the next week or two, so that we can get the edits done and a new version out a bit in advance of the interim. So let's get this party started! # Objectives The overall goal is to meet two objectives: 1. Not requiring DH operations in groups where no messaging is happening 2. Allow some flavor of server-initiated Add and Remove The first of these objectives was raised by Raphael some time ago; see his presentation at the January interim for more details [1]. The second has been a long-outstanding feature request, from Facebook and Cisco, among others. The useful insight is that both of these require deferred operations. In the first case, you want to defer DH operations until someone wants to send a message. In the second case, you might have the server propose an operation that it can=E2=80=99t do, so that the execution of the operation = is deferred until someone in the group does it. # Proposal The proposal here is to refactor the protocol from =E2=80=9Cimmediate mode= =E2=80=9D to =E2=80=9Cdeferred mode=E2=80=9D. None of the underlying tree math changes,= just how we talk about it. * Add, Remove, and Update become =E2=80=9CProposals=E2=80=9D that describe = an operation, rather than carrying the information to accomplish the information immediately * Add =3D =E2=80=9CPlease add ${ClientInitKey}=E2=80=9D * Update =3D =E2=80=9CPlease replace the leaf at ${index} with ${key} a= nd blank its direct path=E2=80=9D * Remove =3D =E2=80=9CPlease remove the member at ${index} * Each epoch contains a set of proposals, followed by a Commit message * None of the proposed changes take effect until the Commit message * If there are outstanding proposals, you SHOULD send a Commit before sending a message * A Commit message contains: * A description of which proposals were applied and how * In particular, the committer chooses the positions where new members are added * A direct path that KEMs new entropy to the group (basically an update from the Committer) * The committer also generates Welcome messages for any new participants * With handshake encryption, the Welcome just needs to have the key for the Commit * The Commit should commit to the state of the tree after the proposals are executed (just like handshake messages do today) * ... so the new joiner doesn't need to see the proposals, just the Commit # Observations * In the framework above, there's no need to synchronize proposals, just Commits * If the Commit includes the proposals by value or hash, then we can just run the transcript over the Commit messages, and the proposals will be included transitively * Note that proposals can overwrite one another, e.g., an update and a remove for the same slot * If we refactor in the above form, an application could reconstruct what we have now by always sending a (Proposal, Commit) combo * In fact, one way to view this is as splitting off the Commit from the current Handshake messages # Benefits * We get the objectives that we set out to achieve: * Quiescent groups can just pile up proposals, and Commit before messaging * The server can synthesize Add and Remove proposals as long as clients have a way to authenticate them (e.g., a designated sender index for the server) * There's a certain conceptual simplicity to only having one message that advances the group state * With regard to the "ghost account" concerns that DKG raised at the IETF meeting, this ensures that the proposals to add users are part of the transcript, thus visible to the group # Costs * The longer you go before a Commit, the more expensive the Commit is, since the proposals are all destructive, in the sense that they blank out parts of the tree * The logic for a new joiner might get more complicated, since they're not actually added until the Commit. In particular, you can't send an Add proposal and have the new member immediately able to transmit, you have to do a Commit as well. * At least in the form above, we lose the property that Adds are constant time, since you would always do an asymmetric ratchet operation. If this were a problem, you could special-case it (if the Commit only has Adds...) * Retry logic might get more complicated; need to wait for a Commit before I know whether my change made it in * The protocol gets more verbose since you need the glue to refer to the proposals from the Commit ----- Thanks for reading all the way to the bottom! Personally, I'm pretty split on this. On the one hand, I think this can be done pretty elegantly. On the other hand, it does feel more complex, and I'm worried we're spending a lot of complexity budget on some fairly niche use cases. On the third hand, I do think we need server-initiated Add/Remove, and all the approaches that come to mind end up looking kind of like this Happy to have questions / comments here, or if there=E2=80=99s enough inter= est, it might be good to have a quick phone call. =E2=80=94Richard --0000000000006f06290590bc0c2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I=E2=80=99d like to pose a question to the= group of whether we should do =E2=80=9Claziness=E2=80=9D or not. =C2=A0 Th= e complete form will be long, but the short version is: Do we care enough a= bout DH overhead and server-initiated operations to do a pretty significant= refactor and possibly add some complexity to the protocol?

I would like to get a go/no-go on this idea before writing a PR, si= nce it's going to be a big PR.=C2=A0 And it would be helpful to make th= at decision in the next week or two, so that we can get the edits done and = a new version out a bit in advance of the interim.=C2=A0 So let's get t= his party started!

# Objectives

The overall = goal is to meet two objectives:

1. Not requiring DH operations in gr= oups where no messaging is happening
2. Allow some flavor of server-init= iated Add and Remove

The first of these objectives was raised by Rap= hael some time ago; see his presentation at the January interim for more de= tails [1].=C2=A0 The second has been a long-outstanding feature request, fr= om Facebook and Cisco, among others.

The useful insight is that both= of these require deferred operations.=C2=A0 In the first case, you want to= defer DH operations until someone wants to send a message.=C2=A0 In the se= cond case, you might have the server propose an operation that it can=E2=80= =99t do, so that the execution of the operation is deferred until someone i= n the group does it.

# Proposal

The proposal here is to refac= tor the protocol from =E2=80=9Cimmediate mode=E2=80=9D to =E2=80=9Cdeferred= mode=E2=80=9D.=C2=A0 None of the underlying tree math changes, just how we= talk about it.

* Add, Remove, and Update become =E2=80=9CProposals= =E2=80=9D that describe an operation, rather than carrying the information = to accomplish the information immediately
=C2=A0 =C2=A0 * Add =3D =E2=80= =9CPlease add ${ClientInitKey}=E2=80=9D
=C2=A0 =C2=A0 * Update =3D =E2= =80=9CPlease replace the leaf at ${index} with ${key} and blank its direct = path=E2=80=9D
=C2=A0 =C2=A0 * Remove =3D =E2=80=9CPlease =C2=A0remove th= e member at ${index}
* Each epoch contains a set of proposals, followed = by a Commit message
=C2=A0 =C2=A0 * None of the proposed changes take ef= fect until the Commit message
=C2=A0 =C2=A0 * If there are outstanding p= roposals, you SHOULD send a Commit before sending a message
* A Commit m= essage contains:
=C2=A0 =C2=A0 * A description of which proposals w= ere applied and how
=C2=A0 =C2=A0 * In particular, the committer choos= es the positions where new members are added
=C2=A0 =C2=A0 * A direct pa= th that KEMs new entropy to the group (basically an update from the Committ= er)
* The committer also generates Welcome messages for any new particip= ants
=C2=A0 =C2=A0 * With handshake encryption, the Welcome just ne= eds to have the key for the Commit
=C2=A0=C2=A0=C2=A0 * The Commi= t should commit to the state of the tree after the proposals are executed (= just like handshake messages do today)
=C2=A0=C2=A0=C2=A0 * ... s= o the new joiner doesn't need to see the proposals, just the Commit
=

# Observations

* In the framework above, there's = no need to synchronize proposals, just Commits
* If the Commit in= cludes the proposals by value or hash, then we can just run the transcript = over the Commit messages, and the proposals will be included transitively
* Note that proposals can overwrite one another, e.g., an upda= te and a remove for the same slot
* If we refactor in the abo= ve form, an application could reconstruct what we have now by always sendin= g a (Proposal, Commit) combo
* In fact, one way to view this is a= s splitting off the Commit from the current Handshake messages

# Benefits

* We get the objectives that = we set out to achieve:
=C2=A0=C2=A0=C2=A0 * Quiescent groups can = just pile up proposals, and Commit before messaging
=C2=A0=C2=A0= =C2=A0 * The server can synthesize Add and Remove proposals as long as clie= nts have a way to authenticate them (e.g., a designated sender index for th= e server)
* There's a certain conceptual simplicity to on= ly having one message that advances the group state
* With regard= to the "ghost account" concerns that DKG raised at the IETF meet= ing, this ensures that the proposals to add users are part of the transcrip= t, thus visible to the group

# Costs

=
* The longer you go before a Commit, the more expensive the Commit is,= since the proposals are all destructive, in the sense that they blank out = parts of the tree
* The logic for a new joiner might get more= complicated, since they're not actually added until the Commit.=C2=A0 = In particular, you can't send an Add proposal and have the new member i= mmediately able to transmit, you have to do a Commit as well.
* At least in the form above, we lose the property that Adds are constant = time, since you would always do an asymmetric ratchet operation.=C2=A0 If t= his were a problem, you could special-case it (if the Commit only has Adds.= ..)
* Retry logic might get more complicated; need to wait fo= r a Commit before I know whether my change made it in
* The proto= col gets more verbose since you need the glue to refer to the proposals fro= m the Commit

-----

Thanks= for reading all the way to the bottom!

Person= ally, I'm pretty split on this.=C2=A0 On the one hand, I think this can= be done pretty elegantly.=C2=A0 On the other hand, it does feel more compl= ex, and I'm worried we're spending a lot of complexity budget on so= me fairly niche use cases.=C2=A0 On the third hand, I do think we need serv= er-initiated Add/Remove, and all the approaches that come to mind end up lo= oking kind of like this

Happy to have question= s / comments here, or if there=E2=80=99s enough interest, it might be good = to have a quick phone call.

=E2=80=94Richard
--0000000000006f06290590bc0c2b-- From nobody Thu Aug 22 15:18:07 2019 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 6D2EE120227 for ; Thu, 22 Aug 2019 15:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZwXdyukL_Qv for ; Thu, 22 Aug 2019 15:18:04 -0700 (PDT) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (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 BAB4412012C for ; Thu, 22 Aug 2019 15:18:04 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id a127so5596805oii.2 for ; Thu, 22 Aug 2019 15:18:04 -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; bh=jyC2uG5J5EEAcyyTu3BVrmqJ/Qqkt6aj2cUppH6rKPk=; b=kPmFYcTs5HRb9uDc6KkQjulADGdnHjS7zpbtOZRFs+dQNft7iSKoKw8atIituOV2ZE FiNTqXLwVaV6cbOKNZU7R5ZOy2+K+ufNUNmIQz5/cAk5C9HjE9h5kFkfuC4ldefU1Koc R3rcRRRZhE1iLgjCbqKhzc0xXliJf0fWtwYnqvZphRUdbCDubglz4wp2I3gd0PjFTQxb fOvXTIHKsCQTw3mR42cx+QLu/K4zgg7Vn9jvSGJVNNNovYUj2RFSRWXRt3petcqXdft8 chzLRqRcrb4CwR12ff3QCKGp6OLOnT1GA+/kcAecMxpXhJW/XnWc4SJW3euEmxPOxe9N MubQ== 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=jyC2uG5J5EEAcyyTu3BVrmqJ/Qqkt6aj2cUppH6rKPk=; b=XDWMIK8fq3jCX5AM1WxWUOY0RiwCHlnrMM+mo5x7QEv176z0WwMo626mKNhlC6raAL urFGWAqknUADyVWm/flAzqJ1dERM8awyijxTWTwPvgIGoBPCMVX8IsNLJ8doa59kEmHT 1Dup3PpttWlMVvSatt6TzEADGHqFmtBsO0TykPQMtFHQe5zhJGA51mQK/HZaRnUKLQ3A uR92sDPHYfCyfp/I8xkATXXsmT2jt2veR9WFtA0ulN6BFY0wxDDBAUWHkitsxLWIhKxb UguWdfwu3ykGEfr3jbkWu1q7xZJYa/++0pT3m3AwdHA+3CBtz/wnp7biDEciuJs6r/4c O9rg== X-Gm-Message-State: APjAAAUEpd3YAJIYThwUCDc3crq9Ll7r2gMdsb8bI3uyCGj+X/2VoG8n nfqP21Mpe1cntih7eqxPTFi7omx5PCknGZld/pFUsR5e/88= X-Google-Smtp-Source: APXvYqx8GCDT3UT75Xpm6vyawJI379H3Rmv6ctl5Gt0ojFQ8obnj2dpEwNK0CR08EOrseANbaUVA8jLLr87IS3JExLg= X-Received: by 2002:aca:53cf:: with SMTP id h198mr942640oib.169.1566512283793; Thu, 22 Aug 2019 15:18:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 22 Aug 2019 18:17:46 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000003669120590bc10b6" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 22 Aug 2019 22:18:06 -0000 --0000000000003669120590bc10b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable BTW, big thanks to Raphael for setting us down this path, and to Katriel for talking this through with me earlier this week (and for coming up with the Welcome-by-Committer part). On Thu, Aug 22, 2019 at 6:16 PM Richard Barnes wrote: > Hey all, > > I=E2=80=99d like to pose a question to the group of whether we should do > =E2=80=9Claziness=E2=80=9D or not. The complete form will be long, but = the short version > is: Do we care enough about DH overhead and server-initiated operations t= o > do a pretty significant refactor and possibly add some complexity to the > protocol? > > I would like to get a go/no-go on this idea before writing a PR, since > it's going to be a big PR. And it would be helpful to make that decision > in the next week or two, so that we can get the edits done and a new > version out a bit in advance of the interim. So let's get this party > started! > > # Objectives > > The overall goal is to meet two objectives: > > 1. Not requiring DH operations in groups where no messaging is happening > 2. Allow some flavor of server-initiated Add and Remove > > The first of these objectives was raised by Raphael some time ago; see hi= s > presentation at the January interim for more details [1]. The second has > been a long-outstanding feature request, from Facebook and Cisco, among > others. > > The useful insight is that both of these require deferred operations. In > the first case, you want to defer DH operations until someone wants to se= nd > a message. In the second case, you might have the server propose an > operation that it can=E2=80=99t do, so that the execution of the operatio= n is > deferred until someone in the group does it. > > # Proposal > > The proposal here is to refactor the protocol from =E2=80=9Cimmediate mod= e=E2=80=9D to > =E2=80=9Cdeferred mode=E2=80=9D. None of the underlying tree math change= s, just how we > talk about it. > > * Add, Remove, and Update become =E2=80=9CProposals=E2=80=9D that describ= e an operation, > rather than carrying the information to accomplish the information > immediately > * Add =3D =E2=80=9CPlease add ${ClientInitKey}=E2=80=9D > * Update =3D =E2=80=9CPlease replace the leaf at ${index} with ${key}= and blank > its direct path=E2=80=9D > * Remove =3D =E2=80=9CPlease remove the member at ${index} > * Each epoch contains a set of proposals, followed by a Commit message > * None of the proposed changes take effect until the Commit message > * If there are outstanding proposals, you SHOULD send a Commit before > sending a message > * A Commit message contains: > * A description of which proposals were applied and how > * In particular, the committer chooses the positions where new member= s > are added > * A direct path that KEMs new entropy to the group (basically an > update from the Committer) > * The committer also generates Welcome messages for any new participants > * With handshake encryption, the Welcome just needs to have the key > for the Commit > * The Commit should commit to the state of the tree after the > proposals are executed (just like handshake messages do today) > * ... so the new joiner doesn't need to see the proposals, just the > Commit > > # Observations > > * In the framework above, there's no need to synchronize proposals, just > Commits > * If the Commit includes the proposals by value or hash, then we can just > run the transcript over the Commit messages, and the proposals will be > included transitively > * Note that proposals can overwrite one another, e.g., an update and a > remove for the same slot > * If we refactor in the above form, an application could reconstruct what > we have now by always sending a (Proposal, Commit) combo > * In fact, one way to view this is as splitting off the Commit from the > current Handshake messages > > # Benefits > > * We get the objectives that we set out to achieve: > * Quiescent groups can just pile up proposals, and Commit before > messaging > * The server can synthesize Add and Remove proposals as long as > clients have a way to authenticate them (e.g., a designated sender index > for the server) > * There's a certain conceptual simplicity to only having one message that > advances the group state > * With regard to the "ghost account" concerns that DKG raised at the IETF > meeting, this ensures that the proposals to add users are part of the > transcript, thus visible to the group > > # Costs > > * The longer you go before a Commit, the more expensive the Commit is, > since the proposals are all destructive, in the sense that they blank out > parts of the tree > * The logic for a new joiner might get more complicated, since they're no= t > actually added until the Commit. In particular, you can't send an Add > proposal and have the new member immediately able to transmit, you have t= o > do a Commit as well. > * At least in the form above, we lose the property that Adds are constant > time, since you would always do an asymmetric ratchet operation. If this > were a problem, you could special-case it (if the Commit only has Adds...= ) > * Retry logic might get more complicated; need to wait for a Commit befor= e > I know whether my change made it in > * The protocol gets more verbose since you need the glue to refer to the > proposals from the Commit > > ----- > > Thanks for reading all the way to the bottom! > > Personally, I'm pretty split on this. On the one hand, I think this can > be done pretty elegantly. On the other hand, it does feel more complex, > and I'm worried we're spending a lot of complexity budget on some fairly > niche use cases. On the third hand, I do think we need server-initiated > Add/Remove, and all the approaches that come to mind end up looking kind = of > like this > > Happy to have questions / comments here, or if there=E2=80=99s enough int= erest, it > might be good to have a quick phone call. > > =E2=80=94Richard > --0000000000003669120590bc10b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
BTW, big thanks to Raphael for setting us down this path, = and to Katriel for talking this through with me earlier this week (and for = coming up with the Welcome-by-Committer part).

On Thu, Aug 22, 2019 at 6= :16 PM Richard Barnes <rlb@ipv.sx> wrote:
Hey all,

I=E2=80= =99d like to pose a question to the group of whether we should do =E2=80=9C= laziness=E2=80=9D or not. =C2=A0 The complete form will be long, but the sh= ort version is: Do we care enough about DH overhead and server-initiated op= erations to do a pretty significant refactor and possibly add some complexi= ty to the protocol?

I would like to get a go/no-go o= n this idea before writing a PR, since it's going to be a big PR.=C2=A0= And it would be helpful to make that decision in the next week or two, so = that we can get the edits done and a new version out a bit in advance of th= e interim.=C2=A0 So let's get this party started!

# Objectives

The overall goal is to meet two objectives:

1= . Not requiring DH operations in groups where no messaging is happening
= 2. Allow some flavor of server-initiated Add and Remove

The first of= these objectives was raised by Raphael some time ago; see his presentation= at the January interim for more details [1].=C2=A0 The second has been a l= ong-outstanding feature request, from Facebook and Cisco, among others.
=
The useful insight is that both of these require deferred operations.= =C2=A0 In the first case, you want to defer DH operations until someone wan= ts to send a message.=C2=A0 In the second case, you might have the server p= ropose an operation that it can=E2=80=99t do, so that the execution of the = operation is deferred until someone in the group does it.

# Proposal=

The proposal here is to refactor the protocol from =E2=80=9Cimmedia= te mode=E2=80=9D to =E2=80=9Cdeferred mode=E2=80=9D.=C2=A0 None of the unde= rlying tree math changes, just how we talk about it.

* Add, Remove, = and Update become =E2=80=9CProposals=E2=80=9D that describe an operation, r= ather than carrying the information to accomplish the information immediate= ly
=C2=A0 =C2=A0 * Add =3D =E2=80=9CPlease add ${ClientInitKey}=E2=80=9D=
=C2=A0 =C2=A0 * Update =3D =E2=80=9CPlease replace the leaf at ${index}= with ${key} and blank its direct path=E2=80=9D
=C2=A0 =C2=A0 * Remove = =3D =E2=80=9CPlease =C2=A0remove the member at ${index}
* Each epoch con= tains a set of proposals, followed by a Commit message
=C2=A0 =C2=A0 * N= one of the proposed changes take effect until the Commit message
=C2=A0 = =C2=A0 * If there are outstanding proposals, you SHOULD send a Commit befor= e sending a message
* A Commit message contains:
=C2=A0 =C2=A0 *= A description of which proposals were applied and how
=C2=A0 =C2=A0 *= In particular, the committer chooses the positions where new members are a= dded
=C2=A0 =C2=A0 * A direct path that KEMs new entropy to the group (b= asically an update from the Committer)
* The committer also generates We= lcome messages for any new participants
=C2=A0 =C2=A0 * With handsh= ake encryption, the Welcome just needs to have the key for the Commit
=
=C2=A0=C2=A0=C2=A0 * The Commit should commit to the state of the tree= after the proposals are executed (just like handshake messages do today)
=C2=A0=C2=A0=C2=A0 * ... so the new joiner doesn't need to see= the proposals, just the Commit

# Observations

* I= n the framework above, there's no need to synchronize proposals, just C= ommits
* If the Commit includes the proposals by value or hash, t= hen we can just run the transcript over the Commit messages, and the propos= als will be included transitively
* Note that proposals can o= verwrite one another, e.g., an update and a remove for the same slot
* If we refactor in the above form, an application could reconstruc= t what we have now by always sending a (Proposal, Commit) combo
*= In fact, one way to view this is as splitting off the Commit from the curr= ent Handshake messages

# Benefits

* We get the objectives that we set out to achieve:
=C2=A0= =C2=A0=C2=A0 * Quiescent groups can just pile up proposals, and Commit befo= re messaging
=C2=A0=C2=A0=C2=A0 * The server can synthesize Add a= nd Remove proposals as long as clients have a way to authenticate them (e.g= ., a designated sender index for the server)
* There's a = certain conceptual simplicity to only having one message that advances the = group state
* With regard to the "ghost account" concer= ns that DKG raised at the IETF meeting, this ensures that the proposals to = add users are part of the transcript, thus visible to the group
<= br>
# Costs

* The longer you go before a Commit= , the more expensive the Commit is, since the proposals are all destructive= , in the sense that they blank out parts of the tree
* The lo= gic for a new joiner might get more complicated, since they're not actu= ally added until the Commit.=C2=A0 In particular, you can't send an Add= proposal and have the new member immediately able to transmit, you have to= do a Commit as well.
* At least in the form above, we lose t= he property that Adds are constant time, since you would always do an asymm= etric ratchet operation.=C2=A0 If this were a problem, you could special-ca= se it (if the Commit only has Adds...)
* Retry logic might ge= t more complicated; need to wait for a Commit before I know whether my chan= ge made it in
* The protocol gets more verbose since you need the= glue to refer to the proposals from the Commit

--= ---

Thanks for reading all the way to the bottom!<= br>

Personally, I'm pretty split on this.=C2= =A0 On the one hand, I think this can be done pretty elegantly.=C2=A0 On th= e other hand, it does feel more complex, and I'm worried we're spen= ding a lot of complexity budget on some fairly niche use cases.=C2=A0 On th= e third hand, I do think we need server-initiated Add/Remove, and all the a= pproaches that come to mind end up looking kind of like this
=
Happy to have questions / comments here, or if there=E2=80= =99s enough interest, it might be good to have a quick phone call.
=E2=80=94Richard
--0000000000003669120590bc10b6-- From nobody Fri Aug 23 02:08:14 2019 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 6B7A31201EF for ; Fri, 23 Aug 2019 02:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 edB4uGa0t_SG for ; Fri, 23 Aug 2019 02:08:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC53B120125 for ; Fri, 23 Aug 2019 02:08:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00830BE5B; Fri, 23 Aug 2019 10:08:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnvUO5yiWHe9; Fri, 23 Aug 2019 10:08:05 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89239BE4D; Fri, 23 Aug 2019 10:08:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566551285; bh=G58BRKybcpCMHn4LP8poj7zqyLj2ER53RJ6jiEWn5r4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BkcvkuW/pcSRzjzQtYgGcPFSb2BNzRu1mEn9hhjl1LKqf5VfCDu8f6gXHNslXpj8B De7wrnR6kfzUldf5NISghNHgem9gLdyl42Mg9ACaiV/v/172Tt28LtjNiomsGXIB/3 2mP9uD929QiWjkI602/3tj7WDdzsxrQyu619JZSE= To: Richard Barnes , Messaging Layer Security WG References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 23 Aug 2019 10:08:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sqUnvbwoEaiNQRqbCW0wCbAyPGeRlBZXa" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 09:08:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sqUnvbwoEaiNQRqbCW0wCbAyPGeRlBZXa Content-Type: multipart/mixed; boundary="J0CkWW8DZCGRYrNNDTqzRGjBWW3jVPshT"; protected-headers="v1" From: Stephen Farrell To: Richard Barnes , Messaging Layer Security WG Message-ID: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) References: In-Reply-To: --J0CkWW8DZCGRYrNNDTqzRGjBWW3jVPshT Content-Type: multipart/mixed; boundary="------------55BCC9A00613BAB8F7AA0FA3" Content-Language: en-GB This is a multi-part message in MIME format. --------------55BCC9A00613BAB8F7AA0FA3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for not following mls in detail but can you explain how: On 22/08/2019 23:16, Richard Barnes wrote: > 2. Allow some flavor of server-initiated Add and Remove =2E..compares to the status quo ante? Thanks, S. --------------55BCC9A00613BAB8F7AA0FA3 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------55BCC9A00613BAB8F7AA0FA3-- --J0CkWW8DZCGRYrNNDTqzRGjBWW3jVPshT-- --sqUnvbwoEaiNQRqbCW0wCbAyPGeRlBZXa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1frPQACgkQWrL68XsX K+rvTQ/+N8muTS7XW/3qyfweiofd6gosjdTbfE8jkBvGPKZrFYxHFeLIjRdCHRLf qgoXOVpmOJH0e/rDScCBakhcJZSCl3C55O/xPFLo2ZAhZsoMG66MM7n6AsRVQw2Q aOuu0X6h2iMPhpdFyBK5XqKSotGia3YhPEjEmkF/MExUj0xEwCKjPtU6aQvlXGzZ aFQpiqnZDNNUgHhkhJx9+iKoNHgBbBCeElergjGsnmxPi9dltaOA6CDa0jz8vj/l 9Vr8SY+E9O74geZoUBx8a+4vJXvLTSONfWOUxKPxW4aHsZs9SkKQ1IqhvNPrjJ81 o57M9+KS+QSRMg5P14ZSSLxkfA91OkCCF87dlNt5Zz1BeKqVZOeexhjB5RMs85iJ 9A+6TYVSoUeFUIwlC9OU3RSLMeL/O5BgSDD6GjGtseoqLoIBOOOPVa9rm1u1qI8i 8EMa4s0Q4AmTanKKAnAB7+hYCZ8BdWMcIAB22uNI6j9LFHmmVyq72TzGznXiAP/b LlSseiou4mKPPZUu6kmKQnXsXWwhrWvNGynRGiwHY0Aw47AsvqgGyNUj238elplo 3/l7ZMwg0uHg56YLjCES9wIi1wEWEN0vXLBpwHzfmfSgEw92J3gY9NqKGMSNtE2W WbluS2IWlBT+F5iihC8dKmErG/3vLpJ/UEmThaePajjEfRgCNVc= =/yMi -----END PGP SIGNATURE----- --sqUnvbwoEaiNQRqbCW0wCbAyPGeRlBZXa-- From nobody Fri Aug 23 03:21:44 2019 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 3B684120804 for ; Fri, 23 Aug 2019 03:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_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=wire-com.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 wD4gFWhhBwBa for ; Fri, 23 Aug 2019 03:21:38 -0700 (PDT) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 E83EC1200B6 for ; Fri, 23 Aug 2019 03:21:37 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id l2so8589574wmg.0 for ; Fri, 23 Aug 2019 03:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=xoMMuDYuhkKBloO5f4DK2I1dbuCUYROfXzy6YhLlySA=; b=il3lzurIbS1F82Cfu7h5xY0W9Wrr2ConVUmIvV7np++XtaOlMgNAlR1v8OQEEEH8yD dUBBtzva5t1/etGVGi8Gctnia4S6jI7+JPC3Sl25156MuGT7qegyHUeVHu8hWHoLWmV3 adv4KLKrxjyY4PlWnDExGmszvDV2+NKJHAenK0MWYaGbkWDV/FwD2BdDolIEADWCQjxX UbF8tomZcA5UYU4blccMGXpvTSiQMydhKUMRL2Mr361buA9tr7E1mhefUIUb2wLVUeKU Pxmqc9XeRcFGYqfzXL7e4KiX5SLqiU6chbP73Q64YgNFZs8ErEfDf+yu9VYfVjgaqSzl +gpg== 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:date:references:to :in-reply-to:message-id; bh=xoMMuDYuhkKBloO5f4DK2I1dbuCUYROfXzy6YhLlySA=; b=eajCMS1L5M95Otv5UY1oYq0xtElw43Mk1F2h3KSpt0pyvEUokgLKO/UtdTmQjEs6uz KXlt9yhba30t18atYEZi6kGcKfKM/mSfk6ZU2792LODNLgoFTNzGH2KiKzG3jGAraQys 6mhBrkZB3G1zevCek4MgZmrUNEe4uWOzbVRb1XRRDXm5hKQo/L/8x2G3FR5dmWT2Tcua TsVt2jb0RQXX320i70yJIiiYNvCvp48sv+9zbbjL4kJZ364/V330rJeasDofK71TMFLG 96BOOaOPrzT8RqgiA1t+ce2/JG77PUGogFKfqmN6S3viV/Hpky5khMC/JYtXP2uRi7YZ QoIA== X-Gm-Message-State: APjAAAXV/dkXG1qm4wgW0eNETgzQ1S2zwKP58yXdZl9sfMGOs/kQUwY2 H/r4ZQv9A2+LS2kJ0ahVgdd+PX7S/sw= X-Google-Smtp-Source: APXvYqxBBmr58LNUrFYOeuPT2HAKUjjqm7pd5lP50qsjlYdASzi5s8B2IdD8lDnW8Qd1WyzycLfNqg== X-Received: by 2002:a7b:cc86:: with SMTP id p6mr4296541wma.106.1566555695608; Fri, 23 Aug 2019 03:21:35 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id w15sm2474794wmi.19.2019.08.23.03.21.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 03:21:34 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_0B917B4F-E69F-439E-BFE4-AEBEDFA66F8B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 23 Aug 2019 12:21:33 +0200 References: To: Messaging Layer Security WG In-Reply-To: Message-Id: <45806213-8D34-4BC0-8FB4-138521E1D826@wire.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 10:21:41 -0000 --Apple-Mail=_0B917B4F-E69F-439E-BFE4-AEBEDFA66F8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A big thank you to Richard and Katriel for fleshing this out to this = level of detail! It is nice to see that we can potentially address two somewhat = orthogonal issues with one solution. I still maintain that a deferred = execution of =E2=80=9CProposals=E2=80=9D adds a real benefit to the = protocol, because it allows for more flexibility in scenarios where = immediate execution is not needed. I also maintain that the total cost = of CPU time and bandwidth might be less on average with this approach, = since I foresee that Adds and Removes will cancel each other out in = groups that are dormant (i.e. where no messages are exchanged). I=E2=80=99d like to raise some practical questions: - How are Proposals encrypted? The intuition would be that we can = encrypt them the same way we encrypt handshake messages today, if the = proposals are issued by an existing member of the group. If they are = issued by the server, they could be either in plaintext or the server = could encrypt them using HPKE with the current root public key of a = tree. - Can Update Proposals be issued by anyone but the member itself? If we = say yes, the analysis will be more straight forward, but it is also more = limited. If we say no, the question remains who can issue them. They = could be issued by the server or another member. Right now I don=E2=80=99t= see why another member should be allowed to do so, but I could think of = reasons why the server should be allowed to do so (multi-device = context). We should again be very careful w.r.t the ghost user scenario = in order to avoid the possibility that the server can sneak in a = malicious participant that way. - At the January interim we also talked about the possibility for = members that were added by the server to send messages right away by = encrypting them to the root of the tree. I wonder if we would pursue = this idea and how we would do it in practice. The idea of instant = communication is certainly nice, but it would mean that messages would = be sent to the group before a Commit has happened. This in turn means = that a member that is supposed to be evicted (through a erred Remove) = could still potentially have the key material to decrypt those messages. = Specifically, this would happen in the sequence {Add D, Remove B}, D = would encrypt messages to the group that can still be read by B until = the commit is issued and B is properly evicted. - If we go for the Proposals concept, we should probably make it very = clear that clients should issue and execute Commits as soon as possible. = Concrete example: if a client determines it has enough processing power = and enough bandwidth, it should pre-emptively issue a Commit in groups = with pending Proposals in order to heal the tree somewhat and restore = all security properties. I can however see that such a strategy is not = uncontroversial, so I=E2=80=99d be happy to hear some arguments of why = we shouldn=E2=80=99t do this. Raphael > On 23 Aug 2019, at 00:17, Richard Barnes wrote: >=20 > BTW, big thanks to Raphael for setting us down this path, and to = Katriel for talking this through with me earlier this week (and for = coming up with the Welcome-by-Committer part). >=20 > On Thu, Aug 22, 2019 at 6:16 PM Richard Barnes wrote: > Hey all, >=20 > I=E2=80=99d like to pose a question to the group of whether we should = do =E2=80=9Claziness=E2=80=9D or not. The complete form will be long, = but the short version is: Do we care enough about DH overhead and = server-initiated operations to do a pretty significant refactor and = possibly add some complexity to the protocol? >=20 > I would like to get a go/no-go on this idea before writing a PR, since = it's going to be a big PR. And it would be helpful to make that = decision in the next week or two, so that we can get the edits done and = a new version out a bit in advance of the interim. So let's get this = party started! >=20 > # Objectives >=20 > The overall goal is to meet two objectives: >=20 > 1.. Not requiring DH operations in groups where no messaging is = happening > 2. Allow some flavor of server-initiated Add and Remove >=20 > The first of these objectives was raised by Raphael some time ago; see = his presentation at the January interim for more details [1]. The = second has been a long-outstanding feature request, from Facebook and = Cisco, among others. >=20 > The useful insight is that both of these require deferred operations. = In the first case, you want to defer DH operations until someone wants = to send a message. In the second case, you might have the server = propose an operation that it can=E2=80=99t do, so that the execution of = the operation is deferred until someone in the group does it. >=20 > # Proposal >=20 > The proposal here is to refactor the protocol from =E2=80=9Cimmediate = mode=E2=80=9D to =E2=80=9Cdeferred mode=E2=80=9D. None of the = underlying tree math changes, just how we talk about it. >=20 > * Add, Remove, and Update become =E2=80=9CProposals=E2=80=9D that = describe an operation, rather than carrying the information to = accomplish the information immediately > * Add =3D =E2=80=9CPlease add ${ClientInitKey}=E2=80=9D > * Update =3D =E2=80=9CPlease replace the leaf at ${index} with = ${key} and blank its direct path=E2=80=9D > * Remove =3D =E2=80=9CPlease remove the member at ${index} > * Each epoch contains a set of proposals, followed by a Commit message > * None of the proposed changes take effect until the Commit = message > * If there are outstanding proposals, you SHOULD send a Commit = before sending a message > * A Commit message contains: > * A description of which proposals were applied and how > * In particular, the committer chooses the positions where new = members are added > * A direct path that KEMs new entropy to the group (basically an = update from the Committer) > * The committer also generates Welcome messages for any new = participants > * With handshake encryption, the Welcome just needs to have the = key for the Commit > * The Commit should commit to the state of the tree after the = proposals are executed (just like handshake messages do today) > * ... so the new joiner doesn't need to see the proposals, just = the Commit >=20 > # Observations >=20 > * In the framework above, there's no need to synchronize proposals, = just Commits > * If the Commit includes the proposals by value or hash, then we can = just run the transcript over the Commit messages, and the proposals will = be included transitively > * Note that proposals can overwrite one another, e.g., an update and a = remove for the same slot > * If we refactor in the above form, an application could reconstruct = what we have now by always sending a (Proposal, Commit) combo > * In fact, one way to view this is as splitting off the Commit from = the current Handshake messages >=20 > # Benefits >=20 > * We get the objectives that we set out to achieve: > * Quiescent groups can just pile up proposals, and Commit before = messaging > * The server can synthesize Add and Remove proposals as long as = clients have a way to authenticate them (e.g.., a designated sender = index for the server) > * There's a certain conceptual simplicity to only having one message = that advances the group state > * With regard to the "ghost account" concerns that DKG raised at the = IETF meeting, this ensures that the proposals to add users are part of = the transcript, thus visible to the group >=20 > # Costs >=20 > * The longer you go before a Commit, the more expensive the Commit is, = since the proposals are all destructive, in the sense that they blank = out parts of the tree > * The logic for a new joiner might get more complicated, since they're = not actually added until the Commit. In particular, you can't send an = Add proposal and have the new member immediately able to transmit, you = have to do a Commit as well. > * At least in the form above, we lose the property that Adds are = constant time, since you would always do an asymmetric ratchet = operation. If this were a problem, you could special-case it (if the = Commit only has Adds...) > * Retry logic might get more complicated; need to wait for a Commit = before I know whether my change made it in > * The protocol gets more verbose since you need the glue to refer to = the proposals from the Commit >=20 > ----- >=20 > Thanks for reading all the way to the bottom! >=20 > Personally, I'm pretty split on this. On the one hand, I think this = can be done pretty elegantly. On the other hand, it does feel more = complex, and I'm worried we're spending a lot of complexity budget on = some fairly niche use cases. On the third hand, I do think we need = server-initiated Add/Remove, and all the approaches that come to mind = end up looking kind of like this >=20 > Happy to have questions / comments here, or if there=E2=80=99s enough = interest, it might be good to have a quick phone call. >=20 > =E2=80=94Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_0B917B4F-E69F-439E-BFE4-AEBEDFA66F8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = big thank you to Richard and Katriel for fleshing this out to this level = of detail!

It is = nice to see that we can potentially address two somewhat orthogonal = issues with one solution. I still maintain that a deferred execution of = =E2=80=9CProposals=E2=80=9D adds a real benefit to the protocol, because = it allows for more flexibility in scenarios where immediate execution is = not needed. I also maintain that the total cost of CPU time and = bandwidth might be less on average with this approach, since I foresee = that Adds and Removes will cancel each other out in groups that are = dormant (i.e. where no messages are exchanged).

I=E2=80=99d like to raise some = practical questions:

 - How are Proposals encrypted? The intuition would be = that we can encrypt them the same way we encrypt handshake messages = today, if the proposals are issued by an existing member of the group. = If they are issued by the server, they could be either in plaintext or = the server could encrypt them using HPKE with the current root public = key of a tree.
 - Can Update Proposals be = issued by anyone but the member itself? If we say yes, the analysis will = be more straight forward, but it is also more limited. If we say no, the = question remains who can issue them. They could be issued by the server = or another member. Right now I don=E2=80=99t see why another member = should be allowed to do so, but I could think of reasons why the server = should be allowed to do so (multi-device context). We should again be = very careful w.r.t the ghost user scenario in order to avoid the = possibility that the server can sneak in a malicious participant that = way.
 - At the January interim we also talked = about the possibility for members that were added by the server to send = messages right away by encrypting them to the root of the tree. I wonder = if we would pursue this idea and how we would do it in practice. The = idea of instant communication is certainly nice, but it would mean that = messages would be sent to the group before a Commit has happened. This = in turn means that a member that is supposed to be evicted (through a = erred Remove) could still potentially have the key material to decrypt = those messages. Specifically, this would happen in the sequence {Add D, = Remove B}, D would encrypt messages to the group that can still be read = by B until the commit is issued and B is properly evicted.
 - If we go for the Proposals concept, we should = probably make it very clear that clients should issue and execute = Commits as soon as possible. Concrete example: if a client determines it = has enough processing power and enough bandwidth, it should = pre-emptively issue a Commit in groups with pending Proposals in order = to heal the tree somewhat and restore all security properties. I can = however see that such a strategy is not uncontroversial, so I=E2=80=99d = be happy to hear some arguments of why we shouldn=E2=80=99t do = this.

Raphael

On 23 Aug 2019, at 00:17, Richard Barnes <rlb@ipv.sx> wrote:

BTW, big thanks to Raphael for setting us down this path, and = to Katriel for talking this through with me earlier this week (and for = coming up with the Welcome-by-Committer part).

On Thu, Aug 22, 2019 at 6:16 PM Richard Barnes = <rlb@ipv.sx> = wrote:
Hey = all,

I=E2=80=99d like to pose a question to = the group of whether we should do =E2=80=9Claziness=E2=80=9D or not. =   The complete form will be long, but the short version is: Do we = care enough about DH overhead and server-initiated operations to do a = pretty significant refactor and possibly add some complexity to the = protocol?

I would like to get a go/no-go on this idea before writing a = PR, since it's going to be a big PR.  And it would be helpful to = make that decision in the next week or two, so that we can get the edits = done and a new version out a bit in advance of the interim.  So = let's get this party started!

# Objectives

The overall = goal is to meet two objectives:

1.. Not = requiring DH operations in groups where no messaging is happening
2. Allow some flavor of server-initiated Add and Remove

The first of these objectives was raised by = Raphael some time ago; see his presentation at the January interim for = more details [1].  The second has been a long-outstanding feature = request, from Facebook and Cisco, among others.

The useful insight is that both of these require deferred = operations.  In the first case, you want to defer DH operations = until someone wants to send a message.  In the second case, you = might have the server propose an operation that it can=E2=80=99t do, so = that the execution of the operation is deferred until someone in the = group does it.

# Proposal

The proposal here is to refactor the protocol from = =E2=80=9Cimmediate mode=E2=80=9D to =E2=80=9Cdeferred mode=E2=80=9D. = None of the underlying tree math changes, just how we talk about it.

* Add, Remove, and Update become = =E2=80=9CProposals=E2=80=9D that describe an operation, rather than = carrying the information to accomplish the information immediately
    * Add =3D =E2=80=9CPlease add = ${ClientInitKey}=E2=80=9D
    * Update =3D = =E2=80=9CPlease replace the leaf at ${index} with ${key} and blank its = direct path=E2=80=9D
    * Remove =3D =E2=80=9CPle= ase  remove the member at ${index}
* Each epoch = contains a set of proposals, followed by a Commit message
    * None of the proposed changes take effect = until the Commit message
    * If there are = outstanding proposals, you SHOULD send a Commit before sending a = message
* A Commit message contains:
    * A description of which proposals were applied = and how
    * In particular, the committer chooses the = positions where new members are added
    * A = direct path that KEMs new entropy to the group (basically an update from = the Committer)
* The committer also generates Welcome = messages for any new participants
  =   * With handshake encryption, the Welcome just needs to have the = key for the Commit
    * The Commit = should commit to the state of the tree after the proposals are executed = (just like handshake messages do today)
    * ... so the new joiner doesn't need to = see the proposals, just the Commit

# = Observations

* In the = framework above, there's no need to synchronize proposals, just = Commits
* If the Commit includes the proposals by = value or hash, then we can just run the transcript over the Commit = messages, and the proposals will be included transitively
* Note that proposals can overwrite one = another, e.g., an update and a remove for the same slot
* If we refactor in the above form, an = application could reconstruct what we have now by always sending a = (Proposal, Commit) combo
* In fact, one way to view = this is as splitting off the Commit from the current Handshake = messages

# = Benefits

* We get the objectives that we set out to achieve:
    * Quiescent groups can just pile up = proposals, and Commit before messaging
    * The server can synthesize Add and Remove = proposals as long as clients have a way to authenticate them (e.g.., a = designated sender index for the server)
* There's a certain conceptual simplicity to only having one = message that advances the group state
* With regard = to the "ghost account" concerns that DKG raised at the IETF meeting, = this ensures that the proposals to add users are part of the transcript, = thus visible to the group

# = Costs

*= The longer you go before a Commit, the more expensive the Commit is, = since the proposals are all destructive, in the sense that they blank = out parts of the tree
* The logic = for a new joiner might get more complicated, since they're not actually = added until the Commit.  In particular, you can't send an Add = proposal and have the new member immediately able to transmit, you have = to do a Commit as well.
* At least = in the form above, we lose the property that Adds are constant time, = since you would always do an asymmetric ratchet operation.  If this = were a problem, you could special-case it (if the Commit only has = Adds...)
* Retry logic might get = more complicated; need to wait for a Commit before I know whether my = change made it in
* The protocol gets more verbose = since you need the glue to refer to the proposals from the = Commit

-----

Thanks for reading all the way to the bottom!

Personally, I'm pretty split on this.  On the one hand, = I think this can be done pretty elegantly.  On the other hand, it = does feel more complex, and I'm worried we're spending a lot of = complexity budget on some fairly niche use cases.  On the third = hand, I do think we need server-initiated Add/Remove, and all the = approaches that come to mind end up looking kind of like this

Happy to have questions / comments here, or if there=E2=80=99s = enough interest, it might be good to have a quick phone call.

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

= --Apple-Mail=_0B917B4F-E69F-439E-BFE4-AEBEDFA66F8B-- From nobody Fri Aug 23 03:24:48 2019 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 BC768120804 for ; Fri, 23 Aug 2019 03:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=wire-com.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 ITNc_lTfu72k for ; Fri, 23 Aug 2019 03:24:45 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 6125E1200B6 for ; Fri, 23 Aug 2019 03:24:45 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id p74so8413634wme.4 for ; Fri, 23 Aug 2019 03:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ke6uuO8FIMqkLSA4e6gPa1jwzrYDQqo7VE0W8grleKk=; b=sceDZD77uqyl9bt7ilfuxOBwNkjbiP8ybY0TEgfdSBEYunHInQsyxoKOoEgzJjlCCU 4GviCT1suHQlUURv6UVue14nx1jmv2htDyndt3ZFWcj7TnlPXAxYzMoAaBbb7rNDFuqG 2SbIh7TgH1nWT4Geqmczxt6XStTVLNfbnH7J3Hvlg8ukj+gKmlna8tu31AmgL5yB6p2T qtaXUqXTabdNNFcMmFkHtvPdJXijIe3G3SWkNBUi/dAbCcTPsjHVhhJsnN/SFyNO8fGD 0RlMTkZofDLZ7fz5VPeEVvS97Hnhxxqz0gzIA7fhg4ihuM6nj69Xgv8P7ed7GLVsKcUi YwSg== 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=ke6uuO8FIMqkLSA4e6gPa1jwzrYDQqo7VE0W8grleKk=; b=mRbxa54E1UlEiIw74501gywxKTMa9hdF0vGprm3YF2BGUrerS91bRFrvAKHV/70Zk1 wcg4QEc0U+BDQhIb/IgBoNu3emuvTklZrbHXa6KWDMKLq2AX6I/ak1Qd3aF0rupbb9lz 6nAxeycxR7Ofzu2jIXHmZ0FZ2YfRKaGMEq7MvzjqNZLLEZ7xONjCLiS4XFdbsd/NW9WY +Cxrdr/ZPuretGQC8v3xxzkzrXUvY1+mEmMTiRG3EATZnV/SNHVbbM0+XbHXBUtiO5H9 S2spX5GQkbt9x/YiOdfviqKHuKWy0Pl3t1RmM3Z5An0wa69ywAq9nrObZLWTFO66mkpO TAgQ== X-Gm-Message-State: APjAAAXodMlnDRQOCPmasePzrr7qDHCIw/+yoQN5YlxUsIyp4Dabd2Ug t4CjYdZeCDdaY8k6r2oPujX7T2o9Epo= X-Google-Smtp-Source: APXvYqzhkrkuM50RX+qig5nvqNQwTZ04NSqpgzeajmrV7oNFvbkUzBj6S9+qg/2GeSEMCuMcBYoBEQ== X-Received: by 2002:a05:600c:214c:: with SMTP id v12mr4412576wml.28.1566555883663; Fri, 23 Aug 2019 03:24:43 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id e6sm2698011wrw.35.2019.08.23.03.24.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 03:24:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Raphael Robert In-Reply-To: Date: Fri, 23 Aug 2019 12:24:41 +0200 Cc: Richard Barnes , Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Farrell X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 10:24:47 -0000 Right now, Add and Remove handshake messages have to be signed by an = existing member of the group. There is no way for the server to make any = changes to the group membership. > On 23 Aug 2019, at 11:08, Stephen Farrell = wrote: >=20 > Signed PGP part >=20 > Sorry for not following mls in detail but can you explain > how: >=20 > On 22/08/2019 23:16, Richard Barnes wrote: >> 2. Allow some flavor of server-initiated Add and Remove >=20 > ...compares to the status quo ante? >=20 > Thanks, > S. > <0x5AB2FAF17B172BEA.asc> >=20 >=20 From nobody Fri Aug 23 04:26:43 2019 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 39669120811 for ; Fri, 23 Aug 2019 04:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 0xSpseUtV3rQ for ; Fri, 23 Aug 2019 04:26:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6D41200B2 for ; Fri, 23 Aug 2019 04:26:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ED90ABE24; Fri, 23 Aug 2019 12:26:34 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lGhLbHGm7Mg; Fri, 23 Aug 2019 12:26:34 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8AD69BE20; Fri, 23 Aug 2019 12:26:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566559594; bh=+j7c130MeehhDT29HH55Y9g2gKbiKSJuZ6Ybt/nW6/E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=b7urtukGFjtw8Y2SbugSo47zHxN1aMZ5xzC9nEsYwylXaBBDPmvE8R3gibzsJCxbl d0nvkgkyXr/Ue3rGTJuixfdGzQ7+dPs7v2jX33FfypnvELJY3ulYZ2r+/fWvqUPT+j K017VW9Z1jHrS/jIsrB8ili7F3s0tzafGCxCOawA= To: Raphael Robert Cc: Richard Barnes , Messaging Layer Security WG References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> Date: Fri, 23 Aug 2019 12:26:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="33W6FSYqMFGHcawR8z2j6R3YFnGUJvCvq" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 11:26:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --33W6FSYqMFGHcawR8z2j6R3YFnGUJvCvq Content-Type: multipart/mixed; boundary="u8p8D2G3WAXdUFUrSY5gK0MTNhs1e7nVN"; protected-headers="v1" From: Stephen Farrell To: Raphael Robert Cc: Richard Barnes , Messaging Layer Security WG Message-ID: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> Subject: Re: [MLS] Proposal: Proposals (was: Laziness) References: In-Reply-To: --u8p8D2G3WAXdUFUrSY5gK0MTNhs1e7nVN Content-Type: multipart/mixed; boundary="------------25A6DF2E400910AEE569876A" Content-Language: en-GB This is a multi-part message in MIME format. --------------25A6DF2E400910AEE569876A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 23/08/2019 11:24, Raphael Robert wrote: > Right now, Add and Remove handshake messages have to be signed by an > existing member of the group. There is no way for the server to make > any changes to the group membership. Thanks. As you note in your other mail, that seems a bit concerning, from a potentially ghostly point of view. My initial reaction (again with the "benefit" of not having kept up to date with the drafts:-) is that a service using MLS could put itself in a position to do the same thing within the application layer if necessary, so it'd seem better for it not to be a feature of the MLS protocol. I've no opinion on the general idea of proposals, my concern is only really about a non-member of the group (the server or anyone else) being able to control group membership like that, for what I guess would effectively be all applications using MLS. Cheers, S. >=20 >> On 23 Aug 2019, at 11:08, Stephen Farrell >> wrote: >>=20 >> Signed PGP part >>=20 >> Sorry for not following mls in detail but can you explain how: >>=20 >> On 22/08/2019 23:16, Richard Barnes wrote: >>> 2. Allow some flavor of server-initiated Add and Remove >>=20 >> ...compares to the status quo ante? >>=20 >> Thanks, S. <0x5AB2FAF17B172BEA.asc> >>=20 >>=20 >=20 >=20 --------------25A6DF2E400910AEE569876A Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------25A6DF2E400910AEE569876A-- --u8p8D2G3WAXdUFUrSY5gK0MTNhs1e7nVN-- --33W6FSYqMFGHcawR8z2j6R3YFnGUJvCvq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1fzWcACgkQWrL68XsX K+rQnhAAsA/kO4ahICm5LarJJQglAe+VwaM3ZmZqzJC4/zstoTG4FGSEWGF6F3+Q ouHoGG65WC24k4iP4NCvhD4FVjtIHK5JlbZwvz14gZDE2Td7NFioUiKiNEQHKQr3 e4bSpykKPsAfSLGWfiVfhOY8V8kYnqN8fEt/w/YtapYlwPOXs61eV33XRXxHWfW6 5ltu8P2dF4djIoapYnrAHK0CtCSYXj2quwn+7ImaInzrgtsM8Ejv05COEgJytiow zMHwD405kfJH4ygE2Z4hzp/wrSF44Yr2SvJBIBvmV4tHz0rwhzCknnC52ZCTieFG ugliv9lrtVEP5H3z9rN8VBEoy6dXHVwZj76S58mfGNvro7JxgzzRVir815YlsHLA 5LGQikU6uZgfGx8084pDijhB2G5dmJ0V3kglCCI0dDUhRvxdxL0uRxuXlbhl4/sM G9te4VBVKVmeJWhgseCV7vaeUQKHSBi/CrAyyAR6hxQVJTKK93MdMHCJcOWKttps opywAUmduFY/PX/kTPwdoFrkANK8pLGah+iFmSSjIFaiYOm3gjw+eIIG4Fw+YfmI 5oUjfGwDmKXxhQVzjjjRvNIrqqe6o2Y2vumA5kSDWk1uKHvWSJfM4bNTCzwP1xBx DCg1Qt/nPLI6ZaR0jYUu47JfrZS49kAnwBnxhHQ/3ubyLsayOOQ= =8sly -----END PGP SIGNATURE----- --33W6FSYqMFGHcawR8z2j6R3YFnGUJvCvq-- From nobody Fri Aug 23 05:18:03 2019 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 499DB120819 for ; Fri, 23 Aug 2019 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_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=wire-com.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 5mh1zQz6nTfP for ; Fri, 23 Aug 2019 05:17:57 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 7BACD120823 for ; Fri, 23 Aug 2019 05:17:57 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id c5so8702119wmb.5 for ; Fri, 23 Aug 2019 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=u9gqW/Gi62jKYWAhjLAnvGlDjmHriIs8ZTC4hm5QSjU=; b=U7nbKa5ed4C1DDGgC8zdjqe8jBR9a7UXyvueCrUoi7ZBkjLRjuSobpSwd7vBEmpOZF vsaI4kYl1AbS8simz2e1U1H5RzqUqX7dLsEYZgskh8XpENlq17T6OCRu++Yqv0/5ONm/ H7w75QLuMYUe5BRXhZGXF2Mx6sNifRqIGCC9PjETvkXKMb3AEhwmL88ER1VNzSrlIkRV y19lSbinX0UBe5t+qgLhtEIRmip38QrU9su09mE/qIxB29Dr/jtGsZh20paYL11nV68s z+dDHHt3/zs8/fNy0EwjNr4qIed27irg1itK0sc/+ij5wgpd/2yw/ctgNmxytZCbY/25 ND7w== 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=u9gqW/Gi62jKYWAhjLAnvGlDjmHriIs8ZTC4hm5QSjU=; b=NatCUS3y/htV+dpCsGEgl02NNO2XsO/EdqeeK1J3mePOc3SubNhjS5gr7DS5hdHxlz UcDX3g/8q2HAekhDQIagmmuOaXl26Q1g0ApuBW2IQDwgNLbtrehU9UmZ0MJuni9GNZdU JTjAteRbs9T9tjz42rgT02S0OgbDbThVa6Kx94C6efFgqpFQrQfRV6idqlE4rzQUP6su ZNqjTRs5lvk/4NxQrUTvtnB+HDuzxPJGym9FR1Ezy1xcbwS5z7jV+S66q6nSvzxNvuNI nNvv5MPwJK5mP3fugwU8akM3VJZFNQGTPtqtzL+LTPvo/WARzVo43K9jy5MxA1Y9+DtN 34/A== X-Gm-Message-State: APjAAAX43vt9A0vEAVsd45vkNnqVEpmXxBgjyatmAJc/s4J+fx5nkkr6 avrIlgdnmvp0Up7lAqhwDVxWSg== X-Google-Smtp-Source: APXvYqzzF1eBoK8rxSWGhog/hKDMHdDG4qdI/RY6hCre8/8OILNBWVL3ZwaZ8tAQNiYg/uxejim06g== X-Received: by 2002:a1c:8094:: with SMTP id b142mr4596446wmd.110.1566562675663; Fri, 23 Aug 2019 05:17:55 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id w13sm6226861wre.44.2019.08.23.05.17.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Aug 2019 05:17:54 -0700 (PDT) From: Raphael Robert Message-Id: <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_35E11ABF-3927-4BBF-8688-42FE48031F4B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 23 Aug 2019 14:17:53 +0200 In-Reply-To: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> Cc: Richard Barnes , Messaging Layer Security WG To: Stephen Farrell References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 12:18:01 -0000 --Apple-Mail=_35E11ABF-3927-4BBF-8688-42FE48031F4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The ghost user scenario is precisely what we want to avoid. In = Richard=E2=80=99s Proposals draft, every Proposal has to be validated by = a Commit message, and the latter can only be issued by an existing = member of the group. Therefore the server still cannot control the group = membership, it can rather only make proposals on how the membership list = should be modified. Naturally we need to make sure that everything works = as intended. > On 23 Aug 2019, at 13:26, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 23/08/2019 11:24, Raphael Robert wrote: >> Right now, Add and Remove handshake messages have to be signed by an >> existing member of the group. There is no way for the server to make >> any changes to the group membership. >=20 > Thanks. As you note in your other mail, that seems a > bit concerning, from a potentially ghostly point of > view. My initial reaction (again with the "benefit" > of not having kept up to date with the drafts:-) is > that a service using MLS could put itself in a position > to do the same thing within the application layer if > necessary, so it'd seem better for it not to be a > feature of the MLS protocol. >=20 > I've no opinion on the general idea of proposals, my > concern is only really about a non-member of the group > (the server or anyone else) being able to control > group membership like that, for what I guess would > effectively be all applications using MLS. >=20 > Cheers, > S. >=20 >>=20 >>> On 23 Aug 2019, at 11:08, Stephen Farrell >>> wrote: >>>=20 >>> Signed PGP part >>>=20 >>> Sorry for not following mls in detail but can you explain how: >>>=20 >>> On 22/08/2019 23:16, Richard Barnes wrote: >>>> 2. Allow some flavor of server-initiated Add and Remove >>>=20 >>> ...compares to the status quo ante? >>>=20 >>> Thanks, S. <0x5AB2FAF17B172BEA.asc> >>>=20 >>>=20 >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> --Apple-Mail=_35E11ABF-3927-4BBF-8688-42FE48031F4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = ghost user scenario is precisely what we want to avoid. In Richard=E2=80=99= s Proposals draft, every Proposal has to be validated by a Commit = message, and the latter can only be issued by an existing member of the = group. Therefore the server still cannot control the group membership, = it can rather only make proposals on how the membership list should be = modified. Naturally we need to make sure that everything works as = intended.

On 23 Aug 2019, at 13:26, Stephen Farrell = <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 23/08/2019 11:24, Raphael = Robert wrote:
Right = now, Add and Remove handshake messages have to be signed by an
existing member of the group. There is no way for the server = to make
any changes to the group membership.

Thanks. As you note in your other mail, that seems = a
bit = concerning, from a potentially ghostly point of
view. My initial reaction (again = with the "benefit"
of not having kept up to date with the drafts:-) is
that a service using MLS could = put itself in a position
to do the same thing within the application layer = if
necessary, so = it'd seem better for it not to be a
feature of the MLS protocol.

I've no opinion on the general idea of proposals, = my
concern is = only really about a non-member of the group
(the server or anyone else) = being able to control
group membership like that, for what I guess would
effectively be all applications = using MLS.

Cheers,
S.


On 23 Aug 2019, at = 11:08, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:

Signed PGP part

Sorry for not = following mls in detail but can you explain how:

On 22/08/2019 23:16, Richard Barnes wrote:
2. Allow some flavor of = server-initiated Add and Remove

...compares to the status quo ante?

Thanks, S. <0x5AB2FAF17B172BEA.asc>




<0x5AB2FAF17= B172BEA.asc>

= --Apple-Mail=_35E11ABF-3927-4BBF-8688-42FE48031F4B-- From nobody Fri Aug 23 05:26:11 2019 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 75C2A120B95 for ; Fri, 23 Aug 2019 05:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie 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 Q0TiwAAHdsob for ; Fri, 23 Aug 2019 05:26:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9261120832 for ; Fri, 23 Aug 2019 05:26:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D77ACBE2C; Fri, 23 Aug 2019 13:26:04 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6arNuoAIGIh; Fri, 23 Aug 2019 13:26:04 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8693ABE24; Fri, 23 Aug 2019 13:26:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566563164; bh=7MUiQUtdLFtXMYYR5Y3uSN/t0yFk7iDkFT22X0w772E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fPz/vwBnrloSVAnFJGRQraQlKbiYmH9XpzO/ujqXFfzrzbHXy6K1Mnay5POKwEA+w 1B+00dx+rQfftF9kCq0TZYEv6U7FTXrCvVORz0j/RPwldSsjclAx8WaaizHN8VRHAu mn1Sc9171GYJ/uAR8N+CFsLr8QsO1bW4ZHlTfiLA= To: Raphael Robert Cc: Richard Barnes , Messaging Layer Security WG References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 23 Aug 2019 13:26:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OI32GNiPYyjJ6MK7y5d7LuQz1sTu9i6TA" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 12:26:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OI32GNiPYyjJ6MK7y5d7LuQz1sTu9i6TA Content-Type: multipart/mixed; boundary="kTrJIclL6OOin5C9qqJAPcIH9ID23Ig8r"; protected-headers="v1" From: Stephen Farrell To: Raphael Robert Cc: Richard Barnes , Messaging Layer Security WG Message-ID: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> In-Reply-To: <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> --kTrJIclL6OOin5C9qqJAPcIH9ID23Ig8r Content-Type: multipart/mixed; boundary="------------9F48FEE1F152A08163ACEAA7" Content-Language: en-GB This is a multi-part message in MIME format. --------------9F48FEE1F152A08163ACEAA7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 23/08/2019 13:17, Raphael Robert wrote: > The ghost user scenario is precisely what we want to avoid. In > Richard=E2=80=99s Proposals draft, every Proposal has to be validated b= y a > Commit message, and the latter can only be issued by an existing > member of the group. Therefore the server still cannot control the > group membership, it can rather only make proposals on how the > membership list should be modified. Naturally we need to make sure > that everything works as intended. Sure, I get that. My concern is that I'm not clear how such proposals could meaningfully be handled by members in general - it seems like it could be quite a footgun. Cheers, S. >=20 >> On 23 Aug 2019, at 13:26, Stephen Farrell >> wrote: >>=20 >>=20 >> Hiya, >>=20 >> On 23/08/2019 11:24, Raphael Robert wrote: >>> Right now, Add and Remove handshake messages have to be signed by >>> an existing member of the group. There is no way for the server >>> to make any changes to the group membership. >>=20 >> Thanks. As you note in your other mail, that seems a bit >> concerning, from a potentially ghostly point of view. My initial >> reaction (again with the "benefit" of not having kept up to date >> with the drafts:-) is that a service using MLS could put itself in >> a position to do the same thing within the application layer if=20 >> necessary, so it'd seem better for it not to be a feature of the >> MLS protocol. >>=20 >> I've no opinion on the general idea of proposals, my concern is >> only really about a non-member of the group (the server or anyone >> else) being able to control group membership like that, for what I >> guess would effectively be all applications using MLS. >>=20 >> Cheers, S. >>=20 >>>=20 >>>> On 23 Aug 2019, at 11:08, Stephen Farrell=20 >>>> wrote: >>>>=20 >>>> Signed PGP part >>>>=20 >>>> Sorry for not following mls in detail but can you explain how: >>>>=20 >>>> On 22/08/2019 23:16, Richard Barnes wrote: >>>>> 2. Allow some flavor of server-initiated Add and Remove >>>>=20 >>>> ...compares to the status quo ante? >>>>=20 >>>> Thanks, S. <0x5AB2FAF17B172BEA.asc> >>>>=20 >>>>=20 >>>=20 >>>=20 >> <0x5AB2FAF17B172BEA.asc> >=20 >=20 >=20 > _______________________________________________ MLS mailing list=20 > MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >=20 --------------9F48FEE1F152A08163ACEAA7 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------9F48FEE1F152A08163ACEAA7-- --kTrJIclL6OOin5C9qqJAPcIH9ID23Ig8r-- --OI32GNiPYyjJ6MK7y5d7LuQz1sTu9i6TA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1f21sACgkQWrL68XsX K+ou7g//YlLxkUh/C9cgOsC+iS27OMtgf/yMDRAQWw2ZBXvc9OCUN4EcrzbuA3C0 OiPHjibuz/8FWSbGFH77EQlNSRFc8vdohD4LH25jx2C2pQW7wecnady3w7GFMEBN ZHZhg43RHMPuSc3VInbGrBxO8ZDz1mSE+67NXI5xk4ROML8n2bAmv8gxPxuHREbA XiXnBYyoUoVNNXD2XfQfCuJ7r2SHdEkbb84b0JW4iVNN9po+POKE7uTjJaoMQhgj Lo+JjKb0sZsLK/xiS5d+ERUgohkC4CUrYMiV59yc77jXW1ZoilM+pHNGL0DHO/TB 2WJK6RrgAYs3ShMXRbmnyW7WHIt79+htY1MlZFa0TMmV8Ifo7tkK8ach+pMQLyTC cClxHWlvl7EOQGdhZHYViKvcOZkEwORVJ9p7LgvwDdmysBNev3giZnD0VIzWzIpv Hf4Cv9gTXsq1UwWZFFCz+BgtokHGtJkJw8TDgtGOvBBeH8k7ihhsClZtNRyrOZob Q1Rq1x9BxauggBDwfh5/IV/2IzVm3SSVpyT01YpN2CNeHyF8mE20Kfmv2bFU4I8F GdgqWEIxuDcmuPYtwX7g2qJb7xD+b3pdKvmzfIY2hh9lWRTm6rBn7u3nsgOghjlU NBSPbQbCnntUj6BVhbv4EyexBswpf8FBAuaMFNtSzoQC6EK2InY= =EOyI -----END PGP SIGNATURE----- --OI32GNiPYyjJ6MK7y5d7LuQz1sTu9i6TA-- From nobody Fri Aug 23 07:11:03 2019 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 D08681200E9 for ; Fri, 23 Aug 2019 07:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZH2-hyQkozr for ; Fri, 23 Aug 2019 07:10:59 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 B630912009C for ; Fri, 23 Aug 2019 07:10:59 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id t24so7054151oij.13 for ; Fri, 23 Aug 2019 07:10:59 -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=Gi+FGQD/3F3rbP3T8M/2s/RMobEPCAC3fJRhxHrykhM=; b=f5+X1sCNI3OEY2pjFmeg37Qfyvk9zw52taI/sX4mi9IdgE51cAYXRcpsG3bBBJRLHq INybBb9tuDcO9WCaWNbxyMhl1qx9e/7/Rj4SXc2bwxKZLNsZbhynhKfyULTUE3Btn70p 45kiRl1Jb1oFA+9pFFZ4hUQUNG3H3uepLBNpFU1y4rAtN84p+/BwTdJDH59hU4JBo/kk dxJm/mgPf4RMadi2Y10N/FChOBaT/YhaO4nt6kZGboTQAy+rUHXHtNpAsoSJYC96rRL+ 1092kBQHfg6VrgNPED3A2idyurdwRYyx3WbskJ/mpsgcQXwQ/0XlbPxa2axJ1pgMRTqn Gy9g== 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=Gi+FGQD/3F3rbP3T8M/2s/RMobEPCAC3fJRhxHrykhM=; b=dTaWTkNKTgczHFlUXuZXSfTtfIj5sw/IWAB4XpsaZUeitctrWbDyCul6Af4aTe6i22 wSXL5UpMfutZqrfSUc9P7ABNclXt802NP1fWZrdaiOkhWwu2WBcPP1bkO8+Mw02WToQ6 LpA/Pp4vEw/AClIS8qJ9oD5Cl0rbnsUnTqtgTSQILcdhTeB6mz/9XMlXBBs8PuMtr6KA s+IAYQ+GiAn54eRjAfdg90mdSExH27kJbKDjBPdjpiMsEmIwe1qHg66U6n8U8HCRUKJe QzLQCkYgol4vJ9krXj0jV5THRJl5FfIaMeW2Hp2ztZ9OXvsJcWsqqLFmo62SsBLnverQ 61Aw== X-Gm-Message-State: APjAAAVkItdNk2tIipXlFV/rnRsNQ50VIpw9CKADVTekzUEFqhq/9CBG jZeY+U4H4HI85DQ5UThWLiTQ9FC33Rr9a+bpyhZucA== X-Google-Smtp-Source: APXvYqwggzuWOWRf/Ikxz+XhgeY9XM46dE1EZDmMUnze7xKxmvZxMVBD3Dq7pmTkepl6M12rOcWpqCvz1nDw54vnSGE= X-Received: by 2002:aca:53cf:: with SMTP id h198mr3120695oib.169.1566569458748; Fri, 23 Aug 2019 07:10:58 -0700 (PDT) MIME-Version: 1.0 References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> In-Reply-To: From: Richard Barnes Date: Fri, 23 Aug 2019 10:10:40 -0400 Message-ID: To: Stephen Farrell Cc: Raphael Robert , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000001ae6270590c96075" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 14:11:02 -0000 --0000000000001ae6270590c96075 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 23, 2019 at 8:26 AM Stephen Farrell wrote: > > Hiya, > > On 23/08/2019 13:17, Raphael Robert wrote: > > The ghost user scenario is precisely what we want to avoid. In > > Richard=E2=80=99s Proposals draft, every Proposal has to be validated b= y a > > Commit message, and the latter can only be issued by an existing > > member of the group. Therefore the server still cannot control the > > group membership, it can rather only make proposals on how the > > membership list should be modified. Naturally we need to make sure > > that everything works as intended. > > Sure, I get that. My concern is that I'm not clear how > such proposals could meaningfully be handled by members > in general - it seems like it could be quite a footgun. > It was pointed out in the discussion at IETF 105 that given that vendors seem to want server-initiated Add/Remove, they will do it somehow, either using a mechanism in the protocol, or as you say, using something at the application layer. It seems to me that between those two options, having it in the protocol is the better one. It at least provides clear accountability for who is in the group and how they were added: The records of who made the proposal and who committed the proposal are both in the transcript, and thus have to be revealed to everyone. In the application-layer alternative, you'd still have the commiter in the transcript, but the server could just whisper to one participant, and nobody else would need to know that the server had anything to do with the transaction. I'm not clear on what you mean by "meaningfully handled by members". Even in the Proposal / server-initiated-in-the-protocol case, messages from the server are authenticated, and endpoints should be expected to apply authorization policy to them. (The presumption would be that the clients in a given environment would be configured to trust their servers.) In addition, like current Add messages, Add proposals would have the full ClientInitKey for the proposed member, which means that members can see their credential and possibly make a decision based on that. So there are two authenticated identities to use for authorization decisions, (1) the server / proposer's identity, and (2) the new member's identity. There are some sharp edges here, but that will be true with any server-initiated case (whether or not in this document), and I think the proposal here provides good guard rails to guide people to better solutions= . --Richard > > Cheers, > S. > > > > >> On 23 Aug 2019, at 13:26, Stephen Farrell > >> wrote: > >> > >> > >> Hiya, > >> > >> On 23/08/2019 11:24, Raphael Robert wrote: > >>> Right now, Add and Remove handshake messages have to be signed by > >>> an existing member of the group. There is no way for the server > >>> to make any changes to the group membership. > >> > >> Thanks. As you note in your other mail, that seems a bit > >> concerning, from a potentially ghostly point of view. My initial > >> reaction (again with the "benefit" of not having kept up to date > >> with the drafts:-) is that a service using MLS could put itself in > >> a position to do the same thing within the application layer if > >> necessary, so it'd seem better for it not to be a feature of the > >> MLS protocol. > >> > >> I've no opinion on the general idea of proposals, my concern is > >> only really about a non-member of the group (the server or anyone > >> else) being able to control group membership like that, for what I > >> guess would effectively be all applications using MLS. > >> > >> Cheers, S. > >> > >>> > >>>> On 23 Aug 2019, at 11:08, Stephen Farrell > >>>> wrote: > >>>> > >>>> Signed PGP part > >>>> > >>>> Sorry for not following mls in detail but can you explain how: > >>>> > >>>> On 22/08/2019 23:16, Richard Barnes wrote: > >>>>> 2. Allow some flavor of server-initiated Add and Remove > >>>> > >>>> ...compares to the status quo ante? > >>>> > >>>> Thanks, S. <0x5AB2FAF17B172BEA.asc> > >>>> > >>>> > >>> > >>> > >> <0x5AB2FAF17B172BEA.asc> > > > > > > > > _______________________________________________ MLS mailing list > > MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls > > > --0000000000001ae6270590c96075 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 23, 2019 at 8:26 AM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 23/08/2019 13:17, Raphael Robert wrote:
> The ghost user scenario is precisely what we want to avoid. In
> Richard=E2=80=99s Proposals draft, every Proposal has to be validated = by a
> Commit message, and the latter can only be issued by an existing
> member of the group. Therefore the server still cannot control the
> group membership, it can rather only make proposals on how the
> membership list should be modified. Naturally we need to make sure
> that everything works as intended.

Sure, I get that. My concern is that I'm not clear how
such proposals could meaningfully be handled by members
in general - it seems like it could be quite a footgun.

It was pointed out in the discussion at IETF 105 that give= n that vendors seem to want server-initiated Add/Remove, they will do it so= mehow, either using a mechanism in the protocol, or as you say, using somet= hing at the application layer.

It seems to me that= between those two options, having it in the protocol is the better one.=C2= =A0 It at least provides clear accountability for who is in the group and h= ow they were added: The records of who made the proposal and who committed = the proposal are both in the transcript, and thus have to be revealed to ev= eryone.=C2=A0 In the application-layer alternative, you'd still have th= e commiter in the transcript, but the server could just whisper to one part= icipant, and nobody else would need to know that the server had anything to= do with the transaction.

I'm not clear on wha= t you mean by "meaningfully handled by members".=C2=A0 Even in th= e Proposal / server-initiated-in-the-protocol case, messages from the serve= r are authenticated, and endpoints should be expected to apply authorizatio= n policy to them.=C2=A0 (The presumption would be that the clients in a giv= en environment would be configured to trust their servers.)=C2=A0 In additi= on, like current Add messages, Add proposals would have the full ClientInit= Key for the proposed member, which means that members can see their credent= ial and possibly make a decision based on that.=C2=A0 So there are two auth= enticated identities to use for authorization decisions, (1) the server / p= roposer's identity, and (2) the new member's identity.
There are some sharp edges here, but that will be true with an= y server-initiated case (whether or not in this document), and I think the = proposal here provides good guard rails to guide people to better solutions= .

--Richard


<= /div>
=C2=A0

Cheers,
S.

>
>> On 23 Aug 2019, at 13:26, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>> Hiya,
>>
>> On 23/08/2019 11:24, Raphael Robert wrote:
>>> Right now, Add and Remove handshake messages have to be signed= by
>>> an existing member of the group. There is no way for the serve= r
>>> to make any changes to the group membership.
>>
>> Thanks. As you note in your other mail, that seems a bit
>> concerning, from a potentially ghostly point of view. My initial >> reaction (again with the "benefit" of not having kept up= to date
>> with the drafts:-) is that a service using MLS could put itself in=
>> a position to do the same thing within the application layer if >> necessary, so it'd seem better for it not to be a feature of t= he
>> MLS protocol.
>>
>> I've no opinion on the general idea of proposals, my concern i= s
>> only really about a non-member of the group (the server or anyone<= br> >> else) being able to control group membership like that, for what I=
>> guess would effectively be all applications using MLS.
>>
>> Cheers, S.
>>
>>>
>>>> On 23 Aug 2019, at 11:08, Stephen Farrell
>>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>>
>>>> Signed PGP part
>>>>
>>>> Sorry for not following mls in detail but can you explain = how:
>>>>
>>>> On 22/08/2019 23:16, Richard Barnes wrote:
>>>>> 2. Allow some flavor of server-initiated Add and Remov= e
>>>>
>>>> ...compares to the status quo ante?
>>>>
>>>> Thanks, S. <0x5AB2FAF17B172BEA.asc>
>>>>
>>>>
>>>
>>>
>> <0x5AB2FAF17B172BEA.asc>
>
>
>
> _______________________________________________ MLS mailing list
> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>
--0000000000001ae6270590c96075-- From nobody Fri Aug 23 07:21:21 2019 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 32A7A120C1C for ; Fri, 23 Aug 2019 07:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 nTVQVZOPhjeP for ; Fri, 23 Aug 2019 07:21:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D98120C50 for ; Fri, 23 Aug 2019 07:21:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E1ADBBE2C; Fri, 23 Aug 2019 15:21:07 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkKlJdjTIfqE; Fri, 23 Aug 2019 15:21:07 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09A1FBE24; Fri, 23 Aug 2019 15:21:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1566570067; bh=/IxOF7LXa0ahsKFKObiuHGeIawEg3I8L+/VO/r3dTbc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=z1FNSjhiyVDGVfRZeCvwY6J86KH0kGuCEVlMinj3xNLcLEE+awhfTwwZrv4CKrVZH NbNnKZENvnQngJc6zevQ4dnOEvG1XPY2t4i21f4SnwGOejPtM4gHkcfB3tqX8Ud12T oTWVNvO13BRzKSzbJwDFyWXklc8RpIzccSGQczQg= To: Richard Barnes Cc: Messaging Layer Security WG , Raphael Robert References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 23 Aug 2019 15:21:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cHO2o6MoDbWSDpSjMB3JkayHIIvQoWNuG" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 14:21:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cHO2o6MoDbWSDpSjMB3JkayHIIvQoWNuG Content-Type: multipart/mixed; boundary="QA01a0w6nmAbtP94EpApI20GJ2OOTVtXX"; protected-headers="v1" From: Stephen Farrell To: Richard Barnes Cc: Messaging Layer Security WG , Raphael Robert Message-ID: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> In-Reply-To: --QA01a0w6nmAbtP94EpApI20GJ2OOTVtXX Content-Type: multipart/mixed; boundary="------------06CE0B6A4530474E4AE75367" Content-Language: en-GB This is a multi-part message in MIME format. --------------06CE0B6A4530474E4AE75367 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 23/08/2019 15:10, Richard Barnes wrote: >=20 > I'm not clear on what you mean by "meaningfully handled by members". >=20 I'm assuming that MLS protocol data will likely be handled by a library. ISTM more likely that such a library might default to, or be carelessly used to, honor anything the server proposes if this is an MLS protocol feature rather than an application layer feature. That'd be an example of not meaningfully handling this:-) We have seen similar kinds of failure with applications and TLS libraries in the past where certs aren't checked etc. I do accept the argument that it can happen at the application layer if not defined in the MLS protocol, but doing this kind of thing at the application layer seems safer to me. It's also not clear to me that all MLS applications would need this feature. (That may be true, I just don't know.) If they don't, then again, it seems to be more conservative to leave it to applications. I agree that there are sharp edges however this kind of thing is done though. Cheers, S. --------------06CE0B6A4530474E4AE75367 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------06CE0B6A4530474E4AE75367-- --QA01a0w6nmAbtP94EpApI20GJ2OOTVtXX-- --cHO2o6MoDbWSDpSjMB3JkayHIIvQoWNuG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl1f9lEACgkQWrL68XsX K+qG2RAAjs4nDdd+W/BR6s0EAI+GL+wnMxCROidKnk9wVaVKw9Ll2ccjY2GLRhaF kv4/HsAmwes64pAels7gGWVKFU+Zx8mdRwAK+UefkAPROjXIV3iy5fFKfCAaKqsu HIJKlC1opSY3xrIWnvYIHZQecFSPjhXn6+Ow0VWgqG7x9BCpG+bfHOtbpLnlurni nFzVvOJ5imigwOD5f+0lK/VlQhkRZLK1vXfbOLikCo7gdbRnB4Jn7ZNuPXhuqdpe yW2pLt97PW+kyYXDN0t550rR1zH1Dh2yGeKCtQ07SiIMLq6JruPDHLiospjPxYaw gH4qV6L1WT4iW7GCAkgvyKu+sftesi90FHn/7q4O7k7PnAEr6lMUsOH0EaZrUlXA ZoEIxlO8Dh/TRWfjx3cHqAPab6y5Ai78ydPzIqW3Bcon0Ouxc9oqOHnrKP7fFq+0 sSMMawoq4cyUsHC+gKdyAbwwGDtNz3nWVuxeSdsDMhslbLrVdy9m9eWOp+0mfh0m ZSOKfZX4/iP/xGQmirQgyykkUYdS8Xn9/y7GJmZBT8Gr5vxW7lb7E0J67G+WpmLO nV+7uEcr72EnaQ/A1AMgI3tYy1WBfPl44Ei+4GjTIAzCFVP+CwhGShp96Wvl7GQX 88JLNsLFWRYK790n5dONUendnP4Lwcuv0Osqs6v2wEBCrKnFDI4= =URZA -----END PGP SIGNATURE----- --cHO2o6MoDbWSDpSjMB3JkayHIIvQoWNuG-- From nobody Fri Aug 23 07:48:28 2019 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 2DC801200E6 for ; Fri, 23 Aug 2019 07:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 PZpjaQTOQe7G for ; Fri, 23 Aug 2019 07:48:24 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 B9DEE12006E for ; Fri, 23 Aug 2019 07:48:24 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id c7so9013673otp.1 for ; Fri, 23 Aug 2019 07:48:24 -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=GACZjhn5sY4wL6MUY+neHQDp7etLDMrXGNHpwLtiu0E=; b=kBqbSDEoIv4dqA0qqqozf+YHiAt5+Wqhvszyeb18aMmr+uWP+9QuzGl8XV++XqZtem njw6rdLwKvYVhgbG4u6dwlQBZefQf2Bg0FqcF7Zp/62GsbUHagCZRpRlRyq75SSTnF0C JUDJEhjknfU1yz9V9Ii5kgCNJRPwBZ5nufZ6gfDl2msq3o7I8oN686Wwhpw911SY7Fyd 5SHEoXtqSOAK5rnXOfocLRtyLYaXhSkTEW2ewSdiCZwstvQAAhu1pHcL4eWo2rwdIs3X d2R+CT0JvtOm436lBO00GdMtuF6z7GawGgMe8H1fsx+D2Tsh0j4pfPzWY6Qnu9BEG0Ym Egjw== 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=GACZjhn5sY4wL6MUY+neHQDp7etLDMrXGNHpwLtiu0E=; b=QUUV9q9eE98KKjgQAywDdSZ258YgdptsF28Cjx2KyTpcaN2Bu6XFGS5vJKy6GWWmI0 5eL7uRL4OGVOdZHzd26YHi8tIXiYQXgTWu9H9u2mGxPKMFcPJQHikD5s8n04CifeJp6M ZxQ0cyg6QGAVVemWoIybl1FMOKmQUtx3JK2dOYrVaZHQmF+X/9OQby/+UWQpe27xxcGS og5Ch7Qjs6lyeTQXd9CTAAgPEeEwp7ZURSkrqBic8zBY3//31jmnlZ0j0wAmU0KBhpWZ VituLTrZraSvzZzugVPsa1B2TnjIhI6N8snWGjkeky5ikRf7xhgs/AcwpeJY+kgpLwka MgNA== X-Gm-Message-State: APjAAAU4uenLBRMQm9ZZRK25hFCyZRpfuKZlg/JATWiCMDoQ54TCVZrm +/2ZhplODvMvMeAOIrBvFrV+Pl1WN0jh73L+sFjpjA== X-Google-Smtp-Source: APXvYqwXQ2WIVh6xOgoH5G8NWgb0PEwd2rMw0fkTsR2gl+ZJQG3Z2+IqpFORO4sWjTHQ4bbdAlJy+4h8CpLr867wjmg= X-Received: by 2002:a9d:7b44:: with SMTP id f4mr4299017oto.42.1566571703911; Fri, 23 Aug 2019 07:48:23 -0700 (PDT) MIME-Version: 1.0 References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> In-Reply-To: From: Richard Barnes Date: Fri, 23 Aug 2019 10:48:05 -0400 Message-ID: To: Stephen Farrell Cc: Messaging Layer Security WG , Raphael Robert Content-Type: multipart/alternative; boundary="000000000000ed56ac0590c9e542" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 14:48:26 -0000 --000000000000ed56ac0590c9e542 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell wrote: > > Hiya, > > On 23/08/2019 15:10, Richard Barnes wrote: > > > > I'm not clear on what you mean by "meaningfully handled by members". > > > > I'm assuming that MLS protocol data will likely be > handled by a library. ISTM more likely that such a > library might default to, or be carelessly used to, > honor anything the server proposes if this is an MLS > protocol feature rather than an application layer > feature. That'd be an example of not meaningfully > handling this:-) We have seen similar kinds of > failure with applications and TLS libraries in the > past where certs aren't checked etc. > Oh I see. That would actually be a pretty difficult policy to implement, at least without turning off authentication altogether, at least in the envisioned protocol. By which I mean: - Right now, clients are expected to maintain a list of members' signing keys - So signers are just indicated by their index in that list - The obvious way to add non-member signers is to reserve a block of indices (say 0xFFFFFFxx) that can correspond to application-specific entities - Then clients need to get configured with which server keys go with which reserved indices Assuming we go in that direction, the natural, "I don't care about server-initiated stuff" library design would be to just not implement any special handling for those reserved indices, in which case you'll reject anything from the server. I would expect a library that does anything else to have an API for the configuration required in the last point. The obvious screw-up case would be, "Treat a signature from the reserved block as trusted". But that's actually a little hard to implement; because the public keys aren't provided, you would have to also not do any signature verification at all, which means you're now totally open to the world. Hopefully that would raise some red flags for developers. So it's not impossible to screw up, but not trivial either. At least if you want to maintain authentication for group members. If you turn that off too, I don't think we can save you. --Richard > > I do accept the argument that it can happen at the > application layer if not defined in the MLS protocol, > but doing this kind of thing at the application layer > seems safer to me. > > It's also not clear to me that all MLS applications > would need this feature. (That may be true, I just > don't know.) If they don't, then again, it seems to > be more conservative to leave it to applications. > > I agree that there are sharp edges however this kind > of thing is done though. > > Cheers, > S. > --000000000000ed56ac0590c9e542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 23, 2019 at 10:21 AM Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:

Hiya,

On 23/08/2019 15:10, Richard Barnes wrote:
>
> I'm not clear on what you mean by "meaningfully handled by me= mbers".
>

I'm assuming that MLS protocol data will likely be
handled by a library. ISTM more likely that such a
library might default to, or be carelessly used to,
honor anything the server proposes if this is an MLS
protocol feature rather than an application layer
feature. That'd be an example of not meaningfully
handling this:-) We have seen similar kinds of
failure with applications and TLS libraries in the
past where certs aren't checked etc.

Oh I see.=C2=A0 That would actually be a pretty difficult policy to imple= ment, at least without turning off authentication altogether, at least in t= he envisioned protocol.=C2=A0 By which I mean:

- R= ight now, clients are expected to maintain a list of members' signing k= eys
- So signers are just indicated by their index in that list
- The obvious way to add non-member signers is to reserve a block = of indices (say 0xFFFFFFxx) that can correspond to application-specific ent= ities
- Then clients need to get configured with which server= keys go with which reserved indices

Assuming we g= o in that direction, the natural, "I don't care about server-initi= ated stuff" library design would be to just not implement any special = handling for those reserved indices, in which case you'll reject anythi= ng from the server.=C2=A0 I would expect a library that does anything else = to have an API for the configuration required in the last point.
<= div>
The obvious screw-up case would be, "Treat a signat= ure from the reserved block as trusted".=C2=A0 But that's actually= a little hard to implement; because the public keys aren't provided, y= ou would have to also not do any signature verification at all, which means= you're now totally open to the world.=C2=A0 Hopefully that would raise= some red flags for developers.

So it's no= t impossible to screw up, but not trivial either.=C2=A0 At least if you wan= t to maintain authentication for group members.=C2=A0 If you turn that off = too, I don't think we can save you.

--Richard= =C2=A0

=C2=A0

I do accept the argument that it can happen at the
application layer if not defined in the MLS protocol,
but doing this kind of thing at the application layer
seems safer to me.

It's also not clear to me that all MLS applications
would need this feature. (That may be true, I just
don't know.) If they don't, then again, it seems to
be more conservative to leave it to applications.

I agree that there are sharp edges however this kind
of thing is done though.

Cheers,
S.
--000000000000ed56ac0590c9e542-- From nobody Fri Aug 23 10:22:28 2019 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 A68EC12087C for ; Fri, 23 Aug 2019 10:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 RyrKuGJu_4ds for ; Fri, 23 Aug 2019 10:22:23 -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 58E4512086C for ; Fri, 23 Aug 2019 10:22:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,422,1559512800"; d="scan'208,217";a="317052973" Received: from d-burl-bng2-72-73-83-48.ngn.east.myfairpoint.net (HELO mp141-pro.home) ([72.73.83.48]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2019 19:22:19 +0200 From: Karthik Bhargavan Message-Id: <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_8704F9E3-F53B-446B-9B04-B2A4BCD37418" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 23 Aug 2019 13:22:17 -0400 In-Reply-To: Cc: Stephen Farrell , Messaging Layer Security WG , Raphael Robert To: Richard Barnes References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 17:22:27 -0000 --Apple-Mail=_8704F9E3-F53B-446B-9B04-B2A4BCD37418 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello All, It seems to me that one way to think about =E2=80=9Claziness=E2=80=9D = would be to cleanly separate the MLS key exchange into two different = protocols. The first is a =E2=80=9Cclassic=E2=80=9D authenticated synchronization = protocol where members of a group can create and modify a shared data = structure (in this case, the group membership tree). The second is a novel key establishment protocol where some member of = the group generates a fresh group secret that will be delivered only to = the current members computed from the (current) group state. Currently the first and second protocols are tightly interleaved: every = time the group data structure is modified by some member (or admin), = that member must also generate and distribute the fresh group secret. The laziness proposal can be thought of as detaching the two protocols: = the key establishment protocol can follow group modifications with some = delay. So rather than trying to add =E2=80=9Claziness=E2=80=9D to the existing = protocol, should we try to do this detachment in a principled way by = defining two independent sub-protocols? It would have the advantage that we may be able to consider other = designs for synchronization and key establishment, which may well be = orthogonal concerns. In our model of MLS, we can already factor out the protocol in this way, = but it makes the security invariants a bit harder to express in a = user-friendly way. Still, I would prefer to compose proofs for simpler sub-protocols rather = than try to prove security for a single complex protocol with lots of = options. Best, -Karthik > On 23 Aug 2019, at 10:48, Richard Barnes wrote: >=20 >=20 >=20 > On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell = > wrote: >=20 > Hiya, >=20 > On 23/08/2019 15:10, Richard Barnes wrote: > >=20 > > I'm not clear on what you mean by "meaningfully handled by members". > >=20 >=20 > I'm assuming that MLS protocol data will likely be > handled by a library. ISTM more likely that such a > library might default to, or be carelessly used to, > honor anything the server proposes if this is an MLS > protocol feature rather than an application layer > feature. That'd be an example of not meaningfully > handling this:-) We have seen similar kinds of > failure with applications and TLS libraries in the > past where certs aren't checked etc. >=20 > Oh I see. That would actually be a pretty difficult policy to = implement, at least without turning off authentication altogether, at = least in the envisioned protocol. By which I mean: >=20 > - Right now, clients are expected to maintain a list of members' = signing keys > - So signers are just indicated by their index in that list > - The obvious way to add non-member signers is to reserve a block of = indices (say 0xFFFFFFxx) that can correspond to application-specific = entities > - Then clients need to get configured with which server keys go with = which reserved indices >=20 > Assuming we go in that direction, the natural, "I don't care about = server-initiated stuff" library design would be to just not implement = any special handling for those reserved indices, in which case you'll = reject anything from the server. I would expect a library that does = anything else to have an API for the configuration required in the last = point. >=20 > The obvious screw-up case would be, "Treat a signature from the = reserved block as trusted". But that's actually a little hard to = implement; because the public keys aren't provided, you would have to = also not do any signature verification at all, which means you're now = totally open to the world. Hopefully that would raise some red flags = for developers. >=20 > So it's not impossible to screw up, but not trivial either. At least = if you want to maintain authentication for group members. If you turn = that off too, I don't think we can save you. >=20 > --Richard =20 >=20 > =20 >=20 > I do accept the argument that it can happen at the > application layer if not defined in the MLS protocol, > but doing this kind of thing at the application layer > seems safer to me. >=20 > It's also not clear to me that all MLS applications > would need this feature. (That may be true, I just > don't know.) If they don't, then again, it seems to > be more conservative to leave it to applications. >=20 > I agree that there are sharp edges however this kind > of thing is done though. >=20 > Cheers, > S. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_8704F9E3-F53B-446B-9B04-B2A4BCD37418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello All,

It seems = to me that one way to think about =E2=80=9Claziness=E2=80=9D would be to = cleanly separate the MLS key exchange into two different protocols.
The first is a =E2=80=9Cclassic=E2=80=9D authenticated = synchronization protocol where members of a group can create and modify = a shared data structure (in this case, the group membership = tree).
The second is a novel key establishment = protocol where some member of the group generates a fresh group secret = that will be delivered only to the current members computed from the = (current) group state.
Currently the first and = second protocols are tightly interleaved: every time the group data = structure is modified by some member (or admin), that member must also = generate and distribute the fresh group secret.
The = laziness proposal can be thought of as detaching the two protocols: the = key establishment protocol can follow group modifications with some = delay.

So = rather than trying to add =E2=80=9Claziness=E2=80=9D to the existing = protocol, should we try to do this detachment in a principled way by = defining two independent sub-protocols?
It would = have the advantage that we may be able to consider other designs for = synchronization and key establishment, which may well be orthogonal = concerns.

In = our model of MLS, we can already factor out the protocol in this way, = but it makes the security invariants a bit harder to express in a = user-friendly way.
Still, I would prefer to compose = proofs for simpler sub-protocols rather than try to prove security for a = single complex protocol with lots of options.

Best,
-Karthik


On 23 Aug 2019, at 10:48, Richard Barnes <rlb@ipv.sx> wrote:



On Fri, Aug = 23, 2019 at 10:21 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 23/08/2019 15:10, = Richard Barnes wrote:
> 
> I'm not = clear on what you mean by "meaningfully handled by members".
> 

I'm assuming that MLS protocol data will = likely be
handled by a library. ISTM more likely that such = a
library might default to, or be carelessly used to,
honor anything the server proposes if this is an MLS
protocol feature rather than an application layer
feature. That'd be an example of not meaningfully
handling this:-) We have seen similar kinds of
failure with applications and TLS libraries in the
past where certs aren't checked etc.

Oh I see.  That would actually be a pretty difficult = policy to implement, at least without turning off authentication = altogether, at least in the envisioned protocol.  By which I = mean:

- Right = now, clients are expected to maintain a list of members' signing = keys
- So signers are just indicated by their index = in that list
- The obvious way to add non-member = signers is to reserve a block of indices (say 0xFFFFFFxx) that can = correspond to application-specific entities
- Then clients need to get configured with which server keys = go with which reserved indices

Assuming we go in that direction, the = natural, "I don't care about server-initiated stuff" library design = would be to just not implement any special handling for those reserved = indices, in which case you'll reject anything from the server.  I = would expect a library that does anything else to have an API for the = configuration required in the last point.

The obvious screw-up = case would be, "Treat a signature from the reserved block as = trusted".  But that's actually a little hard to implement; because = the public keys aren't provided, you would have to also not do any = signature verification at all, which means you're now totally open to = the world.  Hopefully that would raise some red flags for = developers.

So it's not impossible to screw up, but not trivial = either.  At least if you want to maintain authentication for group = members.  If you turn that off too, I don't think we can save = you.

--Richard  

 

I do accept the = argument that it can happen at the
application layer if = not defined in the MLS protocol,
but doing this kind of = thing at the application layer
seems safer to me.

It's also not clear to me that all MLS = applications
would need this feature. (That may be true, I = just
don't know.) If they don't, then again, it seems = to
be more conservative to leave it to applications.

I agree that there are sharp edges however = this kind
of thing is done though.

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

= --Apple-Mail=_8704F9E3-F53B-446B-9B04-B2A4BCD37418-- From nobody Fri Aug 23 15:48:26 2019 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 F1A0512000F for ; Fri, 23 Aug 2019 15:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1dlvjRrw-v8 for ; Fri, 23 Aug 2019 15:48:21 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 173D512001E for ; Fri, 23 Aug 2019 15:48:21 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id j7so10197120ota.9 for ; Fri, 23 Aug 2019 15:48:21 -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=AmvqX2KvRh1tgJx3ihScCg0+mZT0DHm68i9o5lPV/5k=; b=BZpLaua6wr4f40G1Wzm/YnA+RdrldArRiJGg93agkQHG3dSAYoEwJ1YhxcYYzU+iQZ tmU/6KKWCH2nUm4AKOMJK8jMeCExo0sOUFCo9Omt4YjDgQ7HgZTw8H+YDsftYRvnQ4bI 1dZmTXQ0sjo1ZZe8pX1IZEeSrNBwlyz6AjndeNbXLDw349jqEEqnerSMpGvPTyTvw6f5 Ph8eQQbyC8MglGt4aXWWIWIipfL6CPvPR6ggDwD95XtSgFl4FnxcEqzs/S3GZslzjJP/ +36i4Lje9ByHzltHIcA3jjrfbYopNd3KqedJYa/9xH1z4HbvkAT6/FzMVsN0RdUJJ+ME Heqg== 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=AmvqX2KvRh1tgJx3ihScCg0+mZT0DHm68i9o5lPV/5k=; b=jRl3gwJo8y4tMDEkx797vsAjMqv43zJ+Kw1eoCCh3pzSLdDKxA/z3//cVg2qngvV4a 6eQtKz2dS1fsjMLtBkYAVnmmyluMo/n6LXRh0vXrPpD62JK0Uy0Wd7IijA1ifl2AR4lA Xm1kGdg7Gst8veiUApZ5xTa4/zw5+2eXnJO8UFgmv77j9T5ZwFJHyV0FCE6PN2u0lC8r 5MbtYcsh+GVR3WWK9Ml3N9UF3xIMIbMaw8TW3zzGm0m1XuhfWOO5ki0e6FcnxvUY00ks vbqjNqFoRn4YbW4qtZVcrRpVtlmeD7tl5ZfnxUo9YEi4PiM3oOh0I27i8qf01sarqACW GuFQ== X-Gm-Message-State: APjAAAUK29SpjH8XgArsw4xfxFowetmSdqZz95KngajEqrQYy6S9HUBa ypL1GWTIIHOC+VGblxVtJ1RiJfZVqQArbS+po/NJ/A== X-Google-Smtp-Source: APXvYqymOuryqF2VdEqdo22Wl8bDmTbaqmZ3zONgSKwsiIlLNhLjXmJNzk9bulD2CGjo05njy6ZhJfo/lDLVMtqFchY= X-Received: by 2002:a9d:7c87:: with SMTP id q7mr6269059otn.241.1566600500270; Fri, 23 Aug 2019 15:48:20 -0700 (PDT) MIME-Version: 1.0 References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> In-Reply-To: <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> From: Richard Barnes Date: Fri, 23 Aug 2019 18:48:01 -0400 Message-ID: To: Karthik Bhargavan Cc: Stephen Farrell , Messaging Layer Security WG , Raphael Robert Content-Type: multipart/alternative; boundary="00000000000052edf90590d09a67" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 23 Aug 2019 22:48:24 -0000 --00000000000052edf90590d09a67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to confirm I understand, the key exchange protocol in this conception would be something like, at each epoch: 1. KEM a secret to some set of people whom you believe to be the current members of the group 2. Send that KEM'ed value out to the group together with a description of the current membership 3. KDF the KEM'ed secret together with the prior epoch secret to get the new epoch secret 4. Use the new epoch secret to generate a confirmation over the current state of the group Where the KEM in (1) would be something like TreeKEM or just "encrypt to a list of public keys". Then the proposals would just be a way for people to sync up on who the current members of the group are (by leaf key). The major thing I would be worried about in such a split is how it would deal with authority over changes, which affect the authentication properties of the protocol. The current Proposals proposal maintains the property that everyone agrees on the proposals and can verify that they were proper, e.g., only the holder of a leaf can update that leaf. If we sever the connection between the proposals and the top-level transcript entirely, then I'm not sure how you would continue to assure that, say, the sender of a Commit didn't just swap out Joe's leaf key for the NSA. I agree that there is degree of separation here (since, e.g., it's easy to imagine swapping in a "list of keys" KEM for TreeKEM). But it seems like a fairly high degree of coupling is necessary to maintain authentication. --Richard On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > Hello All, > > It seems to me that one way to think about =E2=80=9Claziness=E2=80=9D wou= ld be to cleanly > separate the MLS key exchange into two different protocols. > The first is a =E2=80=9Cclassic=E2=80=9D authenticated synchronization pr= otocol where > members of a group can create and modify a shared data structure (in this > case, the group membership tree). > The second is a novel key establishment protocol where some member of the > group generates a fresh group secret that will be delivered only to the > current members computed from the (current) group state. > Currently the first and second protocols are tightly interleaved: every > time the group data structure is modified by some member (or admin), that > member must also generate and distribute the fresh group secret. > The laziness proposal can be thought of as detaching the two protocols: > the key establishment protocol can follow group modifications with some > delay. > > So rather than trying to add =E2=80=9Claziness=E2=80=9D to the existing p= rotocol, should > we try to do this detachment in a principled way by defining two > independent sub-protocols? > It would have the advantage that we may be able to consider other designs > for synchronization and key establishment, which may well be orthogonal > concerns. > > In our model of MLS, we can already factor out the protocol in this way, > but it makes the security invariants a bit harder to express in a > user-friendly way. > Still, I would prefer to compose proofs for simpler sub-protocols rather > than try to prove security for a single complex protocol with lots of > options. > > Best, > -Karthik > > > On 23 Aug 2019, at 10:48, Richard Barnes wrote: > > > > On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hiya, >> >> On 23/08/2019 15:10, Richard Barnes wrote: >> > >> > I'm not clear on what you mean by "meaningfully handled by members". >> > >> >> I'm assuming that MLS protocol data will likely be >> handled by a library. ISTM more likely that such a >> library might default to, or be carelessly used to, >> honor anything the server proposes if this is an MLS >> protocol feature rather than an application layer >> feature. That'd be an example of not meaningfully >> handling this:-) We have seen similar kinds of >> failure with applications and TLS libraries in the >> past where certs aren't checked etc. >> > > Oh I see. That would actually be a pretty difficult policy to implement, > at least without turning off authentication altogether, at least in the > envisioned protocol. By which I mean: > > - Right now, clients are expected to maintain a list of members' signing > keys > - So signers are just indicated by their index in that list > - The obvious way to add non-member signers is to reserve a block of > indices (say 0xFFFFFFxx) that can correspond to application-specific > entities > - Then clients need to get configured with which server keys go with whic= h > reserved indices > > Assuming we go in that direction, the natural, "I don't care about > server-initiated stuff" library design would be to just not implement any > special handling for those reserved indices, in which case you'll reject > anything from the server. I would expect a library that does anything el= se > to have an API for the configuration required in the last point. > > The obvious screw-up case would be, "Treat a signature from the reserved > block as trusted". But that's actually a little hard to implement; becau= se > the public keys aren't provided, you would have to also not do any > signature verification at all, which means you're now totally open to the > world. Hopefully that would raise some red flags for developers. > > So it's not impossible to screw up, but not trivial either. At least if > you want to maintain authentication for group members. If you turn that > off too, I don't think we can save you. > > --Richard > > > >> >> I do accept the argument that it can happen at the >> application layer if not defined in the MLS protocol, >> but doing this kind of thing at the application layer >> seems safer to me. >> >> It's also not clear to me that all MLS applications >> would need this feature. (That may be true, I just >> don't know.) If they don't, then again, it seems to >> be more conservative to leave it to applications. >> >> I agree that there are sharp edges however this kind >> of thing is done though. >> >> Cheers, >> S. >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > --00000000000052edf90590d09a67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to confirm I understand, the key exchange protoc= ol in this conception would be something like, at each epoch:
1. KEM a secret to some set of people whom you believe to be th= e current members of the group
2. Send that KEM'ed value out = to the group together with a description of the current membership
3. KDF the KEM'ed secret together with the prior epoch secret to = get the new epoch secret
4. Use the new epoch secret to gener= ate a confirmation over the current state of the group

Where the KEM in (1) would be something like TreeKEM or just "= ;encrypt to a list of public keys".=C2=A0 Then the proposals would jus= t be a way for people to sync up on who the current members of the group ar= e (by leaf key).

The major thing I would be worrie= d about in such a split is how it would deal with authority over changes, w= hich affect the authentication properties of the protocol.=C2=A0 The curren= t Proposals proposal maintains the property that everyone agrees on the pro= posals and can verify that they were proper, e.g., only the holder of a lea= f can update that leaf.=C2=A0 If we sever the connection between the propos= als and the top-level transcript entirely, then I'm not sure how you wo= uld continue to assure that, say, the sender of a Commit didn't just sw= ap out Joe's leaf key for the NSA.

I agree tha= t there is degree of separation here (since, e.g., it's easy to imagine= swapping in a "list of keys" KEM for TreeKEM).=C2=A0 But it seem= s like a fairly high degree of coupling is necessary to maintain authentica= tion.

--Richard

<= br>

On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan <karthikeyan.bhargavan@inria.fr>= ; wrote:
Hello All,

It s= eems to me that one way to think about =E2=80=9Claziness=E2=80=9D would be = to cleanly separate the MLS key exchange into two different protocols.
= The first is a =E2=80=9Cclassic=E2=80=9D authenticated synchronization prot= ocol where members of a group can create and modify a shared data structure= (in this case, the group membership tree).
The second is a novel= key establishment protocol where some member of the group generates a fres= h group secret that will be delivered only to the current members computed = from the (current) group state.
Currently the first and second pr= otocols are tightly interleaved: every time the group data structure is mod= ified by some member (or admin), that member must also generate and distrib= ute the fresh group secret.
The laziness proposal can be thought = of as detaching the two protocols: the key establishment protocol can follo= w group modifications with some delay.

So rather t= han trying to add =E2=80=9Claziness=E2=80=9D to the existing protocol, shou= ld we try to do this detachment in a principled way by defining two indepen= dent sub-protocols?
It would have the advantage that we may be ab= le to consider other designs for synchronization and key establishment, whi= ch may well be orthogonal concerns.

In our model o= f MLS, we can already factor out the protocol in this way, but it makes the= security invariants a bit harder to express in a user-friendly way.
<= div>Still, I would prefer to compose proofs for simpler sub-protocols rathe= r than try to prove security for a single complex protocol with lots of opt= ions.

Best,
-Karthik

=

On 23 Aug 2019, at 10:48, Richard B= arnes <rlb@ipv.sx>= ; wrote:



On Fri, Aug 23, 2019 at 10:21 AM Stephen Fa= rrell <st= ephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 23/08/2019 15:10, Richard Barnes= wrote:
>=C2=A0
> I'm not clear on what you mean by "mea= ningfully handled by members".
>=C2=A0

I'm assuming tha= t MLS protocol data will likely be
handled by a library. ISTM more likel= y that such a
library might default to, or be carelessly used to,
hon= or anything the server proposes if this is an MLS
protocol feature rathe= r than an application layer
feature. That'd be an example of not mea= ningfully
handling this:-) We have seen similar kinds of
failure with= applications and TLS libraries in the
past where certs aren't check= ed etc.

Oh I see.=C2=A0 That would actu= ally be a pretty difficult policy to implement, at least without turning of= f authentication altogether, at least in the envisioned protocol.=C2=A0 By = which I mean:

- Right now, clients are expected to= maintain a list of members' signing keys
- So signers are ju= st indicated by their index in that list
- The obvious way to add= non-member signers is to reserve a block of indices (say 0xFFFFFFxx) that = can correspond to application-specific entities
- Then client= s need to get configured with which server keys go with which reserved indi= ces

Assuming we go in that direction, the natural,= "I don't care about server-initiated stuff" library design w= ould be to just not implement any special handling for those reserved indic= es, in which case you'll reject anything from the server.=C2=A0 I would= expect a library that does anything else to have an API for the configurat= ion required in the last point.

The obvious sc= rew-up case would be, "Treat a signature from the reserved block as tr= usted".=C2=A0 But that's actually a little hard to implement; beca= use the public keys aren't provided, you would have to also not do any = signature verification at all, which means you're now totally open to t= he world.=C2=A0 Hopefully that would raise some red flags for developers.

So it's not impossible to screw up, but not= trivial either.=C2=A0 At least if you want to maintain authentication for = group members.=C2=A0 If you turn that off too, I don't think we can sav= e you.

--Richard=C2=A0=C2=A0

=C2=A0

I d= o accept the argument that it can happen at the
application layer if not= defined in the MLS protocol,
but doing this kind of thing at the applic= ation layer
seems safer to me.

It's also not clear to me that= all MLS applications
would need this feature. (That may be true, I just=
don't know.) If they don't, then again, it seems to
be more = conservative to leave it to applications.

I agree that there are sha= rp edges however this kind
of thing is done though.

Cheers,
S.=
MLS mailing listMLS@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/mls

--00000000000052edf90590d09a67-- From nobody Tue Aug 27 10:24:00 2019 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 4FEE6120130 for ; Tue, 27 Aug 2019 10:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 A0ucKZeIpy28 for ; Tue, 27 Aug 2019 10:23:55 -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 79209120074 for ; Tue, 27 Aug 2019 10:23:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,438,1559512800"; d="scan'208,217";a="399083236" Received: from d-burl-bng2-72-73-83-48.ngn.east.myfairpoint.net (HELO mp141-pro.home) ([72.73.83.48]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 19:23:51 +0200 From: Karthik Bhargavan Message-Id: <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_87D6BEA0-A938-4628-A76C-71C84536B9CB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 27 Aug 2019 13:23:46 -0400 In-Reply-To: Cc: Stephen Farrell , Messaging Layer Security WG , Raphael Robert To: Richard Barnes References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 27 Aug 2019 17:23:59 -0000 --Apple-Mail=_87D6BEA0-A938-4628-A76C-71C84536B9CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Richard, > On 23 Aug 2019, at 18:48, Richard Barnes wrote: >=20 > Just to confirm I understand, the key exchange protocol in this = conception would be something like, at each epoch: >=20 > 1. KEM a secret to some set of people whom you believe to be the = current members of the group > 2. Send that KEM'ed value out to the group together with a description = of the current membership > 3. KDF the KEM'ed secret together with the prior epoch secret to get = the new epoch secret > 4. Use the new epoch secret to generate a confirmation over the = current state of the group > Where the KEM in (1) would be something like TreeKEM or just "encrypt = to a list of public keys". Then the proposals would just be a way for = people to sync up on who the current members of the group are (by leaf = key). This is essentially correct, of course with a bunch of details to = guarantee that everyone gets the same keys. It remains mostly unchanged from what we have currently. > The major thing I would be worried about in such a split is how it = would deal with authority over changes, which affect the authentication = properties of the protocol. The current Proposals proposal maintains = the property that everyone agrees on the proposals and can verify that = they were proper, e.g., only the holder of a leaf can update that leaf. = If we sever the connection between the proposals and the top-level = transcript entirely, then I'm not sure how you would continue to assure = that, say, the sender of a Commit didn't just swap out Joe's leaf key = for the NSA. The changes would be signed by the sender, as usual. The only question = is whether this signature is enough, without binding the signature to = the key exchange transcript or current epoch secret. Note that the tree synchronization protocol has its own transcript on = how the tree has changed over time, and certainly we could require each = update to sign this =E2=80=9Cstate history=E2=80=9D transcript. We should of course impose the requirement that only the "holder of the = signature key corresponding to a leaf=E2=80=9D can update that leaf. In fact, the tree update protocol can ensure that only members of a = subtree can change the root of that subtree. This is what we guarantee now anyway. I don=E2=80=99t see that = substantially changing in the decoupled design. > I agree that there is degree of separation here (since, e.g., it's = easy to imagine swapping in a "list of keys" KEM for TreeKEM). But it = seems like a fairly high degree of coupling is necessary to maintain = authentication. So, what would be the authentication property you would want for a tree = change? The tree changing sender must know the signature key for a member *and = must also know the current epoch secret*? Perhaps what you are pointing out is that we cannot remove signatures = from the key exchange protocol, and so we=E2=80=99d end up needing two = signatures; one for tree synchronization and the other for = authenticating the key exchange. Actually, we also need a third signature for the message protection. How = and when we can share these signatures is an optimization problem, but = they serve different purposes. -Karthik >=20 > --Richard >=20 >=20 >=20 > On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan = > = wrote: > Hello All, >=20 > It seems to me that one way to think about =E2=80=9Claziness=E2=80=9D = would be to cleanly separate the MLS key exchange into two different = protocols. > The first is a =E2=80=9Cclassic=E2=80=9D authenticated synchronization = protocol where members of a group can create and modify a shared data = structure (in this case, the group membership tree). > The second is a novel key establishment protocol where some member of = the group generates a fresh group secret that will be delivered only to = the current members computed from the (current) group state. > Currently the first and second protocols are tightly interleaved: = every time the group data structure is modified by some member (or = admin), that member must also generate and distribute the fresh group = secret. > The laziness proposal can be thought of as detaching the two = protocols: the key establishment protocol can follow group modifications = with some delay. >=20 > So rather than trying to add =E2=80=9Claziness=E2=80=9D to the = existing protocol, should we try to do this detachment in a principled = way by defining two independent sub-protocols? > It would have the advantage that we may be able to consider other = designs for synchronization and key establishment, which may well be = orthogonal concerns. >=20 > In our model of MLS, we can already factor out the protocol in this = way, but it makes the security invariants a bit harder to express in a = user-friendly way. > Still, I would prefer to compose proofs for simpler sub-protocols = rather than try to prove security for a single complex protocol with = lots of options. >=20 > Best, > -Karthik >=20 >=20 >> On 23 Aug 2019, at 10:48, Richard Barnes > wrote: >>=20 >>=20 >>=20 >> On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell = > wrote: >>=20 >> Hiya, >>=20 >> On 23/08/2019 15:10, Richard Barnes wrote: >> >=20 >> > I'm not clear on what you mean by "meaningfully handled by = members". >> >=20 >>=20 >> I'm assuming that MLS protocol data will likely be >> handled by a library. ISTM more likely that such a >> library might default to, or be carelessly used to, >> honor anything the server proposes if this is an MLS >> protocol feature rather than an application layer >> feature. That'd be an example of not meaningfully >> handling this:-) We have seen similar kinds of >> failure with applications and TLS libraries in the >> past where certs aren't checked etc. >>=20 >> Oh I see. That would actually be a pretty difficult policy to = implement, at least without turning off authentication altogether, at = least in the envisioned protocol. By which I mean: >>=20 >> - Right now, clients are expected to maintain a list of members' = signing keys >> - So signers are just indicated by their index in that list >> - The obvious way to add non-member signers is to reserve a block of = indices (say 0xFFFFFFxx) that can correspond to application-specific = entities >> - Then clients need to get configured with which server keys go with = which reserved indices >>=20 >> Assuming we go in that direction, the natural, "I don't care about = server-initiated stuff" library design would be to just not implement = any special handling for those reserved indices, in which case you'll = reject anything from the server. I would expect a library that does = anything else to have an API for the configuration required in the last = point. >>=20 >> The obvious screw-up case would be, "Treat a signature from the = reserved block as trusted". But that's actually a little hard to = implement; because the public keys aren't provided, you would have to = also not do any signature verification at all, which means you're now = totally open to the world. Hopefully that would raise some red flags = for developers. >>=20 >> So it's not impossible to screw up, but not trivial either. At least = if you want to maintain authentication for group members. If you turn = that off too, I don't think we can save you. >>=20 >> --Richard =20 >>=20 >> =20 >>=20 >> I do accept the argument that it can happen at the >> application layer if not defined in the MLS protocol, >> but doing this kind of thing at the application layer >> seems safer to me. >>=20 >> It's also not clear to me that all MLS applications >> would need this feature. (That may be true, I just >> don't know.) If they don't, then again, it seems to >> be more conservative to leave it to applications. >>=20 >> I agree that there are sharp edges however this kind >> of thing is done though. >>=20 >> Cheers, >> S. >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_87D6BEA0-A938-4628-A76C-71C84536B9CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Richard,

On = 23 Aug 2019, at 18:48, Richard Barnes <rlb@ipv.sx> wrote:

Just to confirm I understand, the key = exchange protocol in this conception would be something like, at each = epoch:

1. KEM = a secret to some set of people whom you believe to be the current = members of the group
2. Send that KEM'ed value out = to the group together with a description of the current membership
3. KDF the KEM'ed secret together with = the prior epoch secret to get the new epoch secret
4. Use the new epoch secret to generate = a confirmation over the current state of the = group
Where the KEM in = (1) would be something like TreeKEM or just "encrypt to a list of public = keys".  Then the proposals would just be a way for people to sync = up on who the current members of the group are (by leaf = key).

This is essentially correct, of = course with a bunch of details to guarantee that everyone gets the same = keys.
It remains mostly unchanged from what we have = currently.

The major thing I = would be worried about in such a split is how it would deal with = authority over changes, which affect the authentication properties of = the protocol.  The current Proposals proposal maintains the = property that everyone agrees on the proposals and can verify that they = were proper, e.g., only the holder of a leaf can update that leaf.  = If we sever the connection between the proposals and the top-level = transcript entirely, then I'm not sure how you would continue to assure = that, say, the sender of a Commit didn't just swap out Joe's leaf key = for the NSA.

The changes would be signed by the sender, as = usual. The only question is whether this signature is enough, without = binding the signature to the key exchange transcript or current epoch = secret.
Note that the tree synchronization protocol has its = own transcript on how the tree has changed over time, and certainly we = could require each update to sign this =E2=80=9Cstate history=E2=80=9D = transcript.
We should of course impose the requirement that = only the "holder of the signature key corresponding to a leaf=E2=80=9D = can update that leaf.
In fact, the tree update protocol can = ensure that only members of a subtree can change the root of that = subtree.
This is what we guarantee now anyway. I don=E2=80=99t = see that substantially changing in the decoupled design.


I agree that = there is degree of separation here (since, e.g., it's easy to imagine = swapping in a "list of keys" KEM for TreeKEM).  But it seems like a = fairly high degree of coupling is necessary to maintain = authentication.

So, what would be the authentication property you = would want for a tree change?
The tree changing sender must = know the signature key for a member *and must also know the current = epoch secret*?

Perhaps what you are = pointing out is that we cannot remove signatures from the key exchange = protocol, and so we=E2=80=99d end up needing two signatures; one for = tree synchronization and the other for authenticating the key = exchange.
Actually, we also need a third signature for the = message protection. How and when we can share these signatures is an = optimization problem, but they serve different purposes.

-Karthik


--Richard



On Fri, Aug 23, 2019 at 1:22 PM Karthik = Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:
Hello All,

It seems to me that one way to think = about =E2=80=9Claziness=E2=80=9D would be to cleanly separate the MLS = key exchange into two different protocols.
The first is a = =E2=80=9Cclassic=E2=80=9D authenticated synchronization protocol where = members of a group can create and modify a shared data structure (in = this case, the group membership tree).
The second = is a novel key establishment protocol where some member of the group = generates a fresh group secret that will be delivered only to the = current members computed from the (current) group state.
Currently the first and second protocols are tightly = interleaved: every time the group data structure is modified by some = member (or admin), that member must also generate and distribute the = fresh group secret.
The laziness proposal can be = thought of as detaching the two protocols: the key establishment = protocol can follow group modifications with some delay.

So rather than trying to = add =E2=80=9Claziness=E2=80=9D to the existing protocol, should we try = to do this detachment in a principled way by defining two independent = sub-protocols?
It would have the advantage that we = may be able to consider other designs for synchronization and key = establishment, which may well be orthogonal concerns.

In our model of MLS, we = can already factor out the protocol in this way, but it makes the = security invariants a bit harder to express in a user-friendly = way.
Still, I would prefer to compose proofs for = simpler sub-protocols rather than try to prove security for a single = complex protocol with lots of options.

Best,
-Karthik


On 23 Aug 2019, at 10:48, Richard Barnes = <rlb@ipv.sx> wrote:



On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell = <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 23/08/2019 15:10, Richard Barnes wrote:
> <= br class=3D"">> I'm not clear on what you mean by "meaningfully = handled by members".
> <= br class=3D"">
I'm assuming that MLS protocol data will = likely be
handled by a library. ISTM more likely that such = a
library might default to, or be carelessly used to,
honor anything the server proposes if this is an MLS
protocol feature rather than an application layer
feature. That'd be an example of not meaningfully
handling this:-) We have seen similar kinds of
failure with applications and TLS libraries in the
past where certs aren't checked etc.

Oh I see.  That would actually be a pretty difficult = policy to implement, at least without turning off authentication = altogether, at least in the envisioned protocol.  By which I = mean:

- Right = now, clients are expected to maintain a list of members' signing = keys
- So signers are just indicated by their index = in that list
- The obvious way to add non-member = signers is to reserve a block of indices (say 0xFFFFFFxx) that can = correspond to application-specific entities
- Then clients need to get configured with which server keys = go with which reserved indices

Assuming we go in that direction, the = natural, "I don't care about server-initiated stuff" library design = would be to just not implement any special handling for those reserved = indices, in which case you'll reject anything from the server.  I = would expect a library that does anything else to have an API for the = configuration required in the last point.

The obvious screw-up = case would be, "Treat a signature from the reserved block as = trusted".  But that's actually a little hard to implement; because = the public keys aren't provided, you would have to also not do any = signature verification at all, which means you're now totally open to = the world.  Hopefully that would raise some red flags for = developers.

So it's not impossible to screw up, but not trivial = either.  At least if you want to maintain authentication for group = members.  If you turn that off too, I don't think we can save = you.

--Richard  <= br class=3D"">

 

I do accept the = argument that it can happen at the
application layer if = not defined in the MLS protocol,
but doing this kind of = thing at the application layer
seems safer to me.

It's also not clear to me that all MLS = applications
would need this feature. (That may be true, I = just
don't know.) If they don't, then again, it seems = to
be more conservative to leave it to applications.

I agree that there are sharp edges however = this kind
of thing is done though.

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


= --Apple-Mail=_87D6BEA0-A938-4628-A76C-71C84536B9CB-- From nobody Thu Aug 29 08:34:26 2019 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 5A8A41208AD for ; Thu, 29 Aug 2019 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 KuR6P90HorYE for ; Thu, 29 Aug 2019 08:34:22 -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 936981208AA for ; Thu, 29 Aug 2019 08:34:22 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id v38so4174927qtb.0 for ; Thu, 29 Aug 2019 08:34:22 -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=l0/a8sV7ML3Qxmz7oz38hPebkHDuMYW1mFWvzk8O+9g=; b=axRVqAj+xm3Wovz9pZL4kPBfYlVa9qh5aR69JMsARzpq9Wd2nLOOy2uIWmzxKlz0GU jiy5St0H1dzm8QsxUUwFLbnS0JDO4936+hy60acRHSic2TfnrpCs1VzxCBzsduFxRl4s UXI9PVqXVYMZKXW8D8MtxRc4sBpiuIF7jRKPQ= 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=l0/a8sV7ML3Qxmz7oz38hPebkHDuMYW1mFWvzk8O+9g=; b=ZeEQFTwPvhlUkedVm0OusUKJ0oAgBkmAeM50EGbVjA8eGzc90UDHmq7iUQX0P5Tbkp wibbyUzn81EFsWttDicEg5omfNsjRoj1zx074E43jI//ogQRrp1qTsFxnTOy14ugu+7e olT54uHY90Q7KwY8Hn1/LxBC/E8cw8efV+vS+7/h+jK0iaHL7IdBaqhU5vOxO3Z+OSIn IkNCG230WBLp0kM0zRLnIm8E1+LHsHzYmFrkLLD0VDNywCu3UkQydudvGg/DetR5kM31 LiQgfOmMHZDmzJ36YjJHtDilDKLXHo5/M+AMUUfcbTcvH6mDTr+b7gpe5G1Yuba9Yzmh ScwQ== X-Gm-Message-State: APjAAAWPbePdhsmL+Xl8pCkFQ0KCgLECdUJA6CYUgjylLPmhatpdDZSV UJficaSokSa2DcPebh2FsoiXratQrtw= X-Google-Smtp-Source: APXvYqz11DuAvkYP4t66OnFabEfXuxoXfU8dskL3gDvvtJiws1hAMJebGrmiqn5ezH36TkY+GS0gjg== X-Received: by 2002:a0c:f88b:: with SMTP id u11mr6587837qvn.99.1567092861352; Thu, 29 Aug 2019 08:34:21 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id u16sm1271721qkj.107.2019.08.29.08.34.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 08:34:20 -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 12.4 \(3445.104.11\)) Date: Thu, 29 Aug 2019 11:34:19 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [MLS] MLS 2019 Fall Interim 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, 29 Aug 2019 15:34:25 -0000 Hi, Thanks to everyone that participated in the doodle poll. I does appear = that 1-2 October is the best time to get folks together to. Shortly, I = will request the interim and being to update the github repo = (https://github.com/mlswg/wg-materials/tree/master/interim-2019-10) with = relevant details. I plan to request WebEx sessions for each day so = remote participation is still an option. Be on the look-out for the registration email! spt > On Aug 21, 2019, at 23:11, Sean Turner wrote: >=20 > All, >=20 > We are planning to have an MLS 2019 Fall F2F Interim. Please fill out = the following doodle poll to indicate your preference by 2359 UTC = 28-AUG-2019: >=20 > https://doodle.com/poll/5ri8n2uct2vyicka >=20 > Currently, it looks very likely to be 1-2 October. >=20 > The location is London, but the location is still TBD. >=20 > Cheers, >=20 > Nick & Sean From nobody Thu Aug 29 08:39:21 2019 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 8640512090E; Thu, 29 Aug 2019 08:39:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mls-chairs@ietf.org, mls@ietf.org, kaduk@mit.edu, sean@sn3rd.com X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156709315947.1019.13130984486858477631.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2019 08:39:19 -0700 Archived-At: Subject: [MLS] mls - New Interim Meeting Request 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: Thu, 29 Aug 2019 15:39:20 -0000 A new interim meeting request has just been submitted by Sean Turner. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2019-mls-03 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner City: London Country: GB Session 1: Date: 2019-10-01 Start Time: 09:00 Europe/London Duration: 08:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=mcc881216e9ce2341f57d9b4b66bf1faf Agenda Note: Session 2: Date: 2019-10-02 Start Time: 09:00 Europe/London Duration: 08:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m63477cbbe3ca719c9c1ad111def527c3 Agenda Note: --------------------------------------------------------- From nobody Thu Aug 29 10:51:17 2019 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 42EB4120849 for ; Thu, 29 Aug 2019 10:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 NVqXJQNsnMvX for ; Thu, 29 Aug 2019 10:51:13 -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 06BF51209DD for ; Thu, 29 Aug 2019 10:51:13 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id b2so1165593qtq.5 for ; Thu, 29 Aug 2019 10:51:12 -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=67ns/tdMikHl4N/1FJZlkVryTJkYIgF/hLj9JoIzywI=; b=TTstuc2qXklrVCszr1MefkaeODJ/WoSWqUtG1FjclLo1yuO6/dorRU89vW/eodfy7T 8+bjLxRktYBb96s8SEe36iPXwhdGZYE7mhq63119/kKfcY5yU9xPwRf7/n+T1bVW0Ldx yvsahCDCWSP0zGVhS5gFizG9LbmeDUkWYJGig= 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=67ns/tdMikHl4N/1FJZlkVryTJkYIgF/hLj9JoIzywI=; b=T+6dcsYH0p8PDw6+EsubrbqE+FKdxzo5eSzkn8YBdVm+xtmKxzgnXSlAnLVo7P13eC bDQQnbI1zfGLKrPIiuQzgVoxHUuuEKryi+b+9czzMkd0mJAlMSQAmvVrxHDhE1CISWw3 6Q3KZH+d/YVv4sD0AstE7EQFyhSI2AmakiIxaZbOwM9s26xZUeucXZGSK9V7OaWBVRr6 kOSO8f7tQhzn1hjtKkZ/F26tSTt5aapduuOc1spgFUBKdR0X9gelr5/Av8vtYIeNL/ar C6Ti+HL3hdy3ln2USEukd/j3oBAWuDKKbKBnyDOKRSUJmxNIIpbG096b6N2biAV8IBjI hvQg== X-Gm-Message-State: APjAAAWih4UNXuTDCRAFYHBsaUT8zsdpL9nUP7dEEFYfzn2Rt9ZTMJET nCC/6D2tbKtXWTVdQDUVKs0OmRuI7qY= X-Google-Smtp-Source: APXvYqyJ+7WB+I8hzC1eVdgOCp8aj7fpkZfHtZvOzj8TlOssFScgLStHNJEb4dJfwv3euLo2coLIGA== X-Received: by 2002:ac8:661a:: with SMTP id c26mr1194076qtp.106.1567101071932; Thu, 29 Aug 2019 10:51:11 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id d134sm958659qkg.133.2019.08.29.10.51.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 10:51:11 -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 12.4 \(3445.104.11\)) Message-Id: <928256A6-1C12-4C62-BB8E-8E883AA00DA9@sn3rd.com> Date: Thu, 29 Aug 2019 13:51:10 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [MLS] October 2019 Interim Registration and Issue discussion 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, 29 Aug 2019 17:51:15 -0000 The date and location are set for the October 2019 Interim meeting. It = will be on October 1st and 2nd at Cloudflare's London Office. More = details can be found on Github: = https://github.com/mlswg/wg-materials/tree/master/interim-2019-10. Please register with the following form if you intend on attending = either remotely or in person. Registration Link (https://forms.gle/FAB8jUpLXo6tmaC58) Registration deadline closes on October 13th. We are soliciting proposals for presentations to add to the agenda for = the meeting. Please send proposals to mls-chairs@ietf.org. Due to time = limitations, these should be restricted to discussions about current = active drafts. Here are the active documents: Protocol (https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/) Issues: https://github.com/mlswg/mls-protocol/issues Architecture = (https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/) Issues: https://github.com/mlswg/mls-architecture Federation https://datatracker.ietf.org/doc/draft-omara-mls-federation/) Issues: https://github.com/mlswg/mls-federation/issues We encourage the authors and other participants to read these issues, = distill the main questions raised by them and propose answers for = discussion on the list in the coming weeks. Nick and Sean= From nobody Thu Aug 29 12:59:52 2019 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 410B8120B48; Thu, 29 Aug 2019 12:59:44 -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: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156710878414.1081.16768613263298440765@ietfa.amsl.com> Date: Thu, 29 Aug 2019 12:59:44 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting: 2019-10-01 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: Thu, 29 Aug 2019 19:59:44 -0000 The Messaging Layer Security (mls) Working Group will hold a multi-day interim meeting. Session 1: 2019-10-01 09:00 to 17:00 Europe/London Session 2: 2019-10-02 09:00 to 17:00 Europe/London Meeting Location: London, GB Agenda: See https://github.com/mlswg/wg-materials/blob/master/interim-2019-10/agenda.md Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mcc881216e9ce2341f57d9b4b66bf1faf From nobody Fri Aug 30 09:40:40 2019 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 59031120B6D for ; Fri, 30 Aug 2019 09:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=katriel.co.uk header.b=KPG6NxEs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GOZl+dm1 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 bjAsWURjsMuH for ; Fri, 30 Aug 2019 09:40:26 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513BE120B62 for ; Fri, 30 Aug 2019 09:40:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 35DAD21DFB for ; Fri, 30 Aug 2019 12:40:25 -0400 (EDT) Received: from imap36 ([10.202.2.86]) by compute6.internal (MEProxy); Fri, 30 Aug 2019 12:40:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=mesmtp; bh=a5jwYiRTO8VhEMpgIC4VdV/BH +KYaCkXlmiP1jK8LAQ=; b=KPG6NxEsiIxiNNVcF9cIAtNfAKBBnMXPVEi7RpVGD JFNK7z2TLy0KrkA6GWu/Ho2r0h5HHI05dYF/m7opd4wa7eVTfIfiMrWu4V6hfw1l YnDQa1S8pQO4TiJE3BI1djXZxXBR68rmhodVbfRGp7CGkwrz+5K7LUh8D6LONYTy x0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=a5jwYi RTO8VhEMpgIC4VdV/BH+KYaCkXlmiP1jK8LAQ=; b=GOZl+dm1/KX2415PghMcby +o3B7xPtRaEolXeAupXqzyY2v//rmsUR1BRmiTOOdOXkjRljV/FCgWIt48i+LWwq je9HcSG3WDT9ds5eDRxenFT6pky4rlsH4/NeHNRE19PW0ksacJIMCYxXHX9Yvj4N icZ/alPy5S2/797r36TUg4xRhgS5YmqxMynsr4KvJa/U/PuI8DcY8EvjGIQN4YsD 2W+LfxJIRtMt5cultwnUezZFlgTNFZ4+QVH+Uap5SevnU7SgTEKkn5MjXO/2rwu6 wPDgppf+KDRtNK+4qtc+lizHfbuw2sRcj8dHuyHheTKiGYEQ9jVVZx3AVgyfiw/w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeigedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdfmrghtrhhivghlucevohhhnhdqifhorhguohhnfdcu oehmvgeskhgrthhrihgvlhdrtghordhukheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomhepmhgvsehkrghtrhhivghlrdgtohdruhhknecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D25E612200A2; Fri, 30 Aug 2019 12:40:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-154-gfa7592a-fmstable-20190829v1 Mime-Version: 1.0 Message-Id: <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com> In-Reply-To: <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> Date: Fri, 30 Aug 2019 17:40:03 +0100 From: "Katriel Cohn-Gordon" To: mls@ietf.org Cc: "Messaging Layer Security WG" Content-Type: multipart/alternative; boundary=2595ba6b76d840188c5c25255aa2f6ce Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) 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, 30 Aug 2019 16:40:38 -0000 --2595ba6b76d840188c5c25255aa2f6ce Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable This abstraction seems sensible. Server add/remove is important in many = practical use cases: you buy a new phone and log in; the server wants to= remove your old phone from all groups it's in, and add the new phone. S= ince we of course don't want to give the server the ability to actually = effect this change, only to propose it, it seems to me that we already n= eed a way to disconnect proposals and commits anyway. Once that's the ca= se, it doesn't seem too big a leap to cleanly factor all operations into= that structure. My main worry would be complicating the analysis. However, it seems like= if the separation is clean enough then it might not actually make the a= nalysis too bad, because there is a clean property (that Karthik describ= ed) for each epoch change. So, on balance, I think I'm in favour of this= proposal. --katriel On Tue, 27 Aug 2019, at 6:23 PM, Karthik Bhargavan wrote: >=20 > Hi Richard, >=20 >> On 23 Aug 2019, at 18:48, Richard Barnes wrote: >>=20 >> Just to confirm I understand, the key exchange protocol in this conce= ption would be something like, at each epoch: >>=20 >> 1. KEM a secret to some set of people whom you believe to be the curr= ent members of the group >> 2. Send that KEM'ed value out to the group together with a descriptio= n of the current membership >> 3. KDF the KEM'ed secret together with the prior epoch secret to get = the new epoch secret >> 4. Use the new epoch secret to generate a confirmation over the curre= nt state of the group >> Where the KEM in (1) would be something like TreeKEM or just "encrypt= to a list of public keys". Then the proposals would just be a way for p= eople to sync up on who the current members of the group are (by leaf ke= y). >=20 > This is essentially correct, of course with a bunch of details to guar= antee that everyone gets the same keys. > It remains mostly unchanged from what we have currently. >=20 >> The major thing I would be worried about in such a split is how it wo= uld deal with authority over changes, which affect the authentication pr= operties of the protocol. The current Proposals proposal maintains the p= roperty that everyone agrees on the proposals and can verify that they w= ere proper, e.g., only the holder of a leaf can update that leaf. If we = sever the connection between the proposals and the top-level transcript = entirely, then I'm not sure how you would continue to assure that, say, = the sender of a Commit didn't just swap out Joe's leaf key for the NSA. >=20 > The changes would be signed by the sender, as usual. The only question= is whether this signature is enough, without binding the signature to t= he key exchange transcript or current epoch secret. > Note that the tree synchronization protocol has its own transcript on = how the tree has changed over time, and certainly we could require each = update to sign this =E2=80=9Cstate history=E2=80=9D transcript. > We should of course impose the requirement that only the "holder of th= e signature key corresponding to a leaf=E2=80=9D can update that leaf. > In fact, the tree update protocol can ensure that only members of a su= btree can change the root of that subtree. > This is what we guarantee now anyway. I don=E2=80=99t see that substan= tially changing in the decoupled design. >=20 >=20 >> I agree that there is degree of separation here (since, e.g., it's ea= sy to imagine swapping in a "list of keys" KEM for TreeKEM). But it seem= s like a fairly high degree of coupling is necessary to maintain authent= ication. >=20 > So, what would be the authentication property you would want for a tre= e change? > The tree changing sender must know the signature key for a member *and= must also know the current epoch secret*? >=20 > Perhaps what you are pointing out is that we cannot remove signatures = from the key exchange protocol, and so we=E2=80=99d end up needing two s= ignatures; one for tree synchronization and the other for authenticating= the key exchange. > Actually, we also need a third signature for the message protection. H= ow and when we can share these signatures is an optimization problem, bu= t they serve different purposes. >=20 > -Karthik >=20 >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan wrote: >>> Hello All, >>>=20 >>> It seems to me that one way to think about =E2=80=9Claziness=E2=80=9D= would be to cleanly separate the MLS key exchange into two different pr= otocols. >>> The first is a =E2=80=9Cclassic=E2=80=9D authenticated synchronizati= on protocol where members of a group can create and modify a shared data= structure (in this case, the group membership tree). >>> The second is a novel key establishment protocol where some member o= f the group generates a fresh group secret that will be delivered only t= o the current members computed from the (current) group state. >>> Currently the first and second protocols are tightly interleaved: ev= ery time the group data structure is modified by some member (or admin),= that member must also generate and distribute the fresh group secret. >>> The laziness proposal can be thought of as detaching the two protoco= ls: the key establishment protocol can follow group modifications with s= ome delay. >>>=20 >>> So rather than trying to add =E2=80=9Claziness=E2=80=9D to the exist= ing protocol, should we try to do this detachment in a principled way by= defining two independent sub-protocols? >>> It would have the advantage that we may be able to consider other de= signs for synchronization and key establishment, which may well be ortho= gonal concerns. >>>=20 >>> In our model of MLS, we can already factor out the protocol in this = way, but it makes the security invariants a bit harder to express in a u= ser-friendly way. >>> Still, I would prefer to compose proofs for simpler sub-protocols ra= ther than try to prove security for a single complex protocol with lots = of options. >>>=20 >>> Best, >>> -Karthik >>>=20 >>>=20 >>>> On 23 Aug 2019, at 10:48, Richard Barnes wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell wrote: >>>>>=20 >>>>> Hiya, >>>>>=20 >>>>> On 23/08/2019 15:10, Richard Barnes wrote: >>>>> >=20 >>>>> > I'm not clear on what you mean by "meaningfully handled by membe= rs". >>>>> >=20 >>>>>=20 >>>>> I'm assuming that MLS protocol data will likely be >>>>> handled by a library. ISTM more likely that such a >>>>> library might default to, or be carelessly used to, >>>>> honor anything the server proposes if this is an MLS >>>>> protocol feature rather than an application layer >>>>> feature. That'd be an example of not meaningfully >>>>> handling this:-) We have seen similar kinds of >>>>> failure with applications and TLS libraries in the >>>>> past where certs aren't checked etc. >>>>=20 >>>> Oh I see. That would actually be a pretty difficult policy to imple= ment, at least without turning off authentication altogether, at least i= n the envisioned protocol. By which I mean: >>>>=20 >>>> - Right now, clients are expected to maintain a list of members' si= gning keys >>>> - So signers are just indicated by their index in that list >>>> - The obvious way to add non-member signers is to reserve a block o= f indices (say 0xFFFFFFxx) that can correspond to application-specific e= ntities >>>> - Then clients need to get configured with which server keys go wit= h which reserved indices >>>>=20 >>>> Assuming we go in that direction, the natural, "I don't care about = server-initiated stuff" library design would be to just not implement an= y special handling for those reserved indices, in which case you'll reje= ct anything from the server. I would expect a library that does anything= else to have an API for the configuration required in the last point. >>>>=20 >>>> The obvious screw-up case would be, "Treat a signature from the res= erved block as trusted". But that's actually a little hard to implement;= because the public keys aren't provided, you would have to also not do = any signature verification at all, which means you're now totally open t= o the world. Hopefully that would raise some red flags for developers. >>>>=20 >>>> So it's not impossible to screw up, but not trivial either. At leas= t if you want to maintain authentication for group members. If you turn = that off too, I don't think we can save you. >>>>=20 >>>> --Richard=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> I do accept the argument that it can happen at the >>>>> application layer if not defined in the MLS protocol, >>>>> but doing this kind of thing at the application layer >>>>> seems safer to me. >>>>>=20 >>>>> It's also not clear to me that all MLS applications >>>>> would need this feature. (That may be true, I just >>>>> don't know.) If they don't, then again, it seems to >>>>> be more conservative to leave it to applications. >>>>>=20 >>>>> I agree that there are sharp edges however this kind >>>>> of thing is done though. >>>>>=20 >>>>> Cheers, >>>>> S. >>>> _______________________________________________ >>>> 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 >=20 --2595ba6b76d840188c5c25255aa2f6ce Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
This abstraction seems sensible. Server add/remove is = important in many practical use cases: you buy a new phone and log in; t= he server wants to remove your old phone from all groups it's in, and ad= d the new phone. Since we of course don't want to give the server the ab= ility to actually effect this change, only to propose it, it seems to me= that we already need a way to disconnect proposals and commits anyway. = Once that's the case, it doesn't seem too big a leap to cleanly factor a= ll operations into that structure.

My main worry would be complicating the analysis. However, it seems l= ike if the separation is clean enough then it might not actually make th= e analysis too bad, because there is a clean property (that Karthik desc= ribed) for each epoch change. So, on balance, I think I'm in favour of t= his proposal.

--katriel

On Tue, 27 Aug 2019, at = 6:23 PM, Karthik Bhargavan wrote:

Hi Richard,

<= div class=3D"qt-">On 23 Aug 2019, at 18:48, Richard Barnes <rlb@ipv.sx> wrote:

Just to confirm I understa= nd, the key exchange protocol in this conception would be something like= , at each epoch:

1. KEM a secret to some set of people whom you believe to be the curre= nt members of the group
2. Send that KEM'ed = value out to the group together with a description of the current member= ship
3. KDF the KEM'ed secret together with = the prior epoch secret to get the new epoch secret
4. Use the new epoch secret to generate a confirmation over the cu= rrent state of the group
Where the KEM in (1) would be something like TreeKEM or just "= encrypt to a list of public keys".  Then the proposals would just b= e a way for people to sync up on who the current members of the group ar= e (by leaf key).

This is essentially correct, of course with a bunch of details to gua= rantee that everyone gets the same keys.
It remains mostly= unchanged from what we have currently.

The m= ajor thing I would be worried about in such a split is how it would deal= with authority over changes, which affect the authentication properties= of the protocol.  The current Proposals proposal maintains the pro= perty that everyone agrees on the proposals and can verify that they wer= e proper, e.g., only the holder of a leaf can update that leaf.  If= we sever the connection between the proposals and the top-level transcr= ipt entirely, then I'm not sure how you would continue to assure that, s= ay, the sender of a Commit didn't just swap out Joe's leaf key for the N= SA.

The changes wo= uld be signed by the sender, as usual. The only question is whether this= signature is enough, without binding the signature to the key exchange = transcript or current epoch secret.
Note that the tree syn= chronization protocol has its own transcript on how the tree has changed= over time, and certainly we could require each update to sign this =E2=80= =9Cstate history=E2=80=9D transcript.
We should of course = impose the requirement that only the "holder of the signature key corres= ponding to a leaf=E2=80=9D can update that leaf.
In fact, = the tree update protocol can ensure that only members of a subtree can c= hange the root of that subtree.
This is what we guarantee = now anyway. I don=E2=80=99t see that substantially changing in the decou= pled design.


I agree that ther= e is degree of separation here (since, e.g., it's easy to imagine swappi= ng in a "list of keys" KEM for TreeKEM).  But it seems like a fairl= y high degree of coupling is necessary to maintain authentication.

So, what would be the a= uthentication property you would want for a tree change?
T= he tree changing sender must know the signature key for a member *and mu= st also know the current epoch secret*?

Per= haps what you are pointing out is that we cannot remove signatures from = the key exchange protocol, and so we=E2=80=99d end up needing two signat= ures; one for tree synchronization and the other for authenticating the = key exchange.
Actually, we also need a third signature for= the message protection. How and when we can share these signatures is a= n optimization problem, but they serve different purposes.

-Karthik


--Richard



= On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan <karthikeyan.bhargavan@inri= a.fr> wrote:
Hello All,
It seems to me that o= ne way to think about =E2=80=9Claziness=E2=80=9D would be to cleanly sep= arate the MLS key exchange into two different protocols.
The first is a =E2=80=9Cclassic=E2=80=9D authenticated sync= hronization protocol where members of a group can create and modify a sh= ared data structure (in this case, the group membership tree).
=
The second is a novel key establishment protocol wher= e some member of the group generates a fresh group secret that will be d= elivered only to the current members computed from the (current) group s= tate.
Currently the first and second protoco= ls are tightly interleaved: every time the group data structure is modif= ied by some member (or admin), that member must also generate and distri= bute the fresh group secret.
The laziness pr= oposal can be thought of as detaching the two protocols: the key establi= shment protocol can follow group modifications with some delay.

So rather than trying t= o add =E2=80=9Claziness=E2=80=9D to the existing protocol, should we try= to do this detachment in a principled way by defining two independent s= ub-protocols?
It would have the advantage th= at we may be able to consider other designs for synchronization and key = establishment, which may well be orthogonal concerns.

In our model of MLS, we can alrea= dy factor out the protocol in this way, but it makes the security invari= ants a bit harder to express in a user-friendly way.
Still, I would prefer to compose proofs for simpler sub-protoco= ls rather than try to prove security for a single complex protocol with = lots of options.

Best,
-Karthik


On 23 Aug 20= 19, at 10:48, Richard Barnes <rlb@ipv.sx> wrote:


<= div style=3D"font-family:georgia, serif;">
On Fri, Aug 23, 2019 = at 10:21 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 23/08/201= 9 15:10, Richard Barnes wrote:
> 
> I'm not clear on what you mean by "meaningfully handled by me= mbers".
> 

I'm assuming that MLS protocol data = will likely be
handl= ed by a library. ISTM more likely that such a
library might default to, or be carelessly use= d to,
honor anything= the server proposes if this is an MLS
protocol feature rather than an application layer
=
feature. That'd be an e= xample of not meaningfully
handling this:-) We have seen similar kinds of
failure with applications and TLS libr= aries in the
past wh= ere certs aren't checked etc.
<= br>
Oh I see.  That would actually be a pre= tty difficult policy to implement, at least without turning off authenti= cation altogether, at least in the envisioned protocol.  By which I= mean:

- Right = now, clients are expected to maintain a list of members' signing keys
- So signers are just indicated by their index= in that list
- The obvious way to add non-m= ember signers is to reserve a block of indices (say 0xFFFFFFxx) that can= correspond to application-specific entities
- Then clients need to get configured with which server keys go with wh= ich reserved indices

Assuming we go in that direction, the natural, "I don't care about= server-initiated stuff" library design would be to just not implement a= ny special handling for those reserved indices, in which case you'll rej= ect anything from the server.  I would expect a library that does a= nything else to have an API for the configuration required in the last p= oint.

The obvio= us screw-up case would be, "Treat a signature from the reserved block as= trusted".  But that's actually a little hard to implement; because= the public keys aren't provided, you would have to also not do any sign= ature verification at all, which means you're now totally open to the wo= rld.  Hopefully that would raise some red flags for developers.
=

So it's not imposs= ible to screw up, but not trivial either.  At least if you want to = maintain authentication for group members.  If you turn that off to= o, I don't think we can save you.

=
--Richard  

 

I = do accept the argument that it can happen at the
application layer if not defined in the MLS= protocol,
but doing= this kind of thing at the application layer
seems safer to me.

It's also not clear to me that all MLS applications
would need this feature. (That may = be true, I just
don'= t know.) If they don't, then again, it seems to
be more conservative to leave it to applicat= ions.

I agree that there are sharp edge= s however this kind
= of thing is done though.

Cheers,
S.
<= /div>
_______________________________________________
=
MLS mailing list
_= ______________________________________________
MLS mailing= list
MLS@ietf.org
https://www.ietf.org/mail= man/listinfo/mls


--2595ba6b76d840188c5c25255aa2f6ce--