From nobody Thu Jan 3 05:15:39 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 4723F130D7A for ; Thu, 3 Jan 2019 05:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 3BTXEXh_7rk2 for ; Thu, 3 Jan 2019 05:15:34 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 C097F12EB11 for ; Thu, 3 Jan 2019 05:15:34 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id s5so29311194oth.7 for ; Thu, 03 Jan 2019 05:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YrpWFXprp/RpkmzZZqAKTsG1arVfH4bX3ey0znEeqb8=; b=BKbCjqR+b9Kd+CC8/lVqal6+NLaabgMfYsgRxD6D0F8GHbZ0s0YtWwlmAgGTNw8kHO kk0cP9BH9WK0RfJKpGkCi2Hvv6CUaWzMNg6fIjxhxwJvh9Ry+ZdGcysDAGTsOEkj0BkH Dl4bnpstV+1iOkNpOnLz60h/8CXulfCT6YJKlHhpYs1gXj2b2Byi4WF7yDZRHTA1iU/3 mPDuNA2dy74rwIT4KcuClfI8g+ImxDIly0Iv/Xc7rRBUeQNxoHRrc9iu5W41mLuJWTOp yHQbKfyjNhcWTzZLrGV84u5gPcohzqHqdrZYd+PFvetvt90Q2U2rgtvU+sSfgykiJsEs RklQ== 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=YrpWFXprp/RpkmzZZqAKTsG1arVfH4bX3ey0znEeqb8=; b=P9Df7i/mIdQprTW1iygDJcrXd4fMzrN6X9tpW2BUYuaXe+ZbBno4J0u5mZMXKuP3OS DE/g01F1JusB+nrqTihvhXbJV806y30iESoMaX1steCdIDMreszblzzD+1Dl9NNicM45 6pWL3tMbvUz8jtel9tajDQDztUKtSOmim16l+Jhy33UqNT8EPozkPiJ2VVdhvpvCaLLW z4E58TRFwvkcR07/opG1RybK+HsEHZPcsZwjsVELtg3VYkcIlnxs16488o4DpnWb3fy+ Xvp6wPmOp4AaANaV9kPQdxfxGF1EwyVaeTRbm2bEVUS75+3KAxQlcld6hstiealQcEri wL/Q== X-Gm-Message-State: AJcUukfVIF2xVizaK3I4nUFJyTL/zZ92gomzSeCOAD/SM3v2Q/mTVYUW vRsbmokUwcWvPj+m+Mn6DKB2VeFz1qKFWRXUZwyJ2mpGAbs= X-Google-Smtp-Source: ALg8bN7zNiob+wR4igZQ4tXrVQHPtZz3d4eJjSLQxsDO+Z9/Uwek3yY6HFO+laMm32smI0au+Sws4sRfZjFn4GOQ0+g= X-Received: by 2002:a9d:2f64:: with SMTP id h91mr33130853otb.14.1546521333728; Thu, 03 Jan 2019 05:15:33 -0800 (PST) MIME-Version: 1.0 From: Raphael Robert Date: Thu, 3 Jan 2019 14:15:22 +0100 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000bc1d4e057e8d8ec7" Archived-At: Subject: [MLS] Lazy handshake 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, 03 Jan 2019 13:15:37 -0000 --000000000000bc1d4e057e8d8ec7 Content-Type: text/plain; charset="UTF-8" Hi all, Currently Update handshake messages are computed in an eager fashion: the sender of a message has to do most of the work (O(log n) - O(n)) and other group members just consume the HS message in O(1). This leads to a bottleneck situation when a new device is added or removed by a user (as explained at IETF 103). Depending on what multi-device mode is being used (concealed devices under the own leaf node or 1 device per leaf node), either and Update or an Add+Update have to be carried out in every group. This can lead to costly operations (at least O(log n) ECIES operations, worst case O(n) ECIES operations) in potentially hundreds of groups. Adding a new device or removing an old one can therefore lead to considerable UX lag, because these operations cannot really be done in the background and therefore constitute a large blocking atomic operation. The following explores the idea of considerably reducing the size of the atomic operation by asynchronously outsourcing expensive calculations to other members of the group. Lazy Update ----------------- Steps: 1. The sender creates a new leaf node (NLN), but doesn't "hash it up". 2. The public key of the NLN is sent to the group in a new HS message (LazyUpdate) 3. Everyone in the group replaces the old leaf node (OLN) of the sender with the new leaf node (NLN) 4. Everyone blanks the sender's direct path Aside from creating the new leaf node, no cryptographic operations have taken place. This means FS and PCS are not guaranteed yet. Every LazyUpdate therefore has to be followed by a regular Update, no other regular HS message is allowed to follow a LazyUpdate (and must be rejected by recipients). The regular Update can be issued by anyone in the group using node resolution. That way the owner of the OLN cannot know the new group secret (PCS) and the owner of NLN cannot know the old group secret (FS). The idea behind this approach is that costly operations can be spread over time, as there is no need to issue the regular Update right away. If a group is completely inactive, i.e. no messages are being sent, there is no need to rotate the group secret pre-emptively, it can rather be rotated "just in time". The owner of the NLN only needs to know the current init secret of the group to be able to process the regular Update that follows the LazyUpdate. This means that several LazyUpdates can be stacked before a regular Update is issued. Naturally every subsequent LazyUpdate will further unbalance the tree and thus reduce efficiency. It is therefore recommended that active members issue Updates as soon as they see fit, however each member can apply its own strategy. For example, mobile devices might not do Updates as frequently as PCs because of resource constraints. Ideally, the owner of the NLN will do the regular Update themselves. In that case the secret of the NLN probably can just be "hashed up" and KEMed to its resolved copath. This would then be a "slow Update" stretched over 2 phases: Announcing the public key of the node leaf first (in the LazyUpdate message), doing the KEMing later (in the Update message). A similar concept can potentially also be applied to Remove HS messages, where a member merely announces the removal, everyone else blanks the direct path of the removed member, but the key rotation (by means of issuing an Update HS) only occurs later. Raphael --000000000000bc1d4e057e8d8ec7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Currently Update handshake messages are computed in an eager fashi= on: the sender of a message has to do most of the work (O(log n) - O(n)) an= d other group members just consume the HS message in O(1).

This lead= s to a bottleneck situation when a new device is added or removed by a user= (as explained at IETF 103). Depending on what multi-device mode is being u= sed (concealed devices under the own leaf node or 1 device per leaf node), = either and Update or an Add+Update have to be carried out in every group. T= his can lead to costly operations (at least O(log n) ECIES operations, wors= t case O(n) ECIES operations) in potentially hundreds of groups.

Add= ing a new device or removing an old one can therefore lead to considerable = UX lag, because these operations cannot really be done in the background an= d therefore constitute a large blocking atomic operation.

The follow= ing explores the idea of considerably reducing the size of the atomic opera= tion by asynchronously outsourcing expensive calculations to other members = of the group.

Lazy Update
-----------------

Steps:

= =C2=A0 1. The sender creates a new leaf node (NLN), but doesn't "h= ash it up".
=C2=A0 2. The public key of the NLN is sent to the grou= p in a new HS message (LazyUpdate)
=C2=A0 3. Everyone in the group repla= ces the old leaf node (OLN) of the sender with the new leaf node (NLN)
= =C2=A0 4. Everyone blanks the sender's direct path

Aside from cr= eating the new leaf node, no cryptographic operations have taken place. Thi= s means FS and PCS are not guaranteed yet.
Every LazyUpdate therefore h= as to be followed by a regular Update, no other regular HS message is allow= ed to follow a LazyUpdate (and must be rejected by recipients). The regular= Update can be issued by anyone in the group using node resolution. That wa= y the owner of the OLN cannot know the new group secret (PCS) and the owner= of NLN cannot know the old group secret (FS).

The idea behind this = approach is that costly operations can be spread over time, as there is no = need to issue the regular Update right away. If a group is completely inact= ive, i.e. no messages are being sent, there is no need to rotate the group = secret pre-emptively, it can rather be rotated "just in time".
The owner of the NLN only needs to know the current init secret of the= group to be able to process the regular Update that follows the LazyUpdate= . This means that several LazyUpdates can be stacked before a regular Updat= e is issued. Naturally every subsequent LazyUpdate will further unbalance t= he tree and thus reduce efficiency. It is therefore recommended that active= members issue Updates as soon as they see fit, however each member can app= ly its own strategy. For example, mobile devices might not do Updates as fr= equently as PCs because of resource constraints.
Ideally, the owner of t= he NLN will do the regular Update themselves. In that case the secret of th= e NLN probably can just be "hashed up" and KEMed to its resolved = copath. This would then be a "slow Update" stretched over 2 phase= s: Announcing the public key of the node leaf first (in the LazyUpdate mess= age), doing the KEMing later (in the Update message).

A similar conc= ept can potentially also be applied to Remove HS messages, where a member m= erely announces the removal, everyone else blanks the direct path of the re= moved member, but the key rotation (by means of issuing an Update HS) only = occurs later.

