From nobody Mon Aug 22 12:04:17 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18212D798; Mon, 22 Aug 2016 12:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 3mNRk_xNa5nZ; Mon, 22 Aug 2016 12:04:11 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 1D61312D5A5; Mon, 22 Aug 2016 12:04:10 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l2so89950829qkf.3; Mon, 22 Aug 2016 12:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=R46glwfuinuQEXLMMrmIX627Z2aZvla+rlJjE7vw5cg=; b=keaCnE+bLsLTjpdMBg/AcCyQ+V0QcBNJ149Y9ZYkfHmMjtapAB16idE5TDII9jRQaS q751gL+9farQVjEOVQZ0prfs+HHDMgGIzEue5e8enNuaYWj/FSn4enD5iS7RhqaaN/nv vbkgzpgtPaPylVBNWdtNgIv7mUR+WcS69KIEUZQeyi1nr30eC4vX9hz0XoxnaP9IYzrc OPJA6N+UQeMeJfMr05fYyzRnQ60jMINPEgyT4riD2w5PRR9KfAVQJo3pR4xlZq83RTaq VwtFaGJcMSlQruUC7wU6gmiJSbekod7q2pe0qjkU1m3gDJQn9D/ypqy3J0IxP3bFym8l UBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=R46glwfuinuQEXLMMrmIX627Z2aZvla+rlJjE7vw5cg=; b=aTxoNnjekXqRWwy9PzGll2tHJt/jh7STP+MblkQf1PRprKpjgDpsz83L7fA0R6f1j4 bLpbfWHxZdpf9DPYpFDFMK5nZgCt/VRXIe4DVIdgxeR+73jLuDJNF7MD27JGgh8UJERy i9mnYyLgbUFuzOQtzoZfKfluViMucW/ta4SaN1YZPyNqbPqwU785PyYofwPlZTANUuhJ d8qHo1KlRpRN0CyP28C8hOvUm1MDv7Utf1TzLDoPyRFSw79yrtV3MTY121rRzq+nUC0U 5L+Tj8z6iRQw1+efDmnnZxGLSofz/WQ/HtvIQ8Gk4fOaMXxzBHLOaOW6EdwEjXbDdmQN p3gg== X-Gm-Message-State: AEkoouvQKIC7CxVert2ulSeT/mmxwGoWbXVSWCReMY4p06hcAGt78jaCPp+vC9xvsFQVQxnlX/sM3cmHucPVxA== X-Received: by 10.55.99.195 with SMTP id x186mr25013950qkb.26.1471892649031; Mon, 22 Aug 2016 12:04:09 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.168.151 with HTTP; Mon, 22 Aug 2016 12:04:08 -0700 (PDT) From: Phillip Hallam-Baker Date: Mon, 22 Aug 2016 15:04:08 -0400 X-Google-Sender-Auth: 2E1H8l7X350QRopIPTuJz1XG-oU Message-ID: To: endymail , "cfrg@irtf.org" , IETF OpenPGP , IETF SMIME Content-Type: multipart/alternative; boundary=001a114d38227e3edd053aadb633 Archived-At: Subject: [Endymail] Proposal to use Proxy Re-Encryption in a messaging protocol X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:04:12 -0000 --001a114d38227e3edd053aadb633 Content-Type: text/plain; charset=UTF-8 NB: Please direct followups to endymail@ietf.org alone The draft is at: https://www.ietf.org/id/draft-hallambaker-mesh-recrypt-00.txt At the last IETF, I made a presentation on the use of Proxy Re-Encryption 'recryption' at the CFRG session=. I think that this is a very powerful technique that solves some real problems we are facing today that were probably not as apparent when it was first proposed. In particular, recryption allows end-to-end security to be preserved in situations where it would normally be lost. For example in a mailing list application or in a situation where Alice needs to read her email on multiple devices, some of which might be mobile devices that could get lost. Recryption also provides the ideal basis for Confidential Document Control which is an access control system that uses data level encryption, One slight holdup here is that there is a patent encumbrance that purports to claim the use of recyption for DRM applications but this will expire shortly, certainly before any project could get off the ground. I have written an Internet draft showing how Recryption might be implemented as a 'clean slate' protocol. Since we don't have anything like a CDC application yet (Plasma maybe), this is going to be a requirement for some situations. I am thinking we should probably try to build something and work out how to get that running before working out how best to fit these capabilities to S/MIME, OpenPGP, Jabber, etc. Contrary to my usual practice, there is no code so far, well no implementation code.I will be filling that in once I finish a few things ahead of this in the queue, specifically using the Mesh to manage SSH keys. The one technical holdup I see here is that if we are going to get people to use it, usability can't be 'OK' or 'not bad'. The only way to get a new crypto system off the ground is to design something that delivers usability that is iPhone level perfect. I think that the Mesh makes that possible of course but I will probably have to prove that with some demos. Which is why I want to get the Mesh to manage SSH keys. --001a114d38227e3edd053aadb633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
NB:= Please direct followups to endymail@i= etf.org alone


