From nobody Mon Feb 5 10:17:23 2018 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 30F7612D88D for ; Mon, 5 Feb 2018 10:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 zfGzMD2aX1wf for ; Mon, 5 Feb 2018 10:17:21 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 E011012D886 for ; Mon, 5 Feb 2018 10:17:17 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id b52so10307411wrd.10 for ; Mon, 05 Feb 2018 10:17:17 -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=ylh0pMzHG8I9o9HjsaRiFUYyjyTRnwwS+f+A69pFsns=; b=jYKpv7R0qZweYLaPf5//73mK1UxA0ChHo42bEF9mqgnN0ELGu0PpOIXhLIXt4azfDH OVa4puDc40eTq/c2k1l5rHsoJs41Z9omv3NYdKGbrlPaVRrjNU2I6/dE3SgLGH8RA0yp Lix8OEJwOLpqQnvblY58aKjBwoV1a2kFv0aehbh5unXsYD3/yYnKWl48U0zNj54WC3zq oGRXyfHDwRu3wsjLKW27QN1cnvltctkB82yKAfzfg7Nh0NycFVpUENA4co2TSJPyYFiD 265aRP8gr+oIZ6LTfxjkTrxKR3h8Jkhe94Pt6dp+pTbp5xnbAHA12BayIIt6L4SpsJDS pJcQ== 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=ylh0pMzHG8I9o9HjsaRiFUYyjyTRnwwS+f+A69pFsns=; b=GyX7DGPJpo3RnnVBRHjJLYRKQ8wNFX57Zv4AhPC5BWr2AMBacBefJhRce0yiA114L3 UNYfqQpgOoVnU/ycPviA6v5WWamNNlVARJZ0T9kKl28lb+q6dVKu2adxB/1vOnOUKrCA UPi8IQcdb3HSazzCEkRYUdzbKsofEzqireuaD96v2MkVDCEuiBzvu+5fLMmfGUAdkP3D g5gC2kUemItH7541t455GJ+lKTvflV827qwsCUXDKWUmi+R9aMmJ3npe6nazzwYwgY2M QYe4R52iddQXXEL7wW1jv2EhCKFvC4FDa76zE4br/4m4UHPprLKLW9FNocLpuX/x+ujJ xXqg== X-Gm-Message-State: AKwxyteD5Yl6EB8Ke762G7VUEX8+aXGJn0EU1ruFskpSTOfYVWUEEplm KlpFKhTIrNtS3kSv7L+Yi1+3RpvHDmcfDMbwB2zmffI0 X-Google-Smtp-Source: AH8x225lzuVqx3NSjo64nGJbP8uPJApt/yNnwxwfvaets5+UGIAdMhNDNtvqtq4p8TuabP83Oha53a9TJmoqWXn7x84= X-Received: by 10.223.157.129 with SMTP id p1mr18007215wre.95.1517854636108; Mon, 05 Feb 2018 10:17:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.20.66 with HTTP; Mon, 5 Feb 2018 10:17:15 -0800 (PST) From: Richard Barnes Date: Mon, 5 Feb 2018 10:17:15 -0800 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="f4030439c7b46802ba05647b12bd" Archived-At: Subject: [Mls] Test / Welcome X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 18:17:22 -0000 --f4030439c7b46802ba05647b12bd Content-Type: text/plain; charset="UTF-8" Hey all, This is just a test message to make sure the list is working, and to welcome everyone who's subscribed already. I'll follow up with a few other issues soon. --Richard --f4030439c7b46802ba05647b12bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

This is just a test= message to make sure the list is working, and to welcome everyone who'= s subscribed already.=C2=A0 I'll follow up with a few other issues soon= .

--Richard
--f4030439c7b46802ba05647b12bd-- From nobody Mon Feb 5 10:20:49 2018 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 B5D17124B17 for ; Mon, 5 Feb 2018 10:20:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 kz4T_4nSlcEk for ; Mon, 5 Feb 2018 10:20:46 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 D541A120713 for ; Mon, 5 Feb 2018 10:20:45 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 141so27605068wme.3 for ; Mon, 05 Feb 2018 10:20:45 -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=At2BNzJWaBoXVHz+bOTBunCnpkzlWQ8Acu13KQH9z+k=; b=P/y7XHzwb4isF+KCsVGlpXX2fUuskJtfCa9/KbAuZk0pDRpYNEub227j4l3yKFgFqa fXETBa0Soy5es8r6TW/QC5yc/sbUjM3vp2hYxe3Ny//ZxvhIXBo40Cg94hhWbXV7s41s ldHQdUhm6FcFeyM5uFPSo3CSgXmrM/2tZGEmxajMNDP7l9QyIjctnSUvBGxjmbZ6GxKJ UhmfnUXgk9RxighJZLAAGjolfIDZSv8+gPUHZLIJ1codCG82/2M7GYWRYGZGVD6RjfHk M2CgNfsxHwv9u++wEXx0xVJyJQgtshu8mULYsruqhIRBlPo89XNIR10x89bfm52I01ZN KBeA== 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=At2BNzJWaBoXVHz+bOTBunCnpkzlWQ8Acu13KQH9z+k=; b=KSJfotkawqKa+FHpLQZoj85PPYlEQbplPD39OhzGW8UJfqIln5PyxcJvUBeQB+Qxsh q3GC8zXmXWk2/B6zrbb1M+n/Ghd+bi+WFK4WoIKvij6dd2urQJw6ItbOvwCxWwyczHgY Vf4orb+LXxKYDaVOjN5HxsfDqbzwgtHg8RyVz1vuT/mMhTKG1FOrEx6bnvIOIqG9FpDs /nLuoFgXReiA3LaO7e/dfZjGK9ViF0VS5aAfVzOx7HXEn5IwDlFkRmX25rj5iTaBqfSF X6vaqoO7Fwka/KVvDkWZA41uh6+mYIv4CrLXta6xvaMBLptL+4K4PFlDPSV6NBpwUg0m FbsQ== X-Gm-Message-State: APf1xPCaF+WMIdPPX4kVAdtqhe6TO0ktTsIRg1nB950U8jAGwVFqq5jb 8Sb64BEEePUtdKX2wnRrc5FW6Q5sOQbDIrYdMNU1933vH6I= X-Google-Smtp-Source: AH8x226GZJeV0Mp1F7acaB0uWUX2sVeJEiqer5IJeisGodI4F+lT7rfjEwC9da+BXEM9lQb6TjGzk4BjdXsLeB2GFbg= X-Received: by 10.28.216.149 with SMTP id p143mr192105wmg.140.1517854844019; Mon, 05 Feb 2018 10:20:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.20.66 with HTTP; Mon, 5 Feb 2018 10:20:43 -0800 (PST) From: Richard Barnes Date: Mon, 5 Feb 2018 10:20:43 -0800 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="001a11468e20cc79f805647b1edb" Archived-At: Subject: [Mls] Draft charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 18:20:47 -0000 --001a11468e20cc79f805647b1edb Content-Type: text/plain; charset="UTF-8" Hey all, In order to establish a working group, we need to have a charter that describes what the WG is supposed to do. Agreeing on the charter will be one of the major things to do at the BoF. To get ready for that, I've put an initial draft (based on the BoF request text) in this Google Doc: https://docs.google.com/document/d/1OrvqnLsnVDQBN1fnlzkfBoS31vyQVk5Zs-a-tz99ku4/edit?usp=sharing Feel free to suggest edits or put comments there, but if there's anything that needs discussion, please reply in this thread instead. Thanks, --Richard --001a11468e20cc79f805647b1edb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

In order to establi= sh a working group, we need to have a charter that describes what the WG is= supposed to do.=C2=A0 Agreeing on the charter will be one of the major thi= ngs to do at the BoF.=C2=A0 To get ready for that, I've put an initial = draft (based on the BoF request text) in this Google Doc:


Feel free to suggest edits or put comments there,= but if there's anything that needs discussion, please reply in this th= read instead.

Thanks,
--Richard