Raphael
--000000000000bc1d4e057e8d8ec7-- From nobody Fri Jan 4 08:04: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 7A798127AC2 for ; Fri, 4 Jan 2019 08:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 wtt7rfTsNbGB for ; Fri, 4 Jan 2019 08:04:21 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 B7801130DF2 for ; Fri, 4 Jan 2019 08:04:21 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id BC4DF1ABDE6 for ; Fri, 4 Jan 2019 08:37:21 -0700 (MST) Received: from box514.bluehost.com ([74.220.219.114]) by cmsmtp with ESMTP id fRXFgGsSFu4p1fRXFghKoq; Fri, 04 Jan 2019 08:37:21 -0700 X-Authority-Reason: nr=8 Received: from c-67-188-154-250.hsd1.ca.comcast.net ([67.188.154.250]:58831 helo=[10.0.0.188]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gfRXF-0047Ri-4H for mls@ietf.org; Fri, 04 Jan 2019 08:37:21 -0700 From: =JeffH To: Messaging Layer Security WG References: Message-ID: Date: Fri, 4 Jan 2019 07:37:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Kingsmountain.com X-BWhitelist: no X-Source-IP: 67.188.154.250 X-Source-L: No X-Exim-ID: 1gfRXF-0047Ri-4H X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-67-188-154-250.hsd1.ca.comcast.net ([10.0.0.188]) [67.188.154.250]:58831 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [MLS] Fwd: XRD: Scalable Messaging System with Cryptographic Privacy 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, 04 Jan 2019 16:04:25 -0000 Of possible interest... -------- Forwarded Message -------- Subject: Tuesday, January 8 -- Albert Kwon: XRD: Scalable Messaging System with Cryptographic Privacy Date: Thu, 3 Jan 2019 19:42:20 -0800 From: Saba Eskandarian To: security-seminar@lists.stanford.edu  XRD: Scalable Messaging System with Cryptographic Privacy                         Albert Kwon                   Tuesday, January 8, 2019                        Talk at 4:15pm                          Gates 463A Abstract: Even as end-to-end encrypted communication becomes more popular, private messaging remains a challenging problem due to metadata leakages, such as who is communicating with whom. Most existing systems that hide communication metadata either (1) do not scale easily, (2) incur significant overheads, or (3) provide weaker guarantees than cryptographic privacy, such as differential privacy or heuristic privacy. In this talk, I will presents XRD, a metadata private messaging system that provides cryptographic privacy, while scaling easily to support more users by adding more servers. At a high level, XRD uses multiple mix networks in parallel with several techniques, including a novel technique to efficiently and privately verify the correctness of mix network operations. As a result, XRD is more than 10x faster than prior messaging systems that provide cryptographic privacy. Bio: Albert Kwon is a sixth year student at MIT working with Srini Devadas. He is broadly interested in applied cryptography, and likes to design and implement systems that can enhance users' privacy. His most recent focus has been on anonymous and private communication systems. From nobody Fri Jan 4 10:31: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 6A71F130E73 for ; Fri, 4 Jan 2019 10:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 k14eN219oB75 for ; Fri, 4 Jan 2019 10:31:40 -0800 (PST) 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 1AE03130E74 for ; Fri, 4 Jan 2019 10:31:40 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id 81so32843967otj.2 for ; Fri, 04 Jan 2019 10:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cylBuDIRyxS4sQvAVAdf59yybbaDj+reM/c/YDLgtpM=; b=HnLKu1l3/OI1NYVipcyDdTuiwV3yW/sOWIEGyKW+807/KFXAMyZCNvlm0NA1X//QAw ZCB+VkZJMZgyjfp1TDc7WSKZtvOGAeRi3Mw0ttPYb+ML705ogvSwr/Luw768MVw9o9lQ o4TXnNYpBQcb6t1bkhf+SrdlgoQYxnK0YIEhWYLyxO2eMFIFe4bRBvxinLK8QXaGc2Zt nbtM822mdet//n2nEB87pHnNrj0rxu6MEBtStZ8FtUtMIvZSyk24Qj4hkieMzORC2j0Z rmL76PZlGLNdWw9OtLH0LyHExKutSrIrMALIOM/0OZQxrYau6YtxSD4v+dPUUsf1MDza OagA== 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=cylBuDIRyxS4sQvAVAdf59yybbaDj+reM/c/YDLgtpM=; b=Sq2uiBMVRTgZB0hs3beBbhvMsB5qQfQDiCnhXXAPYObz8pr5MT+lUGx09gwa50tVZz uJLVxBvxClA5rHEa1WfmI7tnSdRBVIzDudHCiNz5CP27OrtGsysti5OrCbu/ZB4aZdwj x9fTOd/esGNrghofqIwlMFE6PbOSzqnVTkwsjpWsBF809hWkycBmEGPv9JsSfDnMtiOe OI8/WdECvFomOXjqHmpMl9VzaCJ7snQdFHbT52FOi0yRap+h1h0wX0Vf69cN5na1jnuW rWshNhBo+dkQC3roZNsZYxDxaEen6XmFDSzsiclvf2ThmZMRM9GbG4BtrgyNY3M85JNr dqCg== X-Gm-Message-State: AJcUukfHrvAWoUoulzaqXXDormYvGgbWfQDpwGj8UddcqlzKZxiKOjW5 LRGDXi0Az2xTDRNzMneA8tqbSZpAh3DcQQcYsOoSnw== X-Google-Smtp-Source: ALg8bN6vlFzdu2fcPnciuvOq5s1ejwIZAmUZCirMcb5u0Na8Gp8Ovocyb5EJzhplyUG2+WkRdrpmQB/5lMPeM3AGsJE= X-Received: by 2002:a9d:191a:: with SMTP id j26mr38393680ota.81.1546626699280; Fri, 04 Jan 2019 10:31:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 4 Jan 2019 13:31:13 -0500 Message-ID: To: "=JeffH" Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000002d8ea057ea61704" Archived-At: Subject: Re: [MLS] Fwd: XRD: Scalable Messaging System with Cryptographic Privacy 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, 04 Jan 2019 18:31:43 -0000 --00000000000002d8ea057ea61704 Content-Type: text/plain; charset="UTF-8" Interesting. Looks more metadata-focused than MLS; curious to see if it might dovetail well. Albert was involved in some pre-BoF MLS discussions. I think he might even be on this list? On Fri, Jan 4, 2019 at 11:04 AM =JeffH wrote: > > Of possible interest... > > -------- Forwarded Message -------- > Subject: Tuesday, January 8 -- Albert Kwon: XRD: Scalable Messaging > System with Cryptographic Privacy > Date: Thu, 3 Jan 2019 19:42:20 -0800 > From: Saba Eskandarian > To: security-seminar@lists.stanford.edu > > > XRD: Scalable Messaging System with Cryptographic Privacy > > Albert Kwon > > Tuesday, January 8, 2019 > Talk at 4:15pm > Gates 463A > > Abstract: > > Even as end-to-end encrypted communication becomes > more popular, private messaging remains a challenging problem > due to metadata leakages, such as who is communicating > with whom. Most existing systems that hide communication > metadata either (1) do not scale easily, (2) incur > significant overheads, or (3) provide weaker guarantees than > cryptographic privacy, such as differential privacy or heuristic > privacy. > In this talk, I will presents XRD, a metadata private messaging system > that provides cryptographic privacy, while scaling easily to support > more users > by adding more servers. At a high level, XRD uses multiple > mix networks in parallel with several techniques, including a > novel technique to efficiently and privately verify the correctness of > mix network operations. As a result, XRD is more than 10x > faster than prior messaging systems that provide cryptographic privacy. > > Bio: > > Albert Kwon is a sixth year student at MIT working with Srini Devadas. > He is broadly interested in applied cryptography, and likes to design > and implement systems that can enhance users' privacy. > His most recent focus has been on anonymous and private communication > systems. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000002d8ea057ea61704 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting.=C2=A0 Looks more metadata-focused than M= LS; curious to see if it might dovetail well.

Albe= rt was involved in some pre-BoF MLS discussions.=C2=A0 I think he might eve= n be on this list?

On Fri, Jan 4, 2019 at 11:04 AM =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:

Of possible interest...

-------- Forwarded Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tuesday, January 8 -- Albert Kwon: XRD:= Scalable Messaging
System with Cryptographic Privacy
Date:=C2=A0 =C2=A0Thu, 3 Jan 2019 19:42:20 -0800
From:=C2=A0 =C2=A0Saba Eskandarian <saba@cs.stanford.edu>
To:=C2=A0 =C2=A0 =C2=A0security-seminar@lists.stanford.edu


=C2=A0 =C2=A0XRD: Scalable Messaging System with Cryptographic Privacy

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Al= bert Kwon

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tuesday, January 8, 2019
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Talk at = 4:15pm
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Gates 463A

Abstract:

Even as end-to-end encrypted communication becomes
more popular, private messaging remains a challenging problem
due to metadata leakages, such as who is communicating
with whom. Most existing systems that hide communication
metadata either (1) do not scale easily, (2) incur
significant overheads, or (3) provide weaker guarantees than
cryptographic privacy, such as differential privacy or heuristic
privacy.
In this talk, I will presents XRD, a metadata private messaging system
that provides cryptographic privacy, while scaling easily to support
more users
by adding more servers. At a high level, XRD uses multiple
mix networks in parallel with several techniques, including a
novel technique to efficiently and privately verify the correctness of
mix network operations. As a result, XRD is more than 10x
faster than prior messaging systems that provide cryptographic privacy.

Bio:

Albert Kwon is a sixth year student at MIT working with Srini Devadas.
He is broadly interested in applied cryptography, and likes to design
and implement systems that can enhance users' privacy.
His most recent focus has been on anonymous and private communication
systems.

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000002d8ea057ea61704-- From nobody Fri Jan 4 12:36: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 D4459130E8F for ; Fri, 4 Jan 2019 12:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZFKpdQKnxkjs for ; Fri, 4 Jan 2019 12:36:14 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0: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 D3EFB1200D7 for ; Fri, 4 Jan 2019 12:36:13 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id e12so33132981otl.5 for ; Fri, 04 Jan 2019 12:36:13 -0800 (PST) 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=o+lUsx+KKC8xN49RFLRbudo02X3trDu5L77sDAtpwwI=; b=WWCFSDY+4S14UKUiAbHl/nfYENbLh2GZwCLIPsQ8lag3iRLWGa2/9wZo5aPoQshgZE qaTW/BzubbUgknJXFDm3FjqaNlaasIOtmVIWV1W0k1R90qUW86iJ+eBFfsu22355HsS8 RkLN4SM2od9oSQyQ/CTSFMRPAMZ0a+HqEU73XwqWDxmGUCO+R4J+nPts1pOuuPOy7QKO LAsTpKSjwot2V2Ep/vuPXFb2Zst9VR9BXD7jifHTotTJcHNeYRGT2jncU3jkOy2VcmeI 1gu0Y99RxAIwgYKm2QNOhXtHLHpg0LYxP6D9uyI+3s+A12gq4fPlystbWP3yFQHhdLRW 6q4g== 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=o+lUsx+KKC8xN49RFLRbudo02X3trDu5L77sDAtpwwI=; b=X9s9KM3OAtxOqQ9nlpTNt+opyF3faYEYqVtFRd+2pCxiJXdnixgV0AeEflOScplpmF ea59Ac/ZgL0dTPvtWDKhTDpKSDY4KE15D+fp4HcEWlC2X89hsR2yHcCbNDFb/6oGT7gD YRJt011Esa7oTl+W74GpUCch4XD64fyWJJMhXgXQzT/4P9ktry2TejcrrMBAoJzLM/Xs F34itdoIxQGFW4i+vmtVZtGWc/ypKg2LmJcGHNiVTPGysOvf61LWbgBglFG44A1MJAKG CmIr0cHhqprWgFLTttye5STljtEOuMPEtRWldODQKw/AOxj6MaUoupxCYZR3abOajUna yu6g== X-Gm-Message-State: AJcUukfCzipAj7apZhWeVcyzJrIQJuCHmIzxPSx/Cp/iCw1KcawTWaTk ejzpCI7omBdHPrvKKZrQgiWG3iuajcYU4xSFX/vMrqwfu3g= X-Google-Smtp-Source: ALg8bN5Bb34fJbb3BFKnIytFxcDkJWSO9AKlOHxnI0JzOB+kiF/kZyUytN/WobwGAUeqM24o7D4ZUbEw3Y5SS1Fz/0k= X-Received: by 2002:a05:6830:1584:: with SMTP id i4mr33964583otr.116.1546634172690; Fri, 04 Jan 2019 12:36:12 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Fri, 4 Jan 2019 15:35:47 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000760458057ea7d4c4" Archived-At: Subject: [MLS] Bugfixes and simplifying authentication 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, 04 Jan 2019 20:36:16 -0000 --000000000000760458057ea7d4c4 Content-Type: text/plain; charset="UTF-8" Hey all, I just submitted a couple of PRs. #81 addresses some minor issues, mainly relating to the spec's internal consistency [1]. #82 makes some simplifications to the signature and MAC computations used for authentication, making them more analogous to TLS [2]. If we can get these reviewed and merged soon, I'll issue a new draft before the interm. In a similar vein, please file any PRs you might have lying around ASAP if you want them in before the interim. Thanks, --Richard [1] https://github.com/mlswg/mls-protocol/pull/81 [2] https://github.com/mlswg/mls-protocol/pull/82 --000000000000760458057ea7d4c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,
=
I just submitted a couple of PRs.

#= 81 addresses some minor issues, mainly relating to the spec's internal = consistency [1].

#82 makes some simplifications to= the signature and MAC computations used for authentication, making them mo= re analogous to TLS [2].

If we can get these revie= wed and merged soon, I'll issue a new draft before the interm.=C2=A0 In= a similar vein, please file any PRs you might have lying around ASAP if yo= u want them in before the interim.

--000000000000760458057ea7d4c4-- From nobody Fri Jan 11 16:34:57 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 E3E3A130E2B; Fri, 11 Jan 2019 16:34:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <154725328788.21830.13762623602618793607@ietfa.amsl.com> Date: Fri, 11 Jan 2019 16:34:47 -0800 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-03.txt 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: Sat, 12 Jan 2019 00:34:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-03.txt Pages : 45 Date : 2019-01-11 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-03 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 13 15:13:01 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 D29EA12D4EB for ; Sun, 13 Jan 2019 15:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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 HGWlRfUcGojm for ; Sun, 13 Jan 2019 15:12:57 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 BB68A12008A for ; Sun, 13 Jan 2019 15:12:57 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id x30so17297478edx.2 for ; Sun, 13 Jan 2019 15:12:57 -0800 (PST) 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=TGLi0TaxxwMBakSqi77ZlLUc/k4pGPaRbzkFaeK1wlc=; b=HHLVl7Z6eeZ+vE36tsL5epjBNAl1w2w63D3uCFFCV0V/toQj0VwWOYCdgXoEMgfRO2 7j7CZ/UEnYO/0MRB8w1QjLBxye2HKrL5z3rvSUsvxOISLbrb4mHJsMTR5Cy8RTgRJxU8 GIHSGIwmzz94ajfpEXKvYNb3DwLpn7RIUVa6w= 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=TGLi0TaxxwMBakSqi77ZlLUc/k4pGPaRbzkFaeK1wlc=; b=iF4be3oAGaDkfZaz0IsY91v5dGJ6Gdx5yi7nt2i5BRmvNxjv7fHoboKnL2iPMuwop5 8vVFoGzW8pWHqlKwgBaBKE6zcDrgz4TISt7M1kDmwuFWUk3tQnCd19giwYmrDWX0WyYY 5CAFKIKBMm4OpmRcTAo36z9kPiHXQN8glETBOKevt2Xye+G7Ku9Xu9VwqIFTcMFcVWYJ BQ9WGCqIOil44WlHxLQB4aTzWTOYkhrbuolWEiZyzqXoE4CT2/vPO5TjF6PHt5upWgq2 N3FmMSKlDc5/NA0OR6mxsRAbzaL0J4GjFFW1OVb7EG11ybHZr99LIeFrVpVXaU0G/Zgo BxIA== X-Gm-Message-State: AJcUukeU+vGzyg4TNW502OG4H7syx498xz2/8p64Udhz3QFZ3WMpF21O tXysABojgbvJsDV/uuCzcqPoPlglzOdaoQ== X-Google-Smtp-Source: ALg8bN4P63QRM4Yfv7CmnUDg5fJg3rJT9JcIUz4z/IjLKy3gByijUqfwd6R6l2JGAs5AA/V/Swb5Ew== X-Received: by 2002:a50:9784:: with SMTP id e4mr20820185edb.165.1547421175788; Sun, 13 Jan 2019 15:12:55 -0800 (PST) Received: from [5.5.33.149] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id n11-v6sm2141428ejh.74.2019.01.13.15.12.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jan 2019 15:12:55 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 13 Jan 2019 15:12:51 -0800 References: To: mls@ietf.org In-Reply-To: Message-Id: <48924B15-E278-4E3C-BB31-72EE8AC660E9@sn3rd.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [MLS] reminder: MLS WG JAN 2019 Interim Meeting - WebEx Details X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2019 23:13:00 -0000 For those attending remotely, here are the webex details. spt > On Dec 13, 2018, at 19:50, Sean Turner wrote: >=20 > The WebEx details have been uploaded to the github meeting materials = repo available @: >=20 > = https://github.com/mlswg/wg-materials/blob/master/interim-2019-01/README.m= d >=20 > Please note that the meeting details are different for Monday and = Tuesday. If you=E2=80=99re having any problems please email the chairs = @ mls-chair@ietf.org or look for us the jabber room @ = mls@jabber.ietf.org. >=20 > Cheers, > Nick and Sean From nobody Sun Jan 13 17:27: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 1ABC9130E6E for ; Sun, 13 Jan 2019 17:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 FlT9WNgtIAOo for ; Sun, 13 Jan 2019 17:27:27 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 283B8130E65 for ; Sun, 13 Jan 2019 17:27:27 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id t204so16613564oie.7 for ; Sun, 13 Jan 2019 17:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gbBIdZTs7blebRe9jxqFmvbllPf31PlV32YqHGz2jPA=; b=NCTa2SlpxMxtvtDK1zNQO4mC6q7SaIcowh7Hox9dV+gIE1R9JPFFMbcK72L9XoHmCk uIoxOAZDsbSt5TNReyyv8AjQmWNlPLYZy2K5N10Va9urX7x0tM1SmB+P9nLQLdwT+wWy +fDKbEGhxgVXK6Ll1rBSo3HSxsPh1G1ezkoes= 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=gbBIdZTs7blebRe9jxqFmvbllPf31PlV32YqHGz2jPA=; b=d7a4y1W0rQk2xvpifRZxfJ3UtuS9o449889tnmQjaMjFwLF97lbi9F4GFwFOoFiWD7 ZonM9GCVr73hdBo1S86dOXBEl1gSmWfYlw24tb9Abdz4qlY0gJRzefFPs/zAHY/OlITI Iizxi4i6GcnApW8QVOhlUXSC3h9+/ct2kL6B4Cgb+GGx5rQ+nBG6gATLrsN31wmsmDGP 8N7WQRZHXwtTJFLBliA2wM5DHqDzqhkX02YrqmmMZyDHb50qpa+/RKRV3rEZu95hlp7D iLba02RaOm1ns8ExOpTKL8/0pmQkxHp0rWHgNbHpY8X//Q05Ae6Ksp1GCkMrpxb5iVYL bxmw== X-Gm-Message-State: AJcUukfw3vWqo27q0U5NoR9n6O4rruN3xPK9I0Lx9jnrWlU9tIhardfV 0lF9toomhDtJTwG3gagdsIewzRTG+uSwKy5OQF7WYw== X-Google-Smtp-Source: ALg8bN5WIbqqrMlhSV3cr0Tep+3XVI3q56s09KIg1bYpbdTvCUXo9dOi09xn5Dj1re1msLggvyMHzRKICYIsS7EikxA= X-Received: by 2002:aca:be41:: with SMTP id o62mr14146399oif.206.1547429246149; Sun, 13 Jan 2019 17:27:26 -0800 (PST) MIME-Version: 1.0 References: <48924B15-E278-4E3C-BB31-72EE8AC660E9@sn3rd.com> In-Reply-To: <48924B15-E278-4E3C-BB31-72EE8AC660E9@sn3rd.com> From: Nick Sullivan Date: Sun, 13 Jan 2019 17:27:14 -0800 Message-ID: To: Sean Turner Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000884b06057f60f269" Archived-At: Subject: Re: [MLS] reminder: MLS WG JAN 2019 Interim Meeting - WebEx Details 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, 14 Jan 2019 01:27:29 -0000 --000000000000884b06057f60f269 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a reminder for those attending in person, lunch will not be provided by the host. There are some lunch options nearby, including La Fiesta and all of Castro street. There is a chance of rain, so dress appropriately. Lunchtime is a great opportunity to meet the other attendees and work through some ideas. Nick and Sean On Sun, Jan 13, 2019 at 3:13 PM Sean Turner wrote: > For those attending remotely, here are the webex details. > > spt > > > On Dec 13, 2018, at 19:50, Sean Turner wrote: > > > > The WebEx details have been uploaded to the github meeting materials > repo available @: > > > > > https://github.com/mlswg/wg-materials/blob/master/interim-2019-01/README.= md > > > > Please note that the meeting details are different for Monday and > Tuesday. If you=E2=80=99re having any problems please email the chairs @ > mls-chair@ietf.org or look for us the jabber room @ mls@jabber.ietf.org. > > > > Cheers, > > Nick and Sean > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000884b06057f60f269 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a reminder for those attending in person, lunch will no= t be provided by the host. There are some lunch options nearby, including L= a Fiesta and all of Castro street. There is a chance of rain, so dress appr= opriately. Lunchtime is a great opportunity to meet the other attendees and= work through some ideas.

Nick and Sean

<= div class=3D"gmail_quote">
On Sun, Jan 13, 2019 at 3:13 PM = Sean Turner <sean@sn3rd.com> wr= ote:
For those attending remotely, = here are the webex details.

spt

> On Dec 13, 2018, at 19:50, Sean Turner <sean@sn3rd.com> wrote:
>
> The WebEx details have been uploaded to the github meeting materials r= epo available @:
>
> https://github.com/m= lswg/wg-materials/blob/master/interim-2019-01/README.md
>
> Please note that the meeting details are different for Monday and Tues= day.=C2=A0 If you=E2=80=99re having any problems please email the chairs @ = mls-chair@ietf.org<= /a> or look for us the jabber room @ mls@jabber.ietf.org.
>
> Cheers,
> Nick and Sean

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000884b06057f60f269-- From nobody Mon Jan 14 08:40:32 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 A9895131187 for ; Mon, 14 Jan 2019 08:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 3hrvZLlb2xZX for ; Mon, 14 Jan 2019 08:40:27 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (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 4D6D212D4E9 for ; Mon, 14 Jan 2019 08:40:26 -0800 (PST) Received: (qmail 96471 invoked by uid 0); 14 Jan 2019 16:33:31 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 14 Jan 2019 16:33:31 -0000 Date: Mon, 14 Jan 2019 11:40:14 -0500 From: Sofia To: Richard Barnes Cc: Peter Saint-Andre , mls@ietf.org, shivankaulsahib@gmail.com, jurre@autonomia.digital Message-ID: <20190114164014.GC1024@Sofias-MacBook-Pro.local> References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UFHRwCdBEJvubb2X" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS 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, 14 Jan 2019 16:40:31 -0000 --UFHRwCdBEJvubb2X Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey! Sorry for the late reply.. > Fantastic, glad to have you guys here. One productive way to get involved > would be to read the draft protocol document [1] and send email to this > mailing list with your thoughts. We are very interested in contributing still; but were very busy on OTRv4 t= hings. This month we will send our thoughts. I'll attend the coming meeting shortl= y, so see you there! > If deniability is > something that's important to you, it would be helpful to think about how > you could fit it in as an optional feature. Mmm... I'm very unsure if it makes sense and very unsure if it is possible.= We can discuss this on more detail. Thanks! -- Sof=EDa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --UFHRwCdBEJvubb2X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlw8u2oACgkQOZJhRPid mW/rIBAAnvW/dpIqcWj9yd+AmsK2kLmQODh4RFKKNeM3yUt2WqN1EREjCJqSClKF Vw7P+8OIUC8XlCK7dq1bx9gm6zZ0Pak9+R4gTc2qcilKNoK1ZLzaihfrTsbMhqlu kLnjb3+Dmm4yrBXJgvg3P6iP2otDYVEw+eE50WP4hQQTOUX3llTaTYcz5Dettzmq OLCOz1p9dmHu2lpBexC81aQj2KZI0yPcBxoBtvB5HXc16uO90S5lVq4Dco+ngoaP t/hWmBmLHuQnoIv9gPRjEM2Qgv29qzQSh5o6Eqqhg1N+3IxdU4waVOyA1jOpFJLd +DobV2HToBPSbwsWULi/w9Gr+E+obd+/c+D6ohnRSsjrB7QwJrIMehO2sSSPFtcw KadOMJt0UAGNhVAcCL4PdiPmcakQ4sOQ8xgQDh9aGKLlKAiCrLR9S/jdn09voEQo cifq2ZfetmyqFISUZghgcsXyCIrOxsQUKwiQvj66ukK4pXtBibqTf27EJuwkMpZT lCtoqWZ73EvTao8GUOxbfFBOo0zMJ9kzB0S9+L/6j4yT2iElA5Q1Zu4pJL81KDPV iqEamQ0QJasjKw9aJtcelpgIBQ7dQXs5TspDGtYTEYKleIzuJ9guTW6Mt/fGeCIj W2YJZKV7RROzzV/zSCJgVVEiqJInfvRVEUw0gcyUr03EG0zZQew= =W1rX -----END PGP SIGNATURE----- --UFHRwCdBEJvubb2X-- From nobody Mon Jan 14 08:46:32 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 A841B131187 for ; Mon, 14 Jan 2019 08:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4bGLr-50RTr0 for ; Mon, 14 Jan 2019 08:46:30 -0800 (PST) Received: from mail.autonomia.digital (mail.autonomia.digital [185.108.76.28]) (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 65C93131181 for ; Mon, 14 Jan 2019 08:46:29 -0800 (PST) Received: (qmail 96618 invoked by uid 0); 14 Jan 2019 16:39:36 -0000 Received: from mail.autonomia.digital (HELO mail.autonomia.digital) (sofia) by mail.autonomia.digital with ESMTPS (ECDHE-RSA-AES256-GCM-SHA384 encrypted); 14 Jan 2019 16:39:36 -0000 Date: Mon, 14 Jan 2019 11:46:20 -0500 From: Sofia To: Ian Goldberg Cc: nalini elkins , Richard Barnes , shivankaulsahib@gmail.com, mls@ietf.org, jurre@autonomia.digital, Peter Saint-Andre Message-ID: <20190114164619.GD1024@Sofias-MacBook-Pro.local> References: <20181108160935.GA4116@Sofias-MBP> <41b41184-3153-a780-acc6-64c1ec2cfb79@mozilla.com> <20181109031834.GT5018@yoink.cs.uwaterloo.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0IvGJv3f9h+YhkrH" Content-Disposition: inline In-Reply-To: <20181109031834.GT5018@yoink.cs.uwaterloo.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [MLS] Contribute as OTRv4 to MLS 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, 14 Jan 2019 16:46:32 -0000 --0IvGJv3f9h+YhkrH Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > On Fri, Nov 09, 2018 at 09:41:34AM +0700, nalini elkins wrote: > > > If deniability is something that's important to you, it would be hel= pful > > to think about how you could fit it in as an optional feature. > > > > Just to comment, there is a potential human rights issue (right to life) > > with deniability. Although extremely beneficial in a number of > > circumstances, it is my understanding that deniability can also be used= by > > people such as terrorists to fight lawful subpoenas. > > > > I wonder if that is of interest to this group. Please correct me if my > > understanding is wrong. I very much wish to be wrong. > > I can't figure out what you mean by that. Deniability (well, one form > of it anyway) is the property that the transcript of the protocol > messages does not imply the plaintext messages that were exchanged. > Another form is that it does not imply the participation of any > particular party. (There are other more complex forms involving online > informants.) Plaintext logs are deniable in these senses, since anyone > could easily forge them to say anything they like. If we're talking > subpeonas, note that courts accept plaintext as evidence all the time; > the role of a deniable protocol is to prevent the protocol transcript > from *mathematically* implying the message contents or participation. > (While at the same time the protocol strongly authenticates the > participants and the message contents to those *in* the conversation.) I completely agree with professor Goldberg on this. The idea of deniability= is to prevent the transcript from implying message contents and participation = while being strongly assured you are talking to whom you authenticated with duri= ng the conversation. I don't really understand the comment. Thanks! -- Sof=EDa Celi (aka cherenkov) @claucece / @cherenkov_d Cryptographic research and implementation at CAD: https://autonomia.digital/ EF74 1A5F 5692 E56F 14F6 243C 3992 6144 F89D 996F --0IvGJv3f9h+YhkrH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE73QaX1aS5W8U9iQ8OZJhRPidmW8FAlw8vNgACgkQOZJhRPid mW8iEhAAivfU1HRLYVE7IhEF+xMIs8jk/fdM9mvFZYzU5C2c6fuwt/C546bUwp+j n/kpC4l0s81txzGgTxdWBnYqXyY3E7rLyblXo6r1kkAESO8OYpBMtHs2UFbVNHvq zm8Wm1nv5oijZmobwQCPD8dUZChQHc1HdjjN1EchZoYtMm1ACYvXHOROoVRiUkec DuyvrWK+VtImpbs1gb2+o6/8+NEiysKOcFp0qkkBiUVsHr6lGPYmlu+BU2JW8xDU J8U9dafQAhHxDyv2BIg2p0Z2eaR4zwdEv0yq9SG9P7qYDXnC3ogARTdeQpJUaKRV JiKBc1G+GNz7LuCT16AMUaMVefcmOC8yeUcG5rztoj8TDyn81VNXBLAJg+1kV8W/ KA8mkmf9dj1iYP9yFrLg6mc0oi+ULy9O3q7B0KiAq6+2rLzWB38ZEg1TZ8FDMlti 6OUm3mHjzaGxsoWOJYHcUYM+Di1BK9yOnG6ssOxV3yIYvO0qipbnD7ZF9lR6BLJy 6o/Cuiy9cz9wXR7rPPuQwCbwqRk6x85IaMqBAAIKufmmSAxqKgMnFbY8zjpwSmW0 eDxtGWIvzkk0exnGjVOB1Rud4yRs40v8MemIm3lpUfy7YskV+0zCIlhgnvCuhnOZ ICrNJlBMxpw8oR0IsaduJi8IyPGSoSxykCFcOezwkgN3mreJ94E= =RGbJ -----END PGP SIGNATURE----- --0IvGJv3f9h+YhkrH-- From nobody Tue Jan 15 08:49: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 66610130EAB for ; Tue, 15 Jan 2019 08:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_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 DziyIv9lKO0x for ; Tue, 15 Jan 2019 08:49:33 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 BEB12130E7E for ; Tue, 15 Jan 2019 08:49:32 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id y20so3065973edw.9 for ; Tue, 15 Jan 2019 08:49:32 -0800 (PST) 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=YxrLvbI1KSTlV1RHEFj8IKcKj9rc8OcOtHHjVgqYKLU=; b=GbxZuxYy89dwmfRl3pVj8YaGajSj2czHjF50j5ilgusYCAFD6MmOmunI6vEX/dKbSf X0YhovUtMe2WueXEUE8klUJTlrcEaOhat7ycTCiHKkmc2+q+Dw0oDw53dOZwQXqXF4AS eNOYy4ePPbcwcyNifDrdj5+D0ILa8ME9n6qxo= 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=YxrLvbI1KSTlV1RHEFj8IKcKj9rc8OcOtHHjVgqYKLU=; b=QFMXVvScgTYTRhfCG8+zNdMQzjw4tL+VmplFCyAGmYSgHy+y2xowWcqW4l/7A+JdMA huR/fUlefRumK5BaMn9nPs6nyP0YVYG0Rs40T+nqWeAqjSyV8A+yX8kZk+P2QjVh9szn oRyt1V86nJZkc3vPAeTtKoSmzUcdydvSrDm15nadS/zJFSJI8aJLdmDMeo+ux+E76i6D w6oQYbZigSeW3dFHeALyAZfq5vn2Fg4D7w3x6t3sAByttbaX2mLxv4sGttPIJ0uT83cA 3qDOOsm/sK0gwFtkjo+Vt2+eOFxGvIF9v3ElQngzICfmVk9qbVT7G9MAPuJKM5MEp57k 2+nA== X-Gm-Message-State: AJcUukfwRrnq99t6Ey7K3HdioA+yqZZwTt7gAL3QNBWei2ZCwx89fb+h 0TuHbjGLhgqxDybg/wdGXWHe5xw72nLZcw== X-Google-Smtp-Source: ALg8bN58NScab1ONco82RRtTFO2vy7Gsf2NPG6J5LymlFyC4BQWSy3yvUn2/ci9tWEwVEG8jb8EJKg== X-Received: by 2002:aa7:ca0d:: with SMTP id y13mr3964350eds.285.1547570970953; Tue, 15 Jan 2019 08:49:30 -0800 (PST) Received: from [5.5.33.248] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id z2sm5209807edd.4.2019.01.15.08.49.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jan 2019 08:49:30 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 15 Jan 2019 08:49:26 -0800 References: To: mls@ietf.org In-Reply-To: Message-Id: <52BB3A06-9795-4544-BEE0-E9ED3E03DEDA@sn3rd.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] MLS WG JAN 2019 Interim Meeting - WebEx Details 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, 15 Jan 2019 16:49:37 -0000 Please note that I had some issues with today=E2=80=99s WebEx session = and had to start a new one. The meeting info has been updated in the gh = repo, but I am also sharing it here: meeting number: 317 416 284 password: (there is no pwd) > On Dec 13, 2018, at 19:50, Sean Turner wrote: >=20 > The WebEx details have been uploaded to the github meeting materials = repo available @: >=20 > = https://github.com/mlswg/wg-materials/blob/master/interim-2019-01/README.m= d >=20 > Please note that the meeting details are different for Monday and = Tuesday. If you=E2=80=99re having any problems please email the chairs = @ mls-chair@ietf.org or look for us the jabber room @ = mls@jabber.ietf.org. >=20 > Cheers, > Nick and Sean From nobody Tue Jan 15 11:40:29 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 94FCB12872C for ; Tue, 15 Jan 2019 11:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hKiBHIhPHVWj for ; Tue, 15 Jan 2019 11:40:23 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 A479B1294FA for ; Tue, 15 Jan 2019 11:40:23 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id m6so3055146oig.11 for ; Tue, 15 Jan 2019 11:40:23 -0800 (PST) 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=KVuEwwUvdSk3bTZmAekmbMnnJOITj4wRSZnh0c1cLpE=; b=XmTmmufhz9qu1q03cWIEwG8n986IOlFYGv0X6VYJCyIkKoQjIoW/ApFz40ajOqDhq+ l6mZtJg/jvYd13dXWk+zsBZt+xj/x2mfJKqAJRMpDBdl8RT9yXtP0mv6V+3YRqyZ9dG5 uUzs9GdyvnmZpe3ydG+OdW4UTXTldOg0vd0iw= 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=KVuEwwUvdSk3bTZmAekmbMnnJOITj4wRSZnh0c1cLpE=; b=BL9IhmHt6EZs2ccjRIfw7a6m7unwxQJePRJ612jlg3Jt1SyvsRcjGlfC4+UTUulB6G IvhgbGY/6VKhAzzahzYqmJI7JQ1cUYpKFP434hUPaR1+yf0jg5sEXOo5aDxwHvRDZAGf WxjnOJIuRbnMqwpwidMiJCYp8DEi7tdkwURhtEvlbowmbrFCylVEya8KAjtGf1nL8aU2 RjvwyJFQFGPHbbsRk6BoPlWdD4Ji82HmcTrG6KE3HK7fiEnuCrg8Py7IhMH92rSc+wJx RSou1rieHyecGhtp8sEh9hZo8Af+Hvs9JES564noubgzKv3sGYhAvicpmpVJXnWpZfEe EryA== X-Gm-Message-State: AJcUukcD4XrFRtQ2M31/tAIB0ff40vWZS4CxMPrMkF0svV+YiPk7kYov 66j3ipXQ6PF1UzPuiuofEfuPh6ClwuYI5HroleiZH8KRlUo= X-Google-Smtp-Source: ALg8bN5f6jBEh2bGX2CuukHzdXHf1z6QdPEy0RLjxfdBOWG034xccKDVg0zUiKsIgyb0L8n0dH9kT2yp5lfpCAc5ZXc= X-Received: by 2002:aca:be41:: with SMTP id o62mr1540753oif.206.1547581222601; Tue, 15 Jan 2019 11:40:22 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Tue, 15 Jan 2019 11:40:11 -0800 Message-ID: To: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000090c8d057f84554f" Archived-At: Subject: [MLS] Announcing: Public Wire group for MLS 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, 15 Jan 2019 19:40:27 -0000 --000000000000090c8d057f84554f Content-Type: text/plain; charset="UTF-8" There is now a public Wire group to help coordinate efforts on MLS. Please note that messages sent in the Wire group are not official IETF communications, so please continue to use the mailing list for substantial discussions. You can join here: https://app.wire.com/join/?key=qmrRRfaklMRm8UsYSqpA&code=KD8O6_Pvkli3pmzXbWtr Nick & Sean --000000000000090c8d057f84554f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is now a public Wire group to help coordinate e= fforts on MLS. Please note that messages sent in the Wire group are not off= icial IETF communications, so please continue to use the mailing list for s= ubstantial discussions.

You can join here:
https://app.wire.com/join/?key= =3DqmrRRfaklMRm8UsYSqpA&code=3DKD8O6_Pvkli3pmzXbWtr

<= /div>
Nick & Sean
--000000000000090c8d057f84554f-- From nobody Tue Jan 15 17:02: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 5D080130F90 for ; Tue, 15 Jan 2019 17:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lPhYFATKEtJa for ; Tue, 15 Jan 2019 17:01:56 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 BBBE2130F84 for ; Tue, 15 Jan 2019 17:01:56 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id v23so4459165otk.9 for ; Tue, 15 Jan 2019 17:01:56 -0800 (PST) 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=hqOdPh+NIaPHKWPoG5UDIAPHoNsBcR7V1/fxrTk+bgU=; b=uhjxIyWMMtoNH5/5q6boGRoFhde4woeg98f7xKqK9dfp282gELbReZHzJAmyOd2+Vc er8TdQM2U2/TwYWkGUs7D33AjoJJoMBJhCnjSLGrXWMbt3LzPefR4QIvJdWAKn15rmYa m9a+AnfHIUvG1mVlO+/oQebRypY6GGoWDuUs+S+45lazoTSS2QOO1QFD+Zk/21Uktyc1 QeFFn9WPFzba/5+VoER8FsZwbpnJOBVAalQ1AMffLleoGiCBWkeB0EnkxFJBt77JvodO lAJBca/NawD6kscrPi4mLWSkwNcriSS5IhpfCHujix7UtFWnw0ZxLv1AtIgsGlgFNbSG /OHg== 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=hqOdPh+NIaPHKWPoG5UDIAPHoNsBcR7V1/fxrTk+bgU=; b=GUmf/BipP3vwYJ+IGIldNZEd3pyg8yi9LH0oo0TSu2uIVz/u6y75PashrzxBcDkQYd AGfp6H7vB6CKPjfH4YJzUMtzTHsQyw5GOHszFTps4GhQERx0xqr9ym7I5/5dMXfWioyo 9szk1H5mnmxaLjAu8P+hYMERDGCR1HAKXgLPf9pobRI9pTLVcmhhAqOpbSSfuaHg5tI4 7iSjqROu4anM6/3ZES/MZ6Jm+ef46FyrAxPj2qAfVXNZJYQ+SDoDTZrvVlYh05mTRGcI KRI3nS93Iq7vUDaaiIPTAQJ/bo4rNdh5yCo6x3CV7BKYj9zF2iwTsxm53msfIGAZQMqV wjbQ== X-Gm-Message-State: AJcUukdKz/R5tUHlhJXYeBhmA+T8kx4+d9gEFTGE/ox6u1OHhZh+dgUD dAVFAuuPmMPTnuHMjYto2mtt9pGrIQHptdruDSaNrhUlgAM= X-Google-Smtp-Source: ALg8bN5gi4eXhouMdbRjh9LoarcCkZXCNdNhNRiZMOc99lz9++TUOz1clHQFQC63Rxp4WzwmedrzqxdsQj4Bo0+1taQ= X-Received: by 2002:a9d:3a22:: with SMTP id j31mr4106548otc.238.1547600515654; Tue, 15 Jan 2019 17:01:55 -0800 (PST) MIME-Version: 1.0 From: Richard Barnes Date: Tue, 15 Jan 2019 17:01:22 -0800 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000fd7a0e057f88d25a" Archived-At: Subject: [MLS] February MLS interop event 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, 16 Jan 2019 01:02:09 -0000 --000000000000fd7a0e057f88d25a Content-Type: text/plain; charset="UTF-8" Hey all, A few of us who are writing code for MLS are thinking of having an informal interop event in early February. If you'd like to participate, please fill out this Doodle to help pick dates: https://doodle.com/poll/2yd3b2eydchis82b#table The interop target will be draft-ietf-mls-protocol-03. We will try to get everyone passing a common set of test vectors, covering, e.g.: - Tree math - Derive-Key-Pair - Message parsing and serialization - Fully crypto calculations for a simple scenario This will be a remote meeting / teleconference. I will send out Webex details once we've picked a date/time. --Richard --000000000000fd7a0e057f88d25a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

A = few of us who are writing code for MLS are thinking of having an informal i= nterop event in early February.=C2=A0 If you'd like to participate, ple= ase fill out this Doodle to help pick dates:


The interop target will b= e draft-ietf-mls-protocol-03.=C2=A0 We will try to get everyone passing a c= ommon set of test vectors, covering, e.g.:

- Tree math
- Derive-Key-Pair
- Message parsing and serializatio= n
- Fully crypto calculations for a simple scenario

This will be a remote meeting / teleconference.=C2=A0 = I will send out Webex details once we've picked a date/time.
=
--Richard

--000000000000fd7a0e057f88d25a-- From micro@fastmail.com Tue Jan 22 22: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 BBD7E12D4EF for ; Tue, 22 Jan 2019 22:22:28 -0800 (PST) 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=DOOChqNk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XzQdbS4S 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 9xBqRgoKvbDd for ; Tue, 22 Jan 2019 22:22:26 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27D7127133 for ; Tue, 22 Jan 2019 22:22:26 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B005722101; Wed, 23 Jan 2019 01:22:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 23 Jan 2019 01:22:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= from:content-type:content-transfer-encoding:mime-version:date :subject:message-id:to; s=fm1; bh=JSj4Sh8Bwrcu5/LlFiVVEy7WXpPxbC K6yvO1lnj7Hic=; b=DOOChqNkuuZ6PPtF0JUxE7eUVg01186UrlSRL/2beM8+2d xs8dfER2YqGp/1Do1yJ02xIvwm4PA8vgd/T8Wlq5qd8n3NduCcyeTLHP4WHg0TQS KW8jZo08TkoeVLqK2pSmKUqMpm3om6GjI4ICs5evUnCBGz2DD/p/GQFwKgDRzpAD 9mWuy6uGSl0x6+bmS1Zi7ixg9aBbk7PZABzQmOClTQVyojWlGTfTFKsgY7D+CM9z BkupGdGydCJrFaVcbDcNlLB6yewGoADKcPomzKoRXdiUM96eHqde+n46leweseND PaqvfTlgE5EgX5CRwXgJv7hmcVIr6swCKnoO4dQA== 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=fm1; bh=JSj4Sh 8Bwrcu5/LlFiVVEy7WXpPxbCK6yvO1lnj7Hic=; b=XzQdbS4S+9vhFf0LoqPLck +4UQ3fBoj99TTH3lbphbvQIWSbfoWjhlqZ9hWPNgBaycQbwSFsANR3Y/DydJfIPz hIQ6zT1Jr8/EgjkASga/Ua3ZmLvbDArnlLWtpCaWPL4U9mA6eIAQjsfIHKwyowq3 Fj44dVCmKVKEC2odkMMMcNPeHLnlLIWo0HsQwpefEUPez1tbb3PvEWeEJbXAIvwf wF6aJUiuCTOhscmB9XZvHdTDBfzkw1mb/vXra4SdsfkTz0qlVRgrm9wnzduaioLe NJJOjPYlN3TLElIEOiLKZ9biyBg424IqbqsDJWWjozOYq4eJbIvMxqO7dtC9envg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrheelgdelhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefhtgfgggffuffkvffosehtqhhmtdhhtddvnecuhfhrohhmpefoih gthhgrvghlucftohhsvghnsggvrhhguceomhhitghrohesfhgrshhtmhgrihhlrdgtohhm qeenucfkphepleeirdeggedrvdekrddufeeknecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmihgtrhhosehfrghsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [100.64.7.182] (unknown [96.44.28.138]) by mail.messagingengine.com (Postfix) with ESMTPA id D5F391030D; Wed, 23 Jan 2019 01:22:24 -0500 (EST) From: Michael Rosenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 23 Jan 2019 01:22:17 -0500 Message-Id: To: mls@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [MLS] High-level Questions and Clarifications 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, 23 Jan 2019 07:52:36 -0000 Hey all, I'm just getting involved with MLS and everyone has been super = helpful with onboarding and reviewing stuff, and I'm really grateful for = it. I've been trying to do a close reading of protocol spec and these = are the last of the questions that didn't fall under a previous PR or = Github issue. Some of these questions, if nontrivial, might be better if = split out into threads of their own. And of course, feel free to answer = whichever subset of these questions you wish. Also, I hope to use what I = do understand so far to begin building out a new Rust implementation of = the protocol soon. The following page numbers are from the PDF version of protocol draft = #3. Page 8 =3D=3D=3D=3D=3D=3D The sample exchange depicted here shows Add being sent before Welcome. = But section 7.2 seems to indicate that Welcome messages have to come = first. Does the order matter? I though it did, since Welcome messages = are necessary to set the new participant up with the current GroupState = so everyone's on the same page after the subsequent Add. Pages 11,15 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The wording "A Diffie-Hellman finite-field group or elliptic curve" that = appears twice feels awkward (specifically, I think it should say = "finite-field multiplicative group") but more importantly, it's unclear = if implementations MUST, SHOULD or, MAY use these mathematical objects = for DHE. Further, [clicks in chinstrap on tinfoil hat] could this = reasonably be loosened to allow for ciphersuites with quantum-resistant = DH-like algorithms such as SIDH? Page 12 =3D=3D=3D=3D=3D=3D=3D This may not be a well-founded concern, but it might be desirable that = the Hash that's used iteratively to derive node secrets on the ratchet = tree be keyed (or salted) with tree-specific information. One could = imagine if participant D had poor enough entropy and an attacker had = done a good amount of precomputation of Hash, the attacker could derive = D from Hash(D). Then the attacker could go and do the same thing in = another group with another participant with poor entropy without having = to do any more precomputation. Page 20 =3D=3D=3D=3D=3D=3D=3D Which AEAD and DH algorithms are supposed to be used for sending a = node's secret to a leaf in the resolution of the copath? Suppose A and B = are siblings and that they have different ciphersuite preferences. How = does B compute the shared secret AB in order to encrypt new entropy for = A? Another related general question: There are cases when only a single = party fails an operation, and it's not immediately clear what the = procedure is to handle these. For example, a DirectPath in an Update = operation could be filled with all correct ECIESCiphertexts except one, = whose contents is random garbage. Then only a Participant with knowledge = of the corresponding node secret would be able to tell that there was an = invalid ciphertext in the bunch. The rest would be unable to see this, = and furthermore, it's unclear how the affected Participant would even = prove that it was invalid without having to reveal the node secret to = the rest of the Group. How should the protocol handle this? Page 21 =3D=3D=3D=3D=3D=3D=3D Derive-Secret is a function of HkdfLabel, which in turn contains a = GroupState. But the serialization format of the GroupState is not = specified anywhere. Am I missing something? This probably should not be = implementation-defined, since it is fundamental to agreeing on internal = state. Page 26 =3D=3D=3D=3D=3D=3D=3D Why is cipher_suite in Welcome? Each init key corresponds to a unique = cipher suite, so the sender and recipient already know the cipher suite = they need to use. Page 27 =3D=3D=3D=3D=3D=3D=3D What happens when you get two Welcomes? Could you arbitrarily send a = Welcome to a person and DoS them from the group by forcing them to = update their state to something wrong? Page 35 =3D=3D=3D=3D=3D=3D=3D How exactly are the message signatures calculated? Does it mean the = 16-byte tag at the end of the AES-GCM ciphertext? How does this = generalize for AEADs with non-detachable signatures like AES-CCM (which = is a mac-then-encrypt construction)?= From nobody Wed Jan 23 05:58:38 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 72DDD128CE4 for ; Wed, 23 Jan 2019 05:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 EQv3eeGG2LIL for ; Wed, 23 Jan 2019 05:58:34 -0800 (PST) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 16F29126C01 for ; Wed, 23 Jan 2019 05:58:33 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 49CAAA16FE for ; Wed, 23 Jan 2019 14:58:30 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id XmMHpG2Mc1AR for ; Wed, 23 Jan 2019 14:58:28 +0100 (CET) From: Konrad Kohbrok To: mls@ietf.org Message-ID: Date: Wed, 23 Jan 2019 15:58:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [MLS] KDF instead of hashing up the tree 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, 23 Jan 2019 13:58:36 -0000 Hey everyone, I just discussed the current draft with my advisor Chris Brzuska and he came up with a suggestion that I thought I'd just quickly relay here. As I have only started following the discussion recently, I apologize if this was already brought up in the past. In terms of key separation, wouldn't it make for a cleaner design, if we used a KDF instead of a hash function? Instead of generating a new leaf-node secret and then hashing it to compute the new secret for the parent node, it would be better to generate a new secret and then from that secret independently (i.e. with different labels) compute the new leaf secret and the new secret for the parent node. This key independence would also make the proof easier. In terms of overhead, this would mean two KDF operations instead of one hashing operation. Cheers, Konrad From nobody Wed Jan 23 06:29: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 725C6128CE4 for ; Wed, 23 Jan 2019 06:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 kTJgrJKUfA2q for ; Wed, 23 Jan 2019 06:29:28 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 59ECC1200D7 for ; Wed, 23 Jan 2019 06:29:28 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id m6so1896829oig.11 for ; Wed, 23 Jan 2019 06:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9CnUUhbihWo1OydMDT3r3NrygbzuE33GRdWe/7Tf4WA=; b=m49ojr7NMwtOICSGJW2wCtC+AE9+s65XBVhHJGwxlw1mJ8Ec3KSNSutGaSvN3jjlai DQm6Uiunf032c3sCcBHL9k+xLD1qfdkc0eM86eZdR/SsrPg9fTCdmdd39mQzZJnqukYL sFXXZU8Hq08gOMZfRk5BsyUrxEoQMu6kb4PPbq5NVGzZBt+BUNJkXNucuJKoPq3aVh8T TEDnOmbFhoYTlQHbiNYPP3/qHMfGhZayfhLyL6W8cQXMIcs0oGotiqMGZVUvOtIL9EfF +h40fn4Yc68UnatOc+WqsJ68PNTlhPggLyrlhD22JM9HaFOkHk6awjLkgqgzR53o10QZ bVag== 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=9CnUUhbihWo1OydMDT3r3NrygbzuE33GRdWe/7Tf4WA=; b=TD2wziYHeJCrJraNjZ2oIRzDIFxR5icCBj0A/leR3Cy3znTEzZ86aWbpFYedlh/Axb nMewjMKTmMOBy5jEW01kncjim6IAxACYTyN9LTT2679IJi3M5ux6xCrPy5M9dPmC+nnM yGzAjWzx2NmN1HfEY2UyHHrMHdd9OOeCmLEQe8peUFjTGZvrsKyGkbqOglK2W0zL0LIw qbvJR+QDzaqSXPn244s8TT+CJ6HZUVgq6iHDnEUnYbejsDw5X1DckZbEAwS7xNINgBtd 6EfI5vFdMogIUynjwBHh5488kaWxwcGUY+mqTYbx0yo0BpuMlYz2gb5C3MNaIkT83ZUI nJrw== X-Gm-Message-State: AJcUukfbEQYPJwVDMBYiAYLyXI4cwVBHWLY5mkTot0aUDJIwntv/X0DM wqpLFnuwSzAUlQVS3cnWtE3+Olc7InrbW8QFZFl+bsw2bwo= X-Google-Smtp-Source: ALg8bN4Nl8oqaZwa8gzBy5LF4RZyYz1V5iFqJQI6vYEdPM1TLBgJEIAuq9qGpuFRdAvyhjjF9S4iQq5uSnj4hvjSt8o= X-Received: by 2002:aca:d64d:: with SMTP id n74mr406458oig.199.1548253767383; Wed, 23 Jan 2019 06:29:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 23 Jan 2019 09:29:14 -0500 Message-ID: To: Konrad Kohbrok Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d3d035058020eb88" Archived-At: Subject: Re: [MLS] KDF instead of hashing up the tree 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, 23 Jan 2019 14:29:30 -0000 --000000000000d3d035058020eb88 Content-Type: text/plain; charset="UTF-8" Note this is a little bit expensive in terms of message size; it changes the size of an update from log(N) to log(N)^2. It does not change the number of DH operations This is because you have to send the fresh secret for each intermediate node in the tree to all its descendants. Comparing the secrets you generate in each case, from leaf to root, along a path of depth 3 with S0 at the leaf: Current: S0, S1 = H(S0), S2 = H^2(S0), S3 = H^3(S0) Proposed: S0, S1 = KDF(T0, S0), S2 = KDF(T1, S1), S3 = KDF(T2, S2) Where T* are the fresh secrets called for here. This doesn't change to whom you encrypt things, but changes what you encrypt to each copath node: Current -> Proposed S1 -> S1, T1, T2 S2 -> S2, T2 S3 -> S3 (This is of course because you need to enable each recipient to compute up the tree.) So there's your log->log^2. This discussion is not to say that I'm opposed to this idea. It just looks like it has some non-negligible cost, so we should make sure we know what we're getting for that cost. --Ricahrd On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok wrote: > Hey everyone, > > I just discussed the current draft with my advisor Chris Brzuska and he > came up > with a suggestion that I thought I'd just quickly relay here. As I have > only > started following the discussion recently, I apologize if this was already > brought up in the past. > > In terms of key separation, wouldn't it make for a cleaner design, if we > used a > KDF instead of a hash function? Instead of generating a new leaf-node > secret > and then hashing it to compute the new secret for the parent node, it > would be > better to generate a new secret and then from that secret independently > (i.e. > with different labels) compute the new leaf secret and the new secret for > the > parent node. This key independence would also make the proof easier. In > terms of > overhead, this would mean two KDF operations instead of one hashing > operation. > > Cheers, > Konrad > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d3d035058020eb88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note this is a little bit expensive in terms of messa= ge size; it changes the size of an update from log(N) to log(N)^2.=C2=A0 It= does not change the number of DH operations

T= his is because you have to send the fresh secret for each intermediate node= in the tree to all its descendants.=C2=A0 Comparing the secrets you genera= te in each case, from leaf to root, along a path of depth 3 with S0 at the = leaf:

Current: S0, S1 =3D H(S0), S2 =3D H^2(S0), S= 3 =3D H^3(S0)
Proposed: S0, S1 =3D KDF(T0, S0), S2 =3D KDF(T1, S1= ), S3 =3D KDF(T2, S2)

Where T* are the fresh s= ecrets called for here.=C2=A0 This doesn't change to whom you encrypt t= hings, but changes what you encrypt to each copath node:

Current -> Proposed
S1 -> S1, T1, T2
S2 -&= gt; S2, T2
S3 -> S3

(This is of cours= e because you need to enable each recipient to compute up the tree.)=C2=A0 = So there's your log->log^2.

This discussion= is not to say that I'm opposed to this idea.=C2=A0 It just looks like = it has some non-negligible cost, so we should make sure we know what we'= ;re getting for that cost.

--Ricahrd



On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok &l= t;konrad.kohbrok@datashrine= .de> wrote:
Hey everyone,

I just discussed the current draft with my advisor Chris Brzuska and he cam= e up
with a suggestion that I thought I'd just quickly relay here. As I have= only
started following the discussion recently, I apologize if this was already<= br> brought up in the past.

In terms of key separation, wouldn't it make for a cleaner design, if w= e used a
KDF instead of a hash function? Instead of=C2=A0 generating a new leaf-node= secret
and then hashing it to compute the new secret for the parent node, it would= be
better to generate a new secret and then from that secret independently (i.= e.
with different labels) compute the new leaf secret and the new secret for t= he
parent node. This key independence would also make the proof easier. In ter= ms of
overhead, this would mean two KDF operations instead of one hashing operati= on.

Cheers,
Konrad

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d3d035058020eb88-- From nobody Wed Jan 23 06:59:56 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 1089B130E6D for ; Wed, 23 Jan 2019 06:59:54 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DelkEXSwtcWF for ; Wed, 23 Jan 2019 06:59:51 -0800 (PST) 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 6F825124C04 for ; Wed, 23 Jan 2019 06:59:51 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id g67so2245185wmd.2 for ; Wed, 23 Jan 2019 06:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nK2SnMw0B5MeCy4W3xb1lWnO9jWZEJVyd4fIpOfGGl4=; b=fsc/TH8bZM7ss9wj637/ojC8Zvx4ZGYBLqfZmT2vg8YzkLxhYP2iHoRjTBLj0UPcCA 1CP9ANjuDoBRm0dNjSRD6QAyNNMyVSn4DlZY130Ha5EDOjGy0To9iwKLEr4E4V0elLFx Tl8+v9QHC2IxdqIkoBe/aXv8JKkmNteOyZW05mdVDP6MknNR+tisxZKTKqp9tHSjr7IP sTql9QMA4JbDnwLGfhq9eNL/S8j0mP+vIPdLOYwkkx0QzBPk6WTTOZRu+G46Y2G435XP 5EH2+frP8Cw38YTtovbfXrY0sw8DBKo0A3SSt/ZAwJIMlKyG7N3MnPOfRb52dlAZbpmZ UrlQ== 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=nK2SnMw0B5MeCy4W3xb1lWnO9jWZEJVyd4fIpOfGGl4=; b=Q8QkkoDJFUIZkf5O+vMr+HMigzrVgQh3hgjuDJeG8ipBDCa6kkffrpiYuAyWx8dWh0 NBL6ccJzN5QVnUajsflH4h65l0rvC6NuVjBJJUqmIv1c/lh1hi6jHjf9m4u5a4jARqem OOvH5Mlrmg5op4yFbw+1rsNfvnJQx51+5oDIPMw7YJFUdKlYVkCNbCpCrL6/VRvl5sm0 qFUHW3tMJFFpeLrO71z47Z2VLlrLxWvMsE3VA4i7qE6NoOSNRIfGTRsRwkRor2pf3wsV nfN7cNdaM7o8NA3BjKFKDQCcKLG3SETuMS1dXRESZgzWSSGnruIS91HoIvEBWYCybvEW DFiA== X-Gm-Message-State: AJcUukcd72BxGoYznvqyyH/q7fXIJ4gZNbb+l2TwrK6zLvU9qDUHOUy1 d9EP+6NQbpbyeBsUa7GtQ1b9NoDx X-Google-Smtp-Source: ALg8bN7LyTv/KzzDPVO0yUPmLso+ByCgy6dF0MWObV72OvkAH8wBv+yQ0oMYVm6yNvsOVWCUWKVMCA== X-Received: by 2002:a7b:cb86:: with SMTP id m6mr3037631wmi.61.1548255589678; Wed, 23 Jan 2019 06:59:49 -0800 (PST) Received: from [192.168.0.67] (89-156-93-25.rev.numericable.fr. [89.156.93.25]) by smtp.gmail.com with ESMTPSA id i186sm71673717wmd.19.2019.01.23.06.59.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jan 2019 06:59:49 -0800 (PST) From: Karthikeyan Bhargavan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2D664F46-B4DC-4942-A3DF-99F67B536EFA" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 23 Jan 2019 15:59:47 +0100 In-Reply-To: Cc: Konrad Kohbrok , Messaging Layer Security WG To: Richard Barnes References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] KDF instead of hashing up the tree 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, 23 Jan 2019 14:59:54 -0000 --Apple-Mail=_2D664F46-B4DC-4942-A3DF-99F67B536EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If I understand correctly, Chris and Konrad are not suggesting changing = the secrets. Instead, they are suggesting that H(.) be implemented as something like: H(x) =3D HKDF(x,label=3D=E2=80=9Dparent=E2=80=9D) where x is the tree secret for the current node. Similarly, when generating the KEM private key for a node, we use KGEN(x) =3D HKDF(x,label=3D=E2=80=9Ckem key=E2=80=9D)=20 This would be a good way of making sure that each key in the protocol is = independent, but at no additional cost. Am I understanding this correctly, Konrad? > On 23 Jan 2019, at 15:29, Richard Barnes wrote: >=20 > Note this is a little bit expensive in terms of message size; it = changes the size of an update from log(N) to log(N)^2. It does not = change the number of DH operations >=20 > This is because you have to send the fresh secret for each = intermediate node in the tree to all its descendants. Comparing the = secrets you generate in each case, from leaf to root, along a path of = depth 3 with S0 at the leaf: >=20 > Current: S0, S1 =3D H(S0), S2 =3D H^2(S0), S3 =3D H^3(S0) > Proposed: S0, S1 =3D KDF(T0, S0), S2 =3D KDF(T1, S1), S3 =3D KDF(T2, = S2) >=20 > Where T* are the fresh secrets called for here. This doesn't change = to whom you encrypt things, but changes what you encrypt to each copath = node: >=20 > Current -> Proposed > S1 -> S1, T1, T2 > S2 -> S2, T2 > S3 -> S3 >=20 > (This is of course because you need to enable each recipient to = compute up the tree.) So there's your log->log^2. >=20 > This discussion is not to say that I'm opposed to this idea. It just = looks like it has some non-negligible cost, so we should make sure we = know what we're getting for that cost. >=20 > --Ricahrd >=20 >=20 >=20 > On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok = > = wrote: > Hey everyone, >=20 > I just discussed the current draft with my advisor Chris Brzuska and = he came up > with a suggestion that I thought I'd just quickly relay here. As I = have only > started following the discussion recently, I apologize if this was = already > brought up in the past. >=20 > In terms of key separation, wouldn't it make for a cleaner design, if = we used a > KDF instead of a hash function? Instead of generating a new leaf-node = secret > and then hashing it to compute the new secret for the parent node, it = would be > better to generate a new secret and then from that secret = independently (i.e. > with different labels) compute the new leaf secret and the new secret = for the > parent node. This key independence would also make the proof easier. = In terms of > overhead, this would mean two KDF operations instead of one hashing = operation. >=20 > Cheers, > Konrad >=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=_2D664F46-B4DC-4942-A3DF-99F67B536EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = I understand correctly, Chris and Konrad are not suggesting changing the = secrets.
Instead, they are suggesting that H(.) be = implemented as something like:

H(x) =3D = HKDF(x,label=3D=E2=80=9Dparent=E2=80=9D)

where x is the tree secret for the = current node.

Similarly, when generating the KEM private key for a node, we = use

KGEN(x) =3D = HKDF(x,label=3D=E2=80=9Ckem key=E2=80=9D) 

This would be a good way of making sure = that each key in the protocol is independent, but at no additional = cost.
Am I understanding this correctly, = Konrad?

On 23 Jan 2019, at 15:29, Richard Barnes = <rlb@ipv.sx> = wrote:

Note this is a little bit = expensive in terms of message size; it changes the size of an update = from log(N) to log(N)^2.  It does not change the number of DH = operations

This is because you have to send the fresh secret for each = intermediate node in the tree to all its descendants.  Comparing = the secrets you generate in each case, from leaf to root, along a path = of depth 3 with S0 at the leaf:

Current: S0, S1 =3D H(S0), S2 =3D = H^2(S0), S3 =3D H^3(S0)
Proposed: S0, S1 =3D = KDF(T0, S0), S2 =3D KDF(T1, S1), S3 =3D KDF(T2, S2)

Where T* are the fresh secrets called for here.  This = doesn't change to whom you encrypt things, but changes what you encrypt = to each copath node:

Current -> Proposed
S1 -> S1, T1, = T2
S2 -> S2, T2
S3 -> = S3

(This is of = course because you need to enable each recipient to compute up the = tree.)  So there's your log->log^2.

This discussion is not to say that I'm = opposed to this idea.  It just looks like it has some = non-negligible cost, so we should make sure we know what we're getting = for that cost.

--Ricahrd



On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok = <konrad.kohbrok@datashrine..de> wrote:
Hey everyone,

I just discussed the current draft with my advisor Chris Brzuska and he = came up
with a suggestion that I thought I'd just quickly relay here. As I have = only
started following the discussion recently, I apologize if this was = already
brought up in the past.

In terms of key separation, wouldn't it make for a cleaner design, if we = used a
KDF instead of a hash function? Instead of  generating a new = leaf-node secret
and then hashing it to compute the new secret for the parent node, it = would be
better to generate a new secret and then from that secret independently = (i.e.
with different labels) compute the new leaf secret and the new secret = for the
parent node. This key independence would also make the proof easier. In = terms of
overhead, this would mean two KDF operations instead of one hashing = operation.

Cheers,
Konrad

_______________________________________________
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=_2D664F46-B4DC-4942-A3DF-99F67B536EFA-- From nobody Wed Jan 23 07:19:23 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 0A046129AA0 for ; Wed, 23 Jan 2019 07:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 N_46xbVSe-LF for ; Wed, 23 Jan 2019 07:19:20 -0800 (PST) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 75D9C126BED for ; Wed, 23 Jan 2019 07:19:20 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 04905A180F; Wed, 23 Jan 2019 16:19:18 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id 7oPRwGI1gWNQ; Wed, 23 Jan 2019 16:19:11 +0100 (CET) To: Karthikeyan Bhargavan , Richard Barnes Cc: Messaging Layer Security WG References: From: Konrad Kohbrok Message-ID: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> Date: Wed, 23 Jan 2019 17:19:10 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] KDF instead of hashing up the tree 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, 23 Jan 2019 15:19:23 -0000 Exactly, thanks Karthik! Say we have the same tree as in the example in 5.4: G / \ / \ E _ / \ / \ A B C D Then A generates a fresh secret X_1secret and derives the following new secrets: X_1kemkey=HKDF(X_1secret,"kemkey") X_2secret=HKDF(X_1secret,"parent") X_2kemkey=HKDF(X_2secret,"kemkey") X_3secret=HKDF(X_2secret,"parent") X_3kemkey=HKDF(X_3secret,"kemkey") A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and E(pk(D),X_3secret) to D. Hopefully that makes the idea a little clearer. Sorry for the terrible notation. Konrad On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: > If I understand correctly, Chris and Konrad are not suggesting changing the secrets. > Instead, they are suggesting that H(.) be implemented as something like: > > H(x) = HKDF(x,label=”parent”) > > where x is the tree secret for the current node. > > Similarly, when generating the KEM private key for a node, we use > > KGEN(x) = HKDF(x,label=“kem key”) > > This would be a good way of making sure that each key in the protocol is > independent, but at no additional cost. > Am I understanding this correctly, Konrad? > >> On 23 Jan 2019, at 15:29, Richard Barnes > wrote: >> >> Note this is a little bit expensive in terms of message size; it changes the >> size of an update from log(N) to log(N)^2. It does not change the number of >> DH operations >> >> This is because you have to send the fresh secret for each intermediate node >> in the tree to all its descendants. Comparing the secrets you generate in >> each case, from leaf to root, along a path of depth 3 with S0 at the leaf: >> >> Current: S0, S1 = H(S0), S2 = H^2(S0), S3 = H^3(S0) >> Proposed: S0, S1 = KDF(T0, S0), S2 = KDF(T1, S1), S3 = KDF(T2, S2) >> >> Where T* are the fresh secrets called for here. This doesn't change to whom >> you encrypt things, but changes what you encrypt to each copath node: >> >> Current -> Proposed >> S1 -> S1, T1, T2 >> S2 -> S2, T2 >> S3 -> S3 >> >> (This is of course because you need to enable each recipient to compute up the >> tree.) So there's your log->log^2. >> >> This discussion is not to say that I'm opposed to this idea. It just looks >> like it has some non-negligible cost, so we should make sure we know what >> we're getting for that cost. >> >> --Ricahrd >> >> >> >> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok > > wrote: >> >> Hey everyone, >> >> I just discussed the current draft with my advisor Chris Brzuska and he >> came up >> with a suggestion that I thought I'd just quickly relay here. As I have only >> started following the discussion recently, I apologize if this was already >> brought up in the past. >> >> In terms of key separation, wouldn't it make for a cleaner design, if we >> used a >> KDF instead of a hash function? Instead of generating a new leaf-node secret >> and then hashing it to compute the new secret for the parent node, it would be >> better to generate a new secret and then from that secret independently (i.e. >> with different labels) compute the new leaf secret and the new secret for the >> parent node. This key independence would also make the proof easier. In >> terms of >> overhead, this would mean two KDF operations instead of one hashing operation. >> >> Cheers, >> Konrad >> >> _______________________________________________ >> 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 > From nobody Wed Jan 23 07:48: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 1A708130E25 for ; Wed, 23 Jan 2019 07:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 Q0xS5HVOg_GP for ; Wed, 23 Jan 2019 07:48:02 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 4D241130E78 for ; Wed, 23 Jan 2019 07:48:02 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id v6so2169667oif.2 for ; Wed, 23 Jan 2019 07:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JaA7JPIgoczveuW6bo97H7V5EIsq3b01iUT8ESaD7OE=; b=pz/xQsNQukVTojZGh7u396Wl4BQN3nqVfLRvYpepyifxAXDmXw1aXfiTDZtORIapi0 z/HW6yuIuscjBbvELDozkTlNWc8NIk2c1dKHrvetW50HzvcbfXU9Dp55d5qMJUZfX4nx +J22kVvC+SrW8qMWX4pv5yGJJHw6ERdBgr15zQb6t7tzYpKg0OhM5lYC5FdjtxFweFtf rkLg4sBe+EX/Rrv/Wo+R4xCfYnMLsLJAji0V7AJYMgXMI5ZswLfzx13vePaQvW9APj8E cHj0++1sWPv+tCwzasbUwLUY/DlxHDVS0BnFwkyAHokEroLUKtlyeSXG0OR0TItcd3yZ WKDg== 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=JaA7JPIgoczveuW6bo97H7V5EIsq3b01iUT8ESaD7OE=; b=lst0GzH/cmZmpXrgQZWGCt24QA8ficeGvzdFYDYBf0S5d8DKgJYSRicOrIp+/B6B9N vxOjZayoozj5UZYLYdRN86c7xKEZ9Pw19Y+l7Kl9CVWiKfrHUd3RBt+1mcQxAx9xgvVI Gizpz7b2I3BKElUwxEcUchs+owws3TS//ONVkLHySgTBkS6ttutu6rPTyEIDNVdqWPuS IaUCAsyQqJhbVILm7pJUkQKL6sDwN/XX0WVw/Sj0TH5H7mRSLteGmqRjnPQKGmhya06A Wj4e9/1Kg9obLhU39mDm0Pgn2arYNI+G6Ha90aYSvPKfX5nVeiwX1gphGacJaTxEwT4G 8b7w== X-Gm-Message-State: AJcUukfa4tix8VbhdWuYWu8E3/CtMH1Vt5gV8H2muqAGecRHIg8PZ9NI CSbZzFv4QKGM+7QBfcj44Av0ajMB1bvmbQqUY7A8Tg== X-Google-Smtp-Source: ALg8bN6fQDB+vHkyoRSYrU6dC9MzJeWderx2RQCU/xH7C5Lv+oAQiNpIJHn7o7lDy8FEQgeCwrKtkJdWHrwCTzwz7uQ= X-Received: by 2002:aca:d64d:: with SMTP id n74mr588191oig.199.1548258481423; Wed, 23 Jan 2019 07:48:01 -0800 (PST) MIME-Version: 1.0 References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> In-Reply-To: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> From: Richard Barnes Date: Wed, 23 Jan 2019 10:47:49 -0500 Message-ID: To: Konrad Kohbrok Cc: Karthikeyan Bhargavan , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000ce5ae2058022043b" Archived-At: Subject: Re: [MLS] KDF instead of hashing up the tree 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, 23 Jan 2019 15:48:05 -0000 --000000000000ce5ae2058022043b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, ok, I get it. I misunderstood "new secret" as "fresh entropy". In that case, this falls into the "sure, if it makes the analysis better" bucket. We've been treating hashes/HKDF invocations as basically free. At some point we might need to worry about that, but I suspect that today is not that day. Want to make a PR? --Richard On Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok < konrad.kohbrok@datashrine.de> wrote: > Exactly, thanks Karthik! > > Say we have the same tree as in the example in 5.4: > > G > / \ > / \ > E _ > / \ / \ > A B C D > > Then A generates a fresh secret X_1secret and derives the following new > secrets: > X_1kemkey=3DHKDF(X_1secret,"kemkey") > X_2secret=3DHKDF(X_1secret,"parent") > > X_2kemkey=3DHKDF(X_2secret,"kemkey") > X_3secret=3DHKDF(X_2secret,"parent") > > X_3kemkey=3DHKDF(X_3secret,"kemkey") > > A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and > E(pk(D),X_3secret) to D. > > Hopefully that makes the idea a little clearer. Sorry for the terrible > notation. > > Konrad > > On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: > > If I understand correctly, Chris and Konrad are not suggesting changing > the secrets. > > Instead, they are suggesting that H(.) be implemented as something like= : > > > > H(x) =3D HKDF(x,label=3D=E2=80=9Dparent=E2=80=9D) > > > > where x is the tree secret for the current node. > > > > Similarly, when generating the KEM private key for a node, we use > > > > KGEN(x) =3D HKDF(x,label=3D=E2=80=9Ckem key=E2=80=9D) > > > > This would be a good way of making sure that each key in the protocol i= s > > independent, but at no additional cost. > > Am I understanding this correctly, Konrad? > > > >> On 23 Jan 2019, at 15:29, Richard Barnes > > wrote: > >> > >> Note this is a little bit expensive in terms of message size; it > changes the > >> size of an update from log(N) to log(N)^2. It does not change the > number of > >> DH operations > >> > >> This is because you have to send the fresh secret for each intermediat= e > node > >> in the tree to all its descendants. Comparing the secrets you generat= e > in > >> each case, from leaf to root, along a path of depth 3 with S0 at the > leaf: > >> > >> Current: S0, S1 =3D H(S0), S2 =3D H^2(S0), S3 =3D H^3(S0) > >> Proposed: S0, S1 =3D KDF(T0, S0), S2 =3D KDF(T1, S1), S3 =3D KDF(T2, S= 2) > >> > >> Where T* are the fresh secrets called for here. This doesn't change t= o > whom > >> you encrypt things, but changes what you encrypt to each copath node: > >> > >> Current -> Proposed > >> S1 -> S1, T1, T2 > >> S2 -> S2, T2 > >> S3 -> S3 > >> > >> (This is of course because you need to enable each recipient to comput= e > up the > >> tree.) So there's your log->log^2. > >> > >> This discussion is not to say that I'm opposed to this idea. It just > looks > >> like it has some non-negligible cost, so we should make sure we know > what > >> we're getting for that cost. > >> > >> --Ricahrd > >> > >> > >> > >> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok > >> > wrote: > >> > >> Hey everyone, > >> > >> I just discussed the current draft with my advisor Chris Brzuska > and he > >> came up > >> with a suggestion that I thought I'd just quickly relay here. As I > have only > >> started following the discussion recently, I apologize if this was > already > >> brought up in the past. > >> > >> In terms of key separation, wouldn't it make for a cleaner design, > if we > >> used a > >> KDF instead of a hash function? Instead of generating a new > leaf-node secret > >> and then hashing it to compute the new secret for the parent node, > it would be > >> better to generate a new secret and then from that secret > independently (i.e. > >> with different labels) compute the new leaf secret and the new > secret for the > >> parent node. This key independence would also make the proof > easier. In > >> terms of > >> overhead, this would mean two KDF operations instead of one hashin= g > operation. > >> > >> Cheers, > >> Konrad > >> > >> _______________________________________________ > >> 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 > > > --000000000000ce5ae2058022043b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, ok, I get it.=C2=A0 I misunderstood &= quot;new secret" as "fresh entropy".

In that case, this falls into the "sure, if it makes the analysi= s better" bucket.=C2=A0 We've been treating hashes/HKDF invocation= s as basically free.=C2=A0 At some point we might need to worry about that,= but I suspect that today is not that day.

Want to= make a PR?

--Richard

On = Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok <konrad.kohbrok@datashrine.de> wrote:
=
Exactly, thanks Karthik!<= br>
Say we have the same tree as in the example in 5.4:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0G
=C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0E=C2=A0 =C2=A0 =C2=A0 =C2=A0_
=C2=A0 =C2=A0 / \=C2=A0 =C2=A0 =C2=A0/ \
=C2=A0 =C2=A0A=C2=A0 =C2=A0B=C2=A0 =C2=A0C=C2=A0 =C2=A0D

Then A generates a fresh secret X_1secret and derives the following new sec= rets:
X_1kemkey=3DHKDF(X_1secret,"kemkey")
X_2secret=3DHKDF(X_1secret,"parent")

X_2kemkey=3DHKDF(X_2secret,"kemkey")
X_3secret=3DHKDF(X_2secret,"parent")

X_3kemkey=3DHKDF(X_3secret,"kemkey")

A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and
E(pk(D),X_3secret) to D.

Hopefully that makes the idea a little clearer. Sorry for the terrible nota= tion.

Konrad

On 23/01/2019 16:59, Karthikeyan Bhargavan wrote:
> If I understand correctly, Chris and Konrad are not suggesting changin= g the secrets.
> Instead, they are suggesting that H(.) be implemented as something lik= e:
>
> H(x) =3D HKDF(x,label=3D=E2=80=9Dparent=E2=80=9D)
>
> where x is the tree secret for the current node.
>
> Similarly, when generating the KEM private key for a node, we use
>
> KGEN(x) =3D HKDF(x,label=3D=E2=80=9Ckem key=E2=80=9D)
>
> This would be a good way of making sure that each key in the protocol = is
> independent, but at no additional cost.
> Am I understanding this correctly, Konrad?
>
>> On 23 Jan 2019, at 15:29, Richard Barnes <rlb@ipv.sx <mailto= :rlb@ipv.sx>> wro= te:
>>
>> Note this is a little bit expensive in terms of message size; it c= hanges the
>> size of an update from log(N) to log(N)^2.=C2=A0 It does not chang= e the number of
>> DH operations
>>
>> This is because you have to send the fresh secret for each interme= diate node
>> in the tree to all its descendants.=C2=A0 Comparing the secrets yo= u generate in
>> each case, from leaf to root, along a path of depth 3 with S0 at t= he leaf:
>>
>> Current: S0, S1 =3D H(S0), S2 =3D H^2(S0), S3 =3D H^3(S0)
>> Proposed: S0, S1 =3D KDF(T0, S0), S2 =3D KDF(T1, S1), S3 =3D KDF(T= 2, S2)
>>
>> Where T* are the fresh secrets called for here.=C2=A0 This doesn&#= 39;t change to whom
>> you encrypt things, but changes what you encrypt to each copath no= de:
>>
>> Current -> Proposed
>> S1 -> S1, T1, T2
>> S2 -> S2, T2
>> S3 -> S3
>>
>> (This is of course because you need to enable each recipient to co= mpute up the
>> tree.)=C2=A0 So there's your log->log^2.
>>
>> This discussion is not to say that I'm opposed to this idea.= =C2=A0 It just looks
>> like it has some non-negligible cost, so we should make sure we kn= ow what
>> we're getting for that cost.
>>
>> --Ricahrd
>>
>>
>>
>> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok <konrad.kohbrok@= datashrine..de
>> <mailto:konrad.kohbrok@datashrine.de>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0Hey everyone,
>>
>>=C2=A0 =C2=A0 =C2=A0I just discussed the current draft with my advi= sor Chris Brzuska and he
>>=C2=A0 =C2=A0 =C2=A0came up
>>=C2=A0 =C2=A0 =C2=A0with a suggestion that I thought I'd just q= uickly relay here. As I have only
>>=C2=A0 =C2=A0 =C2=A0started following the discussion recently, I ap= ologize if this was already
>>=C2=A0 =C2=A0 =C2=A0brought up in the past.
>>
>>=C2=A0 =C2=A0 =C2=A0In terms of key separation, wouldn't it mak= e for a cleaner design, if we
>>=C2=A0 =C2=A0 =C2=A0used a
>>=C2=A0 =C2=A0 =C2=A0KDF instead of a hash function? Instead of=C2= =A0 generating a new leaf-node secret
>>=C2=A0 =C2=A0 =C2=A0and then hashing it to compute the new secret f= or the parent node, it would be
>>=C2=A0 =C2=A0 =C2=A0better to generate a new secret and then from t= hat secret independently (i.e.
>>=C2=A0 =C2=A0 =C2=A0with different labels) compute the new leaf sec= ret and the new secret for the
>>=C2=A0 =C2=A0 =C2=A0parent node. This key independence would also m= ake the proof easier. In
>>=C2=A0 =C2=A0 =C2=A0terms of
>>=C2=A0 =C2=A0 =C2=A0overhead, this would mean two KDF operations in= stead of one hashing operation.
>>
>>=C2=A0 =C2=A0 =C2=A0Cheers,
>>=C2=A0 =C2=A0 =C2=A0Konrad
>>
>>=C2=A0 =C2=A0 =C2=A0_______________________________________________=
>>=C2=A0 =C2=A0 =C2=A0MLS mailing list
>>=C2=A0 =C2=A0 =C2=A0MLS@ietf.org <mailto:MLS@ietf.org>
>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/mls
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org= <mailto:MLS@ietf.org<= /a>>
>> https://www.ietf.org/mailman/listinfo/mls
>
--000000000000ce5ae2058022043b-- From nobody Wed Jan 23 08:27: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 B9B1B130E7D for ; Wed, 23 Jan 2019 08:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ZDrzZybHF1Dp for ; Wed, 23 Jan 2019 08:27:35 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 F3ADA130E97 for ; Wed, 23 Jan 2019 08:27:34 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id y23so2282064oia.4 for ; Wed, 23 Jan 2019 08:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fn/eGL9EtRZm39SoKDhs6GNhOR6uEgZMCpcdHgfqapE=; b=uSjFdnhVf4Cgloj8tIdzSq1OqaG5Ne1WKH+WYHRyT1lSLrC0pjgcCLyM6PE0qLH4YW 3MxzgrVAeO3UTVYeRgq3famugeMifE7k2B749G/VDxmW4LZo/8NkHNh5HfIFjDh5qQNA KUfzSeoT7h6tWHNM7lYVqgAh99mb0ytcp6rbxRHDcTfYgM7M8ydlHlSfVlYQ5NvZUPq4 pL9nt7Y/l81ykcQkethsXXxiZ0zQBgQCBmoNc1QdEAxGQjZzxZLgTqTf4W0ThqC1QBF/ 2HuaG72oTGwKmSaUXFX/dbxIDhMTpgqVJu6lukCB+ye7qUJ+5cIz9PWRxnpIh7UvMmhf Fypw== 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=fn/eGL9EtRZm39SoKDhs6GNhOR6uEgZMCpcdHgfqapE=; b=mjOD3zVrGSjTwnHbCZ83wRXRhumZZOEMyT7oohtdgJ6igmA8cX7XZaEsgi36siPksr Ckph7a0HwnZ9ti1K65sMg8uwTDI2D6fYhzgRw4elXPx9L2xKijQezVbBdgjtvE3H0ZSX mXX/7Yu26lcUlkMI7JrxAPMfPeEaCdf5JtFHhUBNPFEVwQYoslIhLaBmEpP4g1OJxqCW dnKjG7yOK24jPmO89e09Vogb3X7SnKmAZ7P59IDunWV7pIi1MiLiMX51oqCeeNZv2QlH dNwBTSYlN8RDaUPxQfT3iPcNsiV+srXIREEFiU0AJUcY4DNWyOtdnMQKwRPL1FVu94AR pHDQ== X-Gm-Message-State: AJcUukcrXzWcVKgYoATrwQr0H/Nsi9XIdMtdLl1GhFmbRF4XJKD0Fs5S maERJD0UMa/sVR0tHUu+tCdTVgh720II3NySaH8JBQ== X-Google-Smtp-Source: ALg8bN51NZA5iWhQGeRgTRhbR6DdGg02SMIEnKk3XDykTqVMzi99L91d6lzYbToMLeuiU7Ab3WEsgvPmjwePCuPUFTU= X-Received: by 2002:aca:d64d:: with SMTP id n74mr681476oig.199.1548260853905; Wed, 23 Jan 2019 08:27:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 23 Jan 2019 11:27:20 -0500 Message-ID: To: Michael Rosenberg Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000378b1f058022921f" Archived-At: Subject: Re: [MLS] High-level Questions and Clarifications 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, 23 Jan 2019 16:27:38 -0000 --000000000000378b1f058022921f Content-Type: text/plain; charset="UTF-8" Hi Michael, Thanks for the feedback. Some responses inline. FWIW, section numbers or titles are easier points of reference than pages :) On Wed, Jan 23, 2019 at 2:52 AM Michael Rosenberg wrote: > Hey all, I'm just getting involved with MLS and everyone has been super > helpful with onboarding and reviewing stuff, and I'm really grateful for > it. I've been trying to do a close reading of protocol spec and these are > the last of the questions that didn't fall under a previous PR or Github > issue. Some of these questions, if nontrivial, might be better if split out > into threads of their own. And of course, feel free to answer whichever > subset of these questions you wish. Also, I hope to use what I do > understand so far to begin building out a new Rust implementation of the > protocol soon. > > The following page numbers are from the PDF version of protocol draft #3. > > Page 8 > ====== > The sample exchange depicted here shows Add being sent before Welcome. But > section 7.2 seems to indicate that Welcome messages have to come first. > Does the order matter? I though it did, since Welcome messages are > necessary to set the new participant up with the current GroupState so > everyone's on the same page after the subsequent Add. > As the draft is currently written, I think you're right. The new joiner should verify that the UIK in the corresponding Add actually belongs to the new joiner, so it needs both the Welcome and the Add to initialize its state. As noted in the OPEN ISSUE in Section 7.2, there's a challenging synchronization issue here. In the event that the Add fails, you don't want the new joiner to initialize its state based on the corresponding Welcome, since that would result in a state the group never entered. I think that in practice this can be managed (e.g., with locks), but if you have ideas on what guidance would be useful in this document, that would be helpful. > Pages 11,15 > =========== > The wording "A Diffie-Hellman finite-field group or elliptic curve" that > appears twice feels awkward (specifically, I think it should say > "finite-field multiplicative group") but more importantly, it's unclear if > implementations MUST, SHOULD or, MAY use these mathematical objects for > DHE. Further, [clicks in chinstrap on tinfoil hat] could this reasonably be > loosened to allow for ciphersuites with quantum-resistant DH-like > algorithms such as SIDH? > We could probably just replace these with "DH group" in general. Post-quantum is no longer tinfoil hat territory. I think a few WG participants have been thinking about what it would look like to plug in PQ primitives. But I think "DH group" would still cover things like CSIDH (but *not* SIDH IIUC). The real question is whether we can get move from DH to a general KEM construction, which would allow us even more choice in PQ primitives. > Page 12 > ======= > This may not be a well-founded concern, but it might be desirable that the > Hash that's used iteratively to derive node secrets on the ratchet tree be > keyed (or salted) with tree-specific information. One could imagine if > participant D had poor enough entropy and an attacker had done a good > amount of precomputation of Hash, the attacker could derive D from Hash(D). > Then the attacker could go and do the same thing in another group with > another participant with poor entropy without having to do any more > precomputation. > Poor entropy could be a concern, but TBH, I'm not sure how much we can do about it. We could, for example, require the leaf secret fold in some value that likely has better entropy, e.g., new_leaf = KDF(salt=prior_leaf, ikm=prior_epoch_secret). But from the perspective of the rest of the group, that's indistinguishable from the leaf holder just picking a random value. > Page 20 > ======= > Which AEAD and DH algorithms are supposed to be used for sending a node's > secret to a leaf in the resolution of the copath? Suppose A and B are > siblings and that they have different ciphersuite preferences. How does B > compute the shared secret AB in order to encrypt new entropy for A? > There is one ciphersuite for the whole group, which is communicated to new members in Welcome.cipher_suite. I wouldn't be surprised if this were unclear, though, so suggestions for how to clarify would be welcome. > Another related general question: There are cases when only a single party > fails an operation, and it's not immediately clear what the procedure is to > handle these. For example, a DirectPath in an Update operation could be > filled with all correct ECIESCiphertexts except one, whose contents is > random garbage. Then only a Participant with knowledge of the corresponding > node secret would be able to tell that there was an invalid ciphertext in > the bunch. The rest would be unable to see this, and furthermore, it's > unclear how the affected Participant would even prove that it was invalid > without having to reveal the node secret to the rest of the Group. How > should the protocol handle this? > This is still an OPEN ISSUE, noted in Section 7 (page 25). > Page 21 > ======= > Derive-Secret is a function of HkdfLabel, which in turn contains a > GroupState. But the serialization format of the GroupState is not specified > anywhere. Am I missing something? This probably should not be > implementation-defined, since it is fundamental to agreeing on internal > state. > The GroupState struct is defined in Section 5.7 (page 18). Since we're using the TLS struct syntax, the definition of a struct defines its serialization. > Page 26 > ======= > Why is cipher_suite in Welcome? Each init key corresponds to a unique > cipher suite, so the sender and recipient already know the cipher suite > they need to use. > As above, the new joiner needs to know the ciphersuite for the group. But also, each UserInitKey can contain init keys for multiple ciphersuites, so the recipient of the Welcome needs to know which one to use to decrypt. Page 27 > ======= > What happens when you get two Welcomes? Could you arbitrarily send a > Welcome to a person and DoS them from the group by forcing them to update > their state to something wrong? > In general, this seems like it's a layer up from what this document is specifying. For example, it's perfectly plausible that you could receive two welcomes with the same group_id and just initialize two different sessions that work just fine. That said, we should be clear that that's the case -- if applications want group IDs to be unique, they need to enforce that. We don't have any mechanism right now for authenticating the information in a Welcome. You would basically need a way to authenticate a GroupState object as a valid state of the group. Suggestions welcome. Of course, if we can't authenticate the information in a Welcome, we should describe the risks in the Security Considerations. Suggestions also welcome here :) > Page 35 > ======= > How exactly are the message signatures calculated? Does it mean the > 16-byte tag at the end of the AES-GCM ciphertext? How does this generalize > for AEADs with non-detachable signatures like AES-CCM (which is a > mac-then-encrypt construction)? > No, it's a signature, not a MAC. As I understand it, the sender: - Constructs a MLSSignatureContent struct with the (plaintext) content and the various indicators of the key being used - Serializes that struct - Signs the serialized struct with its identity key (corresponding to its entry in the group's roster) That text is due to Benjamin Beurdouche; he might have further corrections. --Richard _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000378b1f058022921f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

Thanks for the feedback.=C2=A0 Some responses inline.=C2=A0 FWIW, s= ection numbers or titles are easier points of reference than pages :)