The draft is at:<= /div>

https://www.ietf.org/id/draft-hallambaker= -mesh-recrypt-00.txt


At the= last IETF, I made a presentation on the use of Proxy Re-Encryption 're= cryption' at the CFRG session=3D. I think that this is a very powerful = technique that solves some real problems we are facing today that were prob= ably not as apparent when it was first proposed.

In particular, recryption allows end-to-end securit= y to be preserved in situations where it would normally be lost. For exampl= e in a mailing list application or in a situation where Alice needs to read= her email on multiple devices, some of which might be mobile devices that = could get lost. Recryption also provides the ideal basis for Confidential D= ocument Control which is an access control system that uses data level encr= yption,

One slight holdup= here is that there is a patent encumbrance that purports to claim the use = of recyption for DRM applications but this will expire shortly, certainly b= efore any project could get off the ground.


I have written an Internet draft showing how Recryption might be= implemented as a 'clean slate' protocol. Since we don't have a= nything like a CDC application yet (Plasma maybe), this is going to be a re= quirement for some situations. I am thinking we should probably try to buil= d something and work out how to get that running before working out how bes= t to fit these capabilities to S/MIME, OpenPGP, Jabber, etc.

Contrary to my usual practice, there is= no code so far, well no implementation code.I will be filling that in once= I finish a few things ahead of this in the queue, specifically using the M= esh to manage SSH keys.

<= br>
The one tec= hnical holdup I see here is that if we are going to get people to use it, u= sability can't be 'OK' or 'not bad'. The only way to ge= t a new crypto system off the ground is to design something that delivers u= sability that is iPhone level perfect. I think that the Mesh makes that pos= sible of course but I will probably have to prove that with some demos. Whi= ch is why I want to get the Mesh to manage SSH keys.