--001a11468e20cc79f805647b1edb-- From nadim@symbolic.software Mon Feb 5 11:19:12 2018 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 D156112D949 for ; Mon, 5 Feb 2018 11:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b=JYIASVIQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fqFtq8uC 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 C_gQXH4-2clh for ; Mon, 5 Feb 2018 11:19:10 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B695A1275AB for ; Mon, 5 Feb 2018 11:19:10 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1798F20D1A; Mon, 5 Feb 2018 14:19:10 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 05 Feb 2018 14:19:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=JcJ1R1 UdRv3jgtoh96LczOmzGE11oFI2chrBNNSX6ag=; b=JYIASVIQdfnxRbV9s/wS0g az8nbnG4caivIS8oZ86F4xKPjA3VV/zb6UiJuSqvoOn77gh7Bzb8NLr72CpmvOeT 4JbhW0Y0HmVDVSyS/1hhawqxyy0nAMp04x8k60XgNGd78UyoqAK6yeJ5B+aZh0FK v7sT0SnQPCAmQPMmcBoUb1WgF3Lv/8itK0OWIl1A8JdMp2s7nBfhhjsa0htdXo/W wfUJwT5FaA5MKdqcEjwVAPZsv+OkNUaLaB0xtm/Qkx9ibAY91WFEZGQH3l9rxvmE 6lRTlolLScXT+8hdGXi1d0w3HTzI7kcw3C3PVNyPJL+QmDwwXZ2+6zI5/JCt9b9g == 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JcJ1R1 UdRv3jgtoh96LczOmzGE11oFI2chrBNNSX6ag=; b=fqFtq8uCfUcFp14USqXm0b 2ujsMZISdlwLsq/2xr7kw3kllX58kz3xI307VgL7tiSDZLvxr/bGK0mZIMITUv6y HLN0fdOjUKB5OWl11WiWXkXY1NvjU4AGH5DdpUd7/ERdEZhcvd5WghOgMu4uPlzJ sETgF8QTcj79YQrZ4c6MwfS+A+zYtg2Ik2VdZGftyfrIzSkzeUk7N3BRCKUfJKQR 0ZFSo35yWcxRdsvgrI3qOJt5+a3x0WzHAxVnSFsMh8m0/S7S6XHe+/ad+ioQEXW0 QH6wGWeu/ooFWb9YhVo0tB1pDBstkgVGNZrT9TWwWJz15wczpCW3HxYbS/NevR3A == X-ME-Sender: Received: from [10.209.6.150] (lfbn-1-478-154.w86-245.abo.wanadoo.fr [86.245.184.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B2D6245F1; Mon, 5 Feb 2018 14:19:09 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Nadim Kobeissi In-Reply-To: Date: Mon, 5 Feb 2018 20:19:08 +0100 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <73F9E545-26B9-4299-B578-3BF1343A07CB@symbolic.software> References: To: Richard Barnes X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Mls] Draft charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 19:19:59 -0000 Dear Richard, Congratulations on getting this list off the ground. I think that TLS 1.3 was a revolution in how a protocol gets discussed, = specified, proven secure and implemented. I think that if we are = diligent and disciplined, we can expand the methodology from which TLS = 1.3 benefited from a single precedent to an entire new institution. It=E2=80=99s possible that the MLS Charter is a good opportunity to make = sure the scope of this effort is reined it early on. One problem I = noticed when first reading though mls-architecture-00 is that, while = federation is specified, it seems to be spoken of quite generally: "3.1.6. Federation The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations should be able to interoperate and to form federated systems.=E2=80=9D Now, to quote the present MLS charter: "It is not a goal of this group to enable interoperability between = messaging applications. That would require alignment at many different = layers beyond security, e.g., standard message transport and application = semantics. The focus of this work is to develop a security layer that = different applications can adapt to their own needs." mls-architecture-00 and the charter and not necessarily in = contradiction, but the problem is that this isn=E2=80=99t entirely = clear. Does a federated environment include the possibility for = interoperable applications? If not, are we then considering that a = single application will have multiple user namespaces which will then = federate? If it=E2=80=99s the latter, then there is an entirely new = level of specification that becomes necessary, too. This is a danger I=E2=80=99d like to get out of the way at some early = point, especially since federation is a topic with a lot of opinions. I = think we need to be very clear, from as early on as possible, what we = mean by federation and interoperability, and how far we are willing to = go with regards to it. It might be wise to rule it out entirely from the = scope of this effort, but my preferred situation would be us being able = to determine some reasonable subset of federation features that is small = and self-contained enough to not grow beyond what this WG is capable of, = but still capable enough to allow MLS to succeed within that dimension = as well. Thank you for this important effort. There are many other important = points that I am very much looking forward to discussing with you all. Regards, Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office > On Feb 5, 2018, at 7:20 PM, Richard Barnes wrote: >=20 > Hey all, >=20 > In order to establish a working group, we need to have a charter that = describes what the WG is supposed to do. Agreeing on the charter will = be one of the major things to do at the BoF. To get ready for that, = I've put an initial draft (based on the BoF request text) in this Google = Doc: >=20 > = https://docs.google.com/document/d/1OrvqnLsnVDQBN1fnlzkfBoS31vyQVk5Zs-a-tz= 99ku4/edit?usp=3Dsharing >=20 > Feel free to suggest edits or put comments there, but if there's = anything that needs discussion, please reply in this thread instead. >=20 > Thanks, > --Richard >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Mon Feb 5 11:36:21 2018 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 189B6127735 for ; Mon, 5 Feb 2018 11:36:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 CoFeCyJN6Xwh for ; Mon, 5 Feb 2018 11:36:17 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 13B781275C5 for ; Mon, 5 Feb 2018 11:36:17 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f71so28317040wmf.0 for ; Mon, 05 Feb 2018 11:36:16 -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=A7zbGXyWwyKWsY3pkEcEKKPJjuVyoIvmLG9gVHzM58M=; b=hrCZgo11bjEAv77WjQ6A+eclS0j76pHUnyz5z53R/CHljfghYhGDD/wf5qVgh1xut/ vjdA339UaPSdajKUyPXdrJgMw0Dhe2j3U4r23hUQCdeFZ30OdeeQIjiX7TprrvswwEWg DC3t03IGeMwRwOxCEy2qyS0rTMYdnOACwt5iggFOszMAEyb+NhywiSOOgLUuK81v/wB4 p4q8emZbCeO3psJj3V3aAzsFU22XJr9qOK25Ju2dDuc1YE9Cdw7vquPsu/rQo6el/KlX g5UsyBTG6DOiSQhZXfS9Zewlnl5UoiOrjW+vCQnGBmtht0V70/fhucrpgo3YvR2SZIeV ikkQ== 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=A7zbGXyWwyKWsY3pkEcEKKPJjuVyoIvmLG9gVHzM58M=; b=KvQq3/Bt/Gd7a3KboIiiEqcbG/HfqFHWnZYZ25vcphDTzu9guuk1EvUoo927sBqTHL jRjrfSPhp762otfa6urJPWmxySRm91EMIlDITAmPh4kpVQ/dHIBUJyF82+jrUjwsyvdk K1zuxBxo8He5KgsfrEJkAFelTy38Uk9xrsocvT+Vpo+DfNWn+69Jv2Dt52OmeKX8tI/q 4JzMOe1X9yzOTnttLg8MhqR33kE0R9JhPYMGncg/2dpsffhjUexYWiTa16RauOo/JPHc 7bA32DZjJz5dGU7CQXKl8Rus1+KbzDV3Gw492xfaVL0Q88Rv771KS7zTCbV6aYzdjzJB BJNA== X-Gm-Message-State: APf1xPABFBK5zbHahisXBJsUBfqHVxDAdzujr9X68jIXpVZaKlKB4Y/3 5mP+vKCas5ci981dgIOJyUPmeeRszUI5Y6unFzZtEDFczIk= X-Google-Smtp-Source: AH8x226wandgCW7uQjFuXYfEUXgnIFMKwxJVtOehhcXIAkaQpOWmPqUKvJjft7L5PyOJ8Go77miIoah7AXY+37bTgmY= X-Received: by 10.28.118.15 with SMTP id r15mr376575wmc.88.1517859375365; Mon, 05 Feb 2018 11:36:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.20.66 with HTTP; Mon, 5 Feb 2018 11:36:14 -0800 (PST) From: Richard Barnes Date: Mon, 5 Feb 2018 11:36:14 -0800 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="089e082f274ce3591605647c2c06" Archived-At: Subject: [Mls] Go implementation; hackathon? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 19:36:19 -0000 --089e082f274ce3591605647c2c06 Content-Type: text/plain; charset="UTF-8" I just made public a repo I've had going with a Go implementation of draft-barnes-mls-protocol. It should illustrate the algorithms underlying what's in the document, with more details about how the tree math works, etc. https://github.com/bifurcation/mls Speaking of implementation -- There's an IETF hackathon on the weekend before the IETF. If anyone else was interested in working together on implementations / testing interoperability, it might be possible to get a table there. https://www6.ietf.org/hackathon/101-hackathon.html --089e082f274ce3591605647c2c06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I just made public a repo I've had going with a G= o implementation=20 of draft-barnes-mls-protocol.=C2=A0 It should illustrate the algorithms=20 underlying what's in the document, with more details about how the tree= =20 math works, etc.


Speaking of implementation -- There's an IETF hackathon on the weekend before= =20 the IETF.=C2=A0 If anyone else was interested in working together on=20 implementations / testing interoperability, it might be possible to get a table there.

https://www6.ietf.org/hack= athon/101-hackathon.html
--089e082f274ce3591605647c2c06-- From nobody Mon Feb 5 12:03:27 2018 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 E793E12D94B for ; Mon, 5 Feb 2018 12:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b=oxdihKTr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k9glWO07 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 n4kLbT8rRwFv for ; Mon, 5 Feb 2018 12:03:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DACE127909 for ; Mon, 5 Feb 2018 12:03:23 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9F07F20AE6 for ; Mon, 5 Feb 2018 15:03:21 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 05 Feb 2018 15:03:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=7KFzWsElfRTlX4yx3zJo8nPbd3/I38wBlFdUIPASb 4k=; b=oxdihKTr6fNL3UxvqeL67D5V9AwmAu7CvGvpfxJp8SVkpiflEkUr4AUBU GlLHEaAqNTTAHc66o9aePSDgbDYZ5ZcYzFmsKcm14vzxRT52HYlLbLg2paPuNhvF fo/fBPBGQQ6udh2LAD3WooM/v3FK0Wn1dPOFT4igpTNrr+bA+0zcPDPBYvGxFWaA IUveI8V5wS6YsZa4nawqh/wP6bx8ZzhLtSLmdhRO7rLEFv40bk+batu6+THgHp3V GWKNRKrAQAOBgjPluUWCbeIJ7a6ICwpDt7LKQLHhzTj5XSpSgJRfAyeL7OuGij1b KHWl/7J/LBVmR5uVgUfaahJeOtfoQ== 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-sender :x-me-sender:x-sasl-enc; s=fm1; bh=7KFzWsElfRTlX4yx3zJo8nPbd3/I3 8wBlFdUIPASb4k=; b=k9glWO07Dz40QsyR+UT1N60AkHeJaCvK5B0da9BsmtCbD aP18DjTkGt+CkJ99izm8MZkQkzbqWSaO3R+IWUrz1y8ErfWU59E2Enhus/c1Eju2 tyP3hzDOtBtFGMK5LzxW9TLbff4cNjTBduw+CpzD1+tcjoNrPRni4/coZA0Cuyt4 g6GAYtALUsLZ45nuXvZuU/C6etG2QJbaNkgSbCV5KmBFergpxGJhJLAbvfPGQGjp QUW4W9XH1K+pTD6V9+YUpO9g3iJMuAuOuhRNP1eJeSLiIFDeC7MMDS1bkdUkGovz tClmFd3i+tNFKxB7+ysouf1rT8POBT27nR0vz96zQ== X-ME-Sender: Received: from [10.209.6.150] (lfbn-1-478-154.w86-245.abo.wanadoo.fr [86.245.184.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 4BF7A2415E for ; Mon, 5 Feb 2018 15:03:21 -0500 (EST) From: Nadim Kobeissi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <0FF1E387-CD8B-4CC6-81EC-0289CC0F7519@symbolic.software> Date: Mon, 5 Feb 2018 21:03:20 +0100 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Mls] Regarding Signatures X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 20:03:26 -0000 Hello everyone, mls-protocol-00 says the following with regards to signing keys = possessed by each participant: "Identity Key: A long-lived signing key pair used to authenticate the sender of a message.=E2=80=9D So far, I=E2=80=99ve been able to identify some missing details with = regards to signatures in this protocol: 1. Cipher Suite Ambiguity: Cipher suites seem to specify only Diffie-Hellman key agreement = functions and hash functions, but not signature functions. A reference = to ECDSA seems to exist under the P-256 cipher suite subsection, but it = appears to be nevertheless decontextualized. More confusingly, the = HandshakeType struct seems to specify an open-ended "SignatureScheme = algorithm=E2=80=9D element. Why does this exist outside the namespacing = afforded by cipher suites, if at all? 2. Mention of Supporting Certificates for Signatures: In Section 6.1, a future possibility for including a certificate for = signatures is mentioned. This seems like a bad idea: do we really want = to introduce X.509 and ASN.1 parsing when we have the opportunity to = finally move away from it? 3. Gratuitous Signature Usage Causes Performance Issues and Conflicts = with Deniability: Signatures seem to be sometimes used gratuitously: A. The clearest instance of this is in 9.2, client-side enforced = ordering, which suggests adding a signed envelope to *every message* = simply in order to obtain client-enforced message ordering by signing a = counter. This seems like overkill. B. To a lesser extent, this is also the case in all five = handshake messages (Init, UserAdd, GroupAdd, Update, Delete), which, = while a more sensible venue for signatures, does raise the question of = whether handshake message authenticity can be maintained in some other = way (chaining keys deriving a chain of authenticity from a signed AKE in = the Init handshake message, which is currently unspecified? we should = definitely think more about this, and I hope we don=E2=80=99t end up = empty-handed.) This is problematic, firstly, due to performance concerns, since = signatures are the slowest primitives. Aside from that, though, the = amount of signatures being employed as part of a regular session = conflicts with an explicit goal of the protocol: mls-architecture-00 = mentions deniability in section 3.2.2.5. Signal Protocol has a wonderful construction where signatures are used = to obtain an AKE. Then an HKDF is used to create a ratchet of chaining = keys which chain the authenticity of the AKE down throughout the rest of = the conversation. In an entire Signal session, only one signing = operation is ever performed by each party. Perhaps something similar = could be adopted here? Signatures have always been the most unwieldy = primitive, and it might be fruitful to consider restricting them as much = as possible within this protocol. Regards, Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office From nobody Tue Feb 6 04:11:32 2018 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 C6482126C83 for ; Tue, 6 Feb 2018 04:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1LCBUgbpcHpI for ; Tue, 6 Feb 2018 04:11:29 -0800 (PST) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (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 EE357126C22 for ; Tue, 6 Feb 2018 04:11:28 -0800 (PST) Received: from [91.183.52.43] (helo=[192.168.1.121]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ej25t-0003D4-Kt for mls@ietf.org; Tue, 06 Feb 2018 13:11:27 +0100 To: mls@ietf.org From: Simon Friedberger Message-ID: Date: Tue, 6 Feb 2018 13:11:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Mls] Comments on Charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 12:11:31 -0000 1. I think key transparency should be mentioned. Key distribution is a huge semi-solved problem and leaving it out is not really an option. It seriously degrades security for the average user who does not validate keys. 2. Federation (for example like in XMPP, where many people run their own servers just like for e-mail) probably doesn't require anything specific but it should be discussed to make sure that it works. It would also be good to take this into account when discussing authentication and key transparency to make sure it is clear which guarantees hold for people on other servers. I think it doesn't necessarily have to be in the charter but should be in any final proposal. Best Regards, Simon From nobody Tue Feb 6 07:08:01 2018 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 C0F4F126E3A for ; Tue, 6 Feb 2018 07:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=t597lvkA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sKxSg5V8 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 EBnYxDylb_oO for ; Tue, 6 Feb 2018 07:07:53 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630A112D7F8 for ; Tue, 6 Feb 2018 07:07:53 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A8CC520D1E for ; Tue, 6 Feb 2018 10:07:50 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 06 Feb 2018 10:07:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=FvSbYjEuLGyzJtOK5UctpArXcv hexU0T4HCNkhFGciM=; b=t597lvkAQXhKIQuYP78X0Wxjuzf7GxNL6mrj0Ux0E1 BwlwKlYFNOCaa/TbeBDyHgwsLEI1OT5vgsU7THh0ViVvdxeGgt9fATnAJcMySsyQ 88fASHaWVH0olTSjDEmQ2oEb1YNIkqNCuXmugRX+5EBPQSLj6ATHv48HMurJCHo7 o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FvSbYj EuLGyzJtOK5UctpArXcvhexU0T4HCNkhFGciM=; b=sKxSg5V8Dk37ZOfugkcQ6f H4XpiSVZYgpIhjSMOiPp/wVYC+vSqm5uJHvru8GXhBiLTmfRfHAyBy4bq1iMqdL0 0FU9gNlvfv0Nm593vOqVQzpwE/rMVWhfcTfh4pBmY6ytoePliHLDg/6oY9uSFLwJ Vu7U01s7qhpXc9cP+gSixU8/mlUB0v9+LxUUj1RffyW7qHf7+DCcfdiQ7GJaLdHZ u9f0v7MTbjy+ZY9u8rrbnlXh8bYgmqCh0W0NPC+8ycVur4ORd0jmV/UemAxwZuSb Bgt3EDty7v4cilhwMrSAAiCIT46PpOkzapGYqg/eWlz5PI0XjJHp5PuzW/aCqf8w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 873994265; Tue, 6 Feb 2018 10:07:50 -0500 (EST) Message-Id: <1517929670.2683689.1261399608.2FAC556E@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fde26eb3 Date: Tue, 06 Feb 2018 15:07:50 +0000 In-Reply-To: <0FF1E387-CD8B-4CC6-81EC-0289CC0F7519@symbolic.software> References: <0FF1E387-CD8B-4CC6-81EC-0289CC0F7519@symbolic.software> Archived-At: Subject: Re: [Mls] Regarding Signatures X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 15:08:00 -0000 Thanks for the comments! On (3), I agree it makes sense to restrict the use= of signatures where it's not otherwise problematic, but note that Signal o= nly avoids them because it is two-party: the Sender Key variant includes an= explicit signature on every message precisely because symmetric keys don't= work for message origin authentication in the n-party case. (Which must me= an that the performance isn't _too_ bad, given WhatsApp uses sender keys.) That is, suppose A, B and C all share a symmetric key and A receives a mess= age authenticated by that key. A can't tell whether B or C sent the message= unless there is something else going on, either a signature or some pairwi= se symmetric key that only A and one other party knows. There may well be a design that increases the level of deniability while no= t impacting other more-important goals (for example, by distributing a sign= ature key in a deniable way), and I would be all in favour of that! best, Katriel On Mon, 5 Feb 2018, at 8:03 PM, Nadim Kobeissi wrote: > Hello everyone, > mls-protocol-00 says the following with regards to signing keys=20 > possessed by each participant: >=20 > "Identity Key: A long-lived signing key pair used to authenticate the > sender of a message.=E2=80=9D >=20 > So far, I=E2=80=99ve been able to identify some missing details with rega= rds to=20 > signatures in this protocol: >=20 > 1. Cipher Suite Ambiguity: > Cipher suites seem to specify only Diffie-Hellman key agreement=20 > functions and hash functions, but not signature functions. A reference=20 > to ECDSA seems to exist under the P-256 cipher suite subsection, but it=20 > appears to be nevertheless decontextualized. More confusingly, the=20 > HandshakeType struct seems to specify an open-ended "SignatureScheme=20 > algorithm=E2=80=9D element. Why does this exist outside the namespacing a= fforded=20 > by cipher suites, if at all? >=20 > 2. Mention of Supporting Certificates for Signatures: > In Section 6.1, a future possibility for including a certificate for=20 > signatures is mentioned. This seems like a bad idea: do we really want=20 > to introduce X.509 and ASN.1 parsing when we have the opportunity to=20 > finally move away from it? >=20 > 3. Gratuitous Signature Usage Causes Performance Issues and Conflicts=20 > with Deniability: > Signatures seem to be sometimes used gratuitously: > A. The clearest instance of this is in 9.2, client-side enforced=20 > ordering, which suggests adding a signed envelope to *every message*=20 > simply in order to obtain client-enforced message ordering by signing a=20 > counter. This seems like overkill. > B. To a lesser extent, this is also the case in all five handshake=20 > messages (Init, UserAdd, GroupAdd, Update, Delete), which, while a more=20 > sensible venue for signatures, does raise the question of whether=20 > handshake message authenticity can be maintained in some other way=20 > (chaining keys deriving a chain of authenticity from a signed AKE in the= =20 > Init handshake message, which is currently unspecified? we should=20 > definitely think more about this, and I hope we don=E2=80=99t end up empt= y- > handed.) >=20 > This is problematic, firstly, due to performance concerns, since=20 > signatures are the slowest primitives. Aside from that, though, the=20 > amount of signatures being employed as part of a regular session=20 > conflicts with an explicit goal of the protocol: mls-architecture-00=20 > mentions deniability in section 3.2.2.5. >=20 > Signal Protocol has a wonderful construction where signatures are used=20 > to obtain an AKE. Then an HKDF is used to create a ratchet of chaining=20 > keys which chain the authenticity of the AKE down throughout the rest of= =20 > the conversation. In an entire Signal session, only one signing=20 > operation is ever performed by each party. Perhaps something similar=20 > could be adopted here? Signatures have always been the most unwieldy=20 > primitive, and it might be fruitful to consider restricting them as much= =20 > as possible within this protocol. >=20 > Regards, >=20 > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > Sent from office >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Feb 6 14:35:50 2018 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 508D212711E; Tue, 6 Feb 2018 14:35: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, lflynn@amsl.com, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151795654828.26000.7941806888780042689.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 14:35:48 -0800 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 101 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 22:35:48 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: TLS, DISPATCH, SECDISPATCH, SAAG, ACME, QUIC, PERC People who must be present: Kathleen Moriarty Ben Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Feb 12 03:01:42 2018 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 D2D4B1275C5 for ; Mon, 12 Feb 2018 03:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=O/kx88mi; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=AsuRnz0U 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 hsUPnmZ95Fj2 for ; Mon, 12 Feb 2018 03:01:38 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 E49151275FD for ; Mon, 12 Feb 2018 03:01:36 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w1CAv8g3030761 for ; Mon, 12 Feb 2018 03:01:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=11vVgUrEzmf76i1ImQ9GUOHm1YuZyM1OkKa4dw/C9bQ=; b=O/kx88mik05xJHCzyMFW++JaVRqQSs7BknPV8gyhbxuWF8UDIUtezWAv2iPZ8TAKLBqV xYA1on2gffkIge/r2RJ2iekrsc7qdxboWqZoobBoq2aovE7y/Hg131DObmqKRNF4PDI3 n9UV30uxC67ph5jvHVkIm0BAGcRBQpukPk0= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0001303.ppops.net with ESMTP id 2g30n88tb9-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Feb 2018 03:01:35 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 12 Feb 2018 06:01:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=11vVgUrEzmf76i1ImQ9GUOHm1YuZyM1OkKa4dw/C9bQ=; b=AsuRnz0Uzu+xn7BnDG+Ere8Xr80vDHVFBQroo5JFHl0ZciaZArZltrCEqFh+lUiqPVZd/hemtd4NURtMVAq7+pdzA+etaRbXrsMSrSqSeFSq9I8KBGjaPiDEZKHft+uMsnZ7fBeP/Hzuq5vPegaKsqSmxbv1Aprp3E5Njm4Qsno= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1255.namprd15.prod.outlook.com (10.172.180.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Mon, 12 Feb 2018 11:01:33 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::3028:3f8c:6eeb:3256]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::3028:3f8c:6eeb:3256%17]) with mapi id 15.20.0485.015; Mon, 12 Feb 2018 11:01:32 +0000 From: Jon Millican To: "mls@ietf.org" Thread-Topic: Removing members from groups Thread-Index: AQHTo/DX/lElM66x7kOt9p+HMOD2bw== Date: Mon, 12 Feb 2018 11:01:32 +0000 Message-ID: <86011555-DAF3-485C-91BB-77884FE6B549@fb.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:200::1:9a9c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1255; 7:BX+0xevmlUtTshx5CEnHOYNJvApuv0RYxIdHXASHeGJ1Pps7xWy6GASA5PY2yGeRpC9D8mubFXXT/J6XiLa6Fj8n5tJfkCmVXuWXe55+nHJK+P6n3Anhl6kSWj8ICFG2Qk5n9zDlwCa3K5yh3UrKW3xAVP9PISLiyRcB61cWkT1c2u1OqrOjvZ+44416ubGgOuQjLU9655YXPcv+mhFFIELKcfrNSGryqENSi+VpcEskfCubmKMATnchU/WocgVs; 20:99nKQrExB7Nxx4DmsU41PfyJNo941YYA/Dig3V327OGTGmjiUV+mwRjLuFCM4JtAZSJjeK+V1MWL9dGNjAVdqL6e37/1ilM9aXiwWVcKDWzRBL5zD9cbFer/BGUe9USYcw5b/44cTg6vbHPStyNzldDWsJ5czGV712bJLKj+3z8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: aac689da-6406-459e-4426-08d57207fa0a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CY4PR15MB1255; x-ms-traffictypediagnostic: CY4PR15MB1255: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(11241501184)(944501161)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR15MB1255; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1255; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(366004)(39380400002)(52314003)(199004)(189003)(53754006)(3660700001)(82746002)(6512007)(68736007)(2501003)(25786009)(54896002)(6306002)(53946003)(478600001)(2900100001)(7736002)(6486002)(6916009)(561944003)(36756003)(5640700003)(33656002)(6436002)(81166006)(6116002)(97736004)(5660300001)(3280700002)(3480700004)(105586002)(106356001)(6506007)(8936002)(8676002)(53936002)(5250100002)(102836004)(99286004)(83716003)(186003)(2351001)(14454004)(59450400001)(2906002)(81156014)(86362001)(316002)(1730700003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1255; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: TOMBl+RfJ3ZNDNumFsXy7oL/wp5oQZlmvCNDIArwF02B3AdRPUGETBNtacXKva6qHN+zMUajfFFFIJQzUI6geQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_86011555DAF3485C91BB77884FE6B549fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aac689da-6406-459e-4426-08d57207fa0a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 11:01:32.7326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1255 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-12_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: [MLS] Removing members from groups X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 11:01:41 -0000 --_000_86011555DAF3485C91BB77884FE6B549fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpCZWZvcmUgd2UgbWFkZSB0aGUgZHJhZnRzIHB1YmxpYywgb3VyIGluZm9y bWFsIGdyb3VwIHNwZW50IGEgbG90IG9mIHRpbWUgZGlzY3Vzc2luZyB0aGUgdmFyaW91cyBhbHRl cm5hdGl2ZXMgZm9yIGhvdyBhIG1lbWJlciBjYW4gYmUgc2FmZWx5IHJlbW92ZWQgKG9yIGRlbGV0 ZWQpIGZyb20gYSBncm91cC4gV2l0aCBldmVyeXRoaW5nIG5vdyBwdWJsaWMsIEkgd2FudGVkIHRv IHByZXNlbnQgdGhlIG1haW4gb3B0aW9ucyB0aGF0IHdlIHdlcmUgdGhpbmtpbmcgYWJvdXQgYXQg dGhlIHRpbWUsIGFuZCBwcmVzZW50IGEgbmV3IHZhcmlhbnQgdGhhdCBJJ3ZlIGJlZW4gdGhpbmtp bmcgYWJvdXQgb3ZlciB0aGUgcGFzdCBmZXcgZGF5cy4NCg0KVGhlIHR3byBtYWluIGNvbnRlbmRl cnMgdGhhdCB3ZSBjb25zaWRlcmVkIHdlcmU6DQoNCjEuIFJlcGxhY2UtdGhlbi1ibGFuay4NCjIu IE1peCBpbiBzZWNyZXQgZnJvbSBwdW5jdHVyZWQgdHJlZS4NCg0KRm9yIGFsbCBvZiB0aGVzZSBl eGFtcGxlcywgSSdsbCB1c2UgdGhpcyBleGFtcGxlIHRyZWUsIG5vdGF0aW5nIGEgbm9kZSBieSB0 aGUgbGlzdCBvZiBtZW1iZXJzIHdobyBrbm93IGl0cyBwcml2YXRlIGtleToNCg0KDQoNCiAgICAg ICAgICAgQUJDREVGR0gNCiAgICAgICAgICAvICAgICAgICBcDQogICAgICAgICAvICAgICAgICAg IFwNCiAgICAgICAgLyAgICAgICAgICAgIFwNCiAgICAgICAvICAgICAgICAgICAgICBcDQogICAg IEFCQ0QgICAgICAgICAgICBFRkdIDQogICAgLyAgICBcICAgICAgICAgIC8gICAgXA0KICAgLyAg ICAgIFwgICAgICAgIC8gICAgICBcDQogIEFCICAgICAgQ0QgICAgICBFRiAgICAgIEdIDQovICBc ICAgIC8gIFwgICAgLyAgXCAgICAvICBcDQpBICAgIEIgIEMgICAgRCAgRSAgICBGICBHICAgIEgN Cg0KDQoNCj09PT09DQpSZXBsYWNlLXRoZW4tYmxhbmsuDQrigJTigJTigJTigJTigJTigJTigJTi gJTigJQNCg0KVGhpcyBpcyBwZXJoYXBzIHRoZSBtb3N0IG5hdHVyYWwgd2F5IHRvIHVzZSBBUlQg Zm9yIGRlbGV0aW9uLiBUaGUgaW50dWl0aW9uIGlzIHRoYXQgeW91IHdhbnQgdG8gc2ltcGx5IHJl bW92ZSB0aGUgZXZpY3RlZSdzIGxlYWYgbm9kZSBmcm9tIHRoZSByYXRjaGV0aW5nIHRyZWU7IGJ1 dCBpZiB5b3UgY2FuJ3QgcGVyZm9ybSB0aGlzIHlvdXJzZWxmLCB5b3UgaW5zdGVhZCBqdXN0IHJl cGxhY2UgdGhlaXIgbGVhZiBrZXkgd2l0aCBvbmUgdGhhdCB0aGV5IGRvbid0IGtub3csIHdoaWNo IHdpbGwgcmVtYWluIHRoZXJlIHVudGlsIHNvbWVib2R5IHdobyBpcyBjYXBhYmxlIHBlcmZvcm1z IHRoZSBhY3R1YWwgcmVtb3ZhbC4NCg0KVGhlIG1lY2hhbmlzbSBmb3IgcmVtb3ZpbmcgRSB3b3Jr cyBhcyBmb2xsb3dzOg0KDQpJZiB0aGUgZGVsZXRlciBpcyBGLCBHIG9yIEgsIHRoZXkgc2ltcGx5 IHNlbmQgYW4gdXBkYXRlIHRvIHRoZSB0cmVlIHRoYXQgbWFya3MgRSBhcyBibGFuay4gVGhlc2Ug dGhyZWUgY2FuIHRyaXZpYWxseSBkbyB0aGlzLCBhcyB0aGV5IGNhbiBwZXJmb3JtIHRoZSBjYWxj dWxhdGlvbiBESChGLCBHSCkuIFRoaXMgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGxvY2tz IG91dCBFLCB3aG8gbm93IGtub3dzIG5vdGhpbmcgYWJvdXQgdGhlIHRyZWUuIE5vYm9keSBlbHNl IGlzIGluIGEgcHJpdmlsZWdlZCBwb3NpdGlvbiBlaXRoZXI7IHNvIHRoaXMgaXMgaWRlYWwuDQoN CiAgICAgICAgICAgQUJDRF9GR0gNCiAgICAgICAgICAvICAgICAgICBcDQogICAgICAgICAvICAg ICAgICAgIFwNCiAgICAgICAgLyAgICAgICAgICAgIFwNCiAgICAgICAvICAgICAgICAgICAgICBc DQogICAgIEFCQ0QgICAgICAgICAgICBfRkdIDQogICAgLyAgICBcICAgICAgICAgIC8gICAgXA0K ICAgLyAgICAgIFwgICAgICAgIC8gICAgICBcDQogIEFCICAgICAgQ0QgICAgICBfRiAgICAgIEdI DQovICBcICAgIC8gIFwgICAgLyAgXCAgICAvICBcDQpBICAgIEIgIEMgICAgRCAgXyAgICBGICBH ICAgIEgNCg0KDQoNCklmIHRoZSBkZWxldGVyIGlzIEEsIEIsIEMgb3IgRDsgdGhleSBjYW5ub3Qg Y29tcHV0ZSBESChGLCBHSCksIHNvIG11c3QgaW5zdGVhZCAqcmVwbGFjZSogRSB3aXRoIGEga2V5 IFggdGhhdCB0aGV5IG11c3QgZ2VuZXJhdGUgYW5kIHRoZW4gaW1tZWRpYXRlbHkgZGVzdHJveS4g VGhpcyBhbGxvd3MgdGhlbSB0byBjb21wdXRlIGFuZCB0cmFuc21pdCBFJ3MgZnVsbCBwYXRoLCBh bmQgdGh1cyB0aGUgdHJlZSBjYW4gY29udGludWUgdG8gYmUgdXNlZCwgYnV0IEUgaXMgYWdhaW4g ZnVsbHkgcmVtb3ZlZCB3aXRoIG5vIGZ1cnRoZXIga25vd2xlZGdlIG9mIHRoZSBjb250ZW50cyBv ZiB0aGUgdHJlZS4NCg0KDQogICAgICAgICAgIEFCQ0RYRkdIDQogICAgICAgICAvICAgICAgICBc DQogICAgICAgICAvICAgICAgICAgIFwNCiAgICAgICAgLyAgICAgICAgICAgIFwNCiAgICAgICAv ICAgICAgICAgICAgICBcDQogICAgIEFCQ0QgICAgICAgICAgICBYRkdIDQogICAgLyAgICBcICAg ICAgICAgIC8gICAgXA0KICAgLyAgICAgIFwgICAgICAgIC8gICAgICBcDQogIEFCICAgICAgQ0Qg ICAgICBYRiAgICAgIEdIDQovICBcICAgIC8gIFwgICAgLyAgXCAgICAvICBcDQpBICAgIEIgIEMg ICAgRCAgWCAgICBGICBHICAgIEgNCg0KDQpUaGUgcHJvYmxlbSBoZXJlIHRob3VnaCBpcyB0aGF0 IHdlIGhhdmUgbm93IHB1dCBBIGluIGEgcHJpdmlsZWdlZCBwb3NpdGlvbiwgaW4gdGhhdCBBIGNv dWxkIGhhdmUgYmVlbiBkaXNob25lc3QgYW5kIGZhaWxlZCB0byBkZWxldGUgWC4gVGhpcyBpc24n dCBuZWNlc3NhcmlseSBhIHByb2JsZW0gaWYgQSBpcyBob25lc3QgdGhlbXNlbGYgLSBvciBpbmRl ZWQgaWYgQSBjb250aW51ZXMgdG8gYmUgaW4gdGhlIHRyZWUgLSBhcyB0aGV5IHRoZXJlZm9yZSBh bHJlYWR5IGhhdmUgYWNjZXNzIHRvIHRoZSB0cmVlJ3MgY29udGVudHM7IGJ1dCB3ZSBkb24ndCB3 YW50IHRoZSBwcm90b2NvbCB0byByZWx5IG9uIGJvdGggb2YgdGhlc2UgYmVpbmcgdHJ1ZS4gSW5k ZWVkLCBpZiBYIHdlcmUgdG8gcmVtYWluIGluIHRoZSB0cmVlIHdpdGhvdXQgZXZlciBiZWluZyBy b3RhdGVkLCB3ZSBjb3VsZCAtIGlmIG5vdGhpbmcgZWxzZSAtIHN1ZmZlciBmcm9tIHdlYWtlbmVk IFBvc3QtQ29tcHJvbWlzZSBTZWN1cml0eS4NCg0KVGhlIGZpcnN0IG1pdGlnYXRpb24gaGVyZSBp cyB0byBsYXppbHkgcGVyZm9ybSB0aGUgYWJvdmUgYmxhbmsgb3BlcmF0aW9uIG5leHQgdGltZSBh IGNhcGFibGUgcGFydHkgKEYsIEcgYW5kIEggaW4gdGhpcyBzaXR1YXRpb24pIHBlcmZvcm1zIHRo ZWlyIG93biB1cGRhdGUuDQoNClRoZSBzZWNvbmQgaXMgdG8gZW5zdXJlIHRoYXQgKmlmIEEgaXMg ZGVsZXRlZCwgYW55IG5vZGVzIHdoaWNoIEEgd2FzIHByaXZpbGVnZWQgb3ZlciBtdXN0IGFsc28g YmUgcmUtcmVwbGFjZWQqLiBTbywgc2F5LCBpZiBCIHdlcmUgdG8gbm93IGRlbGV0ZSBBICh3aGlj aCBCIGNhbiBkbyBkaXJlY3RseSksIHRoZXkgd291bGQgYWxzbyBoYXZlIHRvIGdlbmVyYXRlIGFu IGV2aWN0aW9uIGtleSBZLCB0byBwdXQgaW4gcGxhY2Ugb2YgWCwgdG8gbWFrZSBjZXJ0YWluIHRo YXQgQSBjYW5ub3Qgc3RpbGwgY29tcHV0ZSB0aGUgdHJlZSdzIHJvb3Qga2V5Lg0KDQoNCiAgICAg ICAgICAgX0JDRFlGR0gNCiAgICAgICAgICAvICAgICAgICBcDQogICAgICAgICAvICAgICAgICAg IFwNCiAgICAgICAgLyAgICAgICAgICAgIFwNCiAgICAgICAvICAgICAgICAgICAgICBcDQogICAg IF9CQ0QgICAgICAgICAgICBZRkdIDQogICAgLyAgICBcICAgICAgICAgIC8gICAgXA0KICAgLyAg ICAgIFwgICAgICAgIC8gICAgICBcDQogIF9CICAgICAgQ0QgICAgICBZRiAgICAgIEdIDQovICBc ICAgIC8gIFwgICAgLyAgXCAgICAvICBcDQpfICAgIEIgIEMgICAgRCAgWSAgICBGICBHICAgIEgN Cg0KDQpUaGlzIHdob2xlIHByb2Nlc3MgZW5kcyB1cCByZXF1aXJpbmcgYSBsaXR0bGUgZXh0cmEg Ym9vay1rZWVwaW5nLiBJdCdzIG5vdCB0b28gY29tcGxleCwgYW5kIEkgaGF2ZSBhIGRyYWZ0IGFs Z29yaXRobSBkZXNjcmlwdGlvbiBmb3IgdGhpcywgYnV0IGhhdmluZyB0aGUgYm9vay1rZWVwaW5n IGlzIHNvbWV0aGluZyBvZiBhIGRvd25zaWRlLg0KDQoNCkFkdmFudGFnZXMgb2YgcmVwbGFjZS10 aGVuLWJsYW5rOg0KKiBJdCdzIGEgdmVyeSBuYXR1cmFsIHdheSBvZiB1c2luZyBBUlQuIEVhc3kg dG8gdW5kZXJzdGFuZC4NCiogSXQgc2VlbXMgdG8gcmVhc29uYWJseSBzdHJhaWdodC1mb3J3YXJk bHkgbWFpbnRhaW4gcG9zdC1jb21wcm9taXNlIHNlY3VyaXR5Lg0KDQpEaXNhZHZhbnRhZ2VzOg0K KiBFeHRyYSBib29rLWtlZXBpbmcgc29tZXdoYXQgaW5jcmVhc2VzIHByb3RvY29sIGNvbXBsZXhp dHkuDQoqIFRoZXJlIGFyZSBwb3RlbnRpYWwgZWRnZSBjYXNlcyB3aGljaCBjb3VsZCBpbmNyZWFz ZSBvbmUtb2ZmIGRlbGV0ZSBjb3N0IHRvIE8obikuIEUuZy4gaWYgQSBoYXMgZGVsZXRlZCBvbmUg b2YgZXZlcnkgbGVhZiBwYWlyIGluIGEgbGFyZ2UgdHJlZSwgdGhlbiBzb21lYm9keSBkZWxldGVz IEEgLSB0aGV5IHdpbGwgYWxzbyBoYXZlIHRvIHJlcGxhY2UgZXZlcnkgb25lIG9mIEEncyBzaWJs aW5ncy4gVGhpcyBzaG91bGQgYmUgcmFyZSwgYW5kIEknbSBwcmV0dHkgc3VyZSBhbW9ydGlzZXMg YXdheSBvdmVyIG1hbnkgbWVzc2FnZXMsIGJ1dCB3b3VsZCBzdGlsbCBiZSBhIGJhZCBjYXNlLg0K DQoNCg0KPT09PT0NCk1peCBpbiBzZWNyZXQgZnJvbSBwdW5jdHVyZWQgdHJlZS4NCuKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlA0KDQpUaGlzIGFwcHJvYWNoIHVzZXMgYSBuZWF0IHRyaWNrIHRo YXQgd2UgZmlndXJlZCBvdXQgdG8gZ2V0IGVmZmljaWVudCAobi0xKSBzdWJncm91cHMgb2YgdHJl ZXMuIEZvciBhbiBleGFtcGxlLCBpbiB0aGUgdHJlZSB0aGF0IHdlJ3ZlIGJlZW4gdXNpbmcgLSBp ZiBBIHdpc2hlcyB0byBzZW5kIGEgbWVzc2FnZSB0byBldmVyeWJvZHkgYXBhcnQgZnJvbSBFLCB0 aGV5IGNhbiBlbmNyeXB0IGl0IGVhY2ggb2YgdGhlIHB1YmxpYyBrZXlzIGluIEUncyBjb3BhdGg6 IEFCQ0QsIEYgYW5kIEdILg0KDQoNCiAgICAgICAgICAgQUJDREVGR0gNCiAgICAgICAgICAvICAg ICAgICBcDQogICAgICAgICAvICAgICAgICAgIFwNCiAgICAgICAgLyAgICAgICAgICAgIFwNCiAg ICAgICAvICAgICAgICAgICAgICBcDQogICAgIEFCQ0QqICAgICAgICAgICBFRkdIDQogICAgLyAg ICBcICAgICAgICAgIC8gICAgXA0KICAgLyAgICAgIFwgICAgICAgIC8gICAgICBcDQogIEFCICAg ICAgQ0QgICAgICBFRiAgICAgIEdIKg0KLyAgXCAgICAvICBcICAgIC8gIFwgICAgLyAgXA0KQSAg ICBCICBDICAgIEQgIEUgICAgRiogRyAgICBIDQoNCg0KVGhpcyBvcGVyYXRpb24gaGFzIGxvZ2Fy aXRobWljIGVmZmljaWVuY3ksIGFzIHRoZSBjb3BhdGggaXMgc2l6ZWQgbG9nKG4pLiBUaGUgcHJp bmNpcGxlIGFsc28gZXh0ZW5kcyB0byBhIG1vcmUgZ2VuZXJhbCBjb25jZXB0IG9mICJwdW5jdHVy ZWQgdHJlZXMiOyB3aGVyZWJ5IHlvdSBjYW4gc2VuZCBhIG1lc3NhZ2UgdG8gYW55IHN1YnNldCBv ZiB0aGUgdHJlZSBiYXNlZCBvbiB0aGUgc21hbGxlc3Qgc2V0IG9mIGtleXMgdGhhdCBub25lIG9m IHRoZSBleGNsdWRlZCBtZW1iZXJzIGtub3cuIFRoaXMgZXZlbnR1YWxseSBkZWdyYWRlcyB0byBs aW5lYXIgaW4gdGhlIHdvcnN0IGNhc2UgKGV2ZXJ5IHNlY29uZCBsZWFmIG5vZGUgaGFzIGJlZW4g ZXhjbHVkZWQpLCBidXQgYWdhaW4gdGhpcyBsaWtlbHkgZmVlbHMgbW9yZSBlZGdlLWNhc2V5Lg0K DQoNCkkgYmVsaWV2ZSB0aGUgcHJvcG9zYWwgaGVyZSB3YXM6DQoNCiogS2VlcCB0cmFjayBvZiBh bGwgbm9kZXMgd2hvIGhhdmUgYmVlbiBkZWxldGVkLg0KKiBXaGVuIHlvdSB3aXNoIHRvIGRlbGV0 ZSBhIG5ldyBub2RlLCBnZW5lcmF0ZSBhIHRlbXBvcmFyeSBrZXkgSywgdGhlbiBjb21wdXRlIGEg Y29tcGxldGVseSB1bmJhbGFuY2VkIHRyZWUgd2l0aCBLIGFzIHRoZSBsZWZ0LW1vc3Qgbm9kZSwg YW5kIGVhY2ggbm9kZSB1cCBpdHMgY29wYXRoIGJlaW5nIG9uZSBvZiB0aGUgbm9kZXMgZnJvbSB0 aGUgcHVuY3R1cmVkIHRyZWUuIFRoZSByb290IHNlY3JldCBoZXJlIGlzIHRoZW4gS0RGZCBpbnRv IHRoZSBlcG9jaCBzZWNyZXQ7IG1ha2luZyB0aGUgZXBvY2ggbm93IHVuY29tcHV0YWJsZSB0byBF Lg0KDQoNCiAgICAgICAgICAgICBLQUJDREZHSA0KICAgICAgICAgICAgLyAgICAgICAgXA0KICAg ICAgICAgICAvICAgICAgICAgR0gNCiAgICAgICAgICAvDQogICAgICAgS0FCQ0RGDQogICAgICAv ICAgICAgXA0KICAgICAvICAgICAgICBGDQogICAgLw0KICBLQUJDRA0KLyAgICAgXA0KSyAgICAg QUJDRA0KDQoNCkEgbmljZSBwcm9wZXJ0eSB0byBub3RlIGFib3V0IGRvaW5nIHRoaXMgaXMgdGhh dCB0aGUgc2VydmVyIGlzIGNhcGFibGUgb2YgZ2VuZXJhdGluZyBzdWNoIGEgZGVsZXRlIG1lc3Nh Z2UgLSBhcyBpdCByZWxpZXMgb24gbm8gcHJpdmF0ZSBpbmZvcm1hdGlvbiAtIGFuZCB0aGlzIG1h eSBiZSB1c2VmdWwgaW4gY2VydGFpbiBjaXJjdW1zdGFuY2VzLg0KDQoNCldlIGhhZCBhIGZhaXIg Yml0IG9mIGRpc2N1c3Npb24gYWJvdXQgdGhlIHBvc3QtY29tcHJvbWlzZSBzZWN1cml0eSBwcm9w ZXJ0aWVzIGhlcmUsIHdoaWNoIHdlIHZlcnkgc2NpZW50aWZpY2FsbHkgZGVlbWVkIHRvIGJlICJ3 ZWlyZCBQQ1MiLg0KDQpTcGVjaWZpY2FsbHkgdGhlIGlzc3VlIGhlcmUgaXMgdGhhdCBFIGlzbid0 IG5lY2Vzc2FyaWx5IHJlbW92ZWQgZnJvbSB0aGUgdHJlZSBhdCBhbnkgcG9pbnQuIFRoZXkgY2Fu IHN0aWxsIGNvbXB1dGUgdGhlIHRyZWUgcm9vdCAtIGJ1dCBkb24ndCBrbm93IHRoZSBlcG9jaCBz ZWNyZXQsIGFuZCBzbyBjYW5ub3QgY29tcHV0ZSBhbnkgc3Vic2VxdWVudCBlcG9jaCBzZWNyZXRz IChkdWUgdG8gdGhlaXIgY2hhaW5pbmcpLiBUaGlzIG1lYW5zIHRoYXQgaWYgRSB3ZXJlIHRvIGNv bXByb21pc2Ugc29tZSBvdGhlciB0cmVlIG1lbWJlciwgYW5kIHRoZXJlZm9yZSBsZWFybiB0aGUg ZXBvY2ggc2VjcmV0LCBFIHdvdWxkIGVmZmVjdGl2ZWx5IGhhdmUgcmVpbnNlcnRlZCB0aGVtc2Vs dmVzIGFzIGFuIG9ic2VydmVyIHRvIHRoZSBncm91cCwgYXMgdGhleSBjYW4gY29tcHV0ZSBhbGwg ZnV0dXJlIG9wZXJhdGlvbnMuDQoNClRvIGNsYXJpZnksIHRoZSByZWFzb24gdGhhdCB0aGlzIGlz IHdlaXJkIGlzIHRoYXQgd2UgdGVuZCB0byB0aGluayBvZiBQQ1MgYXMgIlBDUyB3aXRoIHJlc3Bl Y3QgdG8gWCIuIFNvIGlmIHRoZSBwcm90b2NvbCB3ZXJlIHRvIGhhdmUgUENTIHdpdGggcmVzcGVj dCB0byBhbnkgaW5kaXZpZHVhbCBwYXJ0aWNpcGFudCAtIHlvdSB3b3VsZCBleHBlY3QgdGhhdCBh ZnRlciB0aGlzIHBhcnRpY2lwYW50IGhhcyB1cGRhdGVkIHRoZWlyIG93biBsZWFmIGtleSwgYW55 Ym9keSB3aG8gaGFkIHByZXZpb3VzbHkgY29tcHJvbWlzZWQgdGhlbSB3b3VsZCBiZSBsb2NrZWQg b3V0IGFnYWluIChJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBzdHJpY3QgZGVmaW5pdGlvbiwgYnV0 IGl0J3MgY2xvc2UgZW5vdWdoIGFzIGFuIGludHVpdGlvbiBmb3IgYSBzZW5zaWJsZSBtb2RlIG9m IG9wZXJhdGlvbiBmb3IgUENTKS4gSG93ZXZlciwgaW4gdGhpcyBzaXR1YXRpb24sIHdlIGRvbid0 IGhhdmUgUENTIHdpdGggcmVzcGVjdCB0byBhbnlib2R5OyBzbyBsb25nIGFzIHRoZSBhdHRhY2tl ciBrbm93cyB0aGUgbGVhZiBrZXkgZm9yIGEgZGVsZXRlZCBtZW1iZXIuDQoNCk9uZSBwb3RlbnRp YWwgbWl0aWdhdGlvbiBoZXJlIHdvdWxkIGJlIHRvIGZvbGxvdyBhIGRlbGV0ZSB3aXRoIGEgYmxh bmsgb3BlcmF0aW9uIC0gYXMgaW4gcmVwbGFjZS10aGVuLWJsYW5rLiBPdGhlcndpc2Ugd2hhdCB3 ZSBzZWVtIHRvIHByb2JhYmx5IGhhdmUgaXMgYSBwcm90b2NvbCB3aXRoIGZvcndhcmQgc2VjcmVj eSwgYW5kICJ3ZWlyZCBQQ1MiLg0KDQpBZHZhbnRhZ2VzIG9mIHRoaXMgYXBwcm9hY2ggd2l0aCB0 aGUgbWl0aWdhdGlvbiBpbiBwbGFjZToNCiogTXVjaCBsZXNzIGJvb2sta2VlcGluZyByZXF1aXJl ZDogd2UgbmV2ZXIgcHV0IGFueWJvZHkgaW4gYSBwcml2aWxlZ2VkIHBvc2l0aW9uLg0KKiBEZWxl dGUgY2FuIGJlIHBlcmZvcm1lZCBieSBub24tZ3JvdXAtbWVtYmVycy4NCg0KRGlzYWR2YW50YWdl czoNCiogV2VpcmQgLSBvciBhdCB3b3JzdCB3ZWFrZXIgLSBwb3N0LWNvbXByb21pc2Ugc2VjdXJp dHkuDQoqIEFmdGVyIG1hbnkgZGVsZXRpb25zLCBkZWxldGlvbiB0aW1lIGNvbXBsZXhpdHkgbWF5 IGRlZ3JhZGUgdG8gbGluZWFyLg0KDQoNCg0KDQoNCg0KT2YgdGhlc2UgYXBwcm9hY2hlcywgd2Ug d2VudCB3aXRoIHJlcGxhY2UtdGhlbi1ibGFuayBmb3IgdGhlIGluaXRpYWwgZHJhZnQgZHVlIHRv IGl0cyBiZXR0ZXIgKG9yLCBhdCBsZWFzdCwgbW9yZSBvYnZpb3VzKSBQQ1MgcHJvcGVydGllcy4N Cg0KDQoNCg0KDQoNCk92ZXIgdGhlIHBhc3QgZmV3IGRheXMgSSB0aG91Z2h0IG9mIGEgbmV3IGFw cHJvYWNoIGJhc2VkIG9uIHB1bmN0dXJlZCB0cmVlcywgdGhhdCBJIGJlbGlldmUgbWF5IHRvbGVy YXRlIGxlc3MgYm9vay1rZWVwaW5nIHRoZW4gcmVwbGFjZS10aGFuLWJsYW5rIHdpdGggYmV0dGVy IFBDUyB3aXRoIHB1bmN0dXJlZCB0cmVlIG1peGlucy4gSSdtIG5vdCBmdWxseSBzdXJlIG9mIGl0 cyBtZXJpdHMgb3IgZGlzYWR2YW50YWdlcywgc28gSSdkIHJlYWxseSBhcHByZWNpYXRlIGZlZWRi YWNrIG9uIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UuDQoNCg0KDQoNCj09PT09DQpFdmljdGlvbi1w YXRoIHB1YmxpYyBrZXkgbXV0YXRpb25zLg0K4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUDQoN ClRoZSBwcm9ibGVtIHdpdGggcmVwbGFjaW5nIGEgbm9uLShzaWJsaW5nIG9yIGNvdXNpbikgbm9k ZSBpcyB0aGF0IHlvdSBjYW5ub3QgY29tcHV0ZSB0aGUgdmFsdWUgb2YgYSBwYXJlbnQgbm9kZSB3 aXRob3V0IGtub3dpbmcgdGhlIHNlY3JldCB2YWx1ZSBhdCBvbmUgb2YgaXRzIGNoaWxkIG5vZGVz LiBUaGUgYWJvdmUgZGVsZXRpb24gYXBwcm9hY2hlcyBhcmUgdGhlcmVmb3JlIGJhc2VkIG9uIHRo ZSBpZGVhIHRoYXQgeW91IGNhbm5vdCBjaGFuZ2UgdGhlIHByaXZhdGUgdmFsdWVzIGluIGFub3Ro ZXIgYnJhbmNoIG9mIHRoZSB0cmVlIHdpdGhvdXQgaW5zZXJ0aW5nIHlvdXJzZWxmIGludG8gYSBw cml2aWxlZ2VkIHBvc2l0aW9uLiBUaGlzIGFzc3VtcHRpb24sIGhvd2V2ZXIsICptYXkqIG5vdCBi ZSBlbnRpcmVseSBjb3JyZWN0Lg0KDQpXaGF0IHdlIG5lZWQgaGVyZSBpcyB0aGUgYWJpbGl0eSB0 byBtdXRhdGUgc29tZWJvZHkgZWxzZSdzIHB1YmxpYyBrZXkgdG8gc29tZXRoaW5nIGZvciB3aGlj aCB0aGV5IC0gYW5kIG9ubHkgdGhleSAtIGNhbiBjb21wdXRlIHRoZSBwcml2YXRlIGtleS4gRm9y dHVuYXRlbHksIEkgYmVsaWV2ZSB0aGF0IERpZmZpZS1IZWxsbWFuIGl0c2VsZiBkaXJlY3RseSBw cm92aWRlcyB0aGlzLg0KDQpGb3IgREggcHJpdmF0ZSBrZXkgeCwgdGhlIHB1YmxpYyBrZXkgaXMg Z154LiBJZiB3ZSB0YWtlIGEgZGlmZmVyZW50IHByaXZhdGUga2V5IGssIHdlIGNhbiBwZXJmb3Jt IHRoZSBESCBvcGVyYXRpb24gb24gaXQgdG8gZ2V0IGdeKHhrKS4gU28gZmFyLCB0aGlzIGlzIHN0 YW5kYXJkIERIIC0gd2l0aCBnXih4aykgdHlwaWNhbGx5IGJlaW5nIHVzZWQgYXMgYSBzaGFyZWQg c2VjcmV0LiBXZSBjb3VsZCwgaG93ZXZlciwgaW5zdGVhZCB0cmVhdCB4ayBhcyB0aGUgbmV3IHBy aXZhdGUga2V5LCBhbmQgZ14oeGspIGFzIGl0cyBwdWJsaWMga2V5LiBUaGlzIHRoZW4gbWVhbnMg dGhhdCBpZiB5b3UgY2FuIHNlY3VyZWx5IHRyYW5zbWl0IGsgdG8gZXZlcnlib2R5OiB0aGV5IGNh biBhbGwgY29tcHV0ZSBnXih4ayk7IGJ1dCBvbmx5IHRoZSBvcmlnaW5hbCBwcml2YXRlIGtleSBv d25lciBhY3R1YWxseSBrbm93cyB0aGUgcHJpdmF0ZSBrZXkgeGsgLSBieSB0aGUgZGlzY3JldGUg bG9nYXJpdGhtIHByb2JsZW0uIE5PVEU6IEkgRE8gTk9UIEtOT1cgSUYgTVkgUkVBU09OSU5HIEhF UkUgSVMgUVVJVEUgQ09SUkVDVC4gVGhpcyBkZWZpbml0ZWx5IHJlcXVpcmVzIGlucHV0IGZyb20g cmVhbCBjcnlwdG9ncmFwaGVycy4NCg0KU28sIGxldCdzIGNvbWJpbmUgdGhpcyBtdXRhdGlvbiB3 aXRoIHB1bmN0dXJlZCB0cmVlcy4gTm93LCB3aGVuIEEgd2FudHMgdG8gZGVsZXRlIEUsIHRoZXkg Y29tcHV0ZSBhIG5ldyBzZWNyZXQgaywgYW5kIHRyYW5zbWl0IGl0IHRvIHRoZSBwdW5jdHVyZWQg dHJlZSBleGNsdWRpbmcgRSAtIGVuc3VyaW5nIHRoYXQgZXZlcnlib2R5IGFwYXJ0IGZyb20gRSBr bm93cyBpdC4gRXZlcnlib2R5IGFwcGxpZXMgdGhlIG11dGF0aW9uIHRvIGV2ZXJ5IG5vZGUgaW4g RSdzIHBhdGgsIGFuZCBpbW1lZGlhdGVseSBkZWxldGVzIGssIHJlc3VsdGluZyBpbiB0aGUgdHJl ZToNCg0KDQogICAgICAgICAgKEFCQ0RFRkdIKWsNCiAgICAgICAgICAvICAgICAgICBcDQogICAg ICAgICAvICAgICAgICAgIFwNCiAgICAgICAgLyAgICAgICAgICAgIFwNCiAgICAgICAvICAgICAg ICAgICAgICBcDQogICAgIEFCQ0QgICAgICAgICAgIChFRkdIKWsNCiAgICAvICAgIFwgICAgICAg ICAgLyAgICBcDQogICAvICAgICAgXCAgICAgICAgLyAgICAgIFwNCiAgQUIgICAgICBDRCAgICAg KEVGKWsgICAgR0gNCi8gIFwgICAgLyAgXCAgICAvICBcICAgIC8gIFwNCkEgICAgQiAgQyAgICBE ICBFayAgIEYgIEcgICAgSA0KDQoNCihIZXJlIHdlIGFyZSBhY3R1YWxseSBicmVha2luZyBhbiBp bnZhcmlhbnQgdGhhdCB1c2VkIHRvIGhvbGQgZnJvbSBBUlQ6IHNwZWNpZmljYWxseSB0aGF0IGEg cGFyZW50IGlzIGRpcmVjdGx5IGNhbGN1bGF0ZWQgYXMgS0RGKERIKGNoaWxkcmVuKSkuIFRoaXMg d2lsbCBtZWFuIHRoYXQgbm9kZXMgbmVlZCB0byBjYWNoZSB0aGVpciBlbnRpcmUgcGF0aCwgYXMg dGhleSBjYW4ndCBkaXJlY3RseSBkZXJpdmUgdGhlbSwgYnV0IHRoaXMgZmVlbHMgZmluZSBpbiBw cmFjdGljZTogaXQncyBvbmx5IGxvZ2FyaXRobWljIGluIHNpemUgYW55d2F5LCBhbmQgd2UgbGlr ZWx5IHdvdWxkIHdhbnQgdG8gY2FjaGUgaXQgaW4gcmVhbC13b3JsZCB1c2FnZSB0byBhdm9pZCBl eHRyYSByZWNhbGN1bGF0aW9ucy4pDQoNClRoaXMgaGFzIHRoZSBuaWNlIHByb3BlcnR5IHRoYXQg RSBubyBsb25nZXIga25vd3MgYW55IHByaXZhdGUga2V5IGluIHRoZSB0cmVlOyBpbmNsdWRpbmcg dGhlaXIgb3duLiBUaGlzIGNvdWxkIHBvdGVudGlhbGx5IGFsbG93IHVzIHRvIG5ldmVyIGV2ZW4g Ym90aGVyIHRvIGJsYW5rIGl0IG91dCwgYnV0IHVuZm9ydHVuYXRlbHkgd2Ugc3RpbGwgaGF2ZSBh IHNsaWdodGx5IHdlaXJkIFBDUyBwcm9wZXJ0eTogaWYgRSBoYWQgY29tcHJvbWlzZWQgYW55Ym9k eSBzaG9ydGx5ICpiZWZvcmUqIGJlaW5nIGRlbGV0ZWQgZnJvbSB0aGUgdHJlZSB0aGV5IGNvdWxk IGxlYXJuIGsgd2hlbiBpdCBpcyB0cmFuc21pdHRlZCwgYW5kIHRodXMgcGVybWFuZW50bHkgcmVp bnNlcnQgdGhlbXNlbGYgaW50byB0aGUgdHJlZS4gSXQncyBhIG11Y2ggc21hbGxlciBjb21wcm9t aXNlIHdpbmRvdyB0aGFuIGluIHRoZSBwcmV2aW91cyBzb2x1dGlvbiAtIHdoaWNoIGlzIGFueSB0 aW1lIGluIHRoZSBmdXR1cmUgLSBidXQgaXQncyBlbm91Z2ggdGhhdCB3ZSB3b3VsZCBwcm9iYWJs eSBzdGlsbCB3YW50IHRvIGluY2x1ZGUgYmxhbmtpbmcgd2hlbiB0aGUgc2libGluZyBvciBjb3Vz aW4gbmV4dCB1cGRhdGVzLiBXZSBjb3VsZCBhbHNvIHBlcmlvZGljYWxseSBzZW5kIGEgbmV3IGsg dW50aWwgdGhlIG5vZGUgaGFzIGJlZW4gYmxhbmtlZCB0byBpbXByb3ZlIHRoZSBtaXRpZ2F0aW9u ICh3aGljaCwgaW5kZWVkLCB3ZSBjb3VsZCBhbHNvIGRvIGluIHRoZSBhYm92ZSBzb2x1dGlvbiku DQoNCg0KQWR2YW50YWdlcyBvZiB0aGlzIGFwcHJvYWNoOg0KKiBTYW1lIG1pbmltYWwgYm9vay1r ZWVwaW5nIHJlcXVpcmVtZW50cyBhcyBpbiAiTWl4IGluIHNlY3JldCBmcm9tIHB1bmN0dXJlZCB0 cmVlIi4NCiogRGVsZXRlcyBjYW4sIGFnYWluLCBiZSBwZXJmb3JtZWQgYnkgbm9uLWdyb3VwIG1l bWJlcnMuDQoqIERlbGV0ZXMgY291bGQgYWx3YXlzIGJlIGxvZ2FyaXRobWljICh3aXRob3V0IHBl cmlvZGljIHJlLWtleWluZykuDQoqIFNtYWxsIHByZS1lbXB0aXZlIGNvbXByb21pc2Ugd2luZG93 IGZvciBldmljdGVlcyB0byBiZSBhYmxlIHRvIHdlYWtlbiBQQ1MgKHdpdGhvdXQgcGVyaW9kaWMg cmUta2V5aW5nKS4NCg0KRGlzYWR2YW50YWdlczoNCiogU3RpbGwgd2Vha2VyIFBDUyB0aGFuIHJl cGxhY2UtdGhlbi1ibGFuay4NCiogV2VpcmQgdXNhZ2Ugb2YgREggd2hpY2ggSSdtIG5vdCBjb25m aWRlbnQgdG8gYXNzZXJ0IGlzIHNhZmUuDQoNCg0KDQoNCg0KU28sIHRoZXNlIGFyZSB0aGUgb3B0 aW9uczsgcGxlYXNlIGxldCBtZSBrbm93IGlmIGFueSBvZiBpdCBpc24ndCBjbGVhci4gSSdkIGxv dmUgdG8gZ2F0aGVyIHBlb3BsZSdzIHRob3VnaHRzLCBhbmQgYW55IGFsdGVybmF0aXZlIGFwcHJv YWNoZXMgeW91IGNhbiB0aGluayBvZiAtIHBhcnRpY3VsYXJseSBhcyBldmVyeXRoaW5nIHdlJ3Zl IHRob3VnaHQgb2Ygc28gZmFyIGludm9sdmVzIGNlcnRhaW4gY29tcHJvbWlzZXMhDQoNCg0KVGhh bmtzIQ0KSm9uDQo= --_000_86011555DAF3485C91BB77884FE6B549fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <94B3C759A3DD4A4192A84B80ACE366DC@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K c3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t R0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+SGVsbG8gYWxsLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+QmVmb3JlIHdlIG1hZGUgdGhlIGRyYWZ0cyBwdWJsaWMsIG91ciBpbmZvcm1h bCBncm91cCBzcGVudCBhIGxvdCBvZiB0aW1lIGRpc2N1c3NpbmcgdGhlIHZhcmlvdXMgYWx0ZXJu YXRpdmVzIGZvciBob3cgYSBtZW1iZXIgY2FuIGJlIHNhZmVseSByZW1vdmVkIChvciBkZWxldGVk KSBmcm9tIGEgZ3JvdXAuDQogV2l0aCBldmVyeXRoaW5nIG5vdyBwdWJsaWMsIEkgd2FudGVkIHRv IHByZXNlbnQgdGhlIG1haW4gb3B0aW9ucyB0aGF0IHdlIHdlcmUgdGhpbmtpbmcgYWJvdXQgYXQg dGhlIHRpbWUsIGFuZCBwcmVzZW50IGEgbmV3IHZhcmlhbnQgdGhhdCBJJ3ZlIGJlZW4gdGhpbmtp bmcgYWJvdXQgb3ZlciB0aGUgcGFzdCBmZXcgZGF5cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPlRoZSB0d28gbWFp biBjb250ZW5kZXJzIHRoYXQgd2UgY29uc2lkZXJlZCB3ZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+MS4gUmVw bGFjZS10aGVuLWJsYW5rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4yLiBNaXggaW4gc2VjcmV0IGZyb20gcHVuY3R1cmVkIHRyZWUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj5Gb3IgYWxsIG9mIHRoZXNlIGV4YW1wbGVzLCBJJ2xsIHVzZSB0aGlzIGV4 YW1wbGUgdHJlZSwgbm90YXRpbmcgYSBub2RlIGJ5IHRoZSBsaXN0IG9mIG1lbWJlcnMgd2hvIGtu b3cgaXRzIHByaXZhdGUga2V5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QUJDREVGR0g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUJDRCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFRkdIPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyBc PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiZuYnNwOyBBQiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBD RCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFRiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBHSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj4vJm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyBcJm5ic3A7 Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IFw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+QSZu YnNwOyZuYnNwOyZuYnNwOyBCJm5ic3A7IEMmbmJzcDsmbmJzcDsmbmJzcDsgRCZuYnNwOyBFJm5i c3A7Jm5ic3A7Jm5ic3A7IEYmbmJzcDsgRyZuYnNwOyZuYnNwOyZuYnNwOyBIPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPj09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPlJlcGxhY2UtdGhlbi1ibGFuay48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5UaGlzIGlzIHBlcmhhcHMgdGhl IG1vc3QgbmF0dXJhbCB3YXkgdG8gdXNlIEFSVCBmb3IgZGVsZXRpb24uIFRoZSBpbnR1aXRpb24g aXMgdGhhdCB5b3Ugd2FudCB0byBzaW1wbHkgcmVtb3ZlIHRoZSBldmljdGVlJ3MgbGVhZiBub2Rl IGZyb20gdGhlIHJhdGNoZXRpbmcgdHJlZTsgYnV0IGlmIHlvdSBjYW4ndA0KIHBlcmZvcm0gdGhp cyB5b3Vyc2VsZiwgeW91IGluc3RlYWQganVzdCByZXBsYWNlIHRoZWlyIGxlYWYga2V5IHdpdGgg b25lIHRoYXQgdGhleSBkb24ndCBrbm93LCB3aGljaCB3aWxsIHJlbWFpbiB0aGVyZSB1bnRpbCBz b21lYm9keSB3aG8gaXMgY2FwYWJsZSBwZXJmb3JtcyB0aGUgYWN0dWFsIHJlbW92YWwuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj5UaGUgbWVjaGFuaXNtIGZvciByZW1vdmluZyBFIHdvcmtzIGFzIGZvbGxvd3M6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj5JZiB0aGUgZGVsZXRlciBpcyBGLCBHIG9yIEgsIHRoZXkgc2ltcGx5IHNlbmQg YW4gdXBkYXRlIHRvIHRoZSB0cmVlIHRoYXQgbWFya3MgRSBhcyBibGFuay4gVGhlc2UgdGhyZWUg Y2FuIHRyaXZpYWxseSBkbyB0aGlzLCBhcyB0aGV5IGNhbiBwZXJmb3JtIHRoZSBjYWxjdWxhdGlv biBESChGLCBHSCkuDQogVGhpcyBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgbG9ja3Mgb3V0 IEUsIHdobyBub3cga25vd3Mgbm90aGluZyBhYm91dCB0aGUgdHJlZS4gTm9ib2R5IGVsc2UgaXMg aW4gYSBwcml2aWxlZ2VkIHBvc2l0aW9uIGVpdGhlcjsgc28gdGhpcyBpcyBpZGVhbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBQkNEX0ZHSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBQkNEJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IF9GR0g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5i c3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgXCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7IEFCJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IENEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9GJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdIPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPi8mbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5i c3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJz cDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj5BJm5ic3A7Jm5ic3A7Jm5ic3A7IEImbmJzcDsgQyZuYnNwOyZuYnNwOyZuYnNwOyBE Jm5ic3A7IF8mbmJzcDsmbmJzcDsmbmJzcDsgRiZuYnNwOyBHJm5ic3A7Jm5ic3A7Jm5ic3A7IEg8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+SWYgdGhlIGRlbGV0ZXIgaXMgQSwgQiwg QyBvciBEOyB0aGV5IGNhbm5vdCBjb21wdXRlIERIKEYsIEdIKSwgc28gbXVzdCBpbnN0ZWFkICpy ZXBsYWNlKiBFIHdpdGggYSBrZXkgWCB0aGF0IHRoZXkgbXVzdCBnZW5lcmF0ZSBhbmQgdGhlbiBp bW1lZGlhdGVseSBkZXN0cm95LiBUaGlzIGFsbG93cyB0aGVtDQogdG8gY29tcHV0ZSBhbmQgdHJh bnNtaXQgRSdzIGZ1bGwgcGF0aCwgYW5kIHRodXMgdGhlIHRyZWUgY2FuIGNvbnRpbnVlIHRvIGJl IHVzZWQsIGJ1dCBFIGlzIGFnYWluIGZ1bGx5IHJlbW92ZWQgd2l0aCBubyBmdXJ0aGVyIGtub3ds ZWRnZSBvZiB0aGUgY29udGVudHMgb2YgdGhlIHRyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEFCQ0RYRkdIPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOy8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg XDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUJDRCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBYRkdIPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNw OyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWYiPiZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyBBQiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBDRCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBYRiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBHSDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmIj4vJm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyBcJm5i c3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IFw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ QSZuYnNwOyZuYnNwOyZuYnNwOyBCJm5ic3A7IEMmbmJzcDsmbmJzcDsmbmJzcDsgRCZuYnNwOyBY Jm5ic3A7Jm5ic3A7Jm5ic3A7IEYmbmJzcDsgRyZuYnNwOyAmbmJzcDsmbmJzcDtIPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+VGhlIHByb2JsZW0gaGVyZSB0aG91Z2ggaXMgdGhhdCB3ZSBoYXZlIG5v dyBwdXQgQSBpbiBhIHByaXZpbGVnZWQgcG9zaXRpb24sIGluIHRoYXQgQSBjb3VsZCBoYXZlIGJl ZW4gZGlzaG9uZXN0IGFuZCBmYWlsZWQgdG8gZGVsZXRlIFguIFRoaXMgaXNuJ3QgbmVjZXNzYXJp bHkgYSBwcm9ibGVtIGlmIEENCiBpcyBob25lc3QgdGhlbXNlbGYgLSBvciBpbmRlZWQgaWYgQSBj b250aW51ZXMgdG8gYmUgaW4gdGhlIHRyZWUgLSBhcyB0aGV5IHRoZXJlZm9yZSBhbHJlYWR5IGhh dmUgYWNjZXNzIHRvIHRoZSB0cmVlJ3MgY29udGVudHM7IGJ1dCB3ZSBkb24ndCB3YW50IHRoZSBw cm90b2NvbCB0byByZWx5IG9uIGJvdGggb2YgdGhlc2UgYmVpbmcgdHJ1ZS4gSW5kZWVkLCBpZiBY IHdlcmUgdG8gcmVtYWluIGluIHRoZSB0cmVlIHdpdGhvdXQgZXZlciBiZWluZyByb3RhdGVkLA0K IHdlIGNvdWxkIC0gaWYgbm90aGluZyBlbHNlIC0gc3VmZmVyIGZyb20gd2Vha2VuZWQgUG9zdC1D b21wcm9taXNlIFNlY3VyaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+VGhlIGZpcnN0IG1pdGlnYXRpb24gaGVy ZSBpcyB0byBsYXppbHkgcGVyZm9ybSB0aGUgYWJvdmUgYmxhbmsgb3BlcmF0aW9uIG5leHQgdGlt ZSBhIGNhcGFibGUgcGFydHkgKEYsIEcgYW5kIEggaW4gdGhpcyBzaXR1YXRpb24pIHBlcmZvcm1z IHRoZWlyIG93biB1cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5UaGUgc2Vjb25kIGlzIHRvIGVuc3VyZSB0 aGF0ICppZiBBIGlzIGRlbGV0ZWQsIGFueSBub2RlcyB3aGljaCBBIHdhcyBwcml2aWxlZ2VkIG92 ZXIgbXVzdCBhbHNvIGJlIHJlLXJlcGxhY2VkKi4gU28sIHNheSwgaWYgQiB3ZXJlIHRvIG5vdyBk ZWxldGUgQSAod2hpY2ggQiBjYW4gZG8gZGlyZWN0bHkpLA0KIHRoZXkgd291bGQgYWxzbyBoYXZl IHRvIGdlbmVyYXRlIGFuIGV2aWN0aW9uIGtleSBZLCB0byBwdXQgaW4gcGxhY2Ugb2YgWCwgdG8g bWFrZSBjZXJ0YWluIHRoYXQgQSBjYW5ub3Qgc3RpbGwgY29tcHV0ZSB0aGUgdHJlZSdzIHJvb3Qg a2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfQkNEWUZHSDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBfQkNEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlGR0g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsm bmJzcDsmbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IC8mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7IF9C Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFlGJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdIPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPi8mbmJzcDsgXCZu YnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyBcJm5i c3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5fJm5ic3A7Jm5ic3A7Jm5ic3A7IEImbmJzcDsg QyZuYnNwOyZuYnNwOyZuYnNwOyBEJm5ic3A7IFkmbmJzcDsmbmJzcDsmbmJzcDsgRiZuYnNwOyBH Jm5ic3A7Jm5ic3A7Jm5ic3A7IEg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5UaGlzIHdob2xlIHBy b2Nlc3MgZW5kcyB1cCByZXF1aXJpbmcgYSBsaXR0bGUgZXh0cmEgYm9vay1rZWVwaW5nLiBJdCdz IG5vdCB0b28gY29tcGxleCwgYW5kIEkgaGF2ZSBhIGRyYWZ0IGFsZ29yaXRobSBkZXNjcmlwdGlv biBmb3IgdGhpcywgYnV0IGhhdmluZyB0aGUgYm9vay1rZWVwaW5nIGlzIHNvbWV0aGluZw0KIG9m IGEgZG93bnNpZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+QWR2YW50YWdlcyBvZiByZXBsYWNl LXRoZW4tYmxhbms6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPiogSXQncyBhIHZlcnkgbmF0dXJhbCB3YXkgb2YgdXNpbmcgQVJULiBF YXN5IHRvIHVuZGVyc3RhbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPiogSXQgc2VlbXMgdG8gcmVhc29uYWJseSBzdHJhaWdodC1m b3J3YXJkbHkgbWFpbnRhaW4gcG9zdC1jb21wcm9taXNlIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ RGlzYWR2YW50YWdlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZiI+KiBFeHRyYSBib29rLWtlZXBpbmcgc29tZXdoYXQgaW5jcmVhc2Vz IHByb3RvY29sIGNvbXBsZXhpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiogVGhlcmUgYXJlIHBvdGVudGlhbCBlZGdlIGNhc2Vz IHdoaWNoIGNvdWxkIGluY3JlYXNlIG9uZS1vZmYgZGVsZXRlIGNvc3QgdG8gTyhuKS4gRS5nLiBp ZiBBIGhhcyBkZWxldGVkIG9uZSBvZiBldmVyeSBsZWFmIHBhaXIgaW4gYSBsYXJnZSB0cmVlLCB0 aGVuIHNvbWVib2R5IGRlbGV0ZXMgQSAtIHRoZXkNCiB3aWxsIGFsc28gaGF2ZSB0byByZXBsYWNl IGV2ZXJ5IG9uZSBvZiBBJ3Mgc2libGluZ3MuIFRoaXMgc2hvdWxkIGJlIHJhcmUsIGFuZCBJJ20g cHJldHR5IHN1cmUgYW1vcnRpc2VzIGF3YXkgb3ZlciBtYW55IG1lc3NhZ2VzLCBidXQgd291bGQg c3RpbGwgYmUgYSBiYWQgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PT09 PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZiI+TWl4IGluIHNlY3JldCBmcm9tIHB1bmN0dXJlZCB0cmVlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj7igJTigJTigJTigJTi gJTigJTigJTigJTigJQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPlRoaXMgYXBwcm9hY2ggdXNlcyBhIG5lYXQgdHJp Y2sgdGhhdCB3ZSBmaWd1cmVkIG91dCB0byBnZXQgZWZmaWNpZW50IChuLTEpIHN1Ymdyb3VwcyBv ZiB0cmVlcy4gRm9yIGFuIGV4YW1wbGUsIGluIHRoZSB0cmVlIHRoYXQgd2UndmUgYmVlbiB1c2lu ZyAtIGlmIEEgd2lzaGVzIHRvIHNlbmQgYSBtZXNzYWdlDQogdG8gZXZlcnlib2R5IGFwYXJ0IGZy b20gRSwgdGhleSBjYW4gZW5jcnlwdCBpdCBlYWNoIG9mIHRoZSBwdWJsaWMga2V5cyBpbiBFJ3Mg Y29wYXRoOiBBQkNELCBGIGFuZCBHSC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUJDREVG R0g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUJDRCombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRUZHSDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsm bmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg XDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj4mbmJzcDsgQUImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0QmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRUYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR0gq PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPi8mbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJz cDsgLyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5BJm5ic3A7Jm5ic3A7 Jm5ic3A7IEImbmJzcDsgQyZuYnNwOyZuYnNwOyZuYnNwOyBEJm5ic3A7IEUmbmJzcDsmbmJzcDsm bmJzcDsgRiogRyZuYnNwOyZuYnNwOyZuYnNwOyBIPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+VGhp cyBvcGVyYXRpb24gaGFzIGxvZ2FyaXRobWljIGVmZmljaWVuY3ksIGFzIHRoZSBjb3BhdGggaXMg c2l6ZWQgbG9nKG4pLiBUaGUgcHJpbmNpcGxlIGFsc28gZXh0ZW5kcyB0byBhIG1vcmUgZ2VuZXJh bCBjb25jZXB0IG9mICZxdW90O3B1bmN0dXJlZCB0cmVlcyZxdW90Ozsgd2hlcmVieSB5b3UgY2Fu IHNlbmQgYSBtZXNzYWdlDQogdG8gYW55IHN1YnNldCBvZiB0aGUgdHJlZSBiYXNlZCBvbiB0aGUg c21hbGxlc3Qgc2V0IG9mIGtleXMgdGhhdCBub25lIG9mIHRoZSBleGNsdWRlZCBtZW1iZXJzIGtu b3cuIFRoaXMgZXZlbnR1YWxseSBkZWdyYWRlcyB0byBsaW5lYXIgaW4gdGhlIHdvcnN0IGNhc2Ug KGV2ZXJ5IHNlY29uZCBsZWFmIG5vZGUgaGFzIGJlZW4gZXhjbHVkZWQpLCBidXQgYWdhaW4gdGhp cyBsaWtlbHkgZmVlbHMgbW9yZSBlZGdlLWNhc2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPkkg YmVsaWV2ZSB0aGUgcHJvcG9zYWwgaGVyZSB3YXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4qIEtlZXAgdHJhY2sg b2YgYWxsIG5vZGVzIHdobyBoYXZlIGJlZW4gZGVsZXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+KiBXaGVuIHlvdSB3aXNoIHRv IGRlbGV0ZSBhIG5ldyBub2RlLCBnZW5lcmF0ZSBhIHRlbXBvcmFyeSBrZXkgSywgdGhlbiBjb21w dXRlIGEgY29tcGxldGVseSB1bmJhbGFuY2VkIHRyZWUgd2l0aCBLIGFzIHRoZSBsZWZ0LW1vc3Qg bm9kZSwgYW5kIGVhY2ggbm9kZSB1cCBpdHMgY29wYXRoIGJlaW5nIG9uZQ0KIG9mIHRoZSBub2Rl cyBmcm9tIHRoZSBwdW5jdHVyZWQgdHJlZS4gVGhlIHJvb3Qgc2VjcmV0IGhlcmUgaXMgdGhlbiBL REZkIGludG8gdGhlIGVwb2NoIHNlY3JldDsgbWFraW5nIHRoZSBlcG9jaCBub3cgdW5jb21wdXRh YmxlIHRvIEUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtBQkNERkdI PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oyxz ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgR0g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtBQkNERjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBcDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyAv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2Vy aWYiPiZuYnNwOyBLQUJDRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+SyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBQkNEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+QSBuaWNlIHBy b3BlcnR5IHRvIG5vdGUgYWJvdXQgZG9pbmcgdGhpcyBpcyB0aGF0IHRoZSBzZXJ2ZXIgaXMgY2Fw YWJsZSBvZiBnZW5lcmF0aW5nIHN1Y2ggYSBkZWxldGUgbWVzc2FnZSAtIGFzIGl0IHJlbGllcyBv biBubyBwcml2YXRlIGluZm9ybWF0aW9uIC0gYW5kIHRoaXMgbWF5IGJlIHVzZWZ1bA0KIGluIGNl cnRhaW4gY2lyY3Vtc3RhbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5XZSBoYWQgYSBmYWly IGJpdCBvZiBkaXNjdXNzaW9uIGFib3V0IHRoZSBwb3N0LWNvbXByb21pc2Ugc2VjdXJpdHkgcHJv cGVydGllcyBoZXJlLCB3aGljaCB3ZSB2ZXJ5IHNjaWVudGlmaWNhbGx5IGRlZW1lZCB0byBiZSAm cXVvdDt3ZWlyZCBQQ1MmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5TcGVjaWZpY2FsbHkgdGhlIGlzc3Vl IGhlcmUgaXMgdGhhdCBFIGlzbid0IG5lY2Vzc2FyaWx5IHJlbW92ZWQgZnJvbSB0aGUgdHJlZSBh dCBhbnkgcG9pbnQuIFRoZXkgY2FuIHN0aWxsIGNvbXB1dGUgdGhlIHRyZWUgcm9vdCAtIGJ1dCBk b24ndCBrbm93IHRoZSBlcG9jaCBzZWNyZXQsIGFuZCBzbyBjYW5ub3QNCiBjb21wdXRlIGFueSBz dWJzZXF1ZW50IGVwb2NoIHNlY3JldHMgKGR1ZSB0byB0aGVpciBjaGFpbmluZykuIFRoaXMgbWVh bnMgdGhhdCBpZiBFIHdlcmUgdG8gY29tcHJvbWlzZSBzb21lIG90aGVyIHRyZWUgbWVtYmVyLCBh bmQgdGhlcmVmb3JlIGxlYXJuIHRoZSBlcG9jaCBzZWNyZXQsIEUgd291bGQgZWZmZWN0aXZlbHkg aGF2ZSByZWluc2VydGVkIHRoZW1zZWx2ZXMgYXMgYW4gb2JzZXJ2ZXIgdG8gdGhlIGdyb3VwLCBh cyB0aGV5IGNhbiBjb21wdXRlDQogYWxsIGZ1dHVyZSBvcGVyYXRpb25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ VG8gY2xhcmlmeSwgdGhlIHJlYXNvbiB0aGF0IHRoaXMgaXMgd2VpcmQgaXMgdGhhdCB3ZSB0ZW5k IHRvIHRoaW5rIG9mIFBDUyBhcyAmcXVvdDtQQ1Mgd2l0aCByZXNwZWN0IHRvIFgmcXVvdDsuIFNv IGlmIHRoZSBwcm90b2NvbCB3ZXJlIHRvIGhhdmUgUENTIHdpdGggcmVzcGVjdCB0byBhbnkgaW5k aXZpZHVhbCBwYXJ0aWNpcGFudA0KIC0geW91IHdvdWxkIGV4cGVjdCB0aGF0IGFmdGVyIHRoaXMg cGFydGljaXBhbnQgaGFzIHVwZGF0ZWQgdGhlaXIgb3duIGxlYWYga2V5LCBhbnlib2R5IHdobyBo YWQgcHJldmlvdXNseSBjb21wcm9taXNlZCB0aGVtIHdvdWxkIGJlIGxvY2tlZCBvdXQgYWdhaW4g KEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBhIHN0cmljdCBkZWZpbml0aW9uLCBidXQgaXQncyBjbG9z ZSBlbm91Z2ggYXMgYW4gaW50dWl0aW9uIGZvciBhIHNlbnNpYmxlIG1vZGUgb2Ygb3BlcmF0aW9u DQogZm9yIFBDUykuIEhvd2V2ZXIsIGluIHRoaXMgc2l0dWF0aW9uLCB3ZSBkb24ndCBoYXZlIFBD UyB3aXRoIHJlc3BlY3QgdG8gYW55Ym9keTsgc28gbG9uZyBhcyB0aGUgYXR0YWNrZXIga25vd3Mg dGhlIGxlYWYga2V5IGZvciBhIGRlbGV0ZWQgbWVtYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+T25lIHBvdGVu dGlhbCBtaXRpZ2F0aW9uIGhlcmUgd291bGQgYmUgdG8gZm9sbG93IGEgZGVsZXRlIHdpdGggYSBi bGFuayBvcGVyYXRpb24gLSBhcyBpbiByZXBsYWNlLXRoZW4tYmxhbmsuIE90aGVyd2lzZSB3aGF0 IHdlIHNlZW0gdG8gcHJvYmFibHkgaGF2ZSBpcyBhIHByb3RvY29sIHdpdGggZm9yd2FyZA0KIHNl Y3JlY3ksIGFuZCAmcXVvdDt3ZWlyZCBQQ1MmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5BZHZhbnRhZ2Vz IG9mIHRoaXMgYXBwcm9hY2ggd2l0aCB0aGUgbWl0aWdhdGlvbiBpbiBwbGFjZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+KiBNdWNo IGxlc3MgYm9vay1rZWVwaW5nIHJlcXVpcmVkOiB3ZSBuZXZlciBwdXQgYW55Ym9keSBpbiBhIHBy aXZpbGVnZWQgcG9zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPiogRGVsZXRlIGNhbiBiZSBwZXJmb3JtZWQgYnkgbm9uLWdy b3VwLW1lbWJlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5EaXNhZHZhbnRhZ2VzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4qIFdlaXJkIC0gb3Ig YXQgd29yc3Qgd2Vha2VyIC0gcG9zdC1jb21wcm9taXNlIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4qIEFmdGVyIG1h bnkgZGVsZXRpb25zLCBkZWxldGlvbiB0aW1lIGNvbXBsZXhpdHkgbWF5IGRlZ3JhZGUgdG8gbGlu ZWFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj5PZiB0aGVzZSBhcHByb2FjaGVzLCB3ZSB3ZW50IHdpdGggcmVwbGFjZS10aGVu LWJsYW5rIGZvciB0aGUgaW5pdGlhbCBkcmFmdCBkdWUgdG8gaXRzIGJldHRlciAob3IsIGF0IGxl YXN0LCBtb3JlIG9idmlvdXMpIFBDUyBwcm9wZXJ0aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5PdmVyIHRoZSBwYXN0IGZl dyBkYXlzIEkgdGhvdWdodCBvZiBhIG5ldyBhcHByb2FjaCBiYXNlZCBvbiBwdW5jdHVyZWQgdHJl ZXMsIHRoYXQgSSBiZWxpZXZlIG1heSB0b2xlcmF0ZSBsZXNzIGJvb2sta2VlcGluZyB0aGVuIHJl cGxhY2UtdGhhbi1ibGFuayB3aXRoIGJldHRlciBQQ1Mgd2l0aCBwdW5jdHVyZWQNCiB0cmVlIG1p eGlucy4gSSdtIG5vdCBmdWxseSBzdXJlIG9mIGl0cyBtZXJpdHMgb3IgZGlzYWR2YW50YWdlcywg c28gSSdkIHJlYWxseSBhcHByZWNpYXRlIGZlZWRiYWNrIG9uIHdoZXRoZXIgaXQgbWFrZXMgc2Vu c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj49PT09PTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5F dmljdGlvbi1wYXRoIHB1YmxpYyBrZXkgbXV0YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj7igJTigJTigJTigJTigJTigJTi gJTigJTigJQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPlRoZSBwcm9ibGVtIHdpdGggcmVwbGFjaW5nIGEgbm9uLShz aWJsaW5nIG9yIGNvdXNpbikgbm9kZSBpcyB0aGF0IHlvdSBjYW5ub3QgY29tcHV0ZSB0aGUgdmFs dWUgb2YgYSBwYXJlbnQgbm9kZSB3aXRob3V0IGtub3dpbmcgdGhlIHNlY3JldCB2YWx1ZSBhdCBv bmUgb2YgaXRzIGNoaWxkIG5vZGVzLiBUaGUNCiBhYm92ZSBkZWxldGlvbiBhcHByb2FjaGVzIGFy ZSB0aGVyZWZvcmUgYmFzZWQgb24gdGhlIGlkZWEgdGhhdCB5b3UgY2Fubm90IGNoYW5nZSB0aGUg cHJpdmF0ZSB2YWx1ZXMgaW4gYW5vdGhlciBicmFuY2ggb2YgdGhlIHRyZWUgd2l0aG91dCBpbnNl cnRpbmcgeW91cnNlbGYgaW50byBhIHByaXZpbGVnZWQgcG9zaXRpb24uIFRoaXMgYXNzdW1wdGlv biwgaG93ZXZlciwgKm1heSogbm90IGJlIGVudGlyZWx5IGNvcnJlY3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5X aGF0IHdlIG5lZWQgaGVyZSBpcyB0aGUgYWJpbGl0eSB0byBtdXRhdGUgc29tZWJvZHkgZWxzZSdz IHB1YmxpYyBrZXkgdG8gc29tZXRoaW5nIGZvciB3aGljaCB0aGV5IC0gYW5kIG9ubHkgdGhleSAt IGNhbiBjb21wdXRlIHRoZSBwcml2YXRlIGtleS4gRm9ydHVuYXRlbHksIEkgYmVsaWV2ZSB0aGF0 DQogRGlmZmllLUhlbGxtYW4gaXRzZWxmIGRpcmVjdGx5IHByb3ZpZGVzIHRoaXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNl cmlmIj5Gb3IgREggcHJpdmF0ZSBrZXkgeCwgdGhlIHB1YmxpYyBrZXkgaXMgZ154LiBJZiB3ZSB0 YWtlIGEgZGlmZmVyZW50IHByaXZhdGUga2V5IGssIHdlIGNhbiBwZXJmb3JtIHRoZSBESCBvcGVy YXRpb24gb24gaXQgdG8gZ2V0IGdeKHhrKS4gU28gZmFyLCB0aGlzIGlzIHN0YW5kYXJkIERIIC0g d2l0aCBnXih4aykNCiB0eXBpY2FsbHkgYmVpbmcgdXNlZCBhcyBhIHNoYXJlZCBzZWNyZXQuIFdl IGNvdWxkLCBob3dldmVyLCBpbnN0ZWFkIHRyZWF0IHhrIGFzIHRoZSBuZXcgcHJpdmF0ZSBrZXks IGFuZCBnXih4aykgYXMgaXRzIHB1YmxpYyBrZXkuIFRoaXMgdGhlbiBtZWFucyB0aGF0IGlmIHlv dSBjYW4gc2VjdXJlbHkgdHJhbnNtaXQgayB0byBldmVyeWJvZHk6IHRoZXkgY2FuIGFsbCBjb21w dXRlIGdeKHhrKTsgYnV0IG9ubHkgdGhlIG9yaWdpbmFsIHByaXZhdGUNCiBrZXkgb3duZXIgYWN0 dWFsbHkga25vd3MgdGhlIHByaXZhdGUga2V5IHhrIC0gYnkgdGhlIGRpc2NyZXRlIGxvZ2FyaXRo bSBwcm9ibGVtLiBOT1RFOiBJIERPIE5PVCBLTk9XIElGIE1ZIFJFQVNPTklORyBIRVJFIElTIFFV SVRFIENPUlJFQ1QuIFRoaXMgZGVmaW5pdGVseSByZXF1aXJlcyBpbnB1dCBmcm9tIHJlYWwgY3J5 cHRvZ3JhcGhlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5TbywgbGV0J3MgY29tYmluZSB0aGlzIG11dGF0aW9u IHdpdGggcHVuY3R1cmVkIHRyZWVzLiBOb3csIHdoZW4gQSB3YW50cyB0byBkZWxldGUgRSwgdGhl eSBjb21wdXRlIGEgbmV3IHNlY3JldCBrLCBhbmQgdHJhbnNtaXQgaXQgdG8gdGhlIHB1bmN0dXJl ZCB0cmVlIGV4Y2x1ZGluZyBFIC0gZW5zdXJpbmcNCiB0aGF0IGV2ZXJ5Ym9keSBhcGFydCBmcm9t IEUga25vd3MgaXQuIEV2ZXJ5Ym9keSBhcHBsaWVzIHRoZSBtdXRhdGlvbiB0byBldmVyeSBub2Rl IGluIEUncyBwYXRoLCBhbmQgaW1tZWRpYXRlbHkgZGVsZXRlcyBrLCByZXN1bHRpbmcgaW4gdGhl IHRyZWU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChBQkNERUZHSClrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7LyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEFCQ0QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKEVGR0gpazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNw OyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJzcDsgQUImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ0QmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKEVG KWsmbmJzcDsmbmJzcDsmbmJzcDsgR0g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+LyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7IC8m bmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsgLyZu YnNwOyBcPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPkEmbmJzcDsmbmJzcDsmbmJzcDsgQiZuYnNwOyBDJm5ic3A7Jm5ic3A7Jm5ic3A7 IEQmbmJzcDsgRWsmbmJzcDsmbmJzcDsgRiZuYnNwOyBHJm5ic3A7Jm5ic3A7Jm5ic3A7IEg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj4oSGVyZSB3ZSBhcmUgYWN0dWFsbHkgYnJlYWtpbmcgYW4gaW52 YXJpYW50IHRoYXQgdXNlZCB0byBob2xkIGZyb20gQVJUOiBzcGVjaWZpY2FsbHkgdGhhdCBhIHBh cmVudCBpcyBkaXJlY3RseSBjYWxjdWxhdGVkIGFzIEtERihESChjaGlsZHJlbikpLiBUaGlzIHdp bGwgbWVhbiB0aGF0IG5vZGVzIG5lZWQNCiB0byBjYWNoZSB0aGVpciBlbnRpcmUgcGF0aCwgYXMg dGhleSBjYW4ndCBkaXJlY3RseSBkZXJpdmUgdGhlbSwgYnV0IHRoaXMgZmVlbHMgZmluZSBpbiBw cmFjdGljZTogaXQncyBvbmx5IGxvZ2FyaXRobWljIGluIHNpemUgYW55d2F5LCBhbmQgd2UgbGlr ZWx5IHdvdWxkIHdhbnQgdG8gY2FjaGUgaXQgaW4gcmVhbC13b3JsZCB1c2FnZSB0byBhdm9pZCBl eHRyYSByZWNhbGN1bGF0aW9ucy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5UaGlzIGhhcyB0aGUgbmljZSBwcm9w ZXJ0eSB0aGF0IEUgbm8gbG9uZ2VyIGtub3dzIGFueSBwcml2YXRlIGtleSBpbiB0aGUgdHJlZTsg aW5jbHVkaW5nIHRoZWlyIG93bi4gVGhpcyBjb3VsZCBwb3RlbnRpYWxseSBhbGxvdyB1cyB0byBu ZXZlciBldmVuIGJvdGhlciB0byBibGFuayBpdCBvdXQsIGJ1dA0KIHVuZm9ydHVuYXRlbHkgd2Ug c3RpbGwgaGF2ZSBhIHNsaWdodGx5IHdlaXJkIFBDUyBwcm9wZXJ0eTogaWYgRSBoYWQgY29tcHJv bWlzZWQgYW55Ym9keSBzaG9ydGx5ICpiZWZvcmUqIGJlaW5nIGRlbGV0ZWQgZnJvbSB0aGUgdHJl ZSB0aGV5IGNvdWxkIGxlYXJuIGsgd2hlbiBpdCBpcyB0cmFuc21pdHRlZCwgYW5kIHRodXMgcGVy bWFuZW50bHkgcmVpbnNlcnQgdGhlbXNlbGYgaW50byB0aGUgdHJlZS4gSXQncyBhIG11Y2ggc21h bGxlciBjb21wcm9taXNlDQogd2luZG93IHRoYW4gaW4gdGhlIHByZXZpb3VzIHNvbHV0aW9uIC0g d2hpY2ggaXMgYW55IHRpbWUgaW4gdGhlIGZ1dHVyZSAtIGJ1dCBpdCdzIGVub3VnaCB0aGF0IHdl IHdvdWxkIHByb2JhYmx5IHN0aWxsIHdhbnQgdG8gaW5jbHVkZSBibGFua2luZyB3aGVuIHRoZSBz aWJsaW5nIG9yIGNvdXNpbiBuZXh0IHVwZGF0ZXMuIFdlIGNvdWxkIGFsc28gcGVyaW9kaWNhbGx5 IHNlbmQgYSBuZXcgayB1bnRpbCB0aGUgbm9kZSBoYXMgYmVlbiBibGFua2VkDQogdG8gaW1wcm92 ZSB0aGUgbWl0aWdhdGlvbiAod2hpY2gsIGluZGVlZCwgd2UgY291bGQgYWxzbyBkbyBpbiB0aGUg YWJvdmUgc29sdXRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPkFkdmFudGFnZXMgb2YgdGhp cyBhcHByb2FjaDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+KiBTYW1lIG1pbmltYWwgYm9vay1rZWVwaW5nIHJlcXVpcmVtZW50cyBh cyBpbiAmcXVvdDtNaXggaW4gc2VjcmV0IGZyb20gcHVuY3R1cmVkIHRyZWUmcXVvdDsuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiog RGVsZXRlcyBjYW4sIGFnYWluLCBiZSBwZXJmb3JtZWQgYnkgbm9uLWdyb3VwIG1lbWJlcnMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PiogRGVsZXRlcyBjb3VsZCBhbHdheXMgYmUgbG9nYXJpdGhtaWMgKHdpdGhvdXQgcGVyaW9kaWMg cmUta2V5aW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyxzZXJpZiI+KiBTbWFsbCBwcmUtZW1wdGl2ZSBjb21wcm9taXNlIHdpbmRvdyBmb3Ig ZXZpY3RlZXMgdG8gYmUgYWJsZSB0byB3ZWFrZW4gUENTICh3aXRob3V0IHBlcmlvZGljIHJlLWtl eWluZykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj5EaXNhZHZhbnRhZ2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4qIFN0aWxsIHdlYWtlciBQQ1Mg dGhhbiByZXBsYWNlLXRoZW4tYmxhbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiogV2VpcmQgdXNhZ2Ugb2YgREggd2hpY2ggSSdt IG5vdCBjb25maWRlbnQgdG8gYXNzZXJ0IGlzIHNhZmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+U28sIHRoZXNlIGFyZSB0aGUgb3B0aW9uczsg cGxlYXNlIGxldCBtZSBrbm93IGlmIGFueSBvZiBpdCBpc24ndCBjbGVhci4gSSdkIGxvdmUgdG8g Z2F0aGVyIHBlb3BsZSdzIHRob3VnaHRzLCBhbmQgYW55IGFsdGVybmF0aXZlIGFwcHJvYWNoZXMg eW91IGNhbiB0aGluayBvZiAtIHBhcnRpY3VsYXJseQ0KIGFzIGV2ZXJ5dGhpbmcgd2UndmUgdGhv dWdodCBvZiBzbyBmYXIgaW52b2x2ZXMgY2VydGFpbiBjb21wcm9taXNlcyE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7LHNlcmlmIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDssc2VyaWYiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_86011555DAF3485C91BB77884FE6B549fbcom_-- From nobody Mon Feb 12 10:09:11 2018 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 1E110129C5D for ; Mon, 12 Feb 2018 10:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fS1JmH1E6MJE for ; Mon, 12 Feb 2018 10:09:06 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (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 5936E126E3A for ; Mon, 12 Feb 2018 10:09:06 -0800 (PST) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1elIX8-0003uY-mR for mls@ietf.org; Mon, 12 Feb 2018 18:09:04 +0000 Received: from dhcp3-nat.cs.ox.ac.uk ([163.1.88.5] helo=T-200) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1elIX7-0000Fs-FN for mls@ietf.org; Mon, 12 Feb 2018 18:08:53 +0000 Date: Mon, 12 Feb 2018 18:08:52 +0000 From: Dennis Jackson To: mls@ietf.org Message-ID: <20180212180852.1915c0ea@T-200> In-Reply-To: <86011555-DAF3-485C-91BB-77884FE6B549@fb.com> References: <86011555-DAF3-485C-91BB-77884FE6B549@fb.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Oxford-Username: exet4027 X-Oxmail-Spam-Status: score=-0.0 tests=T_RP_MATCHES_RCVD -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [MLS] Removing members from groups X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 18:09:10 -0000 Hello Jon, I think I have a nice suggestion that would improve Option 1. The core idea is to keep PCS by rotating the deleted keys and balance the 'ownership' of deleted members amongst the active group members.=20 As you noted, you would have to replace any of the removed member keys (X's) that A generated when A is removed from the group. There is another issue: in the event A has bad randomness or is compromised at the instant when they removed E, PCS no longer holds. The adversary would know the unchanging replacement key X, which might never be blanked if E's neighbors are inactive. =20 This can be fixed by rotating X when A rotates their own key. Let ancestor(A,E) be the closest ancestor of both A and E. Then the number of intermediate values between E and ancestor(A,E) is the extra number of values transmitted whenever A updates their own key. At worst this doubles the number of values that A has to transmit when rotating their key, e.g. when the common ancestor of A and E is the root node. We can reduce this overhead. Let B be another group member such that the path between ancestor(B,E) and E is smaller than ancestor(A,E) and E). Then B should 'take over' the deletion of E by replacing X with a value Y it has generated itself. This requires transmitting fewer extra intermediate values than if A were to do it. (Plus if B is close enough, B can just blank E). In the best case, this reduces overhead per rotation from log n extra values, to 2 extra values. (Any closer B and could just blank A) For ease of implementation, this 'take over' can be done by B issuing the 'Delete Member' for the X leaf node. This also has a nice balancing property - even if A deletes a lot of members, other active members of the group will take over the deleted members key rotation and balance out the overhead of transmitting intermediate values. This also limits the O(n) blowup for the deletion of a member. I also had some ideas on how to give options 2 and 3 'true' PCS by computing k using a subtree with leaf nodes made out of the log n nodes on E's copath. The result is that the X value is updated whenever any group member rotates their key, but at the cost of something like (log log n) / 2 extra messages whenever any member rotates their key. Overall, it seemed a lot more complex than option 1 for little to no benefit. =20 Hope that is helpful!=20 All the best, Dennis On Mon, 12 Feb 2018 11:01:32 +0000 Jon Millican wrote: > Hello all, >=20 > Before we made the drafts public, our informal group spent a lot of > time discussing the various alternatives for how a member can be > safely removed (or deleted) from a group. With everything now public, > I wanted to present the main options that we were thinking about at > the time, and present a new variant that I've been thinking about > over the past few days. >=20 > The two main contenders that we considered were: >=20 > 1. Replace-then-blank. > 2. Mix in secret from punctured tree. >=20 > For all of these examples, I'll use this example tree, notating a > node by the list of members who know its private key: >=20 >=20 >=20 > ABCDEFGH > / \ > / \ > / \ > / \ > ABCD EFGH > / \ / \ > / \ / \ > AB CD EF GH > / \ / \ / \ / \ > A B C D E F G H >=20 >=20 >=20 > =3D=3D=3D=3D=3D > Replace-then-blank. > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > This is perhaps the most natural way to use ART for deletion. The > intuition is that you want to simply remove the evictee's leaf node > from the ratcheting tree; but if you can't perform this yourself, you > instead just replace their leaf key with one that they don't know, > which will remain there until somebody who is capable performs the > actual removal. >=20 > The mechanism for removing E works as follows: >=20 > If the deleter is F, G or H, they simply send an update to the tree > that marks E as blank. These three can trivially do this, as they can > perform the calculation DH(F, GH). This immediately and permanently > locks out E, who now knows nothing about the tree. Nobody else is in > a privileged position either; so this is ideal. >=20 > ABCD_FGH > / \ > / \ > / \ > / \ > ABCD _FGH > / \ / \ > / \ / \ > AB CD _F GH > / \ / \ / \ / \ > A B C D _ F G H >=20 >=20 >=20 > If the deleter is A, B, C or D; they cannot compute DH(F, GH), so > must instead *replace* E with a key X that they must generate and > then immediately destroy. This allows them to compute and transmit > E's full path, and thus the tree can continue to be used, but E is > again fully removed with no further knowledge of the contents of the > tree. >=20 >=20 > ABCDXFGH > / \ > / \ > / \ > / \ > ABCD XFGH > / \ / \ > / \ / \ > AB CD XF GH > / \ / \ / \ / \ > A B C D X F G H >=20 >=20 > The problem here though is that we have now put A in a privileged > position, in that A could have been dishonest and failed to delete X. > This isn't necessarily a problem if A is honest themself - or indeed > if A continues to be in the tree - as they therefore already have > access to the tree's contents; but we don't want the protocol to rely > on both of these being true. Indeed, if X were to remain in the tree > without ever being rotated, we could - if nothing else - suffer from > weakened Post-Compromise Security. >=20 > The first mitigation here is to lazily perform the above blank > operation next time a capable party (F, G and H in this situation) > performs their own update. >=20 > The second is to ensure that *if A is deleted, any nodes which A was > privileged over must also be re-replaced*. So, say, if B were to now > delete A (which B can do directly), they would also have to generate > an eviction key Y, to put in place of X, to make certain that A > cannot still compute the tree's root key. >=20 >=20 > _BCDYFGH > / \ > / \ > / \ > / \ > _BCD YFGH > / \ / \ > / \ / \ > _B CD YF GH > / \ / \ / \ / \ > _ B C D Y F G H >=20 >=20 > This whole process ends up requiring a little extra book-keeping. > It's not too complex, and I have a draft algorithm description for > this, but having the book-keeping is something of a downside. >=20 >=20 > Advantages of replace-then-blank: > * It's a very natural way of using ART. Easy to understand. > * It seems to reasonably straight-forwardly maintain post-compromise > security. >=20 > Disadvantages: > * Extra book-keeping somewhat increases protocol complexity. > * There are potential edge cases which could increase one-off delete > cost to O(n). E.g. if A has deleted one of every leaf pair in a large > tree, then somebody deletes A - they will also have to replace every > one of A's siblings. This should be rare, and I'm pretty sure > amortises away over many messages, but would still be a bad case. >=20 >=20 >=20 > =3D=3D=3D=3D=3D > Mix in secret from punctured tree. > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > This approach uses a neat trick that we figured out to get efficient > (n-1) subgroups of trees. For an example, in the tree that we've been > using - if A wishes to send a message to everybody apart from E, they > can encrypt it each of the public keys in E's copath: ABCD, F and GH. >=20 >=20 > ABCDEFGH > / \ > / \ > / \ > / \ > ABCD* EFGH > / \ / \ > / \ / \ > AB CD EF GH* > / \ / \ / \ / \ > A B C D E F* G H >=20 >=20 > This operation has logarithmic efficiency, as the copath is sized > log(n). The principle also extends to a more general concept of > "punctured trees"; whereby you can send a message to any subset of > the tree based on the smallest set of keys that none of the excluded > members know. This eventually degrades to linear in the worst case > (every second leaf node has been excluded), but again this likely > feels more edge-casey. >=20 >=20 > I believe the proposal here was: >=20 > * Keep track of all nodes who have been deleted. > * When you wish to delete a new node, generate a temporary key K, > then compute a completely unbalanced tree with K as the left-most > node, and each node up its copath being one of the nodes from the > punctured tree. The root secret here is then KDFd into the epoch > secret; making the epoch now uncomputable to E. >=20 >=20 > KABCDFGH > / \ > / GH > / > KABCDF > / \ > / F > / > KABCD > / \ > K ABCD >=20 >=20 > A nice property to note about doing this is that the server is > capable of generating such a delete message - as it relies on no > private information - and this may be useful in certain circumstances. >=20 >=20 > We had a fair bit of discussion about the post-compromise security > properties here, which we very scientifically deemed to be "weird > PCS". >=20 > Specifically the issue here is that E isn't necessarily removed from > the tree at any point. They can still compute the tree root - but > don't know the epoch secret, and so cannot compute any subsequent > epoch secrets (due to their chaining). This means that if E were to > compromise some other tree member, and therefore learn the epoch > secret, E would effectively have reinserted themselves as an observer > to the group, as they can compute all future operations. >=20 > To clarify, the reason that this is weird is that we tend to think of > PCS as "PCS with respect to X". So if the protocol were to have PCS > with respect to any individual participant - you would expect that > after this participant has updated their own leaf key, anybody who > had previously compromised them would be locked out again (I don't > think this is a strict definition, but it's close enough as an > intuition for a sensible mode of operation for PCS). However, in this > situation, we don't have PCS with respect to anybody; so long as the > attacker knows the leaf key for a deleted member. >=20 > One potential mitigation here would be to follow a delete with a > blank operation - as in replace-then-blank. Otherwise what we seem to > probably have is a protocol with forward secrecy, and "weird PCS". >=20 > Advantages of this approach with the mitigation in place: > * Much less book-keeping required: we never put anybody in a > privileged position. > * Delete can be performed by non-group-members. >=20 > Disadvantages: > * Weird - or at worst weaker - post-compromise security. > * After many deletions, deletion time complexity may degrade to > linear. >=20 >=20 >=20 >=20 >=20 >=20 > Of these approaches, we went with replace-then-blank for the initial > draft due to its better (or, at least, more obvious) PCS properties. >=20 >=20 >=20 >=20 >=20 >=20 > Over the past few days I thought of a new approach based on punctured > trees, that I believe may tolerate less book-keeping then > replace-than-blank with better PCS with punctured tree mixins. I'm > not fully sure of its merits or disadvantages, so I'd really > appreciate feedback on whether it makes sense. >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D > Eviction-path public key mutations. > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94 >=20 > The problem with replacing a non-(sibling or cousin) node is that you > cannot compute the value of a parent node without knowing the secret > value at one of its child nodes. The above deletion approaches are > therefore based on the idea that you cannot change the private values > in another branch of the tree without inserting yourself into a > privileged position. This assumption, however, *may* not be entirely > correct. >=20 > What we need here is the ability to mutate somebody else's public key > to something for which they - and only they - can compute the private > key. Fortunately, I believe that Diffie-Hellman itself directly > provides this. >=20 > For DH private key x, the public key is g^x. If we take a different > private key k, we can perform the DH operation on it to get g^(xk). > So far, this is standard DH - with g^(xk) typically being used as a > shared secret. We could, however, instead treat xk as the new private > key, and g^(xk) as its public key. This then means that if you can > securely transmit k to everybody: they can all compute g^(xk); but > only the original private key owner actually knows the private key xk > - by the discrete logarithm problem. NOTE: I DO NOT KNOW IF MY > REASONING HERE IS QUITE CORRECT. This definitely requires input from > real cryptographers. >=20 > So, let's combine this mutation with punctured trees. Now, when A > wants to delete E, they compute a new secret k, and transmit it to > the punctured tree excluding E - ensuring that everybody apart from E > knows it. Everybody applies the mutation to every node in E's path, > and immediately deletes k, resulting in the tree: >=20 >=20 > (ABCDEFGH)k > / \ > / \ > / \ > / \ > ABCD (EFGH)k > / \ / \ > / \ / \ > AB CD (EF)k GH > / \ / \ / \ / \ > A B C D Ek F G H >=20 >=20 > (Here we are actually breaking an invariant that used to hold from > ART: specifically that a parent is directly calculated as > KDF(DH(children)). This will mean that nodes need to cache their > entire path, as they can't directly derive them, but this feels fine > in practice: it's only logarithmic in size anyway, and we likely > would want to cache it in real-world usage to avoid extra > recalculations.) >=20 > This has the nice property that E no longer knows any private key in > the tree; including their own. This could potentially allow us to > never even bother to blank it out, but unfortunately we still have a > slightly weird PCS property: if E had compromised anybody shortly > *before* being deleted from the tree they could learn k when it is > transmitted, and thus permanently reinsert themself into the tree. > It's a much smaller compromise window than in the previous solution - > which is any time in the future - but it's enough that we would > probably still want to include blanking when the sibling or cousin > next updates. We could also periodically send a new k until the node > has been blanked to improve the mitigation (which, indeed, we could > also do in the above solution). >=20 >=20 > Advantages of this approach: > * Same minimal book-keeping requirements as in "Mix in secret from > punctured tree". > * Deletes can, again, be performed by non-group members. > * Deletes could always be logarithmic (without periodic re-keying). > * Small pre-emptive compromise window for evictees to be able to > weaken PCS (without periodic re-keying). >=20 > Disadvantages: > * Still weaker PCS than replace-then-blank. > * Weird usage of DH which I'm not confident to assert is safe. >=20 >=20 >=20 >=20 >=20 > So, these are the options; please let me know if any of it isn't > clear. I'd love to gather people's thoughts, and any alternative > approaches you can think of - particularly as everything we've > thought of so far involves certain compromises! >=20 >=20 > Thanks! > Jon From nobody Wed Feb 21 08:52:05 2018 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 652E61242F7 for ; Wed, 21 Feb 2018 08:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 doBJESrDNJbg for ; Wed, 21 Feb 2018 08:52:02 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C44E127010 for ; Wed, 21 Feb 2018 08:52:01 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id o76so6371866wrb.7 for ; Wed, 21 Feb 2018 08:52:01 -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=DFOSFX+USmvWsq97WKu0epHAJ4tcqBU0gJWXCIPNwu4=; b=ru2Cc7qf6z0BQiZOcYhQKjH6ER6WOkEVu2bOn29eR8RNyjGE7su4YS01hCHRpYBuWo 8TPIPiLCAgQM5/VtE0GJ3Xux/8BvrJ1xALy+c0yyrxjS7DE5gh9hXLei3KHn4MCohXlR 7syMykB1xXYk7YXUtvTlI+L/yfXL3yhw5FyRQuHdmxUETuIqGEyZdifEb/Lq5aNYdNSu HiOS9vPgb71Z4xA3lTsxpNHOVlIVslYQoPqRSeo0VSf5hjFMINZGXQ5SSBia4RSDCmZY E4EZurem9RUkbUeUxIcQlbea0n7RxOsf4icbJiFlezjUDF0+xSQTxxf1qGQCDOGSnw4t RBJQ== 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=DFOSFX+USmvWsq97WKu0epHAJ4tcqBU0gJWXCIPNwu4=; b=KCPRGbefqzs1PTyjOAXP3jhN7BPY6vLa8d//qXKI5jC0pzPf6wtMilMG0oYpmL9BTP trjKefiIHuzuK5H6Afpti0OREumywI/aGp77qKfdaShXSM0XpWzZEeULSDOrpLHqRgRX no28Xzw5220ZH1K4Yj10e1LjDWXsGnr5jhIrwgrNMh0vANQApEMTfVvlbZ5UDHBQqE5S 2GQzElaZI3zVEku9/hWlZg+WGae+5Po09wh7gFmEnYD/FPS7RV2mwdD0VAoy7iLN0Ck3 rc3VO7ip5JbjrKZMAowrKwxWNabNgFwOhQXP99gUtyimOwtndz0A+SM797o3plBBB4W4 WMoA== X-Gm-Message-State: APf1xPCIGqUIAO4GPsMe5T/uwDZMvN7UC9ySqdZXS+wueoKg1e6Z68JX ySgqa4SjU9v+cPjhi+12vYbRiW+5FSFP7//ekuZY2qZLfLY= X-Google-Smtp-Source: AH8x2265e8ChSJ+16xuhZnQ2rY/UPfVWkGfUOKEywb+ErCUX40/IjWHHky3CaGZ7TSDSTIHQECIFjJ6zeEpiD4lENn8= X-Received: by 10.223.171.167 with SMTP id s36mr3478274wrc.52.1519231919872; Wed, 21 Feb 2018 08:51:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.20.66 with HTTP; Wed, 21 Feb 2018 08:51:59 -0800 (PST) From: Richard Barnes Date: Wed, 21 Feb 2018 11:51:59 -0500 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113b37b6ea91d20565bbbe7d" Archived-At: Subject: [MLS] MLS BoF has been scheduled X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:52:03 -0000 --001a113b37b6ea91d20565bbbe7d Content-Type: text/plain; charset="UTF-8" FYI, the preliminary agenda for IETF 101 has been posted: https://datatracker.ietf.org/meeting/agenda.html The MLS BoF is scheduled for 15:50 - 17:50 on Thursday, March 22. For anyone who won't be there in person, remote participation details should be added at the above link as we get closer to the meeting. --001a113b37b6ea91d20565bbbe7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, the preliminary agenda for IETF 101 has been pos= ted:

<= div>
The MLS BoF is scheduled for 15:50 - 17:50 on Thursday, = March 22.=C2=A0

For anyone who won't be t= here in person, remote participation details should be added at the above l= ink as we get closer to the meeting.
--001a113b37b6ea91d20565bbbe7d-- From nobody Tue Feb 27 01:53:35 2018 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 4A94F1274D2 for ; Tue, 27 Feb 2018 01:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=bgJh10hE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IMpcNv5P 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 wNfRgpGhaO-E for ; Tue, 27 Feb 2018 01:53:33 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E57F126BF7 for ; Tue, 27 Feb 2018 01:53:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 67E8E2094D for ; Tue, 27 Feb 2018 04:53:32 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 27 Feb 2018 04:53:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=4S2H2HgujKJ/b+VuoBgZcwfd1xjB11VTnLRUDdb8GuE=; b=bgJh1 0hE+RpnbG8KAE+8HYkKYMbmCDj+C5l+TOAt2LxuopG46YbM3lflDblaPReJjMYR1 p7pvb4Oz/zDheu2xYxxJwTtS5fjkI+PVaeKwQBs95B3v7svsSZud5bCmeOefHAdS WZl1TEaiy8otJoVTicYgfeFwZKg/E3Ea79L9mE= 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-sender :x-me-sender:x-sasl-enc; s=fm2; bh=4S2H2HgujKJ/b+VuoBgZcwfd1xjB1 1VTnLRUDdb8GuE=; b=IMpcNv5PmgBkeaCAYM+sGo/pEjfbRWRIDhxnx5EQTa0yg TUTL1FHYg/p2FEIiMWEepmLiJaWsR1QhO3Oo0hr0vaOb6ERXKiJ85ySAO32NaLdE mfUqhDUiukLlf+3+AmdOuOIchRReHt727o7LeYrFlgcrJA2AOOlIr/LheV3tXval oLmYzzLKIjN7agCuhlKJbQ1AO3U2RDtjfc4RtOUmD7sSUV+tz9HQHaOLsUM1lhSX hAh8szkydwNhX2dy75yu4YlVYgyvVzLGaQ3SBACnTvCkEVPmhMa645QXe6/idoC6 DeOHFUUXZhR+ygT6JLM7HoFOo8g6R1vd/fd6jJZ7A== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4AE36429A; Tue, 27 Feb 2018 04:53:32 -0500 (EST) Message-Id: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 Date: Tue, 27 Feb 2018 09:53:32 +0000 X-Forwarded-Message-Id: <1519725148.924004.1284817792.27264EB7@webmail.messagingengine.com> Archived-At: Subject: [MLS] small subgroup validation X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 09:53:35 -0000 Hi all, We should probably consider small subgroup attacks more carefully in the threat analysis and the draft documents. Specifically, computational proofs often implicitly assume point validation, which is particularly important in the case that a malicious group member sends an invalid copath element. I think the draft should state that point validation is required on all received group elements (unless using a group that doesn't require it); if I understand correctly this will cost roughly an additional exponentiation for each check, so O(log(n)) for a new and untrusted copath. [This was pointed out by Dennis Jackson.] best, Katriel From nobody Tue Feb 27 02:08:48 2018 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 BE2F9126BF6 for ; Tue, 27 Feb 2018 02:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Xx5p9ezpT-_i for ; Tue, 27 Feb 2018 02:08:42 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 1C1AA126BF7 for ; Tue, 27 Feb 2018 02:08:42 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id h21so22881705wmd.1 for ; Tue, 27 Feb 2018 02:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=EvB3PeEqqvJ2Vb4mRAJyB+PvR5WxE04U/ek0CQ0X3ws=; b=j5YqHG2XfQgWkrVSX72qUz4J4FkSITTcvdlKF84/YCZRbCgqXPbFDdjBg2dImfIWef JAgeUOmsB5U2VOt23vsnqfvf66kl1KRMBp/3L1ip+ti3j3GsOt3vq/Tr3CpVkyCgns5L HE6CZm0OIl8AYDW1jhC9df7ESiWJb/ErfeWFhTlWfJELrI/+olAxJgHdP/pQxRIWyrco BpxjGhpzfXpeT0/NI4RwhMZtPFACbbXUISgwGOpVwAL+Dd2UXgKoagv1MI7TrV4bcXbg 5k8D2E2/O4A+q8lv/k2IwLHoY5esPp09cVrYTodjlJe5Tx9VK/QmhPqK2NS3uKe1uNp2 re/g== 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=EvB3PeEqqvJ2Vb4mRAJyB+PvR5WxE04U/ek0CQ0X3ws=; b=NXmzKK+72KLfjpLk2Xm8kvI8NCejLs2VCiInwHLG+wbPDu5ijKyUpVbkWAckR2oZOh go7zCgumfV1WiYciYq/60gyao1B6QZk/W15JPWDZpltD0+QY4gxRQyA97YTesHSiVmep HNEN00wkGxmqFSq8vRVry0dnzXmxgP82m/PC0xdwYDQW2sG7ZB6wCvRt6QJKP7a9FwHU t1kZI7zaWpDljS/aPcwk6k5G5C9mX9Qmx5Jvs9xLmUTAFa+v9cn8HM+nSgWES7/x15Rd gXEqLIxeSca9jDOV5Uqg5Ci/zX92b1q3oqmJuGUHm+NPqOf19aYuhaXGNxmWaTwas5Zv Ql4Q== X-Gm-Message-State: APf1xPDm8vP0EcFdSy2hu0Zj275a6QABp85qBg3Oua41wo2XLXai38k2 +7/LvsltIoEr1RfCuh3CT9HSrzUJ X-Google-Smtp-Source: AH8x224rEfGhqhlzYXqZpPp1z7cdi0ZVWta9jgG75FSkOf0CxWvRfTIuSSb4BST2JkS2kEyODjVpOg== X-Received: by 10.80.240.20 with SMTP id r20mr18622101edl.91.1519726120440; Tue, 27 Feb 2018 02:08:40 -0800 (PST) Received: from jagtop.fritz.box (dslb-178-000-201-148.178.000.pools.vodafone-ip.de. [178.0.201.148]) by smtp.gmail.com with ESMTPSA id c22sm11300838eda.1.2018.02.27.02.08.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 02:08:39 -0800 (PST) From: Tibor Jager Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 27 Feb 2018 11:08:38 +0100 References: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> To: Katriel Cohn-Gordon , mls@ietf.org In-Reply-To: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> Message-Id: <40A3FCD9-8498-46F5-946C-0709B4365731@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MLS] small subgroup validation X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 10:08:47 -0000 > On 27 Feb 2018, at 10:53, Katriel Cohn-Gordon = wrote: >=20 > We should probably consider small subgroup attacks more carefully in = the threat analysis and the draft documents. +1 > Specifically, computational proofs often implicitly assume point = validation, which is particularly important in the case that a malicious = group member sends an invalid copath element. I think the draft should = state that point validation is required on all received group elements = (unless using a group that doesn't require it); if I understand = correctly this will cost roughly an additional exponentiation for each = check, so O(log(n)) for a new and untrusted copath. For elliptic curve groups this can often be done more easily, by simply = checking the equation y^2 =3D x^3 + ax + b. This is almost for free, = when compared to the cost of an exponentiation. Cheers, Tibor From nobody Tue Feb 27 04:20:52 2018 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 9EE42129C6D for ; Tue, 27 Feb 2018 04:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 Q-eKtCMT3Fkk for ; Tue, 27 Feb 2018 04:20:49 -0800 (PST) Received: from thunk.cs.uwaterloo.ca (thunk.cs.uwaterloo.ca [129.97.7.148]) (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 3D060129C6A for ; Tue, 27 Feb 2018 04:20:48 -0800 (PST) Received: from iang by thunk with local (Exim 4.86_2) (envelope-from ) id 1eqeFT-00058o-Eg; Tue, 27 Feb 2018 07:20:47 -0500 Date: Tue, 27 Feb 2018 07:20:47 -0500 From: Ian Goldberg To: mls@ietf.org Message-ID: <20180227122047.GS10778@cs.uwaterloo.ca> References: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> <40A3FCD9-8498-46F5-946C-0709B4365731@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40A3FCD9-8498-46F5-946C-0709B4365731@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [MLS] small subgroup validation X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 12:20:50 -0000 On Tue, Feb 27, 2018 at 11:08:38AM +0100, Tibor Jager wrote: > > > > On 27 Feb 2018, at 10:53, Katriel Cohn-Gordon wrote: > > > > We should probably consider small subgroup attacks more carefully in the threat analysis and the draft documents. > > +1 > > > Specifically, computational proofs often implicitly assume point validation, which is particularly important in the case that a malicious group member sends an invalid copath element. I think the draft should state that point validation is required on all received group elements (unless using a group that doesn't require it); if I understand correctly this will cost roughly an additional exponentiation for each check, so O(log(n)) for a new and untrusted copath. > > For elliptic curve groups this can often be done more easily, by simply checking the equation y^2 = x^3 + ax + b. This is almost for free, when compared to the cost of an exponentiation. That protects against the invalid curve attack (which is also important to check!), not the small subgroup attack. A point can satisfy the curve equation, but if the curve has non-prime order (like Edwards curves), you'll still want to check that the point is in the prime-order subgroup that you typically want to be working in. -- Ian Goldberg Professor and University Research Chair Cheriton School of Computer Science University of Waterloo From nobody Tue Feb 27 05:54:41 2018 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 20EF212D86E for ; Tue, 27 Feb 2018 05:54:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 8wfmGdqi4PTG for ; Tue, 27 Feb 2018 05:54:38 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 4C99D126DC2 for ; Tue, 27 Feb 2018 05:54:38 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id c7so23183443qtn.3 for ; Tue, 27 Feb 2018 05:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G1GvyFdw2cGWGAVNpX9RhWpiEGLBaKNOGcMQUSAmmDs=; b=z1/SLvSSLZgErV9qwwmE3HUG6Pb5pSBM+IazwoyEOmx7BVq3bmXXy1zNr2OeD6RVBy 3BipMxQ1WhxgUS+QFxmgw7VuHGQ1IbaWrDiXjljaczIAL2FyrBqxaNpX1B4Tmg1w6bev +bAI0/l9GGqha5SB/Oi/0ZX0SWBVTG1IFu3fIKyY0VdtTcqL7rZ9CUscqV1Z3HFjOywn uy56oQFeEIuJMpRwOZEfcgrraQMo+a7F/rruQJQkqeN3gECHX+ERSKiQpFLUPXdYA8UI iP5WLe8tgegGze0dj0/Resekb5MshMpkJspUVxBUxBNIPJH9SVxImSqlngoONkYkTqK+ pW6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G1GvyFdw2cGWGAVNpX9RhWpiEGLBaKNOGcMQUSAmmDs=; b=oclgFaxAvi8GQyVrws3SPajE9Yat1QtgT0hoDqmpab2oKhySnmiKzLkiDX9mHmkCZI NKLSD3ouszXkUiGFen4C4DQySoShj2VNPv0qLDpcjHBefoBsGA7WIxXOyLOvdN97ejuR uXtim6FB4G0XUPfF+0rQ0NXFVUdU9qmGLyCXytQm1B1vfKCLQDvs9Nt3p4m2kLY0dHN+ Pmashjm9osfqQwvG5s6kbFl/EUQuc4geOpLtg8jf+sYvA0Jr3jpC2LLiqmI19PtkQre3 qg1JqdXoYvFy4w4y8kl4MsewocxdIPviV5gP5EhmF+NSUzQgqOa45ihFLzm3bVgMWcoD C1vA== X-Gm-Message-State: APf1xPD3gbske1DWet5Hp+LGORAiTeoN2+QF7UfUpa7weGHt/Cs0UJN5 2S9yHGkVuMb919KPF/sC1qDJq8Fyc/b/09ifqODDYMIsPMs= X-Google-Smtp-Source: AG47ELu61CzTv2XV0quboLvIKUQZhUE7eKy7uqRIJ2NZol7hBbWHiOz7Deaiau1quSA0Cb56bGc1hiqhisadZCqA2Dk= X-Received: by 10.237.61.112 with SMTP id h45mr23650596qtf.225.1519739677241; Tue, 27 Feb 2018 05:54:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Tue, 27 Feb 2018 05:53:56 -0800 (PST) In-Reply-To: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> References: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> From: Eric Rescorla Date: Tue, 27 Feb 2018 05:53:56 -0800 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113520e09d2f39056631f793" Archived-At: Subject: Re: [MLS] small subgroup validation X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 13:54:40 -0000 --001a113520e09d2f39056631f793 Content-Type: text/plain; charset="UTF-8" The current drafts do require some validation, borrowed from Matt Green's contributed text to TLS 1.3. https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.1 https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.2 I haven't gone through this in detail in a while. Perhaps it's insufficient? Or were you just making the general point that we should state it for new curves? -Ekr On Tue, Feb 27, 2018 at 1:53 AM, Katriel Cohn-Gordon wrote: > Hi all, > > We should probably consider small subgroup attacks more carefully in the > threat analysis and the draft documents. > > Specifically, computational proofs often implicitly assume point > validation, which is particularly important in the case that a malicious > group member sends an invalid copath element. I think the draft should > state that point validation is required on all received group elements > (unless using a group that doesn't require it); if I understand correctly > this will cost roughly an additional exponentiation for each check, so > O(log(n)) for a new and untrusted copath. > > [This was pointed out by Dennis Jackson.] > > best, > Katriel > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --001a113520e09d2f39056631f793 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current drafts do require some validation, borrowed fr= om Matt Green's contributed text to TLS 1.3.

https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.= 1

I haven't gon= e through this in detail in a while. Perhaps it's insufficient? Or were= you just making the general point that we should state it for new curves?<= /div>

-Ekr


On Tue, Feb 27, 2018= at 1:53 AM, Katriel Cohn-Gordon <me@katriel.co.uk> wrote:
Hi all,

We should probably consider small subgroup attacks more carefully in the th= reat analysis and the draft documents.

Specifically, computational proofs often implicitly assume point validation= , which is particularly important in the case that a malicious group member= sends an invalid copath element. I think the draft should state that point= validation is required on all received group elements (unless using a grou= p that doesn't require it); if I understand correctly this will cost ro= ughly an additional exponentiation for each check, so O(log(n)) for a new a= nd untrusted copath.

[This was pointed out by Dennis Jackson.]

best,
Katriel

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

--001a113520e09d2f39056631f793-- From nobody Tue Feb 27 06:05:46 2018 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 CA323126DC2 for ; Tue, 27 Feb 2018 06:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=wxX045r9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eV+r+Zzm 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 oE19YUkYgXiI for ; Tue, 27 Feb 2018 06:05:41 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B179012D876 for ; Tue, 27 Feb 2018 06:05:41 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D387B20DD6; Tue, 27 Feb 2018 09:05:40 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Tue, 27 Feb 2018 09:05:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=mesmtp; bh=XYzM3xj083JqK4 wGCLH7LFBbRZoQYsTmB1CILqTcbr4=; b=wxX045r9AaMY0WBWIIG8t7O6BFqyJ5 F8ZciP+g43RDfORQNsOw5HY2c6drrq5+kCxK7hgkJIaO42jD0cuJx3D8o1C0/Ab2 JfO5gcdHPFFzMIZ4+7VHXtD2DES3KQmF+ZL7yfXTJSVA5EIgdt2hMu9r/MEdMNhr 70DyRj484Yc0o= 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XYzM3x j083JqK4wGCLH7LFBbRZoQYsTmB1CILqTcbr4=; b=eV+r+Zzms+RPN7BBQvveZO jf5cNxlKoB1xS1mOB1ZuEpN3uQPTidTM3Xr4bdCKvcEGOzgPWPabcLpGsmtCxdLG 8I+8cVEQbEvtJW4FfQoL2djanvAvOzne7fhVSIl3A61pcpmxfpeGsOJ4XfIPDEMb 5pkMWvbyJFgEbLenRzwvW+PTrMYPeDSzF7LfU9RVxNeeQ9OTxtz4s/rJM+U4v18s KoIdK42xSvQnJ4N2V4msPJ5qT8vFd++ICk5I77kk98XOTdwLJnbSCIIP4a6Jl24Y 8yeWYhdRNgJQLna60FoDRBoBu6rizV5AuWronsUY5S1PBd0WWLNiQyo5c7IWzfiA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A7217429A; Tue, 27 Feb 2018 09:05:40 -0500 (EST) Message-Id: <1519740340.1025773.1285066592.29F98648@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: Eric Rescorla Cc: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151974034010257730" X-Mailer: MessagingEngine.com Webmail Interface - ajax-efbb3405 Date: Tue, 27 Feb 2018 14:05:40 +0000 References: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> In-Reply-To: Archived-At: Subject: Re: [MLS] small subgroup validation X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:05:44 -0000 This is a multi-part message in MIME format. --_----------=_151974034010257730 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I'm not an expert on small subgroup attacks in ECC so wanted to make sure we had thought it through fully, particularly where we reason about what invalid points an adversary can send, and where we state our assumptions on primitives. That is to say, the current text may well be enough, I just wanted to flag it up :) Katriel On Tue, 27 Feb 2018, at 1:53 PM, Eric Rescorla wrote: > The current drafts do require some validation, borrowed from Matt > Green's contributed text to TLS 1.3.> > https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.1> https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.2> > I haven't gone through this in detail in a while. Perhaps it's > insufficient? Or were you just making the general point that we should > state it for new curves?> > -Ekr > > > On Tue, Feb 27, 2018 at 1:53 AM, Katriel Cohn-Gordon > wrote:>> Hi all, >> >> We should probably consider small subgroup attacks more carefully in >> the threat analysis and the draft documents.>> >> Specifically, computational proofs often implicitly assume point >> validation, which is particularly important in the case that a >> malicious group member sends an invalid copath element. I think the >> draft should state that point validation is required on all received >> group elements (unless using a group that doesn't require it); if I >> understand correctly this will cost roughly an additional >> exponentiation for each check, so O(log(n)) for a new and untrusted >> copath.>> >> [This was pointed out by Dennis Jackson.] >> >> best, >> Katriel >> >> _______________________________________________ >> 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 --_----------=_151974034010257730 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I'm not an expert on small subgroup attacks in ECC so wanted to make sure we had thought it through fully, particularly where we reason about what invalid points an adversary can send, and where we state our assumptions on primitives.

That is to say, the current text may well be enough, I just wanted to flag it up :)

Katriel


On Tue, 27 Feb 2018, at 1:53 PM, Eric Rescorla wrote:
The current drafts do require some validation, borrowed from Matt Green's contributed text to TLS 1.3.


I haven't gone through this in detail in a while. Perhaps it's insufficient? Or were you just making the general point that we should state it for new curves?

-Ekr


On Tue, Feb 27, 2018 at 1:53 AM, Katriel Cohn-Gordon <me@katriel.co.uk> wrote:
Hi all,

We should probably consider small subgroup attacks more carefully in the threat analysis and the draft documents.

Specifically, computational proofs often implicitly assume point validation, which is particularly important in the case that a malicious group member sends an invalid copath element. I think the draft should state that point validation is required on all received group elements (unless using a group that doesn't require it); if I understand correctly this will cost roughly an additional exponentiation for each check, so O(log(n)) for a new and untrusted copath.

[This was pointed out by Dennis Jackson.]

best,
Katriel

_______________________________________________
MLS mailing list
_______________________________________________
MLS mailing list

--_----------=_151974034010257730-- From nobody Tue Feb 27 15:15:32 2018 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 E160B12EADA; Tue, 27 Feb 2018 15:11:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: mls@ietf.org, Kathleen.Moriarty.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307491.5200.14593508788856954121.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:14 -0800 Archived-At: Subject: [MLS] mls - Requested session has been scheduled for IETF 101 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:15 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mls Session 1 (2:00:00) Thursday, Afternoon Session II 1550-1750 Room Name: Buckingham size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: tls dispatch secdispatch saag acme quic perc People who must be present: Kathleen Moriarty Ben Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Feb 27 20:26:12 2018 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 DDE5C12741D for ; Tue, 27 Feb 2018 20:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 m3Ihq2By4Bfi for ; Tue, 27 Feb 2018 20:26:08 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 01021129C59 for ; Tue, 27 Feb 2018 20:26:07 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id m5so960752wrg.1 for ; Tue, 27 Feb 2018 20:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YwiZShj9LdGYdM2IAfA+ElcVJ/J2u4un8ztP6rMvkOA=; b=l2rE61rItYMa+8KKvCPlrXdRRAdb+WOnjKHSF5gw1qA6bkN0mmQl0kdDnVBWTrx89j Xv4EhTb/9y7+MyCgtxxn4VyHtQ2FoB72blFDgt7zsrZ7e/STxAGXvLm4CNZGYtun1Bxr twplXPWE6PZ6sgD1NOwYzxCnJdDYCYz1rdw2F9YmMZhuuywcYOMAlGyNOF0y6tZSzVCT 0d3Z21AsWp8H8217Uicr147RthmbjlveYdUbY6YGpoMNE9PR9zc5gz3e28sfF29BsVlY 39U3dTOGmZzmwUtpDH+fjPtgCnZqVqJKEyilEtyxqAFkSTCzo0ZpssHpAKhhNgVxxHLv ZoXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YwiZShj9LdGYdM2IAfA+ElcVJ/J2u4un8ztP6rMvkOA=; b=BoVercBmILpDRr1nqYraGu4+WxxcH+zklaIyBCeRCMexFt5XGMGvy+gG/7friH4OWK RBCKzI67GkpvAJOWyyH0STFRs1TVGSXwqnNwvp9uhUuwDk6Z11np5noYUeemJF/G6HtE zrgDq4VW3YFwMvQZizg4uHDZrVJCRWDYpcx2u1x2qgZms+vsx98bbqKpDuJUUc6kQuv8 LXzWS0J0MEsnqGn2AYhHNSxgML7lodPTemaYS6YubApQi9EDyU1E7KJog4IYwlhe0BOZ Mr3UeAKvSaJz/c4+g80RytLC/tW9Ck5DD2PMxnlt2EyCNk7OHAAbfSuxBQrkg67yBOM5 FBtw== X-Gm-Message-State: APf1xPDCMmc6OW12vtqYqW34R5WCwYeYGY856Q50hZ26CNBnO8UNncTQ O6YwBawSuIO/f05TBZlCP04ODLm5gBwSbzR+W9nBPi13+N8= X-Google-Smtp-Source: AH8x227SKQsr3h57dyOMV1Ek8LuvuFUPrRWNY4Kr0E2Yer/Ouk1yS5VCQoUVVzemiBZ0cDJa0/6wnHgLyf0cYnV+POA= X-Received: by 10.223.171.167 with SMTP id s36mr13826642wrc.52.1519791966341; Tue, 27 Feb 2018 20:26:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Tue, 27 Feb 2018 20:26:05 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Tue, 27 Feb 2018 23:26:05 -0500 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113b37b64954fa05663e247e" Archived-At: Subject: Re: [MLS] Go implementation; hackathon? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 04:26:10 -0000 --001a113b37b64954fa05663e247e Content-Type: text/plain; charset="UTF-8" I went ahead and added an MLS topic to the hackathon wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon I'll plan on being there, and Emad and Raphael told me they would be as well. It would be great to get to the BoF already having some interoperable implementations! On Mon, Feb 5, 2018 at 2:36 PM, Richard Barnes wrote: > I just made public a repo I've had going with a Go implementation of > draft-barnes-mls-protocol. It should illustrate the algorithms underlying > what's in the document, with more details about how the tree math works, > etc. > > https://github.com/bifurcation/mls > > Speaking of implementation -- There's an IETF hackathon on the weekend > before the IETF. If anyone else was interested in working together on > implementations / testing interoperability, it might be possible to get a > table there. > > https://www6.ietf.org/hackathon/101-hackathon.html > --001a113b37b64954fa05663e247e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I went ahead and added an MLS topic to the hackathon = wiki:


I'll plan on being there, and Ema= d and Raphael told me they would be as well.=C2=A0 It would be great to get= to the BoF already having some interoperable implementations!

On Mon, Feb 5,= 2018 at 2:36 PM, Richard Barnes <rlb@ipv.sx> wrote:
I just made public a repo I'v= e had going with a Go implementation=20 of draft-barnes-mls-protocol.=C2=A0 It should illustrate the algorithms=20 underlying what's in the document, with more details about how the tree= =20 math works, etc.


Speaking of implementation -- There's an IETF hackathon on the weekend before= =20 the IETF.=C2=A0 If anyone else was interested in working together on=20 implementations / testing interoperability, it might be possible to get a table there.

https://www6.ietf.org/hackatho<= wbr>n/101-hackathon.html

--001a113b37b64954fa05663e247e-- From nobody Tue Feb 27 20:53:58 2018 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 32ABD1267BB for ; Tue, 27 Feb 2018 20:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 zs4TR5pbD2GF for ; Tue, 27 Feb 2018 20:53:54 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 9EB1D1241F8 for ; Tue, 27 Feb 2018 20:53:54 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id u73so874400oie.3 for ; Tue, 27 Feb 2018 20:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=9k3Lycrr2Uds0sU98baQTH+JQ4KS14URP3HEc5BMBwY=; b=N07M/J5Le5+97HoSdSDL1Slrzs9Sma9HmF+SISk+jI5MsrZdAw1tUuWaYwZ+JWw10v NsuYgpbo15At/a4fI4zeHw29zFGjgNCMOh18GuDnDGlS9AcxX5qbnjLOqBP+qOspANle ea0lkMhHfre7QqMXis8cANKnhDAYQ6Qo6499Wt+UezaRrR0I7qe903qb+kwgprYuDdEf i4xFnt2BNzoDgBOoeVxFZWfDUPwpP1kdqyb0KNs9a1kZatZeq1a4aLmnSHu6ejw0kxYD ewEZrinPPl8iBRH/36dm5gAl92F18q0dNn/VE9l1AAclKOeKGDRQ0kvFi0bNiPc6oVB8 ASig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=9k3Lycrr2Uds0sU98baQTH+JQ4KS14URP3HEc5BMBwY=; b=HcTMkkwkdBksg3JDE2xEjyMrmwIxSJl+3MPDGNADxuv4Oa+g3bhibgncFlMnHZYPpH 0P6cRND/B1APz692dshgju5lue8EODlW9LRLOHHDMcWY34nHWjJh9ubXHCCb36VjVV3Y +wAb0OStzdvK4tcmlQ2ALG/X2aavaUto5gSO2iOkkrnPlTy6zx3/U9Szl2xAPvmVj/N2 02Hqrl81Xy/5z7zKIj15jw1pDzNyJyvGdKcnzCCj8Sj/WtTO3uB2bfByQnFGLAhDj9oy N7TEnmo/0zwq1nefaUSxhbgal6KdLmtWxxQbjgXejH7Q89SU2SIjagvJZpDRXqdHXxK+ uYpw== X-Gm-Message-State: APf1xPCiW3C4H3HMrWkPcC/P9rFi5jDwJvNMuMWNVh9pPHILd0hq/h9w ogEtpjPqfPrxlG71//DKm55kuJ17c39zZognPYU= X-Google-Smtp-Source: AG47ELvHDQVDxxO7Knqa9rR2of5oO7bscSdAdf73rRQH5lWXlom4G/z3aVeWUfLe2Hz5DCiaLYPWUFRZOY3AidDgxtw= X-Received: by 10.202.168.199 with SMTP id r190mr11149358oie.180.1519793633503; Tue, 27 Feb 2018 20:53:53 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Tue, 27 Feb 2018 20:53:52 -0800 (PST) From: Phillip Hallam-Baker Date: Tue, 27 Feb 2018 23:53:52 -0500 X-Google-Sender-Auth: jcpM6qLWD7Tg2dZLRLxmvHULvgg Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113cd4b6a82e0305663e873f" Archived-At: Subject: [MLS] Are people open to a different approach to the cryptography? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 04:53:57 -0000 --001a113cd4b6a82e0305663e873f Content-Type: text/plain; charset="UTF-8" I agree that perfect forward secrecy is sometimes a requirement. But it isn't always a requirement and sometimes the requirement may be to create a static record of a conversation. For example, this conversation we are having now. We might well want to make it private but have a permanent record so if we admit a new person to the group, they can read the previous material. For the past couple of years I have been working on multi-key approaches to cryptography based on work by Matt Blaze and Torben Pederssen. The approach is based on the fact that we can do math on Diffie Hellman Keys and results. If you add two discrete log private keys, the public key corresponding to the result is the product of the corresponding public keys. x + y = z e^x . e^y = e^(x+y) = e^z What I have designed the key agreement for my chat protocol to support is the case in which all communication to the group is encrypted under a group encryption key and the decryption key is split differently for each member of the group by an administrator. I am pretty sure I can add PFS into the agreement. But I would need to understand the requirements a bit better first. --001a113cd4b6a82e0305663e873f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= gree that perfect forward secrecy is sometimes a requirement. But it isn= 9;t always a requirement and sometimes the requirement may be to create a s= tatic record of a conversation.

For example, this conversation we are having now. We might well want= to make it private but have a permanent record so if we admit a new person= to the group, they can read the previous material.


For the past couple of years I have been working on multi-= key approaches to cryptography based on work by Matt Blaze and Torben Peder= ssen.

The approach is bas= ed on the fact that we can do math on Diffie Hellman Keys and results.

If you add two discrete log p= rivate keys, the public key corresponding to the result is the product of t= he corresponding public keys.

x + y =3D z
e^x . e^y =3D e^(x+y) =3D e^z


Wha= t I have designed the key agreement for my chat protocol to support is the = case in which all communication to the group is encrypted under a group enc= ryption key and the decryption key is split differently for each member of = the group by an administrator.

I am pretty sure I can add PFS into the agreement. But I would need t= o understand the requirements a bit better first.

--001a113cd4b6a82e0305663e873f-- From nobody Wed Feb 28 07:16:45 2018 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 D454112EB0D for ; Wed, 28 Feb 2018 07:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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=symbolic.software header.b=d/MxuFyw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nCzJjfHD 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 gWbci0n794lY for ; Wed, 28 Feb 2018 07:16: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 00E8A12EB0C for ; Wed, 28 Feb 2018 07:16:41 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1DDFA21238; Wed, 28 Feb 2018 10:16:41 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 28 Feb 2018 10:16:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AKSBN6 xIN+3565dZ+ptbnc+j8RvcL/Lk7C3sNr7+yQU=; b=d/MxuFywglxtrsE9f4x6+O 4MrSs+fZsX79wZli8T62fke5U+CCB/SQhrUAl7XT/6CZF8WJELq0o4FZe8mSo9uR AqGnk+7wcd6tZzH6Hdrrvb71V9ElUNVDWE1xSW0o0dQaAe9+jJ73khyw7BzYcd3z BSOsIzyE6S85OO3C0pI3mWfBHtDMIGM9YUTg9sag+EYnbhrMGeQZjTJcNkgjlCq7 lgVy/QW/LYRS6BykcYX2nH/ImRfbMxViJ5Of/g5WMtFOyTeDTvPx5yHjAyNakw7x ayoukxhkNru/GNFNOPlz/A7/usWMWp4nsEwf5d6HCi6WkZBbeDPZ+P+jk9qp3SUg == 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-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AKSBN6 xIN+3565dZ+ptbnc+j8RvcL/Lk7C3sNr7+yQU=; b=nCzJjfHD2h1UOe27gOBJ+C 3hd76UEAgEuumMo62Q5xp/5hEBj0H/zLSmCwkP9C2tPfegZaXDMDZ+zokmdNBaX6 0KK2lz4A+rVP3XiPTFX4fINLG76eH3hR3u2W8xRWNdYoQ1GkIc414S70sawH2krO jRvjuysPe/tquwk+4unyxwuRSGDySywoTQfuZuPwuC1+SAQdmSC/E+DAHX6OVjDA Okkwz/mii+nvyZiNDl5nfKjcTxX5qDF/FxSrsxntn6y7RdD22QKGkjsrv7R71bt8 kKWPi13tPAmvaSnHNXwp5DUXt5pjLgSGmero0h83gZVofEiiKsjdTnL/+dyJOKXA == X-ME-Sender: Received: from nadims-macbook.home (lfbn-1-478-154.w86-245.abo.wanadoo.fr [86.245.184.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 657DB24802; Wed, 28 Feb 2018 10:16:40 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Nadim Kobeissi In-Reply-To: <1519740340.1025773.1285066592.29F98648@webmail.messagingengine.com> Date: Wed, 28 Feb 2018 16:16:38 +0100 Cc: Eric Rescorla , mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A8A9711-43B8-45A2-B535-D89A445BAD37@symbolic.software> References: <1519725212.924168.1284819432.01A6E695@webmail.messagingengine.com> <1519740340.1025773.1285066592.29F98648@webmail.messagingengine.com> To: Katriel Cohn-Gordon X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MLS] small subgroup validation X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 15:16:44 -0000 Perhaps we could restrict curve-based primitives to those that do not = require expensive validation? Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office > On Feb 27, 2018, at 3:05 PM, Katriel Cohn-Gordon = wrote: >=20 > I'm not an expert on small subgroup attacks in ECC so wanted to make = sure we had thought it through fully, particularly where we reason about = what invalid points an adversary can send, and where we state our = assumptions on primitives. >=20 > That is to say, the current text may well be enough, I just wanted to = flag it up :) >=20 > Katriel >=20 >=20 > On Tue, 27 Feb 2018, at 1:53 PM, Eric Rescorla wrote: >> The current drafts do require some validation, borrowed from Matt = Green's contributed text to TLS 1.3. >>=20 >> = https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.1 >> = https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-6.1.2 >>=20 >> I haven't gone through this in detail in a while. Perhaps it's = insufficient? Or were you just making the general point that we should = state it for new curves? >>=20 >> -Ekr >>=20 >>=20 >> On Tue, Feb 27, 2018 at 1:53 AM, Katriel Cohn-Gordon = wrote: >> Hi all, >>=20 >> We should probably consider small subgroup attacks more carefully in = the threat analysis and the draft documents. >>=20 >> Specifically, computational proofs often implicitly assume point = validation, which is particularly important in the case that a malicious = group member sends an invalid copath element. I think the draft should = state that point validation is required on all received group elements = (unless using a group that doesn't require it); if I understand = correctly this will cost roughly an additional exponentiation for each = check, so O(log(n)) for a new and untrusted copath. >>=20 >> [This was pointed out by Dennis Jackson.] >>=20 >> best, >> Katriel >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 28 09:14:21 2018 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 603BD1242F5 for ; Wed, 28 Feb 2018 09:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoYSdX5YeVMq for ; Wed, 28 Feb 2018 09:14:19 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 C12CE12D7F1 for ; Wed, 28 Feb 2018 09:14:18 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id y19so4631828lfd.4 for ; Wed, 28 Feb 2018 09:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=dUsb+ECJfrlq+eSCCv3r4C16AffIJg/DqXdUQQ9X/tc=; b=RJzS8qzwEvlbZWD1W7IdM5GLsfvcnC5+viPcaBTZpNQMxffQ9/AWCnL+Zr05i4fMPK hKWTRjdAwL7D3bSfPrvcoHpEwmH2NqIclXr88G5UXCBynAyOqg8BR4AvfY3JRGMkXFDu Y73DXALxE7uxwwmPrCVZsYEyTPJJ3pxmuJhnc= 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=dUsb+ECJfrlq+eSCCv3r4C16AffIJg/DqXdUQQ9X/tc=; b=WSTqqu5UtgTLCs50BEjKOu+mx7E8kXtss9F6/2evCKli2pgZfVukc/g7AOTIdgpWVD ZqejnqVYsV4sfM/ZRt9gMOwWq85xaBqTZWF6HhLi1L3i71Mk01QvnkfrquyrqsPWazPl BDuZ+WkhNkzXFHZ2T2+HGSxeFQMZFmjnp7vC9V1E3kkGKQbFQWBplchZ8Kg2GzqSP/i+ oSN4mr3bezZ0a6Oo8Yi/LUGfQgelUwPynv2Ch4W0nK5XnifxpxqgrR840hBiD5REOaYm w8VNIAXFBVp6nqcaEUQcLon+Eja3GAQEX5HJwGcM/rJRDS25rdhfYT9eEFBQWmh1aMmH ShLg== X-Gm-Message-State: APf1xPA04OEerRt6MligC9e3eMXzizcbQcQGKa6OPAbrEaUTxBuQ2ael JZZ3gqctl5TeqSqSjRgK7ORoH5c5DU6zlSFwPA7lU1+T X-Google-Smtp-Source: AG47ELudBw9IUcneW/zGyNhr6WRWFGC2E+Ah0+hE/Zlwb/LyqrbYdRDKmUjwiWbm9kdfRxe4OwoK/PtZ2iErthCbIJc= X-Received: by 10.46.13.10 with SMTP id 10mr14323624ljn.8.1519838056750; Wed, 28 Feb 2018 09:14:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.7 with HTTP; Wed, 28 Feb 2018 09:14:16 -0800 (PST) From: Dave Cridland Date: Wed, 28 Feb 2018 17:14:16 +0000 Message-ID: To: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:14:20 -0000 Hi folks, While I'm really pleased to see MLS, and I generally like the idea of Forward Secrecy, there's a couple of use cases where it might be worth avoiding. Feel free to correct me if these are in fact possible with Forward Secrecy. Both these relate to archival access to past messages: * UX - Some users (actually all of them) would like to be able to install client software on a new device and have their historical messages available to them. Most "business" messaging systems seem to work this way, as well as a number of consumer-grade systems. The nature of Forward Secrecy means that an archive would need to be held on one device and re-sent to another through the network, which is trickier to manage, and is reliant on multiple devices being online at overlapping times. Alternately, the archival copy might be re-uploaded to the server using a static encryption key, I suppose, which would rather spoil the point. * Retention - Many business and government deployments have mandatory retention requirements. An example is MIKEY-SAKKE, promoted in part by the UK Government for its own communications, which uses mandatory key escrow to keep an archived copy of the messages accessible to the business units involved. An advantage of the SAKKE system is that it allows the key escrow to be offline, limiting attack opportunities. Given the latter, for example, I could not use an MLS-based system to discuss a tax problem with the authority, and since I'm unlikely to have a SAKKE-based messaging client, I'm unlikely to have encrypted messaging to my tax authority at all - which seems signficantly worse than merely having no Forward Secrecy. None of this is to say that Forward Secrecy should be avoided entirely, of course. Dave. From nobody Wed Feb 28 09:31:33 2018 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 EAD1C12D880 for ; Wed, 28 Feb 2018 09:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 G3UlYllnO2CB for ; Wed, 28 Feb 2018 09:31:30 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 2356E1243FE for ; Wed, 28 Feb 2018 09:31:30 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id 188so6569478wme.1 for ; Wed, 28 Feb 2018 09:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=xoYxmdjEvyy9JvBM+3Ur15QJYI2SwJW2qIBl/YxsWK4=; b=0QRwZcFPp7bP1o1h74DktJHYziFr/okZPa4B3S79aMuNbEYX4kbZp4adtvi1KcCVbE 3nLX9gpCnYE82au2K9uhcmGMmrkOvCj1ZY5ZDnFNMrVe+YHzC5BRy2X7AkWUgyzCNyKq gLkCOUt1BJ8A+ETr+X058WogGzS59ARog+bl0ejLzGj6a8gM7eoZa5RFFnjAuKiQwvtu u+X1O/vHqDFffhoG/2lehPvHqQOlFRQ3W3AVOgANk1pNTxzQmYkFuxmmcT+aXL6rc3K/ GxzAoqzg03OuL8SiNlSwkjSgN+7u6t/Eyy2IvxtPpzRgps3y8qrQp1AI9aL82umVQooz y7Yw== 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=xoYxmdjEvyy9JvBM+3Ur15QJYI2SwJW2qIBl/YxsWK4=; b=APyle/7Rrz6uO8lMkdM/gkVkG1liPa8U0FvhSJV6HGxRIcFiQ5vhI7jkWBOgbImo+u XRv9owULajncs1UGG2Tx0N7B5tvI1Jpi9bDRoZ97YRzsRxfyq+7cYxLuhYpU42j6hMsg PGnEpg7r4dqbr3HdpuJRhbwB4Umv0J1RdFqACBsHEkSECMl+INsfob717DCiBv7MgrJf JkBs9Gzy6/PInrrEKOxbSzNwF14PrxN7k07PCmQng8jDJ1n5tygHx978CXKzk/OUzyjY vMb/Gg9S950HD0twYCnbBGkPmVFqcxWJCCY3Qu7v4YZlFa4VWpTvxeijt6++WI90xs85 k0hw== X-Gm-Message-State: APf1xPDmC6y9hd2PT44IKisyes7ytQYW7l8AmGelM42mjIJDitQdrdrM Z/yd/le0mBYh6S+/2RGM742aoyLEaFQ= X-Google-Smtp-Source: AG47ELspdeYYINlZpYnzsr7h/8eGXDp1ckHPNTBLUF/D04rJx3EfsP1s1GzHE0eKXEkRF8zc+ZWULA== X-Received: by 10.28.153.133 with SMTP id b127mr13964347wme.105.1519839088015; Wed, 28 Feb 2018 09:31:28 -0800 (PST) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id g52sm4617109wra.20.2018.02.28.09.31.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 09:31:26 -0800 (PST) From: Raphael Robert Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Feb 2018 18:31:25 +0100 References: To: mls@ietf.org In-Reply-To: Message-Id: <33211538-1DA2-4B42-A3BD-A6AD248C907A@wire.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 17:31:32 -0000 Hi Dave, Mandatory retention and UX are valid points of course. The scope of MLS = is however to provide strong security guarantees like FS on the other = hand. Re-using the same encryption key is something applications that = use MLS can on the layer above the messaging protocol: the = =E2=80=9Capplication layer=E2=80=9D. This would allow application = developers to take that decision independently for the specific use = cases they want to cater for. Raphael > On 28 Feb 2018, at 18:14, Dave Cridland wrote: >=20 > Hi folks, >=20 > While I'm really pleased to see MLS, and I generally like the idea of > Forward Secrecy, there's a couple of use cases where it might be worth > avoiding. Feel free to correct me if these are in fact possible with > Forward Secrecy. Both these relate to archival access to past > messages: >=20 > * UX - Some users (actually all of them) would like to be able to > install client software on a new device and have their historical > messages available to them. Most "business" messaging systems seem to > work this way, as well as a number of consumer-grade systems. The > nature of Forward Secrecy means that an archive would need to be held > on one device and re-sent to another through the network, which is > trickier to manage, and is reliant on multiple devices being online at > overlapping times. Alternately, the archival copy might be re-uploaded > to the server using a static encryption key, I suppose, which would > rather spoil the point. >=20 > * Retention - Many business and government deployments have mandatory > retention requirements. An example is MIKEY-SAKKE, promoted in part by > the UK Government for its own communications, which uses mandatory key > escrow to keep an archived copy of the messages accessible to the > business units involved. An advantage of the SAKKE system is that it > allows the key escrow to be offline, limiting attack opportunities. >=20 > Given the latter, for example, I could not use an MLS-based system to > discuss a tax problem with the authority, and since I'm unlikely to > have a SAKKE-based messaging client, I'm unlikely to have encrypted > messaging to my tax authority at all - which seems signficantly worse > than merely having no Forward Secrecy. >=20 > None of this is to say that Forward Secrecy should be avoided > entirely, of course. >=20 > Dave. >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Feb 28 10:18:46 2018 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 BDC6F1201F2 for ; Wed, 28 Feb 2018 10:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqgojLv3MTsb for ; Wed, 28 Feb 2018 10:18:42 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 B7F871200E5 for ; Wed, 28 Feb 2018 10:18:42 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id c18so2477766oiy.9 for ; Wed, 28 Feb 2018 10:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZsI3SJCWo1Num5xYe7kF70yyF3eUW3U+fE/aCLwB3j8=; b=T5JIi2ZrOBK8slQZT9GDh60ZZXfRdSv4WUXfNNWRKCb95MeITJ9Ukh3JiasiMfQef8 Tfi7TSNhHqDvMrlMq1ioVh9ec3Ttz1orWvKKuQfxmA7MSU6EPnY+hH8+S+AYFKUmzqmg /FOg1mbLpbwxQXVTwZjGrPP/121Vxao3eS07Z0g1M7RWIlLhMbmF3U6mJI8pT0diHs+N H7ShJiqPr28/HItGVRtPoz7ILDzm1pdAuYdyrDx/K0BUC3G5MS+bl0jJwvZguSrs7qwk AI/gSibWy/ShERzuKDDDbf+MJ2rCWvvGj/3yhQHdu+INgB9y6jObPy9rjjB+5gP0NDhA XYUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZsI3SJCWo1Num5xYe7kF70yyF3eUW3U+fE/aCLwB3j8=; b=qtqmSVhad+mMbbX1dtU4pnwhNf0PeFjReIk6fU++Um0D7pHiekNoY9X/9HcmblUsir Y6hvCDBLr7AUtQxAgn+aIKJwvwD1ioCCMB2p8dZ357gl4qNjbyPNf+K6Qw2LotjjaUnT MfFQ+Qly69hyAYX5AzxBBrcYYwl/2sd4B7pD4Wsxk5bgnu2x7+6IETTC6LbBMSYLak+i 2PE/bievh3IIDn7/pl6nJsssb9kOhvECVPHaRHXwEezHiHpUCdfOPg1hfCzGTv6rSMSu MO9/2il2uM77Vpvlv87KQYQHrCLs/HTI2uqcghZd/IfzzBQZVpn+bzx8BBRNqSy6Vklq g9XA== X-Gm-Message-State: APf1xPBJ/iMvMkbIhvO3KRRPzh/vBcX3hOS4DeUMbP/lor0IP4hNO/ql OCkMrQLYN9vfIGiddPiQGY20KCu1ZOPm8GHZVLA= X-Google-Smtp-Source: AG47ELt+ZeBVYpwjal/vugkstFfVR6wL60p5GFxtWaYJa4rg7Ux7gxzGL0FKN2/nnOd25nIL9viIzO0RSkdgZmNWHbI= X-Received: by 10.202.64.131 with SMTP id n125mr12437864oia.26.1519841922117; Wed, 28 Feb 2018 10:18:42 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 10:18:41 -0800 (PST) In-Reply-To: <33211538-1DA2-4B42-A3BD-A6AD248C907A@wire.com> References: <33211538-1DA2-4B42-A3BD-A6AD248C907A@wire.com> From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 13:18:41 -0500 X-Google-Sender-Auth: JLqu49zaFj1jV749mmv0JJTo46U Message-ID: To: Raphael Robert Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113de014e1f519056649c582" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 18:18:44 -0000 --001a113de014e1f519056649c582 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BThe scope of the proposal, you mean. MLS is not chartered yet. We are discussing what the scope should be. It is really inappropriate to assert that has been decided before we have met to even discuss what the scope should be.=E2=80=8B Having been involved in the IPSEC effort and seen where the insistence on 'strong security guarantees' led there, I want to see every security requirement backed by a use case. Because what happened with IPSEC was we ended up with a protocol that did not work in the real world because it had been intentionally designed to be hostile to NAT and did not address a long list of real world security issues. On Wed, Feb 28, 2018 at 12:31 PM, Raphael Robert wrote: > Hi Dave, > > Mandatory retention and UX are valid points of course. The scope of MLS i= s > however to provide strong security guarantees like FS on the other hand. > Re-using the same encryption key is something applications that use MLS c= an > on the layer above the messaging protocol: the =E2=80=9Capplication layer= =E2=80=9D. This > would allow application developers to take that decision independently fo= r > the specific use cases they want to cater for. > > Raphael > > > On 28 Feb 2018, at 18:14, Dave Cridland wrote: > > > > Hi folks, > > > > While I'm really pleased to see MLS, and I generally like the idea of > > Forward Secrecy, there's a couple of use cases where it might be worth > > avoiding. Feel free to correct me if these are in fact possible with > > Forward Secrecy. Both these relate to archival access to past > > messages: > > > > * UX - Some users (actually all of them) would like to be able to > > install client software on a new device and have their historical > > messages available to them. Most "business" messaging systems seem to > > work this way, as well as a number of consumer-grade systems. The > > nature of Forward Secrecy means that an archive would need to be held > > on one device and re-sent to another through the network, which is > > trickier to manage, and is reliant on multiple devices being online at > > overlapping times. Alternately, the archival copy might be re-uploaded > > to the server using a static encryption key, I suppose, which would > > rather spoil the point. > > > > * Retention - Many business and government deployments have mandatory > > retention requirements. An example is MIKEY-SAKKE, promoted in part by > > the UK Government for its own communications, which uses mandatory key > > escrow to keep an archived copy of the messages accessible to the > > business units involved. An advantage of the SAKKE system is that it > > allows the key escrow to be offline, limiting attack opportunities. > > > > Given the latter, for example, I could not use an MLS-based system to > > discuss a tax problem with the authority, and since I'm unlikely to > > have a SAKKE-based messaging client, I'm unlikely to have encrypted > > messaging to my tax authority at all - which seems signficantly worse > > than merely having no Forward Secrecy. > > > > None of this is to say that Forward Secrecy should be avoided > > entirely, of course. > > > > Dave. > > > > _______________________________________________ > > 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 > --001a113de014e1f519056649c582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8BThe scope of the proposal, you mean.

MLS is not chartered yet. We are discussing what the scop= e should be. It is really inappropriate to assert that has been decided bef= ore we have met to even discuss what the scope should be.=E2=80=8B

Having been involved in the IPSEC= effort and seen where the insistence on 'strong security guarantees= 9; led there, I want to see every security requirement backed by a use case= . Because what happened with IPSEC was we ended up with a protocol that did= not work in the real world because it had been intentionally designed to b= e hostile to NAT and did not address a long list of real world security iss= ues.

=

On Wed, Feb= 28, 2018 at 12:31 PM, Raphael Robert <raphael@wire.com> wrot= e:
Hi Dave,

Mandatory retention and UX are valid points of course. The scope of MLS is = however to provide strong security guarantees like FS on the other hand. Re= -using the same encryption key is something applications that use MLS can o= n the layer above the messaging protocol: the =E2=80=9Capplication layer=E2= =80=9D. This would allow application developers to take that decision indep= endently for the specific use cases they want to cater for.

Raphael

> On 28 Feb 2018, at 18:14, Dave Cridland <dave@cridland.net> wrote:
>
> Hi folks,
>
> While I'm really pleased to see MLS, and I generally like the idea= of
> Forward Secrecy, there's a couple of use cases where it might be w= orth
> avoiding. Feel free to correct me if these are in fact possible with > Forward Secrecy. Both these relate to archival access to past
> messages:
>
> * UX - Some users (actually all of them) would like to be able to
> install client software on a new device and have their historical
> messages available to them. Most "business" messaging system= s seem to
> work this way, as well as a number of consumer-grade systems. The
> nature of Forward Secrecy means that an archive would need to be held<= br> > on one device and re-sent to another through the network, which is
> trickier to manage, and is reliant on multiple devices being online at=
> overlapping times. Alternately, the archival copy might be re-uploaded=
> to the server using a static encryption key, I suppose, which would > rather spoil the point.
>
> * Retention - Many business and government deployments have mandatory<= br> > retention requirements. An example is MIKEY-SAKKE, promoted in part by=
> the UK Government for its own communications, which uses mandatory key=
> escrow to keep an archived copy of the messages accessible to the
> business units involved. An advantage of the SAKKE system is that it > allows the key escrow to be offline, limiting attack opportunities. >
> Given the latter, for example, I could not use an MLS-based system to<= br> > discuss a tax problem with the authority, and since I'm unlikely t= o
> have a SAKKE-based messaging client, I'm unlikely to have encrypte= d
> messaging to my tax authority at all - which seems signficantly worse<= br> > than merely having no Forward Secrecy.
>
> None of this is to say that Forward Secrecy should be avoided
> entirely, of course.
>
> Dave.
>
> _______________________________________________
> 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

--001a113de014e1f519056649c582-- From nobody Wed Feb 28 13:16:33 2018 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 2E6A3124BE8 for ; Wed, 28 Feb 2018 13:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5GAazrV_obx for ; Wed, 28 Feb 2018 13:16:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555F51201FA for ; Wed, 28 Feb 2018 13:16:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00E08BE2F; Wed, 28 Feb 2018 21:16:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpvdlVLYojcq; Wed, 28 Feb 2018 21:16:25 +0000 (GMT) Received: from [10.200.0.239] (unknown [193.180.218.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 75C2ABDF9; Wed, 28 Feb 2018 21:16:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1519852585; bh=0jBJXs6Z62yuzYZw3Oaxt62QT1N2H63C5KKh15Id+xM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DVsuwycTpyfDB/STssHripZw5AAfQd+hZkvGrdWCfkyX5yPevOQ9N7GXRWArTauez e5IaN39howUrLuVkbnw37ebJwriOmVl4a694wNJneKBRe9oR/dXcNqyWqxX4F4Yekx kf02qEiRx02AACGJ9LXrH706J600pL5J1uDILh+k= To: Dave Cridland , mls@ietf.org References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Wed, 28 Feb 2018 21:16:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B1kKW3RVGPOYQybvujMoLCapPyOhqvnQo" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:16:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B1kKW3RVGPOYQybvujMoLCapPyOhqvnQo Content-Type: multipart/mixed; boundary="U3vuPcgt5LxFoVd0lbYZRQIiQkEUWpO5s"; protected-headers="v1" From: Stephen Farrell To: Dave Cridland , mls@ietf.org Message-ID: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy References: In-Reply-To: --U3vuPcgt5LxFoVd0lbYZRQIiQkEUWpO5s Content-Type: multipart/mixed; boundary="------------F9E8A19998C5AA54906CCE68" Content-Language: en-GB This is a multi-part message in MIME format. --------------F9E8A19998C5AA54906CCE68 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/18 17:14, Dave Cridland wrote: > Given the latter, for example, I could not use an MLS-based system to > discuss a tax problem with the authority, and since I'm unlikely to > have a SAKKE-based messaging client, I'm unlikely to have encrypted > messaging to my tax authority at all - which seems signficantly worse > than merely having no Forward Secrecy. Sorry, why is transport layer security not sufficient between you and your tax authority? I'm unclear as to why the security guarantees (aimed for) between groups of people ought be reduced in order to meet the goals of securing communications between a person and a service provider. I do agree that it'd be good if a user of some application could add a new device and still see old messages, but I'm not at all clear that's that significant (for the crypto) since people will always need to have some kind of fallback to handle cases where they've lost state. S. --------------F9E8A19998C5AA54906CCE68 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------F9E8A19998C5AA54906CCE68-- --U3vuPcgt5LxFoVd0lbYZRQIiQkEUWpO5s-- --B1kKW3RVGPOYQybvujMoLCapPyOhqvnQo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJalxwoAAoJEFqy+vF7FyvqNMIP/00x7ESJk6KFnOXXK84iZ9AG wRiMLIymR38MtC8jfrWjFzV2Hp10dHRx0lJm2FyHj9UfAdvhf5b5O1HsC1ZRcTv9 kyyew+Yh9aw9vHhhZBH+tpi+5L/A7ZWZZmy5s7ixkVEnsDvarmT1ADag+6YQFWGq /5fd3cYDYsdhVAuTOHEJB/wN/R8ZRsPZqOHpjy/wqPfYcedo7b04G7sRxU1nEWvA VpE/AWttTWQgZmmOJP3Bm6/cA5rA42kz3F6xuZiEInoFBmhLniAcW5MipA7HSc7m MPYn5H5t79lJ3CUo2UNc59J74eXjbBFGNJc1YE9cKgr8RfG64h4ON2u1CeTy1wP4 Q/puVhMWMVK/0yepFR0AZZuobk5NqiOsq7+OQ0Q5+/J4VmFVmEqKR6QeX7DYUM84 zCw6a+zYJlzkT0x9GyQFoaTF9bxU4RQTiNA8ksTziqAOifztN1FfZf5psRPrbzxn vuWPVJvDcw9wOVKcLf9gOpjIVZa55LdEJUORv5ISoUEpnjHLtnC+4t8NsBixAwX0 rnU0j9tlvXqUmdsf7h1V+TmGfC06i1cpDVRgozwVxhXxo3c2bO/8Yo+iPOISVLg9 hwyW0cVtCB6doJZuprV7Fk39TrWgh4qDNDxl+/GqqM5xWMED5yafiF4xqf5xZ7LP myMW5oXNs6aywF1nMwrO =OQZ6 -----END PGP SIGNATURE----- --B1kKW3RVGPOYQybvujMoLCapPyOhqvnQo-- From nobody Wed Feb 28 13:58:54 2018 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 37530126D73 for ; Wed, 28 Feb 2018 13:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thWzNRv7qTjw for ; Wed, 28 Feb 2018 13:58:52 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 1211E126CF9 for ; Wed, 28 Feb 2018 13:58:51 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id y11so3732353otg.0 for ; Wed, 28 Feb 2018 13:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eL1PoaqXggE6hwZbO0m37+5W0gk73c38m1a8jiqNMr0=; b=FZC6zxUaclEJOPMsPTumoOAubBhoqUHYcf2v6o598LtVnj11zN+VCqGtjzXermB1wh 9p7J62C3K+DNdIWfaBnzstZpRUDtzkwmSonIWMjA3k35THuc9+G/lfYrym7Y9vF5ZkSv lIOYeWl0YazZQZesjgz9FtiYRFmT6d5YL4sSoI6S9T3Rjb1Bs+ciUdJkJ2ovYfBdv7Z0 BzTD4pQaHzWu+naXvCKVXkQg0XK/IFu1HH/MyWMerLhxeg7xqM8bKjrwPm6jSiBhyMlm B91dq5WnC11TvJ2D8wJVwbazPom3az0Gs8dVhDPN2/ffMRfDnpRDEQCppJCX9F/Cp6ma ueSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eL1PoaqXggE6hwZbO0m37+5W0gk73c38m1a8jiqNMr0=; b=BbrIfbSP4A0Hdzqml0P3Bsn934z7O6aqTN5i9yDzH4SfA7B8XrzjBA63YeqweHJJw5 eleBCkSCjdPAfaM8XAQgf3OoRnDmbppwtU38nmtTFWarbjKElRHG7wHOxYd5iGbChdz/ y3LmUUIMMeSa5GKeC+kwyTFmyLzahkiDDxwPz/z4WMt4q1mHgflQSYBuriRPYKFNYvZT 4137kD34kWl//A87BNrDmia/QzWAf6Yjtw5sKCRnKv+HamQ75tyeXt3K9PfU1yi7zUeD HL4Adz4nNYUvHe5ZOuPggtRd0LBbqRrjiP/0NtkigYlsfWMGwUKO+3BWzqHD+QN7BnMk v8bg== X-Gm-Message-State: APf1xPB5FxxQH0YS8AugpuIKlVUjBgYcC3od0E3VrFio4e+dkpIyOtAI ImvlvJdT90jRMkv6nuoOvE5NYpxwbKequC+FB9E= X-Google-Smtp-Source: AG47ELsFmhULVPwevaYrigCXZCu/5bWJjdTzwJEIYDiLfU/iyWQSy+mbulrEy5+70GWEWszC1SQY/ZEUO1Jjv2srvYw= X-Received: by 10.157.3.196 with SMTP id f62mr14706800otf.360.1519855131102; Wed, 28 Feb 2018 13:58:51 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 13:58:50 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 16:58:50 -0500 X-Google-Sender-Auth: A2qobZNC046UFi7A6hoJwW4b7J4 Message-ID: To: Stephen Farrell Cc: Dave Cridland , mls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c03c32633150e05664cd90c" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 21:58:53 -0000 --94eb2c03c32633150e05664cd90c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell wrote: > > Hiya, > > On 28/02/18 17:14, Dave Cridland wrote: > > Given the latter, for example, I could not use an MLS-based system to > > discuss a tax problem with the authority, and since I'm unlikely to > > have a SAKKE-based messaging client, I'm unlikely to have encrypted > > messaging to my tax authority at all - which seems signficantly worse > > than merely having no Forward Secrecy. > > Sorry, why is transport layer security not sufficient between you > and your tax authority? > > I'm unclear as to why the security guarantees (aimed for) between > groups of people ought be reduced in order to meet the goals of > securing communications between a person and a service provider. > > I do agree that it'd be good if a user of some application could > add a new device and still see old messages, but I'm not at all > clear that's that significant (for the crypto) since people will > always need to have some kind of fallback to handle cases where > they've lost state. =E2=80=8BI posted a use case in which I do not want forward secrecy earlier= . Alice works in a team with Bob and Carol. At some point Doug joins the team. At that point, Doug needs access to all documents and discussions related to the project, including: * All Word, Powerpoint, etc. documents. * All Web sites and discussion forums. * All group chats, video conferences, etc.=E2=80=8B =E2=80=8BI have a system that can support this use case with end to end enc= ryption. Mallet can run all the online services. The only time an administration key is required is when people are added to or removed from the group. Using the term 'reduced' in relation to security properties is pejorative and unhelpful. If we are having a discussion related to a project there will be times when: 1) We want the discussion to be off the record with no permanent record. 2) We want the discussion to be on the record with a permanent record. =E2=80=8BThese are disjoint use cases and they are both valid. =E2=80=8BThe= y are even valid for different discussions relating to a single project. If we are working at the Transport layer, our conversation is always synchronous and PFS does not constrain us. If however we are working at the message layer, we will often want to support an asynchronous mode in which one party sends some data and another picks it up later. That does not prevent us working end to end but it does prevent us using PFS. --94eb2c03c32633150e05664cd90c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Fe= b 28, 2018 at 4:16 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie<= /a>> wrote:

Hiya,

On 28/02/18 17:14, Dave Cridland wrote:
> Given the latter, for example, I could not use an MLS-based system to<= br> > discuss a tax problem with the authority, and since I'm unlikely t= o
> have a SAKKE-based messaging client, I'm unlikely to have encrypte= d
> messaging to my tax authority at all - which seems signficantly worse<= br> > than merely having no Forward Secrecy.

Sorry, why is transport layer security not sufficient between you and your tax authority?

I'm unclear as to why the security guarantees (aimed for) between
groups of people ought be reduced in order to meet the goals of
securing communications between a person and a service provider.

I do agree that it'd be good if a user of some application could
add a new device and still see old messages, but I'm not at all
clear that's that significant (for the crypto) since people will
always need to have some kind of fallback to handle cases where
they've lost state.

=E2=80=8BI posted a use case in which I= do not want forward secrecy earlier.

Alice works in a team with Bob and Carol. At some point Doug j= oins the team. At that point, Doug needs access to all documents and discus= sions related to the project, including:

* All Word, Powerpoint, etc. documents.
* All Web sites and discussion for= ums.
* All grou= p chats, video conferences, etc.=E2=80=8B

=E2=80=8BI have a system that= can support this use case with end to end encryption. Mallet can run all t= he online services. The only time an administration key is required is when= people are added to or removed from the group.

Using the term 'reduced' in relation to secu= rity properties is pejorative and unhelpful. If we are having a discussion = related to a project there will be times when:

1) We want the discussion to be off the record with n= o permanent record.
2)=C2=A0We want the discussion to be on the = record with a permanent record.

=E2=80=8BThese are disjoint use cases and they are both valid. =E2=80=8BTh= ey are even valid for different discussions relating to a single project.

=
If we are worki= ng at the Transport layer, our conversation is always synchronous and PFS d= oes not constrain us. If however we are working at the message layer, we wi= ll often want to support an asynchronous mode in which one party sends some= data and another picks it up later. That does not prevent us working end t= o end but it does prevent us using PFS.



--94eb2c03c32633150e05664cd90c-- From nobody Wed Feb 28 14:28:20 2018 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 3D3DF126FB3 for ; Wed, 28 Feb 2018 14:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eK1o9O5bRDUc for ; Wed, 28 Feb 2018 14:28:14 -0800 (PST) Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) (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 55C5C126B6D for ; Wed, 28 Feb 2018 14:28:14 -0800 (PST) Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay14.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1erACf-0003E6-jM; Wed, 28 Feb 2018 22:28:12 +0000 Received: from sth-1.gradacc.ox.ac.uk ([192.76.28.109] helo=T-200) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1erACe-000CdC-MC; Wed, 28 Feb 2018 22:28:00 +0000 Date: Wed, 28 Feb 2018 22:28:00 +0000 From: Dennis Jackson To: mls@ietf.org Message-ID: <20180228222800.0a978ded@T-200> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Oxford-Username: exet4027 X-Oxmail-Spam-Status: score=-0.0 tests=T_RP_MATCHES_RCVD -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:28:17 -0000 > If however we are working at the message layer, we will often want to > support an asynchronous mode in which one party sends some data and > another picks it up later. That does not prevent us working end to > end but it does prevent us using PFS. This is incorrect. You may want to review the design of Signal, or indeed the current MLS draft. > MLS is not chartered yet. We are discussing what the scope should be. > It is really inappropriate to assert that has been decided before we > have met to even discuss what the scope should be.=E2=80=8B The current proposal is designed to provide strong end to end security for group messaging, with perfect forward secrecy and post compromise security.=20 If you don't agree with those design goals, I think you might be in the wrong mailing list, as rather than being a bird of a feather, you appear to be a bird of an all together different species.=20 On Wed, 28 Feb 2018 16:58:50 -0500 Phillip Hallam-Baker wrote: > On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell > wrote: >=20 > > > > Hiya, > > > > On 28/02/18 17:14, Dave Cridland wrote: > > > Given the latter, for example, I could not use an MLS-based > > > system to discuss a tax problem with the authority, and since I'm > > > unlikely to have a SAKKE-based messaging client, I'm unlikely to > > > have encrypted messaging to my tax authority at all - which seems > > > signficantly worse than merely having no Forward Secrecy. > > > > Sorry, why is transport layer security not sufficient between you > > and your tax authority? > > > > I'm unclear as to why the security guarantees (aimed for) between > > groups of people ought be reduced in order to meet the goals of > > securing communications between a person and a service provider. > > > > I do agree that it'd be good if a user of some application could > > add a new device and still see old messages, but I'm not at all > > clear that's that significant (for the crypto) since people will > > always need to have some kind of fallback to handle cases where > > they've lost state. >=20 >=20 > =E2=80=8BI posted a use case in which I do not want forward secrecy earli= er. >=20 > Alice works in a team with Bob and Carol. At some point Doug joins the > team. At that point, Doug needs access to all documents and > discussions related to the project, including: >=20 > * All Word, Powerpoint, etc. documents. > * All Web sites and discussion forums. > * All group chats, video conferences, etc.=E2=80=8B >=20 > =E2=80=8BI have a system that can support this use case with end to end > encryption. Mallet can run all the online services. The only time an > administration key is required is when people are added to or removed > from the group. >=20 > Using the term 'reduced' in relation to security properties is > pejorative and unhelpful. If we are having a discussion related to a > project there will be times when: >=20 > 1) We want the discussion to be off the record with no permanent > record. 2) We want the discussion to be on the record with a > permanent record. >=20 > =E2=80=8BThese are disjoint use cases and they are both valid. =E2=80=8BT= hey are even > valid for different discussions relating to a single project. >=20 > If we are working at the Transport layer, our conversation is always > synchronous and PFS does not constrain us. If however we are working > at the message layer, we will often want to support an asynchronous > mode in which one party sends some data and another picks it up > later. That does not prevent us working end to end but it does > prevent us using PFS. From nobody Wed Feb 28 14:50:26 2018 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 E9E1E126FDC for ; Wed, 28 Feb 2018 14:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 GcLmvoTiSOtr for ; Wed, 28 Feb 2018 14:50:21 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 71459126FB3 for ; Wed, 28 Feb 2018 14:50:21 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id b8so3062112oib.11 for ; Wed, 28 Feb 2018 14:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=XarE2ci7Pp+WS8iTiS+mQAPQ4d3aWcB6YIZYDkcJ7Tw=; b=NdVXWa5kUWxcD/n3L3wduysjZMN3krlSC2WiwbMcLXjofiosQLDZYzbD7RGalK+Gb/ +/xP08f/4n5u42QZDOQFIjvfqPxYytkqqtUUcJhe7cgy43TuXyBaJYcu5MpawufqhiDU 9rJAHE4E5eHUzehKQPutkW163IsXXYa+qB6y9iIEG84waGN8KPCjTrwpXO7uhH5fWTMU 41pybrnN38o++bJSvRD3XGKxVVOfWx8c39DzWMjSPi3xHvyc+I2qQ9p8oHraigrUrq4h JAEUrPp/FTvc3yiAdS/h9zH82S40JXVhgiT+kRmP5JVnVuMtVGmfArvWlxpz2RDlSacE ww/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=XarE2ci7Pp+WS8iTiS+mQAPQ4d3aWcB6YIZYDkcJ7Tw=; b=RmdvG5sX8v0iv5+0jMlCmZaej2hf7Rzac2gSu07YV7R7r+NmDLstBia883vyT0ktR7 u5DFp/6bqjcoz+6p1zLqsJPNg2j52ES/xjv9yV3UgFnpmoqx4OcT6JXDUh5IjBoI1DbC WOJVvENRjoCwk3/7y/CwF5rDYr01aiK6VvtdCcOqpAvQsvU6K4QrHx3TGKKkDv7F7n8p 8Mc7DEz8tTk6JCpSquMyChC6FypfQ9lq74/CacE10NAQZ99WJ7Ecy9u7OJ/xWuJy36/E XDVrZmq6781XilvluzzUOUtWDNl+f1d63VJkxDeV8TQrogIAETcNehfecJIQH7BAlWri 6+oA== X-Gm-Message-State: APf1xPA8yz390XOZ6HGKz8dY86nwxP+TxHJFLgyAUx2ctkouGz3rwi0v UZ4pdhtPgZYTYpe1H1jRRS956NubT8hPnY++UZz1zg== X-Google-Smtp-Source: AG47ELu2HkUSmwZPwwBqWl04bOM85Jx9y5b7jV3hyzTv7BZq5yxBaDm8qXRd1+W/gfBRzrGRZLKo6nOCkxiV5sCy4aU= X-Received: by 10.202.178.11 with SMTP id b11mr11112089oif.36.1519858220188; Wed, 28 Feb 2018 14:50:20 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 14:50:19 -0800 (PST) From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 17:50:19 -0500 X-Google-Sender-Auth: mlSesIudOBnJjxH7vA0YKhtPGdw Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113cd28452d04d05664d9118" Archived-At: Subject: [MLS] A different way to do key exchange X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:50:25 -0000 --001a113cd28452d04d05664d9118 Content-Type: text/plain; charset="UTF-8" Traditional TLS uses RSA Encryption and RSA signature to perform a key exchange. Then we do a Diffie Hellman exchange. And if we want client side authentication, well blerghhh Why not just to a DH exchange? let Alice's {private, public} key be {a, A}, Bob's be {b, B} etc. A = g^a mod p B = g^b mod p etc Assume we have a directory that maps Alice->A, Bob->B etc. So using straight DH with mutual authentication, the mutually agreed key is g^ab mod p. We calculate that as A^b mod p or B^a mod p. [From this point on, I will drop the mod p] This works, but it is not great because now all messages Alice sends to Bob are encrypted under a single key. Yuk. We also have the problem that they can be decrypted using Alice's key which she might not want. If Alice doesn't need to authenticate herself to Bob, she can just generate a per-message ephemeral {x, X} and use that instead. The mutual agreed key is now g^xb. Alice uses a different x each time. And she can only decrypt the message if she decides to explicitly create a decryption blob for herself. We could use this last exchange plus a HKDF key derivation for TLS with the same properties as the original RSA exchange but more simply. It does not give us PFS though, What if we want to get that with one exchange? To get PFS, we are going to need to introduce some sort of nonce or blinding factor on Bob's side. So lets generate another keypair {y, Y} and this time we are going to ADD it to Bob's key so that the key agreement value is g^x(b+y). Alice knows x and calculates B^x . Y^x Bob knows b, y and calculates either X^(b+y) or X^b . X^y At this point we are applying Torben Pedersen's Distributed key generation scheme. And it has wondrous properties. We can perform all the operations on b in a HSM and perform the blinding factor calculation at the application level. We can even split the private key between MULTIPLE HSMs. [OK I did elide something here, you can add b+y in modular arithmetic, yes. But it is modulo the subgroup size not the prime. This is p-1 for DH and (p-1)/8 for our CFRG curves.] OK so now what if we want to perform client side authentication and involve Alice's credential {a, A} ? Easy, the key agreement value is now g^(a+x)(b+y) So here we have one key agreement function that lets us add in or remove PFS according to whether or not we require it for a particular set of messages. We can even turn PFS on in the middle of an existing conversation or turn it off just by dropping the blinding factor out of the mix (or not). Want three way key agreement? g^(a+x)(b+y)(c+z) Want it in ECC? yes, it all works in Ed25519 or Ed448. It will also work in Curve 25519 and Curve 448 if someone can point me to a routine to perform addition of two Montgomery points in the compressed representation. The HSM compartmentalization could be a way to defeat the Spectre and Meltdown attacks. I showed some of this in a preview of my RSA talk on this. All I need is for the CPU manufacturer to provide us with an isolated core to perform x25519 and x448 operations. The information from that core can then be used to apply a blinding factor to crypto operations at the application level. There is a simple proof that this approach is secure if the underlying DH scheme is. --001a113cd28452d04d05664d9118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tra= ditional TLS uses RSA Encryption and RSA signature to perform a key exchang= e. Then we do a Diffie Hellman exchange. And if we want client side authent= ication, well blerghhh

Why not just= to a DH exchange?

let Al= ice's {private, public} key be {a, A}, Bob's be {b, B} etc.

A =3D g^a mod p
B = =3D g^b mod p
etc
<= div class=3D"gmail_default" style=3D"font-size:small">
Assume we have a directory tha= t maps Alice->A, Bob->B etc.

So using straight DH with mutual authentication, the mutually ag= reed key is g^ab mod p. We calculate that as A^b mod p or B^a mod p.
<= div class=3D"gmail_default" style=3D"font-size:small">
[From this point on, I will dr= op the mod p]
<= br>
This works,= but it is not great because now all messages Alice sends to Bob are encryp= ted under a single key. Yuk. We also have the problem that they can be decr= ypted using Alice's key which she might not want.

If Alice doesn't need to authenticate hers= elf to Bob, she can just generate a per-message ephemeral {x, X} and use th= at instead. The mutual agreed key is now g^xb. Alice uses a different x eac= h time. And she can only decrypt the message if she decides to explicitly c= reate a decryption blob for herself.

We could use this last exchange plus a HKDF key derivation for = TLS with the same properties as the original RSA exchange but more simply. = It does not give us PFS though, What if we want to get that with one exchan= ge?

<= div class=3D"gmail_default" style=3D"font-size:small">
To get PFS, we are going to ne= ed to introduce some sort of nonce or blinding factor on Bob's side. So= lets generate another keypair {y, Y} and this time we are going to ADD it = to Bob's key so that the key agreement value is g^x(b+y).

Alice knows x and calculates B^x . Y^x=
Bob knows b, y= and calculates either X^(b+y) or X^b . X^y

At this point we are applying Torben Pedersen's Di= stributed key generation scheme. And it has wondrous properties. We can per= form all the operations on b in a HSM and perform the blinding factor calcu= lation at the application level. We can even split the private key between = MULTIPLE HSMs.
=
[OK I did = elide something here, you can add b+y in modular arithmetic, yes. But it is= modulo the subgroup size not the prime. This is p-1 for DH and (p-1)/8 for= our CFRG curves.]


OK so now what i= f we want to perform client side authentication and involve Alice's cre= dential {a, A} ?

Easy, th= e key agreement value is now g^(a+x)(b+y)


So here we have one key agreement function that lets us add in or re= move PFS according to whether or not we require it for a particular set of = messages. We can even turn PFS on in the middle of an existing conversation= or turn it off just by dropping the blinding factor out of the mix (or not= ).

Want three way key agr= eement?=C2=A0 g^(a+x)(b+y)(c+z)

Want it in ECC? yes, it all works in Ed25519 or Ed448. It will al= so work in Curve 25519 and Curve 448 if someone can point me to a routine t= o perform addition of two Montgomery points in the compressed representatio= n.


The HSM compartmentalization could= be a way to defeat the Spectre and Meltdown attacks. I showed some of this= in a preview of my RSA talk on this.

All I need is for the CPU manufacturer to provide us with an i= solated core to perform x25519 and x448 operations. The information from th= at core can then be used to apply a blinding factor to crypto operations at= the application level.=C2=A0


There= is a simple proof that this approach is secure if the underlying DH scheme= is.=C2=A0

=
--001a113cd28452d04d05664d9118-- From nobody Wed Feb 28 14:52:44 2018 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 DF411126FDC for ; Wed, 28 Feb 2018 14:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_eEDlDAkiWI for ; Wed, 28 Feb 2018 14:52:41 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 F3701126FB3 for ; Wed, 28 Feb 2018 14:52:40 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 108so3825915otv.3 for ; Wed, 28 Feb 2018 14:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cMBUxUGVUz7x/RsfTfSMbXmmdcLHHPRChQsWK3gR+AI=; b=dWmvZX6F+1f6O/LgvSi1L0llDwjwtwWaSvy1UwCWWdMwiEyWu7i0CJwMGPqKRtcjWB q9anoz6AwTAAauHdEra1ne9iuBpChRWCzln7rcj+HC4oPrTTYea4vXBmh1Y54M6a/uWj ExOf9RyhG+NrVNfhmMedaVICyu3dRG6iDGSO0eejFQ3R9TWbMsbfYS7vNcJz58rLtjv1 keJBsFnR6/ih/vCcVprXEdgjeueZIxWhVLD5jchGiAJgoShzgCQMk+XXauFUvWIXwxXp hzOclgTL+0nSZvzMnD9OblB1ICI+YJZfBqrsLOvBC5u3RWE712ZyjYK+T1464pOYrwnh YQfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cMBUxUGVUz7x/RsfTfSMbXmmdcLHHPRChQsWK3gR+AI=; b=r1gjcElFqq091nqlrgZsZnT7LN+JaiNglixBSzyw9bFqN65l2avDtG2kalSMPhyerj DUBxgFuDQ+iDTdv/I+nSp4778RwTIXy+QqH5jwcpVoYTwaxm8DpVreplX4uIt0mZG4Se sAwnQL3bLSVg15T6yX+q29cA4T8NFZeesU0q3GAAODqtc97XNabxTOl5w8Sun13QJX4M VOQ1aqr6ijHIIUb7HOrdkHP7ohRMFt7zspH+H5DADOMHtk/TY/Z+Bq6E0nGBHm3veLRP q8IzHWv7d16q+AxIHiEmnnkCx9qgpkr0Bz9qVTs8oLxTxNwIKDHXzRxc9wt8+rhgeyOg O+zw== X-Gm-Message-State: APf1xPDYTeazStUDEFPEgJXXm9MKS8fn/ZUvqbLEVeU6FC7SmwhBbcrs vrqCVNlsj6qlJDBLlNe7x8StFCbY16qd3tHhzVc= X-Google-Smtp-Source: AH8x225oe1yWRj0GkTsaunHyrX+pTl8VxzXzHIHS9b5sXUSw3aV9gKEYY1t6Zqv6sfV3KZbvSZIXaTj2xdNm+H8PRfU= X-Received: by 10.157.48.216 with SMTP id r24mr14616832otg.338.1519858360317; Wed, 28 Feb 2018 14:52:40 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 14:52:39 -0800 (PST) In-Reply-To: <20180228222800.0a978ded@T-200> References: <20180228222800.0a978ded@T-200> From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 17:52:39 -0500 X-Google-Sender-Auth: CVQqzwODossj-lMCstKGFprL1lU Message-ID: To: Dennis Jackson Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="f4030437961cacfb4305664d99f4" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:52:43 -0000 --f4030437961cacfb4305664d99f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If this group is not interested in open discussion, it might be in the wrong standards organization. Trying to shut down discussion of other requirements is a REALLY BAD predictor of success in IETF. Go talk to the DANE folk and see how that worked for them. On Wed, Feb 28, 2018 at 5:28 PM, Dennis Jackson wrote: > > If however we are working at the message layer, we will often want to > > support an asynchronous mode in which one party sends some data and > > another picks it up later. That does not prevent us working end to > > end but it does prevent us using PFS. > > This is incorrect. You may want to review the design of Signal, or > indeed the current MLS draft. > > > MLS is not chartered yet. We are discussing what the scope should be. > > It is really inappropriate to assert that has been decided before we > > have met to even discuss what the scope should be.=E2=80=8B > > The current proposal is designed to provide strong end to end > security for group messaging, with perfect forward secrecy and post > compromise security. > > If you don't agree with those design goals, I think you might be in the > wrong mailing list, as rather than being a bird of a feather, you appear > to be a bird of an all together different species. > > On Wed, 28 Feb 2018 16:58:50 -0500 > Phillip Hallam-Baker wrote: > > > On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell > > wrote: > > > > > > > > Hiya, > > > > > > On 28/02/18 17:14, Dave Cridland wrote: > > > > Given the latter, for example, I could not use an MLS-based > > > > system to discuss a tax problem with the authority, and since I'm > > > > unlikely to have a SAKKE-based messaging client, I'm unlikely to > > > > have encrypted messaging to my tax authority at all - which seems > > > > signficantly worse than merely having no Forward Secrecy. > > > > > > Sorry, why is transport layer security not sufficient between you > > > and your tax authority? > > > > > > I'm unclear as to why the security guarantees (aimed for) between > > > groups of people ought be reduced in order to meet the goals of > > > securing communications between a person and a service provider. > > > > > > I do agree that it'd be good if a user of some application could > > > add a new device and still see old messages, but I'm not at all > > > clear that's that significant (for the crypto) since people will > > > always need to have some kind of fallback to handle cases where > > > they've lost state. > > > > > > =E2=80=8BI posted a use case in which I do not want forward secrecy ear= lier. > > > > Alice works in a team with Bob and Carol. At some point Doug joins the > > team. At that point, Doug needs access to all documents and > > discussions related to the project, including: > > > > * All Word, Powerpoint, etc. documents. > > * All Web sites and discussion forums. > > * All group chats, video conferences, etc.=E2=80=8B > > > > =E2=80=8BI have a system that can support this use case with end to end > > encryption. Mallet can run all the online services. The only time an > > administration key is required is when people are added to or removed > > from the group. > > > > Using the term 'reduced' in relation to security properties is > > pejorative and unhelpful. If we are having a discussion related to a > > project there will be times when: > > > > 1) We want the discussion to be off the record with no permanent > > record. 2) We want the discussion to be on the record with a > > permanent record. > > > > =E2=80=8BThese are disjoint use cases and they are both valid. =E2=80= =8BThey are even > > valid for different discussions relating to a single project. > > > > If we are working at the Transport layer, our conversation is always > > synchronous and PFS does not constrain us. If however we are working > > at the message layer, we will often want to support an asynchronous > > mode in which one party sends some data and another picks it up > > later. That does not prevent us working end to end but it does > > prevent us using PFS. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --f4030437961cacfb4305664d99f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If = this group is not interested in open discussion, it might be in the wrong s= tandards organization.

Tr= ying to shut down discussion of other requirements is a REALLY BAD predicto= r of success in IETF.

Go = talk to the DANE folk and see how that worked for them.=C2=A0

On Wed, Feb 28, 2018 at 5= :28 PM, Dennis Jackson <dennis.jackson@cs.ox.ac.uk>= wrote:
> If however = we are working at the message layer, we will often want to
> support an asynchronous mode in which one party sends some data and > another picks it up later. That does not prevent us working end to
> end but it does prevent us using PFS.

This is incorrect. You may want to review the design of Signal, or indeed the current MLS draft.

> MLS is not chartered yet. We are discussing what the scope should be.<= br> > It is really inappropriate to assert that has been decided before we > have met to even discuss what the scope should be.=E2=80=8B

The current proposal is designed to provide strong end to end
security for group messaging, with perfect forward secrecy and post
compromise security.

If you don't agree with those design goals, I think you might be in the=
wrong mailing list, as rather than being a bird of a feather, you appear to be a bird of an all together different species.

On Wed, 28 Feb 2018 16:58:50 -0500
Phillip Hallam-Baker <phill@hal= lambaker.com> wrote:

> On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell
> <stephen.farrell@cs.tc= d.ie> wrote:
>
> >
> > Hiya,
> >
> > On 28/02/18 17:14, Dave Cridland wrote:
> > > Given the latter, for example, I could not use an MLS-based<= br> > > > system to discuss a tax problem with the authority, and sinc= e I'm
> > > unlikely to have a SAKKE-based messaging client, I'm unl= ikely to
> > > have encrypted messaging to my tax authority at all - which = seems
> > > signficantly worse than merely having no Forward Secrecy. > >
> > Sorry, why is transport layer security not sufficient between you=
> > and your tax authority?
> >
> > I'm unclear as to why the security guarantees (aimed for) bet= ween
> > groups of people ought be reduced in order to meet the goals of > > securing communications between a person and a service provider.<= br> > >
> > I do agree that it'd be good if a user of some application co= uld
> > add a new device and still see old messages, but I'm not at a= ll
> > clear that's that significant (for the crypto) since people w= ill
> > always need to have some kind of fallback to handle cases where > > they've lost state.
>
>
> =E2=80=8BI posted a use case in which I do not want forward secrecy ea= rlier.
>
> Alice works in a team with Bob and Carol. At some point Doug joins the=
> team. At that point, Doug needs access to all documents and
> discussions related to the project, including:
>
> * All Word, Powerpoint, etc. documents.
> * All Web sites and discussion forums.
> * All group chats, video conferences, etc.=E2=80=8B
>
> =E2=80=8BI have a system that can support this use case with end to en= d
> encryption. Mallet can run all the online services. The only time an > administration key is required is when people are added to or removed<= br> > from the group.
>
> Using the term 'reduced' in relation to security properties is=
> pejorative and unhelpful. If we are having a discussion related to a > project there will be times when:
>
> 1) We want the discussion to be off the record with no permanent
> record. 2) We want the discussion to be on the record with a
> permanent record.
>
> =E2=80=8BThese are disjoint use cases and they are both valid. =E2=80= =8BThey are even
> valid for different discussions relating to a single project.
>
> If we are working at the Transport layer, our conversation is always > synchronous and PFS does not constrain us. If however we are working > at the message layer, we will often want to support an asynchronous > mode in which one party sends some data and another picks it up
> later. That does not prevent us working end to end but it does
> prevent us using PFS.

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

--f4030437961cacfb4305664d99f4-- From nobody Wed Feb 28 14:56:27 2018 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 069CF12708C for ; Wed, 28 Feb 2018 14:56:27 -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=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEveqh5_MZKx for ; Wed, 28 Feb 2018 14:56:25 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 C7CC6126FDC for ; Wed, 28 Feb 2018 14:56:24 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id l191so6008567lfe.1 for ; Wed, 28 Feb 2018 14:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5OpMTIenpIUHZdFRCIvc/uKBNuiSp2ZSPLXutcMCWwI=; b=O5Os4CZc8K9dm+1BD2QVIWdCxV/YT5f+++DZPJ01tzCcmu/G8vIDxB5bMuuv5SZKDd v0Jg4EYhfajrx7HB5NGKESdTAB3TCGeMdrT2BNVtoTIMs3dCa8FSgJsTGL8XO/l3X/3C IEIezHT2t1IxCPwBaenTHu+6hTItnStfGP1iI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5OpMTIenpIUHZdFRCIvc/uKBNuiSp2ZSPLXutcMCWwI=; b=Bm89lH8s643QRs9dv0W8fcXgZGF0ITxDv3pPS9ZPr1F/1oAw44YJxE8ANluihsJBf5 wqA9Bjc/5cnJAYX/N7/WbBMmeZggpDrbyswcbigS/P+4UiJh+KxbTWf0lIfNoHZx844+ LUOad67w6v6/aTyQqEyRF5afrA2OD5YysLICKCQVjZCvbqfqOf99S3t7CqkCqU4hbxcS mXsCxvD7VPKaS0JtLGRdbTfuf4YBwMtt95D7mzcegEdQkm9NUHXo828+3+ZQg3BKXyva E19r/sX+tMaYyQ7t5Uzm6/0lMeQj3asTmVkKNzDJplZaMXk5E7ZnxcjDR1YowG+/EK+g OqNw== X-Gm-Message-State: APf1xPDPkGh67ZhWwqViJrLMgetdvExg8qcCIdC4yybZg3rd6K14HANI IgAjydZHtU3yuMNzPPlLnBJXZ5tnJilcwY/aXVBJiQeX X-Google-Smtp-Source: AG47ELs2jfj/OUzDMaxOMPjZkeWF1E4rjztSei+ZMMRKDSdr8b22WbG69alWN+ATpGwmB/nbfjrd5ithZxOkhBrlSDo= X-Received: by 10.46.56.6 with SMTP id f6mr14683057lja.4.1519858582904; Wed, 28 Feb 2018 14:56:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.80.4 with HTTP; Wed, 28 Feb 2018 14:56:22 -0800 (PST) In-Reply-To: References: From: Dave Cridland Date: Wed, 28 Feb 2018 22:56:22 +0000 Message-ID: To: Stephen Farrell Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:56:27 -0000 On 28 February 2018 at 21:16, Stephen Farrell wrote: > > Hiya, > > On 28/02/18 17:14, Dave Cridland wrote: >> Given the latter, for example, I could not use an MLS-based system to >> discuss a tax problem with the authority, and since I'm unlikely to >> have a SAKKE-based messaging client, I'm unlikely to have encrypted >> messaging to my tax authority at all - which seems signficantly worse >> than merely having no Forward Secrecy. > > Sorry, why is transport layer security not sufficient between you > and your tax authority? > Because it's not a single hop. Supposing my tax authority uses XMPP, for example, and so has (in my case) hmrc.gov.uk as an XMPP domain. I use some commercialish XMPP provider. I don't want my provider to be able to read my tax messages, nor do I want them archived in plaintext on the server (although I probably do want a verifiable record). Meanwhile, HMRC wants to keep an archived, but secured, copy at their end, viewable by their organisation. > I'm unclear as to why the security guarantees (aimed for) between > groups of people ought be reduced in order to meet the goals of > securing communications between a person and a service provider. > I'm not suggesting they should be. I am suggesting that it might be nice if my options were not simply FS or FO. (Besides which, the archives in a non-FS situation gain some security guarantees, too). > I do agree that it'd be good if a user of some application could > add a new device and still see old messages, but I'm not at all > clear that's that significant (for the crypto) since people will > always need to have some kind of fallback to handle cases where > they've lost state. Assume a FS-only message transfer. In that case, how do we recover missing messages? We have to transport those from another device that has them. That's a perfectly reasonable concept, and one that has been tried before in Skype. Unfortunately, as mobile devices replaced desktop/laptop combinations as the dominant device, they switched away from the design back to centrally-held archives since the clever synchronisation options simply didn't work. Of course, there are users who prefer the trade-off of higher security and no (or limited) archives. Such users would, one hopes, be warned about the change in security should they enter into a conversation with someone who cannot (or will not) support FS. Dave. From nobody Wed Feb 28 15:03:36 2018 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 CA86D127023 for ; Wed, 28 Feb 2018 15:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUePavs5lbPZ for ; Wed, 28 Feb 2018 15:03:33 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 6D44B126FDC for ; Wed, 28 Feb 2018 15:03:33 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id l5so3842819otf.9 for ; Wed, 28 Feb 2018 15:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8Xc+524sI/+KovON+PWgxvWD8MmXiVEJfVGj0BNbFcY=; b=L4ZKyepmHyowC51TNs0+2Z/tC99eLMuM9Xuh8xSxv4hd+efcBA1AOQW9RH2TYTASpa cknazvev7SR6sCt/ATgC+/ldHY6vwvDVJa5jkxWh78v+r9JSA7bkr+jQOB86XsHXaff8 ffeS0QryK5CCXE4AXLyAXYIgFltVw+nhZ/OIGStVP1TyjqZ52+jXTL9SPLFbrJNU6uMx x3YTSxp7htIP3ejqGYle81NI/C0sM8XQgP5HkzZmrzLhfkx7w7WZKT6Y1V+tUuRMSyf2 hbywh2kDHBF14XSz9p/XzhfpokKsUVctYLct3jAZiPYyjH+GboBmWCsRoTXA3QjrJJLC 0/UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8Xc+524sI/+KovON+PWgxvWD8MmXiVEJfVGj0BNbFcY=; b=BpUQzBaDASp4GjALNWXlwF1f/xUlf+S4EMjmGyOgQZbf4kSBFlUuOgYokZE/Obwwxs Y59pnxUzkbeL9kZMVTfgy5lKRV7eiKfrFB8BnM1hHu1/rzb5QN7t3Qm/ciQiXR5QCRly /qgxT+OBbX2o7V5kyVij8a4wf12+TFbKDJyopjkQlWqOxH5X8avnG9/2Raj4EuFbNibJ EzcB6RyNwLi9Z4mr1dwCuLxmjaT6sMmF0330HnSDCiGe0wxXvxzqNgvxXNqVnlUU+5PI JUrew/WKtrfye0Sg2mBa2CclM9Itku+8id8xD9y7kgn05vugM8Noy+e6PjFEyhOSY/gl fRvQ== X-Gm-Message-State: APf1xPApU8+L7yTucdURJxQ4tf9JO0TbQXXaaYfFM7uEyjNO6wa1/W6A qZxHM0zEVJel3SxaHvBI1PBDzUADJoN0FVkChyA= X-Google-Smtp-Source: AG47ELuaBSxXYPJYHuRGxnwCv2USNTMhG5yR3x/Dmj6viSnFehb9d6PO/qqVo6sY3BN965/BrLNSecyEUvpC6J6bStw= X-Received: by 10.157.37.113 with SMTP id j46mr13830658otd.218.1519859012751; Wed, 28 Feb 2018 15:03:32 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 15:03:31 -0800 (PST) In-Reply-To: <20180228222800.0a978ded@T-200> References: <20180228222800.0a978ded@T-200> From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 18:03:31 -0500 X-Google-Sender-Auth: UEf9Gaj0a50rm9aNQj5AfVCHW88 Message-ID: To: Dennis Jackson Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113d0cf490577505664dc008" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:03:35 -0000 --001a113d0cf490577505664dc008 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 5:28 PM, Dennis Jackson wrote: > > If however we are working at the message layer, we will often want to > > support an asynchronous mode in which one party sends some data and > > another picks it up later. That does not prevent us working end to > > end but it does prevent us using PFS. > > This is incorrect. You may want to review the design of Signal, or > indeed the current MLS draft. =E2=80=8BNo it is completely correct. The P in PFS stands for Perfect . If Alice creates a message for Bob using only her knowledge of Bob's public key then it is not going to be PFS because a compromise of Bob's private key is a breach. What Signal is doing is sending messages based on Bob's key plus state from previous communications that Alice and Bob have stored. Now that is providing some form of Forward Secrecy but only a marketing person would claim it was 'Perfect'. =E2=80=8BThe cost of this shared state is far from trivial at the protocol = level as both the sending and receiving device have to be in synchronization. What happens when Alice and Bob have a dozen devices? Then we have 144 sets of shared state.=E2=80=8B --001a113d0cf490577505664dc008 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Fe= b 28, 2018 at 5:28 PM, Dennis Jackson <dennis.jackson@cs.ox.ac.uk= > wrote:
&= gt; If however we are working at the message layer, we will often want to > support an asynchronous mode in which one party sends some data and > another picks it up later. That does not prevent us working end to
> end but it does prevent us using PFS.

This is incorrect. You may want to review the design of Signal, or indeed the current MLS draft.

=E2=80=8BNo it is completely corr= ect. The P in PFS stands for Perfect .

If Alice creates a message for Bob using only her knowledge o= f Bob's public key then it is not going to be PFS because a compromise = of Bob's private key is a breach.=C2=A0

What Signal is doing is sending messages based on Bob&= #39;s key plus state from previous communications that Alice and Bob have s= tored. Now that is providing some form of Forward Secrecy but only a market= ing person would claim it was 'Perfect'.

=E2=80=8BThe cost of this = shared state is far from trivial at the protocol level as both the sending = and receiving device have to be in synchronization. What happens when Alice= and Bob have a dozen devices? Then we have 144 sets of shared state.=E2=80= =8B

--001a113d0cf490577505664dc008-- From nobody Wed Feb 28 15:19:10 2018 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 EEFD0127058 for ; Wed, 28 Feb 2018 15:19:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 aCbRRuXWh8wy for ; Wed, 28 Feb 2018 15:19:07 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 5477C127023 for ; Wed, 28 Feb 2018 15:19:07 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id o25so5273123qkl.7 for ; Wed, 28 Feb 2018 15:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PDKVzwynnZL9jWCsdFaxoMqaTXiGFXpRYNChk1+FHmk=; b=oxE/tCiEJgv9n/dKzXkEQDtDHVxu38Se9R7hsMcIWK57oSmNzexNJh0/P4d9nDBu6q PhEs97j7dLstu0s6QMdk+J0gCtMxxVYVDTt4Ui8p3zWWg1Ct1ZqZj0JMa79bqzcbmwx5 n6x5/JSW10PEBPKkvSkBIFCPLSzOVGGry/f+LhpL5DvJK8Q5u7IPevlevzvewXZ47WMs DyhyZDdwDmM2geb1e8DcrElVCx5ojRhAWtoTkFwQ1vo5PRuIkh3ISaLjkO78Nnftk9P+ ABOp8SHUmJ1ASUY1Oo8tVRjJ/bc5N9nesmo3vIQhEXTmbiIfxsqIZ1QK/+tXga4MInfu uNvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PDKVzwynnZL9jWCsdFaxoMqaTXiGFXpRYNChk1+FHmk=; b=QVjzZHnhr7aSdD+ckB3n0+vGFwznlnOADkQCHswkB3ovZSCwvOXR+k1oGDEvzYy27U 3fDNFXvzRepKZUbqkDEi4JCDYhU3ApR8/Ui7tMVT1q7xsmgZ4NMyU7vygmuZycgA1aW8 V6T8QfcfMJgcw+vEizCyLAWQcOZBE7bE/y/NQyYK6bsCpqfd/6wgY9ajsq6RRjw1dUu7 hyu10wYoAXRJHuk7fIoSUX72xI2OEvg79wwpbg2aG8kj7LO8iw0pvfjsIpqhUoghG1eR Go0dN/FxniLm3uoFr1pPYXwCie3LAKbnEXUmUYeCRhqXea6qEb9FKcpJnfVlt1pHNYGJ IZYw== X-Gm-Message-State: APf1xPDjrtps4AtCz6Z8iHxYWknqC1juAXU2HA0i4vwOQVKkpf2ZY7jW e/6Yxvl9IYLE4mI9gjkYyWRor93cD2mwQI+0cDiEbA== X-Google-Smtp-Source: AG47ELu3MqtDq0UfCSrR5XKGUHxNoxLIbpoMBsysqr3/2OfgmRzDDp9ZKOm9ZA1F+5qOSi7PXj7rH/8pYMBCmW8F04s= X-Received: by 10.55.195.145 with SMTP id r17mr31225277qkl.83.1519859946431; Wed, 28 Feb 2018 15:19:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 28 Feb 2018 15:18:25 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 28 Feb 2018 15:18:25 -0800 Message-ID: To: Dave Cridland Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a1147a3243753c405664df88f" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:19:09 -0000 --001a1147a3243753c405664df88f Content-Type: text/plain; charset="UTF-8" Hi Dave, I certainly agree with you that there are use cases where applications might want to archive communications. Generally, I think the right answer to these, however, isn't to modify the messaging protocol but rather to add that functionality on the messaging app over the top. That also is a much easier way to do new device history sync -Ekr On Wed, Feb 28, 2018 at 9:14 AM, Dave Cridland wrote: > Hi folks, > > While I'm really pleased to see MLS, and I generally like the idea of > Forward Secrecy, there's a couple of use cases where it might be worth > avoiding. Feel free to correct me if these are in fact possible with > Forward Secrecy. Both these relate to archival access to past > messages: > > * UX - Some users (actually all of them) would like to be able to > install client software on a new device and have their historical > messages available to them. Most "business" messaging systems seem to > work this way, as well as a number of consumer-grade systems. The > nature of Forward Secrecy means that an archive would need to be held > on one device and re-sent to another through the network, which is > trickier to manage, and is reliant on multiple devices being online at > overlapping times. Alternately, the archival copy might be re-uploaded > to the server using a static encryption key, I suppose, which would > rather spoil the point. > > * Retention - Many business and government deployments have mandatory > retention requirements. An example is MIKEY-SAKKE, promoted in part by > the UK Government for its own communications, which uses mandatory key > escrow to keep an archived copy of the messages accessible to the > business units involved. An advantage of the SAKKE system is that it > allows the key escrow to be offline, limiting attack opportunities. > > Given the latter, for example, I could not use an MLS-based system to > discuss a tax problem with the authority, and since I'm unlikely to > have a SAKKE-based messaging client, I'm unlikely to have encrypted > messaging to my tax authority at all - which seems signficantly worse > than merely having no Forward Secrecy. > > None of this is to say that Forward Secrecy should be avoided > entirely, of course. > > Dave. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --001a1147a3243753c405664df88f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

I certainly agree with you tha= t there are use cases where applications might want to archive communicatio= ns.

Generally, I think the right answer to these, = however, isn't to modify the messaging protocol but rather to add that = functionality on the messaging app over the top. That also is a much easier= way to do new device history sync

-Ekr
=

O= n Wed, Feb 28, 2018 at 9:14 AM, Dave Cridland <dave@cridland.net> wrote:
Hi folks,

While I'm really pleased to see MLS, and I generally like the idea of Forward Secrecy, there's a couple of use cases where it might be worth<= br> avoiding. Feel free to correct me if these are in fact possible with
Forward Secrecy. Both these relate to archival access to past
messages:

* UX - Some users (actually all of them) would like to be able to
install client software on a new device and have their historical
messages available to them. Most "business" messaging systems see= m to
work this way, as well as a number of consumer-grade systems. The
nature of Forward Secrecy means that an archive would need to be held
on one device and re-sent to another through the network, which is
trickier to manage, and is reliant on multiple devices being online at
overlapping times. Alternately, the archival copy might be re-uploaded
to the server using a static encryption key, I suppose, which would
rather spoil the point.

* Retention - Many business and government deployments have mandatory
retention requirements. An example is MIKEY-SAKKE, promoted in part by
the UK Government for its own communications, which uses mandatory key
escrow to keep an archived copy of the messages accessible to the
business units involved. An advantage of the SAKKE system is that it
allows the key escrow to be offline, limiting attack opportunities.

Given the latter, for example, I could not use an MLS-based system to
discuss a tax problem with the authority, and since I'm unlikely to
have a SAKKE-based messaging client, I'm unlikely to have encrypted
messaging to my tax authority at all - which seems signficantly worse
than merely having no Forward Secrecy.

None of this is to say that Forward Secrecy should be avoided
entirely, of course.

Dave.

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

--001a1147a3243753c405664df88f-- From nobody Wed Feb 28 15:26:04 2018 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 9CC521270A7 for ; Wed, 28 Feb 2018 15:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhfW5m1bHgPG for ; Wed, 28 Feb 2018 15:25:59 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 BB411127058 for ; Wed, 28 Feb 2018 15:25:59 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id m22so3886268otf.10 for ; Wed, 28 Feb 2018 15:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=S9Qgko4eEaYlY03jJl9n8uldv2o0Ne4lCVO6+qLJFkM=; b=IUiVCxFfd72mgvDR/0vZwSVDZM2jMepIwsQuN/Nfg+2SAB1Y0fndIscd/E6Uk3NH7m vEEV03No4/NuLmN/jCT406AaAm68+zBMLtbfwhNuD63s26LIx1WE0Sx5k3h05tr6KfLq //TAfOlSezraK76uJFONfiupUZA4k6rkEUFdffHnON6mz8wpJ6RlCWTS9DthgTneMQVQ LIH/lsC/ekj3cGjYVNYWXYXYHqOwSWqBfpSko+wKUB330hOwLbCvh44tyOIxye9eqrPs EbofxOWwrJvhXMO0EbD6KvPGT0ZysUdcvvN4hHs+/JdPdWlYPuDtv/kLoGr7ml/n3Plf izFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=S9Qgko4eEaYlY03jJl9n8uldv2o0Ne4lCVO6+qLJFkM=; b=MnFXR/3q3/kBWd1ePFHHmnp8QfU+LESKu/9RQ6C7ro3bLj5ncKvxZcWlP+rjWiHkV1 v4aLfyjBqp5ooOBbSxB5cNLmBz1J8n9MHeCPUz+8tYfbgwEfY7vvDBktTYNMKQCnjRU0 Sai9Im5THOSbvfbrgLaoHyUbD/fT1Fs5Fo3DetUFudJEW5xB+pWFcgASb2TIs7KmeVZP mq8DYrb0c81uz9Qn8L2B1Wp3AECKi5HwqIdoH0gj8mFXUa01Q/K3BmecQeTBeuwoD3Jr 4IQs+cqTwjYZ1iBmfMR67S31r8GWuJla05lyJCpMJvIZGjPpPPnE4swYGQpeC3eReO1s 1j1A== X-Gm-Message-State: APf1xPBeTIp/zLLI+9LEbc9T7tUzmeRvw8TZ7FAm/k08Jr7H2uM36sdM JQnfbBkd2TxrNIAzx8enk9pud31aXPzdFJrVvFI= X-Google-Smtp-Source: AH8x224GEgjNIDvWyWqobLBXIYanmfE822/bFHHQEhVa80F5YuRsNzYEnHlNafVSCDAUpHztYKcQgoIFL/Tym8Z5II8= X-Received: by 10.157.48.216 with SMTP id r24mr14682405otg.338.1519860359040; Wed, 28 Feb 2018 15:25:59 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 15:25:58 -0800 (PST) In-Reply-To: References: From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 18:25:58 -0500 X-Google-Sender-Auth: jWtsNEo-22sO2ELc8rpy5Voyxn0 Message-ID: To: Eric Rescorla Cc: Dave Cridland , mls@ietf.org Content-Type: multipart/alternative; boundary="f4030437961ccf15bd05664e1006" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:26:01 -0000 --f4030437961ccf15bd05664e1006 Content-Type: text/plain; charset="UTF-8" Ekr Well maybe. It depends on how much of the complexity of the proposed protocol is coming from the attempt to achieve 'PFS' and also what the protocol is in fact achieving. In general, I like to see what the requirements are before jumping to implementation. Right now we seem to have a different key agreement approach for every protocol. And we seem to be still doing key agreement the way we used to do it in RSA even though we now use ECDH. -Phb. On Wed, Feb 28, 2018 at 6:18 PM, Eric Rescorla wrote: > Hi Dave, > > I certainly agree with you that there are use cases where applications > might want to archive communications. > > Generally, I think the right answer to these, however, isn't to modify the > messaging protocol but rather to add that functionality on the messaging > app over the top. That also is a much easier way to do new device history > sync > > -Ekr > > > On Wed, Feb 28, 2018 at 9:14 AM, Dave Cridland wrote: > >> Hi folks, >> >> While I'm really pleased to see MLS, and I generally like the idea of >> Forward Secrecy, there's a couple of use cases where it might be worth >> avoiding. Feel free to correct me if these are in fact possible with >> Forward Secrecy. Both these relate to archival access to past >> messages: >> >> * UX - Some users (actually all of them) would like to be able to >> install client software on a new device and have their historical >> messages available to them. Most "business" messaging systems seem to >> work this way, as well as a number of consumer-grade systems. The >> nature of Forward Secrecy means that an archive would need to be held >> on one device and re-sent to another through the network, which is >> trickier to manage, and is reliant on multiple devices being online at >> overlapping times. Alternately, the archival copy might be re-uploaded >> to the server using a static encryption key, I suppose, which would >> rather spoil the point. >> >> * Retention - Many business and government deployments have mandatory >> retention requirements. An example is MIKEY-SAKKE, promoted in part by >> the UK Government for its own communications, which uses mandatory key >> escrow to keep an archived copy of the messages accessible to the >> business units involved. An advantage of the SAKKE system is that it >> allows the key escrow to be offline, limiting attack opportunities. >> >> Given the latter, for example, I could not use an MLS-based system to >> discuss a tax problem with the authority, and since I'm unlikely to >> have a SAKKE-based messaging client, I'm unlikely to have encrypted >> messaging to my tax authority at all - which seems signficantly worse >> than merely having no Forward Secrecy. >> >> None of this is to say that Forward Secrecy should be avoided >> entirely, of course. >> >> Dave. >> >> _______________________________________________ >> 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 > > --f4030437961ccf15bd05664e1006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ekr=

Well maybe. It depends o= n how much of the complexity of the proposed protocol is coming from the at= tempt to achieve 'PFS' and also what the protocol is in fact achiev= ing.

=
In general, I like t= o see what the requirements are before jumping to implementation.=C2=A0

Right now we seem to have a = different key agreement approach for every protocol. And we seem to be stil= l doing key agreement the way we used to do it in RSA even though we now us= e ECDH.


-Phb.


On Wed, Feb 28, 2018 at 6:18 PM, Eric Resco= rla <ekr@rtfm.com> wrote:
Hi Dave,

I certainly agree with you that the= re are use cases where applications might want to archive communications.

Generally, I think the right answer to these, howev= er, isn't to modify the messaging protocol but rather to add that funct= ionality on the messaging app over the top. That also is a much easier way = to do new device history sync

-Ekr

<= /div>

On Wed, Feb 28, 2018 at 9:14 AM, Dave Cri= dland <dave@cridland.net> wrote:
Hi folks,

While I'm really pleased to see MLS, and I generally like the idea of Forward Secrecy, there's a couple of use cases where it might be worth<= br> avoiding. Feel free to correct me if these are in fact possible with
Forward Secrecy. Both these relate to archival access to past
messages:

* UX - Some users (actually all of them) would like to be able to
install client software on a new device and have their historical
messages available to them. Most "business" messaging systems see= m to
work this way, as well as a number of consumer-grade systems. The
nature of Forward Secrecy means that an archive would need to be held
on one device and re-sent to another through the network, which is
trickier to manage, and is reliant on multiple devices being online at
overlapping times. Alternately, the archival copy might be re-uploaded
to the server using a static encryption key, I suppose, which would
rather spoil the point.

* Retention - Many business and government deployments have mandatory
retention requirements. An example is MIKEY-SAKKE, promoted in part by
the UK Government for its own communications, which uses mandatory key
escrow to keep an archived copy of the messages accessible to the
business units involved. An advantage of the SAKKE system is that it
allows the key escrow to be offline, limiting attack opportunities.

Given the latter, for example, I could not use an MLS-based system to
discuss a tax problem with the authority, and since I'm unlikely to
have a SAKKE-based messaging client, I'm unlikely to have encrypted
messaging to my tax authority at all - which seems signficantly worse
than merely having no Forward Secrecy.

None of this is to say that Forward Secrecy should be avoided
entirely, of course.

Dave.

_______________________________________________
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


--f4030437961ccf15bd05664e1006-- From nobody Wed Feb 28 15:41:11 2018 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 0205412711A for ; Wed, 28 Feb 2018 15:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TAYDeISlkdYA for ; Wed, 28 Feb 2018 15:41:07 -0800 (PST) Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) (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 7F947127023 for ; Wed, 28 Feb 2018 15:41:07 -0800 (PST) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay15.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1erBLN-0003hu-na for mls@ietf.org; Wed, 28 Feb 2018 23:41:05 +0000 Received: from sth-1.gradacc.ox.ac.uk ([192.76.28.109] helo=T-200) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1erBLN-0007TI-GV for mls@ietf.org; Wed, 28 Feb 2018 23:41:05 +0000 Date: Wed, 28 Feb 2018 23:41:04 +0000 From: Dennis Jackson To: mls@ietf.org Message-ID: <20180228234104.14fde460@T-200> In-Reply-To: References: <20180228222800.0a978ded@T-200> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Oxford-Username: exet4027 X-Oxmail-Spam-Status: score=-0.0 tests=T_RP_MATCHES_RCVD -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Oxmail-Spam-Level: / Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:41:10 -0000 > =E2=80=8BThe cost of this shared state is far from trivial at the protocol > level as both the sending and receiving device have to be in > synchronization. What happens when Alice and Bob have a dozen > devices? Then we have 144 sets of shared state.=E2=80=8B Phillip, it's clear you've read neither the MLS draft, nor the paper it is based on. For example: one of the key contributions is a reduction in the amount of shared state from O(n^2) to O(log n). > If this group is not interested in open discussion, it might be in > the wrong standards organization. > Trying to shut down discussion of other requirements is a REALLY BAD > predictor of success in IETF. > Go talk to the DANE folk and see how that worked for them.=C2=A0 The discussion on PFS has been done to death, both on the TLS mailing list and in numerous other places and I would hate to see us repeat it for little gain. In the end, TLS 1.3 mandates that PFS be used in every connection. I find it hard to imagine that MLS will aspire=20 to a weaker security goal than TLS, but as you say, it is for the group to decide.=20 On Wed, 28 Feb 2018 18:03:31 -0500 Phillip Hallam-Baker wrote: > On Wed, Feb 28, 2018 at 5:28 PM, Dennis Jackson > wrote: >=20 > > > If however we are working at the message layer, we will often > > > want to support an asynchronous mode in which one party sends > > > some data and another picks it up later. That does not prevent us > > > working end to end but it does prevent us using PFS. > > > > This is incorrect. You may want to review the design of Signal, or > > indeed the current MLS draft. >=20 >=20 > =E2=80=8BNo it is completely correct. The P in PFS stands for Perfect . >=20 > If Alice creates a message for Bob using only her knowledge of Bob's > public key then it is not going to be PFS because a compromise of > Bob's private key is a breach. >=20 > What Signal is doing is sending messages based on Bob's key plus > state from previous communications that Alice and Bob have stored. > Now that is providing some form of Forward Secrecy but only a > marketing person would claim it was 'Perfect'. >=20 > =E2=80=8BThe cost of this shared state is far from trivial at the protocol > level as both the sending and receiving device have to be in > synchronization. What happens when Alice and Bob have a dozen > devices? Then we have 144 sets of shared state.=E2=80=8B From nobody Wed Feb 28 15:58:11 2018 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 36F22127058 for ; Wed, 28 Feb 2018 15:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=BqSPnBW6; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=S+QqLCsT 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 vCZZoNeJri66 for ; Wed, 28 Feb 2018 15:58:07 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 CFF7F1241F3 for ; Wed, 28 Feb 2018 15:58:07 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1SNt77p014783; Wed, 28 Feb 2018 15:58:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=flXlSiTj88FUyQu6x6qrM3mnXxtCfacDr9FGWZixZks=; b=BqSPnBW6YKiZUbDOFYq0TW6auiC2QqV89RKnIJFKPh6LnJXeA8stcZBlV7XJsk5rdfZO YRkJxvj76I4p4MQEopCHArr87XG6MzKaeHtmhH5aSOGN4Sb/OJUnzxPJvLKOtD0M/FMO yhT2j0FYTp3s50mpwDy/5S5fTj74Ur+H6AE= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2ge6g581jt-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Feb 2018 15:58:06 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.16) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 28 Feb 2018 15:58:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=flXlSiTj88FUyQu6x6qrM3mnXxtCfacDr9FGWZixZks=; b=S+QqLCsT3doUa7Ha7RO6U9kgFF1eJhKYeAV9pD/lurypv3FVy08G9seIg5pNUE3vDuyYZ9k43pFm3I8LCgRKvWbvmueVRBf+vwm9M0AQsUHg9BgRwO+otBxtzkk1ekSCYQBw5dKHiJew6JUvpjG5uuTONTdTqnlJBxVuIfhDL4U= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1463.namprd15.prod.outlook.com (10.172.161.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 23:58:02 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::3028:3f8c:6eeb:3256]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::3028:3f8c:6eeb:3256%17]) with mapi id 15.20.0527.021; Wed, 28 Feb 2018 23:58:02 +0000 From: Jon Millican To: Eric Rescorla , Dave Cridland CC: "mls@ietf.org" Thread-Topic: [MLS] Use Cases for avoiding Forward Secrecy Thread-Index: AQHTsLeowtsdDTBzZk+HHlXOjx9LuqO6c26AgAALEIA= Date: Wed, 28 Feb 2018 23:58:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:180::1:9340] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1463; 7:VjGRwb4HNF73KqBPyWwisQ51vyxMQI+2BPM07IN4h/zs56nzvY5/klkeMaj9L3bFZWffxzdzdrUCzQQsjYSB3yKhjEGd/0JkTju1K0h+YZHRH+iw/RhzyTZowko43TKm5V+Lb4SvbT9xG1ijp7KxctuOEwPkauhtUC68tn9I7O2Z8e+D6WixIHZFNZcLwrvDkqNDHzTNASlXPxul56jbX/Wy7TN6fC9h81T7O//QiY7SJpfzlVxa7X9Xv/tsNO/E; 20:K/D5n7vF0OxaEfrdbCub8N0jsX386BhEo+zJV5Otj6Zm+VaRyNNSZ/FMFw6vnd4gv8rE9KkLxG8PRCAX/tvAJO05SmXbQgGilsYcIibigrRk+97Z+OEMqp8C7kUXt9iayV6oclkyExW01LhLVQnZNceS3ic7qmt05UY8pe13WB8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d64ce2f5-ac94-419a-fb56-08d57f071a7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR15MB1463; x-ms-traffictypediagnostic: CY4PR15MB1463: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(209352067349851)(192374486261705)(21748063052155)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(11241501184)(944501221)(93006095)(93001095)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR15MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1463; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39860400002)(396003)(376002)(366004)(199004)(189003)(4326008)(2950100002)(102836004)(229853002)(36756003)(33656002)(7736002)(186003)(53546011)(6506007)(5250100002)(2900100001)(606006)(68736007)(478600001)(966005)(6486002)(6116002)(83716003)(6436002)(6306002)(14454004)(3660700001)(6246003)(54896002)(25786009)(8676002)(86362001)(6512007)(81156014)(236005)(81166006)(53936002)(59450400001)(3280700002)(97736004)(561944003)(5660300001)(110136005)(76176011)(105586002)(316002)(8936002)(106356001)(2906002)(82746002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1463; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tVPCh7SbUO7wk/RFXMhn+w8tmCTcPnL3tz3GVWmB1Xj6i4BA1AIQoQNUWyNgrVal9K3Yi177iVylLQO/G3Ug8lNkB6oG/csnFBj8BBzRGP0i6+2uSg+rDNUvRDeYvqFSn6pbvrRHuHwxvL/DdqECcPrAwYQm4KteSK4rZK/oHns= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B2A5860D01544E4386D346F0FAC2F75Cfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d64ce2f5-ac94-419a-fb56-08d57f071a7c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 23:58:02.7752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1463 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-28_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 23:58:10 -0000 --_000_B2A5860D01544E4386D346F0FAC2F75Cfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIGJlbmVmaXQgdG8gdGhlIHJhdGNoZXRpbmcgYXBwcm9hY2ggaW4gdGhlIHByb3Bvc2FsIGlz IHRoZSBpbW1lZGlhdGUgbG9jay1vdXQgeW91IGdldCB3aGVuIGEgcGFydGljaXBhbnQgaXMgZXZp Y3RlZCBmcm9tIGEgZ3JvdXAuIFRoaXMgaXMgYSBkaWZmZXJlbnQgcHJvcGVydHkgZnJvbSBmb3J3 YXJkIHNlY3JlY3k7IGJ1dCBpZiB3ZSBkbyB3aXNoIHRvIGhhdmUgdGhpcyBiZW5lZml0IGluIHRo ZSBwcm90b2NvbCB0aGVuIEkgYmVsaWV2ZSB0aGF0IHdlIHdpbGwgaGF2ZSB0byBiZSB0b2xlcmFu dCB0byBtdXRhdGlvbnMgb2YgbWVzc2FnZSBrZXlzLCBhbmQgdGhhdCBhbnkgbWVjaGFuaXNtIHRv IHJldHJpZXZlIG1lc3NhZ2UgaGlzdG9yeSBvciBlc2Nyb3cgbWVzc2FnZXMgd291bGQgdGhlcmVm b3JlIGhhdmUgdG8gdG9sZXJhdGUgbWVzc2FnZXMgYmVpbmcgZW5jcnlwdGVkIHdpdGggYXJiaXRy YXJpbHkgbWFueSBrZXlzLiBJZiB5b3UgY2FuIHN1cHBvcnQgdGhpcyBmb3IgZXZpY3Rpb24tdHJp Z2dlcmVkIGtleSBtdXRhdGlvbnMsIEkgZmVlbCBsaWtlIGl0IHdvdWxkbuKAmXQgYmUgbXVjaCBv ZiBhIHN0cmV0Y2ggdG8gbWFrZSBpdCB3b3JrIG9uIHRvcCBvZiBhIGZvcndhcmQgc2VjcmV0IHBy b3RvY29sLg0KDQpPZiBjb3Vyc2UsIG9uZSBwb3NzaWJsZSBzZXQgb2YgcmVxdWlyZW1lbnRzIGNv dWxkIHRvbGVyYXRlIGV2aWN0ZWQgZ3JvdXAgbWVtYmVycyByZXRhaW5pbmcgYWNjZXNzIHRvIHRo ZSBncm91cCBlbmNyeXB0aW9uIGtleXMg4oCTIHdoaWNoIHdvdWxkIHJlbmRlciBteSBhYm92ZSBw b2ludCBtb290IOKAkyBidXQgdGhpcyB3b3VsZCBmZWVsIHRvIG1lIGxpa2UgcXVpdGUgYSBzdHJh bmdlIHNlY3VyaXR5IHByb3BlcnR5IHRvIGhhdmUuDQoNCk9uIDI4LzAyLzIwMTgsIDIzOjE5LCAi TUxTIG9uIGJlaGFsZiBvZiBFcmljIFJlc2NvcmxhIiA8bWxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1scy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgZWtyQHJ0Zm0uY29tPG1haWx0 bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KSGkgRGF2ZSwNCg0KSSBjZXJ0YWlubHkgYWdyZWUg d2l0aCB5b3UgdGhhdCB0aGVyZSBhcmUgdXNlIGNhc2VzIHdoZXJlIGFwcGxpY2F0aW9ucyBtaWdo dCB3YW50IHRvIGFyY2hpdmUgY29tbXVuaWNhdGlvbnMuDQoNCkdlbmVyYWxseSwgSSB0aGluayB0 aGUgcmlnaHQgYW5zd2VyIHRvIHRoZXNlLCBob3dldmVyLCBpc24ndCB0byBtb2RpZnkgdGhlIG1l c3NhZ2luZyBwcm90b2NvbCBidXQgcmF0aGVyIHRvIGFkZCB0aGF0IGZ1bmN0aW9uYWxpdHkgb24g dGhlIG1lc3NhZ2luZyBhcHAgb3ZlciB0aGUgdG9wLiBUaGF0IGFsc28gaXMgYSBtdWNoIGVhc2ll ciB3YXkgdG8gZG8gbmV3IGRldmljZSBoaXN0b3J5IHN5bmMNCg0KLUVrcg0KDQoNCk9uIFdlZCwg RmViIDI4LCAyMDE4IGF0IDk6MTQgQU0sIERhdmUgQ3JpZGxhbmQgPGRhdmVAY3JpZGxhbmQubmV0 PG1haWx0bzpkYXZlQGNyaWRsYW5kLm5ldD4+IHdyb3RlOg0KSGkgZm9sa3MsDQoNCldoaWxlIEkn bSByZWFsbHkgcGxlYXNlZCB0byBzZWUgTUxTLCBhbmQgSSBnZW5lcmFsbHkgbGlrZSB0aGUgaWRl YSBvZg0KRm9yd2FyZCBTZWNyZWN5LCB0aGVyZSdzIGEgY291cGxlIG9mIHVzZSBjYXNlcyB3aGVy ZSBpdCBtaWdodCBiZSB3b3J0aA0KYXZvaWRpbmcuIEZlZWwgZnJlZSB0byBjb3JyZWN0IG1lIGlm IHRoZXNlIGFyZSBpbiBmYWN0IHBvc3NpYmxlIHdpdGgNCkZvcndhcmQgU2VjcmVjeS4gQm90aCB0 aGVzZSByZWxhdGUgdG8gYXJjaGl2YWwgYWNjZXNzIHRvIHBhc3QNCm1lc3NhZ2VzOg0KDQoqIFVY IC0gU29tZSB1c2VycyAoYWN0dWFsbHkgYWxsIG9mIHRoZW0pIHdvdWxkIGxpa2UgdG8gYmUgYWJs ZSB0bw0KaW5zdGFsbCBjbGllbnQgc29mdHdhcmUgb24gYSBuZXcgZGV2aWNlIGFuZCBoYXZlIHRo ZWlyIGhpc3RvcmljYWwNCm1lc3NhZ2VzIGF2YWlsYWJsZSB0byB0aGVtLiBNb3N0ICJidXNpbmVz cyIgbWVzc2FnaW5nIHN5c3RlbXMgc2VlbSB0bw0Kd29yayB0aGlzIHdheSwgYXMgd2VsbCBhcyBh IG51bWJlciBvZiBjb25zdW1lci1ncmFkZSBzeXN0ZW1zLiBUaGUNCm5hdHVyZSBvZiBGb3J3YXJk IFNlY3JlY3kgbWVhbnMgdGhhdCBhbiBhcmNoaXZlIHdvdWxkIG5lZWQgdG8gYmUgaGVsZA0Kb24g b25lIGRldmljZSBhbmQgcmUtc2VudCB0byBhbm90aGVyIHRocm91Z2ggdGhlIG5ldHdvcmssIHdo aWNoIGlzDQp0cmlja2llciB0byBtYW5hZ2UsIGFuZCBpcyByZWxpYW50IG9uIG11bHRpcGxlIGRl dmljZXMgYmVpbmcgb25saW5lIGF0DQpvdmVybGFwcGluZyB0aW1lcy4gQWx0ZXJuYXRlbHksIHRo ZSBhcmNoaXZhbCBjb3B5IG1pZ2h0IGJlIHJlLXVwbG9hZGVkDQp0byB0aGUgc2VydmVyIHVzaW5n IGEgc3RhdGljIGVuY3J5cHRpb24ga2V5LCBJIHN1cHBvc2UsIHdoaWNoIHdvdWxkDQpyYXRoZXIg c3BvaWwgdGhlIHBvaW50Lg0KDQoqIFJldGVudGlvbiAtIE1hbnkgYnVzaW5lc3MgYW5kIGdvdmVy bm1lbnQgZGVwbG95bWVudHMgaGF2ZSBtYW5kYXRvcnkNCnJldGVudGlvbiByZXF1aXJlbWVudHMu IEFuIGV4YW1wbGUgaXMgTUlLRVktU0FLS0UsIHByb21vdGVkIGluIHBhcnQgYnkNCnRoZSBVSyBH b3Zlcm5tZW50IGZvciBpdHMgb3duIGNvbW11bmljYXRpb25zLCB3aGljaCB1c2VzIG1hbmRhdG9y eSBrZXkNCmVzY3JvdyB0byBrZWVwIGFuIGFyY2hpdmVkIGNvcHkgb2YgdGhlIG1lc3NhZ2VzIGFj Y2Vzc2libGUgdG8gdGhlDQpidXNpbmVzcyB1bml0cyBpbnZvbHZlZC4gQW4gYWR2YW50YWdlIG9m IHRoZSBTQUtLRSBzeXN0ZW0gaXMgdGhhdCBpdA0KYWxsb3dzIHRoZSBrZXkgZXNjcm93IHRvIGJl IG9mZmxpbmUsIGxpbWl0aW5nIGF0dGFjayBvcHBvcnR1bml0aWVzLg0KDQpHaXZlbiB0aGUgbGF0 dGVyLCBmb3IgZXhhbXBsZSwgSSBjb3VsZCBub3QgdXNlIGFuIE1MUy1iYXNlZCBzeXN0ZW0gdG8N CmRpc2N1c3MgYSB0YXggcHJvYmxlbSB3aXRoIHRoZSBhdXRob3JpdHksIGFuZCBzaW5jZSBJJ20g dW5saWtlbHkgdG8NCmhhdmUgYSBTQUtLRS1iYXNlZCBtZXNzYWdpbmcgY2xpZW50LCBJJ20gdW5s aWtlbHkgdG8gaGF2ZSBlbmNyeXB0ZWQNCm1lc3NhZ2luZyB0byBteSB0YXggYXV0aG9yaXR5IGF0 IGFsbCAtIHdoaWNoIHNlZW1zIHNpZ25maWNhbnRseSB3b3JzZQ0KdGhhbiBtZXJlbHkgaGF2aW5n IG5vIEZvcndhcmQgU2VjcmVjeS4NCg0KTm9uZSBvZiB0aGlzIGlzIHRvIHNheSB0aGF0IEZvcndh cmQgU2VjcmVjeSBzaG91bGQgYmUgYXZvaWRlZA0KZW50aXJlbHksIG9mIGNvdXJzZS4NCg0KRGF2 ZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1M UyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19tbHMmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVY X2J2RXFNYTg0USZtPXFMOFh3WTRESzEzSWYwenBibXQ2cGNTRTNpRWw1RWJLVDBGWTdMX2FfLVEm cz0wUnJYYUpObTBRWG1rcmc1VzlzUmhQNmZkNml3ZmlLM0hwcTdFUHBmbWpzJmU9Pg0KDQo= --_000_B2A5860D01544E4386D346F0FAC2F75Cfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9CEF4EBD3552A645A259D54444DC2715@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pk9uZSBiZW5lZml0IHRvIHRoZSByYXRjaGV0aW5nIGFwcHJvYWNoIGluIHRoZSBwcm9wb3NhbCBp cyB0aGUgaW1tZWRpYXRlIGxvY2stb3V0IHlvdSBnZXQgd2hlbiBhIHBhcnRpY2lwYW50IGlzIGV2 aWN0ZWQgZnJvbSBhIGdyb3VwLiBUaGlzIGlzIGEgZGlmZmVyZW50IHByb3BlcnR5IGZyb20gZm9y d2FyZCBzZWNyZWN5OyBidXQgaWYgd2UgZG8NCiB3aXNoIHRvIGhhdmUgdGhpcyBiZW5lZml0IGlu IHRoZSBwcm90b2NvbCB0aGVuIEkgYmVsaWV2ZSB0aGF0IHdlIHdpbGwgaGF2ZSB0byBiZSB0b2xl cmFudCB0byBtdXRhdGlvbnMgb2YgbWVzc2FnZSBrZXlzLCBhbmQgdGhhdCBhbnkgbWVjaGFuaXNt IHRvIHJldHJpZXZlIG1lc3NhZ2UgaGlzdG9yeSBvciBlc2Nyb3cgbWVzc2FnZXMgd291bGQgdGhl cmVmb3JlIGhhdmUgdG8gdG9sZXJhdGUgbWVzc2FnZXMgYmVpbmcgZW5jcnlwdGVkIHdpdGggYXJi aXRyYXJpbHkNCiBtYW55IGtleXMuIElmIHlvdSBjYW4gc3VwcG9ydCB0aGlzIGZvciBldmljdGlv bi10cmlnZ2VyZWQga2V5IG11dGF0aW9ucywgSSBmZWVsIGxpa2UgaXQgd291bGRu4oCZdCBiZSBt dWNoIG9mIGEgc3RyZXRjaCB0byBtYWtlIGl0IHdvcmsgb24gdG9wIG9mIGEgZm9yd2FyZCBzZWNy ZXQgcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPk9mIGNvdXJzZSwgb25lIHBvc3NpYmxlIHNldCBvZiByZXF1aXJl bWVudHMgY291bGQgdG9sZXJhdGUgZXZpY3RlZCBncm91cCBtZW1iZXJzIHJldGFpbmluZyBhY2Nl c3MgdG8gdGhlIGdyb3VwIGVuY3J5cHRpb24ga2V5cyDigJMgd2hpY2ggd291bGQgcmVuZGVyIG15 IGFib3ZlIHBvaW50IG1vb3Qg4oCTIGJ1dCB0aGlzIHdvdWxkIGZlZWwgdG8gbWUNCiBsaWtlIHF1 aXRlIGEgc3RyYW5nZSBzZWN1cml0eSBwcm9wZXJ0eSB0byBoYXZlLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjgvMDIv MjAxOCwgMjM6MTksICZxdW90O01MUyBvbiBiZWhhbGYgb2YgRXJpYyBSZXNjb3JsYSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1scy1ib3VuY2VzQGlldGYub3JnIj5tbHMtYm91bmNlc0BpZXRm Lm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JA cnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+SGkg RGF2ZSwNCjxvOnA+PC9vOnA+PC9hPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JIGNlcnRhaW5seSBhZ3JlZSB3 aXRoIHlvdSB0aGF0IHRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgYXBwbGljYXRpb25zIG1pZ2h0 IHdhbnQgdG8gYXJjaGl2ZSBjb21tdW5pY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5HZW5lcmFsbHksIEkgdGhpbmsgdGhlIHJpZ2h0IGFuc3dlciB0byB0 aGVzZSwgaG93ZXZlciwgaXNuJ3QgdG8gbW9kaWZ5IHRoZSBtZXNzYWdpbmcgcHJvdG9jb2wgYnV0 IHJhdGhlciB0byBhZGQgdGhhdCBmdW5jdGlvbmFsaXR5IG9uIHRoZSBtZXNzYWdpbmcgYXBwIG92 ZXIgdGhlIHRvcC4NCiBUaGF0IGFsc28gaXMgYSBtdWNoIGVhc2llciB3YXkgdG8gZG8gbmV3IGRl dmljZSBoaXN0b3J5IHN5bmM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+T24gV2VkLCBGZWIgMjgsIDIwMTggYXQgOToxNCBBTSwgRGF2ZSBDcmlk bGFuZCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkYXZlQGNyaWRsYW5kLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmRh dmVAY3JpZGxhbmQubmV0PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5IaSBmb2xrcyw8YnI+DQo8YnI+ DQpXaGlsZSBJJ20gcmVhbGx5IHBsZWFzZWQgdG8gc2VlIE1MUywgYW5kIEkgZ2VuZXJhbGx5IGxp a2UgdGhlIGlkZWEgb2Y8YnI+DQpGb3J3YXJkIFNlY3JlY3ksIHRoZXJlJ3MgYSBjb3VwbGUgb2Yg dXNlIGNhc2VzIHdoZXJlIGl0IG1pZ2h0IGJlIHdvcnRoPGJyPg0KYXZvaWRpbmcuIEZlZWwgZnJl ZSB0byBjb3JyZWN0IG1lIGlmIHRoZXNlIGFyZSBpbiBmYWN0IHBvc3NpYmxlIHdpdGg8YnI+DQpG b3J3YXJkIFNlY3JlY3kuIEJvdGggdGhlc2UgcmVsYXRlIHRvIGFyY2hpdmFsIGFjY2VzcyB0byBw YXN0PGJyPg0KbWVzc2FnZXM6PGJyPg0KPGJyPg0KKiBVWCAtIFNvbWUgdXNlcnMgKGFjdHVhbGx5 IGFsbCBvZiB0aGVtKSB3b3VsZCBsaWtlIHRvIGJlIGFibGUgdG88YnI+DQppbnN0YWxsIGNsaWVu dCBzb2Z0d2FyZSBvbiBhIG5ldyBkZXZpY2UgYW5kIGhhdmUgdGhlaXIgaGlzdG9yaWNhbDxicj4N Cm1lc3NhZ2VzIGF2YWlsYWJsZSB0byB0aGVtLiBNb3N0ICZxdW90O2J1c2luZXNzJnF1b3Q7IG1l c3NhZ2luZyBzeXN0ZW1zIHNlZW0gdG88YnI+DQp3b3JrIHRoaXMgd2F5LCBhcyB3ZWxsIGFzIGEg bnVtYmVyIG9mIGNvbnN1bWVyLWdyYWRlIHN5c3RlbXMuIFRoZTxicj4NCm5hdHVyZSBvZiBGb3J3 YXJkIFNlY3JlY3kgbWVhbnMgdGhhdCBhbiBhcmNoaXZlIHdvdWxkIG5lZWQgdG8gYmUgaGVsZDxi cj4NCm9uIG9uZSBkZXZpY2UgYW5kIHJlLXNlbnQgdG8gYW5vdGhlciB0aHJvdWdoIHRoZSBuZXR3 b3JrLCB3aGljaCBpczxicj4NCnRyaWNraWVyIHRvIG1hbmFnZSwgYW5kIGlzIHJlbGlhbnQgb24g bXVsdGlwbGUgZGV2aWNlcyBiZWluZyBvbmxpbmUgYXQ8YnI+DQpvdmVybGFwcGluZyB0aW1lcy4g QWx0ZXJuYXRlbHksIHRoZSBhcmNoaXZhbCBjb3B5IG1pZ2h0IGJlIHJlLXVwbG9hZGVkPGJyPg0K dG8gdGhlIHNlcnZlciB1c2luZyBhIHN0YXRpYyBlbmNyeXB0aW9uIGtleSwgSSBzdXBwb3NlLCB3 aGljaCB3b3VsZDxicj4NCnJhdGhlciBzcG9pbCB0aGUgcG9pbnQuPGJyPg0KPGJyPg0KKiBSZXRl bnRpb24gLSBNYW55IGJ1c2luZXNzIGFuZCBnb3Zlcm5tZW50IGRlcGxveW1lbnRzIGhhdmUgbWFu ZGF0b3J5PGJyPg0KcmV0ZW50aW9uIHJlcXVpcmVtZW50cy4gQW4gZXhhbXBsZSBpcyBNSUtFWS1T QUtLRSwgcHJvbW90ZWQgaW4gcGFydCBieTxicj4NCnRoZSBVSyBHb3Zlcm5tZW50IGZvciBpdHMg b3duIGNvbW11bmljYXRpb25zLCB3aGljaCB1c2VzIG1hbmRhdG9yeSBrZXk8YnI+DQplc2Nyb3cg dG8ga2VlcCBhbiBhcmNoaXZlZCBjb3B5IG9mIHRoZSBtZXNzYWdlcyBhY2Nlc3NpYmxlIHRvIHRo ZTxicj4NCmJ1c2luZXNzIHVuaXRzIGludm9sdmVkLiBBbiBhZHZhbnRhZ2Ugb2YgdGhlIFNBS0tF IHN5c3RlbSBpcyB0aGF0IGl0PGJyPg0KYWxsb3dzIHRoZSBrZXkgZXNjcm93IHRvIGJlIG9mZmxp bmUsIGxpbWl0aW5nIGF0dGFjayBvcHBvcnR1bml0aWVzLjxicj4NCjxicj4NCkdpdmVuIHRoZSBs YXR0ZXIsIGZvciBleGFtcGxlLCBJIGNvdWxkIG5vdCB1c2UgYW4gTUxTLWJhc2VkIHN5c3RlbSB0 bzxicj4NCmRpc2N1c3MgYSB0YXggcHJvYmxlbSB3aXRoIHRoZSBhdXRob3JpdHksIGFuZCBzaW5j ZSBJJ20gdW5saWtlbHkgdG88YnI+DQpoYXZlIGEgU0FLS0UtYmFzZWQgbWVzc2FnaW5nIGNsaWVu dCwgSSdtIHVubGlrZWx5IHRvIGhhdmUgZW5jcnlwdGVkPGJyPg0KbWVzc2FnaW5nIHRvIG15IHRh eCBhdXRob3JpdHkgYXQgYWxsIC0gd2hpY2ggc2VlbXMgc2lnbmZpY2FudGx5IHdvcnNlPGJyPg0K dGhhbiBtZXJlbHkgaGF2aW5nIG5vIEZvcndhcmQgU2VjcmVjeS48YnI+DQo8YnI+DQpOb25lIG9m IHRoaXMgaXMgdG8gc2F5IHRoYXQgRm9yd2FyZCBTZWNyZWN5IHNob3VsZCBiZSBhdm9pZGVkPGJy Pg0KZW50aXJlbHksIG9mIGNvdXJzZS48YnI+DQo8YnI+DQpEYXZlLjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTUxTIG1haWxp bmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5NTFNAaWV0Zi5vcmc8L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtj PTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7 bT1xTDhYd1k0REsxM0lmMHpwYm10NnBjU0UzaUVsNUViS1QwRlk3TF9hXy1RJmFtcDtzPTBSclhh Sk5tMFFYbWtyZzVXOXNSaFA2ZmQ2aXdmaUszSHBxN0VQcGZtanMmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8L3NwYW4+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_B2A5860D01544E4386D346F0FAC2F75Cfbcom_-- From nobody Wed Feb 28 16:07:09 2018 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 7E0DE126C2F for ; Wed, 28 Feb 2018 16:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8xhIFH1zL9B for ; Wed, 28 Feb 2018 16:07:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB96412426E for ; Wed, 28 Feb 2018 16:07:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3F147BE50; Thu, 1 Mar 2018 00:07:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAm_ghILBEwi; Thu, 1 Mar 2018 00:07:00 +0000 (GMT) Received: from [10.200.0.239] (unknown [193.180.218.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49357BE4D; Thu, 1 Mar 2018 00:07:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1519862820; bh=cTl0MV2sP4wVGyW7+TJ0gf75fDQGkyrrKUzV8v3XQHU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=3GVjfRi31JlgIvNWiVJ76mbw+wHoJ7/LQDwgI1K/pm+dQ/bfaVMLw4nBUmRvg+KCq CayEpJgRBQjs/nd9zRJykXCdVrg4CUdLz4MYkaHbdAnnG34M32B2agMuykKq0i00MR EywR9SsdI7cc66T0qjesXDi8hNzG1xXcOeL6dNbk= To: Dave Cridland Cc: mls@ietf.org References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <7a138a3d-0889-59b4-2d20-c7acd1caab98@cs.tcd.ie> Date: Thu, 1 Mar 2018 00:06:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="47BAlBFzSJIL6QzgUdQDZzqz1bPxoAT5F" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 00:07:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --47BAlBFzSJIL6QzgUdQDZzqz1bPxoAT5F Content-Type: multipart/mixed; boundary="a9vzlAoQaHNPYbEywNNDXESLwqt2OVyue"; protected-headers="v1" From: Stephen Farrell To: Dave Cridland Cc: mls@ietf.org Message-ID: <7a138a3d-0889-59b4-2d20-c7acd1caab98@cs.tcd.ie> Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy References: In-Reply-To: --a9vzlAoQaHNPYbEywNNDXESLwqt2OVyue Content-Type: multipart/mixed; boundary="------------ADBCF97BD75B88232E5E7B5B" Content-Language: en-GB This is a multi-part message in MIME format. --------------ADBCF97BD75B88232E5E7B5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/02/18 22:56, Dave Cridland wrote: > On 28 February 2018 at 21:16, Stephen Farrell wrote: >> >> Hiya, >> >> On 28/02/18 17:14, Dave Cridland wrote: >>> Given the latter, for example, I could not use an MLS-based system to= >>> discuss a tax problem with the authority, and since I'm unlikely to >>> have a SAKKE-based messaging client, I'm unlikely to have encrypted >>> messaging to my tax authority at all - which seems signficantly worse= >>> than merely having no Forward Secrecy. >> >> Sorry, why is transport layer security not sufficient between you >> and your tax authority? >> >=20 > Because it's not a single hop. >=20 > Supposing my tax authority uses XMPP, for example, and so has (in my > case) hmrc.gov.uk as an XMPP domain. I use some commercialish XMPP > provider. I don't want my provider to be able to read my tax messages, > nor do I want them archived in plaintext on the server (although I > probably do want a verifiable record). Meanwhile, HMRC wants to keep > an archived, but secured, copy at their end, viewable by their > organisation. I see no evidence that revenue.ie would ever prefer to handle tax information via any intermediary when they have the option to provide a URL to a tax payer or their agent. But perhaps you do have a convincing use-case along those lines. If so, then I'd say describing that, rather than asking to back off from forward secrecy, might be a better approach at this stage (even if your concern is really with the FS aspects of current MLS proposals). >=20 >> I'm unclear as to why the security guarantees (aimed for) between >> groups of people ought be reduced in order to meet the goals of >> securing communications between a person and a service provider. >> >=20 > I'm not suggesting they should be. FWIW, that's how I read your message. Apologies if I misread it. >=20 > I am suggesting that it might be nice if my options were not simply FS = or FO. FO? >=20 > (Besides which, the archives in a non-FS situation gain some security > guarantees, too). Again, specifics there would be useful. I can't evaluate the sentence above. >=20 >> I do agree that it'd be good if a user of some application could >> add a new device and still see old messages, but I'm not at all >> clear that's that significant (for the crypto) since people will >> always need to have some kind of fallback to handle cases where >> they've lost state. >=20 > Assume a FS-only message transfer. In that case, how do we recover > missing messages?=20 I've no idea. But MLS isn't aiming to provide interoperable messaging (sadly but understandably IMO), so that seem a tad out of scope, as ekr pointed out. > We have to transport those from another device that > has them. That's a perfectly reasonable concept, and one that has been > tried before in Skype. Unfortunately, as mobile devices replaced > desktop/laptop combinations as the dominant device, they switched away > from the design back to centrally-held archives since the clever > synchronisation options simply didn't work. I'm fine if MLS is only usable by some subset of interpersonal messaging applications myself, even if the precise delineation of the set of applications that can use MLS isn't precisely known. (So long as there are a useful set of applications that can use MLS.) >=20 > Of course, there are users who prefer the trade-off of higher security > and no (or limited) archives. Such users would, one hopes, be warned > about the change in security should they enter into a conversation > with someone who cannot (or will not) support FS. I don't think such subtle differences are at all desirable myself. Cheers, S. >=20 > Dave. >=20 --------------ADBCF97BD75B88232E5E7B5B Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------ADBCF97BD75B88232E5E7B5B-- --a9vzlAoQaHNPYbEywNNDXESLwqt2OVyue-- --47BAlBFzSJIL6QzgUdQDZzqz1bPxoAT5F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJal0QiAAoJEFqy+vF7FyvqER4QAMI/uKHAKcLJgKpaqp3cqzqv BiShEHA7uEFdF1GCdE8zgDQgM1Lc0oPPzcmtq+MRsxs7qebehZJi/jzieHV+TAEh SLc2U7Xuwtftgdwj+zbQRi19eqPbI8eYihc6rsa7TgygSPU8kN9nZIgILhW7P8ZC RN9yskz/kQypr+ChHRewLzHYRUblEmk4Q1cS0kQrf7tTl/m8b2skJmnH9oWnBEJA Zm7BialV6BWtwoTqBylcEV/OX5izXyRW5VG5OVPugUFsJ9KXMvurhlVSoRSlDZqB xusfO9ZFCL/9MzJhOtU8GsbsEyXrhKA9bftMJAhPAyL1KgabO3qB/jMUK+TsnP04 x0WSaa/GG5FOHvBdV2DyHY3pJpwN9VVbSxx3s1g4pdVvKgUN0gngfsVWI1AqNh7p o6RsbXhCPicLjBxazBaynvDfmD2StnfrLk3eo/IH1YDoju6RZFyLTNMdqecoZyEd a4YbjLqe6e0jgT1wn1dSxCNcS3hTxu9+NqNU/FlDVXxey7NND9enC6YGA28peyNm NuF0Opoh3KcsiPOGIbuXizMZ01LIvfnToVYpM1jAbUxr6yjl/KxY7oudjkV3HTac TyZjdkFoiyblVWIcw47+q/RpfAvtWb9jPXtUALuPBnqoq8VxdqDoy5vVpqj5ZIJ9 am4nqXMiMa3qO+99u0ST =7IqO -----END PGP SIGNATURE----- --47BAlBFzSJIL6QzgUdQDZzqz1bPxoAT5F-- From nobody Wed Feb 28 17:10:21 2018 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 CE45112D7F9 for ; Wed, 28 Feb 2018 17:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1yDXSeIqkVk for ; Wed, 28 Feb 2018 17:10:19 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 0BBC812D7F6 for ; Wed, 28 Feb 2018 17:10:19 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id f11so4086840otj.12 for ; Wed, 28 Feb 2018 17:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PVmM8h6Y7gDz/oZw28kISyNZh2H0WwADMNHqpDNQ274=; b=PS9q8w/yGeVSHXQqq20GGRYhj8/Ske7kqmP1MkuWhhkTyTlECFewRo43YEttQmtg/P ePFfxk/E7JUJn1SYu2AECf4g5hqOgkO3n79aK5fMdFczHop9lfGxBrHgqQBTZVLmyZkd oMF9nR69h3rzBreICAJ0BmZ7qSrVYmhv8t/QtYBQdKtEwg0b6kVW+2LEFnUznZr6nwJs 2NHmgKvElen7VVf/pd4yCtG+gHzJGlrTjw9aq7/sOEqQXfHChfH4BYHRmhLzuv5OiMxU fHb/cYvrX9omk+10AUQaF2WzzDDH+b8Ym1ImOA+opi1SbtIRnrdZooFg7Ab7SX5EU39B KnQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PVmM8h6Y7gDz/oZw28kISyNZh2H0WwADMNHqpDNQ274=; b=nohWPlwnY3Y78kaozM0MxavIrh03KHF9t2w5pz1aI6Mk3mEnwJXJuhKBbhdEhbfISI 09kFD6A4myizMDHK9h3WBnWEFINg2KA5DBkG8zBcr0RL0Hg9AARx4nz9ok6trYbet5d6 1y3HDivYubwjaFntrERfHs3xXUcb0TF6zoXbEbwVyLLicRbVjMMKCOTi/lqv20mZSnFJ HgeCL8IOMH+jsvpwu7GPH/8lUuSrwQkYF1V/h0bF4t38yE8YBgiawpQ2zJH2I0ME52KJ O7PW8T6a4/XmAivPaQSDIcjEzF7yy6Lq1G6XouhwQqDTTLiXItfkVmpSbcETVlZABt02 4yfQ== X-Gm-Message-State: AElRT7FvTpmThdC7oxgjm2IpgACYx8hQZKRSI2DfqqTCIYMWOy7B9UEJ 5j/2tq0cRfAmecv061ltBEImsXk7TwYsSPPdUkM= X-Google-Smtp-Source: AG47ELuxzL8lH+Q26DDyjh/1GFiLejJ83tRDPMr0bXNfBOT7X4TbCEk3jnRdxGPLb6j97I931koJhiEMTiJfpGB0Q6M= X-Received: by 10.157.3.196 with SMTP id f62mr54924otf.360.1519866618101; Wed, 28 Feb 2018 17:10:18 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Wed, 28 Feb 2018 17:10:17 -0800 (PST) In-Reply-To: <20180228234104.14fde460@T-200> References: <20180228222800.0a978ded@T-200> <20180228234104.14fde460@T-200> From: Phillip Hallam-Baker Date: Wed, 28 Feb 2018 20:10:17 -0500 X-Google-Sender-Auth: 6h3cI8s9NKpyzF7dFQlkHDJu8Ig Message-ID: To: Dennis Jackson Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c03c326e0c5e305664f8530" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 01:10:21 -0000 --94eb2c03c326e0c5e305664f8530 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 6:41 PM, Dennis Jackson wrote: > > =E2=80=8BThe cost of this shared state is far from trivial at the proto= col > > level as both the sending and receiving device have to be in > > synchronization. What happens when Alice and Bob have a dozen > > devices? Then we have 144 sets of shared state.=E2=80=8B > > Phillip, it's clear you've read neither the MLS draft, nor the paper it > is based on. For example: one of the key contributions is a reduction in > the amount of shared state from O(n^2) to O(log n) > =E2=80=8BIt is pretty clear to me that you need to stop making assumptions = about what other people have read. You are being very rude and you need to stop. NOW. These are complicated issues and I for one would never assume that I had written a paper that was clear enough for everyone to understand immediately. Further, it is far from clear to me that the paper addresses the multiple devices per user as distinct from the multiple user problem. The draft has all of two paragraphs on multiple devices. I have spent three years working on the problem of sharing keys across multiple devices and it requires more than two paragraphs to address all the issues, I am sure.=E2=80=8B =E2=80=8B =E2=80=8BMy exchange is O(n). If a participant drops out, the others can re= key using the existing information.=E2=80=8B > > If this group is not interested in open discussion, it might be in > > the wrong standards organization. > > Trying to shut down discussion of other requirements is a REALLY BAD > > predictor of success in IETF. > > Go talk to the DANE folk and see how that worked for them. > > The discussion on PFS has been done to death, both on the TLS mailing > list and in numerous other places and I would hate to see us repeat it > for little gain. =E2=80=8BWell hate away=E2=80=8B. This is a different problem to TLS because we have more than two parties and it changes matters. One of the things I only just realized is that PFS is not even a property of the protocol, it is a property of a key in the exchange and not of the exchange itself. I can modify my key exchange to support use cases in which the key exchange has forward secrecy with respect to the keys of Alice and Bob but not Doug or Carol. I am not sure why you would want to do that yet. But you can do it. =E2=80=8BActually, I do have a use case. Let us say that we want FS with respect to each of the keys of Alice, Bob, Carol and Doug but =E2=80=8Bthey don't all want to inject fresh FS informat= ion at the exact same time. Let us say Alice has her key in a HSM while Bob is using a soft key, Alice is sitting in a SOC and Bob is a field agent on Moscow Rules. Bob probably wants for FS their key every ten minutes. Alice might be good for a week. > In the end, TLS 1.3 mandates that PFS be used in > every connection. I find it hard to imagine that MLS will aspire > to a weaker security goal than TLS, but as you say, it is for the > group to decide. If we have PFS at the TLS level, why do we need it at the messaging layer as well? Or are you thinking you will be running your application over IP? In general, I think that thinking about the protocol more is what leads to higher security. Not simply insisting on a set of features we already know how to implement. --94eb2c03c326e0c5e305664f8530 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Fe= b 28, 2018 at 6:41 PM, Dennis Jackson <dennis.jackson@cs.ox.ac.uk= > wrote:
&= gt; =E2=80=8BThe cost of this shared state is far from trivial at the proto= col
> level as both the sending and receiving device have to be in
> synchronization. What happens when Alice and Bob have a dozen
> devices? Then we have 144 sets of shared state.=E2=80=8B

Phillip, it's clear you've read neither the MLS draft, nor t= he paper it
is based on. For example: one of the key contributions is a reduction in the amount of shared state from O(n^2) to O(log n)
=E2=80= =8BIt is pretty clear to me that you need to stop making assumptions about = what other people have read.=C2=A0

You are being very rude and you need to stop. NOW.


These are complicated issues and I for one would= never assume that I had written a paper that was clear enough for everyone= to understand immediately.=C2=A0

Further, it is far from clear to me that the paper addresses the= multiple devices per user as distinct from the multiple user problem. The = draft has all of two paragraphs on multiple devices. I have spent three yea= rs working on the problem of sharing keys across multiple devices and it re= quires more than two paragraphs to address all the issues, I am sure.=E2=80= =8B
= =E2=80=8B

=E2=80=8BMy exchange is O(n). If a participant drops out, the oth= ers can rekey using the existing information.=E2=80=8B

= =C2=A0
> If this group is not interested in open discussion, it might be in
> the wrong standards organization.
> Trying to shut down discussion of other requirements is a REALLY BAD > predictor of success in IETF.
> Go talk to the DANE folk and see how that worked for them.=C2=A0

The discussion on PFS has been done to death, both on the TLS mailin= g
list and in numerous other places and I would hate to see us repeat it
for little gain.
=C2=A0
=E2=80=8BWell hate away=E2=80=8B.

This is a different problem to TLS = because we have more than two parties and it changes matters. One of the th= ings I only just realized is that PFS is not even a property of the protoco= l, it is a property of a key in the exchange and not of the exchange itself= .

I can modify my key exc= hange to support use cases in which the key exchange has forward secrecy wi= th respect to the keys of Alice and Bob but not Doug or Carol. I am not sur= e why you would want to do that yet. But you can do it.

=E2=80=8BActually, I do have a use case.=C2= =A0

<= div class=3D"gmail_default" style=3D"font-size:small">Let us say that we wa= nt FS with respect to each of the keys of Alice, Bob, Carol and Doug but = =E2=80=8Bthey don't all want to inject fresh FS information at the exac= t same time. Let us say Alice has her key in a HSM while Bob is using a sof= t key, Alice is sitting in a SOC and Bob is a field agent on Moscow Rules. = Bob probably wants for FS their key every ten minutes. Alice might be good = for a week.
=C2=A0
In = the end, TLS 1.3 mandates that PFS be used in
every connection. I find it hard to imagine that MLS will aspire
to a weaker security goal than TLS, but as you say, it is for the
group to decide.

If we have PFS at the TLS level, why do we nee= d it at the messaging layer as well? Or are you thinking you will be runnin= g your application over IP?


In general, I think that thinking about the protocol more is what leads to= higher security. Not simply insisting on a set of features we already know= how to implement.
--94eb2c03c326e0c5e305664f8530-- From nobody Wed Feb 28 18:21:59 2018 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 DA23C12D95F for ; Wed, 28 Feb 2018 18:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PxzmtmBHQEKV for ; Wed, 28 Feb 2018 18:21:56 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A377712D95B for ; Wed, 28 Feb 2018 18:21:55 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id v65so4462816wrc.11 for ; Wed, 28 Feb 2018 18:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=srbXwhWn/LugVirreAB+X343RbDFt/xrTUJ8df3PgC8=; b=dkKLXrXj71nVdyqK5AMRH5USAunR9ZFz4aFCTBIgLhXXHT02lSZqhnrLqjxPnForNP igbdBvWvjQwW5GVv3TaX4Cb+05ZgVb5k9d+gAyD6PqEqU293Dr5INz0wyCubMGQpP9mH 6dLw9QbchSiEGvU1KdRbCpTa3DuFKZ3b+OmpK5u/5ezlDt+CMkPoW0DSo7Iy0xNE5m+i p3Gd4Ovgf1NA3V8n8ofsChkTpJAdBHeGCOVKbuOWClSNJ707oAR1L7A+mO8dPDUvAKTt Ue3yrjvDkEb2HDETX98zcfayfoe90aed9p2OVauyQYwO00fIH6EwlGy5mP/6L4pAmjM/ VdjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=srbXwhWn/LugVirreAB+X343RbDFt/xrTUJ8df3PgC8=; b=JsnPUvJgQ2ENxCGZKX1/4rU3tZ+MNr+MzXn1Jo5405+ZoYbAOCpnsQSnEmgn4/FQJG 4QNshHHRiICXa74VTLfswHuQtMTVMi4eRaJGLYdsK4DvPEaCPn2QBlcjuG6nZqKZE+xx G/MbW+Z6JkYvZrNGqt+sJpwOg3DUvPirTXCPoD/lDqr8hG5QPxI1dlySUFo83Uf+HLb7 /bZ7xkN8sB07+Z/4DITqrAw0x4YRJe/pYdJJ17Dy0SOA0f+Gilw9MzjW4xNuy4Gm+AZO O0dzAm36b8JYclsr2++yK46FLwqmmexTFkc4x8JSTZtASjqOpEHJ75WJoPVVoPJKikr8 p9BA== X-Gm-Message-State: APf1xPD9gfVs1wz1MRYc4hvG5v4v3vgfXfWe5tb6VyuXMv8EBF//hGLv CLXKQTE/R996pzI2F8L5i3bSZcaieqKrjvPkbgHDIA== X-Google-Smtp-Source: AG47ELtvxLGj5u/t81KJOdA4y1bGbunhVlVY/uOmHU007jJrE8IjJsJsUpgTnL/iZTz8NVcJjSvvi+lgxrbF1ECwmG4= X-Received: by 10.223.169.110 with SMTP id u101mr182458wrc.31.1519870914064; Wed, 28 Feb 2018 18:21:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Wed, 28 Feb 2018 18:21:53 -0800 (PST) Received: by 10.28.12.140 with HTTP; Wed, 28 Feb 2018 18:21:53 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Wed, 28 Feb 2018 21:21:53 -0500 Message-ID: To: Dave Cridland Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="f403045cf0bef003ed05665085e1" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 02:21:58 -0000 --f403045cf0bef003ed05665085e1 Content-Type: text/plain; charset="UTF-8" Re-adding the list. On Feb 28, 2018 18:21, "Richard Barnes" wrote: > Hey Dave, > > Thanks for the feedback. This is a good point to clarify. It had also > crossed my mind, as the product I work with most in my day job also has > retention features. > > However, I kind of chose not to worry about it, under the following > theory: You can always build a non-forward-secret system out of a > forward-secret one. For example, you could use the FS keys to encrypt a > long-term key, passing it forward across FS boundaries. > > So kind of like Raphael was saying, I figured an application with > history-sharing or retention needs could wrap see extra stuff around MLS to > dial back the appropriate knobs. > > --Richard > > On Feb 28, 2018 12:14, "Dave Cridland" wrote: > >> Hi folks, >> >> While I'm really pleased to see MLS, and I generally like the idea of >> Forward Secrecy, there's a couple of use cases where it might be worth >> avoiding. Feel free to correct me if these are in fact possible with >> Forward Secrecy. Both these relate to archival access to past >> messages: >> >> * UX - Some users (actually all of them) would like to be able to >> install client software on a new device and have their historical >> messages available to them. Most "business" messaging systems seem to >> work this way, as well as a number of consumer-grade systems. The >> nature of Forward Secrecy means that an archive would need to be held >> on one device and re-sent to another through the network, which is >> trickier to manage, and is reliant on multiple devices being online at >> overlapping times. Alternately, the archival copy might be re-uploaded >> to the server using a static encryption key, I suppose, which would >> rather spoil the point. >> >> * Retention - Many business and government deployments have mandatory >> retention requirements. An example is MIKEY-SAKKE, promoted in part by >> the UK Government for its own communications, which uses mandatory key >> escrow to keep an archived copy of the messages accessible to the >> business units involved. An advantage of the SAKKE system is that it >> allows the key escrow to be offline, limiting attack opportunities. >> >> Given the latter, for example, I could not use an MLS-based system to >> discuss a tax problem with the authority, and since I'm unlikely to >> have a SAKKE-based messaging client, I'm unlikely to have encrypted >> messaging to my tax authority at all - which seems signficantly worse >> than merely having no Forward Secrecy. >> >> None of this is to say that Forward Secrecy should be avoided >> entirely, of course. >> >> Dave. >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --f403045cf0bef003ed05665085e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re-adding the list.=C2=A0

On Feb 28, 2018 18:21, "Richard Barnes= " <rlb@ipv.sx> wrote:
Hey Dave,

Thanks for the feedback.=C2=A0 This is a good point to clarify.= =C2=A0 It had also crossed my mind, as the product I work with most in my d= ay job also has retention features.=C2=A0

=
However, I kind of chose not to worry about it, under the= following theory: You can always build a non-forward-secret system out of = a forward-secret one.=C2=A0 For example, you could use the FS keys to encry= pt a long-term key, passing it forward across FS boundaries.=C2=A0=C2=A0

So kind of like Raphael wa= s saying, I figured an application with history-sharing or retention needs = could wrap see extra stuff around MLS to dial back the appropriate knobs.= =C2=A0

--Richard

On Feb 28, 20= 18 12:14, "Dave Cridland" <dave@cridland.net> wrote:
Hi folks,

While I'm really pleased to see MLS, and I generally like the idea of Forward Secrecy, there's a couple of use cases where it might be worth<= br> avoiding. Feel free to correct me if these are in fact possible with
Forward Secrecy. Both these relate to archival access to past
messages:

* UX - Some users (actually all of them) would like to be able to
install client software on a new device and have their historical
messages available to them. Most "business" messaging systems see= m to
work this way, as well as a number of consumer-grade systems. The
nature of Forward Secrecy means that an archive would need to be held
on one device and re-sent to another through the network, which is
trickier to manage, and is reliant on multiple devices being online at
overlapping times. Alternately, the archival copy might be re-uploaded
to the server using a static encryption key, I suppose, which would
rather spoil the point.

* Retention - Many business and government deployments have mandatory
retention requirements. An example is MIKEY-SAKKE, promoted in part by
the UK Government for its own communications, which uses mandatory key
escrow to keep an archived copy of the messages accessible to the
business units involved. An advantage of the SAKKE system is that it
allows the key escrow to be offline, limiting attack opportunities.

Given the latter, for example, I could not use an MLS-based system to
discuss a tax problem with the authority, and since I'm unlikely to
have a SAKKE-based messaging client, I'm unlikely to have encrypted
messaging to my tax authority at all - which seems signficantly worse
than merely having no Forward Secrecy.

None of this is to say that Forward Secrecy should be avoided
entirely, of course.

Dave.

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