On= Wed, Jan 23, 2019 at 2:52 AM Michael Rosenberg <micro@fastmail.com> wrote:
Hey all, I'm just getting involved wit= h MLS and everyone has been super helpful with onboarding and reviewing stu= ff, and I'm really grateful for it. I've been trying to do a close = reading of protocol spec and these are the last of the questions that didn&= #39;t fall under a previous PR or Github issue. Some of these questions, if= nontrivial, might be better if split out into threads of their own. And of= course, feel free to answer whichever subset of these questions you wish. = Also, I hope to use what I do understand so far to begin building out a new= Rust implementation of the protocol soon.

The following page numbers are from the PDF version of protocol draft #3.
Page 8
=3D=3D=3D=3D=3D=3D
The sample exchange depicted here shows Add being sent before Welcome. But = section 7.2 seems to indicate that Welcome messages have to come first. Doe= s the order matter? I though it did, since Welcome messages are necessary t= o set the new participant up with the current GroupState so everyone's = on the same page after the subsequent Add.

<= div>As the draft is currently written, I think you're right.=C2=A0 The = new joiner should verify that the UIK in the corresponding Add actually bel= ongs to the new joiner, so it needs both the Welcome and the Add to initial= ize its state.

As noted in the OPEN ISSUE in S= ection 7.2, there's a challenging synchronization issue here.=C2=A0 In = the event that the Add fails, you don't want the new joiner to initiali= ze its state based on the corresponding Welcome, since that would result in= a state the group never entered.=C2=A0 I think that in practice this=C2=A0= can be managed (e.g., with locks), but if you have ideas on what guidance = would be useful in this document, that would be helpful.