--001a114d38227e3edd053aadb633-- From nobody Mon Aug 22 19:48:59 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F85C12D846 for ; Mon, 22 Aug 2016 19:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 iAmsM9JR-kMZ for ; Mon, 22 Aug 2016 19:48:55 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C1812D107 for ; Mon, 22 Aug 2016 19:48:55 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 74so223053446uau.0 for ; Mon, 22 Aug 2016 19:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q7Y0gi64nEYbb8bbrxQpUI+kBYAelMTlmgzXV6CyE4A=; b=EN3eFw99CLALoP3Az21JDOGGmctRbjuXZrF0LNJDkSFFOT5OjLW/bDIQDaOBOouVOt wLqFWPGRAQAgJPLh1M5oVSuc7JdvTYR714h4+veZM6pj52P95M3tl1H8hxgAfGgrwAJV g1FPdoTFbt85yrR9ZlK72pruqvlVEdKxny70z8JXY8CXJ/yRUOY3Hm2DzicOEKFTsRvh VUwC/nMdlHEscLTcjJO/crmSwA9hn13juv7Igs25vyFfQVLS/PYtTo0WwjGr7JwDiKdC S6I+yN/1fs8B2IBqY59gt/4+Q2bJtuWHSd9m16UedVFhIXUHAnejvfiYULdgve1a4b82 6KQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q7Y0gi64nEYbb8bbrxQpUI+kBYAelMTlmgzXV6CyE4A=; b=L0ULlCjyh1zCCn7l9UD6JoUr5PftTXZwNj/YpyCFP+2oz0ZaeBBYmWK6Re5U9EVOu5 v9MJK2CBL17hC76z2vH9nk28JiPRPNFNn2l4ny4wEz9mhXZm8Awp9HorekIsqyQ2gGPO PLZgFC9x89lqniEqSwbX3sAKkmaExRf/QOvPPSJS8ErJ+NxJa5qEWW5mS1+raGFzX74h FgnYruOzYS72qmDDc1CGdovgB+HHR18KC9w7Mn01cSKO7g4a7LDHi+TsDBxq/Hfrsxzw K7IvtrKKcBc9bAqNm4EkzSDPOq5X0CDzVK+hcj/8/M/BxY3FP0NLnNU/p6ByH77e3jDD aIRA== X-Gm-Message-State: AEkoouv/YEYUIVr7hOV+TE+VK08j87REo4d20dru54vYpBk5Cn3uhBzUoPzK4D9yAXni0sDGLlFtZWXcGjamRg== X-Received: by 10.176.2.242 with SMTP id 105mr13461665uah.10.1471920534234; Mon, 22 Aug 2016 19:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.82.27 with HTTP; Mon, 22 Aug 2016 19:48:33 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Mon, 22 Aug 2016 19:48:33 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a1142e55094afe1053ab4349f Archived-At: Cc: messaging , endymail@ietf.org Subject: Re: [Endymail] [messaging] Mesh/Recrypt X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 02:48:56 -0000 --001a1142e55094afe1053ab4349f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2016 at 4:48 PM, Phillip Hallam-Baker wrote: > =E2=80=8BI suggested followups to the endymail@ietf.org mailing list rath= er than > CFRG though. > Ok, CC'd! That said, here's a followup: I was kind of confused why you cite RFC7748, but then go on to explain things in terms of classical Diffie-Hellman. As far as an ECC-based approach goes, I think something like the multiparty Signal protocol[1] is a good starting point for how to solve the general problem, and, as far as I can tell, addresses most of the concerns you cited as a motivation. The specific approach you detailed could be adapted to ECC as well. [1] I'm not sure there's a more recent overview than this, which is probably out-of-date: https://whispersystems.org/blog/private-groups/ --=20 Tony Arcieri --001a1142e55094afe1053ab4349f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 22, 2016 at 4:48 PM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
=E2=80=8BI suggested fol= lowups to the endyma= il@ietf.org mailing list rather than CFRG though.

Ok, CC'd! That said, here's a followup:<= /div>

I was kind of confused why you cite=C2=A0RFC7748, but then go on to exp= lain things in terms of classical Diffie-Hellman.

As far as an ECC-based appro= ach goes, I think something like the multiparty Signal protocol[1] is a goo= d starting point for how to solve the general problem, and, as far as I can= tell, addresses most of the concerns you cited as a motivation.

The specific = approach you detailed could be adapted to ECC as well.

[1] I'm not sure there's a more recent overview t= han this, which is probably out-of-date:=C2=A0https://whispersystems.org/blog/private-grou= ps/