=C2= =A0
Pages 11,15
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The wording "A Diffie-Hellman finite-field group or elliptic curve&quo= t; that appears twice feels awkward (specifically, I think it should say &q= uot;finite-field multiplicative group") but more importantly, it's= unclear if implementations MUST, SHOULD or, MAY use these mathematical obj= ects for DHE. Further, [clicks in chinstrap on tinfoil hat] could this reas= onably be loosened to allow for ciphersuites with quantum-resistant DH-like= algorithms such as SIDH?

We could prob= ably just replace these with "DH group" in general.=C2=A0 Post-qu= antum is no longer tinfoil hat territory.=C2=A0 I think a few WG participan= ts have been thinking about what it would look like to plug in PQ primitive= s.=C2=A0 But I think "DH group" would still cover things like CSI= DH (but *not* SIDH IIUC).

The real question is whe= ther we can get move from DH to a general KEM construction, which would all= ow us even more choice in PQ primitives.

=C2=A0
Page 12
=3D=3D=3D=3D=3D=3D=3D
This may not be a well-founded concern, but it might be desirable that the = Hash that's used iteratively to derive node secrets on the ratchet tree= be keyed (or salted) with tree-specific information. One could imagine if = participant D had poor enough entropy and an attacker had done a good amoun= t of precomputation of Hash, the attacker could derive D from Hash(D). Then= the attacker could go and do the same thing in another group with another = participant with poor entropy without having to do any more precomputation.=

Poor entropy could be a concern, but T= BH, I'm not sure how much we can do about it.=C2=A0 We could, for examp= le, require the leaf secret fold in some value that likely has better entro= py, e.g., new_leaf =3D KDF(salt=3Dprior_leaf, ikm=3Dprior_epoch_secret).=C2= =A0 But from the perspective of the rest of the group, that's indisting= uishable from the leaf holder just picking a random value.

=C2=A0
Page 20
=3D=3D=3D=3D=3D=3D=3D
Which AEAD and DH algorithms are supposed to be used for sending a node'= ;s secret to a leaf in the resolution of the copath? Suppose A and B are si= blings and that they have different ciphersuite preferences. How does B com= pute the shared secret AB in order to encrypt new entropy for A?

There is one ciphersuite for the whole group, whi= ch is communicated to new members in Welcome.cipher_suite.=C2=A0 I wouldn&#= 39;t be surprised if this were unclear, though, so suggestions for how to c= larify would be welcome.

=C2=A0
Another related general question: There are cases when only a single party = fails an operation, and it's not immediately clear what the procedure i= s to handle these. For example, a DirectPath in an Update operation could b= e filled with all correct ECIESCiphertexts except one, whose contents is ra= ndom garbage. Then only a Participant with knowledge of the corresponding n= ode secret would be able to tell that there was an invalid ciphertext in th= e bunch. The rest would be unable to see this, and furthermore, it's un= clear how the affected Participant would even prove that it was invalid wit= hout having to reveal the node secret to the rest of the Group. How should = the protocol handle this?

This is still= an OPEN ISSUE, noted in Section 7 (page 25).

=C2= =A0
Page 21
=3D=3D=3D=3D=3D=3D=3D
Derive-Secret is a function of HkdfLabel, which in turn contains a GroupSta= te. But the serialization format of the GroupState is not specified anywher= e. Am I missing something? This probably should not be implementation-defin= ed, since it is fundamental to agreeing on internal state.
=

The GroupState struct is defined in Section 5.7 (page 1= 8).=C2=A0 Since we're using the TLS struct syntax, the definition of a = struct defines its serialization.
=C2=A0
Page 26
=3D=3D=3D=3D=3D=3D=3D
Why is cipher_suite in Welcome? Each init key corresponds to a unique ciphe= r suite, so the sender and recipient already know the cipher suite they nee= d to use.

As above, the new joiner need= s to know the ciphersuite for the group.=C2=A0 But also, each UserInitKey c= an contain init keys for multiple ciphersuites, so the recipient of the Wel= come needs to know which one to use to decrypt.
=C2=A0
<= div>
Page 27
=3D=3D=3D=3D=3D=3D=3D
What happens when you get two Welcomes? Could you arbitrarily send a Welcom= e to a person and DoS them from the group by forcing them to update their s= tate to something wrong?

In general, th= is seems like it's a layer up from what this document is specifying.=C2= =A0 For example, it's perfectly plausible that you could receive two we= lcomes with the same group_id and just initialize two different sessions th= at work just fine.=C2=A0 That said, we should be clear that that's the = case -- if applications want group IDs to be unique, they need to enforce t= hat.

We don't have any mechanism right now for= authenticating the information in a Welcome.=C2=A0 You would basically nee= d a way to authenticate a GroupState object as a valid state of the group.= =C2=A0 Suggestions welcome.

Of course, if we can&#= 39;t authenticate the information in a Welcome, we should describe the risk= s in the Security Considerations.=C2=A0 Suggestions also welcome here :)

=C2=A0
Page 35
=3D=3D=3D=3D=3D=3D=3D
How exactly are the message signatures calculated? Does it mean the 16-byte= tag at the end of the AES-GCM ciphertext? How does this generalize for AEA= Ds with non-detachable signatures like AES-CCM (which is a mac-then-encrypt= construction)?

No, it's a signatur= e, not a MAC. As I understand it, the sender:

- Co= nstructs a MLSSignatureContent struct with the (plaintext) content and the = various indicators of the key being used
- Serializes that struct=
- Signs the serialized struct with its identity key (correspondi= ng to its entry in the group's roster)
=C2=A0
T= hat text is due to Benjamin Beurdouche; he might have further corrections.<= /div>

--Richard


<= div>
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000378b1f058022921f-- From nobody Wed Jan 23 10:51: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 072C3130F74 for ; Wed, 23 Jan 2019 10:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 7CAClPnbvf3w for ; Wed, 23 Jan 2019 10:50:58 -0800 (PST) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 E1BD0131207 for ; Wed, 23 Jan 2019 10:06:04 -0800 (PST) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 6B172A16B3; Wed, 23 Jan 2019 19:06:00 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id jJmxdM_g-rOd; Wed, 23 Jan 2019 19:05:58 +0100 (CET) To: Richard Barnes Cc: Karthikeyan Bhargavan , Messaging Layer Security WG References: <7507c820-d574-a570-6aba-c469366cc9c5@datashrine.de> From: Konrad Kohbrok Message-ID: <5cbb002f-fcc4-f739-0964-d3a75eca8cea@datashrine.de> Date: Wed, 23 Jan 2019 20:05:56 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] KDF instead of hashing up the tree 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, 23 Jan 2019 18:51:01 -0000 Sure, I'll give it a go. Konrad On 23/01/2019 17:47, Richard Barnes wrote: > Ah, ok, I get it.  I misunderstood "new secret" as "fresh entropy". > > In that case, this falls into the "sure, if it makes the analysis better" > bucket.  We've been treating hashes/HKDF invocations as basically free.  At some > point we might need to worry about that, but I suspect that today is not that day. > > Want to make a PR? > > --Richard > > > On Wed, Jan 23, 2019 at 10:19 AM Konrad Kohbrok > wrote: > > Exactly, thanks Karthik! > > Say we have the same tree as in the example in 5.4: > >          G >        /   \ >       /     \ >      E       _ >     / \     / \ >    A   B   C   D > > Then A generates a fresh secret X_1secret and derives the following new secrets: > X_1kemkey=HKDF(X_1secret,"kemkey") > X_2secret=HKDF(X_1secret,"parent") > > X_2kemkey=HKDF(X_2secret,"kemkey") > X_3secret=HKDF(X_2secret,"parent") > > X_3kemkey=HKDF(X_3secret,"kemkey") > > A then sends E(pk(B), X_2secret) to B, E(pk(C),X_3secret) to C and > E(pk(D),X_3secret) to D. > > Hopefully that makes the idea a little clearer. Sorry for the terrible notation. > > Konrad > > On 23/01/2019 16:59, Karthikeyan Bhargavan wrote: > > If I understand correctly, Chris and Konrad are not suggesting changing > the secrets. > > Instead, they are suggesting that H(.) be implemented as something like: > > > > H(x) = HKDF(x,label=”parent”) > > > > where x is the tree secret for the current node. > > > > Similarly, when generating the KEM private key for a node, we use > > > > KGEN(x) = HKDF(x,label=“kem key”) > > > > This would be a good way of making sure that each key in the protocol is > > independent, but at no additional cost. > > Am I understanding this correctly, Konrad? > > > >> On 23 Jan 2019, at 15:29, Richard Barnes >> wrote: > >> > >> Note this is a little bit expensive in terms of message size; it changes the > >> size of an update from log(N) to log(N)^2.  It does not change the number of > >> DH operations > >> > >> This is because you have to send the fresh secret for each intermediate node > >> in the tree to all its descendants.  Comparing the secrets you generate in > >> each case, from leaf to root, along a path of depth 3 with S0 at the leaf: > >> > >> Current: S0, S1 = H(S0), S2 = H^2(S0), S3 = H^3(S0) > >> Proposed: S0, S1 = KDF(T0, S0), S2 = KDF(T1, S1), S3 = KDF(T2, S2) > >> > >> Where T* are the fresh secrets called for here.  This doesn't change to whom > >> you encrypt things, but changes what you encrypt to each copath node: > >> > >> Current -> Proposed > >> S1 -> S1, T1, T2 > >> S2 -> S2, T2 > >> S3 -> S3 > >> > >> (This is of course because you need to enable each recipient to compute > up the > >> tree.)  So there's your log->log^2. > >> > >> This discussion is not to say that I'm opposed to this idea.  It just looks > >> like it has some non-negligible cost, so we should make sure we know what > >> we're getting for that cost. > >> > >> --Ricahrd > >> > >> > >> > >> On Wed, Jan 23, 2019 at 8:58 AM Konrad Kohbrok >> >> wrote: > >> > >>     Hey everyone, > >> > >>     I just discussed the current draft with my advisor Chris Brzuska and he > >>     came up > >>     with a suggestion that I thought I'd just quickly relay here. As I > have only > >>     started following the discussion recently, I apologize if this was > already > >>     brought up in the past. > >> > >>     In terms of key separation, wouldn't it make for a cleaner design, if we > >>     used a > >>     KDF instead of a hash function? Instead of  generating a new > leaf-node secret > >>     and then hashing it to compute the new secret for the parent node, it > would be > >>     better to generate a new secret and then from that secret > independently (i.e. > >>     with different labels) compute the new leaf secret and the new secret > for the > >>     parent node. This key independence would also make the proof easier. In > >>     terms of > >>     overhead, this would mean two KDF operations instead of one hashing > operation. > >> > >>     Cheers, > >>     Konrad > >> > >>     _______________________________________________ > >>     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 > > > From nobody Wed Jan 23 12:32:46 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 6A468130EF9 for ; Wed, 23 Jan 2019 12:32:44 -0800 (PST) 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=NKhmxxjB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tPWAzllo 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 MT_BniW70Jml for ; Wed, 23 Jan 2019 12:32:42 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E072A130EF7 for ; Wed, 23 Jan 2019 12:32:41 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DC5F0231B2; Wed, 23 Jan 2019 15:32:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 23 Jan 2019 15:32:40 -0500 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=fm1; bh=X ggnhc+w42oG6WAImxaMtbriXGRvHcl2qnEdFG2M134=; b=NKhmxxjBnEqj1Ywx6 7Fb3fXGtODr9Qp92JaYn6+Y3ckat58RD9/OULQ69w5975m+SActah6AOwSlIISaZ eCpkYG86IU4hZqbNfq6UyYNW8EfmjFJAVe+7FHFsi+uG0PBk9Ok01SbWQ9Ow0FBS ZOb6G5gR1ViwEsYXUWPpNR0MJgkO2OZf2v9HsZTZmnGksfrP939mQhIMMLWZa3MI OZAgGZXq2aWap1nFYLMDJjvnG2Pi/jPvzyk7ZHfjU4iTth1NC5H6U7UDmv9zgLcf 9/xU7goyKtiMyvaU2CqgqV//IJFwbDDOb2zACqSecWFvjeNt/jiQmI8jcJzbXLfc Qt3ug== 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=fm1; bh=Xggnhc+w42oG6WAImxaMtbriXGRvHcl2qnEdFG2M1 34=; b=tPWAzlloZw55uUXv23UFD90PHwSHJaP8SdfHC3H5w4onPGsmh5l0cLcRJ nFNx+qJadwK77mvVdEMI5XTrPWqAGRfzx5hB4V/QsTNGv6HAPFn0/ZpfauHXU2f/ x9e+wOBv8Xwm54GRJqVJcCyy2+ym24qpQtNMq2+nZkUwVYvlwAXbbkNaw3AtFY6T e3p27GTMRos4+St4+Hv7Snpc2c48+StoPRV/Xp8CpLxmEnn9BjPYr0R5P/swNCD9 xAEz2yrsv0bdv1Na2a4vuWDGFUL060jAlvgtY+H/LCvo66MJ6W0PUPrE0dGwo0XO /JzDMp4pxHC+EhCwdT7MxWpNJ+UuQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledriedtgddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomh epofhitghhrggvlhcutfhoshgvnhgsvghrghcuoehmihgtrhhosehfrghsthhmrghilhdr tghomheqnecuffhomhgrihhnpehirggtrhdrohhrghenucfkphepieejrdduleegrdduge drvdehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmihgtrhhosehfrghsthhmrghilhdr tghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [67.194.14.25] (unknown [67.194.14.25]) by mail.messagingengine.com (Postfix) with ESMTPA id BFDA3E4744; Wed, 23 Jan 2019 15:32:39 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Michael Rosenberg In-Reply-To: Date: Wed, 23 Jan 2019 15:32:39 -0500 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [MLS] High-level Questions and Clarifications 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, 23 Jan 2019 20:32:44 -0000 Many thanks for the quick response. This clears up a few things. I have = some inline responses and follow-ups. > On Jan 23, 2019, at 11:27 AM, Richard Barnes wrote: >=20 >> Pages 11,15 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The wording "A Diffie-Hellman finite-field group or elliptic curve" = that appears twice feels awkward (specifically, I think it should say = "finite-field multiplicative group") but more importantly, it's unclear = if implementations MUST, SHOULD or, MAY use these mathematical objects = for DHE. Further, [clicks in chinstrap on tinfoil hat] could this = reasonably be loosened to allow for ciphersuites with quantum-resistant = DH-like algorithms such as SIDH? >=20 > We could probably just replace these with "DH group" in general. = Post-quantum is no longer tinfoil hat territory. I think a few WG = participants have been thinking about what it would look like to plug in = PQ primitives. But I think "DH group" would still cover things like = CSIDH (but *not* SIDH IIUC). >=20 > The real question is whether we can get move from DH to a general KEM = construction, which would allow us even more choice in PQ primitives. I think the primitive we're looking for might be a "2 part key agreement = protocol with perfect forward secrecy" but I can't find much literature = on this after a cursory check. Besides DH, ECDH, CSIDH, and SIDH there = are some pairing-based constructions = (https://eprint.iacr.org/2006/199.pdf has a review of a few such = schemes). =20 >> Page 12 >> =3D=3D=3D=3D=3D=3D=3D >> This may not be a well-founded concern, but it might be desirable = that the Hash that's used iteratively to derive node secrets on the = ratchet tree be keyed (or salted) with tree-specific information. One = could imagine if participant D had poor enough entropy and an attacker = had done a good amount of precomputation of Hash, the attacker could = derive D from Hash(D). Then the attacker could go and do the same thing = in another group with another participant with poor entropy without = having to do any more precomputation. >=20 > Poor entropy could be a concern, but TBH, I'm not sure how much we can = do about it. We could, for example, require the leaf secret fold in = some value that likely has better entropy, e.g., new_leaf =3D = KDF(salt=3Dprior_leaf, ikm=3Dprior_epoch_secret). But from the = perspective of the rest of the group, that's indistinguishable from the = leaf holder just picking a random value. Right, but even picking a static salt for each Group could at least = cover the case of precomputation attacks against node public keys, no? =20 >> Page 20 >> =3D=3D=3D=3D=3D=3D=3D >> Which AEAD and DH algorithms are supposed to be used for sending a = node's secret to a leaf in the resolution of the copath? Suppose A and B = are siblings and that they have different ciphersuite preferences. How = does B compute the shared secret AB in order to encrypt new entropy for = A? >=20 > There is one ciphersuite for the whole group, which is communicated to = new members in Welcome.cipher_suite. I wouldn't be surprised if this = were unclear, though, so suggestions for how to clarify would be = welcome. Oh, this changes a lot. I didn't realize that. I'll try to understand = how this actually works and make a PR at some point. >> Page 21 >> =3D=3D=3D=3D=3D=3D=3D >> Derive-Secret is a function of HkdfLabel, which in turn contains a = GroupState. But the serialization format of the GroupState is not = specified anywhere. Am I missing something? This probably should not be = implementation-defined, since it is fundamental to agreeing on internal = state. >=20 > The GroupState struct is defined in Section 5.7 (page 18). Since = we're using the TLS struct syntax, the definition of a struct defines = its serialization. Gotcha. This was confusing for me. The architecture spec explicitly = states that MLS does not have a canonical wire encoding, but I now see = that that is different from having an internal serialization format. I = might submit a PR that makes this clearer, because the spec currently = only says that the TLS syntax is used, and nothing more. =20 >> Page 26 >> =3D=3D=3D=3D=3D=3D=3D >> Why is cipher_suite in Welcome? Each init key corresponds to a unique = cipher suite, so the sender and recipient already know the cipher suite = they need to use. >=20 > As above, the new joiner needs to know the ciphersuite for the group. = But also, each UserInitKey can contain init keys for multiple = ciphersuites, so the recipient of the Welcome needs to know which one to = use to decrypt. I'm still confused. What happens if I specify some Welcome.cipher_suite = and then pick the user_init_key_id such that the = UserInitKey.cipher_suites_[user_init_key_id] does not agree with the = Welcome.cipher_suite? Isn't this a conflict? >> Page 27 >> =3D=3D=3D=3D=3D=3D=3D >> What happens when you get two Welcomes? Could you arbitrarily send a = Welcome to a person and DoS them from the group by forcing them to = update their state to something wrong? >=20 > In general, this seems like it's a layer up from what this document is = specifying. For example, it's perfectly plausible that you could = receive two welcomes with the same group_id and just initialize two = different sessions that work just fine. That said, we should be clear = that that's the case -- if applications want group IDs to be unique, = they need to enforce that. >=20 > We don't have any mechanism right now for authenticating the = information in a Welcome. You would basically need a way to = authenticate a GroupState object as a valid state of the group. = Suggestions welcome. >=20 > Of course, if we can't authenticate the information in a Welcome, we = should describe the risks in the Security Considerations. Suggestions = also welcome here :) Fair enough. It seems state synchronization is going to be one of the = biggest hurdles to overcome. Unfortunately I don't have much experience = in designing distributed systems. =20 >> Page 35 >> =3D=3D=3D=3D=3D=3D=3D >> How exactly are the message signatures calculated? Does it mean the = 16-byte tag at the end of the AES-GCM ciphertext? How does this = generalize for AEADs with non-detachable signatures like AES-CCM (which = is a mac-then-encrypt construction)? >=20 > No, it's a signature, not a MAC. As I understand it, the sender: >=20 > - Constructs a MLSSignatureContent struct with the (plaintext) content = and the various indicators of the key being used > - Serializes that struct > - Signs the serialized struct with its identity key (corresponding to = its entry in the group's roster) > =20 > That text is due to Benjamin Beurdouche; he might have further = corrections. Ah, I forgot that the identity key exists. It doesn't appear that any = signature algorithm is specified anywhere. I suppose that's for some = time in the future, though. The OPEN ISSUE in 10.2 makes a good case for = waiting to see which guarantees we want to support. -Michael From nobody Wed Jan 23 17:34:18 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 D8F27130FE9 for ; Wed, 23 Jan 2019 17:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 J3XwjYj59ZjP for ; Wed, 23 Jan 2019 17:34:14 -0800 (PST) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 5409C130FE4 for ; Wed, 23 Jan 2019 17:34:14 -0800 (PST) Received: by mail-oi1-x22d.google.com with SMTP id j21so3545147oii.8 for ; Wed, 23 Jan 2019 17:34:14 -0800 (PST) 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=41YFSpfxWW3uIztfqG8InLyuxeOH1fKDO+lytpTG/xM=; b=ObvDmHGlukM1kI0FG7w5Zersj5BWhX7nBZ61WAnc5p09uqsaTxMvnqQcz2tzGkS30+ f1YUX9/A1rxGmlYQT436/o8qKlqGqxhhxk/8+pug4vQb9GvhXBm+3xh1QlQKzNQNVsvo 9KkIdzO2agEnjub1ASph1QRhUVpgKBMX9jt2M= 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=41YFSpfxWW3uIztfqG8InLyuxeOH1fKDO+lytpTG/xM=; b=gKb/+9Z8OfOxeYpQyegqS1snuPsF6N75D5hO0gKv014aRyCPHC5raaycic5Xqvsv3r l04eJ4uKqvl0Gexx9Yjuc2YuYeO7XNwet1Excw2RHJ7zVRB67nC1XPtDHqXYOotNqEEW /zvi6xzAli/7nJ2OxZKudTLSfTcM0LLBVm+HDA+1hBaxSPMIlL01B2xS9bIl1/Mxn12d Jm+D7xSZToyxLfKVwtZgnBoRnRwX9UMWY8cHzhbfZdDMI6TbKAtFs0JSGUvOJLIMg5t3 o7Uzx466OLjDrfVQvvpAbFXDG20F/QA/BWVMBZI2G1wkhU+MeKVcjjZxhdDci3fPPJsQ hO/g== X-Gm-Message-State: AJcUukexEiv3e/EoeMshJZfdmXevgW31fV7pqmAx4TT8lW1sKSmr8Enw hxdnXuJzJPEx00KxlmIsY3uQVMQEfAa4bSK5z2DbwufsSKk= X-Google-Smtp-Source: ALg8bN5/na1Tq//wJ5frGQ/dkZ2PwLeUm70hGDZ28HehqHOit63pNAk+FK415xdBs357KepbucShcEa1WugNJNFCZwE= X-Received: by 2002:aca:4fc5:: with SMTP id d188mr23442oib.138.1548293653067; Wed, 23 Jan 2019 17:34:13 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Wed, 23 Jan 2019 17:34:02 -0800 Message-ID: To: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000331f1205802a35d1" Archived-At: Subject: [MLS] Idea for Issue #33 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, 24 Jan 2019 01:34:17 -0000 --000000000000331f1205802a35d1 Content-Type: text/plain; charset="UTF-8" Hello all, Relaying some ideas that I posted in the Github issue that allow a participant that was maliciously removed from the group by a bad update message to publicly prove that it was given an inconsistent update. This is an idea based on lightweight zero-knowledge proofs. https://github.com/mlswg/mls-protocol/issues/21 Recall the following from ECIES: Say that you are encrypting a ciphertext *X* to a user with private key *a*, public key *A* (= aP) and elliptic curve base point *P*. The ECIES ciphertext is the pair *(rP, c)* where *r* is a randomly-chosen scalar and *c* is the encryption of X with a key derived from *k*=KDF(rA)=KDF(raP). The key to this mechanism is revealing enough to prove to a third party that an update received by the user is decrypted to an inconsistent X than an update received by another participant, but without revealing the private key *a *(which would compromise the confidentiality of previous messages). Proposed modifications of the protocol: 1) Add a mechanism that allows a party with access to a supposed secret value of a node to validate the consistency of the chain of hashed derived from that secret. This could be implemented by creating a public value that consists of a KDF of the secret value with a known public value for every node that is being updated. To check a secret value, the validating party needs to compute the KDF for every node up the tree to the root and compare with the published values. The KDF acts as sort of a public integrity hash of to the node's secret value. 2) Add a Schnorr NIZK of knowledge (RFC 8235) of the random value r with every ECIES ciphertext. This proves that the r used in the ECIES encryption is known to the updater and rP is not trivially derived from some other previously sent r'P. For one participant to prove that they were given an update message that did not include the correct node secret, that participant can reveal the following: arP, DLEQ(arP:rP :: P:aP) Where a is the node's private key, and DLEQ is a discrete log equivalence proof that shows that arP is rP multiplied by the private key *a* of the user. So in summary, we would add: - Proof of knowledge of the randomness used in ECIES - Public KDF of each node's secret value and then a member could prove to an auditor that it was given the wrong secret by revealing: - an intermediate calculation of the ECIES decryption, a DLEQ proof that the right key was used I'm eager for this proposal to have some holes shot in it. Nick --000000000000331f1205802a35d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

Relaying some ide= as that I posted in the Github issue that allow a participant that was mali= ciously removed from the group by a bad update message to publicly prove th= at it was given an inconsistent update. This is an idea based on lightweigh= t zero-knowledge proofs.

Recall the following from ECIES:
Sa= y that you are encrypting a ciphertext X to a=C2=A0user with private= key a, public key A (=3D aP) and elliptic curve base point <= b>P. The ECIES ciphertext is the pair (rP, c) where r is = a randomly-chosen scalar and c is the encryption of X with a key der= ived from k=3DKDF(rA)=3DKDF(raP).

The key t= o this mechanism is revealing enough to prove to a third party that an upda= te received=C2=A0by the user is decrypted to an inconsistent X than an upda= te received=C2=A0by another participant, but without revealing the private = key a=C2=A0(which would compromise the confidentiality of previous m= essages).

Proposed modifications of the protocol:<= /div>
1) Add a mechanism that allows a party with access to a supposed = secret value of a node to validate the consistency of the chain of hashed d= erived from that secret. This could be implemented by creating a public val= ue that consists of a KDF of the secret value with a known public value for= every node that is being updated. To check a secret value, the validating = party needs to compute the KDF for every node up the tree to the root and c= ompare with the published values.

The KDF acts as = sort of a public integrity hash of to the node's secret value.

2)=C2=A0Add a Schnorr NIZK of knowledge (RFC 8235) of the = random value r with every ECIES ciphertext. This proves that the r used in = the ECIES encryption is known to the updater and rP=C2=A0is not trivially d= erived from some other previously sent r'P.

Fo= r one participant to prove that they were given an update message that did = not include the correct node secret, that participant can reveal the follow= ing:
arP, DLEQ(arP:rP :: P:aP)

Where a i= s the node's private key, and DLEQ is a discrete log equivalence proof = that shows that arP is rP=C2=A0multiplied by the private key a of th= e user.


So in summary, we would add= :
- Proof of knowledge of the randomness used in ECIES
= - Public KDF of each node's secret value
and then a membe= r could prove to an auditor that it was given the wrong secret by revealing= :
- an intermediate calculation of the ECIES decryption, a D= LEQ proof that the right key was used


I'm eager for this proposal to have some holes shot in it.


Nick