--
Tony Arcieri
--001a1142e55094afe1053ab4349f-- From nobody Mon Aug 22 19:57:49 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E2812D1A2 for ; Mon, 22 Aug 2016 19:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=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 RT5pcuA3mp91 for ; Mon, 22 Aug 2016 19:57:46 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 9A738124281 for ; Mon, 22 Aug 2016 19:57:46 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v123so95995092qkh.2 for ; Mon, 22 Aug 2016 19:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=O93CzImOdRSAQbHZoHJWp3DB1pHMimNExNskX3rxeQA=; b=XnYp6Eet4idJLU95s34eknPn+1Mn266kGrSuSbxZrlwNzb8CX+vFP6ZEXDBXxyQzao acmc1S8W4rOyinA2XW9KrFxXbYomz7OQYc9IxupItc3XyqDCaZygu+WUywrXcWYaMv6l 5aq5Y04u7Y3d+ylAbME7AMTAAT261J7AohVDTburu1zwgf3eoD2TawUW+DS9hSP5Tx2y z+XFTyn7+82pQaOYp8Y2NxZDRlRHnhGk3isCSvmcnQgj2l+P2/9ZpACnBhmhMlyKnG9E zzULNlCrXYRGrJqGrV5ligG8wicHi7N/5RJcaPebNqX50+26lhbU8ubnTpyvorTOiNS1 Yefw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=O93CzImOdRSAQbHZoHJWp3DB1pHMimNExNskX3rxeQA=; b=LIAvI0Tr1IRE0JDp3KoA3a/m0/aRozCZeJUD+lC5pNMwTW4BlSbjvD0AdGZT3DEE9l eJGii586jdhV5J7CUBRKEux7keDVo2v4NCWP72evyt8FA4gO1fjRPEcXoLBaYxuIWyfv j8kyrdWo+rm2X9PBHA6XP6bJeN3Qr60thsgLTaCnbjcHb307LxphH4WyI0u6KmBni3Vf q44m/CyoOt/ZhGkpj5pxs9ABQnLtWlgSjzBudW+Q0IUISTiAX+a/bSq6HGcHk/o43yOj OhfBi7O3fOYdRRlhB3oIHLtUzulJV0F7joIA+6u8IcP6YhbcAr66/U9402sjHEVuoSiS RhQw== X-Gm-Message-State: AEkoouvO/k7C0MSc5+biq5ZHPgVAPtroeoKZfPWNwXf3yDF+HbajSThazfRKP6uSIH6aBXy4Gc56q+2v/wsEyA== X-Received: by 10.55.186.65 with SMTP id k62mr27493365qkf.204.1471921065703; Mon, 22 Aug 2016 19:57:45 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.158.211 with HTTP; Mon, 22 Aug 2016 19:57:45 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 22 Aug 2016 22:57:45 -0400 X-Google-Sender-Auth: NFT051DSRsGfbhxWh4PL36KAHGA Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=94eb2c0441ce423ec0053ab45445 Archived-At: Cc: endymail Subject: Re: [Endymail] [messaging] Mesh/Recrypt X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 02:57:48 -0000 --94eb2c0441ce423ec0053ab45445 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2016 at 10:48 PM, Tony Arcieri wrote: > On Mon, Aug 22, 2016 at 4:48 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> =E2=80=8BI suggested followups to the endymail@ietf.org mailing list rat= her than >> CFRG though. >> > > Ok, CC'd! That said, here's a followup: > > I was kind of confused why you cite RFC7748, but then go on to explain > things in terms of classical Diffie-Hellman. > =E2=80=8BA limitation in my development environment=E2=80=8B. I have classi= cal DH and NIST curves. But I don't have the new curves or the abilty to do the EC math outside the crypto library so I can't to the recryption at the mo. As far as an ECC-based approach goes, I think something like the multiparty > Signal protocol[1] is a good starting point for how to solve the general > problem, and, as far as I can tell, addresses most of the concerns you > cited as a motivation. > > The specific approach you detailed could be adapted to ECC as well. > > [1] I'm not sure there's a more recent overview than this, which is > probably out-of-date: https://whispersystems.org/blog/private-groups/ > > =E2=80=8BThe math is very similar and they can probably adapt very easily. = The difference is that their problem statement is for synchronous communication with all the parties present for the key exchange. Recryption allows the asynchronous case to be supported as well. The CDC problem is essentially the problem of how do I mark a document with a security label in a way that the administrator of the security label can grant access to a new reader by adding them to the label. I will read up on that though, thanks!=E2=80=8B --94eb2c0441ce423ec0053ab45445 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Au= g 22, 2016 at 10:48 PM, Tony Arcieri <bascule@gmail.com> wro= te:
On Mon, Aug 22, 2016 at = 4:48 PM, Phillip Hallam-Baker <phill@hallambaker.com> wr= ote:
=
=E2=80=8BI suggested followups to the endymail@ietf.org mail= ing list rather than CFRG though.

Ok, CC'd! That said, here's a followup:
I was kind of confused why you cite=C2=A0RFC7748, but then go on to explain things i= n terms of classical Diffie-Hellman.

=E2=80=8BA limitation in my development environment=E2=80=8B. I have c= lassical DH and NIST curves. But I don't have the new curves or the abi= lty to do the EC math outside the crypto library so I can't to the recr= yption at the mo.


=
As far as an ECC= -based approach goes, I think something like the multiparty Signal protocol= [1] is a good starting point for how to solve the general problem, and, as = far as I can tell, addresses most of the concerns you cited as a motivation= .
T= he specific approach you detailed could be adapted to ECC as well.

[1] I'm not sure there's a more recen= t overview than this, which is probably out-of-date:=C2=A0https://w= hispersystems.org/blog/private-groups/


=E2=80=8BThe math is very similar and they can probably adapt very easi= ly. The difference is that their problem statement is for synchronous commu= nication with all the parties present for the key exchange. Recryption allo= ws the asynchronous case to be supported as well.

The CDC problem is essentially the problem of how = do I mark a document with a security label in a way that the administrator = of the security label can grant access to a new reader by adding them to th= e label.

I will read up o= n that though, thanks!=E2=80=8B

=C2=A0
--94eb2c0441ce423ec0053ab45445-- From nobody Sun Aug 28 17:59:51 2016 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EBE12D0B1 for ; Sun, 28 Aug 2016 17:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 3JrckchPb43k for ; Sun, 28 Aug 2016 17:59:48 -0700 (PDT) Received: from straum.hexapodia.org (straum.hexapodia.org [192.235.78.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BBC12B069 for ; Sun, 28 Aug 2016 17:59:48 -0700 (PDT) Received: by straum.hexapodia.org (Postfix, from userid 22448) id A6A414384; Sun, 28 Aug 2016 17:59:47 -0700 (PDT) Date: Sun, 28 Aug 2016 17:59:47 -0700 From: Andy Isaacson To: Tony Arcieri Message-ID: <20160829005947.GM745@hexapodia.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Old-GPG-Fingerprint: 1914 0645 FD53 C18E EEEF C402 4A69 B1F3 68D2 A63F X-GPG-Fingerprint: A5FC 6141 F76D B6B1 C81F 0FB7 AFA0 A45F ED3D 116D X-GPG-Key-URL: http://web.hexapodia.org/~adi/gpg.txt X-Domestic-Surveillance: money launder bomb tax evasion User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: messaging , Phillip Hallam-Baker , endymail@ietf.org Subject: Re: [Endymail] [messaging] Mesh/Recrypt X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 00:59:49 -0000 On Mon, Aug 22, 2016 at 07:48:33PM -0700, Tony Arcieri wrote: >As far as an ECC-based approach goes, I think something like the multiparty >Signal protocol[1] is a good starting point for how to solve the general [snip] >[1] I'm not sure there's a more recent overview than this, which is >probably out-of-date: https://whispersystems.org/blog/private-groups/ Based on a bit of experimenting with the various language implementations of libsignal, I'm pretty sure Signal group messages don't do the encrypt-to-each-recipient thing anymore. But I haven't tried to interoperate with or even study the mainline client, so it's possible I'm missing something. -andy