--000000000000331f1205802a35d1-- From nobody Thu Jan 24 01:51: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 E5E88130FCD for ; Thu, 24 Jan 2019 01:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RnJiPce9zsiU for ; Thu, 24 Jan 2019 01:51:00 -0800 (PST) Received: from mx2.mailbox.org (mx2a.mailbox.org [IPv6:2001:67c:2050:104:0:2:25:2]) (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 ADFD712D7F8 for ; Thu, 24 Jan 2019 01:51:00 -0800 (PST) Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 01C59A11F9 for ; Thu, 24 Jan 2019 10:50:57 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id P7IbIsZXrQRM for ; Thu, 24 Jan 2019 10:50:55 +0100 (CET) From: Konrad Kohbrok To: Messaging Layer Security WG Message-ID: Date: Thu, 24 Jan 2019 11:50:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [MLS] Improve FS granularity at a cost 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, 24 Jan 2019 09:51:04 -0000 Currently, when a member of a group does not issue an update for a while and then gets compromised, the adversary gets to see all the key material back until that member had last sent an update. The application could enforce a policy, where members have to issue updates in regular intervals, but in specific scenarios, but we might be able to do better for a price. Again, if this was already suggested earlier and for some reason didn't make it into the document, I'm sorry. In the case of an honest-but-lazy group member which is online, but doesn't send updates, we could still get some FS guarantees in case that member gets corrupted. One way of doing this could be puncturable encryption [1], where after a decryption operation, the receiver "punctures" their private key such that a certain set of ciphertexts (in our case, every ciphertext decrypted until that point) can no longer be decrypted with this copy of the key, giving us forward secrecy. I'm not intimately familiar with the details, but I think this doesn't work with any public key encryption scheme, so it might limit our choice there. Another way would be if with every update (or maybe with a special "UpdateAll" handshake message), the updating node contributes to the key of every node they would KEM an update to. Since we have to make sure that every node is still aware of the (new) public key of every node that was impacted that way, we could do something like this: (This is similar to Yevgeniy's "delta" proposal for garbage collection or might even be the same thing seen in a different light.) Along with the regular KEMed secrets, the updating node (A) encrypts some additional randomness. Then, every node changes their private and public keys using that randomness. Revisiting the example from Section 5.4.: G / \ / \ E _ / \ / \ A B C D Let's say A updates its secret key to X. Then, along with the relevant secrets for the nodes in the resolution of its direct path, the ciphertext sent also contains some fresh randomness r. The message sent to C for example would look like this: E(pk(C), r||h(h(X))) Then E would update its private key to be Er and its public key to be (g^E)^r=g^(Er) Now every node can compute the new public key of every other node updated this way, because they know the old key and they all received the same randomness (resulting in n DH-operations for every node). If a node gets compromised, the adversary only get the new key (Er), but won't be able to derive E from it and thus can't access key material that was previously KEMed under that key. Of course, this doesn't work if the victim is not online, but I still think it might be a realistic threat model. The catch here is that every member has to do log(n) exponentiations. Konrad [1]: https://ieeexplore.ieee.org/abstract/document/7163033 From nobody Thu Jan 24 06:22:39 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 05BEA1277CC for ; Thu, 24 Jan 2019 06:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qxy8QnNuOVsW for ; Thu, 24 Jan 2019 06:22:35 -0800 (PST) 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 988B1123FFD for ; Thu, 24 Jan 2019 06:22:35 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id 81so5379710otj.2 for ; Thu, 24 Jan 2019 06:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSPrrvfcfVmP5+lXp32qvwWhOORvVnIDG8v24yGBMyc=; b=ntApB0yPuSOBN7nfA0iuO9NUmBIRkxfttjBkdaaFl39OJaot66hRyAj/DQFCwm/D8r oRGH4n0OlLCtppwkl8woRO9ZUgR++lt7UvJqJmb162NaI/qpjpe3Xp7hdDhVZ/UIdLdq Plpm+cqCRsXtlhDNOrV7/Dlt/eBCQCRBr42e+zz66D3tW6zjyg00x9VlY7/qNz2tJO5j xJYFhRcIEET7KqrcFIa8Vy6xWdS8AucPmyaQGHbDIWIwQtKr+n2zdmMl8wxTM33MJJxB aNVyonvlKbxqfSKH6CQOV6xe55QROf+pD/++zsddiSS68F8fSvkm/F8m6GrRZn00iaj+ iqOg== 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=cSPrrvfcfVmP5+lXp32qvwWhOORvVnIDG8v24yGBMyc=; b=mPbEVuWnxI8TYKIoUKa7yTF9SmJH8YOw5WiYwJaI7tzANBNw8Gaf2mUZLkTb7vqNEN QRrGirRKKy0Vzhc/dD/t092ttfy8xprFcY4u7AcMGy3gLGcM9OqNUWuPE3CBMt3oGxkg l/OMYmoZnn5+cMrVevCVrSQmhRAFYtxi2k+npAkNcfxjtYg0O6B7X8UKxW51PSDNtkpy 6mT/bvRBxaSnvfqWmwibWRzq71bKe9B0HX+YlRAafKKX6OArWxkjBqRd4SiuF95sr+y2 ce9sVjh2Du3hLm8I8enHFlpnNrPAySClsnEauuGGmekic1e8snLUkS6TM4fDDbBtwCLy X4Lw== X-Gm-Message-State: AJcUukcDJi3EuTjDF1giDTQi5H7rE4pgUzfYDBQyg1oC1KR7t6G16AKV 3Dp4+LYfYVXtBnN1bXEt9ufzvgypP5E+b8azuptRfpsj X-Google-Smtp-Source: ALg8bN4qN5ve7q9b8U6YhpDZi26ROJ3V53hcGjyTq0PpvyRuPJnL+EjgoworAddWKkQILV/k2inyWAV57J+iZdGbyY0= X-Received: by 2002:a9d:3f34:: with SMTP id m49mr4301396otc.23.1548339754441; Thu, 24 Jan 2019 06:22:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 24 Jan 2019 09:22:21 -0500 Message-ID: To: Nick Sullivan Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000e319b058034f176" Archived-At: Subject: Re: [MLS] Idea for Issue #33 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, 24 Jan 2019 14:22:38 -0000 --0000000000000e319b058034f176 Content-Type: text/plain; charset="UTF-8" Hey Nick, If I'm understanding this correctly, I'm not sure it adds much new. W.r.t (1), the public keys in the path already provide this function, since they're a public value derived from the node's secret. Similarly, w.r.t. (2), the public key rP commits to the secret value r. So if the desire is to allow a third party to verify that an update is bad, and we're OK revealing one of the (previously) encrypted node secrets, we may have the machinery we need. The reporter can reveal the ECIES secret value r, and the verifier can first check that r matches the ECIESCiphertext, then decrypt the ciphertext and check the rest of the path. It seems like the only way you could do better than this is if you could do reporting without revealing any node secrets (even the inconsistent ones). But that seems appreciably more difficult. --Richard On Wed, Jan 23, 2019 at 8:34 PM Nick Sullivan wrote: > Hello all, > > Relaying some ideas that I posted in the Github issue that allow a > participant that was maliciously removed from the group by a bad update > message to publicly prove that it was given an inconsistent update. This is > an idea based on lightweight zero-knowledge proofs. > > https://github.com/mlswg/mls-protocol/issues/21 > > > Recall the following from ECIES: > Say that you are encrypting a ciphertext *X* to a user with private key > *a*, public key *A* (= aP) and elliptic curve base point *P*. The ECIES > ciphertext is the pair *(rP, c)* where *r* is a randomly-chosen scalar > and *c* is the encryption of X with a key derived from *k* > =KDF(rA)=KDF(raP). > > The key to this mechanism is revealing enough to prove to a third party > that an update received by the user is decrypted to an inconsistent X than > an update received by another participant, but without revealing the > private key *a *(which would compromise the confidentiality of previous > messages). > > Proposed modifications of the protocol: > 1) Add a mechanism that allows a party with access to a supposed secret > value of a node to validate the consistency of the chain of hashed derived > from that secret. This could be implemented by creating a public value that > consists of a KDF of the secret value with a known public value for every > node that is being updated. To check a secret value, the validating party > needs to compute the KDF for every node up the tree to the root and compare > with the published values. > > The KDF acts as sort of a public integrity hash of to the node's secret > value. > > 2) Add a Schnorr NIZK of knowledge (RFC 8235) of the random value r with > every ECIES ciphertext. This proves that the r used in the ECIES encryption > is known to the updater and rP is not trivially derived from some other > previously sent r'P. > > For one participant to prove that they were given an update message that > did not include the correct node secret, that participant can reveal the > following: > arP, DLEQ(arP:rP :: P:aP) > > Where a is the node's private key, and DLEQ is a discrete log equivalence > proof that shows that arP is rP multiplied by the private key *a* of the > user. > > > So in summary, we would add: > - Proof of knowledge of the randomness used in ECIES > - Public KDF of each node's secret value > and then a member could prove to an auditor that it was given the wrong > secret by revealing: > - an intermediate calculation of the ECIES decryption, a DLEQ proof that > the right key was used > > > I'm eager for this proposal to have some holes shot in it. > > > Nick > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000000e319b058034f176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Nick,

If I'm underst= anding this correctly, I'm not sure it adds much new.

W.r.t (1), the public keys in the path already provide this functio= n, since they're a public value derived from the node's secret.=C2= =A0 Similarly, w.r.t. (2), the public key rP commits to the secret value r.=

So if the desire is to allow a third party t= o verify that an update is bad, and we're OK revealing one of the (prev= iously) encrypted node secrets, we may have the machinery we need.=C2=A0 Th= e reporter can reveal the ECIES secret value r, and the verifier can first = check that r matches the ECIESCiphertext, then decrypt the ciphertext and c= heck the rest of the path.

It seems like the only = way you could do better than this is if you could do reporting without reve= aling any node secrets (even the inconsistent ones).=C2=A0 But that seems a= ppreciably more difficult.

--Richard


On Wed, Jan 23, 2019 at 8:34 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org= > wrote:
=
Hello all,

Relaying some ide= as that I posted in the Github issue that allow a participant that was mali= ciously removed from the group by a bad update message to publicly prove th= at it was given an inconsistent update. This is an idea based on lightweigh= t zero-knowledge proofs.

Recall the following from = ECIES:
Say that you are encrypting a ciphertext X to a=C2= =A0user with private key a, public key A (=3D aP) and ellipti= c curve base point P. The ECIES ciphertext is the pair (rP, c) where r is a randomly-chosen scalar and c is the encryption= of X with a key derived from k=3DKDF(rA)=3DKDF(raP).

=
The key to this mechanism is revealing enough to prove to a thir= d party that an update received=C2=A0by the user is decrypted to an inconsi= stent X than an update received=C2=A0by another participant, but without re= vealing the private key a=C2=A0(which would compromise the confident= iality of previous messages).

Proposed modificatio= ns of the protocol:
1) Add a mechanism that allows a party with a= ccess to a supposed secret value of a node to validate the consistency of t= he chain of hashed derived from that secret. This could be implemented by c= reating a public value that consists of a KDF of the secret value with a kn= own public value for every node that is being updated. To check a secret va= lue, the validating party needs to compute the KDF for every node up the tr= ee to the root and compare with the published values.

<= div>The KDF acts as sort of a public integrity hash of to the node's se= cret value.

2)=C2=A0Add a Schnorr NIZK of knowledg= e (RFC 8235) of the random value r with every ECIES ciphertext. This proves= that the r used in the ECIES encryption is known to the updater and rP=C2= =A0is not trivially derived from some other previously sent r'P.
<= div>
For one participant to prove that they were given an upd= ate message that did not include the correct node secret, that participant = can reveal the following:
arP, DLEQ(arP:rP :: P:aP)
Where a is the node's private key, and DLEQ is a discrete l= og equivalence proof that shows that arP is rP=C2=A0multiplied by the priva= te key a of the user.


So in = summary, we would add:
- Proof of knowledge of the randomness use= d in ECIES
- Public KDF of each node's secret value
=
and then a member could prove to an auditor that it was given the wron= g secret by revealing:
- an intermediate calculation of the = ECIES decryption, a DLEQ proof that the right key was used
=

I'm eager for this proposal to have some = holes shot in it.


Nick

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000000e319b058034f176-- From nobody Thu Jan 24 08:58: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 AABF21311DF for ; Thu, 24 Jan 2019 08:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 MxW7KFdZC5AG for ; Thu, 24 Jan 2019 08:58:38 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 899F5130EB8 for ; Thu, 24 Jan 2019 08:58:38 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id k98so5872248otk.3 for ; Thu, 24 Jan 2019 08:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uRT1W473CHM4kTPV1jn9t/C2Spxb4qJK5CRNf0aXoZI=; b=mLnFQruzvjrSVS0mqMIweLQ8Nxsr59Z+xpglMB1/M88udc5jc0roDpNUGs0sgIAU66 2vBH70V0g8r2dNWMw4wGrcA+lw9aLTSkBQvm2mlJqOtpB8jOlz5xFi/HXKMSKZsJe+0X kzIrTjh5WNFmDEoct/y1MXPmCUV19ayKY+/70= 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=uRT1W473CHM4kTPV1jn9t/C2Spxb4qJK5CRNf0aXoZI=; b=AfALhP93SibRf1MTI/LRjEGsnSGSFoRZV1h0GlP4EFivrZQJZhRPfWsw1cUvPZeRsh HYDxK0DjCktThE7ShmbmgZE+I9A22TeW2XXk7HPnN2gKmDInvuomCeTRpOiu4wRa5mCn OJJXAGdAUrkBJfnI7Cp4byU4WpH4lbtVOIEb7lfASbcKURXC9V7rqfvSKe7a16Uv3lH9 Yju4/b1I67IkHsMo00YNLVHjUXx5kEFJPFSvhcPWBFMKDdLe5BZfqd+DllgmgP+e0yNm 30b+dUoNjv+pA/A8Z07M7wbLF2D0cNupCF7cwbwJgeqE9qlfedqzSsxkCL8pcMOTfBPq cMmA== X-Gm-Message-State: AJcUukdv8g1j583d4aDE2SkjvBXHsOV/LWcYyZnYmnXFi18STCuUAvDT XVpndxYlHKjguxSXedqw/dVk0PzUjouCBcJssRRy1g== X-Google-Smtp-Source: ALg8bN7+Mvzz1NA4T95v9o7ZeUIhjjKdjjfQu05JJEtzsgzq4I3Gv5II91bZVprYXTszv1qVmOItBvQs0O2ARAbDazw= X-Received: by 2002:a9d:3f7:: with SMTP id f110mr5207313otf.171.1548349117620; Thu, 24 Jan 2019 08:58:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Thu, 24 Jan 2019 08:58:25 -0800 Message-ID: To: Richard Barnes Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002516980580371f3c" Archived-At: Subject: Re: [MLS] Idea for Issue #33 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, 24 Jan 2019 16:58:41 -0000 --0000000000002516980580371f3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, You=E2=80=99re right, the KDF part is not necessary, the verifier can just = compare the public key. Scratch that part. However, revealing r is not an option for the participant who was given the wrong key share, only the participant who created the bad key share. They may be offline or claim to have deleted it for forward secrecy reasons. This is why you need the zero-knowledge machinery. Nick On Thu, Jan 24, 2019 at 6:22 AM Richard Barnes wrote: > Hey Nick, > > If I'm understanding this correctly, I'm not sure it adds much new. > > W.r.t (1), the public keys in the path already provide this function, > since they're a public value derived from the node's secret. Similarly, > w.r.t. (2), the public key rP commits to the secret value r. > > So if the desire is to allow a third party to verify that an update is > bad, and we're OK revealing one of the (previously) encrypted node secret= s, > we may have the machinery we need. The reporter can reveal the ECIES > secret value r, and the verifier can first check that r matches the > ECIESCiphertext, then decrypt the ciphertext and check the rest of the pa= th. > > It seems like the only way you could do better than this is if you could > do reporting without revealing any node secrets (even the inconsistent > ones). But that seems appreciably more difficult. > > --Richard > > > On Wed, Jan 23, 2019 at 8:34 PM Nick Sullivan 40cloudflare.com@dmarc.ietf.org> wrote: > >> Hello all, >> >> Relaying some ideas that I posted in the Github issue that allow a >> participant that was maliciously removed from the group by a bad update >> message to publicly prove that it was given an inconsistent update. This= is >> an idea based on lightweight zero-knowledge proofs. >> >> https://github.com/mlswg/mls-protocol/issues/21 >> >> >> Recall the following from ECIES: >> Say that you are encrypting a ciphertext *X* to a user with private key >> *a*, public key *A* (=3D aP) and elliptic curve base point *P*. The ECIE= S >> ciphertext is the pair *(rP, c)* where *r* is a randomly-chosen scalar >> and *c* is the encryption of X with a key derived from *k* >> =3DKDF(rA)=3DKDF(raP). >> >> The key to this mechanism is revealing enough to prove to a third party >> that an update received by the user is decrypted to an inconsistent X th= an >> an update received by another participant, but without revealing the >> private key *a *(which would compromise the confidentiality of previous >> messages). >> >> Proposed modifications of the protocol: >> 1) Add a mechanism that allows a party with access to a supposed secret >> value of a node to validate the consistency of the chain of hashed deriv= ed >> from that secret. This could be implemented by creating a public value t= hat >> consists of a KDF of the secret value with a known public value for ever= y >> node that is being updated. To check a secret value, the validating part= y >> needs to compute the KDF for every node up the tree to the root and comp= are >> with the published values. >> >> The KDF acts as sort of a public integrity hash of to the node's secret >> value. >> >> 2) Add a Schnorr NIZK of knowledge (RFC 8235) of the random value r with >> every ECIES ciphertext. This proves that the r used in the ECIES encrypt= ion >> is known to the updater and rP is not trivially derived from some other >> previously sent r'P. >> >> For one participant to prove that they were given an update message that >> did not include the correct node secret, that participant can reveal the >> following: >> arP, DLEQ(arP:rP :: P:aP) >> >> Where a is the node's private key, and DLEQ is a discrete log equivalenc= e >> proof that shows that arP is rP multiplied by the private key *a* of the >> user. >> >> >> So in summary, we would add: >> - Proof of knowledge of the randomness used in ECIES >> - Public KDF of each node's secret value >> and then a member could prove to an auditor that it was given the wrong >> secret by revealing: >> - an intermediate calculation of the ECIES decryption, a DLEQ proof that >> the right key was used >> >> >> I'm eager for this proposal to have some holes shot in it. >> >> >> Nick >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --0000000000002516980580371f3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard,

You=E2=80=99re right, the KDF part is not necessary, the= verifier can just compare the public key. Scratch that part.

Howeve= r, revealing r is not an option for the participant who was given the wrong= key share, only the participant who created the bad key share. They may be= offline or claim to have deleted it for forward secrecy reasons. This is w= hy you need the zero-knowledge machinery.

Nick
On Thu, Jan 24, 2019 at 6:22 AM Richard Barnes &l= t;rlb@ipv.sx> wrote:
Hey Nick,

If I'm understanding this= correctly, I'm not sure it adds much new.

W.r= .t (1), the public keys in the path already provide this function, since th= ey're a public value derived from the node's secret.=C2=A0 Similarl= y, w.r.t. (2), the public key rP commits to the secret value r.
<= div>
So if the desire is to allow a third party to verify tha= t an update is bad, and we're OK revealing one of the (previously) encr= ypted node secrets, we may have the machinery we need.=C2=A0 The reporter c= an reveal the ECIES secret value r, and the verifier can first check that r= matches the ECIESCiphertext, then decrypt the ciphertext and check the res= t of the path.

It seems like the only way you coul= d do better than this is if you could do reporting without revealing any no= de secrets (even the inconsistent ones).=C2=A0 But that seems appreciably m= ore difficult.

--Richard


On Wed, Jan 23, 2019 at 8:34 PM = Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
=
Hel= lo all,

Relaying some ideas that I posted in the G= ithub issue that allow a participant that was maliciously removed from the = group by a bad update message to publicly prove that it was given an incons= istent update. This is an idea based on lightweight zero-knowledge proofs.<= /div>

Recall the following from ECIES:
Say tha= t you are encrypting a ciphertext X to a=C2=A0user with private key = a, public key A (=3D aP) and elliptic curve base point P. The ECIES ciphertext is the pair (rP, c) where r is a ran= domly-chosen scalar and c is the encryption of X with a key derived = from k=3DKDF(rA)=3DKDF(raP).

The key to thi= s mechanism is revealing enough to prove to a third party that an update re= ceived=C2=A0by the user is decrypted to an inconsistent X than an update re= ceived=C2=A0by another participant, but without revealing the private key <= b>a=C2=A0(which would compromise the confidentiality of previous messag= es).

Proposed modifications of the protocol:
=
1) Add a mechanism that allows a party with access to a supposed secre= t value of a node to validate the consistency of the chain of hashed derive= d from that secret. This could be implemented by creating a public value th= at consists of a KDF of the secret value with a known public value for ever= y node that is being updated. To check a secret value, the validating party= needs to compute the KDF for every node up the tree to the root and compar= e with the published values.

The KDF acts as sort = of a public integrity hash of to the node's secret value.
2)=C2=A0Add a Schnorr NIZK of knowledge (RFC 8235) of the rando= m value r with every ECIES ciphertext. This proves that the r used in the E= CIES encryption is known to the updater and rP=C2=A0is not trivially derive= d from some other previously sent r'P.

For one= participant to prove that they were given an update message that did not i= nclude the correct node secret, that participant can reveal the following:<= /div>
arP, DLEQ(arP:rP :: P:aP)

Where a is the= node's private key, and DLEQ is a discrete log equivalence proof that = shows that arP is rP=C2=A0multiplied by the private key a of the use= r.


So in summary, we would add:
- Proof of knowledge of the randomness used in ECIES
- Pub= lic KDF of each node's secret value
and then a member cou= ld prove to an auditor that it was given the wrong secret by revealing:
- an intermediate calculation of the ECIES decryption, a DLEQ p= roof that the right key was used


<= div>I'm eager for this proposal to have some holes shot in it.


Nick


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000002516980580371f3c-- From nobody Thu Jan 24 09:13:32 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 02378131255 for ; Thu, 24 Jan 2019 09:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 yvfI2nIEI7Tl for ; Thu, 24 Jan 2019 09:13:26 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 C057E131250 for ; Thu, 24 Jan 2019 09:13:22 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id s5so5891673oth.7 for ; Thu, 24 Jan 2019 09:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VmUxehPstHRS1Intd2gbf2BymTtfSDQwFuaV5BfL26U=; b=Hui8KDO+NETjjtn5nAnAMfBW7M66eVFySYamXwvGpx50/22Uq1/Dkl4FWv90ot6y1c 1FlztvZiH11Vs6jZim8sffDKVIaiDDBSc4lowzboQixayJNFu0wkuBFxXGDIxM+azMvk DznHyGaIXX9nWitiEsabp+9CShFDPiV0c6qI0= 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=VmUxehPstHRS1Intd2gbf2BymTtfSDQwFuaV5BfL26U=; b=s5zVlh1ohma3/O3fjwFmfrdeVcVz2zxSq/wG+V9ZmTGxPxoSzaBvhTak5nazhgXdlP uHPq+KtEsFciq/wFhE1CZYl8VjaxEOik87y3sKmvo/3AU75itBho40aWsH4xeI84Ho8R uaUVt2WOhvUkf5FYjILiNLBiN0vuPHFmxEBD9ubxZ5SgMsylgYENYO+luXViFxjipUFN CZvMii898VL6lx+ax0sVD/sJaAgNhj6YeqUNcENVhcFcvLjV+EM/ly4OhKqqnV6bKfqj H8gEg7+Ycx0ToTECO9fsKvpPCSQu3tG3yrXEZ9zaqO7jwBhAD4zcDLrHayfm4idB//J7 feIA== X-Gm-Message-State: AJcUukeiVAxlKdc/QgnjuDFc/WJ31CZijHn7T4HabLfrJejKPvcOvlrb QnI7BLZP0iBt3gPNQT9wHfQM1Tc8VhZGMJmA7mgtFR/yCCI= X-Google-Smtp-Source: ALg8bN6+9ror/HWSIozbpa5xwb5zdXHLZMcoRdzBGNoiIuCEKGo+P0xKIO74zfVb+923TXi58oD33P0EDfI2Ft7ZKrk= X-Received: by 2002:a9d:3f7:: with SMTP id f110mr5254172otf.171.1548350001763; Thu, 24 Jan 2019 09:13:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Thu, 24 Jan 2019 09:13:11 -0800 Message-ID: To: Yevgeniy Dodis Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d7fa030580375311" Archived-At: Subject: Re: [MLS] Idea for Issue #33 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, 24 Jan 2019 17:13:30 -0000 --000000000000d7fa030580375311 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 23, 2019 at 7:02 PM Yevgeniy Dodis wrote: > Hi Nick. > > As I told Jon and you in Mountain View, this is a really nice idea. > > A couple of concerns regarding the specific proof of DLEQ by the > receiver. Effectively, a malicious sender > can send a ciphertext of the form for any value Q of its > choice (not necessarily the one where he > knows r such that Q =3D rP, and the receiver will "complain" by opening > the value aQ. In crypto terms, this corresponds > to CDH (computational diffie-hellman) oracle: given (P, P' =3D aP) fixed > and any value Q, return aQ. > > There is an old paper of Maurer and Wolf which shows CDH and discrete > log (DL) are polynomially equivalent in certain groups: > ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol99b.pdf > I think standard groups we use do not fall there, but I did not check > the paper in more detail. > > Of more immediate concern, this opens the following simple chosen > ciphertext attack. Malicious sender wants > to decrypt some old valid ciphertext (C=3DrP, D). He wants to obtain D / > xC, so suffices to compute xC. > He generates random r', and submits ciphertext (C' =3D r' C, garbage). > Receiver will complain by opening > x C' =3D r' (xC), from which can raise to 1/r' to recover xC, and hence > D/xC. > > Is this chosen ciphertext attack possible? What might save us is that > the only people who encrypt to node with public > key aP, are the nodes in the subtree rooted by the sibling of a, since > only then a is on the co-path. And these nodes anyway should be > allowed to decrypt all ciphertexts encrypted using aP to the subtree > rooted at a. But I feel we might concoct a scenario where this attack > could be relevant. Not sure now, just pointing out this concern. The hope was that by requiring the sender to create a Schnorr NIZK that they know r for rP that you couldn=E2=80=99t construct a Q for which reveal= ing aQ does not reveal anything about a previous Q (=3Dr=E2=80=99P without knowing= r=E2=80=99). Is it really possible to do this without solving the DLP for Q with respect to P? I guess if the participant sending the bad update was the one to send r=E2= =80=99 previously then they could construct this proof (for r=E2=80=99+1, for exam= ple) and force the target to reveal a previous group state. This is one of the downsides of TreeKEM=E2=80=99s non-contributiveness, I guess. > > > In general, one malicious insiders are allowed, my feeling is that we > need some kind of CCA protection, and basic ElGamal will not be > secure. > > Still, I love the idea, and hope we can make it work... > Yevgeniy > > > > > > On Wed, Jan 23, 2019 at 8:34 PM Nick Sullivan > wrote: > > > > Hello all, > > > > Relaying some ideas that I posted in the Github issue that allow a > participant that was maliciously removed from the group by a bad update > message to publicly prove that it was given an inconsistent update. This = is > an idea based on lightweight zero-knowledge proofs. > > > > https://github.com/mlswg/mls-protocol/issues/21 > > > > Recall the following from ECIES: > > Say that you are encrypting a ciphertext X to a user with private key a= , > public key A (=3D aP) and elliptic curve base point P. The ECIES cipherte= xt > is the pair (rP, c) where r is a randomly-chosen scalar and c is the > encryption of X with a key derived from k=3DKDF(rA)=3DKDF(raP). > > > > The key to this mechanism is revealing enough to prove to a third party > that an update received by the user is decrypted to an inconsistent X tha= n > an update received by another participant, but without revealing the > private key a (which would compromise the confidentiality of previous > messages). > > > > Proposed modifications of the protocol: > > 1) Add a mechanism that allows a party with access to a supposed secret > value of a node to validate the consistency of the chain of hashed derive= d > from that secret. This could be implemented by creating a public value th= at > consists of a KDF of the secret value with a known public value for every > node that is being updated. To check a secret value, the validating party > needs to compute the KDF for every node up the tree to the root and compa= re > with the published values. > > > > The KDF acts as sort of a public integrity hash of to the node's secret > value. > > > > 2) Add a Schnorr NIZK of knowledge (RFC 8235) of the random value r wit= h > every ECIES ciphertext. This proves that the r used in the ECIES encrypti= on > is known to the updater and rP is not trivially derived from some other > previously sent r'P. > > > > For one participant to prove that they were given an update message tha= t > did not include the correct node secret, that participant can reveal the > following: > > arP, DLEQ(arP:rP :: P:aP) > > > > Where a is the node's private key, and DLEQ is a discrete log > equivalence proof that shows that arP is rP multiplied by the private key= a > of the user. > > > > > > So in summary, we would add: > > - Proof of knowledge of the randomness used in ECIES > > - Public KDF of each node's secret value > > and then a member could prove to an auditor that it was given the wrong > secret by revealing: > > - an intermediate calculation of the ECIES decryption, a DLEQ proof tha= t > the right key was used > > > > > > I'm eager for this proposal to have some holes shot in it. > > > > > > Nick > > > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > --000000000000d7fa030580375311 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed,= Jan 23, 2019 at 7:02 PM Yevgeniy Dodis <dodis@cs.nyu.edu> wrote:
ftp://ftp.inf.ethz.ch/pub/crypto/publicat= ions/MauWol99b.pdf
I think standard groups we use do not fall there, but I did not check
the paper in more detail.

Of more immediate concern, this opens the following simple chosen
ciphertext attack. Malicious sender wants
to decrypt some old valid ciphertext (C=3DrP, D). He wants to obtain D / xC, so suffices to compute xC.
He generates random r', and submits ciphertext (C' =3D r' C, ga= rbage).
Receiver will complain by opening
x C' =3D=C2=A0 r' (xC), from which can raise to 1/r' to recover= xC, and hence D/xC.

Is this chosen ciphertext attack possible? What might save us is that
the only people who encrypt to node with public
key aP, are the nodes in the subtree rooted by the sibling of a, since
only then a is on the co-path. And these nodes anyway should be
allowed to decrypt all ciphertexts encrypted using aP to the subtree
rooted at a. But I feel we might concoct a scenario where this attack
could be relevant. Not sure now, just pointing out this concern.

The hope was that by requir= ing the sender to create a Schnorr NIZK that they know r for rP that you co= uldn=E2=80=99t construct a Q for which revealing aQ does not reveal anythin= g about a previous Q (=3Dr=E2=80=99P without knowing r=E2=80=99). Is it rea= lly possible to do this without solving the DLP for Q with respect to P?

I guess if the participant= sending the bad update was the one to send r=E2=80=99 previously then they= could construct this proof (for r=E2=80=99+1, for example) and force the t= arget to reveal a previous group state. This is one of the downsides of Tre= eKEM=E2=80=99s non-contributiveness, I guess.


In general, one malicious insiders are allowed, my feeling is that we
need some kind of CCA protection, and basic ElGamal will not be
secure.

Still, I love the idea, and hope we can make it work...
Yevgeniy





On Wed, Jan 23, 2019 at 8:34 PM Nick Sullivan
<nick=3D40cloudflare.com@dmarc.ietf.org> wrote:
>
> Hello all,
>
> Relaying some ideas that I posted in the Github issue that allow a par= ticipant that was maliciously removed from the group by a bad update messag= e to publicly prove that it was given an inconsistent update. This is an id= ea based on lightweight zero-knowledge proofs.
>
> https://github.com/mlswg/mls-protocol/issues/21<= /a>
>
> Recall the following from ECIES:
> Say that you are encrypting a ciphertext X to a user with private key = a, public key A (=3D aP) and elliptic curve base point P. The ECIES ciphert= ext is the pair (rP, c) where r is a randomly-chosen scalar and c is the en= cryption of X with a key derived from k=3DKDF(rA)=3DKDF(raP).
>
> The key to this mechanism is revealing enough to prove to a third part= y that an update received by the user is decrypted to an inconsistent X tha= n an update received by another participant, but without revealing the priv= ate key a (which would compromise the confidentiality of previous messages)= .
>
> Proposed modifications of the protocol:
> 1) Add a mechanism that allows a party with access to a supposed secre= t value of a node to validate the consistency of the chain of hashed derive= d from that secret. This could be implemented by creating a public value th= at consists of a KDF of the secret value with a known public value for ever= y node that is being updated. To check a secret value, the validating party= needs to compute the KDF for every node up the tree to the root and compar= e with the published values.
>
> The KDF acts as sort of a public integrity hash of to the node's s= ecret value.
>
> 2) Add a Schnorr NIZK of knowledge (RFC 8235) of the random value r wi= th every ECIES ciphertext. This proves that the r used in the ECIES encrypt= ion is known to the updater and rP is not trivially derived from some other= previously sent r'P.
>
> For one participant to prove that they were given an update message th= at did not include the correct node secret, that participant can reveal the= following:
> arP, DLEQ(arP:rP :: P:aP)
>
> Where a is the node's private key, and DLEQ is a discrete log equi= valence proof that shows that arP is rP multiplied by the private key a of = the user.
>
>
> So in summary, we would add:
> - Proof of knowledge of the randomness used in ECIES
> - Public KDF of each node's secret value
> and then a member could prove to an auditor that it was given the wron= g secret by revealing:
> - an intermediate calculation of the ECIES decryption, a DLEQ proof th= at the right key was used
>
>
> I'm eager for this proposal to have some holes shot in it.
>
>
> Nick
>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
--000000000000d7fa030580375311-- From nobody Thu Jan 24 17:35: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 393B3130DE5 for ; Wed, 23 Jan 2019 19:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LUYcX6AdvC-i for ; Wed, 23 Jan 2019 19:02:00 -0800 (PST) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 DE572130DE4 for ; Wed, 23 Jan 2019 19:01:59 -0800 (PST) Received: by mail-ed1-f47.google.com with SMTP id y20so3366620edw.9 for ; Wed, 23 Jan 2019 19:01:59 -0800 (PST) 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:content-transfer-encoding; bh=GyNRg6UWTnMFZFZIo4VSqLxxI1jxecrBjEXiSnW9jmg=; b=KJvaJl778zj7IMTtgDTfvRbQ54w/9hLct2sxB/H7+WdcXkFiGLqBgfZywyITtd00r5 ES3Z1iPHzRLc7DYQLYtyIZEnf9GT7UZ4ojKQw09gw6yYXodyGaz92UqWWGZYC7fQorG8 ZKbLM0x5DVRVXNuTUG1waL/sHpaN/qdiDrCggIvnVWFrfgXMxQwJczpiEGSWZF5VNsNp M7LLE6bPVHr64lzP8xCfH/X8tPFXol5PV3j/JM3vYK+C3IaRDtl97WUEmPfSK0c+ej5P R671X/vswp/1fbJv0unZT1xfuL+NYn/M2fcewr2KbOgXWCwGTdAiQPR7dKszj8peKVHF x4fw== X-Gm-Message-State: AJcUukejL9Q1FX2QX8+4WYCYJ1v1Ph3o4wCv3HMoD80HIT/d8MCh4DqP ZmXxu0As4iIK6wslTDspybp6XPpjd3cAjq2qrQt2PqQ/ X-Google-Smtp-Source: ALg8bN5oLvoE8zoUDKGTceWy91J4FhyLGvy7bpxzXij188PiD61h6zsli+sOOs0+s6nQtspCxsTZukCIY8DBgJcNF7Y= X-Received: by 2002:a50:f4c3:: with SMTP id v3mr4848859edm.196.1548298917767; Wed, 23 Jan 2019 19:01:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yevgeniy Dodis Date: Wed, 23 Jan 2019 22:01:47 -0500 Message-ID: To: Nick Sullivan Cc: "mls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 24 Jan 2019 17:35:02 -0800 Subject: Re: [MLS] Idea for Issue #33 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, 24 Jan 2019 03:02:02 -0000 Hi Nick. As I told Jon and you in Mountain View, this is a really nice idea. A couple of concerns regarding the specific proof of DLEQ by the receiver. Effectively, a malicious sender can send a ciphertext of the form for any value Q of its choice (not necessarily the one where he knows r such that Q =3D rP, and the receiver will "complain" by opening the value aQ. In crypto terms, this corresponds to CDH (computational diffie-hellman) oracle: given (P, P' =3D aP) fixed and any value Q, return aQ. There is an old paper of Maurer and Wolf which shows CDH and discrete log (DL) are polynomially equivalent in certain groups: ftp://ftp.inf.ethz.ch/pub/crypto/publications/MauWol99b.pdf I think standard groups we use do not fall there, but I did not check the paper in more detail. Of more immediate concern, this opens the following simple chosen ciphertext attack. Malicious sender wants to decrypt some old valid ciphertext (C=3DrP, D). He wants to obtain D / xC, so suffices to compute xC. He generates random r', and submits ciphertext (C' =3D r' C, garbage). Receiver will complain by opening x C' =3D r' (xC), from which can raise to 1/r' to recover xC, and hence D/= xC. Is this chosen ciphertext attack possible? What might save us is that the only people who encrypt to node with public key aP, are the nodes in the subtree rooted by the sibling of a, since only then a is on the co-path. And these nodes anyway should be allowed to decrypt all ciphertexts encrypted using aP to the subtree rooted at a. But I feel we might concoct a scenario where this attack could be relevant. Not sure now, just pointing out this concern. In general, one malicious insiders are allowed, my feeling is that we need some kind of CCA protection, and basic ElGamal will not be secure. Still, I love the idea, and hope we can make it work... Yevgeniy On Wed, Jan 23, 2019 at 8:34 PM Nick Sullivan wrote: > > Hello all, > > Relaying some ideas that I posted in the Github issue that allow a partic= ipant that was maliciously removed from the group by a bad update message t= o publicly prove that it was given an inconsistent update. This is an idea = based on lightweight zero-knowledge proofs. > > https://github.com/mlswg/mls-protocol/issues/21 > > Recall the following from ECIES: > Say that you are encrypting a ciphertext X to a user with private key a, = public key A (=3D aP) and elliptic curve base point P. The ECIES ciphertext= is the pair (rP, c) where r is a randomly-chosen scalar and c is the encry= ption of X with a key derived from k=3DKDF(rA)=3DKDF(raP). > > The key to this mechanism is revealing enough to prove to a third party t= hat an update received by the user is decrypted to an inconsistent X than a= n update received by another participant, but without revealing the private= key a (which would compromise the confidentiality of previous messages). > > Proposed modifications of the protocol: > 1) Add a mechanism that allows a party with access to a supposed secret v= alue of a node to validate the consistency of the chain of hashed derived f= rom that secret. This could be implemented by creating a public value that = consists of a KDF of the secret value with a known public value for every n= ode that is being updated. To check a secret value, the validating party ne= eds to compute the KDF for every node up the tree to the root and compare w= ith the published values. > > The KDF acts as sort of a public integrity hash of to the node's secret v= alue. > > 2) Add a Schnorr NIZK of knowledge (RFC 8235) of the random value r with = every ECIES ciphertext. This proves that the r used in the ECIES encryption= is known to the updater and rP is not trivially derived from some other pr= eviously sent r'P. > > For one participant to prove that they were given an update message that = did not include the correct node secret, that participant can reveal the fo= llowing: > arP, DLEQ(arP:rP :: P:aP) > > Where a is the node's private key, and DLEQ is a discrete log equivalence= proof that shows that arP is rP multiplied by the private key a of the use= r. > > > So in summary, we would add: > - Proof of knowledge of the randomness used in ECIES > - Public KDF of each node's secret value > and then a member could prove to an auditor that it was given the wrong s= ecret by revealing: > - an intermediate calculation of the ECIES decryption, a DLEQ proof that = the right key was used > > > I'm eager for this proposal to have some holes shot in it. > > > Nick > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Sat Jan 26 10:25:25 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 0E4F8130F44 for ; Sat, 26 Jan 2019 10:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1Z3UV_eKZy-J for ; Sat, 26 Jan 2019 10:25:21 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0: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 65FBA130F19 for ; Sat, 26 Jan 2019 10:25:21 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id k98so11437201otk.3 for ; Sat, 26 Jan 2019 10:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=awvC9xnLnWBtXhgIblrT6QJzjc0kY8kOUpWrFeDb2R8=; b=hdjIKrBCP++qyzfimUQ6iN1wcvAvk3/99BvNU4Qefx6ETgHpXYvJ/uygMrz/+YQLqC EtBYloSvTmmt8W7x7GMJOkPPje5gLNSIMGdr0rf+SJvDEoWM7RGdgrqLeBIoLZV9Ewgk /U2muErPd8D02XZ2QVq9MpaRYAwLRF7nRDIsYZykwAgZDFr2rPrfDHoOdYMi9opYPeo7 x+f04W8q/4Ru/JISsQoUtNWFNGr+1ovt0kif5w846douUXwsgQTYDWDqW7mIudaZP7/N 9BNZDz6byXYLe4fjWns7PvArIeK0yMC+0VpOj7g49E8t6CwEmfmhKhv/55Rx8C6t1bUk sxGA== 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=awvC9xnLnWBtXhgIblrT6QJzjc0kY8kOUpWrFeDb2R8=; b=CFxCl8j6Zh14Hep0xFh8UHd1rgYz4VT0p4Gl0aCqKbB6Qi5mDV/GLqvtMBtzw7v2DO vGaHzJjq5TF5V/4dUrvHFk3TAmSaDD8MhMaSxSmUWA1FK6LHqrunKC7sK3qrvcyj1ZK6 CjbJIwbLcLc5HNn38b2suItBwh1adYgNwzlVqRBNy4HDg/9w18LH8sAFqkRwvcS3iT4M 8scYGI5zbXQWdFulpXeiR3xAOOW+WTOrfY9QmdE7T4P0Sjs1Okcr+Jt009TJHaXCIwJy rZeW/y6Hd5fpqlM1F0Xa273YL2ifOxW2ozdfEButkdj+hYXE6BV59kFO/JS9dlX43K6i HYTw== X-Gm-Message-State: AJcUukdSwLRxjHe7rOCZM2APeD35jaq6RC46jRMBM5Rf7HY1e5lJowFT toNBmYpA6q92bTo/FU44BGc7m9bfJLF/wHXpc9Xpf4giN/w= X-Google-Smtp-Source: ALg8bN5TzOaL+tcf7m8VDHBnAo3CigIKX9ge+hb4c2Cx86WAWtFkYLSndDq2p3JDIIU3LEqSESPp1kq7SfmDwfZQ+D8= X-Received: by 2002:a9d:3424:: with SMTP id v33mr11147453otb.167.1548527120311; Sat, 26 Jan 2019 10:25:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sat, 26 Jan 2019 13:25:04 -0500 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000ee7b620580609064" Archived-At: Subject: Re: [MLS] February MLS interop event 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, 26 Jan 2019 18:25:24 -0000 --000000000000ee7b620580609064 Content-Type: text/plain; charset="UTF-8" OK, based on the Doodle results, let's shoot for 16:00-19:00 UTC https://www.timeanddate.com/worldclock/fixedtime.html?msg=MLS+Interop&iso=20190208T16&p1=1440&ah=3 We can use the following Webex bridge: Join from a video conferencing system or application Meeting link: https://cisco.webex.com/meet/richbarn Dial: richbarn@cisco.webex.com Join using Microsoft Skype for Business: richbarn.cisco@lync.webex.com Toll Free: +1-866-432-9903 Toll: +1-408-525-6800 Access Code: 201006237 If you're interested in joining, please make sure you're in the MLS Implementors Wire channel, which we'll use for text-based coordination. https://app.wire.com/join/?key=3tL-NJOoCKZlDXNU1H2c&code=kZOc0ujnDQ9Tq98tLfSt On Tue, Jan 15, 2019 at 8:01 PM Richard Barnes wrote: > Hey all, > > A few of us who are writing code for MLS are thinking of having an > informal interop event in early February. If you'd like to participate, > please fill out this Doodle to help pick dates: > > https://doodle.com/poll/2yd3b2eydchis82b#table > > The interop target will be draft-ietf-mls-protocol-03. We will try to get > everyone passing a common set of test vectors, covering, e.g.: > > - Tree math > - Derive-Key-Pair > - Message parsing and serialization > - Fully crypto calculations for a simple scenario > > This will be a remote meeting / teleconference. I will send out Webex > details once we've picked a date/time. > > --Richard > > --000000000000ee7b620580609064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, based on the Do= odle results, let's shoot for 16:00-19:00 UTC


We can use the follow= ing Webex bridge:

Join from a video conferencing s= ystem or application
Meeting link: https://cisco.webex.com/meet/richbarn
Dial: richbarn@cisco.webex.com
Join using= Microsoft Skype for Business: richbarn.cisco@lync.webex.com
Toll Free: +1-866-432-9903
Tol= l: +1-408-525-6800
Access Code: 201006237

If yo= u're interested in joining, please make sure you're in the MLS Impl= ementors Wire channel, which we'll use for text-based coordination.



On Tue, Jan 15, 2019 at 8:01 PM Richard B= arnes <rlb@ipv.sx> wrote:
Hey all,
<= br>
A few of us who are writing code for MLS are thinking of havi= ng an informal interop event in early February.=C2=A0 If you'd like to = participate, please fill out this Doodle to help pick dates:

=
<= br>
The interop target will be draft-ietf-mls-protocol-03.=C2=A0 We wi= ll try to get everyone passing a common set of test vectors, covering, e.g.= :

- Tree math
- Derive-Key-Pair
= - Message parsing and serialization
- Fully crypto calculatio= ns for a simple scenario

This will be a remot= e meeting / teleconference.=C2=A0 I will send out Webex details once we'= ;ve picked a date/time.

--Richard
--000000000000ee7b620580609064-- From nobody Thu Jan 31 14:44:50 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 80A25130F72; Thu, 31 Jan 2019 14:44:48 -0800 (PST) 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.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154897468845.10119.18328777443458343252.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2019 14:44:48 -0800 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 104 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, 31 Jan 2019 22:44:49 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 125 Conflicts to Avoid: First Priority: acme artarea cfrg dispatch iasa2 httpbis perc quic rtcweb saag secdispatch tls Second Priority: curdle dprive lamps sidrops stir suit teep People who must be present: Eric Rescorla Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: ---------------------------------------------------------