From nobody Thu Oct 1 18:42:06 2020 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 6761A3A0403; Thu, 1 Oct 2020 18:42:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls-chairs@ietf.org, sean@sn3rd.com, mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.18.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160160292334.12673.16577649353522083609@ietfa.amsl.com> Date: Thu, 01 Oct 2020 18:42:03 -0700 Archived-At: Subject: [MLS] mls - New Meeting Session Request for IETF 109 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 01:42:03 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the mls working group. --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack privacypass masque Key Participant Conflict: acme artarea dispatch perc People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 2 11:19:56 2020 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 7F5483A1663 for ; Fri, 2 Oct 2020 11:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3n0sTuXO031 for ; Fri, 2 Oct 2020 11:19:54 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8C23A166A for ; Fri, 2 Oct 2020 11:19:54 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id f11so1340680qvw.3 for ; Fri, 02 Oct 2020 11:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=YVBDl/2+7Zr0MBkJDPnrysYycFbjdrIVj4TSiAjzA2E=; b=RbmqLRR/p6KNJk4LKjnPum/SmBcCnJwob8CCG78BAjnlewkRYzPNiBypgEwiI2cPkk e+oBzkvPQpD3DfsNX3eSROXmMnKyECOgkMbTOwVYij6Xk1I7JbvZGETwU58K12Y6zI7W 66D4JtrsjWcBQp4XaPi1O1PMZljmvtQ/rDBgY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=YVBDl/2+7Zr0MBkJDPnrysYycFbjdrIVj4TSiAjzA2E=; b=JVi9+ku0Eqjw2Na0bU3nXaoTcpTJLgd+Pylixql3skCncLlVqJbCvMOMezRkDVxQng tTEU0R0GVqkJA82EqeQ7/VeZeMscaB16+/FI2u0fF+n7oJebAeWjcn2ZsLD5JUChih1X RDeH1dcsXVKlps0ESgXz6/cYFH3yQUSPfGB5lKZhGAYVeHOgHsko1Z+Krvve2iVDUDTg l1OKfjvwpI2oCIY9swN7I8aB/PnoLYkFty7oekggm6jvlSsvJGzNZouVD5YoDnTF2aqw EgQ597aip5s1jfzThQI1MEXIs5IyDcUfEwuCPhVN0U5OmCHCTjKyWFIfNOsyjCQxST3t t/jQ== X-Gm-Message-State: AOAM531LbastF8ldkd8fWoKX7FPNf5079nqPmwi4fDrHNRv9vOdFUFog wciyolf+t9r9Ikq/nOKqG3Lja8Rt0ty//w== X-Google-Smtp-Source: ABdhPJzdwqRM84XGgi4bk2Vi8YJHzP0TTkKiupvykfkSuHgKUAdgAxKWrojsoxoAQEwxY1y+Q55jhQ== X-Received: by 2002:a0c:8d84:: with SMTP id t4mr3533767qvb.36.1601662792894; Fri, 02 Oct 2020 11:19:52 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id r187sm1534770qkc.63.2020.10.02.11.19.51 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 11:19:51 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Fri, 2 Oct 2020 14:19:51 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [MLS] MLS Virtual Interims: 6 and 20 October X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 18:19:56 -0000 In case you missed the meeting notices flying by, Nick and I requested = two more virtual interims sessions based on the last interim. They are = scheduled for October 6th and 20th @ 15:00 UTC. Please note this is one = hour early than our previous interims! The agenda will mirror what we=E2=80=99ve been doing previous, i.e., = addressing github issues and pull requests [1]. Cheers, spt [1] = https://datatracker.ietf.org/doc/slides-interim-2020-mls-23-sessa-chair-sl= ides/= From nobody Fri Oct 2 11:25:12 2020 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 3485F3A1674 for ; Fri, 2 Oct 2020 11:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovg88S2uwVfo for ; Fri, 2 Oct 2020 11:25:09 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8653A1671 for ; Fri, 2 Oct 2020 11:25:09 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id s131so2507854qke.0 for ; Fri, 02 Oct 2020 11:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=CkR0OlnAkTCWomudZfxMLt3JK/II7Oq0RK1OovccOgM=; b=mPl9fRpQObm7TkzZIlInIV3sC3KSEtjhHfsd32zTNX+9MTDM8MrnfkBd9CqvJuIDnm YwV3Vlxu9RlOWzWIzX5VLJ50t64lr1Z49M2TZkYIBQf66EV9oZv10pz8i5CDd6mU4gTs CMvUsEYqHn0+rsMF7LHZUNez+OBY+wqO3D+dQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=CkR0OlnAkTCWomudZfxMLt3JK/II7Oq0RK1OovccOgM=; b=TFRrDfvvYNgT8DKwWZtUYcB5XVcgempbimmEv9dkOm+koXSb1KlpFtSJWkqnTpTddY 9UPzD7Qnlzeh9nk6N+x1q3OiDQqtZpelnqSBcRvuM9QDARg7qWAdBouEGC41cSKbHbR7 DKU34NFb5xusurKm7ikozQ1n8/1WAuWWCEV5Cw1xCA7OK/hPapUxKsrKIh9yhi3hrMVV 4DnrcTQXU60UuzFLYhIZBg6ecHrmid3rBVAS6h5y7cD4Nrhis2PA4xFg+x30OMEXbkTA c4GsMwRhchrimi6upiI+JE8LWDN0ZYxJJY9c9jHLr7B145yuhTYxV7zgucH/Di4D4KaQ Ckeg== X-Gm-Message-State: AOAM532o59IhymlYJwBca6X5ynCzNdMFbflaURa/I/PP5Ohd0IIaEyOA 9+tGyuXVd+kFZZgDCO2zPIXT9SFIQlCVSQ== X-Google-Smtp-Source: ABdhPJzeBXJJRnCF1AyH3A6S2VNE0crNb4JAhvCI4n+nvgVvbeQHpaOLNmmm/e/zjfZN/W/+4DJvNQ== X-Received: by 2002:a05:620a:1341:: with SMTP id c1mr3227804qkl.460.1601663107867; Fri, 02 Oct 2020 11:25:07 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id p30sm1574764qtd.89.2020.10.02.11.25.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 11:25:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Fri, 2 Oct 2020 14:25:05 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [MLS] MLS@IETF109 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 18:25:11 -0000 Nick and I also went ahead and requested a 1-hour slot for IETF109: = 16-20 November. Scheduling has not yet happened, but when we know more = we will let you know. spt= From nobody Sun Oct 4 00:41:09 2020 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 8607E3A128E for ; Sun, 4 Oct 2020 00:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=HZC0nfvj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qNI7OCMY 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 GSry2ZE5LaWH for ; Sun, 4 Oct 2020 00:41:04 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70603A128C for ; Sun, 4 Oct 2020 00:41:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3A49F5C009F for ; Sun, 4 Oct 2020 03:33:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 04 Oct 2020 03:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=x/zYfsHLDuTzwnfPNpaSOmTBuyLjz4h9nNLfGcOAayk=; b=HZC0nfvj P15ERrcCUhMiH9kaL3ekByYofPEQuEzGFq8uxN7bSgpJwiu6w6Gx4EkgKeE6fmAY xE8Ir+I9DU17J65oAcEzf+J0xT6b7PHfPCa9i0s4YnRag4zOX4+9WIEhryhAJ1XJ XlDjqQrNswNbITL8s2tDZJPP7LCf3hCeX8x3Ctmrqvm1Dn1UkDCoPJELPBcUAG/H 8+8mNQOHEWCl8HCyZVcvquzYRmIFZHbROtoCz6Jri5u9VwzQPbqmuKf71WoF0Zw7 sztvPdbdGFHfP+DvDD+UJ/XK436wbZTEOcvyfM5YDb+j1quzPQ0qx4Yq2HlgcvZe 7imWyDM9jDxFBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=x/zYfsHLDuTzwnfPNpaSOmTBuyLjz 4h9nNLfGcOAayk=; b=qNI7OCMYxfG/AZQjPQV5C+FS46Lnwi/pbwkw9UitGV3QL Eb8eDVa7PfdeWxA1kuj+RgSP1LsnGcb8kROYp6/iPp5DmryeMyPKOngoK/9jRJgM cSQMChkCSQWoB8IvtwZtEw3U1MB2ILdaxLPDqzB+3yiyZiN0q+ykVGTgNk9uqX6l 0Lwb5btdmWy0CcKB4f2OTWKNmcAkNXyXoeE962SX2etWWFDX4WfdlAGd19igWyp7 frvh9qO/ptvckBOI8SxIAB7SvLznefOtE8GOLgZjBrt6tUiaKvJ4xA+YZyeCozv6 0xNUIcGTVNsVGSNi9kUB1Gqde0PU47P61ZRLE9Jug== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeelgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepvddtrdeggedrleekrddufe elnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az12.internal.cloudapp.net (unknown [20.44.98.139]) by mail.messagingengine.com (Postfix) with ESMTPA id F34993064610 for ; Sun, 4 Oct 2020 03:33:05 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============9186588780218181265==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201004073305.F34993064610@mailuser.nyi.internal> Date: Sun, 4 Oct 2020 03:33:05 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 07:41:08 -0000 --===============9186588780218181265== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC0) 1 issues closed: - Mandatory Extensions vs. Fields https://github.com/mlswg/mls-protocol/i= ssues/405=20 Pull requests ------------- * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #408 Clarify X509Credential structure (1 by suhasHere) https://github.com/mlswg/mls-protocol/pull/408=20 1 pull requests merged: - Remove long term and explicitly prevent changing of identity https://github.com/mlswg/mls-protocol/pull/404=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============9186588780218181265== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 04, 2020

Issues

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

1 issues closed:

Pull requests

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

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============9186588780218181265==-- From nobody Mon Oct 5 05:35:45 2020 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 B629E3A09E5 for ; Mon, 5 Oct 2020 05:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEDOPxyouxyW for ; Mon, 5 Oct 2020 05:35:42 -0700 (PDT) Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050::465:101]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A632E3A09EA for ; Mon, 5 Oct 2020 05:35:42 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4C4g704HCbzKmks; Mon, 5 Oct 2020 14:35:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id KAP4llnTqf0N; Mon, 5 Oct 2020 14:35:36 +0200 (CEST) Date: Mon, 5 Oct 2020 14:35:35 +0200 (CEST) From: Konrad Kohbrok To: Franziskus Kiefer , "mls@ietf.org" Message-ID: <781922648.117964.1601901336014@office.mailbox.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: X-Rspamd-Score: -6.13 / 15.00 / 15.00 X-Rspamd-Queue-Id: 05FFB1711 X-Rspamd-UID: 9469d3 Archived-At: Subject: Re: [MLS] draft structure feedback and suggestions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 12:35:45 -0000 Hi everyone, I think Franziskus make some good points here. We've been making individual= changes all over the document, but the structure hasn't really changed for= quite a while. Maybe this would be a good time to take a look at the docum= ent as a whole? In addition to his mail below, Franziskus has also filed an issue https://g= ithub.com/mlswg/mls-protocol/issues/409.=20 @Sean: Any chance we can put it on the agenda for the meeting tomorrow? Cheers, Konrad > Franziskus Kiefer hat am 17.09.2020 13:18 ge= schrieben: >=20 >=20 > Hi all, >=20 >=20 > While trying to implement the MLS protocol from scratch I ran into a coup= le issues and I think there=E2=80=99s a general problem regarding the struc= ture of the draft. Note that these are all editorial issues. > Right now I see no straightforward way to implement the spec as there=E2= =80=99s no clear structure. To implement even the basic tree structure it= =E2=80=99s necessary to jump through the entire document. There=E2=80=99s a= lso a lot of prose and examples and very little implementable parts. >=20 > Let me give some examples: >=20 >=20 > Section 5 (Ratchet Trees) reads like a non-normative section (or paper). = The really interesting bit related to trees is in Appendix A. I suggest mov= ing the formal description of the tree from Appendix A to this section. It= =E2=80=99s impossible to implement this from the hand full examples here. > There=E2=80=99s no description in here on how the tree actually works. Fo= r example, adding a node to the tree is defined in 10.1.1 (Add). > The ratchet tree nodes as described in Section 5 don't hold a KeyPackage.= But Section 7 says =E2=80=9CAs the KeyPackage is a structure which is stor= ed in the Ratchet Tree and updated depending on the evolution of this tree= =E2=80=9D. > The tree nodes have a parent hash field, which is of course part of the r= atchet tree but shouldn=E2=80=99t be necessary for the description of the t= ree structure. > Also, the description of the tree hash (Section 7.5) follows the definiti= on of the parent_hash extension in Section 7.4 such that it is not entirely= clear which parent_hash is used there (extension or node value). > Section 5 also talks about commit messages without linking to them or int= roducing them. Having to talk about commit messages in this section is also= a little confusing. > The term =E2=80=9Chandshake message=E2=80=9D is first used in Section 7.8= (Key Schedule) but never introduced. This should probably happen in 10 (Gr= oup Evolution), which doesn=E2=80=99t talk about handshake messages at all = until 10.3 (Ratchet Tree Extension). >=20 >=20 > There are probably plenty more issues like this. But I don=E2=80=99t thin= k addressing any of these issues individually makes sense. I therefore sugg= est having an overhaul of the document structure. >=20 >=20 > The way I see MLS there are a set of high-level structures and components= that should be clearly described and built upon each other. There=E2=80=99= s a data structure (tree) that is used to represent a group. Then there is = the MLSgroupthat implements a specific semantic on the tree. Operations to = modify the group are specified in thehandshake protocol. Andapplication mes= sagesdefine messages encrypted with keys derived in the handshake protocol = with the key schedule. > The tree is a basic left-balanced binary tree and defines functions to cr= eate a tree, and add and remove nodes. > A group is the main part of MLS, a tree with nodes of a certain type. So = this part should describe whatnodeslook like and how the tree is used to co= mpute tree invariants and keys. > The handshake protocol defines all messages needed to perform operations = on the MLS group. >=20 >=20 > This is certainly not exhaustive and would need further refinement. But i= t=E2=80=99s the high-level structure I=E2=80=99d expect from the document. = I=E2=80=99m sure other structures would work as well. But what we currently= have isn=E2=80=99t what is needed to implement MLS imho. >=20 >=20 > Cheers, > Franziskus >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Mon Oct 5 11:12:12 2020 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 3DBFF3A0B6B for ; Mon, 5 Oct 2020 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPKDljlROIMt for ; Mon, 5 Oct 2020 11:12:07 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D019E3A0F67 for ; Mon, 5 Oct 2020 11:12:07 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id q63so13023690qkf.3 for ; Mon, 05 Oct 2020 11:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KycArNUlfqfBn3OgpyUq/2XRj4rxdAvaqFLg8GgT1pM=; b=gmGUf2PegG4U/TV6JcKGvrBuaw2PBZKLLNWjwUzN99Dr0in96yk61LiyWUz5aIRFyv VzipkcAxnrV6k5Ve/8u7eXXjC5zeGsVGaRr0DV4W+/OZtGyfAiBgJWaHuZ0lFDZLDsTW 3ZCbYNus14gc3rkaZFAak8xdEfQIyRZYJ0olI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KycArNUlfqfBn3OgpyUq/2XRj4rxdAvaqFLg8GgT1pM=; b=TbPpWpIcWWlVtKhhVdIwlXBEf2BJyYjGXvoCh/vo2CXoHmeNfVr8uWjJkcTBdGnvga J/R0Sz1dcZwiN23H6fFw4XuXzaRx0SxFnGBnLNEF3XfvFN4HwV7epRzf9mpGQhDMQHm2 Ctx7WkyPhRJ0HFfljoNz55LKfCb7RE7NSqLfNM6G5+ZO4/jnOb/GUjI+YhgCHpMVQj6j 2R/yKFBUJs7EMCCSEFdo6Ck036dVXqgtRhz8twZdOO2OBAzVe3ZwigyQAodR+Yoih+EM RkP6CexVCJoVc0NMworYNSTmOsSNMNAqbAYicYht02hBv1TCRvUkDAKq5s+fZqn/P/PE BJ1w== X-Gm-Message-State: AOAM530WVjuhgVh9z0Q07UtcRjro/E3JvNlvfjO5Ly4lLG/ccdb8CiSC UwP9NSat/FlYiogktEXTW3EAcvwm6x6FtWi3b1tlpA== X-Google-Smtp-Source: ABdhPJw87lXPiNPtVHwTq4p0a3JGA0i3VtREjhAzAnyTofT0h54fEOpsfpD/7GXzHygLXOqeCwLKB/ehVwkLkITKkxU= X-Received: by 2002:a05:620a:795:: with SMTP id 21mr1225561qka.131.1601921526643; Mon, 05 Oct 2020 11:12:06 -0700 (PDT) MIME-Version: 1.0 References: <781922648.117964.1601901336014@office.mailbox.org> In-Reply-To: <781922648.117964.1601901336014@office.mailbox.org> From: Brendan McMillion Date: Mon, 5 Oct 2020 11:11:55 -0700 Message-ID: To: Konrad Kohbrok Cc: Franziskus Kiefer , "mls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008de66305b0f06b5d" Archived-At: Subject: Re: [MLS] draft structure feedback and suggestions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 18:12:10 -0000 --0000000000008de66305b0f06b5d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think this belongs on the agenda. What Franziskus says is right, the MLS protocol document has become nonsensical over time. But right now we're focusing on substantive changes to the protocol and can rearrange when we've finished. On Mon, Oct 5, 2020 at 5:35 AM Konrad Kohbrok wrote: > Hi everyone, > > I think Franziskus make some good points here. We've been making > individual changes all over the document, but the structure hasn't really > changed for quite a while. Maybe this would be a good time to take a look > at the document as a whole? > > In addition to his mail below, Franziskus has also filed an issue > https://github.com/mlswg/mls-protocol/issues/409. > > @Sean: Any chance we can put it on the agenda for the meeting tomorrow? > > Cheers, > Konrad > > > Franziskus Kiefer hat am 17.09.2020 13:18 > geschrieben: > > > > > > Hi all, > > > > > > While trying to implement the MLS protocol from scratch I ran into a > couple issues and I think there=E2=80=99s a general problem regarding the= structure > of the draft. Note that these are all editorial issues. > > Right now I see no straightforward way to implement the spec as there= =E2=80=99s > no clear structure. To implement even the basic tree structure it=E2=80= =99s > necessary to jump through the entire document. There=E2=80=99s also a lot= of prose > and examples and very little implementable parts. > > > > Let me give some examples: > > > > > > Section 5 (Ratchet Trees) reads like a non-normative section (or paper)= . > The really interesting bit related to trees is in Appendix A. I suggest > moving the formal description of the tree from Appendix A to this section= . > It=E2=80=99s impossible to implement this from the hand full examples her= e. > > There=E2=80=99s no description in here on how the tree actually works. = For > example, adding a node to the tree is defined in 10.1.1 (Add). > > The ratchet tree nodes as described in Section 5 don't hold a > KeyPackage. But Section 7 says =E2=80=9CAs the KeyPackage is a structure = which is > stored in the Ratchet Tree and updated depending on the evolution of this > tree=E2=80=9D. > > The tree nodes have a parent hash field, which is of course part of the > ratchet tree but shouldn=E2=80=99t be necessary for the description of th= e tree > structure. > > Also, the description of the tree hash (Section 7.5) follows the > definition of the parent_hash extension in Section 7.4 such that it is no= t > entirely clear which parent_hash is used there (extension or node value). > > Section 5 also talks about commit messages without linking to them or > introducing them. Having to talk about commit messages in this section is > also a little confusing. > > The term =E2=80=9Chandshake message=E2=80=9D is first used in Section 7= .8 (Key Schedule) > but never introduced. This should probably happen in 10 (Group Evolution)= , > which doesn=E2=80=99t talk about handshake messages at all until 10.3 (Ra= tchet Tree > Extension). > > > > > > There are probably plenty more issues like this. But I don=E2=80=99t th= ink > addressing any of these issues individually makes sense. I therefore > suggest having an overhaul of the document structure. > > > > > > The way I see MLS there are a set of high-level structures and > components that should be clearly described and built upon each other. > There=E2=80=99s a data structure (tree) that is used to represent a group= . Then > there is the MLSgroupthat implements a specific semantic on the tree. > Operations to modify the group are specified in thehandshake protocol. > Andapplication messagesdefine messages encrypted with keys derived in the > handshake protocol with the key schedule. > > The tree is a basic left-balanced binary tree and defines functions to > create a tree, and add and remove nodes. > > A group is the main part of MLS, a tree with nodes of a certain type. S= o > this part should describe whatnodeslook like and how the tree is used to > compute tree invariants and keys. > > The handshake protocol defines all messages needed to perform operation= s > on the MLS group. > > > > > > This is certainly not exhaustive and would need further refinement. But > it=E2=80=99s the high-level structure I=E2=80=99d expect from the documen= t. I=E2=80=99m sure other > structures would work as well. But what we currently have isn=E2=80=99t w= hat is > needed to implement MLS imho. > > > > > > Cheers, > > Franziskus > > > > > > _______________________________________________ > > 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 > --0000000000008de66305b0f06b5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think this belongs on the agenda. What Franzis= kus says is right, the MLS protocol document has become nonsensical over ti= me. But right now we're focusing on substantive changes to the protocol= and can rearrange when we've finished.

On Mon, Oct 5, 2020 at 5:35 AM K= onrad Kohbrok <konrad.ko= hbrok@datashrine.de> wrote:
Hi everyone,

I think Franziskus make some good points here. We've been making indivi= dual changes all over the document, but the structure hasn't really cha= nged for quite a while. Maybe this would be a good time to take a look at t= he document as a whole?

In addition to his mail below, Franziskus has also filed an issue https://github.com/mlswg/mls-protocol/issues/409.

@Sean: Any chance we can put it on the agenda for the meeting tomorrow?

Cheers,
Konrad

> Franziskus Kiefer <franziskuskiefer@gmail.com> hat am 17.09.2020 13:18 = geschrieben:
>
>
> Hi all,
>
>
> While trying to implement the MLS protocol from scratch I ran into a c= ouple issues and I think there=E2=80=99s a general problem regarding the st= ructure of the draft. Note that these are all editorial issues.
> Right now I see no straightforward way to implement the spec as there= =E2=80=99s no clear structure. To implement even the basic tree structure i= t=E2=80=99s necessary to jump through the entire document. There=E2=80=99s = also a lot of prose and examples and very little implementable parts.
>
> Let me give some examples:
>
>
> Section 5 (Ratchet Trees) reads like a non-normative section (or paper= ). The really interesting bit related to trees is in Appendix A. I suggest = moving the formal description of the tree from Appendix A to this section. = It=E2=80=99s impossible to implement this from the hand full examples here.=
> There=E2=80=99s no description in here on how the tree actually works.= For example, adding a node to the tree is defined in 10.1.1 (Add).
> The ratchet tree nodes as described in Section 5 don't hold a KeyP= ackage. But Section 7 says =E2=80=9CAs the KeyPackage is a structure which = is stored in the Ratchet Tree and updated depending on the evolution of thi= s tree=E2=80=9D.
> The tree nodes have a parent hash field, which is of course part of th= e ratchet tree but shouldn=E2=80=99t be necessary for the description of th= e tree structure.
> Also, the description of the tree hash (Section 7.5) follows the defin= ition of the parent_hash extension in Section 7.4 such that it is not entir= ely clear which parent_hash is used there (extension or node value).
> Section 5 also talks about commit messages without linking to them or = introducing them. Having to talk about commit messages in this section is a= lso a little confusing.
> The term =E2=80=9Chandshake message=E2=80=9D is first used in Section = 7.8 (Key Schedule) but never introduced. This should probably happen in 10 = (Group Evolution), which doesn=E2=80=99t talk about handshake messages at a= ll until 10.3 (Ratchet Tree Extension).
>
>
> There are probably plenty more issues like this. But I don=E2=80=99t t= hink addressing any of these issues individually makes sense. I therefore s= uggest having an overhaul of the document structure.
>
>
> The way I see MLS there are a set of high-level structures and compone= nts that should be clearly described and built upon each other. There=E2=80= =99s a data structure (tree) that is used to represent a group. Then there = is the MLSgroupthat implements a specific semantic on the tree. Operations = to modify the group are specified in thehandshake protocol. Andapplication = messagesdefine messages encrypted with keys derived in the handshake protoc= ol with the key schedule.
> The tree is a basic left-balanced binary tree and defines functions to= create a tree, and add and remove nodes.
> A group is the main part of MLS, a tree with nodes of a certain type. = So this part should describe whatnodeslook like and how the tree is used to= compute tree invariants and keys.
> The handshake protocol defines all messages needed to perform operatio= ns on the MLS group.
>
>
> This is certainly not exhaustive and would need further refinement. Bu= t it=E2=80=99s the high-level structure I=E2=80=99d expect from the documen= t. I=E2=80=99m sure other structures would work as well. But what we curren= tly have isn=E2=80=99t what is needed to implement MLS imho.
>
>
> Cheers,
> Franziskus
>
>
> _______________________________________________
> 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
--0000000000008de66305b0f06b5d-- From nobody Mon Oct 5 12:15:13 2020 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 90AF53A0E45 for ; Mon, 5 Oct 2020 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWNrBia4l54n for ; Mon, 5 Oct 2020 12:15:10 -0700 (PDT) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2B43A0E41 for ; Mon, 5 Oct 2020 12:15:10 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4C4qzw5x73zQlKL; Mon, 5 Oct 2020 21:15:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id bvSftMzbyyUw; Mon, 5 Oct 2020 21:14:59 +0200 (CEST) Date: Mon, 5 Oct 2020 21:14:58 +0200 (CEST) From: Konrad Kohbrok To: Brendan McMillion Cc: Franziskus Kiefer , "mls@ietf.org" Message-ID: <553305330.121948.1601925298649@office.mailbox.org> In-Reply-To: References: <781922648.117964.1601901336014@office.mailbox.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-MBO-SPAM-Probability: X-Rspamd-Score: -6.15 / 15.00 / 15.00 X-Rspamd-Queue-Id: D6D35181E X-Rspamd-UID: 95cf43 Archived-At: Subject: Re: [MLS] draft structure feedback and suggestions X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 19:15:13 -0000 It's not something we're going to decide on this meeting, for sure. However= , I was under the impression that the last big changes are already foreseea= ble and starting to outline a new document structure now makes sense in my = opinion. I don't think any of the big upcoming PRs are going to change much= w.r.t. the structure. Konrad > Brendan McMillion hat am 05.1= 0.2020 20:11 geschrieben: >=20 >=20 > I don't think this belongs on the agenda. What Franziskus says is right, = the MLS protocol document has become nonsensical over time. But right now w= e're focusing on substantive changes to the protocol and can rearrange when= we've finished. >=20 >=20 > On Mon, Oct 5, 2020 at 5:35 AM Konrad Kohbrok wrote: > > Hi everyone, > > =20 > > I think Franziskus make some good points here. We've been making indiv= idual changes all over the document, but the structure hasn't really change= d for quite a while. Maybe this would be a good time to take a look at the = document as a whole? > > =20 > > In addition to his mail below, Franziskus has also filed an issue http= s://github.com/mlswg/mls-protocol/issues/409.=20 > > =20 > > @Sean: Any chance we can put it on the agenda for the meeting tomorrow= ? > > =20 > > Cheers, > > Konrad > > =20 > > > Franziskus Kiefer hat am 17.09.2020 13:= 18 geschrieben: > > >=20 > > >=20 > > > Hi all, > > >=20 > > >=20 > > > While trying to implement the MLS protocol from scratch I ran into a= couple issues and I think there=E2=80=99s a general problem regarding the = structure of the draft. Note that these are all editorial issues. > > > Right now I see no straightforward way to implement the spec as ther= e=E2=80=99s no clear structure. To implement even the basic tree structure = it=E2=80=99s necessary to jump through the entire document. There=E2=80=99s= also a lot of prose and examples and very little implementable parts. > > >=20 > > > Let me give some examples: > > >=20 > > >=20 > > > Section 5 (Ratchet Trees) reads like a non-normative section (or pap= er). The really interesting bit related to trees is in Appendix A. I sugges= t moving the formal description of the tree from Appendix A to this section= . It=E2=80=99s impossible to implement this from the hand full examples her= e. > > > There=E2=80=99s no description in here on how the tree actually work= s. For example, adding a node to the tree is defined in 10.1.1 (Add). > > > The ratchet tree nodes as described in Section 5 don't hold a KeyPac= kage. But Section 7 says =E2=80=9CAs the KeyPackage is a structure which is= stored in the Ratchet Tree and updated depending on the evolution of this = tree=E2=80=9D. > > > The tree nodes have a parent hash field, which is of course part of = the ratchet tree but shouldn=E2=80=99t be necessary for the description of = the tree structure. > > > Also, the description of the tree hash (Section 7.5) follows the def= inition of the parent_hash extension in Section 7.4 such that it is not ent= irely clear which parent_hash is used there (extension or node value). > > > Section 5 also talks about commit messages without linking to them o= r introducing them. Having to talk about commit messages in this section is= also a little confusing. > > > The term =E2=80=9Chandshake message=E2=80=9D is first used in Sectio= n 7.8 (Key Schedule) but never introduced. This should probably happen in 1= 0 (Group Evolution), which doesn=E2=80=99t talk about handshake messages at= all until 10.3 (Ratchet Tree Extension). > > >=20 > > >=20 > > > There are probably plenty more issues like this. But I don=E2=80=99t= think addressing any of these issues individually makes sense. I therefore= suggest having an overhaul of the document structure. > > >=20 > > >=20 > > > The way I see MLS there are a set of high-level structures and compo= nents that should be clearly described and built upon each other. There=E2= =80=99s a data structure (tree) that is used to represent a group. Then the= re is the MLSgroupthat implements a specific semantic on the tree. Operatio= ns to modify the group are specified in thehandshake protocol. Andapplicati= on messagesdefine messages encrypted with keys derived in the handshake pro= tocol with the key schedule. > > > The tree is a basic left-balanced binary tree and defines functions = to create a tree, and add and remove nodes. > > > A group is the main part of MLS, a tree with nodes of a certain type= . So this part should describe whatnodeslook like and how the tree is used = to compute tree invariants and keys. > > > The handshake protocol defines all messages needed to perform operat= ions on the MLS group. > > >=20 > > >=20 > > > This is certainly not exhaustive and would need further refinement. = But it=E2=80=99s the high-level structure I=E2=80=99d expect from the docum= ent. I=E2=80=99m sure other structures would work as well. But what we curr= ently have isn=E2=80=99t what is needed to implement MLS imho. > > >=20 > > >=20 > > > Cheers, > > > Franziskus > > >=20 > > >=20 > > > _______________________________________________ > > > MLS mailing list > > > MLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/mls > > =20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Oct 6 09:38:56 2020 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 820503A0CCE for ; Tue, 6 Oct 2020 09:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 OKqxO8GgPvyU for ; Tue, 6 Oct 2020 09:38:53 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 A5D4B3A0B23 for ; Tue, 6 Oct 2020 09:38:53 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id p13so8324792edi.7 for ; Tue, 06 Oct 2020 09:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=uR1Y9++/lNn3PH0ZhggaLIPW8bJri6GciTnYVxWLDn8=; b=1+fmEuLgrNKVD8HPZWimZRCTnoE6TcAlcQUW+oQlg6q6F6Gw1kQyrbCU8/XQr/Mog8 kqYz2AtuZZCvZTuXnc7yjqCmGX/mNijogUAqbj0U29iY4C281bWOqbndNN52gW9ZnMuh E9b7iMisyARE49bwVgXJhNIF/MSpFo+8c1FNwdYal5Ku12xHWcrg3bex1vVj/28/gRtF HM5dXItXICX/f+R6v5aJZNqSh/DcKVZjHriEhjEoPACWT9Q6U/G1F21TKCMqrAg2F67Z fF7qPw+hOd0sLPvnl6gzpMydOAXXn4tejgRW7qNYgehkSnmTYAiWiOlj6Gjnn7Gb5j6k Ej7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=uR1Y9++/lNn3PH0ZhggaLIPW8bJri6GciTnYVxWLDn8=; b=ZUJsyqQiuXJZ1+OybWoZrtlZ77tAQcMUnSAn45XoJuZHYkocGj4tEB43538M93ZWFN hlc4twSOGOSpEIWxXtyGzr8WcFOS8uZTmtcYiNs1M5OebhvGaC25nPnK2pdCZc7NBAQD VbJQ4BQZd6OYdkgOZdf3Y2W3vAqEKRoSlpFbwhKga1Qik2smOoBo+tLT8fcaD6yzNxLx Q+vU24yoFr+ysElBPUiH3Ys1ihF6zgb7IK+drja5Vxa8hMi/EiWOwtKNaJVHB7kSuJo/ HjM40MDshilex681xpO9K7kYxrU4X8kSncnsLt6wHI22tzKTh3Uy+YTXRUCTUrP9KnaC Txfw== X-Gm-Message-State: AOAM5321UeXggut376Cq9M3kh9fUeGXQD1cgPhIS/9D9OgzJZpE0tUvz MUjwspvcLch+tPCxh7hViaOH29MPXTJTwKDP X-Google-Smtp-Source: ABdhPJyPv35KL/qApjeniQpCT+Ipz0afwt9bdvjwKVp+MZEuPFLhBeNnsYzMtTccZd7/QFUo7q09rw== X-Received: by 2002:a05:6402:b68:: with SMTP id cb8mr6735939edb.350.1602002331659; Tue, 06 Oct 2020 09:38:51 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id v2sm2493779ejh.57.2020.10.06.09.38.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 09:38:50 -0700 (PDT) To: Messaging Layer Security WG From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: Date: Tue, 6 Oct 2020 18:38:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 16:38:56 -0000 Hey people, To follow up on the discussion at the end of the Interim about whether to use the new "asymmetric external commit" (AEC) mechanism for internal commits I wanted to summarize my thoughts here. For brevity let SIC be our current "symmetric internal commit" mechanism. - AEC requires extra asymmetric crypto operations (both for committer and receiver) compared to SIC which I think we should avoid if we can, even at the cost of some code complexity. - AEC doesn't ensure the committer knows the old epoch's key schedule. This can play a deciding role in several types of attacks. Consider this execution: 1. Alice is in a group. Her state leaks (including her signining key). 2. Alice commits (to arbitrary propal). At this point, the adversary can still forge a new AEC from Alice but not an SIC. Worse, step 2 could have instead been "Alice sends an update proposal replacing her leaf HPKE but keeping the her sig keys (e.g. because new credentials are costly to come by). Someone commits to the new proposal." At this point I'd expect PCS to have kicked in for Alice (as it does when using SIC). But not for AECs since Alice's signing key is all thats needed to forge a new AEC. I think it is not worth weakening security this way if we dont have to. (Especially, since in some deployments external commits may not be a supported feature at all.) - As for what may or may not be displaid to users, that's really up to the implementation. IMO our goal should be to make the protocol as secure as we can subject to reasonable costs. Which aspects of the resulting security properties are ultimately communicated to users should, in principle, be left up to implementations. That means we shouldn't be designing away security features only because we think they might be hard to communicate. (Nor does it seem that inconceivable to me that some implementation may end up explicitly signaling whether a commit was external vs internal.) - Joël From nobody Tue Oct 6 09:55:47 2020 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 13BBE3A0D84 for ; Tue, 6 Oct 2020 09:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxsKYM3Yw7Ja for ; Tue, 6 Oct 2020 09:55:44 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4C4113A0D81 for ; Tue, 6 Oct 2020 09:55:44 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id t9so5647566wrq.11 for ; Tue, 06 Oct 2020 09:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kyhOq/s8b3n/O0IfOdMxGz0Dc5trRWk7FDjsL2qRDIw=; b=Vc2xjmg6fydf5Pfb631gffJae7jsGYAMNHXEeQrNAB+4aVnIdYUiXHrPzDJyj2F10+ ztXyh8j0PXEbjsVt/rDbpxFEBf9oDu1PR/YYeEemalEWIsnEdoQRsEh4qRRkiCfSu4up FFrnywxw/KlPxReJLOTZRscaTRLJ3kbV5zGd4CTaJp93ESEZWW5/aQCnWL7dsbwk6+ZE 1umrC2H6oycQkKSWs8+x4OLmnSU6Dp5DPC60HtzzzVarRMEhj0A41s2VBHuRFmKTRe1e 8s/1YU2c0wulTiJTm3vaKrLPjmdfMTG/rRxJf1eLbIO+o4Xgt3jiq1utQmKjgAQJZJu1 cTLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kyhOq/s8b3n/O0IfOdMxGz0Dc5trRWk7FDjsL2qRDIw=; b=jbHPqwuWZEN3UKMLFhVRE5vGT4/Ju7mMtDnyB5K5ryWy+vRab0OqbEK312ychMSQvc 78l/g7kRC3JoCM5x5HQdhff8Mcf914DajV7zJyQ7UKDfCm/ePum3E8POUndHMGiRwELY RitTKhgBiNefoxb6YcIlYq87QdMBWYG/Bbg+Pl8lBv+jr8Q3OKIOGspNUwU+3iRIkJ4/ GwB85UAozbDiFqgQcNWq1Ga4jSFgKSu5QFc6dQeqhdOF17d2WypQ8aJy6rduYlZlVAmy Zz73c1EACzhiK5Z/JYR5BXPAd7m3wQO9zCc7Y0p5JZQqbvWYfxzdfmu9V/CpD5imYDpy bMBA== X-Gm-Message-State: AOAM530ldxWwD+OKKScw7bR7KoXXA6NdEFWWIfZTEv808gG1jldFE6YR JYqWBu7gBDuhpu/8H02CchpSk08WK5T6XA== X-Google-Smtp-Source: ABdhPJzZZEcjc3HTKMGBZkohdAvnYnMLxB9s3slLxD2byW4sp226KsALO4ZOllshL0o35f2T75d5HA== X-Received: by 2002:a5d:6886:: with SMTP id h6mr6285303wru.374.1602003342406; Tue, 06 Oct 2020 09:55:42 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id u15sm4586603wml.21.2020.10.06.09.55.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 09:55:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: Date: Tue, 6 Oct 2020 18:55:40 +0200 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> References: To: Joel Alwen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 16:55:46 -0000 I second that assessment, my idea behind External Commits was to offer a = mechanism where internal Commits couldn=E2=80=99t be used. External = Commits should remain optional (this can easily be achieved by not = providing the ExternalCommitInfo package to new members) and when they = are used they should be used as a last resort mechanism (meaning there = really is no way to add a member with an internal Commit). I also think MLS should should remain in the position to cover most = scenarios from mainstream consumer messaging to messaging in high = security environments. External Commits make the former much more = accessible but shouldn=E2=80=99t jeopardise the latter. Raphael > On 6 Oct 2020, at 18:38, Joel Alwen wrote: >=20 > Hey people, >=20 > To follow up on the discussion at the end of the Interim about whether = to use > the new "asymmetric external commit" (AEC) mechanism for internal = commits I > wanted to summarize my thoughts here. For brevity let SIC be our = current > "symmetric internal commit" mechanism. >=20 > - AEC requires extra asymmetric crypto operations (both for committer = and > receiver) compared to SIC which I think we should avoid if we can, = even at the > cost of some code complexity. >=20 > - AEC doesn't ensure the committer knows the old epoch's key schedule. = This can > play a deciding role in several types of attacks. >=20 > Consider this execution: >=20 > 1. Alice is in a group. Her state leaks (including her signining key). > 2. Alice commits (to arbitrary propal). >=20 > At this point, the adversary can still forge a new AEC from Alice but = not an SIC. >=20 > Worse, step 2 could have instead been "Alice sends an update proposal = replacing > her leaf HPKE but keeping the her sig keys (e.g. because new = credentials are > costly to come by). Someone commits to the new proposal." At this = point I'd > expect PCS to have kicked in for Alice (as it does when using SIC). = But not for > AECs since Alice's signing key is all thats needed to forge a new AEC. >=20 > I think it is not worth weakening security this way if we dont have = to. > (Especially, since in some deployments external commits may not be a = supported > feature at all.) >=20 > - As for what may or may not be displaid to users, that's really up to = the > implementation. IMO our goal should be to make the protocol as secure = as we can > subject to reasonable costs. Which aspects of the resulting security = properties > are ultimately communicated to users should, in principle, be left up = to > implementations. That means we shouldn't be designing away security = features > only because we think they might be hard to communicate. (Nor does it = seem that > inconceivable to me that some implementation may end up explicitly = signaling > whether a commit was external vs internal.) >=20 > - Jo=C3=ABl >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Tue Oct 6 18:20:31 2020 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 6E0833A1554 for ; Tue, 6 Oct 2020 18:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h5bKZmGOHRH for ; Tue, 6 Oct 2020 18:20:29 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA20C3A1446 for ; Tue, 6 Oct 2020 18:20:23 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id bl9so207349qvb.10 for ; Tue, 06 Oct 2020 18:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=uPkfusi2RacTrxD1JjXEgACkqJ+HBtkhZiMVH6U5OkU=; b=aHudOM3EeMkOEwrs0KY18E+gVdVyOmpFxTa4qL2KBeU9QLUgOIW36eerT92+VhbcjL IFG+4ietqhByDsSHXa52gW507dSu1f7PWXUQ7TLANs6W2A7MLDNP17VrXkwzWXLTcLNH pBBv2P6VjXsy9QudJ4p3CNrIEuZ7lXti3E/t5MDO6Sq9BZoW/Bzsg/lZ0sJlswgPjpm5 0WoZiNr2a2taz6MtlNa3hsrGUXyeaKCi+cAs/fm6SVvm6qV9ldAESuqpMH1k91J+VpXz +iGl4trvkuB6V710K0UIWtS15ut2ARSYBRtXlZZMAe/aJqLOsKmlEssN4F5Mly6pzzO+ BZNg== 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=uPkfusi2RacTrxD1JjXEgACkqJ+HBtkhZiMVH6U5OkU=; b=lRZ5X9H0nFdtGc2ihVcNOAdvAXeGrL3eTMj5zYLva9GX0sxcEcfYJAruOhaYkGRa87 u9VS8rjWGJE+U6E8vNYT3vGGqk+nj7LK8PIn6pNMdx161JVKl1vW5VC01dhwb5ccK6fl s1GkMF/cwujEkDHmwV1Euu7bgTaqxSbaRcyf3UbfGtD1JOFPPEk5lYcB1zsFfkTvHS87 hPlDXpDECu3Ab6QR8d4sKB903v8xxIubZ78zLOYNKBSkTh2dwVuc3uutZAaX7eiwIlVR Jtij7kJ5TKk2zBrQTIu9AldGx6kc/m5q9adD+jWtCHF2QqyJUALgh48VfzXTobFWUdXq R2Bg== X-Gm-Message-State: AOAM531LIUlg8F7I4zaXGFz990UecpCvDVKWkepqgGQ+KTlkvV/se/GA sJ657ZUhrAbogEcxGQEw5bofMjNNCN4SzQQVORnV3XPWgEvsCg== X-Google-Smtp-Source: ABdhPJz4jPrRTJvqmVsPYkPEYRJle2mGJ6PodfwKNeC2YZdwCXtMGN2s4M61D/6T22CtqWfHEThyv99JNxgI8RHRlsk= X-Received: by 2002:a0c:cdc4:: with SMTP id a4mr976506qvn.31.1602033622210; Tue, 06 Oct 2020 18:20:22 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Tue, 6 Oct 2020 21:20:10 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000f86fad05b10a8483" Archived-At: Subject: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 01:20:30 -0000 --000000000000f86fad05b10a8483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, I wanted to send some thoughts on how to implement external commit, as a prelude to a PR. This is a little bit of an essay, so tl;dr, the proposal is: - Rather than re-using Proposal/Commit, we should make a new ExternalCommit message, parallel to Proposal/Commit - We should also define a syntax for telling the joiner the requisite information about the group # HPKE-based init secret The concept here is as follows: - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key schedule for each epoch - The public key `pkG` of that key pair is published along with with other group metadata - The joiner calls SetupBaseS(pkG, some_public_group_context) to get an encapsulated key `enc` and an HPKE context `ctx` - The joiner sends the encapsulated key to the group with their external commit - The members of the group call SetupBaseS(enc, skG, some_public_group_context) to get an equivalent HPKE context `ctx` - Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to derive the init secret So there are two syntactic requirements: 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the encapsulated key `enc` to the group # What Proposals? The current PR correctly requires that the external Commit MUST cover an Add proposal for the new member. It does not forbid the Commit covering *other* proposals. It seems like it might be useful in a couple of cases to keep that option open: * Including PSK proposals for additional authentication when joining * Including a Remove proposal for your prior appearance when re-joining The only current proposal that would be nonsensical is an Update. Whether we do this has some impact on the syntax, as discussed below. # External commit syntax: Separate or Together Assume for the moment that we are not going to do the above asymmetric calculation for every commit. Then we need some extra, optional syntax to carry `enc`, either as an optional field on Commit or as a new Proposal, which is the agreed mechanism for extending Commits. (If we do it every time, we can just make this part of Commit.) In the below, I=E2=80=99ll as= sume a new Proposal, say ExternalInitSecret. struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; Given the requirement for an Add proposal, the joiner now has to send a =E2=80=9Cflight of messages=E2=80=9D: - Proposal(Add) - Proposal(ExternalInitSecret) - Commit Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit heavyweigh= t, since each of these is signed separately. It=E2=80=99s duplicative, since the KeyPackage= in the Add is immediately overwritten by the (necessarily different) KP in the Commit. And you have potential fate-sharing issues, since all three need to succeed or fail. You could also envision a Together Option, where we define another top-level content type (parallel to Proposal and Commit) for this purpose: struct { opaque kem_output<0..2^16-1>; UpdatePath path; } ExternalCommit; That would avoid all of the challenges above, but it optimizes out all of the flexibility to include other proposals. So maybe it=E2=80=99s worth considering an Extensible Together Option, where we can put extra proposals into an ExternalCommit struct { Proposal proposals<0..2^32-1>; opaque kem_output<0..2^16-1>; UpdatePath path; } ExternalCommit; Personally, I kind of like the Flexible Together Option, since it provides simplicity and extensibility. And to be honest, I=E2=80=99ve been wonderin= g if we should allow inline proposals in Commit for a while, along just these lines. If we do this option, we should probably back-port it to Commit as well. # Syntax for what the Joiner Needs The PR notes that the joiner needs to know a bunch of information about the group in order to make a well-formed ExternalCommit. In earlier iterations of this style of join, we had a GroupInitKey that carried the right information. Following that pattern here, we get something like the following: struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 epoch; opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>; Extension extensions<0..2^32-1>; } GroupKeyPackage; Note that this object is essentially the same as a GroupInfo object. The only things it is missing are interim_transcript_hash and signature, both of which might be useful. So maybe all we need to do here is say that clients can publish GroupInfo unencrypted if they want to enable self-adds, in addition to distributing it in encrypted form in Welcome. In any case, it seems like it would be useful to have some syntax for this. Hope this helps, =E2=80=94RLB --000000000000f86fad05b10a8483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I wanted to send some thoughts on how to i= mplement external commit, as a prelude to a PR.=C2=A0 This is a little bit = of an essay, so tl;dr, the proposal is:

- Rather than re-using Propo= sal/Commit, we should make a new ExternalCommit message, parallel to Propos= al/Commit
- We should also define a syntax for telling the joiner the re= quisite information about the group

# HPKE-based init secret

= The concept here is as follows:

- An HPKE/KEM key pair `(skG, pkG)` = is derived off of the key schedule for each epoch
- The public key `pkG`= of that key pair is published along with with other group metadata
- Th= e joiner calls SetupBaseS(pkG, some_public_group_context) to get an encapsu= lated key `enc` and an HPKE context `ctx`
- The joiner sends the encapsu= lated key to the group with their external commit
- The members of the g= roup call SetupBaseS(enc, skG, some_public_group_context) to get an equival= ent HPKE context `ctx`
- Everyone calls `ctx.export(MLS_export_label, in= it_secret_size)` to derive the init secret

So there are two syntacti= c requirements:

1. Publishing the group=E2=80=99s public key `pkG`2. Sending the encapsulated key `enc` to the group


# What Prop= osals?

The current PR correctly requires that the external Commit MU= ST cover an Add proposal for the new member. =C2=A0 It does not forbid the = Commit covering *other* proposals.=C2=A0 It seems like it might be useful i= n a couple of cases to keep that option open:=E2=80=A8
* Including PSK p= roposals for additional authentication when joining
* Including a Remove= proposal for your prior appearance when re-joining

The only current= proposal that would be nonsensical is an Update. =C2=A0

Whether we = do this has some impact on the syntax, as discussed below.


# Ext= ernal commit syntax: Separate or Together

Assume for the moment that= we are not going to do the above asymmetric calculation for every commit.= =C2=A0 Then we need some extra, optional syntax =C2=A0to carry `enc`, eithe= r as an optional field on Commit or as a new Proposal, which is the agreed = mechanism for extending Commits. =C2=A0(If we do it every time, we can just= make this part of Commit.) =C2=A0In the below, I=E2=80=99ll assume a new P= roposal, say ExternalInitSecret.

struct {
=C2=A0 opaque kem_outpu= t<0..2^16-1>;
} ExternalInitSecret;

Given the requirement f= or an Add proposal, the joiner now has to send a =E2=80=9Cflight of message= s=E2=80=9D:

- Proposal(Add)
- Proposal(ExternalInitSecret)
- C= ommit

Let=E2=80=99s call this the Separate Option.=C2=A0 It=E2=80=99= s a bit heavyweight, since each of these is signed separately.=C2=A0 It=E2= =80=99s duplicative, since the KeyPackage in the Add is immediately overwri= tten by the (necessarily different) KP in the Commit.=C2=A0 And you have po= tential fate-sharing issues, since all three need to succeed or fail.
You could also envision a Together Option, where we define another top-le= vel content type (parallel to Proposal and Commit) for this purpose:
struct {
=C2=A0 opaque kem_output<0..2^16-1>;
=C2=A0 UpdatePat= h path;
} ExternalCommit;

That would avoid all of the challenges = above, but it optimizes out all of the flexibility to include other proposa= ls.=C2=A0 So maybe it=E2=80=99s worth considering an Extensible Together Op= tion, where we can put extra proposals into an ExternalCommit

struct= {
=C2=A0 Proposal proposals<0..2^32-1>;
=C2=A0 opaque kem_outp= ut<0..2^16-1>;
=C2=A0 UpdatePath path;
} ExternalCommit;
Personally, I kind of like the Flexible Together Option, since it provides= simplicity and extensibility.=C2=A0 And to be honest, I=E2=80=99ve been wo= ndering if we should allow inline proposals in Commit for a while, along ju= st these lines.=C2=A0 If we do this option, we should probably back-port it= to Commit as well.


# Syntax for what the Joiner Needs

Th= e PR notes that the joiner needs to know a bunch of information about the g= roup in order to make a well-formed ExternalCommit.=C2=A0 In earlier iterat= ions of this style of join, we had a GroupInitKey that carried the right in= formation. Following that pattern here, we get something like the following= :

struct {
=C2=A0 CipherSuite cipher_suite;
=C2=A0 opaque grou= p_id<0..255>;
=C2=A0 uint64 epoch;
=C2=A0 opaque tree_hash<0= ..255>;
=C2=A0 opaque confirmed_transcript_hash<0..255>;
=C2= =A0 Extension extensions<0..2^32-1>;
} GroupKeyPackage;

Not= e that this object is essentially the same as a GroupInfo object.=C2=A0 The= only things it is missing are interim_transcript_hash and signature, both = of which might be useful.=C2=A0 So maybe all we need to do here is say that= clients can publish GroupInfo unencrypted if they want to enable self-adds= , in addition to distributing it in encrypted form in Welcome.

In an= y case, it seems like it would be useful to have some syntax for this.
<= br>Hope this helps,
=E2=80=94RLB
--000000000000f86fad05b10a8483-- From nobody Wed Oct 7 03:36:29 2020 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 60F893A08AE for ; Wed, 7 Oct 2020 03:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XnurOjpyie0 for ; Wed, 7 Oct 2020 03:36:25 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 5DFE53A08AB for ; Wed, 7 Oct 2020 03:36:25 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id l16so1625467eds.3 for ; Wed, 07 Oct 2020 03:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4I5l2jkAyCvPGZ606osTHEMiXtYElcH29Wr1135XuKg=; b=BfJYXeyZzK8dle6QLmIaazH+DDKyoHz9lUTQ5ndsT+oydfzdezaowgKH+n0E4lMJ1P /O7XYModmcPM9zPdLNxHXuXjAwUd+Bk/K8776sTfdaHvaggo/Ryj1wpxlMPEsn3ymS/h /dkuXzcY2PQ5nbN2b1M21ht6lb1w6b4f5T6QjLOgdxvIfA0u1+yVyFveHnqwqFoHbiw+ JueB9Hhd0fbDUhqO7uoEIvuBvAehoTVNaMuwRm7X70KkZzZmCp5zthz6qWT665YFAQNZ 7PUzHzLG7W8TEVJXHbTutG7i5pAwSyF8swt++tbIQhu+TSk4ymY0rhn8ObYuww9jWg01 JLtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4I5l2jkAyCvPGZ606osTHEMiXtYElcH29Wr1135XuKg=; b=Q9Xv8RoA37HUbNhL6KajySDxCIfNMWMHAkwn9fhBDuNgNwgKaLrTi+sKztFrEy4tAo RlcQpq/S6fOmat8PhWMl0GzMfc1nPCkQz70nI6EBJcpH4uY52fazLvFkcTK8uxkbq1V5 tv3500o10BqZxb8c5VLSxuV4wzgjmfKxJAL/5ghEHhWQUwinPS/iAtsFUF96c0cBgeTA OFD4y/IyQuQNrc7acLCga9qoDXM2ohU58DcZQv5DHIXeZsmboYQ5zdPP1ByUWxzexalM 6Hgis+Jf5YzIs1TX50w1zsNE5d/dxcmp/FOfU1ZXnieV9JhLuFtQ59aKQTXjOipkiAyT apsw== X-Gm-Message-State: AOAM533NyKEWgZVTrOdoczxj0WXlWUNcZ4LWZEVGqWjKZEmMp1LjC71F kwgQQrBhZPl0FG7Ezbw7k8x3GvNpPsq0qQ== X-Google-Smtp-Source: ABdhPJzuSFGrOU5EwosiW9UyPbrn/e4uLxsjMuYb5JRW3OZaPALyNUXJmmCVtA5FJ5wMdhdb/POZsg== X-Received: by 2002:aa7:c256:: with SMTP id y22mr2834928edo.324.1602066983547; Wed, 07 Oct 2020 03:36:23 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id 92sm1165503edm.30.2020.10.07.03.36.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 03:36:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: Date: Wed, 7 Oct 2020 12:36:21 +0200 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 10:36:27 -0000 Thanks Richard for looking at all aspects in detail! I thought about these things as well and will comment inline: > On 7 Oct 2020, at 03:20, Richard Barnes wrote: >=20 > Hey all, >=20 > I wanted to send some thoughts on how to implement external commit, as = a prelude to a PR. This is a little bit of an essay, so tl;dr, the = proposal is: >=20 > - Rather than re-using Proposal/Commit, we should make a new = ExternalCommit message, parallel to Proposal/Commit I think we are better off with re-using the current Commit syntax and = I=E2=80=99ll explain why further below. > - We should also define a syntax for telling the joiner the requisite = information about the group >=20 > # HPKE-based init secret >=20 > The concept here is as follows: >=20 > - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key schedule = for each epoch > - The public key `pkG` of that key pair is published along with with = other group metadata > - The joiner calls SetupBaseS(pkG, some_public_group_context) to get = an encapsulated key `enc` and an HPKE context `ctx` > - The joiner sends the encapsulated key to the group with their = external commit > - The members of the group call SetupBaseS(enc, skG, = some_public_group_context) to get an equivalent HPKE context `ctx` > - Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to = derive the init secret >=20 > So there are two syntactic requirements: >=20 > 1. Publishing the group=E2=80=99s public key `pkG` > 2. Sending the encapsulated key `enc` to the group =46rom the discussion at the interim, I think there is consensus about = this part, we just need to add that to the PR. >=20 >=20 > # What Proposals? >=20 > The current PR correctly requires that the external Commit MUST cover = an Add proposal for the new member. It does not forbid the Commit = covering *other* proposals. It seems like it might be useful in a = couple of cases to keep that option open:=E2=80=A8>=20 > * Including PSK proposals for additional authentication when joining > * Including a Remove proposal for your prior appearance when = re-joining >=20 > The only current proposal that would be nonsensical is an Update. =20 >=20 > Whether we do this has some impact on the syntax, as discussed below. While that is not very explicit in the current PR, my approach was the = following: All Proposals should be allowed in an external Commit: - Adds: The joiner (new member) could right away add more members, or = Commit to already existing Add Proposals if those are accessible.=20 - Removes: The joiner can remove prior appearances of itself (like you = pointed out) or Commit to already existing Remove Proposals. - Updates: The joiner should of course not issue own Updates and Commit = to them, but that is already the case for internal Commits. The joiner = can Commit to already existing Update Proposals from other members. Whether all of the above is allowed should only be governed by the = policy for a group, nothing else. As a reminder: all clients MUST have = the same policy for a certain group in order ta validate/refute = Proposals and Commits. This pretty much motivates my idea for fully re-using the existing = Commit syntax and only introduce the new ExternalInitSecret Proposal. >=20 >=20 > # External commit syntax: Separate or Together >=20 > Assume for the moment that we are not going to do the above asymmetric = calculation for every commit. Then we need some extra, optional syntax = to carry `enc`, either as an optional field on Commit or as a new = Proposal, which is the agreed mechanism for extending Commits. (If we = do it every time, we can just make this part of Commit.) In the below, = I=E2=80=99ll assume a new Proposal, say ExternalInitSecret. >=20 > struct { > opaque kem_output<0..2^16-1>; > } ExternalInitSecret; This is exactly the Proposal we need. >=20 > Given the requirement for an Add proposal, the joiner now has to send = a =E2=80=9Cflight of messages=E2=80=9D: >=20 > - Proposal(Add) > - Proposal(ExternalInitSecret) > - Commit I see some more nuance here. The first Add Proposal does not have to be = issued by the new joiner, it could very well be an external Proposal. = The scenario I had in mind here is the following: A server issues an external Add Proposal for a group. The following = things can happen: a) Ideal scenario: - A member of the group comes online, validates the Add Proposal = according to the policy and references it in an internal Commit (no = External Commit needed) and sends a Welcome message to the new member b) Equally ideal scenario: - The new joiner comes online before anyone else, has access to the = public group data but does not need to communicate with the group. = Nothing happens. c) Emergency scenario: - The new joiner comes online before anyone else and needs to urgently = send a message to the group. The new joiner creates the = ExternalInitSecret Proposal and the Commit and sends both to group. >=20 > Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit = heavyweight, since each of these is signed separately. It=E2=80=99s = duplicative, since the KeyPackage in the Add is immediately overwritten = by the (necessarily different) KP in the Commit. And you have potential = fate-sharing issues, since all three need to succeed or fail. >=20 > You could also envision a Together Option, where we define another = top-level content type (parallel to Proposal and Commit) for this = purpose: >=20 > struct { > opaque kem_output<0..2^16-1>; > UpdatePath path; > } ExternalCommit; >=20 > That would avoid all of the challenges above, but it optimizes out all = of the flexibility to include other proposals. So maybe it=E2=80=99s = worth considering an Extensible Together Option, where we can put extra = proposals into an ExternalCommit >=20 > struct { > Proposal proposals<0..2^32-1>; > opaque kem_output<0..2^16-1>; > UpdatePath path; > } ExternalCommit; >=20 > Personally, I kind of like the Flexible Together Option, since it = provides simplicity and extensibility. And to be honest, I=E2=80=99ve = been wondering if we should allow inline proposals in Commit for a = while, along just these lines. If we do this option, we should probably = back-port it to Commit as well. >=20 As mentioned above, I=E2=80=99m all for re-using the existing Commit = syntax because of clarity, simplicity and flexibility.=20 I do agree that the amount of signatures is sub-optimal, and this is = something that also occurs in other situations. For example, when a = member wants to add n new members at once to the group, it needs to = compute n+1 signatures for that. You mention the idea of inline proposals: Would that be a proposal that = doesn=E2=80=99t have a signature, but still all other information? If = so, I think it would be worthwhile looking at that separately, because = as you say, it could be back-ported to internal Commits as well. I=E2=80=99= m all for exploring that idea further. >=20 > # Syntax for what the Joiner Needs >=20 > The PR notes that the joiner needs to know a bunch of information = about the group in order to make a well-formed ExternalCommit. In = earlier iterations of this style of join, we had a GroupInitKey that = carried the right information. Following that pattern here, we get = something like the following: >=20 > struct { > CipherSuite cipher_suite; > opaque group_id<0..255>; > uint64 epoch; > opaque tree_hash<0..255>; > opaque confirmed_transcript_hash<0..255>; > Extension extensions<0..2^32-1>; > } GroupKeyPackage; This is what the PR currently says, except that the PR used GroupContext = and has the full public tree. I agree that the tree hash should be = enough and I=E2=80=99ll change the PR accordingly. >=20 > Note that this object is essentially the same as a GroupInfo object. = The only things it is missing are interim_transcript_hash and signature, = both of which might be useful. So maybe all we need to do here is say = that clients can publish GroupInfo unencrypted if they want to enable = self-adds, in addition to distributing it in encrypted form in Welcome. While the two are awfully similar, the signature on GroupInfo is not = required here and might have undesired effects w.r.t deniability if this = is publicly accessible. The other reason for not wanting the signature = is that it would be an additional signature to compute with every = Commit, making them even more expensive. I propose to keep the struct = as-is. >=20 > In any case, it seems like it would be useful to have some syntax for = this. >=20 > Hope this helps, > =E2=80=94RLB TL;DR: I propose the following: - Keep the current Commit syntax=20 - Allow all kinds of Proposals for External Commits, same as with = internal Commits - Do the HPKE-based init secret for External Commits - Introduce the ExternalInitSecret Proposal and make it mandatory for = External Commits - Explore the idea of inline proposals separately - Do not re-use signed GroupInfo struct and keep the adjusted = ExternalCommitInfo instead Raphael > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Oct 7 04:27:13 2020 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 D66643A09F9 for ; Wed, 7 Oct 2020 04:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 NqgCEFvr0gPv for ; Wed, 7 Oct 2020 04:27:08 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA613A09F7 for ; Wed, 7 Oct 2020 04:27:07 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id md26so2394159ejb.10 for ; Wed, 07 Oct 2020 04:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zzbg0lRPuZW/YTj/xmMGQNSIsK5dd36MJVFwv1hLV4A=; b=uw6bFeCMHvwHjIS8cOEFBIG5EP5dLSNvMq7Pg5XZoVVkgv57l05vEtCZ8tMEUAPT/g ji7xB1AhytH2Dm7JnaDXr8Pc3B2NXTx0zm7KEvVIyvAhtmP8V82aVnrnMNOFWOpUuA0w e7eMdhA2M0BZ75xTVlm0ScGp1zFsH2pYfcUCNGYgfSJBohT83b2cTRHPzbdBzq4BI0lc qJX2/29kxgBP4ZaJ6d7tn9kR7+jMxintL3Qx3v3Y3UEVy7TULSSqi1BcGsP0aF6zbe9G xEACETawmm+sMgLu1yM+5/C8+/DRaZcM3E/3unmV3lxjlEN9yRrhlnk9o0GEMwNSR75h Dsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zzbg0lRPuZW/YTj/xmMGQNSIsK5dd36MJVFwv1hLV4A=; b=IX3E84egEpHneO5GfrpijhK4ZWuLCH38AHGXW/15rnUanCiDyqUbiAToewBEFsPRiR UY7eln6VZc5Y60B3mfzgIWUveBK3WHYPwuGidBMzfEChoUmvNychWi6zMlPUnXcIh2q1 1S4z0vrzKMZ5JPNtlYPYz+p56tEggDNBJDxpyxPPLyOKAzgEI7V95cz3DfmHuAxXhUar qfjgoo+VO6/LdvtyOu6dPLiKgoQr+BT8DU0lHeMfFz1uU9mEe8/06dD4XQ4PxgAsOEjz w5hY+NXE1aQPqXPuNT1WMfuxcGKc2+Q3EiZ1yM1RklOlkejJsTTexEADXVUJBABdLJO9 8B3g== X-Gm-Message-State: AOAM532ty8WAmq0wirkZc0oWab5SSK1JA3WL2TMKMYKio/Lcrii64hpb hHsB5h8g6aEUc0Lgw3stXjE9/wtnsUuaG2XX X-Google-Smtp-Source: ABdhPJxdXaJUWuahavp6bGi9haMA71NxU4V/Nw7Us5JUdrqpsuOqmciyoy9jdk5Bb7LIVB3AMr91+A== X-Received: by 2002:a17:906:4cd6:: with SMTP id q22mr2784481ejt.139.1602070025746; Wed, 07 Oct 2020 04:27:05 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id df12sm1269288edb.8.2020.10.07.04.27.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Oct 2020 04:27:04 -0700 (PDT) To: mls@ietf.org References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: Date: Wed, 7 Oct 2020 13:27:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 11:27:11 -0000 On 7 Oct 2020, at 03:20, Richard Barnes wrote: > Assume for the moment that we are not going to do the above asymmetric > calculation for every commit. Then we need some extra, optional syntax to > carry `enc`, either as an optional field on Commit or as a new Proposal, > which is the agreed mechanism for extending Commits. (If we do it every > time, we can just make this part of Commit.) In the below, I’ll assume a > new Proposal, say ExternalInitSecret. Isn't it a bit redundant to have the External party prepare a full (ExternInitSecret) proposal packet only to then immediately commit to it? That means a full extra frame of bandwidth, an extra signature for the external party and an extra sig verification for group members. I'm wondering what the motivation is for making this an explicit proposal instead of, say, a second mode for commits. (E.g. a commit uses init_secret[n] iff no kem_output field is included in the commit packet. Otherwise it uses the "external_init_secret" computed as Richard described.) ATM I can't think of a scenario where we wouldnt want the external committer to also be the one creating the ExternalInitSecret proposal and immediatly committing to it... - Joël On 07/10/2020 12:36, Raphael Robert wrote: > Thanks Richard for looking at all aspects in detail! > > I thought about these things as well and will comment inline: > >> On 7 Oct 2020, at 03:20, Richard Barnes wrote: >> >> Hey all, >> >> I wanted to send some thoughts on how to implement external commit, as a >> prelude to a PR. This is a little bit of an essay, so tl;dr, the proposal >> is: >> >> - Rather than re-using Proposal/Commit, we should make a new ExternalCommit >> message, parallel to Proposal/Commit > > I think we are better off with re-using the current Commit syntax and I’ll > explain why further below. > >> - We should also define a syntax for telling the joiner the requisite >> information about the group >> >> # HPKE-based init secret >> >> The concept here is as follows: >> >> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key schedule for >> each epoch - The public key `pkG` of that key pair is published along with >> with other group metadata - The joiner calls SetupBaseS(pkG, >> some_public_group_context) to get an encapsulated key `enc` and an HPKE >> context `ctx` - The joiner sends the encapsulated key to the group with >> their external commit - The members of the group call SetupBaseS(enc, skG, >> some_public_group_context) to get an equivalent HPKE context `ctx` - >> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to derive >> the init secret >> >> So there are two syntactic requirements: >> >> 1. Publishing the group’s public key `pkG` 2. Sending the encapsulated key >> `enc` to the group > > From the discussion at the interim, I think there is consensus about this > part, we just need to add that to the PR. > >> >> >> # What Proposals? >> >> The current PR correctly requires that the external Commit MUST cover an >> Add proposal for the new member. It does not forbid the Commit covering >> *other* proposals. It seems like it might be useful in a couple of cases >> to keep that option open:
> * Including PSK proposals for additional >> authentication when joining * Including a Remove proposal for your prior >> appearance when re-joining >> >> The only current proposal that would be nonsensical is an Update. >> >> Whether we do this has some impact on the syntax, as discussed below. > > While that is not very explicit in the current PR, my approach was the > following: > > All Proposals should be allowed in an external Commit: > > - Adds: The joiner (new member) could right away add more members, or Commit > to already existing Add Proposals if those are accessible. - Removes: The > joiner can remove prior appearances of itself (like you pointed out) or > Commit to already existing Remove Proposals. - Updates: The joiner should of > course not issue own Updates and Commit to them, but that is already the case > for internal Commits. The joiner can Commit to already existing Update > Proposals from other members. > > Whether all of the above is allowed should only be governed by the policy for > a group, nothing else. As a reminder: all clients MUST have the same policy > for a certain group in order ta validate/refute Proposals and Commits. > > This pretty much motivates my idea for fully re-using the existing Commit > syntax and only introduce the new ExternalInitSecret Proposal. > >> >> >> # External commit syntax: Separate or Together >> >> Assume for the moment that we are not going to do the above asymmetric >> calculation for every commit. Then we need some extra, optional syntax to >> carry `enc`, either as an optional field on Commit or as a new Proposal, >> which is the agreed mechanism for extending Commits. (If we do it every >> time, we can just make this part of Commit.) In the below, I’ll assume a >> new Proposal, say ExternalInitSecret. >> >> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; > > This is exactly the Proposal we need. > >> >> Given the requirement for an Add proposal, the joiner now has to send a >> “flight of messages”: >> >> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit > > I see some more nuance here. The first Add Proposal does not have to be > issued by the new joiner, it could very well be an external Proposal. The > scenario I had in mind here is the following: > > A server issues an external Add Proposal for a group. The following things > can happen: > > a) Ideal scenario: > > - A member of the group comes online, validates the Add Proposal according to > the policy and references it in an internal Commit (no External Commit > needed) and sends a Welcome message to the new member > > b) Equally ideal scenario: > > - The new joiner comes online before anyone else, has access to the public > group data but does not need to communicate with the group. Nothing happens. > > c) Emergency scenario: > > - The new joiner comes online before anyone else and needs to urgently send a > message to the group. The new joiner creates the ExternalInitSecret Proposal > and the Commit and sends both to group. > >> >> Let’s call this the Separate Option. It’s a bit heavyweight, since each of >> these is signed separately. It’s duplicative, since the KeyPackage in the >> Add is immediately overwritten by the (necessarily different) KP in the >> Commit. And you have potential fate-sharing issues, since all three need >> to succeed or fail. >> >> You could also envision a Together Option, where we define another >> top-level content type (parallel to Proposal and Commit) for this purpose: >> >> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } ExternalCommit; >> >> That would avoid all of the challenges above, but it optimizes out all of >> the flexibility to include other proposals. So maybe it’s worth >> considering an Extensible Together Option, where we can put extra proposals >> into an ExternalCommit >> >> struct { Proposal proposals<0..2^32-1>; opaque kem_output<0..2^16-1>; >> UpdatePath path; } ExternalCommit; >> >> Personally, I kind of like the Flexible Together Option, since it provides >> simplicity and extensibility. And to be honest, I’ve been wondering if we >> should allow inline proposals in Commit for a while, along just these >> lines. If we do this option, we should probably back-port it to Commit as >> well. >> > > As mentioned above, I’m all for re-using the existing Commit syntax because > of clarity, simplicity and flexibility. > > I do agree that the amount of signatures is sub-optimal, and this is > something that also occurs in other situations. For example, when a member > wants to add n new members at once to the group, it needs to compute n+1 > signatures for that. You mention the idea of inline proposals: Would that be > a proposal that doesn’t have a signature, but still all other information? If > so, I think it would be worthwhile looking at that separately, because as you > say, it could be back-ported to internal Commits as well. I’m all for > exploring that idea further. > >> >> # Syntax for what the Joiner Needs >> >> The PR notes that the joiner needs to know a bunch of information about the >> group in order to make a well-formed ExternalCommit. In earlier iterations >> of this style of join, we had a GroupInitKey that carried the right >> information. Following that pattern here, we get something like the >> following: >> >> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 epoch; >> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>; >> Extension extensions<0..2^32-1>; } GroupKeyPackage; > > This is what the PR currently says, except that the PR used GroupContext and > has the full public tree. I agree that the tree hash should be enough and > I’ll change the PR accordingly. > >> >> Note that this object is essentially the same as a GroupInfo object. The >> only things it is missing are interim_transcript_hash and signature, both >> of which might be useful. So maybe all we need to do here is say that >> clients can publish GroupInfo unencrypted if they want to enable self-adds, >> in addition to distributing it in encrypted form in Welcome. > > While the two are awfully similar, the signature on GroupInfo is not required > here and might have undesired effects w.r.t deniability if this is publicly > accessible. The other reason for not wanting the signature is that it would > be an additional signature to compute with every Commit, making them even > more expensive. I propose to keep the struct as-is. > >> >> In any case, it seems like it would be useful to have some syntax for >> this. >> >> Hope this helps, —RLB > > > TL;DR: > > I propose the following: > > - Keep the current Commit syntax - Allow all kinds of Proposals for External > Commits, same as with internal Commits - Do the HPKE-based init secret for > External Commits - Introduce the ExternalInitSecret Proposal and make it > mandatory for External Commits - Explore the idea of inline proposals > separately - Do not re-use signed GroupInfo struct and keep the adjusted > ExternalCommitInfo instead > > Raphael > >> _______________________________________________ MLS mailing list >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ MLS mailing list > MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Oct 7 05:57:36 2020 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 C4BF73A0128 for ; Wed, 7 Oct 2020 05:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpZjBwBg3ND9 for ; Wed, 7 Oct 2020 05:57:31 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 A1A093A00E5 for ; Wed, 7 Oct 2020 05:57:30 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id b12so2028542edz.11 for ; Wed, 07 Oct 2020 05:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJOtJ+xUV91ombcQ8OhO22CZYe7xAK6Uoi8l1lWktM4=; b=bn+4mY5e+fOyzlzQSwELwV70NErz2gXaDbKyFo7wzW/h4y2rHl2sBlvYH2xIwGTN4J KPMO62k/3VKTakS4D3/JiGKQuoxXfiavEMaYi9U2DfYBI3u2dF+liVu3qiK7gqpF6yxy FoVKZmUi7+2TFrbi8S/YWhpmOLbII4uwCK4BNdo/Cqd/83PZMXTVSY7tv5SBKJfrz4WB bFfEi8ZkLgecDwb/8CYlxw1oSOS5SdV8pmWL1Aja7IZkPMVpOaQbMpy1fmyc/bGbyPip TGDchj29xdDwvU9HnlGhcpcjMEpV8g9BGA4XWPBEGKVTmFT56emE49oV4iREmXyhb/oV tYFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IJOtJ+xUV91ombcQ8OhO22CZYe7xAK6Uoi8l1lWktM4=; b=aWdgaIB7849ELZW6RyhdY8BsOMX6Dp1Uf9omzzSy8th1sYwccN4WaF95F3n0I/X0Po Gckq1GKPqF2jSj970h06g8nc/bHrFiLjfjBa3ByLpqeVjyLk75mySP0XhdLcSTSJLspC DOG6IeNIznYv7kj3BczXaMpSndGfydeSMxOe76YQv3vpi4YHVAIwkGbc1OclmQDmPpbP CLbxARxaCVDMUAg+kzItp5uyrWZ0v4ajj17TF9z0lVJ5cVtlrZ3OZRunph8dG77UrCfU qxiRH5gK+jfqpoQB/dVbq9axh7DtBHO9ioFD+PkN/g1nyGcLstwoDAFDqEZND1IQLINq rpFg== X-Gm-Message-State: AOAM530qdHUtUURyb43Qjjixs/AZ2xu3rBrX9q9hd0lZMIu44QG3Zm/e eZ4To32zs64eta8cos80rMaT8Q== X-Google-Smtp-Source: ABdhPJwW0BBKufsdhAm5iZcvCybJe60n9ReVftHKAIIhGyhnPRWMA++x8uyWx6ATOVK/UIe8h492Sw== X-Received: by 2002:aa7:dcc7:: with SMTP id w7mr3464762edu.80.1602075448571; Wed, 07 Oct 2020 05:57:28 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id rn4sm1577406ejb.43.2020.10.07.05.57.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 05:57:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: Date: Wed, 7 Oct 2020 14:57:26 +0200 Cc: mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> To: Joel Alwen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 12:57:35 -0000 I think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use case! Raphael > On 7 Oct 2020, at 13:27, Joel Alwen wrote: >=20 > On 7 Oct 2020, at 03:20, Richard Barnes wrote: >> Assume for the moment that we are not going to do the above = asymmetric >> calculation for every commit. Then we need some extra, optional = syntax to >> carry `enc`, either as an optional field on Commit or as a new = Proposal, >> which is the agreed mechanism for extending Commits. (If we do it = every >> time, we can just make this part of Commit.) In the below, I=E2=80=99l= l assume a >> new Proposal, say ExternalInitSecret. > Isn't it a bit redundant to have the External party prepare a full > (ExternInitSecret) proposal packet only to then immediately commit to = it? That > means a full extra frame of bandwidth, an extra signature for the = external party > and an extra sig verification for group members. >=20 > I'm wondering what the motivation is for making this an explicit = proposal > instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n] > iff no kem_output field is included in the commit packet. Otherwise it = uses the > "external_init_secret" computed as Richard described.) >=20 > ATM I can't think of a scenario where we wouldnt want the external = committer to > also be the one creating the ExternalInitSecret proposal and = immediatly > committing to it... >=20 > - Jo=C3=ABl >=20 >=20 > On 07/10/2020 12:36, Raphael Robert wrote: >> Thanks Richard for looking at all aspects in detail! >>=20 >> I thought about these things as well and will comment inline: >>=20 >>> On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>>=20 >>> Hey all, >>>=20 >>> I wanted to send some thoughts on how to implement external commit, = as a >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the = proposal >>> is: >>>=20 >>> - Rather than re-using Proposal/Commit, we should make a new = ExternalCommit >>> message, parallel to Proposal/Commit >>=20 >> I think we are better off with re-using the current Commit syntax and = I=E2=80=99ll >> explain why further below. >>=20 >>> - We should also define a syntax for telling the joiner the = requisite >>> information about the group >>>=20 >>> # HPKE-based init secret >>>=20 >>> The concept here is as follows: >>>=20 >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for >>> each epoch - The public key `pkG` of that key pair is published = along with >>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> some_public_group_context) to get an encapsulated key `enc` and an = HPKE >>> context `ctx` - The joiner sends the encapsulated key to the group = with >>> their external commit - The members of the group call = SetupBaseS(enc, skG, >>> some_public_group_context) to get an equivalent HPKE context `ctx` - >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to = derive >>> the init secret >>>=20 >>> So there are two syntactic requirements: >>>=20 >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the = encapsulated key >>> `enc` to the group >>=20 >> =46rom the discussion at the interim, I think there is consensus = about this >> part, we just need to add that to the PR. >>=20 >>>=20 >>>=20 >>> # What Proposals? >>>=20 >>> The current PR correctly requires that the external Commit MUST = cover an >>> Add proposal for the new member. It does not forbid the Commit = covering >>> *other* proposals. It seems like it might be useful in a couple of = cases >>> to keep that option open: >> * Including PSK proposals for additional >>> authentication when joining * Including a Remove proposal for your = prior >>> appearance when re-joining >>>=20 >>> The only current proposal that would be nonsensical is an Update. >>>=20 >>> Whether we do this has some impact on the syntax, as discussed = below. >>=20 >> While that is not very explicit in the current PR, my approach was = the >> following: >>=20 >> All Proposals should be allowed in an external Commit: >>=20 >> - Adds: The joiner (new member) could right away add more members, or = Commit >> to already existing Add Proposals if those are accessible. - Removes: = The >> joiner can remove prior appearances of itself (like you pointed out) = or >> Commit to already existing Remove Proposals. - Updates: The joiner = should of >> course not issue own Updates and Commit to them, but that is already = the case >> for internal Commits. The joiner can Commit to already existing = Update >> Proposals from other members. >>=20 >> Whether all of the above is allowed should only be governed by the = policy for >> a group, nothing else. As a reminder: all clients MUST have the same = policy >> for a certain group in order ta validate/refute Proposals and = Commits. >>=20 >> This pretty much motivates my idea for fully re-using the existing = Commit >> syntax and only introduce the new ExternalInitSecret Proposal. >>=20 >>>=20 >>>=20 >>> # External commit syntax: Separate or Together >>>=20 >>> Assume for the moment that we are not going to do the above = asymmetric >>> calculation for every commit. Then we need some extra, optional = syntax to >>> carry `enc`, either as an optional field on Commit or as a new = Proposal, >>> which is the agreed mechanism for extending Commits. (If we do it = every >>> time, we can just make this part of Commit.) In the below, I=E2=80=99= ll assume a >>> new Proposal, say ExternalInitSecret. >>>=20 >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >>=20 >> This is exactly the Proposal we need. >>=20 >>>=20 >>> Given the requirement for an Add proposal, the joiner now has to = send a >>> =E2=80=9Cflight of messages=E2=80=9D: >>>=20 >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >>=20 >> I see some more nuance here. The first Add Proposal does not have to = be >> issued by the new joiner, it could very well be an external Proposal. = The >> scenario I had in mind here is the following: >>=20 >> A server issues an external Add Proposal for a group. The following = things >> can happen: >>=20 >> a) Ideal scenario: >>=20 >> - A member of the group comes online, validates the Add Proposal = according to >> the policy and references it in an internal Commit (no External = Commit >> needed) and sends a Welcome message to the new member >>=20 >> b) Equally ideal scenario: >>=20 >> - The new joiner comes online before anyone else, has access to the = public >> group data but does not need to communicate with the group. Nothing = happens. >>=20 >> c) Emergency scenario: >>=20 >> - The new joiner comes online before anyone else and needs to = urgently send a >> message to the group. The new joiner creates the ExternalInitSecret = Proposal >> and the Commit and sends both to group. >>=20 >>>=20 >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit = heavyweight, since each of >>> these is signed separately. It=E2=80=99s duplicative, since the = KeyPackage in the >>> Add is immediately overwritten by the (necessarily different) KP in = the >>> Commit. And you have potential fate-sharing issues, since all three = need >>> to succeed or fail. >>>=20 >>> You could also envision a Together Option, where we define another >>> top-level content type (parallel to Proposal and Commit) for this = purpose: >>>=20 >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } = ExternalCommit; >>>=20 >>> That would avoid all of the challenges above, but it optimizes out = all of >>> the flexibility to include other proposals. So maybe it=E2=80=99s = worth >>> considering an Extensible Together Option, where we can put extra = proposals >>> into an ExternalCommit >>>=20 >>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;=20 >>> UpdatePath path; } ExternalCommit; >>>=20 >>> Personally, I kind of like the Flexible Together Option, since it = provides >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been = wondering if we >>> should allow inline proposals in Commit for a while, along just = these >>> lines. If we do this option, we should probably back-port it to = Commit as >>> well. >>>=20 >>=20 >> As mentioned above, I=E2=80=99m all for re-using the existing Commit = syntax because >> of clarity, simplicity and flexibility. >>=20 >> I do agree that the amount of signatures is sub-optimal, and this is >> something that also occurs in other situations. For example, when a = member >> wants to add n new members at once to the group, it needs to compute = n+1 >> signatures for that. You mention the idea of inline proposals: Would = that be >> a proposal that doesn=E2=80=99t have a signature, but still all other = information? If >> so, I think it would be worthwhile looking at that separately, = because as you >> say, it could be back-ported to internal Commits as well. I=E2=80=99m = all for >> exploring that idea further. >>=20 >>>=20 >>> # Syntax for what the Joiner Needs >>>=20 >>> The PR notes that the joiner needs to know a bunch of information = about the >>> group in order to make a well-formed ExternalCommit. In earlier = iterations >>> of this style of join, we had a GroupInitKey that carried the right >>> information. Following that pattern here, we get something like the >>> following: >>>=20 >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 = epoch;=20 >>> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>;=20= >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >>=20 >> This is what the PR currently says, except that the PR used = GroupContext and >> has the full public tree. I agree that the tree hash should be enough = and >> I=E2=80=99ll change the PR accordingly. >>=20 >>>=20 >>> Note that this object is essentially the same as a GroupInfo object. = The >>> only things it is missing are interim_transcript_hash and signature, = both >>> of which might be useful. So maybe all we need to do here is say = that >>> clients can publish GroupInfo unencrypted if they want to enable = self-adds, >>> in addition to distributing it in encrypted form in Welcome. >>=20 >> While the two are awfully similar, the signature on GroupInfo is not = required >> here and might have undesired effects w.r.t deniability if this is = publicly >> accessible. The other reason for not wanting the signature is that it = would >> be an additional signature to compute with every Commit, making them = even >> more expensive. I propose to keep the struct as-is. >>=20 >>>=20 >>> In any case, it seems like it would be useful to have some syntax = for >>> this. >>>=20 >>> Hope this helps, =E2=80=94RLB >>=20 >>=20 >> TL;DR: >>=20 >> I propose the following: >>=20 >> - Keep the current Commit syntax - Allow all kinds of Proposals for = External >> Commits, same as with internal Commits - Do the HPKE-based init = secret for >> External Commits - Introduce the ExternalInitSecret Proposal and make = it >> mandatory for External Commits - Explore the idea of inline proposals >> separately - Do not re-use signed GroupInfo struct and keep the = adjusted >> ExternalCommitInfo instead >>=20 >> Raphael >>=20 >>> _______________________________________________ MLS mailing list=20 >>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ MLS mailing list=20 >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Wed Oct 7 08:38:46 2020 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 73F573A0A83 for ; Wed, 7 Oct 2020 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R1c6gJRglX9 for ; Wed, 7 Oct 2020 08:38:40 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBB43A097B for ; Wed, 7 Oct 2020 08:38:40 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id c23so2256195qtp.0 for ; Wed, 07 Oct 2020 08:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OgflR2LxM55zp85FCXTbTM7sfS6fub3apW+e9uBO8Bc=; b=dCtI+qtIeSY0GO4zsCPrUFe3NUBD4tMrTVV5D6CnGaaU0vxDdgMnjSAT+LstTWoUWT xbo2gyz7TQc/LnbBYx/AanBAChXpqEGsE4IZYpmO6rSJGlvMB6HRdnmSZkyXrBjld2v5 sp2shc196dUDhgZQVWdf4Oc4Q0SQ3skV4cHpxkf5L5GknPJUDHi3I7K65bluntQtWTW1 2jxfFdS1AY1XcfCbLIs8R1tv16hqnTmE5oZYKJis0rLRFpOEELFHUZrG2daPqUtEOtwQ KUUs8GYGHbcFXIgwDTPghHiIE87lePCUnQH7ie45eSQ0mmZ1JRjTXzGkjRLmA6taqMYO yOFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OgflR2LxM55zp85FCXTbTM7sfS6fub3apW+e9uBO8Bc=; b=Z4DVuNbaDF4CGWGaMjnvktgCwl0zTgIOASg0yR+215I3czxXHX2vB3NuhjW7suwxaq tavzlPr54YU/Rc2tMwLnclrqfnW9X1YNRSKAt42BJsEAGT34cK35j/ch2lqAbmIT8mvJ 7vzeQ7e81URZsBUCEVWHJb3NHoOoqLIIveMtLUOmWOq3kNr1yzk9gEOXQCvEqzDDmIlF 72vbQUmh19TrT27kVfTS0vSvhrIKqvZkMRO2F/O3kLJngLej7PBsONcASWHF7eW6HQn3 qnN28SaFuB5OyVPqgGBd53TSXIJqzUvYfcBAK9mwd475dBPzMrErZKjkGolKVLV6LKqn x8yg== X-Gm-Message-State: AOAM532jiUSHFq6vLtF8jm5NPyvDsc6VWoz1Tf69rvVYeZV+ro9EXK0+ 3hmdezVJaLsmpq3oSygljojenbt1qi5k9xDrdHaq7Sacp9RIPQ== X-Google-Smtp-Source: ABdhPJx+eIA+nGaCuwR9hHul3fL9r4TdSxgzsiGvZBwrCCy6R9kDz6h6altJSBiTWDeiBGZyqc4QT7UncdX8y8ZfBJ4= X-Received: by 2002:aed:3ae5:: with SMTP id o92mr3703292qte.265.1602085119143; Wed, 07 Oct 2020 08:38:39 -0700 (PDT) MIME-Version: 1.0 References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> In-Reply-To: <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> From: Richard Barnes Date: Wed, 7 Oct 2020 11:38:26 -0400 Message-ID: To: Raphael Robert Cc: Joel Alwen , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000006d4bfb05b1168221" Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:38:44 -0000 --0000000000006d4bfb05b1168221 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, how about the following proposal (heh): - Add ExternalInitSecret proposal - Add an "inline proposals" field to Commit that lets the committer send proposals with a commit Two remaining worries here: - Validation: You want it to be the case that an ExternalInitSecret is only present for a Commit signed by a new joiner. So some that information will have to be passed from MLSPlaintext validation to Commit processing. Or maybe we don't care about that restriction? It seems like a member sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's not bad enough to absolutely forbid / have hard checks against. - Complexity: MLSPlaintext signature validation has to find a key to verify the signature. I guess in this case, it should take the one for the Committer (Commit.update_path.leaf_key_package.public_key), but it should also be the case that that key was added to the group with this Commit. In any case, this probably calls for a new sender type. Maybe these can both be solved with a flag passed into Commit processing: if (external_commit) { // verify that there is an Add corresponding to update_path.leaf_key_package } else { // verify that ExternalInitSecret is not present } Even if so, that logic should get specified in the commit processing section of the spec. --RLB On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert wrote: > I think that=E2=80=99s exactly the motivation we need for inline proposal= s, this > surplus of signatures is not specific to this use case! > > Raphael > > > On 7 Oct 2020, at 13:27, Joel Alwen wrote: > > > > On 7 Oct 2020, at 03:20, Richard Barnes wrote: > >> Assume for the moment that we are not going to do the above asymmetric > >> calculation for every commit. Then we need some extra, optional > syntax to > >> carry `enc`, either as an optional field on Commit or as a new Proposa= l, > >> which is the agreed mechanism for extending Commits. (If we do it eve= ry > >> time, we can just make this part of Commit.) In the below, I=E2=80=99= ll assume > a > >> new Proposal, say ExternalInitSecret. > > Isn't it a bit redundant to have the External party prepare a full > > (ExternInitSecret) proposal packet only to then immediately commit to > it? That > > means a full extra frame of bandwidth, an extra signature for the > external party > > and an extra sig verification for group members. > > > > I'm wondering what the motivation is for making this an explicit propos= al > > instead of, say, a second mode for commits. (E.g. a commit uses > init_secret[n] > > iff no kem_output field is included in the commit packet. Otherwise it > uses the > > "external_init_secret" computed as Richard described.) > > > > ATM I can't think of a scenario where we wouldnt want the external > committer to > > also be the one creating the ExternalInitSecret proposal and immediatly > > committing to it... > > > > - Jo=C3=ABl > > > > > > On 07/10/2020 12:36, Raphael Robert wrote: > >> Thanks Richard for looking at all aspects in detail! > >> > >> I thought about these things as well and will comment inline: > >> > >>> On 7 Oct 2020, at 03:20, Richard Barnes wrote: > >>> > >>> Hey all, > >>> > >>> I wanted to send some thoughts on how to implement external commit, a= s > a > >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the > proposal > >>> is: > >>> > >>> - Rather than re-using Proposal/Commit, we should make a new > ExternalCommit > >>> message, parallel to Proposal/Commit > >> > >> I think we are better off with re-using the current Commit syntax and > I=E2=80=99ll > >> explain why further below. > >> > >>> - We should also define a syntax for telling the joiner the requisite > >>> information about the group > >>> > >>> # HPKE-based init secret > >>> > >>> The concept here is as follows: > >>> > >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key schedul= e > for > >>> each epoch - The public key `pkG` of that key pair is published along > with > >>> with other group metadata - The joiner calls SetupBaseS(pkG, > >>> some_public_group_context) to get an encapsulated key `enc` and an HP= KE > >>> context `ctx` - The joiner sends the encapsulated key to the group wi= th > >>> their external commit - The members of the group call SetupBaseS(enc, > skG, > >>> some_public_group_context) to get an equivalent HPKE context `ctx` - > >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to > derive > >>> the init secret > >>> > >>> So there are two syntactic requirements: > >>> > >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the enc= apsulated > key > >>> `enc` to the group > >> > >> From the discussion at the interim, I think there is consensus about > this > >> part, we just need to add that to the PR. > >> > >>> > >>> > >>> # What Proposals? > >>> > >>> The current PR correctly requires that the external Commit MUST cover > an > >>> Add proposal for the new member. It does not forbid the Commit > covering > >>> *other* proposals. It seems like it might be useful in a couple of > cases > >>> to keep that option open: > >> * Including PSK proposals for additional > >>> authentication when joining * Including a Remove proposal for your > prior > >>> appearance when re-joining > >>> > >>> The only current proposal that would be nonsensical is an Update. > >>> > >>> Whether we do this has some impact on the syntax, as discussed below. > >> > >> While that is not very explicit in the current PR, my approach was the > >> following: > >> > >> All Proposals should be allowed in an external Commit: > >> > >> - Adds: The joiner (new member) could right away add more members, or > Commit > >> to already existing Add Proposals if those are accessible. - Removes: > The > >> joiner can remove prior appearances of itself (like you pointed out) o= r > >> Commit to already existing Remove Proposals. - Updates: The joiner > should of > >> course not issue own Updates and Commit to them, but that is already > the case > >> for internal Commits. The joiner can Commit to already existing Update > >> Proposals from other members. > >> > >> Whether all of the above is allowed should only be governed by the > policy for > >> a group, nothing else. As a reminder: all clients MUST have the same > policy > >> for a certain group in order ta validate/refute Proposals and Commits. > >> > >> This pretty much motivates my idea for fully re-using the existing > Commit > >> syntax and only introduce the new ExternalInitSecret Proposal. > >> > >>> > >>> > >>> # External commit syntax: Separate or Together > >>> > >>> Assume for the moment that we are not going to do the above asymmetri= c > >>> calculation for every commit. Then we need some extra, optional > syntax to > >>> carry `enc`, either as an optional field on Commit or as a new > Proposal, > >>> which is the agreed mechanism for extending Commits. (If we do it > every > >>> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll > assume a > >>> new Proposal, say ExternalInitSecret. > >>> > >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; > >> > >> This is exactly the Proposal we need. > >> > >>> > >>> Given the requirement for an Add proposal, the joiner now has to send= a > >>> =E2=80=9Cflight of messages=E2=80=9D: > >>> > >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit > >> > >> I see some more nuance here. The first Add Proposal does not have to b= e > >> issued by the new joiner, it could very well be an external Proposal. > The > >> scenario I had in mind here is the following: > >> > >> A server issues an external Add Proposal for a group. The following > things > >> can happen: > >> > >> a) Ideal scenario: > >> > >> - A member of the group comes online, validates the Add Proposal > according to > >> the policy and references it in an internal Commit (no External Commit > >> needed) and sends a Welcome message to the new member > >> > >> b) Equally ideal scenario: > >> > >> - The new joiner comes online before anyone else, has access to the > public > >> group data but does not need to communicate with the group. Nothing > happens. > >> > >> c) Emergency scenario: > >> > >> - The new joiner comes online before anyone else and needs to urgently > send a > >> message to the group. The new joiner creates the ExternalInitSecret > Proposal > >> and the Commit and sends both to group. > >> > >>> > >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit heav= yweight, since > each of > >>> these is signed separately. It=E2=80=99s duplicative, since the KeyP= ackage in > the > >>> Add is immediately overwritten by the (necessarily different) KP in t= he > >>> Commit. And you have potential fate-sharing issues, since all three > need > >>> to succeed or fail. > >>> > >>> You could also envision a Together Option, where we define another > >>> top-level content type (parallel to Proposal and Commit) for this > purpose: > >>> > >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } > ExternalCommit; > >>> > >>> That would avoid all of the challenges above, but it optimizes out al= l > of > >>> the flexibility to include other proposals. So maybe it=E2=80=99s wo= rth > >>> considering an Extensible Together Option, where we can put extra > proposals > >>> into an ExternalCommit > >>> > >>> struct { Proposal proposals<0..2^32-1>; opaque kem_output<0..2^16-1>; > >>> UpdatePath path; } ExternalCommit; > >>> > >>> Personally, I kind of like the Flexible Together Option, since it > provides > >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been wo= ndering > if we > >>> should allow inline proposals in Commit for a while, along just these > >>> lines. If we do this option, we should probably back-port it to > Commit as > >>> well. > >>> > >> > >> As mentioned above, I=E2=80=99m all for re-using the existing Commit s= yntax > because > >> of clarity, simplicity and flexibility. > >> > >> I do agree that the amount of signatures is sub-optimal, and this is > >> something that also occurs in other situations. For example, when a > member > >> wants to add n new members at once to the group, it needs to compute n= +1 > >> signatures for that. You mention the idea of inline proposals: Would > that be > >> a proposal that doesn=E2=80=99t have a signature, but still all other > information? If > >> so, I think it would be worthwhile looking at that separately, because > as you > >> say, it could be back-ported to internal Commits as well. I=E2=80=99m = all for > >> exploring that idea further. > >> > >>> > >>> # Syntax for what the Joiner Needs > >>> > >>> The PR notes that the joiner needs to know a bunch of information > about the > >>> group in order to make a well-formed ExternalCommit. In earlier > iterations > >>> of this style of join, we had a GroupInitKey that carried the right > >>> information. Following that pattern here, we get something like the > >>> following: > >>> > >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 > epoch; > >>> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>; > >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; > >> > >> This is what the PR currently says, except that the PR used > GroupContext and > >> has the full public tree. I agree that the tree hash should be enough > and > >> I=E2=80=99ll change the PR accordingly. > >> > >>> > >>> Note that this object is essentially the same as a GroupInfo object. > The > >>> only things it is missing are interim_transcript_hash and signature, > both > >>> of which might be useful. So maybe all we need to do here is say tha= t > >>> clients can publish GroupInfo unencrypted if they want to enable > self-adds, > >>> in addition to distributing it in encrypted form in Welcome. > >> > >> While the two are awfully similar, the signature on GroupInfo is not > required > >> here and might have undesired effects w.r.t deniability if this is > publicly > >> accessible. The other reason for not wanting the signature is that it > would > >> be an additional signature to compute with every Commit, making them > even > >> more expensive. I propose to keep the struct as-is. > >> > >>> > >>> In any case, it seems like it would be useful to have some syntax for > >>> this. > >>> > >>> Hope this helps, =E2=80=94RLB > >> > >> > >> TL;DR: > >> > >> I propose the following: > >> > >> - Keep the current Commit syntax - Allow all kinds of Proposals for > External > >> Commits, same as with internal Commits - Do the HPKE-based init secret > for > >> External Commits - Introduce the ExternalInitSecret Proposal and make = it > >> mandatory for External Commits - Explore the idea of inline proposals > >> separately - Do not re-use signed GroupInfo struct and keep the adjust= ed > >> ExternalCommitInfo instead > >> > >> Raphael > >> > >>> _______________________________________________ MLS mailing list > >>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls > >> > >> _______________________________________________ MLS mailing list > >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls > >> > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000006d4bfb05b1168221 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, how about the following proposal (heh):

- Add ExternalInitSecret proposal
- Add an "= inline proposals" field to Commit that lets the committer send proposa= ls with a commit

Two remaining worries here:
<= /div>

- Validation: You want it to be the case that an E= xternalInitSecret is only present for a Commit signed by a new joiner.=C2= =A0 So some that information will have to be passed from MLSPlaintext valid= ation to Commit processing.=C2=A0 Or maybe we don't care about that res= triction?=C2=A0 It seems like a member sending ExternalInitSecret should at= least be SHOULD NOT, but maybe it's not bad enough to absolutely forbi= d / have hard checks against.

- Complexity: ML= SPlaintext signature validation has to find a key to verify the signature.= =C2=A0 I guess in this case, it should take the one for the Committer (Comm= it.update_path.leaf_key_package.public_key), but it should also be the case= that that key was added to the group with this Commit.=C2=A0 In any case, = this probably calls for a new sender type.

May= be these can both be solved with a flag passed into Commit processing:

if (external_commit) {
=C2=A0 // verify that= there is an Add corresponding to update_path.leaf_key_package
} = else {
=C2=A0 // verify that ExternalInitSecret is not presen= t
}

Even if so, that logic should ge= t specified in the commit processing section of the spec.

--RLB


=
On Wed, Oct 7, 2020 at 8:57 AM Raphae= l Robert <raphael=3D40wire.= com@dmarc.ietf.org> wrote:
I think that=E2=80=99s exactly the motivation we need for= inline proposals, this surplus of signatures is not specific to this use c= ase!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>> Assume for the moment that we are not going to do the above asymme= tric
>> calculation for every commit.=C2=A0 Then we need some extra, optio= nal syntax=C2=A0 to
>> carry `enc`, either as an optional field on Commit or as a new Pro= posal,
>> which is the agreed mechanism for extending Commits.=C2=A0 (If we = do it every
>> time, we can just make this part of Commit.)=C2=A0 In the below, I= =E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a full=
> (ExternInitSecret) proposal packet only to then immediately commit to = it? That
> means a full extra frame of bandwidth, an extra signature for the exte= rnal party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit p= roposal
> instead of, say, a second mode for commits. (E.g. a commit uses init_s= ecret[n]
> iff no kem_output field is included in the commit packet. Otherwise it= uses the
> "external_init_secret" computed as Richard described.)
>
> ATM I can't think of a scenario where we wouldnt want the external= committer to
> also be the one creating the ExternalInitSecret proposal and immediatl= y
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external co= mmit, as a
>>> prelude to a PR.=C2=A0 This is a little bit of an essay, so tl= ;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a new E= xternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the re= quisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for
>>> each epoch - The public key `pkG` of that key pair is publishe= d along with
>>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> some_public_group_context) to get an encapsulated key `enc` an= d an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to the g= roup with
>>> their external commit - The members of the group call SetupBas= eS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE context `= ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)= ` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending = the encapsulated key
>>> `enc` to the group
>>
>> From the discussion at the interim, I think there is consensus abo= ut this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit MUS= T cover an
>>> Add proposal for the new member.=C2=A0 =C2=A0It does not forbi= d the Commit covering
>>> *other* proposals.=C2=A0 It seems like it might be useful in a= couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal for = your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an Upda= te.
>>>
>>> Whether we do this has some impact on the syntax, as discussed= below.
>>
>> While that is not very explicit in the current PR, my approach was= the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more members,= or Commit
>> to already existing Add Proposals if those are accessible. - Remov= es: The
>> joiner can remove prior appearances of itself (like you pointed ou= t) or
>> Commit to already existing Remove Proposals. - Updates: The joiner= should of
>> course not issue own Updates and Commit to them, but that is alrea= dy the case
>> for internal Commits. The joiner can Commit to already existing Up= date
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by the= policy for
>> a group, nothing else. As a reminder: all clients MUST have the sa= me policy
>> for a certain group in order ta validate/refute Proposals and Comm= its.
>>
>> This pretty much motivates my idea for fully re-using the existing= Commit
>> syntax and only introduce the new ExternalInitSecret Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
>>>
>>> Assume for the moment that we are not going to do the above as= ymmetric
>>> calculation for every commit.=C2=A0 Then we need some extra, o= ptional syntax=C2=A0 to
>>> carry `enc`, either as an optional field on Commit or as a new= Proposal,
>>> which is the agreed mechanism for extending Commits.=C2=A0 (If= we do it every
>>> time, we can just make this part of Commit.)=C2=A0 In the belo= w, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSec= ret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now has = to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not have = to be
>> issued by the new joiner, it could very well be an external Propos= al. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The followin= g things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add Proposal a= ccording to
>> the policy and references it in an internal Commit (no External Co= mmit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to th= e public
>> group data but does not need to communicate with the group. Nothin= g happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to urge= ntly send a
>> message to the group. The new joiner creates the ExternalInitSecre= t Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.=C2=A0 It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.=C2=A0 It=E2=80=99s duplicative, si= nce the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily different) = KP in the
>>> Commit.=C2=A0 And you have potential fate-sharing issues, sinc= e all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define ano= ther
>>> top-level content type (parallel to Proposal and Commit) for t= his purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; = } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it optimizes= out all of
>>> the flexibility to include other proposals.=C2=A0 So maybe it= =E2=80=99s worth
>>> considering an Extensible Together Option, where we can put ex= tra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque kem_outpu= t<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, since= it provides
>>> simplicity and extensibility.=C2=A0 And to be honest, I=E2=80= =99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along jus= t these
>>> lines.=C2=A0 If we do this option, we should probably back-por= t it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing Comm= it syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and this = is
>> something that also occurs in other situations. For example, when = a member
>> wants to add n new members at once to the group, it needs to compu= te n+1
>> signatures for that. You mention the idea of inline proposals: Wou= ld that be
>> a proposal that doesn=E2=80=99t have a signature, but still all ot= her information? If
>> so, I think it would be worthwhile looking at that separately, bec= ause as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of informat= ion about the
>>> group in order to make a well-formed ExternalCommit.=C2=A0 In = earlier iterations
>>> of this style of join, we had a GroupInitKey that carried the = right
>>> information. Following that pattern here, we get something lik= e the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque group_id<0..255&g= t;; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque confirmed_transcript_ha= sh<0..255>;
>>> Extension extensions<0..2^32-1>; } GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used GroupC= ontext and
>> has the full public tree. I agree that the tree hash should be eno= ugh and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a GroupInfo o= bject.=C2=A0 The
>>> only things it is missing are interim_transcript_hash and sign= ature, both
>>> of which might be useful.=C2=A0 So maybe all we need to do her= e is say that
>>> clients can publish GroupInfo unencrypted if they want to enab= le self-adds,
>>> in addition to distributing it in encrypted form in Welcome. >>
>> While the two are awfully similar, the signature on GroupInfo is n= ot required
>> here and might have undesired effects w.r.t deniability if this is= publicly
>> accessible. The other reason for not wanting the signature is that= it would
>> be an additional signature to compute with every Commit, making th= em even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some syn= tax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals fo= r External
>> Commits, same as with internal Commits - Do the HPKE-based init se= cret for
>> External Commits - Introduce the ExternalInitSecret Proposal and m= ake it
>> mandatory for External Commits - Explore the idea of inline propos= als
>> separately - Do not re-use signed GroupInfo struct and keep the ad= justed
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing li= st
>>> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing list <= br> >> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000006d4bfb05b1168221-- From nobody Wed Oct 7 08:48:57 2020 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 409753A0AA1 for ; Wed, 7 Oct 2020 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmC17KyhUuzb for ; Wed, 7 Oct 2020 08:48:54 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D7B3A0A82 for ; Wed, 7 Oct 2020 08:48:54 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id w12so3287145qki.6 for ; Wed, 07 Oct 2020 08:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PE8lzhZcountODNx2WZciJEuusfh8XVsaZqmxSugGbY=; b=HObAy1ReOOKfdl3wjlkoRInAelvjmh1Z9glWBhrixhbkmFNesWMpgTGUsFmwmq0hgP iBqOAndYzHv9YN1/3ftkUCmXyQetxOvZY5yCg8SWaf7z/vHTcWK25zyhwBGaY5iWIl5i gU3sQB0oLcLqquLCLtzeIxO2XwflQ8Jitg/epfGSz85U+Khoi01KBQ6WM7HNrcZ9s6Fd 6OBpthtbdfVGjd2SjwxoHbjYQm66wceGAEYnoewPUuhqUvycG9/zIg3IU2px+mmS2mwf NS4own5uCIR77CY/RNdRT6xPD0qNm9aE+bPhoTl8WMZNL/N8eQP0CA/zb/uFVNQ5GwwP cbFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PE8lzhZcountODNx2WZciJEuusfh8XVsaZqmxSugGbY=; b=Vr1ECcKABjJSdEqyH/n/n6pHT8+lrg8c/UpRBkwHVwKegqj40Q1F2H6RqhRbX7OES/ x+5w9Sb92APoHEGf/SO3iPd0FRaI9kTACVKDeBCFugI7iz74HjNyitK98yxu1KG9sNbx 9JolkEDrbHyySX3twIpOW+r+OIRRqMPgRciPCD75PQTPJF62/Hcc9GoDAr8jRaCCi0Rm qe3JWbUWKLEKz9jbgReL7F7aQeadm6mZ5LmkKI/+iCXEQ8JH1bPeIc1wqYi3NaGQN93r EaejqrCwE393rwlcSQgPsXbMYdQqySdVRpZzOTe9pW7eUj8y+MNE6NY0Nf2rKVjbvmgZ l75w== X-Gm-Message-State: AOAM532U8of18zJ45JDbnHm0w36s4SY3zHjaFXYLwnqqYdMQxt/NeiY8 Nc7ePtOfaTS7WSq89wgcv/xMKoxeMmqudsOAqIwUUA== X-Google-Smtp-Source: ABdhPJwB7x86gHL9txi9nv/pOvX0rpePOYq/eN6zVlf2O4qwSvhe+nYriZfrCXGpEZKZ07yLOtowe2j//YdWVirtYE8= X-Received: by 2002:a05:620a:15b6:: with SMTP id f22mr2245688qkk.490.1602085733162; Wed, 07 Oct 2020 08:48:53 -0700 (PDT) MIME-Version: 1.0 References: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> In-Reply-To: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> From: Richard Barnes Date: Wed, 7 Oct 2020 11:48:40 -0400 Message-ID: To: Raphael Robert Cc: Joel Alwen , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000006722205b116a7d1" Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:48:56 -0000 --00000000000006722205b116a7d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for this analysis, Jo=C3=ABl. This aligns with my intuition as well= , and seems like a good rationale for a hard prohibition on AEC / ExternalCommit from group members. (Something about which I had waffled in a previous email.) Another way to think about this: PCS with regard to a member is about removing an old version of that member (as represented by an HPKE key and signing key). AEC is designed to allow joins, which means that AEC-from-inside allows the old, compromised version of the member to rejoin, which kills PCS. --Richard On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert wrote: > I second that assessment, my idea behind External Commits was to offer a > mechanism where internal Commits couldn=E2=80=99t be used. External Commi= ts should > remain optional (this can easily be achieved by not providing the > ExternalCommitInfo package to new members) and when they are used they > should be used as a last resort mechanism (meaning there really is no way > to add a member with an internal Commit). > > I also think MLS should should remain in the position to cover most > scenarios from mainstream consumer messaging to messaging in high securit= y > environments. External Commits make the former much more accessible but > shouldn=E2=80=99t jeopardise the latter. > > Raphael > > > On 6 Oct 2020, at 18:38, Joel Alwen wrote: > > > > Hey people, > > > > To follow up on the discussion at the end of the Interim about whether > to use > > the new "asymmetric external commit" (AEC) mechanism for internal > commits I > > wanted to summarize my thoughts here. For brevity let SIC be our curren= t > > "symmetric internal commit" mechanism. > > > > - AEC requires extra asymmetric crypto operations (both for committer a= nd > > receiver) compared to SIC which I think we should avoid if we can, even > at the > > cost of some code complexity. > > > > - AEC doesn't ensure the committer knows the old epoch's key schedule. > This can > > play a deciding role in several types of attacks. > > > > Consider this execution: > > > > 1. Alice is in a group. Her state leaks (including her signining key). > > 2. Alice commits (to arbitrary propal). > > > > At this point, the adversary can still forge a new AEC from Alice but > not an SIC. > > > > Worse, step 2 could have instead been "Alice sends an update proposal > replacing > > her leaf HPKE but keeping the her sig keys (e.g. because new credential= s > are > > costly to come by). Someone commits to the new proposal." At this point > I'd > > expect PCS to have kicked in for Alice (as it does when using SIC). But > not for > > AECs since Alice's signing key is all thats needed to forge a new AEC. > > > > I think it is not worth weakening security this way if we dont have to. > > (Especially, since in some deployments external commits may not be a > supported > > feature at all.) > > > > - As for what may or may not be displaid to users, that's really up to > the > > implementation. IMO our goal should be to make the protocol as secure a= s > we can > > subject to reasonable costs. Which aspects of the resulting security > properties > > are ultimately communicated to users should, in principle, be left up t= o > > implementations. That means we shouldn't be designing away security > features > > only because we think they might be hard to communicate. (Nor does it > seem that > > inconceivable to me that some implementation may end up explicitly > signaling > > whether a commit was external vs internal.) > > > > - Jo=C3=ABl > > > > _______________________________________________ > > 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 > --00000000000006722205b116a7d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this analysis, Jo=C3=ABl.=C2=A0 This align= s with my intuition as well, and seems like a good rationale for a hard pro= hibition on AEC / ExternalCommit from group members.=C2=A0 (Something about= which I had waffled in a previous email.)

Another= way to think about this: PCS with regard to a member is about removing an = old version of that member (as represented by an HPKE key and signing key).= =C2=A0 AEC is designed to allow joins, which means that AEC-from-inside all= ows the old, compromised version of the member to rejoin, which kills PCS.<= br>

--Richard

On Tue, Oct 6, 2020 at 12:5= 5 PM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I second that assessment, my idea behind Exter= nal Commits was to offer a mechanism where internal Commits couldn=E2=80=99= t be used. External Commits should remain optional (this can easily be achi= eved by not providing the ExternalCommitInfo package to new members) and wh= en they are used they should be used as a last resort mechanism (meaning th= ere really is no way to add a member with an internal Commit).

I also think MLS should should remain in the position to cover most scenari= os from mainstream consumer messaging to messaging in high security environ= ments. External Commits make the former much more accessible but shouldn=E2= =80=99t jeopardise the latter.

Raphael

> On 6 Oct 2020, at 18:38, Joel Alwen <jalwen@wickr.com> wrote:
>
> Hey people,
>
> To follow up on the discussion at the end of the Interim about whether= to use
> the new "asymmetric external commit" (AEC) mechanism for int= ernal commits I
> wanted to summarize my thoughts here. For brevity let SIC be our curre= nt
> "symmetric internal commit" mechanism.
>
> - AEC requires extra asymmetric crypto operations (both for committer = and
> receiver) compared to SIC which I think we should avoid if we can, eve= n at the
> cost of some code complexity.
>
> - AEC doesn't ensure the committer knows the old epoch's key s= chedule. This can
> play a deciding role in several types of attacks.
>
> Consider this execution:
>
> 1. Alice is in a group. Her state leaks (including her signining key).=
> 2. Alice commits (to arbitrary propal).
>
> At this point, the adversary can still forge a new AEC from Alice but = not an SIC.
>
> Worse, step 2 could have instead been "Alice sends an update prop= osal replacing
> her leaf HPKE but keeping the her sig keys (e.g. because new credentia= ls are
> costly to come by). Someone commits to the new proposal." At this= point I'd
> expect PCS to have kicked in for Alice (as it does when using SIC). Bu= t not for
> AECs since Alice's signing key is all thats needed to forge a new = AEC.
>
> I think it is not worth weakening security this way if we dont have to= .
> (Especially, since in some deployments external commits may not be a s= upported
> feature at all.)
>
> - As for what may or may not be displaid to users, that's really u= p to the
> implementation. IMO our goal should be to make the protocol as secure = as we can
> subject to reasonable costs. Which aspects of the resulting security p= roperties
> are ultimately communicated to users should, in principle, be left up = to
> implementations. That means we shouldn't be designing away securit= y features
> only because we think they might be hard to communicate. (Nor does it = seem that
> inconceivable to me that some implementation may end up explicitly sig= naling
> whether a commit was external vs internal.)
>
> - Jo=C3=ABl
>
> _______________________________________________
> 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
--00000000000006722205b116a7d1-- From nobody Wed Oct 7 08:54:03 2020 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 F00F13A0A9F for ; Wed, 7 Oct 2020 08:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2_Zr-Trk83C for ; Wed, 7 Oct 2020 08:53:56 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AA83A0AAB for ; Wed, 7 Oct 2020 08:53:51 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 188so3248024qkk.12 for ; Wed, 07 Oct 2020 08:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=owJA2DV5J4vdmY10z6qj6FGN6/pzXkJXNIG/lOWfxs8=; b=cSJeD1P4PgH27MU6Rnr4IXXdI9u8HIdRou40dxwyAcpMIwGOFhRi5bD2Ewb04KnSDs 1uM81WSR82jvHkCdqMwM2rAYxc6vPgyEHc1PQj9uifAYd0QI/izTmxaYkIsiTCoUMcLJ 5oZeB1gVSB0Iw1DDC3oslHoI7i33LzRktckbY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=owJA2DV5J4vdmY10z6qj6FGN6/pzXkJXNIG/lOWfxs8=; b=gwzptvdlzwBFlRQBoyqBmPLm/UHeo73f3F9d9is2kbS+dWdqc1G+Yj835/Pr03G1C6 Yx/HkKvR762VsJJZg4HFNvIEAjlptz0a7qWmFue/rRK9VtZj4+7uDcqzuhUguvmU3PGe e4/PvFvM9X+YnpMhwMJAsEuV1LSlO4se74kqwlkbm4Qex8BsKk8vt8MYUZ8sWuSvGmpB IHfKdRn+m1ZjBmFv2zYwsbYiT+Qt8S6R+3W4JXlidNTe95BMi/j2bAFUJHwYB+bTNi+D t1YXxT0oIbpS41twcq0DUJDUH/ZYiAzG2+SaS4hNRlIX3Bal4LYkLdUNk4Gn3YyVPODL NOcg== X-Gm-Message-State: AOAM5333KEUkuycl/N0bJ1K2PExvX/0GoQZptK8ll3F+twjoDFgsLA+C sOlz/cxv8tNhiRDnth2DEvQ/uUrCOcDaXA== X-Google-Smtp-Source: ABdhPJzzLtoaRa8+4p7Xjhqar2fVOwG3bNlQUf0XchlNK5wdbnjgEM7CxmdUwqkSgwGpCstzt6p8dA== X-Received: by 2002:a37:9e8d:: with SMTP id h135mr3606440qke.7.1602086029955; Wed, 07 Oct 2020 08:53:49 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id p77sm11812qke.39.2020.10.07.08.53.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 08:53:48 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Wed, 7 Oct 2020 11:53:47 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [MLS] 10-05-2020 MLS Virtual Interim Recording X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:53:58 -0000 Hi all, Thank you for attending the virtual interim meeting on Tuesday. The = recording is available at: = https://ietf.webex.com/recordingservice/sites/ietf/recording/playback/b225= 69d098124552aa254f70faf0e6b5 We=E2=80=99ll probably keep the recording around until just after the = next interim on 10-20-2020. Cheers, spt From nobody Wed Oct 7 13:23:58 2020 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 E365C3A134B for ; Wed, 7 Oct 2020 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVjol0WF2DsX for ; Wed, 7 Oct 2020 13:23:52 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEFE3A1348 for ; Wed, 7 Oct 2020 13:23:52 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id e22so4839516ejr.4 for ; Wed, 07 Oct 2020 13:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vhETrxkzxFr8FfGrXnHvKObZ3L/OTj/s/BiYfipmDXY=; b=Nus6h3Ic8N43B2YNgpeOp3NBw+QO44L/kKGko4SswaNaw7q2epdB8o1R1wJI04zqfJ ZidB0sSIyeybw78W8m8S5baNK/HvJXKIfh+A6n7+BBLXOogo3/0+ftk9fvyWEaJ3h0yQ iHWIpzfeXvsl68UOVfxlL4nIDPrZ/83y0vY8zoUUNjrnZBzB5VfWeGGQVEPQVOqltQyT 0VxkMFM7t5u/YCLf3aasi+jjxQHVOzSKJ4G1gmopGZm+r3j7tihE+fdZbN/dMv6Abzy/ 2MexkEJXerE7cijeO8EzBc6iKqKjBFJ/gGhYzwIDyWVSILCkyoHCqErywc/Fb9ohSYaK 2OTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vhETrxkzxFr8FfGrXnHvKObZ3L/OTj/s/BiYfipmDXY=; b=Q6gdysp5o94D10386qJS0qkyRv039ScKOIxST2E9J8xwhS5HHboCjuZBFbS01tL8NP naxxe15ORH7GVuEGvU8BUBCULt4FCNZJqeiB82a4SsdjjNUmejlXD0grMTqlbaN5mHnN eXgSGr6vX1Ls0/gPX5CkGz05dvXF3McRGhgktk8F3L4vV9bYd7PsSiO9JKOY/dKaN7g8 JjdXpWk1k1jWCINhFSJNwv3WGl9EpWltpzFyJ35sfWS0DfWjY+ZBRHfiZjzBZpqYWTo4 fDhA6T7BOUltFkedZ1Vu1JKW3Y5XLojzhfB5p8RVhxanObSgv1FJqpinlNcoV3UI2mB5 Az9Q== X-Gm-Message-State: AOAM533DIDv1ga0DYjPVMCe9RS+t/0eHjCqRnHj2ZoztxlPnZCa7D53H 99+B0C41mNsYZwdjtcaTJYPUiZVRJy5f4EpO X-Google-Smtp-Source: ABdhPJyWYNxLGt2juliBlS6/6I9umcxo98KGTKmLf010uWGX9u2Y3lN2Os2h19CXXAURfBB3+1gsog== X-Received: by 2002:a17:906:f0d8:: with SMTP id dk24mr5065349ejb.492.1602102230734; Wed, 07 Oct 2020 13:23:50 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id do22sm2100529ejc.16.2020.10.07.13.23.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 13:23:49 -0700 (PDT) From: Raphael Robert Message-Id: <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E2FD64D9-F769-4B4E-8D54-BFE0867A8D59" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 7 Oct 2020 22:23:48 +0200 In-Reply-To: Cc: Joel Alwen , Messaging Layer Security WG To: Richard Barnes References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 20:23:56 -0000 --Apple-Mail=_E2FD64D9-F769-4B4E-8D54-BFE0867A8D59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good points again! > On 7 Oct 2020, at 17:38, Richard Barnes wrote: >=20 > OK, how about the following proposal (heh): >=20 > - Add ExternalInitSecret proposal > - Add an "inline proposals" field to Commit that lets the committer = send proposals with a commit >=20 > Two remaining worries here:=20 >=20 > - Validation: You want it to be the case that an ExternalInitSecret is = only present for a Commit signed by a new joiner. So some that = information will have to be passed from MLSPlaintext validation to = Commit processing. Or maybe we don't care about that restriction? It = seems like a member sending ExternalInitSecret should at least be SHOULD = NOT, but maybe it's not bad enough to absolutely forbid / have hard = checks against. Good question. I guess you want to detect early on if it is an External = Commit or an internal one, perhaps also to block External Commits by = policy. Indeed only the signature and sender type would reveal that.=20 Should internal Commits be allowed to have a ExternalInitSecret proposal = that then just gets ignored? I don=E2=80=99t have strong feelings about = it, but I=E2=80=99m leaning towards the safe approach of saying it MUST = not. >=20 > - Complexity: MLSPlaintext signature validation has to find a key to = verify the signature. I guess in this case, it should take the one for = the Committer (Commit.update_path.leaf_key_package.public_key), but it = should also be the case that that key was added to the group with this = Commit. In any case, this probably calls for a new sender type. >=20 > Maybe these can both be solved with a flag passed into Commit = processing: >=20 > if (external_commit) { > // verify that there is an Add corresponding to = update_path.leaf_key_package > } else { > // verify that ExternalInitSecret is not present > } I=E2=80=99m thinking that the MLSPlaintext framing the External Commit = will reference a previously empty leave (namely the left most empty = leave in the tree). Normally clients would look up the leave to verify a = signature, but in this case it=E2=80=99s an indication that it is an = External Commit. Instead, clients have to parse the list of Add Proposal = the precede the Commit to determine who the signer/sender is. Lastly the = ExternalInitSecret Proposal MUST also be there. As for the sender type, couldn=E2=80=99t we use new_member here? Both = for the Add Proposal and the Commit? >=20 > Even if so, that logic should get specified in the commit processing = section of the spec. I agree that this should be written up in detailed steps to avoid any = confusion. Raphael >=20 > --RLB >=20 >=20 > On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert = > = wrote: > I think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use case! >=20 > Raphael >=20 > > On 7 Oct 2020, at 13:27, Joel Alwen > wrote: > >=20 > > On 7 Oct 2020, at 03:20, Richard Barnes > wrote: > >> Assume for the moment that we are not going to do the above = asymmetric > >> calculation for every commit. Then we need some extra, optional = syntax to > >> carry `enc`, either as an optional field on Commit or as a new = Proposal, > >> which is the agreed mechanism for extending Commits. (If we do it = every > >> time, we can just make this part of Commit.) In the below, I=E2=80=99= ll assume a > >> new Proposal, say ExternalInitSecret. > > Isn't it a bit redundant to have the External party prepare a full > > (ExternInitSecret) proposal packet only to then immediately commit = to it? That > > means a full extra frame of bandwidth, an extra signature for the = external party > > and an extra sig verification for group members. > >=20 > > I'm wondering what the motivation is for making this an explicit = proposal > > instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n] > > iff no kem_output field is included in the commit packet. Otherwise = it uses the > > "external_init_secret" computed as Richard described.) > >=20 > > ATM I can't think of a scenario where we wouldnt want the external = committer to > > also be the one creating the ExternalInitSecret proposal and = immediatly > > committing to it... > >=20 > > - Jo=C3=ABl > >=20 > >=20 > > On 07/10/2020 12:36, Raphael Robert wrote: > >> Thanks Richard for looking at all aspects in detail! > >>=20 > >> I thought about these things as well and will comment inline: > >>=20 > >>> On 7 Oct 2020, at 03:20, Richard Barnes > wrote: > >>>=20 > >>> Hey all, > >>>=20 > >>> I wanted to send some thoughts on how to implement external = commit, as a > >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the = proposal > >>> is: > >>>=20 > >>> - Rather than re-using Proposal/Commit, we should make a new = ExternalCommit > >>> message, parallel to Proposal/Commit > >>=20 > >> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll > >> explain why further below. > >>=20 > >>> - We should also define a syntax for telling the joiner the = requisite > >>> information about the group > >>>=20 > >>> # HPKE-based init secret > >>>=20 > >>> The concept here is as follows: > >>>=20 > >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for > >>> each epoch - The public key `pkG` of that key pair is published = along with > >>> with other group metadata - The joiner calls SetupBaseS(pkG, > >>> some_public_group_context) to get an encapsulated key `enc` and an = HPKE > >>> context `ctx` - The joiner sends the encapsulated key to the group = with > >>> their external commit - The members of the group call = SetupBaseS(enc, skG, > >>> some_public_group_context) to get an equivalent HPKE context `ctx` = - > >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to = derive > >>> the init secret > >>>=20 > >>> So there are two syntactic requirements: > >>>=20 > >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the = encapsulated key > >>> `enc` to the group > >>=20 > >> =46rom the discussion at the interim, I think there is consensus = about this > >> part, we just need to add that to the PR. > >>=20 > >>>=20 > >>>=20 > >>> # What Proposals? > >>>=20 > >>> The current PR correctly requires that the external Commit MUST = cover an > >>> Add proposal for the new member. It does not forbid the Commit = covering > >>> *other* proposals. It seems like it might be useful in a couple = of cases > >>> to keep that option open: > >> * Including PSK proposals for additional > >>> authentication when joining * Including a Remove proposal for your = prior > >>> appearance when re-joining > >>>=20 > >>> The only current proposal that would be nonsensical is an Update. > >>>=20 > >>> Whether we do this has some impact on the syntax, as discussed = below. > >>=20 > >> While that is not very explicit in the current PR, my approach was = the > >> following: > >>=20 > >> All Proposals should be allowed in an external Commit: > >>=20 > >> - Adds: The joiner (new member) could right away add more members, = or Commit > >> to already existing Add Proposals if those are accessible. - = Removes: The > >> joiner can remove prior appearances of itself (like you pointed = out) or > >> Commit to already existing Remove Proposals. - Updates: The joiner = should of > >> course not issue own Updates and Commit to them, but that is = already the case > >> for internal Commits. The joiner can Commit to already existing = Update > >> Proposals from other members. > >>=20 > >> Whether all of the above is allowed should only be governed by the = policy for > >> a group, nothing else. As a reminder: all clients MUST have the = same policy > >> for a certain group in order ta validate/refute Proposals and = Commits. > >>=20 > >> This pretty much motivates my idea for fully re-using the existing = Commit > >> syntax and only introduce the new ExternalInitSecret Proposal. > >>=20 > >>>=20 > >>>=20 > >>> # External commit syntax: Separate or Together > >>>=20 > >>> Assume for the moment that we are not going to do the above = asymmetric > >>> calculation for every commit. Then we need some extra, optional = syntax to > >>> carry `enc`, either as an optional field on Commit or as a new = Proposal, > >>> which is the agreed mechanism for extending Commits. (If we do it = every > >>> time, we can just make this part of Commit.) In the below, I=E2=80=99= ll assume a > >>> new Proposal, say ExternalInitSecret. > >>>=20 > >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; > >>=20 > >> This is exactly the Proposal we need. > >>=20 > >>>=20 > >>> Given the requirement for an Add proposal, the joiner now has to = send a > >>> =E2=80=9Cflight of messages=E2=80=9D: > >>>=20 > >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit > >>=20 > >> I see some more nuance here. The first Add Proposal does not have = to be > >> issued by the new joiner, it could very well be an external = Proposal. The > >> scenario I had in mind here is the following: > >>=20 > >> A server issues an external Add Proposal for a group. The following = things > >> can happen: > >>=20 > >> a) Ideal scenario: > >>=20 > >> - A member of the group comes online, validates the Add Proposal = according to > >> the policy and references it in an internal Commit (no External = Commit > >> needed) and sends a Welcome message to the new member > >>=20 > >> b) Equally ideal scenario: > >>=20 > >> - The new joiner comes online before anyone else, has access to the = public > >> group data but does not need to communicate with the group. Nothing = happens. > >>=20 > >> c) Emergency scenario: > >>=20 > >> - The new joiner comes online before anyone else and needs to = urgently send a > >> message to the group. The new joiner creates the ExternalInitSecret = Proposal > >> and the Commit and sends both to group. > >>=20 > >>>=20 > >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit = heavyweight, since each of > >>> these is signed separately. It=E2=80=99s duplicative, since the = KeyPackage in the > >>> Add is immediately overwritten by the (necessarily different) KP = in the > >>> Commit. And you have potential fate-sharing issues, since all = three need > >>> to succeed or fail. > >>>=20 > >>> You could also envision a Together Option, where we define another > >>> top-level content type (parallel to Proposal and Commit) for this = purpose: > >>>=20 > >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } = ExternalCommit; > >>>=20 > >>> That would avoid all of the challenges above, but it optimizes out = all of > >>> the flexibility to include other proposals. So maybe it=E2=80=99s = worth > >>> considering an Extensible Together Option, where we can put extra = proposals > >>> into an ExternalCommit > >>>=20 > >>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;=20 > >>> UpdatePath path; } ExternalCommit; > >>>=20 > >>> Personally, I kind of like the Flexible Together Option, since it = provides > >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been = wondering if we > >>> should allow inline proposals in Commit for a while, along just = these > >>> lines. If we do this option, we should probably back-port it to = Commit as > >>> well. > >>>=20 > >>=20 > >> As mentioned above, I=E2=80=99m all for re-using the existing = Commit syntax because > >> of clarity, simplicity and flexibility. > >>=20 > >> I do agree that the amount of signatures is sub-optimal, and this = is > >> something that also occurs in other situations. For example, when a = member > >> wants to add n new members at once to the group, it needs to = compute n+1 > >> signatures for that. You mention the idea of inline proposals: = Would that be > >> a proposal that doesn=E2=80=99t have a signature, but still all = other information? If > >> so, I think it would be worthwhile looking at that separately, = because as you > >> say, it could be back-ported to internal Commits as well. I=E2=80=99m= all for > >> exploring that idea further. > >>=20 > >>>=20 > >>> # Syntax for what the Joiner Needs > >>>=20 > >>> The PR notes that the joiner needs to know a bunch of information = about the > >>> group in order to make a well-formed ExternalCommit. In earlier = iterations > >>> of this style of join, we had a GroupInitKey that carried the = right > >>> information. Following that pattern here, we get something like = the > >>> following: > >>>=20 > >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 = epoch;=20 > >>> opaque tree_hash<0..255>; opaque = confirmed_transcript_hash<0..255>;=20 > >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; > >>=20 > >> This is what the PR currently says, except that the PR used = GroupContext and > >> has the full public tree. I agree that the tree hash should be = enough and > >> I=E2=80=99ll change the PR accordingly. > >>=20 > >>>=20 > >>> Note that this object is essentially the same as a GroupInfo = object. The > >>> only things it is missing are interim_transcript_hash and = signature, both > >>> of which might be useful. So maybe all we need to do here is say = that > >>> clients can publish GroupInfo unencrypted if they want to enable = self-adds, > >>> in addition to distributing it in encrypted form in Welcome. > >>=20 > >> While the two are awfully similar, the signature on GroupInfo is = not required > >> here and might have undesired effects w.r.t deniability if this is = publicly > >> accessible. The other reason for not wanting the signature is that = it would > >> be an additional signature to compute with every Commit, making = them even > >> more expensive. I propose to keep the struct as-is. > >>=20 > >>>=20 > >>> In any case, it seems like it would be useful to have some syntax = for > >>> this. > >>>=20 > >>> Hope this helps, =E2=80=94RLB > >>=20 > >>=20 > >> TL;DR: > >>=20 > >> I propose the following: > >>=20 > >> - Keep the current Commit syntax - Allow all kinds of Proposals for = External > >> Commits, same as with internal Commits - Do the HPKE-based init = secret for > >> External Commits - Introduce the ExternalInitSecret Proposal and = make it > >> mandatory for External Commits - Explore the idea of inline = proposals > >> separately - Do not re-use signed GroupInfo struct and keep the = adjusted > >> ExternalCommitInfo instead > >>=20 > >> Raphael > >>=20 > >>> _______________________________________________ MLS mailing list=20= > >>> MLS@ietf.org = https://www.ietf.org/mailman/listinfo/mls = > >>=20 > >> _______________________________________________ MLS mailing list=20 > >> MLS@ietf.org = https://www.ietf.org/mailman/listinfo/mls = > >>=20 > >=20 > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_E2FD64D9-F769-4B4E-8D54-BFE0867A8D59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good = points again!

On 7 Oct 2020, at 17:38, Richard Barnes = <rlb@ipv.sx> = wrote:

OK, how about the following = proposal (heh):

- Add ExternalInitSecret proposal
- Add = an "inline proposals" field to Commit that lets the committer send = proposals with a commit

Two remaining worries here:

- Validation: You want = it to be the case that an ExternalInitSecret is only present for a = Commit signed by a new joiner.  So some that information will have = to be passed from MLSPlaintext validation to Commit processing.  Or = maybe we don't care about that restriction?  It seems like a member = sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's = not bad enough to absolutely forbid / have hard checks against.

Good = question. I guess you want to detect early on if it is an External = Commit or an internal one, perhaps also to block External Commits by = policy. Indeed only the signature and sender type would reveal = that. 
Should internal Commits be allowed to have a = ExternalInitSecret proposal that then just gets ignored? I don=E2=80=99t = have strong feelings about it, but I=E2=80=99m leaning towards the safe = approach of saying it MUST not.


- Complexity: = MLSPlaintext signature validation has to find a key to verify the = signature.  I guess in this case, it should take the one for the = Committer (Commit.update_path.leaf_key_package.public_key), but it = should also be the case that that key was added to the group with this = Commit.  In any case, this probably calls for a new sender type.

Maybe these can both be solved with a flag passed into Commit = processing:

if = (external_commit) {
  // verify that there is = an Add corresponding to update_path.leaf_key_package
} else {
  // verify = that ExternalInitSecret is not present
}

I=E2=80= =99m thinking that the MLSPlaintext framing the External Commit will = reference a previously empty leave (namely the left most empty leave in = the tree). Normally clients would look up the leave to verify a = signature, but in this case it=E2=80=99s an indication that it is an = External Commit. Instead, clients have to parse the list of Add Proposal = the precede the Commit to determine who the signer/sender is. Lastly the = ExternalInitSecret Proposal MUST also be there.

As for the sender type, couldn=E2=80=99t we use = new_member here? Both for the Add Proposal and the Commit?


Even if so, that logic should get = specified in the commit processing section of the = spec.

I agree = that this should be written up in detailed steps to avoid any = confusion.

Raphael


--RLB


On Wed, Oct 7, 2020 at 8:57 AM Raphael = Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I = think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use = case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx>= wrote:
>> Assume for the moment that we are not going to do the above = asymmetric
>> calculation for every commit.  Then we need some extra, = optional syntax  to
>> carry `enc`, either as an optional field on Commit or as a new = Proposal,
>> which is the agreed mechanism for extending Commits.  (If = we do it every
>> time, we can just make this part of Commit.)  In the = below, I=E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a = full
> (ExternInitSecret) proposal packet only to then immediately commit = to it? That
> means a full extra frame of bandwidth, an extra signature for the = external party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit = proposal
> instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n]
> iff no kem_output field is included in the commit packet. Otherwise = it uses the
> "external_init_secret" computed as Richard described.)
= >
> ATM I can't think of a scenario where we wouldnt want the external = committer to
> also be the one creating the ExternalInitSecret proposal and = immediatly
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment = inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx>= wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external = commit, as a
>>> prelude to a PR.  This is a little bit of an essay, so = tl;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a = new ExternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit = syntax and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the = requisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the = key schedule for
>>> each epoch - The public key `pkG` of that key pair is = published along with
>>> with other group metadata - The joiner calls = SetupBaseS(pkG,
>>> some_public_group_context) to get an encapsulated key `enc` = and an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to = the group with
>>> their external commit - The members of the group call = SetupBaseS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE = context `ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, = init_secret_size)` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. = Sending the encapsulated key
>>> `enc` to the group
>>
>> =46rom the discussion at the interim, I think there is = consensus about this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit = MUST cover an
>>> Add proposal for the new member.   It does not = forbid the Commit covering
>>> *other* proposals.  It seems like it might be useful = in a couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal = for your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an = Update.
>>>
>>> Whether we do this has some impact on the syntax, as = discussed below.
>>
>> While that is not very explicit in the current PR, my approach = was the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more = members, or Commit
>> to already existing Add Proposals if those are accessible. - = Removes: The
>> joiner can remove prior appearances of itself (like you pointed = out) or
>> Commit to already existing Remove Proposals. - Updates: The = joiner should of
>> course not issue own Updates and Commit to them, but that is = already the case
>> for internal Commits. The joiner can Commit to already existing = Update
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by = the policy for
>> a group, nothing else. As a reminder: all clients MUST have the = same policy
>> for a certain group in order ta validate/refute Proposals and = Commits.
>>
>> This pretty much motivates my idea for fully re-using the = existing Commit
>> syntax and only introduce the new ExternalInitSecret = Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
= >>>
>>> Assume for the moment that we are not going to do the above = asymmetric
>>> calculation for every commit.  Then we need some = extra, optional syntax  to
>>> carry `enc`, either as an optional field on Commit or as a = new Proposal,
>>> which is the agreed mechanism for extending Commits.  = (If we do it every
>>> time, we can just make this part of Commit.)  In the = below, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } = ExternalInitSecret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now = has to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not = have to be
>> issued by the new joiner, it could very well be an external = Proposal. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The = following things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add = Proposal according to
>> the policy and references it in an internal Commit (no External = Commit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to = the public
>> group data but does not need to communicate with the group. = Nothing happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to = urgently send a
>> message to the group. The new joiner creates the = ExternalInitSecret Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.  It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.  It=E2=80=99s duplicative, = since the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily = different) KP in the
>>> Commit.  And you have potential fate-sharing issues, = since all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define = another
>>> top-level content type (parallel to Proposal and Commit) = for this purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath = path; } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it = optimizes out all of
>>> the flexibility to include other proposals.  So maybe = it=E2=80=99s worth
>>> considering an Extensible Together Option, where we can put = extra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, = since it provides
>>> simplicity and extensibility.  And to be honest, = I=E2=80=99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along = just these
>>> lines.  If we do this option, we should probably = back-port it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing = Commit syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and = this is
>> something that also occurs in other situations. For example, = when a member
>> wants to add n new members at once to the group, it needs to = compute n+1
>> signatures for that. You mention the idea of inline proposals: = Would that be
>> a proposal that doesn=E2=80=99t have a signature, but still all = other information? If
>> so, I think it would be worthwhile looking at that separately, = because as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of = information about the
>>> group in order to make a well-formed ExternalCommit.  = In earlier iterations
>>> of this style of join, we had a GroupInitKey that carried = the right
>>> information. Following that pattern here, we get something = like the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque = group_id<0..255>; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque = confirmed_transcript_hash<0..255>;
>>> Extension extensions<0..2^32-1>; } = GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used = GroupContext and
>> has the full public tree. I agree that the tree hash should be = enough and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a = GroupInfo object.  The
>>> only things it is missing are interim_transcript_hash and = signature, both
>>> of which might be useful.  So maybe all we need to do = here is say that
>>> clients can publish GroupInfo unencrypted if they want to = enable self-adds,
>>> in addition to distributing it in encrypted form in = Welcome.
>>
>> While the two are awfully similar, the signature on GroupInfo = is not required
>> here and might have undesired effects w.r.t deniability if this = is publicly
>> accessible. The other reason for not wanting the signature is = that it would
>> be an additional signature to compute with every Commit, making = them even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some = syntax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals = for External
>> Commits, same as with internal Commits - Do the HPKE-based init = secret for
>> External Commits - Introduce the ExternalInitSecret Proposal = and make it
>> mandatory for External Commits - Explore the idea of inline = proposals
>> separately - Do not re-use signed GroupInfo struct and keep the = adjusted
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing = list
>>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing = list
>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

= --Apple-Mail=_E2FD64D9-F769-4B4E-8D54-BFE0867A8D59-- From nobody Wed Oct 7 17:24:55 2020 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 CDD743A0BD7 for ; Wed, 7 Oct 2020 17:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_AnmKFZjegs for ; Wed, 7 Oct 2020 17:24:52 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39DC3A0AB5 for ; Wed, 7 Oct 2020 17:24:52 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id c62so5227265qke.1 for ; Wed, 07 Oct 2020 17:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DnXHizpvnFr8liglDlzYm5vyD0OtjPBKepXwNGcE1PE=; b=Mk0xLuHOoO7e76Ng/ojUuLlbsAXCJ4CQK22dOGtea76ecF5+QY3QDrkugwKbKhJRxv UQxwGuAdwxpC23GotaHp2hEwDcOqBRKM1105KLQzmrCeoNl3N1/I45GJW23zeqbdgdbj oNDSOJ0VCQXxbVpVp0QDuLZTrTQWHmvzmFts8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DnXHizpvnFr8liglDlzYm5vyD0OtjPBKepXwNGcE1PE=; b=hBe6NT7W9UDg/ClTW5mjfHPr/4kEVebR5NLrKokmsrG/M2bebhm9J2vjRyHi/rRJC9 mHxkNmseEkkb0olhHQMBXrv2s0PtSy0lAQe2ndFSV+P5tDFH0HIv0LwWrtRir3PVfM/B nxxOQaMknI9twwhu5sqEh/azQy1N5cueaX4rO9mwHJxVeG1UOWV0nPY+JBhn9dQ8Wwhz PwL4UUgDlYm2Zx5qErSdCwVgXCkhVirTY/K3VLYjqsKm6J8jzSv3591o+OcPHIHpyems ovJHGH1MYehEEjrPXQqjxAOhXrhLAZdFeSuAC9hxDV5S3sMTSm5uG3Uvz1bEXzLUoe/O 2Aqg== X-Gm-Message-State: AOAM5318KxYjyuxpbjD2zvAl/8dRJ6jN3qo1imPA2HVvEVY6kwgsDY0j reOYyktW6Qnm/VsjgdAbXXBDx23Z7ZFe1V3xfJfYdw== X-Google-Smtp-Source: ABdhPJxTGD13j0G6FBXbeu7fepZxliFP9UFMjK3sPbG1oErhIHlKX2cMTkMBJKxt3lD0BEbdziy323UyVjr0CExTwYI= X-Received: by 2002:a37:6d4:: with SMTP id 203mr5514981qkg.150.1602116691711; Wed, 07 Oct 2020 17:24:51 -0700 (PDT) MIME-Version: 1.0 References: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> In-Reply-To: From: Brendan McMillion Date: Wed, 7 Oct 2020 17:25:17 -0700 Message-ID: To: Richard Barnes Cc: Raphael Robert , Messaging Layer Security WG , Joel Alwen Content-Type: multipart/alternative; boundary="0000000000004c79cd05b11ddc4e" Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 00:24:55 -0000 --0000000000004c79cd05b11ddc4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Unfortunately the attack outlined above doesn't work because if an attacker has Alice's state from a previous epoch and Alice has since Updated, they're unable to encrypt MLSCiphertext or authenticate MLSPlaintext messages. The attacker could use Alice's signing private key to send an Add proposal and Commit, but they'd be marked as being from an external sender. There's no distinction between Alice being in the group already or the attacker adding Alice to groups she was never in to begin with -- this is a risk inherent with allowing external joiners, not the asymmetric Commit mechanism itself. On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes wrote: > Thanks for this analysis, Jo=C3=ABl. This aligns with my intuition as we= ll, > and seems like a good rationale for a hard prohibition on AEC / > ExternalCommit from group members. (Something about which I had waffled = in > a previous email.) > > Another way to think about this: PCS with regard to a member is about > removing an old version of that member (as represented by an HPKE key and > signing key). AEC is designed to allow joins, which means that > AEC-from-inside allows the old, compromised version of the member to > rejoin, which kills PCS. > > --Richard > > On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert 40wire.com@dmarc.ietf.org> wrote: > >> I second that assessment, my idea behind External Commits was to offer a >> mechanism where internal Commits couldn=E2=80=99t be used. External Comm= its should >> remain optional (this can easily be achieved by not providing the >> ExternalCommitInfo package to new members) and when they are used they >> should be used as a last resort mechanism (meaning there really is no wa= y >> to add a member with an internal Commit). >> >> I also think MLS should should remain in the position to cover most >> scenarios from mainstream consumer messaging to messaging in high securi= ty >> environments. External Commits make the former much more accessible but >> shouldn=E2=80=99t jeopardise the latter. >> >> Raphael >> >> > On 6 Oct 2020, at 18:38, Joel Alwen wrote: >> > >> > Hey people, >> > >> > To follow up on the discussion at the end of the Interim about whether >> to use >> > the new "asymmetric external commit" (AEC) mechanism for internal >> commits I >> > wanted to summarize my thoughts here. For brevity let SIC be our curre= nt >> > "symmetric internal commit" mechanism. >> > >> > - AEC requires extra asymmetric crypto operations (both for committer >> and >> > receiver) compared to SIC which I think we should avoid if we can, eve= n >> at the >> > cost of some code complexity. >> > >> > - AEC doesn't ensure the committer knows the old epoch's key schedule. >> This can >> > play a deciding role in several types of attacks. >> > >> > Consider this execution: >> > >> > 1. Alice is in a group. Her state leaks (including her signining key). >> > 2. Alice commits (to arbitrary propal). >> > >> > At this point, the adversary can still forge a new AEC from Alice but >> not an SIC. >> > >> > Worse, step 2 could have instead been "Alice sends an update proposal >> replacing >> > her leaf HPKE but keeping the her sig keys (e.g. because new >> credentials are >> > costly to come by). Someone commits to the new proposal." At this poin= t >> I'd >> > expect PCS to have kicked in for Alice (as it does when using SIC). Bu= t >> not for >> > AECs since Alice's signing key is all thats needed to forge a new AEC. >> > >> > I think it is not worth weakening security this way if we dont have to= . >> > (Especially, since in some deployments external commits may not be a >> supported >> > feature at all.) >> > >> > - As for what may or may not be displaid to users, that's really up to >> the >> > implementation. IMO our goal should be to make the protocol as secure >> as we can >> > subject to reasonable costs. Which aspects of the resulting security >> properties >> > are ultimately communicated to users should, in principle, be left up = to >> > implementations. That means we shouldn't be designing away security >> features >> > only because we think they might be hard to communicate. (Nor does it >> seem that >> > inconceivable to me that some implementation may end up explicitly >> signaling >> > whether a commit was external vs internal.) >> > >> > - Jo=C3=ABl >> > >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000004c79cd05b11ddc4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately the attack outlined above doesn't work b= ecause if an attacker has Alice's state from a previous epoch and Alice= has since Updated, they're unable to encrypt MLSCiphertext or authenti= cate MLSPlaintext messages. The attacker could use Alice's signing priv= ate key to send an Add proposal and Commit, but they'd be marked as bei= ng from an external sender. There's no distinction between Alice being = in the group already or the attacker adding Alice to groups she was never i= n to begin with -- this is a risk inherent with allowing external joiners, = not the asymmetric Commit mechanism itself.

On Wed, Oct 7, 2020 at 8:49 = AM Richard Barnes <rlb@ipv.sx> wrot= e:
Thanks for this analysis, Jo=C3=ABl.=C2=A0 This aligns with my int= uition as well, and seems like a good rationale for a hard prohibition on A= EC / ExternalCommit from group members.=C2=A0 (Something about which I had = waffled in a previous email.)

Another way to think= about this: PCS with regard to a member is about removing an old version o= f that member (as represented by an HPKE key and signing key).=C2=A0 AEC is= designed to allow joins, which means that AEC-from-inside allows the old, = compromised version of the member to rejoin, which kills PCS.

--Richard

On Tue, Oct 6, 2020 at 12:55 PM Raphael = Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I second that assessment, my idea behind = External Commits was to offer a mechanism where internal Commits couldn=E2= =80=99t be used. External Commits should remain optional (this can easily b= e achieved by not providing the ExternalCommitInfo package to new members) = and when they are used they should be used as a last resort mechanism (mean= ing there really is no way to add a member with an internal Commit).

I also think MLS should should remain in the position to cover most scenari= os from mainstream consumer messaging to messaging in high security environ= ments. External Commits make the former much more accessible but shouldn=E2= =80=99t jeopardise the latter.

Raphael

> On 6 Oct 2020, at 18:38, Joel Alwen <jalwen@wickr.com> wrote:
>
> Hey people,
>
> To follow up on the discussion at the end of the Interim about whether= to use
> the new "asymmetric external commit" (AEC) mechanism for int= ernal commits I
> wanted to summarize my thoughts here. For brevity let SIC be our curre= nt
> "symmetric internal commit" mechanism.
>
> - AEC requires extra asymmetric crypto operations (both for committer = and
> receiver) compared to SIC which I think we should avoid if we can, eve= n at the
> cost of some code complexity.
>
> - AEC doesn't ensure the committer knows the old epoch's key s= chedule. This can
> play a deciding role in several types of attacks.
>
> Consider this execution:
>
> 1. Alice is in a group. Her state leaks (including her signining key).=
> 2. Alice commits (to arbitrary propal).
>
> At this point, the adversary can still forge a new AEC from Alice but = not an SIC.
>
> Worse, step 2 could have instead been "Alice sends an update prop= osal replacing
> her leaf HPKE but keeping the her sig keys (e.g. because new credentia= ls are
> costly to come by). Someone commits to the new proposal." At this= point I'd
> expect PCS to have kicked in for Alice (as it does when using SIC). Bu= t not for
> AECs since Alice's signing key is all thats needed to forge a new = AEC.
>
> I think it is not worth weakening security this way if we dont have to= .
> (Especially, since in some deployments external commits may not be a s= upported
> feature at all.)
>
> - As for what may or may not be displaid to users, that's really u= p to the
> implementation. IMO our goal should be to make the protocol as secure = as we can
> subject to reasonable costs. Which aspects of the resulting security p= roperties
> are ultimately communicated to users should, in principle, be left up = to
> implementations. That means we shouldn't be designing away securit= y features
> only because we think they might be hard to communicate. (Nor does it = seem that
> inconceivable to me that some implementation may end up explicitly sig= naling
> whether a commit was external vs internal.)
>
> - Jo=C3=ABl
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000004c79cd05b11ddc4e-- From nobody Wed Oct 7 17:45:27 2020 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 1B1AB3A00C9 for ; Wed, 7 Oct 2020 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAv4E4Bkkuro for ; Wed, 7 Oct 2020 17:45:22 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 F31983A0061 for ; Wed, 7 Oct 2020 17:45:21 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id c5so3730459qtw.3 for ; Wed, 07 Oct 2020 17:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fdq2GuYh24l+t+AhOCmmaDK1wsjQWvmLiJivF8fdw7M=; b=wNSgqpsPJmw4jvw3JUlk9fHQ/EPsuENwBGSRC+dcLnXIxURhDKE3vU40pgIDZBCv+9 +i64/HyM1IYet3QncvOggFBkYT8H+2UATQtuJlRBRUgTTrGfgPWqyNFGRDCNvP/GU5ce VlPvoL55vqBTwYfc0YRZkt7cbxOmKyOeJNXlo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fdq2GuYh24l+t+AhOCmmaDK1wsjQWvmLiJivF8fdw7M=; b=gK/asxJpTqCE0Gpb3H7Bwwq0+GbZziKcLDVP3pyUj33CqOoyvGHXcrg0mBJ+1Qe81/ 2eLydOCNTYgoRQWlQpJD0Q3H3rzuxpOdzuKDylGm3DAjf1aSuyDP/1Etw2B7/XAjnG18 VHuJYYxzy8GEkdKZtt97ZnT208QJFx9S/Yzxn9Gl7dC6VhbrlsGVrd5xisbko7OCVrGa zfEj/4LxEK7NK3GWzQFw5zMcdT4bSwGnRfaKO0iTJZkdezJYHxXSkHfIYLExeDS9FDgd 3gumrIPaq5NvSweXZhzVI1AYc4DpvtAepAMCBjPcAwg+xSjOrdKCdIe/Xd2NxAUBgyVk oW3A== X-Gm-Message-State: AOAM533bJaYbmKpBBOcSWCyFHpHuPSaSybNWaLL3KkfQqb6FG28bDl9T 7Pl3u+GBnS+M1qxCXgq+hsF/4q8iYClJAd3CUgaMgcsCC1A= X-Google-Smtp-Source: ABdhPJy6wNPQEyHjoxRdnmJcCvoE665hr6FI3JrhSVLnnVKLIjX3RnWBLfKMnDCvsav8FBPEZzIl81rqNPS2rgF3aBg= X-Received: by 2002:ac8:7cba:: with SMTP id z26mr4261143qtv.7.1602117920734; Wed, 07 Oct 2020 17:45:20 -0700 (PDT) MIME-Version: 1.0 References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> In-Reply-To: <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> From: Brendan McMillion Date: Wed, 7 Oct 2020 17:45:48 -0700 Message-ID: To: Raphael Robert Cc: Richard Barnes , Messaging Layer Security WG , Joel Alwen Content-Type: multipart/alternative; boundary="0000000000008de48605b11e25a2" Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 00:45:26 -0000 --0000000000008de48605b11e25a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I know you're all tired of hearing me say this, but I still feel strongly we should always use asymmetric Commits. If MLS is otherwise secure, then there's simply no reason not to, and it simplifies implementations. There wouldn't have to be a new ExternalInitSecret proposal, validation logic wouldn't get substantially more complicated, and there wouldn't be this worry about bundling several proposals. Otoh, I think allowing inline proposals in Commits is a good idea but it's orthogonal to asymmetric Commits. On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert wrote: > Good points again! > > On 7 Oct 2020, at 17:38, Richard Barnes wrote: > > OK, how about the following proposal (heh): > > - Add ExternalInitSecret proposal > - Add an "inline proposals" field to Commit that lets the committer send > proposals with a commit > > Two remaining worries here: > > - Validation: You want it to be the case that an ExternalInitSecret is > only present for a Commit signed by a new joiner. So some that informati= on > will have to be passed from MLSPlaintext validation to Commit processing. > Or maybe we don't care about that restriction? It seems like a member > sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's > not bad enough to absolutely forbid / have hard checks against. > > > Good question. I guess you want to detect early on if it is an External > Commit or an internal one, perhaps also to block External Commits by > policy. Indeed only the signature and sender type would reveal that. > Should internal Commits be allowed to have a ExternalInitSecret proposal > that then just gets ignored? I don=E2=80=99t have strong feelings about i= t, but I=E2=80=99m > leaning towards the safe approach of saying it MUST not. > > > - Complexity: MLSPlaintext signature validation has to find a key to > verify the signature. I guess in this case, it should take the one for t= he > Committer (Commit.update_path.leaf_key_package.public_key), but it should > also be the case that that key was added to the group with this Commit. = In > any case, this probably calls for a new sender type. > > Maybe these can both be solved with a flag passed into Commit processing: > > if (external_commit) { > // verify that there is an Add corresponding to > update_path.leaf_key_package > } else { > // verify that ExternalInitSecret is not present > } > > > I=E2=80=99m thinking that the MLSPlaintext framing the External Commit wi= ll > reference a previously empty leave (namely the left most empty leave in t= he > tree). Normally clients would look up the leave to verify a signature, bu= t > in this case it=E2=80=99s an indication that it is an External Commit. In= stead, > clients have to parse the list of Add Proposal the precede the Commit to > determine who the signer/sender is. Lastly the ExternalInitSecret Proposa= l > MUST also be there. > > As for the sender type, couldn=E2=80=99t we use new_member here? Both for= the Add > Proposal and the Commit? > > > Even if so, that logic should get specified in the commit processing > section of the spec. > > > I agree that this should be written up in detailed steps to avoid any > confusion. > > Raphael > > > --RLB > > > On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert 40wire.com@dmarc.ietf.org> wrote: > >> I think that=E2=80=99s exactly the motivation we need for inline proposa= ls, this >> surplus of signatures is not specific to this use case! >> >> Raphael >> >> > On 7 Oct 2020, at 13:27, Joel Alwen wrote: >> > >> > On 7 Oct 2020, at 03:20, Richard Barnes wrote: >> >> Assume for the moment that we are not going to do the above asymmetri= c >> >> calculation for every commit. Then we need some extra, optional >> syntax to >> >> carry `enc`, either as an optional field on Commit or as a new >> Proposal, >> >> which is the agreed mechanism for extending Commits. (If we do it >> every >> >> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >> assume a >> >> new Proposal, say ExternalInitSecret. >> > Isn't it a bit redundant to have the External party prepare a full >> > (ExternInitSecret) proposal packet only to then immediately commit to >> it? That >> > means a full extra frame of bandwidth, an extra signature for the >> external party >> > and an extra sig verification for group members. >> > >> > I'm wondering what the motivation is for making this an explicit >> proposal >> > instead of, say, a second mode for commits. (E.g. a commit uses >> init_secret[n] >> > iff no kem_output field is included in the commit packet. Otherwise it >> uses the >> > "external_init_secret" computed as Richard described.) >> > >> > ATM I can't think of a scenario where we wouldnt want the external >> committer to >> > also be the one creating the ExternalInitSecret proposal and immediatl= y >> > committing to it... >> > >> > - Jo=C3=ABl >> > >> > >> > On 07/10/2020 12:36, Raphael Robert wrote: >> >> Thanks Richard for looking at all aspects in detail! >> >> >> >> I thought about these things as well and will comment inline: >> >> >> >>> On 7 Oct 2020, at 03:20, Richard Barnes wrote: >> >>> >> >>> Hey all, >> >>> >> >>> I wanted to send some thoughts on how to implement external commit, >> as a >> >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the >> proposal >> >>> is: >> >>> >> >>> - Rather than re-using Proposal/Commit, we should make a new >> ExternalCommit >> >>> message, parallel to Proposal/Commit >> >> >> >> I think we are better off with re-using the current Commit syntax and >> I=E2=80=99ll >> >> explain why further below. >> >> >> >>> - We should also define a syntax for telling the joiner the requisit= e >> >>> information about the group >> >>> >> >>> # HPKE-based init secret >> >>> >> >>> The concept here is as follows: >> >>> >> >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key >> schedule for >> >>> each epoch - The public key `pkG` of that key pair is published alon= g >> with >> >>> with other group metadata - The joiner calls SetupBaseS(pkG, >> >>> some_public_group_context) to get an encapsulated key `enc` and an >> HPKE >> >>> context `ctx` - The joiner sends the encapsulated key to the group >> with >> >>> their external commit - The members of the group call SetupBaseS(enc= , >> skG, >> >>> some_public_group_context) to get an equivalent HPKE context `ctx` - >> >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to >> derive >> >>> the init secret >> >>> >> >>> So there are two syntactic requirements: >> >>> >> >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the >> encapsulated key >> >>> `enc` to the group >> >> >> >> From the discussion at the interim, I think there is consensus about >> this >> >> part, we just need to add that to the PR. >> >> >> >>> >> >>> >> >>> # What Proposals? >> >>> >> >>> The current PR correctly requires that the external Commit MUST cove= r >> an >> >>> Add proposal for the new member. It does not forbid the Commit >> covering >> >>> *other* proposals. It seems like it might be useful in a couple of >> cases >> >>> to keep that option open: >> >> * Including PSK proposals for additional >> >>> authentication when joining * Including a Remove proposal for your >> prior >> >>> appearance when re-joining >> >>> >> >>> The only current proposal that would be nonsensical is an Update. >> >>> >> >>> Whether we do this has some impact on the syntax, as discussed below= . >> >> >> >> While that is not very explicit in the current PR, my approach was th= e >> >> following: >> >> >> >> All Proposals should be allowed in an external Commit: >> >> >> >> - Adds: The joiner (new member) could right away add more members, or >> Commit >> >> to already existing Add Proposals if those are accessible. - Removes: >> The >> >> joiner can remove prior appearances of itself (like you pointed out) = or >> >> Commit to already existing Remove Proposals. - Updates: The joiner >> should of >> >> course not issue own Updates and Commit to them, but that is already >> the case >> >> for internal Commits. The joiner can Commit to already existing Updat= e >> >> Proposals from other members. >> >> >> >> Whether all of the above is allowed should only be governed by the >> policy for >> >> a group, nothing else. As a reminder: all clients MUST have the same >> policy >> >> for a certain group in order ta validate/refute Proposals and Commits= . >> >> >> >> This pretty much motivates my idea for fully re-using the existing >> Commit >> >> syntax and only introduce the new ExternalInitSecret Proposal. >> >> >> >>> >> >>> >> >>> # External commit syntax: Separate or Together >> >>> >> >>> Assume for the moment that we are not going to do the above asymmetr= ic >> >>> calculation for every commit. Then we need some extra, optional >> syntax to >> >>> carry `enc`, either as an optional field on Commit or as a new >> Proposal, >> >>> which is the agreed mechanism for extending Commits. (If we do it >> every >> >>> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >> assume a >> >>> new Proposal, say ExternalInitSecret. >> >>> >> >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >> >> >> >> This is exactly the Proposal we need. >> >> >> >>> >> >>> Given the requirement for an Add proposal, the joiner now has to sen= d >> a >> >>> =E2=80=9Cflight of messages=E2=80=9D: >> >>> >> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >> >> >> >> I see some more nuance here. The first Add Proposal does not have to = be >> >> issued by the new joiner, it could very well be an external Proposal. >> The >> >> scenario I had in mind here is the following: >> >> >> >> A server issues an external Add Proposal for a group. The following >> things >> >> can happen: >> >> >> >> a) Ideal scenario: >> >> >> >> - A member of the group comes online, validates the Add Proposal >> according to >> >> the policy and references it in an internal Commit (no External Commi= t >> >> needed) and sends a Welcome message to the new member >> >> >> >> b) Equally ideal scenario: >> >> >> >> - The new joiner comes online before anyone else, has access to the >> public >> >> group data but does not need to communicate with the group. Nothing >> happens. >> >> >> >> c) Emergency scenario: >> >> >> >> - The new joiner comes online before anyone else and needs to urgentl= y >> send a >> >> message to the group. The new joiner creates the ExternalInitSecret >> Proposal >> >> and the Commit and sends both to group. >> >> >> >>> >> >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit hea= vyweight, since >> each of >> >>> these is signed separately. It=E2=80=99s duplicative, since the Key= Package >> in the >> >>> Add is immediately overwritten by the (necessarily different) KP in >> the >> >>> Commit. And you have potential fate-sharing issues, since all three >> need >> >>> to succeed or fail. >> >>> >> >>> You could also envision a Together Option, where we define another >> >>> top-level content type (parallel to Proposal and Commit) for this >> purpose: >> >>> >> >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } >> ExternalCommit; >> >>> >> >>> That would avoid all of the challenges above, but it optimizes out >> all of >> >>> the flexibility to include other proposals. So maybe it=E2=80=99s w= orth >> >>> considering an Extensible Together Option, where we can put extra >> proposals >> >>> into an ExternalCommit >> >>> >> >>> struct { Proposal proposals<0..2^32-1>; opaque kem_output<0..2^16-1>= ; >> >>> UpdatePath path; } ExternalCommit; >> >>> >> >>> Personally, I kind of like the Flexible Together Option, since it >> provides >> >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been w= ondering >> if we >> >>> should allow inline proposals in Commit for a while, along just thes= e >> >>> lines. If we do this option, we should probably back-port it to >> Commit as >> >>> well. >> >>> >> >> >> >> As mentioned above, I=E2=80=99m all for re-using the existing Commit = syntax >> because >> >> of clarity, simplicity and flexibility. >> >> >> >> I do agree that the amount of signatures is sub-optimal, and this is >> >> something that also occurs in other situations. For example, when a >> member >> >> wants to add n new members at once to the group, it needs to compute >> n+1 >> >> signatures for that. You mention the idea of inline proposals: Would >> that be >> >> a proposal that doesn=E2=80=99t have a signature, but still all other >> information? If >> >> so, I think it would be worthwhile looking at that separately, becaus= e >> as you >> >> say, it could be back-ported to internal Commits as well. I=E2=80=99m= all for >> >> exploring that idea further. >> >> >> >>> >> >>> # Syntax for what the Joiner Needs >> >>> >> >>> The PR notes that the joiner needs to know a bunch of information >> about the >> >>> group in order to make a well-formed ExternalCommit. In earlier >> iterations >> >>> of this style of join, we had a GroupInitKey that carried the right >> >>> information. Following that pattern here, we get something like the >> >>> following: >> >>> >> >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 >> epoch; >> >>> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>; >> >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >> >> >> >> This is what the PR currently says, except that the PR used >> GroupContext and >> >> has the full public tree. I agree that the tree hash should be enough >> and >> >> I=E2=80=99ll change the PR accordingly. >> >> >> >>> >> >>> Note that this object is essentially the same as a GroupInfo object. >> The >> >>> only things it is missing are interim_transcript_hash and signature, >> both >> >>> of which might be useful. So maybe all we need to do here is say th= at >> >>> clients can publish GroupInfo unencrypted if they want to enable >> self-adds, >> >>> in addition to distributing it in encrypted form in Welcome. >> >> >> >> While the two are awfully similar, the signature on GroupInfo is not >> required >> >> here and might have undesired effects w.r.t deniability if this is >> publicly >> >> accessible. The other reason for not wanting the signature is that it >> would >> >> be an additional signature to compute with every Commit, making them >> even >> >> more expensive. I propose to keep the struct as-is. >> >> >> >>> >> >>> In any case, it seems like it would be useful to have some syntax fo= r >> >>> this. >> >>> >> >>> Hope this helps, =E2=80=94RLB >> >> >> >> >> >> TL;DR: >> >> >> >> I propose the following: >> >> >> >> - Keep the current Commit syntax - Allow all kinds of Proposals for >> External >> >> Commits, same as with internal Commits - Do the HPKE-based init secre= t >> for >> >> External Commits - Introduce the ExternalInitSecret Proposal and make >> it >> >> mandatory for External Commits - Explore the idea of inline proposals >> >> separately - Do not re-use signed GroupInfo struct and keep the >> adjusted >> >> ExternalCommitInfo instead >> >> >> >> Raphael >> >> >> >>> _______________________________________________ MLS mailing list >> >>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >> >> >> >> _______________________________________________ MLS mailing list >> >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >> >> >> > >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> 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 > --0000000000008de48605b11e25a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know you're all tired of hearing me say this, but I = still feel strongly we should always use asymmetric Commits. If MLS is othe= rwise secure, then there's simply no reason not to, and it simplifies i= mplementations. There wouldn't have to be a new ExternalInitSecret prop= osal, validation logic wouldn't get substantially more complicated, and= there wouldn't be this worry about bundling several proposals. Otoh, I= think allowing inline proposals in Commits is a good idea but it's ort= hogonal to asymmetric Commits.

On Wed, Oct 7, 2020 at 1:24 PM Raphael Ro= bert <raphael=3D40wire.com@= dmarc.ietf.org> wrote:
Good points again!<= br>

On 7 Oct 2020, at 17:38, Richard= Barnes <rlb@ipv.sx&= gt; wrote:

OK, how about the following = proposal (heh):

- Add ExternalInitSecret proposal<= /div>
- Add an "inline proposals" field to Commit that lets t= he committer send proposals with a commit

Two rema= ining worries here:

- Validation: You want it= to be the case that an ExternalInitSecret is only present for a Commit sig= ned by a new joiner.=C2=A0 So some that information will have to be passed = from MLSPlaintext validation to Commit processing.=C2=A0 Or maybe we don= 9;t care about that restriction?=C2=A0 It seems like a member sending Exter= nalInitSecret should at least be SHOULD NOT, but maybe it's not bad eno= ugh to absolutely forbid / have hard checks against.
<= /blockquote>

Good question. I guess you want to detect early = on if it is an External Commit or an internal one, perhaps also to block Ex= ternal Commits by policy. Indeed only the signature and sender type would r= eveal that.=C2=A0
Should internal Commits be allowed to have a Ex= ternalInitSecret proposal that then just gets ignored? I don=E2=80=99t have= strong feelings about it, but I=E2=80=99m leaning towards the safe approac= h of saying it MUST not.


- Complexity: MLSPlaintext signature valida= tion has to find a key to verify the signature.=C2=A0 I guess in this case,= it should take the one for the Committer (Commit.update_path.leaf_key_pack= age.public_key), but it should also be the case that that key was added to = the group with this Commit.=C2=A0 In any case, this probably calls for a ne= w sender type.

Maybe these can both be solved = with a flag passed into Commit processing:

if (ext= ernal_commit) {
=C2=A0 // verify that there is an Add correspondi= ng to update_path.leaf_key_package
} else {
=C2=A0 = // verify that ExternalInitSecret is not present
}

I=E2=80=99m thinking that the MLSPlainte= xt framing the External Commit will reference a previously empty leave (nam= ely the left most empty leave in the tree). Normally clients would look up = the leave to verify a signature, but in this case it=E2=80=99s an indicatio= n that it is an External Commit. Instead, clients have to parse the list of= Add Proposal the precede the Commit to determine who the signer/sender is.= Lastly the ExternalInitSecret Proposal MUST also be there.

<= /div>
As for the sender type, couldn=E2=80=99t we use new_member here? = Both for the Add Proposal and the Commit?


Even if so, tha= t logic should get specified in the commit processing section of the spec.<= /div>

I agree that this should be wr= itten up in detailed steps to avoid any confusion.

Raphael


--RLB


On Wed, Oct 7, 2020 at 8:57 A= M Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I think that=E2=80=99s exactly = the motivation we need for inline proposals, this surplus of signatures is = not specific to this use case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>> Assume for the moment that we are not going to do the above asymme= tric
>> calculation for every commit.=C2=A0 Then we need some extra, optio= nal syntax=C2=A0 to
>> carry `enc`, either as an optional field on Commit or as a new Pro= posal,
>> which is the agreed mechanism for extending Commits.=C2=A0 (If we = do it every
>> time, we can just make this part of Commit.)=C2=A0 In the below, I= =E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a full=
> (ExternInitSecret) proposal packet only to then immediately commit to = it? That
> means a full extra frame of bandwidth, an extra signature for the exte= rnal party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit p= roposal
> instead of, say, a second mode for commits. (E.g. a commit uses init_s= ecret[n]
> iff no kem_output field is included in the commit packet. Otherwise it= uses the
> "external_init_secret" computed as Richard described.)
>
> ATM I can't think of a scenario where we wouldnt want the external= committer to
> also be the one creating the ExternalInitSecret proposal and immediatl= y
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external co= mmit, as a
>>> prelude to a PR.=C2=A0 This is a little bit of an essay, so tl= ;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a new E= xternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the re= quisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for
>>> each epoch - The public key `pkG` of that key pair is publishe= d along with
>>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> some_public_group_context) to get an encapsulated key `enc` an= d an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to the g= roup with
>>> their external commit - The members of the group call SetupBas= eS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE context `= ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)= ` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending = the encapsulated key
>>> `enc` to the group
>>
>> From the discussion at the interim, I think there is consensus abo= ut this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit MUS= T cover an
>>> Add proposal for the new member.=C2=A0 =C2=A0It does not forbi= d the Commit covering
>>> *other* proposals.=C2=A0 It seems like it might be useful in a= couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal for = your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an Upda= te.
>>>
>>> Whether we do this has some impact on the syntax, as discussed= below.
>>
>> While that is not very explicit in the current PR, my approach was= the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more members,= or Commit
>> to already existing Add Proposals if those are accessible. - Remov= es: The
>> joiner can remove prior appearances of itself (like you pointed ou= t) or
>> Commit to already existing Remove Proposals. - Updates: The joiner= should of
>> course not issue own Updates and Commit to them, but that is alrea= dy the case
>> for internal Commits. The joiner can Commit to already existing Up= date
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by the= policy for
>> a group, nothing else. As a reminder: all clients MUST have the sa= me policy
>> for a certain group in order ta validate/refute Proposals and Comm= its.
>>
>> This pretty much motivates my idea for fully re-using the existing= Commit
>> syntax and only introduce the new ExternalInitSecret Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
>>>
>>> Assume for the moment that we are not going to do the above as= ymmetric
>>> calculation for every commit.=C2=A0 Then we need some extra, o= ptional syntax=C2=A0 to
>>> carry `enc`, either as an optional field on Commit or as a new= Proposal,
>>> which is the agreed mechanism for extending Commits.=C2=A0 (If= we do it every
>>> time, we can just make this part of Commit.)=C2=A0 In the belo= w, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSec= ret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now has = to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not have = to be
>> issued by the new joiner, it could very well be an external Propos= al. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The followin= g things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add Proposal a= ccording to
>> the policy and references it in an internal Commit (no External Co= mmit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to th= e public
>> group data but does not need to communicate with the group. Nothin= g happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to urge= ntly send a
>> message to the group. The new joiner creates the ExternalInitSecre= t Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.=C2=A0 It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.=C2=A0 It=E2=80=99s duplicative, si= nce the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily different) = KP in the
>>> Commit.=C2=A0 And you have potential fate-sharing issues, sinc= e all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define ano= ther
>>> top-level content type (parallel to Proposal and Commit) for t= his purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; = } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it optimizes= out all of
>>> the flexibility to include other proposals.=C2=A0 So maybe it= =E2=80=99s worth
>>> considering an Extensible Together Option, where we can put ex= tra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque kem_outpu= t<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, since= it provides
>>> simplicity and extensibility.=C2=A0 And to be honest, I=E2=80= =99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along jus= t these
>>> lines.=C2=A0 If we do this option, we should probably back-por= t it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing Comm= it syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and this = is
>> something that also occurs in other situations. For example, when = a member
>> wants to add n new members at once to the group, it needs to compu= te n+1
>> signatures for that. You mention the idea of inline proposals: Wou= ld that be
>> a proposal that doesn=E2=80=99t have a signature, but still all ot= her information? If
>> so, I think it would be worthwhile looking at that separately, bec= ause as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of informat= ion about the
>>> group in order to make a well-formed ExternalCommit.=C2=A0 In = earlier iterations
>>> of this style of join, we had a GroupInitKey that carried the = right
>>> information. Following that pattern here, we get something lik= e the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque group_id<0..255&g= t;; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque confirmed_transcript_ha= sh<0..255>;
>>> Extension extensions<0..2^32-1>; } GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used GroupC= ontext and
>> has the full public tree. I agree that the tree hash should be eno= ugh and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a GroupInfo o= bject.=C2=A0 The
>>> only things it is missing are interim_transcript_hash and sign= ature, both
>>> of which might be useful.=C2=A0 So maybe all we need to do her= e is say that
>>> clients can publish GroupInfo unencrypted if they want to enab= le self-adds,
>>> in addition to distributing it in encrypted form in Welcome. >>
>> While the two are awfully similar, the signature on GroupInfo is n= ot required
>> here and might have undesired effects w.r.t deniability if this is= publicly
>> accessible. The other reason for not wanting the signature is that= it would
>> be an additional signature to compute with every Commit, making th= em even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some syn= tax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals fo= r External
>> Commits, same as with internal Commits - Do the HPKE-based init se= cret for
>> External Commits - Introduce the ExternalInitSecret Proposal and m= ake it
>> mandatory for External Commits - Explore the idea of inline propos= als
>> separately - Do not re-use signed GroupInfo struct and keep the ad= justed
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing li= st
>>> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing list <= br> >> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

________________________________________= _______
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000008de48605b11e25a2-- From nobody Thu Oct 8 08:47:41 2020 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 43C4E3A0A04 for ; Thu, 8 Oct 2020 08:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di-ACJ8K-aNj for ; Thu, 8 Oct 2020 08:47:36 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3312B3A08C7 for ; Thu, 8 Oct 2020 08:47:35 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id z6so7517478qkz.4 for ; Thu, 08 Oct 2020 08:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8IkKMBGdFt642oojtdCHt3XOtxENpyF0HE8BZP2n0B0=; b=j4iaP+oBua89hPElWvnSV2isamEokoUnM0yav6aeK6zisGlqAJ2oUnoS2ZpOPisTTZ Z2OEAeKC00r/7xqox4WXwxc8e0bFm1EW/HhmsHqiY3whFqS7iQt0U9pvwxeLGEGB3CSq W5plZ8wMIh9qgE1/A1Hw2nrix8YQg6oZFqAW4f8WOjxl5gse48/ZofinbbkAfhf/N8g4 UXrDYNGXv3ckaBzWrgBqoYpl6YY0kLgBD29mUvlIJV0Nt+7pwcJ6mJWgb4hnCwvvgf5C WQxwnHc80VOgUqq5e+XOT+rffeaUEO1JpnQlAkw2HusUL0nMBUEqMdEf+Gx7QkwAKFP9 +Q8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8IkKMBGdFt642oojtdCHt3XOtxENpyF0HE8BZP2n0B0=; b=HynKeih/7YIQub4kIbr3M1afIXfJIjuIq5Y3GWTlAUhk/TY+1XkZ94FCcrOfYnouYR ZqXVvylEW8wQf/FUBKdl3lwcjuoQrijrleUl6eZqCh8q4PrciUaa6pln4cEdeXZoQl0z 25aA/2Rc1L/BtfoWxTMAniBdJgwt0LHxN4z/zMTRDO+/EtwsUYWxp/YpnejLxme9fks3 2xsOOkIWCniZ+iI/HHRrR32I0QhILxpgWC/5iNxRUioNNUGAvcVGIE6PQgjNOMExF9IM dI4Rt3YGI0wRUMVxVoXCu1hT3zz/waaGrpMNCMfmgHytOQYjk2+Y8GoGikKJca7k/jVe 1v5A== X-Gm-Message-State: AOAM53265BWxDHWPvI1TSVsKxOjHbrv5wJd3gsrTuz3EyjIeZfa93xMD 0xNm7zNtguBODhMl/+reVa7h5I5PaaYdXgX01hVMwB0ZfufB/Q== X-Google-Smtp-Source: ABdhPJxol/7oE5mkCHOXya+R9PVDHucSLZkSjINyaVpC8lmhyas+zjhYjQVfSp3ltGOZkrkcGKV7aBIy0aXSFjT15+Q= X-Received: by 2002:a05:620a:15b6:: with SMTP id f22mr1537391qkk.490.1602172054445; Thu, 08 Oct 2020 08:47:34 -0700 (PDT) MIME-Version: 1.0 References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> In-Reply-To: From: Richard Barnes Date: Thu, 8 Oct 2020 11:47:21 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000002cb23a05b12ac0e0" Archived-At: Subject: [MLS] Inline proposals X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 15:47:39 -0000 --0000000000002cb23a05b12ac0e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Changing subject line because changing subject) Since there seems to be some energy around inline proposals regardless of ExternalCommit, I made a quick PR: https://github.com/mlswg/mls-protocol/pull/414 The interesting nuance here is that the Commit specifies an order in which Proposals are applied. So there are basically two design options here: 1. Include proposals by value, and reference them by hash in the order specification 2. Allow the order specification to reference proposals by value or by hash I went with the latter approach, because it seemed slightly simpler to me. But if folks feel strongly, we could go the other way as well. --Richard On Wed, Oct 7, 2020 at 8:45 PM Brendan McMillion wrote: > I know you're all tired of hearing me say this, but I still feel strongly > we should always use asymmetric Commits. If MLS is otherwise secure, then > there's simply no reason not to, and it simplifies implementations. There > wouldn't have to be a new ExternalInitSecret proposal, validation logic > wouldn't get substantially more complicated, and there wouldn't be this > worry about bundling several proposals. Otoh, I think allowing inline > proposals in Commits is a good idea but it's orthogonal to asymmetric > Commits. > > On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert 40wire.com@dmarc.ietf.org> wrote: > >> Good points again! >> >> On 7 Oct 2020, at 17:38, Richard Barnes wrote: >> >> OK, how about the following proposal (heh): >> >> - Add ExternalInitSecret proposal >> - Add an "inline proposals" field to Commit that lets the committer send >> proposals with a commit >> >> Two remaining worries here: >> >> - Validation: You want it to be the case that an ExternalInitSecret is >> only present for a Commit signed by a new joiner. So some that informat= ion >> will have to be passed from MLSPlaintext validation to Commit processing= . >> Or maybe we don't care about that restriction? It seems like a member >> sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's >> not bad enough to absolutely forbid / have hard checks against. >> >> >> Good question. I guess you want to detect early on if it is an External >> Commit or an internal one, perhaps also to block External Commits by >> policy. Indeed only the signature and sender type would reveal that. >> Should internal Commits be allowed to have a ExternalInitSecret proposal >> that then just gets ignored? I don=E2=80=99t have strong feelings about = it, but I=E2=80=99m >> leaning towards the safe approach of saying it MUST not. >> >> >> - Complexity: MLSPlaintext signature validation has to find a key to >> verify the signature. I guess in this case, it should take the one for = the >> Committer (Commit.update_path.leaf_key_package.public_key), but it shoul= d >> also be the case that that key was added to the group with this Commit. = In >> any case, this probably calls for a new sender type. >> >> Maybe these can both be solved with a flag passed into Commit processing= : >> >> if (external_commit) { >> // verify that there is an Add corresponding to >> update_path.leaf_key_package >> } else { >> // verify that ExternalInitSecret is not present >> } >> >> >> I=E2=80=99m thinking that the MLSPlaintext framing the External Commit w= ill >> reference a previously empty leave (namely the left most empty leave in = the >> tree). Normally clients would look up the leave to verify a signature, b= ut >> in this case it=E2=80=99s an indication that it is an External Commit. I= nstead, >> clients have to parse the list of Add Proposal the precede the Commit to >> determine who the signer/sender is. Lastly the ExternalInitSecret Propos= al >> MUST also be there. >> >> As for the sender type, couldn=E2=80=99t we use new_member here? Both fo= r the Add >> Proposal and the Commit? >> >> >> Even if so, that logic should get specified in the commit processing >> section of the spec. >> >> >> I agree that this should be written up in detailed steps to avoid any >> confusion. >> >> Raphael >> >> >> --RLB >> >> >> On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert > 40wire.com@dmarc.ietf.org> wrote: >> >>> I think that=E2=80=99s exactly the motivation we need for inline propos= als, this >>> surplus of signatures is not specific to this use case! >>> >>> Raphael >>> >>> > On 7 Oct 2020, at 13:27, Joel Alwen wrote: >>> > >>> > On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>> >> Assume for the moment that we are not going to do the above asymmetr= ic >>> >> calculation for every commit. Then we need some extra, optional >>> syntax to >>> >> carry `enc`, either as an optional field on Commit or as a new >>> Proposal, >>> >> which is the agreed mechanism for extending Commits. (If we do it >>> every >>> >> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >>> assume a >>> >> new Proposal, say ExternalInitSecret. >>> > Isn't it a bit redundant to have the External party prepare a full >>> > (ExternInitSecret) proposal packet only to then immediately commit to >>> it? That >>> > means a full extra frame of bandwidth, an extra signature for the >>> external party >>> > and an extra sig verification for group members. >>> > >>> > I'm wondering what the motivation is for making this an explicit >>> proposal >>> > instead of, say, a second mode for commits. (E.g. a commit uses >>> init_secret[n] >>> > iff no kem_output field is included in the commit packet. Otherwise i= t >>> uses the >>> > "external_init_secret" computed as Richard described.) >>> > >>> > ATM I can't think of a scenario where we wouldnt want the external >>> committer to >>> > also be the one creating the ExternalInitSecret proposal and immediat= ly >>> > committing to it... >>> > >>> > - Jo=C3=ABl >>> > >>> > >>> > On 07/10/2020 12:36, Raphael Robert wrote: >>> >> Thanks Richard for looking at all aspects in detail! >>> >> >>> >> I thought about these things as well and will comment inline: >>> >> >>> >>> On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>> >>> >>> >>> Hey all, >>> >>> >>> >>> I wanted to send some thoughts on how to implement external commit, >>> as a >>> >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the >>> proposal >>> >>> is: >>> >>> >>> >>> - Rather than re-using Proposal/Commit, we should make a new >>> ExternalCommit >>> >>> message, parallel to Proposal/Commit >>> >> >>> >> I think we are better off with re-using the current Commit syntax an= d >>> I=E2=80=99ll >>> >> explain why further below. >>> >> >>> >>> - We should also define a syntax for telling the joiner the requisi= te >>> >>> information about the group >>> >>> >>> >>> # HPKE-based init secret >>> >>> >>> >>> The concept here is as follows: >>> >>> >>> >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key >>> schedule for >>> >>> each epoch - The public key `pkG` of that key pair is published >>> along with >>> >>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> >>> some_public_group_context) to get an encapsulated key `enc` and an >>> HPKE >>> >>> context `ctx` - The joiner sends the encapsulated key to the group >>> with >>> >>> their external commit - The members of the group call >>> SetupBaseS(enc, skG, >>> >>> some_public_group_context) to get an equivalent HPKE context `ctx` = - >>> >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to >>> derive >>> >>> the init secret >>> >>> >>> >>> So there are two syntactic requirements: >>> >>> >>> >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the >>> encapsulated key >>> >>> `enc` to the group >>> >> >>> >> From the discussion at the interim, I think there is consensus about >>> this >>> >> part, we just need to add that to the PR. >>> >> >>> >>> >>> >>> >>> >>> # What Proposals? >>> >>> >>> >>> The current PR correctly requires that the external Commit MUST >>> cover an >>> >>> Add proposal for the new member. It does not forbid the Commit >>> covering >>> >>> *other* proposals. It seems like it might be useful in a couple of >>> cases >>> >>> to keep that option open: >>> >> * Including PSK proposals for additional >>> >>> authentication when joining * Including a Remove proposal for your >>> prior >>> >>> appearance when re-joining >>> >>> >>> >>> The only current proposal that would be nonsensical is an Update. >>> >>> >>> >>> Whether we do this has some impact on the syntax, as discussed belo= w. >>> >> >>> >> While that is not very explicit in the current PR, my approach was t= he >>> >> following: >>> >> >>> >> All Proposals should be allowed in an external Commit: >>> >> >>> >> - Adds: The joiner (new member) could right away add more members, o= r >>> Commit >>> >> to already existing Add Proposals if those are accessible. - Removes= : >>> The >>> >> joiner can remove prior appearances of itself (like you pointed out) >>> or >>> >> Commit to already existing Remove Proposals. - Updates: The joiner >>> should of >>> >> course not issue own Updates and Commit to them, but that is already >>> the case >>> >> for internal Commits. The joiner can Commit to already existing Upda= te >>> >> Proposals from other members. >>> >> >>> >> Whether all of the above is allowed should only be governed by the >>> policy for >>> >> a group, nothing else. As a reminder: all clients MUST have the same >>> policy >>> >> for a certain group in order ta validate/refute Proposals and Commit= s. >>> >> >>> >> This pretty much motivates my idea for fully re-using the existing >>> Commit >>> >> syntax and only introduce the new ExternalInitSecret Proposal. >>> >> >>> >>> >>> >>> >>> >>> # External commit syntax: Separate or Together >>> >>> >>> >>> Assume for the moment that we are not going to do the above >>> asymmetric >>> >>> calculation for every commit. Then we need some extra, optional >>> syntax to >>> >>> carry `enc`, either as an optional field on Commit or as a new >>> Proposal, >>> >>> which is the agreed mechanism for extending Commits. (If we do it >>> every >>> >>> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >>> assume a >>> >>> new Proposal, say ExternalInitSecret. >>> >>> >>> >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >>> >> >>> >> This is exactly the Proposal we need. >>> >> >>> >>> >>> >>> Given the requirement for an Add proposal, the joiner now has to >>> send a >>> >>> =E2=80=9Cflight of messages=E2=80=9D: >>> >>> >>> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >>> >> >>> >> I see some more nuance here. The first Add Proposal does not have to >>> be >>> >> issued by the new joiner, it could very well be an external Proposal= . >>> The >>> >> scenario I had in mind here is the following: >>> >> >>> >> A server issues an external Add Proposal for a group. The following >>> things >>> >> can happen: >>> >> >>> >> a) Ideal scenario: >>> >> >>> >> - A member of the group comes online, validates the Add Proposal >>> according to >>> >> the policy and references it in an internal Commit (no External Comm= it >>> >> needed) and sends a Welcome message to the new member >>> >> >>> >> b) Equally ideal scenario: >>> >> >>> >> - The new joiner comes online before anyone else, has access to the >>> public >>> >> group data but does not need to communicate with the group. Nothing >>> happens. >>> >> >>> >> c) Emergency scenario: >>> >> >>> >> - The new joiner comes online before anyone else and needs to >>> urgently send a >>> >> message to the group. The new joiner creates the ExternalInitSecret >>> Proposal >>> >> and the Commit and sends both to group. >>> >> >>> >>> >>> >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit he= avyweight, since >>> each of >>> >>> these is signed separately. It=E2=80=99s duplicative, since the Ke= yPackage >>> in the >>> >>> Add is immediately overwritten by the (necessarily different) KP in >>> the >>> >>> Commit. And you have potential fate-sharing issues, since all thre= e >>> need >>> >>> to succeed or fail. >>> >>> >>> >>> You could also envision a Together Option, where we define another >>> >>> top-level content type (parallel to Proposal and Commit) for this >>> purpose: >>> >>> >>> >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } >>> ExternalCommit; >>> >>> >>> >>> That would avoid all of the challenges above, but it optimizes out >>> all of >>> >>> the flexibility to include other proposals. So maybe it=E2=80=99s = worth >>> >>> considering an Extensible Together Option, where we can put extra >>> proposals >>> >>> into an ExternalCommit >>> >>> >>> >>> struct { Proposal proposals<0..2^32-1>; opaque >>> kem_output<0..2^16-1>; >>> >>> UpdatePath path; } ExternalCommit; >>> >>> >>> >>> Personally, I kind of like the Flexible Together Option, since it >>> provides >>> >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been = wondering >>> if we >>> >>> should allow inline proposals in Commit for a while, along just the= se >>> >>> lines. If we do this option, we should probably back-port it to >>> Commit as >>> >>> well. >>> >>> >>> >> >>> >> As mentioned above, I=E2=80=99m all for re-using the existing Commit= syntax >>> because >>> >> of clarity, simplicity and flexibility. >>> >> >>> >> I do agree that the amount of signatures is sub-optimal, and this is >>> >> something that also occurs in other situations. For example, when a >>> member >>> >> wants to add n new members at once to the group, it needs to compute >>> n+1 >>> >> signatures for that. You mention the idea of inline proposals: Would >>> that be >>> >> a proposal that doesn=E2=80=99t have a signature, but still all othe= r >>> information? If >>> >> so, I think it would be worthwhile looking at that separately, >>> because as you >>> >> say, it could be back-ported to internal Commits as well. I=E2=80=99= m all for >>> >> exploring that idea further. >>> >> >>> >>> >>> >>> # Syntax for what the Joiner Needs >>> >>> >>> >>> The PR notes that the joiner needs to know a bunch of information >>> about the >>> >>> group in order to make a well-formed ExternalCommit. In earlier >>> iterations >>> >>> of this style of join, we had a GroupInitKey that carried the right >>> >>> information. Following that pattern here, we get something like the >>> >>> following: >>> >>> >>> >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 >>> epoch; >>> >>> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>; >>> >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >>> >> >>> >> This is what the PR currently says, except that the PR used >>> GroupContext and >>> >> has the full public tree. I agree that the tree hash should be enoug= h >>> and >>> >> I=E2=80=99ll change the PR accordingly. >>> >> >>> >>> >>> >>> Note that this object is essentially the same as a GroupInfo >>> object. The >>> >>> only things it is missing are interim_transcript_hash and signature= , >>> both >>> >>> of which might be useful. So maybe all we need to do here is say >>> that >>> >>> clients can publish GroupInfo unencrypted if they want to enable >>> self-adds, >>> >>> in addition to distributing it in encrypted form in Welcome. >>> >> >>> >> While the two are awfully similar, the signature on GroupInfo is not >>> required >>> >> here and might have undesired effects w.r.t deniability if this is >>> publicly >>> >> accessible. The other reason for not wanting the signature is that i= t >>> would >>> >> be an additional signature to compute with every Commit, making them >>> even >>> >> more expensive. I propose to keep the struct as-is. >>> >> >>> >>> >>> >>> In any case, it seems like it would be useful to have some syntax f= or >>> >>> this. >>> >>> >>> >>> Hope this helps, =E2=80=94RLB >>> >> >>> >> >>> >> TL;DR: >>> >> >>> >> I propose the following: >>> >> >>> >> - Keep the current Commit syntax - Allow all kinds of Proposals for >>> External >>> >> Commits, same as with internal Commits - Do the HPKE-based init >>> secret for >>> >> External Commits - Introduce the ExternalInitSecret Proposal and mak= e >>> it >>> >> mandatory for External Commits - Explore the idea of inline proposal= s >>> >> separately - Do not re-use signed GroupInfo struct and keep the >>> adjusted >>> >> ExternalCommitInfo instead >>> >> >>> >> Raphael >>> >> >>> >>> _______________________________________________ MLS mailing list >>> >>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>> >> >>> >> _______________________________________________ MLS mailing list >>> >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>> >> >>> > >>> > _______________________________________________ >>> > MLS mailing list >>> > MLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> 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 >> > --0000000000002cb23a05b12ac0e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Changing subject line because changing subject)

Since there seems to be some energy around inline prop= osals regardless of ExternalCommit, I made a quick PR:

=

The intere= sting nuance here is that the Commit specifies an order in which Proposals = are applied.=C2=A0 So there are basically two design options here:

<= /div>
1. Include proposals by value, and reference them by hash in the = order specification
2. Allow the order specification to reference= proposals by value or by hash

I went with the lat= ter approach, because it seemed slightly simpler to me.=C2=A0 But if folks = feel strongly, we could go the other way as well.

= --Richard


On Wed, Oct 7, 2020 at 8:45 PM Brendan M= cMillion <brendan@cloudflare.c= om> wrote:
I know you're all tired of hearing me say this, but = I still feel strongly we should always use asymmetric Commits. If MLS is ot= herwise secure, then there's simply no reason not to, and it simplifies= implementations. There wouldn't have to be a new ExternalInitSecret pr= oposal, validation logic wouldn't get substantially more complicated, a= nd there wouldn't be this worry about bundling several proposals. Otoh,= I think allowing inline proposals in Commits is a good idea but it's o= rthogonal to asymmetric Commits.

On Wed, Oct 7, 2020 at 1:24 PM Raphael = Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
Good points again!

On 7 Oct 2020, at 17:38, Richard Barnes <rlb@ipv.sx> wrote:
<= br>
OK, how about the following proposal (heh):

- Add ExternalInitSecret proposal
- Add a= n "inline proposals" field to Commit that lets the committer send= proposals with a commit

Two remaining worries her= e:

- Validation: You want it to be the case t= hat an ExternalInitSecret is only present for a Commit signed by a new join= er.=C2=A0 So some that information will have to be passed from MLSPlaintext= validation to Commit processing.=C2=A0 Or maybe we don't care about th= at restriction?=C2=A0 It seems like a member sending ExternalInitSecret sho= uld at least be SHOULD NOT, but maybe it's not bad enough to absolutely= forbid / have hard checks against.
=
Good question. I guess you want to detect early on if it is an Ex= ternal Commit or an internal one, perhaps also to block External Commits by= policy. Indeed only the signature and sender type would reveal that.=C2=A0=
Should internal Commits be allowed to have a ExternalInitSecret = proposal that then just gets ignored? I don=E2=80=99t have strong feelings = about it, but I=E2=80=99m leaning towards the safe approach of saying it MU= ST not.

=
- Complexity: MLSPlaintext signature validation has to find = a key to verify the signature.=C2=A0 I guess in this case, it should take t= he one for the Committer (Commit.update_path.leaf_key_package.public_key), = but it should also be the case that that key was added to the group with th= is Commit.=C2=A0 In any case, this probably calls for a new sender type.

Maybe these can both be solved with a flag passe= d into Commit processing:

if (external_commit) {
=C2=A0 // verify that there is an Add corresponding to update_path= .leaf_key_package
} else {
=C2=A0 // verify that Ex= ternalInitSecret is not present
}

I=E2=80=99m thinking that the MLSPlaintext framing the Ex= ternal Commit will reference a previously empty leave (namely the left most= empty leave in the tree). Normally clients would look up the leave to veri= fy a signature, but in this case it=E2=80=99s an indication that it is an E= xternal Commit. Instead, clients have to parse the list of Add Proposal the= precede the Commit to determine who the signer/sender is. Lastly the Exter= nalInitSecret Proposal MUST also be there.

As for = the sender type, couldn=E2=80=99t we use new_member here? Both for the Add = Proposal and the Commit?


Even if so, that logic should ge= t specified in the commit processing section of the spec.
=

I agree that this should be written up in detai= led steps to avoid any confusion.

Raphael


-= -RLB


On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert= <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I think that=E2=80=99s exactly the motivation w= e need for inline proposals, this surplus of signatures is not specific to = this use case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>> Assume for the moment that we are not going to do the above asymme= tric
>> calculation for every commit.=C2=A0 Then we need some extra, optio= nal syntax=C2=A0 to
>> carry `enc`, either as an optional field on Commit or as a new Pro= posal,
>> which is the agreed mechanism for extending Commits.=C2=A0 (If we = do it every
>> time, we can just make this part of Commit.)=C2=A0 In the below, I= =E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a full=
> (ExternInitSecret) proposal packet only to then immediately commit to = it? That
> means a full extra frame of bandwidth, an extra signature for the exte= rnal party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit p= roposal
> instead of, say, a second mode for commits. (E.g. a commit uses init_s= ecret[n]
> iff no kem_output field is included in the commit packet. Otherwise it= uses the
> "external_init_secret" computed as Richard described.)
>
> ATM I can't think of a scenario where we wouldnt want the external= committer to
> also be the one creating the ExternalInitSecret proposal and immediatl= y
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external co= mmit, as a
>>> prelude to a PR.=C2=A0 This is a little bit of an essay, so tl= ;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a new E= xternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the re= quisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for
>>> each epoch - The public key `pkG` of that key pair is publishe= d along with
>>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> some_public_group_context) to get an encapsulated key `enc` an= d an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to the g= roup with
>>> their external commit - The members of the group call SetupBas= eS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE context `= ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)= ` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending = the encapsulated key
>>> `enc` to the group
>>
>> From the discussion at the interim, I think there is consensus abo= ut this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit MUS= T cover an
>>> Add proposal for the new member.=C2=A0 =C2=A0It does not forbi= d the Commit covering
>>> *other* proposals.=C2=A0 It seems like it might be useful in a= couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal for = your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an Upda= te.
>>>
>>> Whether we do this has some impact on the syntax, as discussed= below.
>>
>> While that is not very explicit in the current PR, my approach was= the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more members,= or Commit
>> to already existing Add Proposals if those are accessible. - Remov= es: The
>> joiner can remove prior appearances of itself (like you pointed ou= t) or
>> Commit to already existing Remove Proposals. - Updates: The joiner= should of
>> course not issue own Updates and Commit to them, but that is alrea= dy the case
>> for internal Commits. The joiner can Commit to already existing Up= date
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by the= policy for
>> a group, nothing else. As a reminder: all clients MUST have the sa= me policy
>> for a certain group in order ta validate/refute Proposals and Comm= its.
>>
>> This pretty much motivates my idea for fully re-using the existing= Commit
>> syntax and only introduce the new ExternalInitSecret Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
>>>
>>> Assume for the moment that we are not going to do the above as= ymmetric
>>> calculation for every commit.=C2=A0 Then we need some extra, o= ptional syntax=C2=A0 to
>>> carry `enc`, either as an optional field on Commit or as a new= Proposal,
>>> which is the agreed mechanism for extending Commits.=C2=A0 (If= we do it every
>>> time, we can just make this part of Commit.)=C2=A0 In the belo= w, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSec= ret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now has = to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not have = to be
>> issued by the new joiner, it could very well be an external Propos= al. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The followin= g things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add Proposal a= ccording to
>> the policy and references it in an internal Commit (no External Co= mmit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to th= e public
>> group data but does not need to communicate with the group. Nothin= g happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to urge= ntly send a
>> message to the group. The new joiner creates the ExternalInitSecre= t Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.=C2=A0 It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.=C2=A0 It=E2=80=99s duplicative, si= nce the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily different) = KP in the
>>> Commit.=C2=A0 And you have potential fate-sharing issues, sinc= e all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define ano= ther
>>> top-level content type (parallel to Proposal and Commit) for t= his purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; = } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it optimizes= out all of
>>> the flexibility to include other proposals.=C2=A0 So maybe it= =E2=80=99s worth
>>> considering an Extensible Together Option, where we can put ex= tra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque kem_outpu= t<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, since= it provides
>>> simplicity and extensibility.=C2=A0 And to be honest, I=E2=80= =99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along jus= t these
>>> lines.=C2=A0 If we do this option, we should probably back-por= t it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing Comm= it syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and this = is
>> something that also occurs in other situations. For example, when = a member
>> wants to add n new members at once to the group, it needs to compu= te n+1
>> signatures for that. You mention the idea of inline proposals: Wou= ld that be
>> a proposal that doesn=E2=80=99t have a signature, but still all ot= her information? If
>> so, I think it would be worthwhile looking at that separately, bec= ause as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of informat= ion about the
>>> group in order to make a well-formed ExternalCommit.=C2=A0 In = earlier iterations
>>> of this style of join, we had a GroupInitKey that carried the = right
>>> information. Following that pattern here, we get something lik= e the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque group_id<0..255&g= t;; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque confirmed_transcript_ha= sh<0..255>;
>>> Extension extensions<0..2^32-1>; } GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used GroupC= ontext and
>> has the full public tree. I agree that the tree hash should be eno= ugh and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a GroupInfo o= bject.=C2=A0 The
>>> only things it is missing are interim_transcript_hash and sign= ature, both
>>> of which might be useful.=C2=A0 So maybe all we need to do her= e is say that
>>> clients can publish GroupInfo unencrypted if they want to enab= le self-adds,
>>> in addition to distributing it in encrypted form in Welcome. >>
>> While the two are awfully similar, the signature on GroupInfo is n= ot required
>> here and might have undesired effects w.r.t deniability if this is= publicly
>> accessible. The other reason for not wanting the signature is that= it would
>> be an additional signature to compute with every Commit, making th= em even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some syn= tax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals fo= r External
>> Commits, same as with internal Commits - Do the HPKE-based init se= cret for
>> External Commits - Introduce the ExternalInitSecret Proposal and m= ake it
>> mandatory for External Commits - Explore the idea of inline propos= als
>> separately - Do not re-use signed GroupInfo struct and keep the ad= justed
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing li= st
>>> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing list <= br> >> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

________________________________________= _______
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000002cb23a05b12ac0e0-- From nobody Thu Oct 8 22:26:03 2020 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 E31133A08AA for ; Thu, 8 Oct 2020 22:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkaGADHGSNGK for ; Thu, 8 Oct 2020 22:25:56 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD663A0898 for ; Thu, 8 Oct 2020 22:25:56 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id u8so11329435ejg.1 for ; Thu, 08 Oct 2020 22:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kFBVFjs4N3YmRxMu35gLu8GzPk+Hd/VYr9BrXhcX8iE=; b=W24N8wvakVQ5Tn1w+M2AL4+nKU3uk9C0iGzigTeiaXLkxkDy2sCCKoxz7KcfsSYmca S8kSRgW4VTYpby2KaWFE5JmjjBkmqqCi8cLsjPLj+0TNpTU8kY/GcjYv8n4Klzl5ZvnL C9s1jqRErJkGUG6PEabQAo3r6PQYMOerGnjRpvNxs07H/yco/rEOKRQYCSqoHNX0+yUn TXV9I1ztpPK0cOx+DWfYli03wbUkv072cPehQCWjW7oMVZzlpdwD0WmsHLORCPK9GitB 8b+KdHxBlxDk+QxeN8SRuciaeLQcrC215dEpgAgaf5prYMSj3g9nOhCY51FtiPI+W2HO xhKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kFBVFjs4N3YmRxMu35gLu8GzPk+Hd/VYr9BrXhcX8iE=; b=UF2YoLOFEu7m3G9Q/j956Rk4CWkD7ZvPoVYFirggpAIuqqs+7PIGCDCNjrpb7Hx6vF 8iho7sO9HLwB9xr3bK0tL4A4CcOdqaBbyJLyRPAGXA/rJMxVrhFJzdWNOVHONETTTscp Zkc3GzX7FKQJfUC5QaPhSdB6oDmeEqQUgKaCbii+43Mtk8v1KPgT1nM+oiw5VRoC5OVs 4j/bQlLC6uZAGQwOODSuzCr0bGKxr7Y83T5M2mqYHkRm5PQpyLfo8EwuAuleEKgdIOme ZSR2d6XBGW1w4S1EL3/hKa6FkFcPhXIp7IvuVTB4ex0Whl8EODNtWz0SWvB8tTot92Ua WptA== X-Gm-Message-State: AOAM531Wdkz69tk/TH07mLPujWRmECmQBO1gZ7yC0YAAJAQBze9Di1ba MpYj2jiyKbEOqDbqfJRqDvEuc/vkzqCGaXOh X-Google-Smtp-Source: ABdhPJxHLidixTdi0+IG5aoORJ/PMIO/Z9ZvjzfghYbr3B8hH/yO6SwVGwgG1vY05Sfhe5TfZ4AB0w== X-Received: by 2002:a17:906:b784:: with SMTP id dt4mr13285057ejb.376.1602221154501; Thu, 08 Oct 2020 22:25:54 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id bk13sm5711776ejb.58.2020.10.08.22.25.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Oct 2020 22:25:53 -0700 (PDT) From: Raphael Robert Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3F3065C9-A2EA-467C-B24C-448C85F988E9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 9 Oct 2020 07:25:51 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Richard Barnes References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Inline proposals X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 05:26:01 -0000 --Apple-Mail=_3F3065C9-A2EA-467C-B24C-448C85F988E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this is a good start and a useful feature in general! I think there is is one more nuance when it comes to processing and = validating Commits: In the current state of the draft clients send Proposals followed by one = Commit. Proposals might be valid or not and clients have to validate = them at the latest when they process the Commit. At that point they will = reject the Commit if it contains any invalid Proposal. They will however = still keep the Proposals as such around and wait for the next Commit or = issue a Commit themselves. With inline Proposals this is no longer true. When clients reject a = Commit because of an invalid inline proposal, that proposal is = effectively lost. Clients could of course extract the inline proposals = and either re-use them in their own Commit or frame them as standalone = proposals. We should think about whether we want that and what we should = specify here. > On 8 Oct 2020, at 17:47, Richard Barnes wrote: >=20 > (Changing subject line because changing subject) >=20 > Since there seems to be some energy around inline proposals regardless = of ExternalCommit, I made a quick PR: >=20 > https://github.com/mlswg/mls-protocol/pull/414 = >=20 > The interesting nuance here is that the Commit specifies an order in = which Proposals are applied. So there are basically two design options = here: >=20 > 1. Include proposals by value, and reference them by hash in the order = specification > 2. Allow the order specification to reference proposals by value or by = hash >=20 > I went with the latter approach, because it seemed slightly simpler to = me. But if folks feel strongly, we could go the other way as well. I=E2=80=99m not sure I understand how that=E2=80=99s reflected in the = current PR. Regardless, I think that inline and standalone proposals = should be treated equally from a semantic point of view. >=20 > --Richard >=20 >=20 > On Wed, Oct 7, 2020 at 8:45 PM Brendan McMillion = > wrote: > I know you're all tired of hearing me say this, but I still feel = strongly we should always use asymmetric Commits. If MLS is otherwise = secure, then there's simply no reason not to, and it simplifies = implementations. There wouldn't have to be a new ExternalInitSecret = proposal, validation logic wouldn't get substantially more complicated, = and there wouldn't be this worry about bundling several proposals. Otoh, = I think allowing inline proposals in Commits is a good idea but it's = orthogonal to asymmetric Commits. >=20 > On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert = > = wrote: > Good points again! >=20 >> On 7 Oct 2020, at 17:38, Richard Barnes > wrote: >>=20 >> OK, how about the following proposal (heh): >>=20 >> - Add ExternalInitSecret proposal >> - Add an "inline proposals" field to Commit that lets the committer = send proposals with a commit >>=20 >> Two remaining worries here:=20 >>=20 >> - Validation: You want it to be the case that an ExternalInitSecret = is only present for a Commit signed by a new joiner. So some that = information will have to be passed from MLSPlaintext validation to = Commit processing. Or maybe we don't care about that restriction? It = seems like a member sending ExternalInitSecret should at least be SHOULD = NOT, but maybe it's not bad enough to absolutely forbid / have hard = checks against. >=20 > Good question. I guess you want to detect early on if it is an = External Commit or an internal one, perhaps also to block External = Commits by policy. Indeed only the signature and sender type would = reveal that.=20 > Should internal Commits be allowed to have a ExternalInitSecret = proposal that then just gets ignored? I don=E2=80=99t have strong = feelings about it, but I=E2=80=99m leaning towards the safe approach of = saying it MUST not. >=20 >>=20 >> - Complexity: MLSPlaintext signature validation has to find a key to = verify the signature. I guess in this case, it should take the one for = the Committer (Commit.update_path.leaf_key_package.public_key), but it = should also be the case that that key was added to the group with this = Commit. In any case, this probably calls for a new sender type. >>=20 >> Maybe these can both be solved with a flag passed into Commit = processing: >>=20 >> if (external_commit) { >> // verify that there is an Add corresponding to = update_path.leaf_key_package >> } else { >> // verify that ExternalInitSecret is not present >> } >=20 > I=E2=80=99m thinking that the MLSPlaintext framing the External Commit = will reference a previously empty leave (namely the left most empty = leave in the tree). Normally clients would look up the leave to verify a = signature, but in this case it=E2=80=99s an indication that it is an = External Commit. Instead, clients have to parse the list of Add Proposal = the precede the Commit to determine who the signer/sender is. Lastly the = ExternalInitSecret Proposal MUST also be there. >=20 > As for the sender type, couldn=E2=80=99t we use new_member here? Both = for the Add Proposal and the Commit? >=20 >>=20 >> Even if so, that logic should get specified in the commit processing = section of the spec. >=20 > I agree that this should be written up in detailed steps to avoid any = confusion. >=20 > Raphael >=20 >>=20 >> --RLB >>=20 >>=20 >> On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert = > = wrote: >> I think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use case! >>=20 >> Raphael >>=20 >> > On 7 Oct 2020, at 13:27, Joel Alwen > wrote: >> >=20 >> > On 7 Oct 2020, at 03:20, Richard Barnes > wrote: >> >> Assume for the moment that we are not going to do the above = asymmetric >> >> calculation for every commit. Then we need some extra, optional = syntax to >> >> carry `enc`, either as an optional field on Commit or as a new = Proposal, >> >> which is the agreed mechanism for extending Commits. (If we do it = every >> >> time, we can just make this part of Commit.) In the below, I=E2=80=99= ll assume a >> >> new Proposal, say ExternalInitSecret. >> > Isn't it a bit redundant to have the External party prepare a full >> > (ExternInitSecret) proposal packet only to then immediately commit = to it? That >> > means a full extra frame of bandwidth, an extra signature for the = external party >> > and an extra sig verification for group members. >> >=20 >> > I'm wondering what the motivation is for making this an explicit = proposal >> > instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n] >> > iff no kem_output field is included in the commit packet. Otherwise = it uses the >> > "external_init_secret" computed as Richard described.) >> >=20 >> > ATM I can't think of a scenario where we wouldnt want the external = committer to >> > also be the one creating the ExternalInitSecret proposal and = immediatly >> > committing to it... >> >=20 >> > - Jo=C3=ABl >> >=20 >> >=20 >> > On 07/10/2020 12:36, Raphael Robert wrote: >> >> Thanks Richard for looking at all aspects in detail! >> >>=20 >> >> I thought about these things as well and will comment inline: >> >>=20 >> >>> On 7 Oct 2020, at 03:20, Richard Barnes > wrote: >> >>>=20 >> >>> Hey all, >> >>>=20 >> >>> I wanted to send some thoughts on how to implement external = commit, as a >> >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the = proposal >> >>> is: >> >>>=20 >> >>> - Rather than re-using Proposal/Commit, we should make a new = ExternalCommit >> >>> message, parallel to Proposal/Commit >> >>=20 >> >> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll >> >> explain why further below. >> >>=20 >> >>> - We should also define a syntax for telling the joiner the = requisite >> >>> information about the group >> >>>=20 >> >>> # HPKE-based init secret >> >>>=20 >> >>> The concept here is as follows: >> >>>=20 >> >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for >> >>> each epoch - The public key `pkG` of that key pair is published = along with >> >>> with other group metadata - The joiner calls SetupBaseS(pkG, >> >>> some_public_group_context) to get an encapsulated key `enc` and = an HPKE >> >>> context `ctx` - The joiner sends the encapsulated key to the = group with >> >>> their external commit - The members of the group call = SetupBaseS(enc, skG, >> >>> some_public_group_context) to get an equivalent HPKE context = `ctx` - >> >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` = to derive >> >>> the init secret >> >>>=20 >> >>> So there are two syntactic requirements: >> >>>=20 >> >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the = encapsulated key >> >>> `enc` to the group >> >>=20 >> >> =46rom the discussion at the interim, I think there is consensus = about this >> >> part, we just need to add that to the PR. >> >>=20 >> >>>=20 >> >>>=20 >> >>> # What Proposals? >> >>>=20 >> >>> The current PR correctly requires that the external Commit MUST = cover an >> >>> Add proposal for the new member. It does not forbid the Commit = covering >> >>> *other* proposals. It seems like it might be useful in a couple = of cases >> >>> to keep that option open: >> >> * Including PSK proposals for additional >> >>> authentication when joining * Including a Remove proposal for = your prior >> >>> appearance when re-joining >> >>>=20 >> >>> The only current proposal that would be nonsensical is an Update. >> >>>=20 >> >>> Whether we do this has some impact on the syntax, as discussed = below. >> >>=20 >> >> While that is not very explicit in the current PR, my approach was = the >> >> following: >> >>=20 >> >> All Proposals should be allowed in an external Commit: >> >>=20 >> >> - Adds: The joiner (new member) could right away add more members, = or Commit >> >> to already existing Add Proposals if those are accessible. - = Removes: The >> >> joiner can remove prior appearances of itself (like you pointed = out) or >> >> Commit to already existing Remove Proposals. - Updates: The joiner = should of >> >> course not issue own Updates and Commit to them, but that is = already the case >> >> for internal Commits. The joiner can Commit to already existing = Update >> >> Proposals from other members. >> >>=20 >> >> Whether all of the above is allowed should only be governed by the = policy for >> >> a group, nothing else. As a reminder: all clients MUST have the = same policy >> >> for a certain group in order ta validate/refute Proposals and = Commits. >> >>=20 >> >> This pretty much motivates my idea for fully re-using the existing = Commit >> >> syntax and only introduce the new ExternalInitSecret Proposal. >> >>=20 >> >>>=20 >> >>>=20 >> >>> # External commit syntax: Separate or Together >> >>>=20 >> >>> Assume for the moment that we are not going to do the above = asymmetric >> >>> calculation for every commit. Then we need some extra, optional = syntax to >> >>> carry `enc`, either as an optional field on Commit or as a new = Proposal, >> >>> which is the agreed mechanism for extending Commits. (If we do = it every >> >>> time, we can just make this part of Commit.) In the below, = I=E2=80=99ll assume a >> >>> new Proposal, say ExternalInitSecret. >> >>>=20 >> >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >> >>=20 >> >> This is exactly the Proposal we need. >> >>=20 >> >>>=20 >> >>> Given the requirement for an Add proposal, the joiner now has to = send a >> >>> =E2=80=9Cflight of messages=E2=80=9D: >> >>>=20 >> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >> >>=20 >> >> I see some more nuance here. The first Add Proposal does not have = to be >> >> issued by the new joiner, it could very well be an external = Proposal. The >> >> scenario I had in mind here is the following: >> >>=20 >> >> A server issues an external Add Proposal for a group. The = following things >> >> can happen: >> >>=20 >> >> a) Ideal scenario: >> >>=20 >> >> - A member of the group comes online, validates the Add Proposal = according to >> >> the policy and references it in an internal Commit (no External = Commit >> >> needed) and sends a Welcome message to the new member >> >>=20 >> >> b) Equally ideal scenario: >> >>=20 >> >> - The new joiner comes online before anyone else, has access to = the public >> >> group data but does not need to communicate with the group. = Nothing happens. >> >>=20 >> >> c) Emergency scenario: >> >>=20 >> >> - The new joiner comes online before anyone else and needs to = urgently send a >> >> message to the group. The new joiner creates the = ExternalInitSecret Proposal >> >> and the Commit and sends both to group. >> >>=20 >> >>>=20 >> >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit = heavyweight, since each of >> >>> these is signed separately. It=E2=80=99s duplicative, since the = KeyPackage in the >> >>> Add is immediately overwritten by the (necessarily different) KP = in the >> >>> Commit. And you have potential fate-sharing issues, since all = three need >> >>> to succeed or fail. >> >>>=20 >> >>> You could also envision a Together Option, where we define = another >> >>> top-level content type (parallel to Proposal and Commit) for this = purpose: >> >>>=20 >> >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } = ExternalCommit; >> >>>=20 >> >>> That would avoid all of the challenges above, but it optimizes = out all of >> >>> the flexibility to include other proposals. So maybe it=E2=80=99s = worth >> >>> considering an Extensible Together Option, where we can put extra = proposals >> >>> into an ExternalCommit >> >>>=20 >> >>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;=20 >> >>> UpdatePath path; } ExternalCommit; >> >>>=20 >> >>> Personally, I kind of like the Flexible Together Option, since it = provides >> >>> simplicity and extensibility. And to be honest, I=E2=80=99ve = been wondering if we >> >>> should allow inline proposals in Commit for a while, along just = these >> >>> lines. If we do this option, we should probably back-port it to = Commit as >> >>> well. >> >>>=20 >> >>=20 >> >> As mentioned above, I=E2=80=99m all for re-using the existing = Commit syntax because >> >> of clarity, simplicity and flexibility. >> >>=20 >> >> I do agree that the amount of signatures is sub-optimal, and this = is >> >> something that also occurs in other situations. For example, when = a member >> >> wants to add n new members at once to the group, it needs to = compute n+1 >> >> signatures for that. You mention the idea of inline proposals: = Would that be >> >> a proposal that doesn=E2=80=99t have a signature, but still all = other information? If >> >> so, I think it would be worthwhile looking at that separately, = because as you >> >> say, it could be back-ported to internal Commits as well. I=E2=80=99= m all for >> >> exploring that idea further. >> >>=20 >> >>>=20 >> >>> # Syntax for what the Joiner Needs >> >>>=20 >> >>> The PR notes that the joiner needs to know a bunch of information = about the >> >>> group in order to make a well-formed ExternalCommit. In earlier = iterations >> >>> of this style of join, we had a GroupInitKey that carried the = right >> >>> information. Following that pattern here, we get something like = the >> >>> following: >> >>>=20 >> >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; = uint64 epoch;=20 >> >>> opaque tree_hash<0..255>; opaque = confirmed_transcript_hash<0..255>;=20 >> >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >> >>=20 >> >> This is what the PR currently says, except that the PR used = GroupContext and >> >> has the full public tree. I agree that the tree hash should be = enough and >> >> I=E2=80=99ll change the PR accordingly. >> >>=20 >> >>>=20 >> >>> Note that this object is essentially the same as a GroupInfo = object. The >> >>> only things it is missing are interim_transcript_hash and = signature, both >> >>> of which might be useful. So maybe all we need to do here is say = that >> >>> clients can publish GroupInfo unencrypted if they want to enable = self-adds, >> >>> in addition to distributing it in encrypted form in Welcome. >> >>=20 >> >> While the two are awfully similar, the signature on GroupInfo is = not required >> >> here and might have undesired effects w.r.t deniability if this is = publicly >> >> accessible. The other reason for not wanting the signature is that = it would >> >> be an additional signature to compute with every Commit, making = them even >> >> more expensive. I propose to keep the struct as-is. >> >>=20 >> >>>=20 >> >>> In any case, it seems like it would be useful to have some syntax = for >> >>> this. >> >>>=20 >> >>> Hope this helps, =E2=80=94RLB >> >>=20 >> >>=20 >> >> TL;DR: >> >>=20 >> >> I propose the following: >> >>=20 >> >> - Keep the current Commit syntax - Allow all kinds of Proposals = for External >> >> Commits, same as with internal Commits - Do the HPKE-based init = secret for >> >> External Commits - Introduce the ExternalInitSecret Proposal and = make it >> >> mandatory for External Commits - Explore the idea of inline = proposals >> >> separately - Do not re-use signed GroupInfo struct and keep the = adjusted >> >> ExternalCommitInfo instead >> >>=20 >> >> Raphael >> >>=20 >> >>> _______________________________________________ MLS mailing list=20= >> >>> MLS@ietf.org = https://www.ietf.org/mailman/listinfo/mls = >> >>=20 >> >> _______________________________________________ MLS mailing list=20= >> >> MLS@ietf.org = https://www.ietf.org/mailman/listinfo/mls = >> >>=20 >> >=20 >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mls = >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_3F3065C9-A2EA-467C-B24C-448C85F988E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think this is a good start and a useful feature in general!

I think there is is one = more nuance when it comes to processing and validating = Commits:

In = the current state of the draft clients send Proposals followed by one = Commit. Proposals might be valid or not and clients have to validate = them at the latest when they process the Commit. At that point they will = reject the Commit if it contains any invalid Proposal. They will however = still keep the Proposals as such around and wait for the next Commit or = issue a Commit themselves.

With inline Proposals this is no longer true. When clients = reject a Commit because of an invalid inline proposal, that proposal is = effectively lost. Clients could of course extract the inline proposals = and either re-use them in their own Commit or frame them as standalone = proposals. We should think about whether we want that and what we should = specify here.

On 8 Oct 2020, at 17:47, = Richard Barnes <rlb@ipv.sx> wrote:

(Changing subject line because changing = subject)

Since = there seems to be some energy around inline proposals regardless of = ExternalCommit, I made a quick PR:

https://github.com/mlswg/mls-protocol/pull/414

The interesting nuance = here is that the Commit specifies an order in which Proposals are = applied.  So there are basically two design options here:

1. Include proposals by = value, and reference them by hash in the order specification
2. Allow the order specification to reference proposals by = value or by hash

I went with the latter approach, because it seemed slightly = simpler to me.  But if folks feel strongly, we could go the other = way as well.

I=E2=80= =99m not sure I understand how that=E2=80=99s reflected in the current = PR. Regardless, I think that inline and standalone proposals should be = treated equally from a semantic point of view.


--Richard


On Wed, Oct 7, 2020 at 8:45 PM Brendan = McMillion <brendan@cloudflare.com> wrote:
I know = you're all tired of hearing me say this, but I still feel strongly we = should always use asymmetric Commits. If MLS is otherwise secure, then = there's simply no reason not to, and it simplifies implementations. = There wouldn't have to be a new ExternalInitSecret proposal, validation = logic wouldn't get substantially more complicated, and there wouldn't be = this worry about bundling several proposals. Otoh, I think allowing = inline proposals in Commits is a good idea but it's orthogonal to = asymmetric Commits.

On Wed, Oct = 7, 2020 at 1:24 PM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
Good points again!

On 7 Oct 2020, at 17:38, Richard Barnes = <rlb@ipv.sx> wrote:

OK, how about the = following proposal (heh):

- Add ExternalInitSecret proposal
- Add = an "inline proposals" field to Commit that lets the committer send = proposals with a commit

Two remaining worries here:

- Validation: You want = it to be the case that an ExternalInitSecret is only present for a = Commit signed by a new joiner.  So some that information will have = to be passed from MLSPlaintext validation to Commit processing.  Or = maybe we don't care about that restriction?  It seems like a member = sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's = not bad enough to absolutely forbid / have hard checks against.

Good question. I guess you want to detect early on if = it is an External Commit or an internal one, perhaps also to block = External Commits by policy. Indeed only the signature and sender type = would reveal that. 
Should internal Commits be = allowed to have a ExternalInitSecret proposal that then just gets = ignored? I don=E2=80=99t have strong feelings about it, but I=E2=80=99m = leaning towards the safe approach of saying it MUST not.


- Complexity: MLSPlaintext signature = validation has to find a key to verify the signature.  I guess in = this case, it should take the one for the Committer = (Commit.update_path.leaf_key_package.public_key), but it should also be = the case that that key was added to the group with this Commit.  In = any case, this probably calls for a new sender type.

Maybe these can both be solved with a flag passed into Commit = processing:

if = (external_commit) {
  // verify that there is = an Add corresponding to update_path.leaf_key_package
} else {
  // verify = that ExternalInitSecret is not present
}

I=E2=80=99m thinking that the MLSPlaintext framing the = External Commit will reference a previously empty leave (namely the left = most empty leave in the tree). Normally clients would look up the leave = to verify a signature, but in this case it=E2=80=99s an indication that = it is an External Commit. Instead, clients have to parse the list of Add = Proposal the precede the Commit to determine who the signer/sender is. = Lastly the ExternalInitSecret Proposal MUST also be there.

As for the sender type, = couldn=E2=80=99t we use new_member here? Both for the Add Proposal and = the Commit?


Even if so, that logic should get specified in the commit = processing section of the spec.

I agree that this should be written up = in detailed steps to avoid any confusion.

Raphael


--RLB


On Wed, Oct 7, 2020 at 8:57 AM Raphael = Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I = think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use = case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx>= wrote:
>> Assume for the moment that we are not going to do the above = asymmetric
>> calculation for every commit.  Then we need some extra, = optional syntax  to
>> carry `enc`, either as an optional field on Commit or as a new = Proposal,
>> which is the agreed mechanism for extending Commits.  (If = we do it every
>> time, we can just make this part of Commit.)  In the = below, I=E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a = full
> (ExternInitSecret) proposal packet only to then immediately commit = to it? That
> means a full extra frame of bandwidth, an extra signature for the = external party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit = proposal
> instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n]
> iff no kem_output field is included in the commit packet. Otherwise = it uses the
> "external_init_secret" computed as Richard described.)
= >
> ATM I can't think of a scenario where we wouldnt want the external = committer to
> also be the one creating the ExternalInitSecret proposal and = immediatly
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment = inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx>= wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external = commit, as a
>>> prelude to a PR.  This is a little bit of an essay, so = tl;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a = new ExternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit = syntax and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the = requisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the = key schedule for
>>> each epoch - The public key `pkG` of that key pair is = published along with
>>> with other group metadata - The joiner calls = SetupBaseS(pkG,
>>> some_public_group_context) to get an encapsulated key `enc` = and an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to = the group with
>>> their external commit - The members of the group call = SetupBaseS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE = context `ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, = init_secret_size)` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. = Sending the encapsulated key
>>> `enc` to the group
>>
>> =46rom the discussion at the interim, I think there is = consensus about this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit = MUST cover an
>>> Add proposal for the new member.   It does not = forbid the Commit covering
>>> *other* proposals.  It seems like it might be useful = in a couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal = for your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an = Update.
>>>
>>> Whether we do this has some impact on the syntax, as = discussed below.
>>
>> While that is not very explicit in the current PR, my approach = was the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more = members, or Commit
>> to already existing Add Proposals if those are accessible. - = Removes: The
>> joiner can remove prior appearances of itself (like you pointed = out) or
>> Commit to already existing Remove Proposals. - Updates: The = joiner should of
>> course not issue own Updates and Commit to them, but that is = already the case
>> for internal Commits. The joiner can Commit to already existing = Update
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by = the policy for
>> a group, nothing else. As a reminder: all clients MUST have the = same policy
>> for a certain group in order ta validate/refute Proposals and = Commits.
>>
>> This pretty much motivates my idea for fully re-using the = existing Commit
>> syntax and only introduce the new ExternalInitSecret = Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
= >>>
>>> Assume for the moment that we are not going to do the above = asymmetric
>>> calculation for every commit.  Then we need some = extra, optional syntax  to
>>> carry `enc`, either as an optional field on Commit or as a = new Proposal,
>>> which is the agreed mechanism for extending Commits.  = (If we do it every
>>> time, we can just make this part of Commit.)  In the = below, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } = ExternalInitSecret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now = has to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not = have to be
>> issued by the new joiner, it could very well be an external = Proposal. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The = following things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add = Proposal according to
>> the policy and references it in an internal Commit (no External = Commit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to = the public
>> group data but does not need to communicate with the group. = Nothing happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to = urgently send a
>> message to the group. The new joiner creates the = ExternalInitSecret Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.  It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.  It=E2=80=99s duplicative, = since the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily = different) KP in the
>>> Commit.  And you have potential fate-sharing issues, = since all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define = another
>>> top-level content type (parallel to Proposal and Commit) = for this purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath = path; } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it = optimizes out all of
>>> the flexibility to include other proposals.  So maybe = it=E2=80=99s worth
>>> considering an Extensible Together Option, where we can put = extra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, = since it provides
>>> simplicity and extensibility.  And to be honest, = I=E2=80=99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along = just these
>>> lines.  If we do this option, we should probably = back-port it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing = Commit syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and = this is
>> something that also occurs in other situations. For example, = when a member
>> wants to add n new members at once to the group, it needs to = compute n+1
>> signatures for that. You mention the idea of inline proposals: = Would that be
>> a proposal that doesn=E2=80=99t have a signature, but still all = other information? If
>> so, I think it would be worthwhile looking at that separately, = because as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of = information about the
>>> group in order to make a well-formed ExternalCommit.  = In earlier iterations
>>> of this style of join, we had a GroupInitKey that carried = the right
>>> information. Following that pattern here, we get something = like the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque = group_id<0..255>; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque = confirmed_transcript_hash<0..255>;
>>> Extension extensions<0..2^32-1>; } = GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used = GroupContext and
>> has the full public tree. I agree that the tree hash should be = enough and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a = GroupInfo object.  The
>>> only things it is missing are interim_transcript_hash and = signature, both
>>> of which might be useful.  So maybe all we need to do = here is say that
>>> clients can publish GroupInfo unencrypted if they want to = enable self-adds,
>>> in addition to distributing it in encrypted form in = Welcome.
>>
>> While the two are awfully similar, the signature on GroupInfo = is not required
>> here and might have undesired effects w.r.t deniability if this = is publicly
>> accessible. The other reason for not wanting the signature is = that it would
>> be an additional signature to compute with every Commit, making = them even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some = syntax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals = for External
>> Commits, same as with internal Commits - Do the HPKE-based init = secret for
>> External Commits - Introduce the ExternalInitSecret Proposal = and make it
>> mandatory for External Commits - Explore the idea of inline = proposals
>> separately - Do not re-use signed GroupInfo struct and keep the = adjusted
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing = list
>>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing = list
>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

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

= --Apple-Mail=_3F3065C9-A2EA-467C-B24C-448C85F988E9-- From nobody Sun Oct 11 00:41:01 2020 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 0CC583A0F61 for ; Sun, 11 Oct 2020 00:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZSSeCrpA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HJzm75kj 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 tuUsSgzZ4BxX for ; Sun, 11 Oct 2020 00:40:54 -0700 (PDT) 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 3A8C43A0F66 for ; Sun, 11 Oct 2020 00:40:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F160E5C00EF for ; Sun, 11 Oct 2020 03:33:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 11 Oct 2020 03:33:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=5RTTYhCPRBkPezbv7fpSLAYaX1QI0WaaFfnFSC+Kro0=; b=ZSSeCrpA rO2aWMgwyu34+jRFGAw4eQNitaPwUZrXsBgMST9HGadw1a8RoC1gsk40ezautGz/ Fa/3n1yY54rJlWa68iIzXHffijWQegkP7Tz0V+TtEDyd/9wQ3ba2zl16ghsY3r/Z SG6JU9N4SPx1J4y7s+s8c8eMLz6JPxSm4wF+88GYPgYWIYbyh/PbWRSZnVgvgRGr prmvhJAKCGDsAEsXCjvq1DFeUqNscoJjpXNsRgrpbTRXVeoGpjjCMtnWYxvNhooA A90dgdwuWRfgib9HdXEUIf34DScnTGkrCY0SOCWz2/VXaVR8NxRzYpTUsExfoU0L KLV32zLIj0ybhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=5RTTYhCPRBkPezbv7fpSLAYaX1QI0 WaaFfnFSC+Kro0=; b=HJzm75kj4NJZ6wjFPD5uCegY3YbgbCSMrnFi/L3RlcKYN Lfy3eeKZLAIpuZWTMjUT3/MyFRIWfGWm8OFyTjXxRhjIZlhm1T2hWJWZFeNKXJn6 hYMX4An12lWiTXf8SgF2L3FFqx0KZRHd84AZ0Dmurrx1C2YZGAP3+eNVj2POctXo RM+Y/+ueU7P0lC0X/LzlEVLimHEBWricll69PuK/TBDMWo1FvAyD6tA8ahALubhC 86TV/5Lrs+4ik0Cpb2g2DQzTRAwsFS+YmMHzx5X8CET2L4mgxyQo4II4SF4k4HVm Bt+RR4dtfC4d+N/QOuZNovF+6z/jHXfDgp1osf8oQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheeggddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddugeeirdefjedrud ehjeenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az54.internal.cloudapp.net (unknown [52.146.37.157]) by mail.messagingengine.com (Postfix) with ESMTPA id BA5053064680 for ; Sun, 11 Oct 2020 03:33:08 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4694024700191757177==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201011073308.BA5053064680@mailuser.nyi.internal> Date: Sun, 11 Oct 2020 03:33:08 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 07:40:56 -0000 --===============4694024700191757177== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+3/-1/=F0=9F=92=AC12) 3 issues created: - Track Expected Types of Deployments (by Bren2010) https://github.com/mlswg/mls-protocol/issues/411=20 - Welcome message delivery (by franziskuskiefer) https://github.com/mlswg/mls-protocol/issues/410=20 - Draft structure/Editorial Changes (by franziskuskiefer) https://github.com/mlswg/mls-protocol/issues/409=20 4 issues received 12 new comments: - #411 Track Expected Types of Deployments (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/411=20 - #410 Welcome message delivery (6 by Bren2010, bifurcation, franziskuski= efer) https://github.com/mlswg/mls-protocol/issues/410 [editorial]=20 - #409 Draft structure/Editorial Changes (4 by beurdouche, franziskuskief= er) https://github.com/mlswg/mls-protocol/issues/409 [editorial]=20 - #273 Editorial: structure of the document (1 by beurdouche) https://github.com/mlswg/mls-protocol/issues/273 [discussion] [editoria= l]=20 1 issues closed: - Editorial: structure of the document https://github.com/mlswg/mls-proto= col/issues/273 [discussion] [editorial]=20 Pull requests ------------- * mlswg/mls-protocol (+5/-7/=F0=9F=92=AC6) 5 pull requests submitted: - Inlclude the signature in the confirmation tag (by dajost) https://github.com/mlswg/mls-protocol/pull/416=20 - make IANA reference for Signature Schemes more precise (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/415=20 - Allow proposals by value in Commit (by bifurcation) https://github.com/mlswg/mls-protocol/pull/414=20 - Remove references to undefined SignatureScheme enum. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/413=20 - Editorial changes to Content Auth section. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/412=20 3 pull requests received 6 new comments: - #415 make IANA reference for Signature Schemes more precise (2 by Bren2= 010, kkohbrok) https://github.com/mlswg/mls-protocol/pull/415=20 - #402 Allow for credentials supporting multiple signature schemes (3 by = bifurcation, kkohbrok) https://github.com/mlswg/mls-protocol/pull/402=20 - #349 Use opaque epoch IDs and encrypt content type (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/349=20 7 pull requests merged: - Editorial changes to Content Auth section. https://github.com/mlswg/mls-protocol/pull/412=20 - Allow for credentials supporting multiple signature schemes https://github.com/mlswg/mls-protocol/pull/402=20 - PSK Injection, Group recovery, Re-Init, Sub-group Branching https://github.com/mlswg/mls-protocol/pull/336 [key schedule]=20 - Update security considerations. https://github.com/mlswg/mls-protocol/pull/400=20 - Authenticate group membership in MLSPlaintext https://github.com/mlswg/mls-protocol/pull/396=20 - Derive handshake keys from a secret tree as well. https://github.com/mlswg/mls-protocol/pull/401=20 - Clarify X509Credential structure https://github.com/mlswg/mls-protocol/pull/408=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============4694024700191757177== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 11, 2020

Issues

mlswg/mls-protocol (+3/-1/=F0=9F=92=AC12)

3 issues created:

4 issues received 12 new comments:

1 issues closed:

Pull requests

mlswg/mls-protocol (+5/-7/=F0=9F=92=AC6)

5 pull requests submitted:

3 pull requests received 6 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============4694024700191757177==-- From nobody Sun Oct 11 11:59:01 2020 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 60EE93A1008 for ; Sun, 11 Oct 2020 11:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWiaQTsYspbM for ; Sun, 11 Oct 2020 11:58:55 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 90B863A1007 for ; Sun, 11 Oct 2020 11:58:55 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id t20so7413328qvv.8 for ; Sun, 11 Oct 2020 11:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QWL4evmgo8WazPBMziHYhVMgc/QfGUz6QQNs6+qqq+4=; b=0Ke5/CL1v4/8XEfOBAJQHhS4j2ax59laJoxvmTBjkTyQuc/ly99yjm8u/Vpc7VKDF5 2xxn0o1n/CHb0ar36A5kA90E/EpqgS+PRreQlfNPRzmEYjRc4BL6DUXyv6gN/nX/Lx4k Qs7DRZnAL7k/VQ2MpObP6ZECM6xHYeXdwXDs8GTaTJY21h33af+tBxnXCEEKnnYMd4KL owXabJX+C9bg0Z+8h5B7j+FwH1c/hohI1pB3K+Fd0BZMAIxxbGWaCoWxjthJyTZA/JNU /J8DgX28XVz1ZGzZbzjgnyRYSTM3yE+j4GYULO9HVLRRkHp4DLahaESzgPn6AlOeMRRh QDlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QWL4evmgo8WazPBMziHYhVMgc/QfGUz6QQNs6+qqq+4=; b=tXMt/HXgZZ4QyiG5ixn5IcC9AzlndU8NaF+KhIA1zAVtf3XfFDCV4aqQlM6GJZCQu+ S+otIbBmSjwOI5smyGZaSM6kranF4YF4nBxdg/7UHQRisJfiPHkKrOBCOo28f/fNMZxS NTKr07Bkb2ZrkZRWzxQP5nKqdOU5SeJXLjYTzvQUkSrEiUfSyrbbroheqxfqEAQTbTt8 u0zjb5omn6siawVCckjlOL9OPS6en4uLUzvXLdxbalWehVxWiEx4IqpPmyeFAB+Cmug/ v395g30hgHS4z0XR8E/v2AkfaYdGWHinH3cvBnZs4oH5lhKF8YvRdp9t9T/qOW5pnpGJ J9ug== X-Gm-Message-State: AOAM530dVBmkDaLsvn3m8feuAb9P8Q4yMXR8KKTfxCgPVerc2K3YwOwG 1vmLKxYwkruoHzAJo3yiz0DNtq5ni2+TiKPWLUFbqA== X-Google-Smtp-Source: ABdhPJzTWqPJ+w28LahAC/ZTcDoiI00THk/UBOz9kG79T1t033o8dQX477m1Uhqp+H888ocmo8oStIMj440khiRozCw= X-Received: by 2002:a0c:f64b:: with SMTP id s11mr15691016qvm.47.1602442733031; Sun, 11 Oct 2020 11:58:53 -0700 (PDT) MIME-Version: 1.0 References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> In-Reply-To: From: Richard Barnes Date: Sun, 11 Oct 2020 14:58:38 -0400 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000e02b3005b169c5df" Archived-At: Subject: Re: [MLS] Inline proposals X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 18:58:59 -0000 --000000000000e02b3005b169c5df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In case it helps folks grok this change: I implemented this PR in the C++ stack that Suhas and I have been working on, as part of prototyping out external Commit: https://github.com/cisco/mlspp/pull/118/commits/a52018c1ed44224fe5b616b7ef8= 24b74a791d1f7 Raphael: To your equivalence point, the above code does what I think is the opposite of what you propose -- inline proposals fate share with the Commit they're attached to. If the Commit fails, then the proposals inlined in it are not cached. Personally, I think that's probably the right outcome, since otherwise you end up with a Commit that can partly fail, in the sense that it was not applied, but still left some proposals cached. Cleaner to have the Commit and all inline proposals discarded if the Commit or any inline proposal is invalid. --Richard On Fri, Oct 9, 2020 at 1:25 AM Raphael Robert wrote: > I think this is a good start and a useful feature in general! > > I think there is is one more nuance when it comes to processing and > validating Commits: > > In the current state of the draft clients send Proposals followed by one > Commit. Proposals might be valid or not and clients have to validate them > at the latest when they process the Commit. At that point they will rejec= t > the Commit if it contains any invalid Proposal. They will however still > keep the Proposals as such around and wait for the next Commit or issue a > Commit themselves. > > With inline Proposals this is no longer true. When clients reject a Commi= t > because of an invalid inline proposal, that proposal is effectively lost. > Clients could of course extract the inline proposals and either re-use th= em > in their own Commit or frame them as standalone proposals. We should thin= k > about whether we want that and what we should specify here. > > On 8 Oct 2020, at 17:47, Richard Barnes wrote: > > (Changing subject line because changing subject) > > Since there seems to be some energy around inline proposals regardless of > ExternalCommit, I made a quick PR: > > https://github.com/mlswg/mls-protocol/pull/414 > > The interesting nuance here is that the Commit specifies an order in whic= h > Proposals are applied. So there are basically two design options here: > > 1. Include proposals by value, and reference them by hash in the order > specification > 2. Allow the order specification to reference proposals by value or by ha= sh > > I went with the latter approach, because it seemed slightly simpler to > me. But if folks feel strongly, we could go the other way as well. > > > I=E2=80=99m not sure I understand how that=E2=80=99s reflected in the cur= rent PR. > Regardless, I think that inline and standalone proposals should be treate= d > equally from a semantic point of view. > > > --Richard > > > On Wed, Oct 7, 2020 at 8:45 PM Brendan McMillion > wrote: > >> I know you're all tired of hearing me say this, but I still feel strongl= y >> we should always use asymmetric Commits. If MLS is otherwise secure, the= n >> there's simply no reason not to, and it simplifies implementations. Ther= e >> wouldn't have to be a new ExternalInitSecret proposal, validation logic >> wouldn't get substantially more complicated, and there wouldn't be this >> worry about bundling several proposals. Otoh, I think allowing inline >> proposals in Commits is a good idea but it's orthogonal to asymmetric >> Commits. >> >> On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert > 40wire.com@dmarc.ietf.org> wrote: >> >>> Good points again! >>> >>> On 7 Oct 2020, at 17:38, Richard Barnes wrote: >>> >>> OK, how about the following proposal (heh): >>> >>> - Add ExternalInitSecret proposal >>> - Add an "inline proposals" field to Commit that lets the committer sen= d >>> proposals with a commit >>> >>> Two remaining worries here: >>> >>> - Validation: You want it to be the case that an ExternalInitSecret is >>> only present for a Commit signed by a new joiner. So some that informa= tion >>> will have to be passed from MLSPlaintext validation to Commit processin= g. >>> Or maybe we don't care about that restriction? It seems like a member >>> sending ExternalInitSecret should at least be SHOULD NOT, but maybe it'= s >>> not bad enough to absolutely forbid / have hard checks against. >>> >>> >>> Good question. I guess you want to detect early on if it is an External >>> Commit or an internal one, perhaps also to block External Commits by >>> policy. Indeed only the signature and sender type would reveal that. >>> Should internal Commits be allowed to have a ExternalInitSecret proposa= l >>> that then just gets ignored? I don=E2=80=99t have strong feelings about= it, but I=E2=80=99m >>> leaning towards the safe approach of saying it MUST not. >>> >>> >>> - Complexity: MLSPlaintext signature validation has to find a key to >>> verify the signature. I guess in this case, it should take the one for= the >>> Committer (Commit.update_path.leaf_key_package.public_key), but it shou= ld >>> also be the case that that key was added to the group with this Commit.= In >>> any case, this probably calls for a new sender type. >>> >>> Maybe these can both be solved with a flag passed into Commit processin= g: >>> >>> if (external_commit) { >>> // verify that there is an Add corresponding to >>> update_path.leaf_key_package >>> } else { >>> // verify that ExternalInitSecret is not present >>> } >>> >>> >>> I=E2=80=99m thinking that the MLSPlaintext framing the External Commit = will >>> reference a previously empty leave (namely the left most empty leave in= the >>> tree). Normally clients would look up the leave to verify a signature, = but >>> in this case it=E2=80=99s an indication that it is an External Commit. = Instead, >>> clients have to parse the list of Add Proposal the precede the Commit t= o >>> determine who the signer/sender is. Lastly the ExternalInitSecret Propo= sal >>> MUST also be there. >>> >>> As for the sender type, couldn=E2=80=99t we use new_member here? Both f= or the >>> Add Proposal and the Commit? >>> >>> >>> Even if so, that logic should get specified in the commit processing >>> section of the spec. >>> >>> >>> I agree that this should be written up in detailed steps to avoid any >>> confusion. >>> >>> Raphael >>> >>> >>> --RLB >>> >>> >>> On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert >> 40wire.com@dmarc.ietf.org> wrote: >>> >>>> I think that=E2=80=99s exactly the motivation we need for inline propo= sals, >>>> this surplus of signatures is not specific to this use case! >>>> >>>> Raphael >>>> >>>> > On 7 Oct 2020, at 13:27, Joel Alwen wrote: >>>> > >>>> > On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>>> >> Assume for the moment that we are not going to do the above >>>> asymmetric >>>> >> calculation for every commit. Then we need some extra, optional >>>> syntax to >>>> >> carry `enc`, either as an optional field on Commit or as a new >>>> Proposal, >>>> >> which is the agreed mechanism for extending Commits. (If we do it >>>> every >>>> >> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >>>> assume a >>>> >> new Proposal, say ExternalInitSecret. >>>> > Isn't it a bit redundant to have the External party prepare a full >>>> > (ExternInitSecret) proposal packet only to then immediately commit t= o >>>> it? That >>>> > means a full extra frame of bandwidth, an extra signature for the >>>> external party >>>> > and an extra sig verification for group members. >>>> > >>>> > I'm wondering what the motivation is for making this an explicit >>>> proposal >>>> > instead of, say, a second mode for commits. (E.g. a commit uses >>>> init_secret[n] >>>> > iff no kem_output field is included in the commit packet. Otherwise >>>> it uses the >>>> > "external_init_secret" computed as Richard described.) >>>> > >>>> > ATM I can't think of a scenario where we wouldnt want the external >>>> committer to >>>> > also be the one creating the ExternalInitSecret proposal and >>>> immediatly >>>> > committing to it... >>>> > >>>> > - Jo=C3=ABl >>>> > >>>> > >>>> > On 07/10/2020 12:36, Raphael Robert wrote: >>>> >> Thanks Richard for looking at all aspects in detail! >>>> >> >>>> >> I thought about these things as well and will comment inline: >>>> >> >>>> >>> On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>>> >>> >>>> >>> Hey all, >>>> >>> >>>> >>> I wanted to send some thoughts on how to implement external commit= , >>>> as a >>>> >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the >>>> proposal >>>> >>> is: >>>> >>> >>>> >>> - Rather than re-using Proposal/Commit, we should make a new >>>> ExternalCommit >>>> >>> message, parallel to Proposal/Commit >>>> >> >>>> >> I think we are better off with re-using the current Commit syntax >>>> and I=E2=80=99ll >>>> >> explain why further below. >>>> >> >>>> >>> - We should also define a syntax for telling the joiner the >>>> requisite >>>> >>> information about the group >>>> >>> >>>> >>> # HPKE-based init secret >>>> >>> >>>> >>> The concept here is as follows: >>>> >>> >>>> >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key >>>> schedule for >>>> >>> each epoch - The public key `pkG` of that key pair is published >>>> along with >>>> >>> with other group metadata - The joiner calls SetupBaseS(pkG, >>>> >>> some_public_group_context) to get an encapsulated key `enc` and an >>>> HPKE >>>> >>> context `ctx` - The joiner sends the encapsulated key to the group >>>> with >>>> >>> their external commit - The members of the group call >>>> SetupBaseS(enc, skG, >>>> >>> some_public_group_context) to get an equivalent HPKE context `ctx`= - >>>> >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to >>>> derive >>>> >>> the init secret >>>> >>> >>>> >>> So there are two syntactic requirements: >>>> >>> >>>> >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the >>>> encapsulated key >>>> >>> `enc` to the group >>>> >> >>>> >> From the discussion at the interim, I think there is consensus abou= t >>>> this >>>> >> part, we just need to add that to the PR. >>>> >> >>>> >>> >>>> >>> >>>> >>> # What Proposals? >>>> >>> >>>> >>> The current PR correctly requires that the external Commit MUST >>>> cover an >>>> >>> Add proposal for the new member. It does not forbid the Commit >>>> covering >>>> >>> *other* proposals. It seems like it might be useful in a couple o= f >>>> cases >>>> >>> to keep that option open: >>>> >> * Including PSK proposals for additional >>>> >>> authentication when joining * Including a Remove proposal for your >>>> prior >>>> >>> appearance when re-joining >>>> >>> >>>> >>> The only current proposal that would be nonsensical is an Update. >>>> >>> >>>> >>> Whether we do this has some impact on the syntax, as discussed >>>> below. >>>> >> >>>> >> While that is not very explicit in the current PR, my approach was >>>> the >>>> >> following: >>>> >> >>>> >> All Proposals should be allowed in an external Commit: >>>> >> >>>> >> - Adds: The joiner (new member) could right away add more members, >>>> or Commit >>>> >> to already existing Add Proposals if those are accessible. - >>>> Removes: The >>>> >> joiner can remove prior appearances of itself (like you pointed out= ) >>>> or >>>> >> Commit to already existing Remove Proposals. - Updates: The joiner >>>> should of >>>> >> course not issue own Updates and Commit to them, but that is alread= y >>>> the case >>>> >> for internal Commits. The joiner can Commit to already existing >>>> Update >>>> >> Proposals from other members. >>>> >> >>>> >> Whether all of the above is allowed should only be governed by the >>>> policy for >>>> >> a group, nothing else. As a reminder: all clients MUST have the sam= e >>>> policy >>>> >> for a certain group in order ta validate/refute Proposals and >>>> Commits. >>>> >> >>>> >> This pretty much motivates my idea for fully re-using the existing >>>> Commit >>>> >> syntax and only introduce the new ExternalInitSecret Proposal. >>>> >> >>>> >>> >>>> >>> >>>> >>> # External commit syntax: Separate or Together >>>> >>> >>>> >>> Assume for the moment that we are not going to do the above >>>> asymmetric >>>> >>> calculation for every commit. Then we need some extra, optional >>>> syntax to >>>> >>> carry `enc`, either as an optional field on Commit or as a new >>>> Proposal, >>>> >>> which is the agreed mechanism for extending Commits. (If we do it >>>> every >>>> >>> time, we can just make this part of Commit.) In the below, I=E2= =80=99ll >>>> assume a >>>> >>> new Proposal, say ExternalInitSecret. >>>> >>> >>>> >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >>>> >> >>>> >> This is exactly the Proposal we need. >>>> >> >>>> >>> >>>> >>> Given the requirement for an Add proposal, the joiner now has to >>>> send a >>>> >>> =E2=80=9Cflight of messages=E2=80=9D: >>>> >>> >>>> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >>>> >> >>>> >> I see some more nuance here. The first Add Proposal does not have t= o >>>> be >>>> >> issued by the new joiner, it could very well be an external >>>> Proposal. The >>>> >> scenario I had in mind here is the following: >>>> >> >>>> >> A server issues an external Add Proposal for a group. The following >>>> things >>>> >> can happen: >>>> >> >>>> >> a) Ideal scenario: >>>> >> >>>> >> - A member of the group comes online, validates the Add Proposal >>>> according to >>>> >> the policy and references it in an internal Commit (no External >>>> Commit >>>> >> needed) and sends a Welcome message to the new member >>>> >> >>>> >> b) Equally ideal scenario: >>>> >> >>>> >> - The new joiner comes online before anyone else, has access to the >>>> public >>>> >> group data but does not need to communicate with the group. Nothing >>>> happens. >>>> >> >>>> >> c) Emergency scenario: >>>> >> >>>> >> - The new joiner comes online before anyone else and needs to >>>> urgently send a >>>> >> message to the group. The new joiner creates the ExternalInitSecret >>>> Proposal >>>> >> and the Commit and sends both to group. >>>> >> >>>> >>> >>>> >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit h= eavyweight, since >>>> each of >>>> >>> these is signed separately. It=E2=80=99s duplicative, since the K= eyPackage >>>> in the >>>> >>> Add is immediately overwritten by the (necessarily different) KP i= n >>>> the >>>> >>> Commit. And you have potential fate-sharing issues, since all >>>> three need >>>> >>> to succeed or fail. >>>> >>> >>>> >>> You could also envision a Together Option, where we define another >>>> >>> top-level content type (parallel to Proposal and Commit) for this >>>> purpose: >>>> >>> >>>> >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } >>>> ExternalCommit; >>>> >>> >>>> >>> That would avoid all of the challenges above, but it optimizes out >>>> all of >>>> >>> the flexibility to include other proposals. So maybe it=E2=80=99s= worth >>>> >>> considering an Extensible Together Option, where we can put extra >>>> proposals >>>> >>> into an ExternalCommit >>>> >>> >>>> >>> struct { Proposal proposals<0..2^32-1>; opaque >>>> kem_output<0..2^16-1>; >>>> >>> UpdatePath path; } ExternalCommit; >>>> >>> >>>> >>> Personally, I kind of like the Flexible Together Option, since it >>>> provides >>>> >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been >>>> wondering if we >>>> >>> should allow inline proposals in Commit for a while, along just >>>> these >>>> >>> lines. If we do this option, we should probably back-port it to >>>> Commit as >>>> >>> well. >>>> >>> >>>> >> >>>> >> As mentioned above, I=E2=80=99m all for re-using the existing Commi= t syntax >>>> because >>>> >> of clarity, simplicity and flexibility. >>>> >> >>>> >> I do agree that the amount of signatures is sub-optimal, and this i= s >>>> >> something that also occurs in other situations. For example, when a >>>> member >>>> >> wants to add n new members at once to the group, it needs to comput= e >>>> n+1 >>>> >> signatures for that. You mention the idea of inline proposals: Woul= d >>>> that be >>>> >> a proposal that doesn=E2=80=99t have a signature, but still all oth= er >>>> information? If >>>> >> so, I think it would be worthwhile looking at that separately, >>>> because as you >>>> >> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for >>>> >> exploring that idea further. >>>> >> >>>> >>> >>>> >>> # Syntax for what the Joiner Needs >>>> >>> >>>> >>> The PR notes that the joiner needs to know a bunch of information >>>> about the >>>> >>> group in order to make a well-formed ExternalCommit. In earlier >>>> iterations >>>> >>> of this style of join, we had a GroupInitKey that carried the righ= t >>>> >>> information. Following that pattern here, we get something like th= e >>>> >>> following: >>>> >>> >>>> >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 >>>> epoch; >>>> >>> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>= ; >>>> >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >>>> >> >>>> >> This is what the PR currently says, except that the PR used >>>> GroupContext and >>>> >> has the full public tree. I agree that the tree hash should be >>>> enough and >>>> >> I=E2=80=99ll change the PR accordingly. >>>> >> >>>> >>> >>>> >>> Note that this object is essentially the same as a GroupInfo >>>> object. The >>>> >>> only things it is missing are interim_transcript_hash and >>>> signature, both >>>> >>> of which might be useful. So maybe all we need to do here is say >>>> that >>>> >>> clients can publish GroupInfo unencrypted if they want to enable >>>> self-adds, >>>> >>> in addition to distributing it in encrypted form in Welcome. >>>> >> >>>> >> While the two are awfully similar, the signature on GroupInfo is no= t >>>> required >>>> >> here and might have undesired effects w.r.t deniability if this is >>>> publicly >>>> >> accessible. The other reason for not wanting the signature is that >>>> it would >>>> >> be an additional signature to compute with every Commit, making the= m >>>> even >>>> >> more expensive. I propose to keep the struct as-is. >>>> >> >>>> >>> >>>> >>> In any case, it seems like it would be useful to have some syntax >>>> for >>>> >>> this. >>>> >>> >>>> >>> Hope this helps, =E2=80=94RLB >>>> >> >>>> >> >>>> >> TL;DR: >>>> >> >>>> >> I propose the following: >>>> >> >>>> >> - Keep the current Commit syntax - Allow all kinds of Proposals for >>>> External >>>> >> Commits, same as with internal Commits - Do the HPKE-based init >>>> secret for >>>> >> External Commits - Introduce the ExternalInitSecret Proposal and >>>> make it >>>> >> mandatory for External Commits - Explore the idea of inline proposa= ls >>>> >> separately - Do not re-use signed GroupInfo struct and keep the >>>> adjusted >>>> >> ExternalCommitInfo instead >>>> >> >>>> >> Raphael >>>> >> >>>> >>> _______________________________________________ MLS mailing list >>>> >>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>>> >> >>>> >> _______________________________________________ MLS mailing list >>>> >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>>> >> >>>> > >>>> > _______________________________________________ >>>> > MLS mailing list >>>> > MLS@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/mls >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > --000000000000e02b3005b169c5df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In case it helps folks grok this change: I implemente= d this PR in the C++ stack that Suhas and I have been working on, as part o= f prototyping out external Commit:


Raphael: To your equi= valence point, the above code does what I think is the opposite of what you= propose -- inline proposals fate share with the Commit they're attache= d to.=C2=A0 If the Commit fails, then the proposals inlined in it are not c= ached.=C2=A0 Personally, I think that's probably the right outcome, sin= ce otherwise you end up with a Commit that can partly fail, in the sense th= at it was not applied, but still left some proposals cached.=C2=A0 Cleaner = to have the Commit and all inline proposals discarded if the Commit or any = inline proposal is invalid.

--Richard

On Fri, Oct 9, 2020 at 1:25 AM Raphael Robert <raphael@wire.com> wrote:
I thi= nk this is a good start and a useful feature in general!

I think there is is one more nuance when it comes to processing and valida= ting Commits:

In the current state of the draft cl= ients send Proposals followed by one Commit. Proposals might be valid or no= t and clients have to validate them at the latest when they process the Com= mit. At that point they will reject the Commit if it contains any invalid P= roposal. They will however still keep the Proposals as such around and wait= for the next Commit or issue a Commit themselves.

With inline Proposals this is no longer true. When clients reject a Commit= because of an invalid inline proposal, that proposal is effectively lost. = Clients could of course extract the inline proposals and either re-use them= in their own Commit or frame them as standalone proposals. We should think= about whether we want that and what we should specify here.

On 8 Oct 2020, at 17:47, Richard Barnes= <rlb@ipv.sx> wro= te:

(Changing subject line because chan= ging subject)

Since there seems to be some energy = around inline proposals regardless of ExternalCommit, I made a quick PR:


The interesting nuance here is that the Commit sp= ecifies an order in which Proposals are applied.=C2=A0 So there are basical= ly two design options here:

1. Include proposals by value= , and reference them by hash in the order specification
2. Allow = the order specification to reference proposals by value or by hash

I went with the latter approach, because it seemed slightl= y simpler to me.=C2=A0 But if folks feel strongly, we could go the other wa= y as well.

I=E2=80=99m not sur= e I understand how that=E2=80=99s reflected in the current PR. Regardless, = I think that inline and standalone proposals should be treated equally from= a semantic point of view.


--Richard


On Wed= , Oct 7, 2020 at 8:45 PM Brendan McMillion <brendan@cloudflare.com> wrote:
I kn= ow you're all tired of hearing me say this, but I still feel strongly w= e should always use asymmetric Commits. If MLS is otherwise secure, then th= ere's simply no reason not to, and it simplifies implementations. There= wouldn't have to be a new ExternalInitSecret proposal, validation logi= c wouldn't get substantially more complicated, and there wouldn't b= e this worry about bundling several proposals. Otoh, I think allowing inlin= e proposals in Commits is a good idea but it's orthogonal to asymmetric= Commits.

On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert <raphael=3D40wire.com@dma= rc.ietf.org> wrote:
Good points again!

On 7 Oct 2020, at 17:38, Richard Barnes <rlb@ipv.sx> wrote:

OK, how about the following proposal (heh):

- Add ExternalInitSecret proposal
- Add an "inline proposal= s" field to Commit that lets the committer send proposals with a commi= t

Two remaining worries here:

<= /div>
- Validation: You want it to be the case that an ExternalInitSecr= et is only present for a Commit signed by a new joiner.=C2=A0 So some that = information will have to be passed from MLSPlaintext validation to Commit p= rocessing.=C2=A0 Or maybe we don't care about that restriction?=C2=A0 I= t seems like a member sending ExternalInitSecret should at least be SHOULD = NOT, but maybe it's not bad enough to absolutely forbid / have hard che= cks against.

Good question= . I guess you want to detect early on if it is an External Commit or an int= ernal one, perhaps also to block External Commits by policy. Indeed only th= e signature and sender type would reveal that.=C2=A0
Should inter= nal Commits be allowed to have a ExternalInitSecret proposal that then just= gets ignored? I don=E2=80=99t have strong feelings about it, but I=E2=80= =99m leaning towards the safe approach of saying it MUST not.

- Comp= lexity: MLSPlaintext signature validation has to find a key to verify the s= ignature.=C2=A0 I guess in this case, it should take the one for the Commit= ter (Commit.update_path.leaf_key_package.public_key), but it should also be= the case that that key was added to the group with this Commit.=C2=A0 In a= ny case, this probably calls for a new sender type.

Maybe these can both be solved with a flag passed into Commit process= ing:

if (external_commit) {
=C2=A0 // ve= rify that there is an Add corresponding to update_path.leaf_key_package
} else {
=C2=A0 // verify that ExternalInitSecret is n= ot present
}

I= =E2=80=99m thinking that the MLSPlaintext framing the External Commit will = reference a previously empty leave (namely the left most empty leave in the= tree). Normally clients would look up the leave to verify a signature, but= in this case it=E2=80=99s an indication that it is an External Commit. Ins= tead, clients have to parse the list of Add Proposal the precede the Commit= to determine who the signer/sender is. Lastly the ExternalInitSecret Propo= sal MUST also be there.

As for the sender type, co= uldn=E2=80=99t we use new_member here? Both for the Add Proposal and the Co= mmit?


Even if so, that logic should get specified in the = commit processing section of the spec.
<= br>
I agree that this should be written up in detailed steps to avoid = any confusion.

Raphael


--RLB
=

On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert <raphael=3D40wire.com@dmarc.= ietf.org> wrote:
I think that=E2=80=99s exactly the motivation we need for inline pr= oposals, this surplus of signatures is not specific to this use case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>> Assume for the moment that we are not going to do the above asymme= tric
>> calculation for every commit.=C2=A0 Then we need some extra, optio= nal syntax=C2=A0 to
>> carry `enc`, either as an optional field on Commit or as a new Pro= posal,
>> which is the agreed mechanism for extending Commits.=C2=A0 (If we = do it every
>> time, we can just make this part of Commit.)=C2=A0 In the below, I= =E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a full=
> (ExternInitSecret) proposal packet only to then immediately commit to = it? That
> means a full extra frame of bandwidth, an extra signature for the exte= rnal party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit p= roposal
> instead of, say, a second mode for commits. (E.g. a commit uses init_s= ecret[n]
> iff no kem_output field is included in the commit packet. Otherwise it= uses the
> "external_init_secret" computed as Richard described.)
>
> ATM I can't think of a scenario where we wouldnt want the external= committer to
> also be the one creating the ExternalInitSecret proposal and immediatl= y
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external co= mmit, as a
>>> prelude to a PR.=C2=A0 This is a little bit of an essay, so tl= ;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a new E= xternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the re= quisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for
>>> each epoch - The public key `pkG` of that key pair is publishe= d along with
>>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> some_public_group_context) to get an encapsulated key `enc` an= d an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to the g= roup with
>>> their external commit - The members of the group call SetupBas= eS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE context `= ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)= ` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending = the encapsulated key
>>> `enc` to the group
>>
>> From the discussion at the interim, I think there is consensus abo= ut this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit MUS= T cover an
>>> Add proposal for the new member.=C2=A0 =C2=A0It does not forbi= d the Commit covering
>>> *other* proposals.=C2=A0 It seems like it might be useful in a= couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal for = your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an Upda= te.
>>>
>>> Whether we do this has some impact on the syntax, as discussed= below.
>>
>> While that is not very explicit in the current PR, my approach was= the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more members,= or Commit
>> to already existing Add Proposals if those are accessible. - Remov= es: The
>> joiner can remove prior appearances of itself (like you pointed ou= t) or
>> Commit to already existing Remove Proposals. - Updates: The joiner= should of
>> course not issue own Updates and Commit to them, but that is alrea= dy the case
>> for internal Commits. The joiner can Commit to already existing Up= date
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by the= policy for
>> a group, nothing else. As a reminder: all clients MUST have the sa= me policy
>> for a certain group in order ta validate/refute Proposals and Comm= its.
>>
>> This pretty much motivates my idea for fully re-using the existing= Commit
>> syntax and only introduce the new ExternalInitSecret Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
>>>
>>> Assume for the moment that we are not going to do the above as= ymmetric
>>> calculation for every commit.=C2=A0 Then we need some extra, o= ptional syntax=C2=A0 to
>>> carry `enc`, either as an optional field on Commit or as a new= Proposal,
>>> which is the agreed mechanism for extending Commits.=C2=A0 (If= we do it every
>>> time, we can just make this part of Commit.)=C2=A0 In the belo= w, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSec= ret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now has = to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not have = to be
>> issued by the new joiner, it could very well be an external Propos= al. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The followin= g things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add Proposal a= ccording to
>> the policy and references it in an internal Commit (no External Co= mmit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to th= e public
>> group data but does not need to communicate with the group. Nothin= g happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to urge= ntly send a
>> message to the group. The new joiner creates the ExternalInitSecre= t Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.=C2=A0 It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.=C2=A0 It=E2=80=99s duplicative, si= nce the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily different) = KP in the
>>> Commit.=C2=A0 And you have potential fate-sharing issues, sinc= e all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define ano= ther
>>> top-level content type (parallel to Proposal and Commit) for t= his purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; = } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it optimizes= out all of
>>> the flexibility to include other proposals.=C2=A0 So maybe it= =E2=80=99s worth
>>> considering an Extensible Together Option, where we can put ex= tra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque kem_outpu= t<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, since= it provides
>>> simplicity and extensibility.=C2=A0 And to be honest, I=E2=80= =99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along jus= t these
>>> lines.=C2=A0 If we do this option, we should probably back-por= t it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing Comm= it syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and this = is
>> something that also occurs in other situations. For example, when = a member
>> wants to add n new members at once to the group, it needs to compu= te n+1
>> signatures for that. You mention the idea of inline proposals: Wou= ld that be
>> a proposal that doesn=E2=80=99t have a signature, but still all ot= her information? If
>> so, I think it would be worthwhile looking at that separately, bec= ause as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of informat= ion about the
>>> group in order to make a well-formed ExternalCommit.=C2=A0 In = earlier iterations
>>> of this style of join, we had a GroupInitKey that carried the = right
>>> information. Following that pattern here, we get something lik= e the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque group_id<0..255&g= t;; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque confirmed_transcript_ha= sh<0..255>;
>>> Extension extensions<0..2^32-1>; } GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used GroupC= ontext and
>> has the full public tree. I agree that the tree hash should be eno= ugh and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a GroupInfo o= bject.=C2=A0 The
>>> only things it is missing are interim_transcript_hash and sign= ature, both
>>> of which might be useful.=C2=A0 So maybe all we need to do her= e is say that
>>> clients can publish GroupInfo unencrypted if they want to enab= le self-adds,
>>> in addition to distributing it in encrypted form in Welcome. >>
>> While the two are awfully similar, the signature on GroupInfo is n= ot required
>> here and might have undesired effects w.r.t deniability if this is= publicly
>> accessible. The other reason for not wanting the signature is that= it would
>> be an additional signature to compute with every Commit, making th= em even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some syn= tax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals fo= r External
>> Commits, same as with internal Commits - Do the HPKE-based init se= cret for
>> External Commits - Introduce the ExternalInitSecret Proposal and m= ake it
>> mandatory for External Commits - Explore the idea of inline propos= als
>> separately - Do not re-use signed GroupInfo struct and keep the ad= justed
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing li= st
>>> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing list <= br> >> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

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

<= /div> --000000000000e02b3005b169c5df-- From nobody Sun Oct 11 12:09:23 2020 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 D18503A00F7 for ; Sun, 11 Oct 2020 12:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 169Y9uEUpM_5 for ; Sun, 11 Oct 2020 12:09:19 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 DB10E3A0100 for ; Sun, 11 Oct 2020 12:09:18 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 140so14176623qko.2 for ; Sun, 11 Oct 2020 12:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2nKYRRTE7NSj8EQT2obpwMYfcLZL8M9+bW6F+dKB/Ic=; b=mrp1XD3nAsQ9ze4hIraJjzapj1FHWn7H5EIjQxFZyyi/y3GRop/nFkOFXDsj8K6/Ki 1KO4KimgyQPqHQCV5GBWuXdmgHKB8NqtHlTP/G2bhhA9oK0fzfUi3faO4xvXckEsB8ty epHJOO9ZVxVYrogocvh1zEwh1FLfs2lBnKNFAfPpYMWHnGpXREDQRYRkiZ5GilRImhm4 WN8syddeYxdYj04yYfZWuYJm2aMaTDa3PtLBh9C/6rty47xDF9A4Wb9iicvOSrz6cnLc cPs1JBlJwrsFF9KnQ4aOBfa+T7+L276NCX5ckDk8ahJNzOIrO/IFminOaD3Q1dSbb/r8 +K0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2nKYRRTE7NSj8EQT2obpwMYfcLZL8M9+bW6F+dKB/Ic=; b=KyjljTNAttePnRSywPBrCSYznVbiofbD3xvx2Xs5JvXZE63Azj6i4EWLh12KFTDv7T ypOVqwKvKQfgs9Qw2JnoYYpHIID1nL+zcUCe+o55MAZBpGz7RQ9VYhJW0WHuFG4Ws9gg 83HVWZ30gTbCuo/+xafejNGRzXj/5UgReYgM4PI2PYWYMTVubeH4AdQtb5kwhDwICu/c yJMLDVFJQ5oT0VqhgWWL2uDzylORHSL/0rjTlSjMVko3O3NZtw2I1lAx5mrL51137j3+ G/g3LfrjuZ2882R4gUG6cS0s1Z309Lm4rhdmrXb9MCgSMtbUe2AgHFAjpQi57WfYjJI2 YF2w== X-Gm-Message-State: AOAM53016NAECJ09/qrHK0cgBmAE+77pQT83jech7dqpYgJqoTeSoopm BNPv65xF0LhYxDfja7xqBG66sKnjW5Bct/zzqCcwsw== X-Google-Smtp-Source: ABdhPJwCg293NApJceaSVOGIEqHNeRdKLNJl42kxsNx6NDPvd5Ks4jkYkeW2LvmjunRVavXRpvh+Xet5AcKaSpBQMnU= X-Received: by 2002:a05:620a:15b6:: with SMTP id f22mr7001074qkk.490.1602443357555; Sun, 11 Oct 2020 12:09:17 -0700 (PDT) MIME-Version: 1.0 References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> In-Reply-To: From: Richard Barnes Date: Sun, 11 Oct 2020 15:09:02 -0400 Message-ID: To: Brendan McMillion Cc: Raphael Robert , Messaging Layer Security WG , Joel Alwen Content-Type: multipart/alternative; boundary="00000000000019a23905b169eb0e" Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 19:09:23 -0000 --00000000000019a23905b169eb0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To help flush out additional details needed here, I went ahead and prototyped out external commits in mlspp: https://github.com/cisco/mlspp/pull/118 As outlined in the PR, there are few additional things we need in the spec PR: 1. The ExternalInit proposal type and its handling This is largely just what was sketched up-thread. 2. Defining the minimal requirements for an external Commit We probably need a section describing some special additional constraints that apply to external Commits, beyond general Commits: - It MUST cover an Add proposal for the committer - It MUST include an inline an ExternalInit proposal - It MAY cover other proposals - Commit.path MUST be populated 3. A new SenderType value for external commits and signature validation logic The above PR defines a new SenderType value "external_joiner", and when an MLSPlaintext with that sender type is encountered, uses the public key from Commit.path.leaf_key_package. (The latter so that it doesn't have to look up an Add proposal within the Commit.) I think that validation strategy is probably the right balance of simplicity and correctness. As far as the SenderType, we could probably re-use the "new_member" type, with the understanding that: - new_member + Proposal =3D> Proposal MUST be an Add, and the signature mus= t validate with the public key from Add.key_package - new_member + Commit =3D> Commit MUST be an external Commit (with Add and ExternalInit proposals), and the signature must validate with the public key from Commit.path.leaf_key_package But if we can nail those down, I think we have a tool here that's pretty powerful, and not all that complicated to implement. --Richard On Wed, Oct 7, 2020 at 8:45 PM Brendan McMillion wrote: > I know you're all tired of hearing me say this, but I still feel strongly > we should always use asymmetric Commits. If MLS is otherwise secure, then > there's simply no reason not to, and it simplifies implementations. There > wouldn't have to be a new ExternalInitSecret proposal, validation logic > wouldn't get substantially more complicated, and there wouldn't be this > worry about bundling several proposals. Otoh, I think allowing inline > proposals in Commits is a good idea but it's orthogonal to asymmetric > Commits. > > On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert 40wire.com@dmarc.ietf.org> wrote: > >> Good points again! >> >> On 7 Oct 2020, at 17:38, Richard Barnes wrote: >> >> OK, how about the following proposal (heh): >> >> - Add ExternalInitSecret proposal >> - Add an "inline proposals" field to Commit that lets the committer send >> proposals with a commit >> >> Two remaining worries here: >> >> - Validation: You want it to be the case that an ExternalInitSecret is >> only present for a Commit signed by a new joiner. So some that informat= ion >> will have to be passed from MLSPlaintext validation to Commit processing= . >> Or maybe we don't care about that restriction? It seems like a member >> sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's >> not bad enough to absolutely forbid / have hard checks against. >> >> >> Good question. I guess you want to detect early on if it is an External >> Commit or an internal one, perhaps also to block External Commits by >> policy. Indeed only the signature and sender type would reveal that. >> Should internal Commits be allowed to have a ExternalInitSecret proposal >> that then just gets ignored? I don=E2=80=99t have strong feelings about = it, but I=E2=80=99m >> leaning towards the safe approach of saying it MUST not. >> >> >> - Complexity: MLSPlaintext signature validation has to find a key to >> verify the signature. I guess in this case, it should take the one for = the >> Committer (Commit.update_path.leaf_key_package.public_key), but it shoul= d >> also be the case that that key was added to the group with this Commit. = In >> any case, this probably calls for a new sender type. >> >> Maybe these can both be solved with a flag passed into Commit processing= : >> >> if (external_commit) { >> // verify that there is an Add corresponding to >> update_path.leaf_key_package >> } else { >> // verify that ExternalInitSecret is not present >> } >> >> >> I=E2=80=99m thinking that the MLSPlaintext framing the External Commit w= ill >> reference a previously empty leave (namely the left most empty leave in = the >> tree). Normally clients would look up the leave to verify a signature, b= ut >> in this case it=E2=80=99s an indication that it is an External Commit. I= nstead, >> clients have to parse the list of Add Proposal the precede the Commit to >> determine who the signer/sender is. Lastly the ExternalInitSecret Propos= al >> MUST also be there. >> >> As for the sender type, couldn=E2=80=99t we use new_member here? Both fo= r the Add >> Proposal and the Commit? >> >> >> Even if so, that logic should get specified in the commit processing >> section of the spec. >> >> >> I agree that this should be written up in detailed steps to avoid any >> confusion. >> >> Raphael >> >> >> --RLB >> >> >> On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert > 40wire.com@dmarc.ietf.org> wrote: >> >>> I think that=E2=80=99s exactly the motivation we need for inline propos= als, this >>> surplus of signatures is not specific to this use case! >>> >>> Raphael >>> >>> > On 7 Oct 2020, at 13:27, Joel Alwen wrote: >>> > >>> > On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>> >> Assume for the moment that we are not going to do the above asymmetr= ic >>> >> calculation for every commit. Then we need some extra, optional >>> syntax to >>> >> carry `enc`, either as an optional field on Commit or as a new >>> Proposal, >>> >> which is the agreed mechanism for extending Commits. (If we do it >>> every >>> >> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >>> assume a >>> >> new Proposal, say ExternalInitSecret. >>> > Isn't it a bit redundant to have the External party prepare a full >>> > (ExternInitSecret) proposal packet only to then immediately commit to >>> it? That >>> > means a full extra frame of bandwidth, an extra signature for the >>> external party >>> > and an extra sig verification for group members. >>> > >>> > I'm wondering what the motivation is for making this an explicit >>> proposal >>> > instead of, say, a second mode for commits. (E.g. a commit uses >>> init_secret[n] >>> > iff no kem_output field is included in the commit packet. Otherwise i= t >>> uses the >>> > "external_init_secret" computed as Richard described.) >>> > >>> > ATM I can't think of a scenario where we wouldnt want the external >>> committer to >>> > also be the one creating the ExternalInitSecret proposal and immediat= ly >>> > committing to it... >>> > >>> > - Jo=C3=ABl >>> > >>> > >>> > On 07/10/2020 12:36, Raphael Robert wrote: >>> >> Thanks Richard for looking at all aspects in detail! >>> >> >>> >> I thought about these things as well and will comment inline: >>> >> >>> >>> On 7 Oct 2020, at 03:20, Richard Barnes wrote: >>> >>> >>> >>> Hey all, >>> >>> >>> >>> I wanted to send some thoughts on how to implement external commit, >>> as a >>> >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the >>> proposal >>> >>> is: >>> >>> >>> >>> - Rather than re-using Proposal/Commit, we should make a new >>> ExternalCommit >>> >>> message, parallel to Proposal/Commit >>> >> >>> >> I think we are better off with re-using the current Commit syntax an= d >>> I=E2=80=99ll >>> >> explain why further below. >>> >> >>> >>> - We should also define a syntax for telling the joiner the requisi= te >>> >>> information about the group >>> >>> >>> >>> # HPKE-based init secret >>> >>> >>> >>> The concept here is as follows: >>> >>> >>> >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key >>> schedule for >>> >>> each epoch - The public key `pkG` of that key pair is published >>> along with >>> >>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> >>> some_public_group_context) to get an encapsulated key `enc` and an >>> HPKE >>> >>> context `ctx` - The joiner sends the encapsulated key to the group >>> with >>> >>> their external commit - The members of the group call >>> SetupBaseS(enc, skG, >>> >>> some_public_group_context) to get an equivalent HPKE context `ctx` = - >>> >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` to >>> derive >>> >>> the init secret >>> >>> >>> >>> So there are two syntactic requirements: >>> >>> >>> >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the >>> encapsulated key >>> >>> `enc` to the group >>> >> >>> >> From the discussion at the interim, I think there is consensus about >>> this >>> >> part, we just need to add that to the PR. >>> >> >>> >>> >>> >>> >>> >>> # What Proposals? >>> >>> >>> >>> The current PR correctly requires that the external Commit MUST >>> cover an >>> >>> Add proposal for the new member. It does not forbid the Commit >>> covering >>> >>> *other* proposals. It seems like it might be useful in a couple of >>> cases >>> >>> to keep that option open: >>> >> * Including PSK proposals for additional >>> >>> authentication when joining * Including a Remove proposal for your >>> prior >>> >>> appearance when re-joining >>> >>> >>> >>> The only current proposal that would be nonsensical is an Update. >>> >>> >>> >>> Whether we do this has some impact on the syntax, as discussed belo= w. >>> >> >>> >> While that is not very explicit in the current PR, my approach was t= he >>> >> following: >>> >> >>> >> All Proposals should be allowed in an external Commit: >>> >> >>> >> - Adds: The joiner (new member) could right away add more members, o= r >>> Commit >>> >> to already existing Add Proposals if those are accessible. - Removes= : >>> The >>> >> joiner can remove prior appearances of itself (like you pointed out) >>> or >>> >> Commit to already existing Remove Proposals. - Updates: The joiner >>> should of >>> >> course not issue own Updates and Commit to them, but that is already >>> the case >>> >> for internal Commits. The joiner can Commit to already existing Upda= te >>> >> Proposals from other members. >>> >> >>> >> Whether all of the above is allowed should only be governed by the >>> policy for >>> >> a group, nothing else. As a reminder: all clients MUST have the same >>> policy >>> >> for a certain group in order ta validate/refute Proposals and Commit= s. >>> >> >>> >> This pretty much motivates my idea for fully re-using the existing >>> Commit >>> >> syntax and only introduce the new ExternalInitSecret Proposal. >>> >> >>> >>> >>> >>> >>> >>> # External commit syntax: Separate or Together >>> >>> >>> >>> Assume for the moment that we are not going to do the above >>> asymmetric >>> >>> calculation for every commit. Then we need some extra, optional >>> syntax to >>> >>> carry `enc`, either as an optional field on Commit or as a new >>> Proposal, >>> >>> which is the agreed mechanism for extending Commits. (If we do it >>> every >>> >>> time, we can just make this part of Commit.) In the below, I=E2=80= =99ll >>> assume a >>> >>> new Proposal, say ExternalInitSecret. >>> >>> >>> >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >>> >> >>> >> This is exactly the Proposal we need. >>> >> >>> >>> >>> >>> Given the requirement for an Add proposal, the joiner now has to >>> send a >>> >>> =E2=80=9Cflight of messages=E2=80=9D: >>> >>> >>> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >>> >> >>> >> I see some more nuance here. The first Add Proposal does not have to >>> be >>> >> issued by the new joiner, it could very well be an external Proposal= . >>> The >>> >> scenario I had in mind here is the following: >>> >> >>> >> A server issues an external Add Proposal for a group. The following >>> things >>> >> can happen: >>> >> >>> >> a) Ideal scenario: >>> >> >>> >> - A member of the group comes online, validates the Add Proposal >>> according to >>> >> the policy and references it in an internal Commit (no External Comm= it >>> >> needed) and sends a Welcome message to the new member >>> >> >>> >> b) Equally ideal scenario: >>> >> >>> >> - The new joiner comes online before anyone else, has access to the >>> public >>> >> group data but does not need to communicate with the group. Nothing >>> happens. >>> >> >>> >> c) Emergency scenario: >>> >> >>> >> - The new joiner comes online before anyone else and needs to >>> urgently send a >>> >> message to the group. The new joiner creates the ExternalInitSecret >>> Proposal >>> >> and the Commit and sends both to group. >>> >> >>> >>> >>> >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit he= avyweight, since >>> each of >>> >>> these is signed separately. It=E2=80=99s duplicative, since the Ke= yPackage >>> in the >>> >>> Add is immediately overwritten by the (necessarily different) KP in >>> the >>> >>> Commit. And you have potential fate-sharing issues, since all thre= e >>> need >>> >>> to succeed or fail. >>> >>> >>> >>> You could also envision a Together Option, where we define another >>> >>> top-level content type (parallel to Proposal and Commit) for this >>> purpose: >>> >>> >>> >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } >>> ExternalCommit; >>> >>> >>> >>> That would avoid all of the challenges above, but it optimizes out >>> all of >>> >>> the flexibility to include other proposals. So maybe it=E2=80=99s = worth >>> >>> considering an Extensible Together Option, where we can put extra >>> proposals >>> >>> into an ExternalCommit >>> >>> >>> >>> struct { Proposal proposals<0..2^32-1>; opaque >>> kem_output<0..2^16-1>; >>> >>> UpdatePath path; } ExternalCommit; >>> >>> >>> >>> Personally, I kind of like the Flexible Together Option, since it >>> provides >>> >>> simplicity and extensibility. And to be honest, I=E2=80=99ve been = wondering >>> if we >>> >>> should allow inline proposals in Commit for a while, along just the= se >>> >>> lines. If we do this option, we should probably back-port it to >>> Commit as >>> >>> well. >>> >>> >>> >> >>> >> As mentioned above, I=E2=80=99m all for re-using the existing Commit= syntax >>> because >>> >> of clarity, simplicity and flexibility. >>> >> >>> >> I do agree that the amount of signatures is sub-optimal, and this is >>> >> something that also occurs in other situations. For example, when a >>> member >>> >> wants to add n new members at once to the group, it needs to compute >>> n+1 >>> >> signatures for that. You mention the idea of inline proposals: Would >>> that be >>> >> a proposal that doesn=E2=80=99t have a signature, but still all othe= r >>> information? If >>> >> so, I think it would be worthwhile looking at that separately, >>> because as you >>> >> say, it could be back-ported to internal Commits as well. I=E2=80=99= m all for >>> >> exploring that idea further. >>> >> >>> >>> >>> >>> # Syntax for what the Joiner Needs >>> >>> >>> >>> The PR notes that the joiner needs to know a bunch of information >>> about the >>> >>> group in order to make a well-formed ExternalCommit. In earlier >>> iterations >>> >>> of this style of join, we had a GroupInitKey that carried the right >>> >>> information. Following that pattern here, we get something like the >>> >>> following: >>> >>> >>> >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 >>> epoch; >>> >>> opaque tree_hash<0..255>; opaque confirmed_transcript_hash<0..255>; >>> >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >>> >> >>> >> This is what the PR currently says, except that the PR used >>> GroupContext and >>> >> has the full public tree. I agree that the tree hash should be enoug= h >>> and >>> >> I=E2=80=99ll change the PR accordingly. >>> >> >>> >>> >>> >>> Note that this object is essentially the same as a GroupInfo >>> object. The >>> >>> only things it is missing are interim_transcript_hash and signature= , >>> both >>> >>> of which might be useful. So maybe all we need to do here is say >>> that >>> >>> clients can publish GroupInfo unencrypted if they want to enable >>> self-adds, >>> >>> in addition to distributing it in encrypted form in Welcome. >>> >> >>> >> While the two are awfully similar, the signature on GroupInfo is not >>> required >>> >> here and might have undesired effects w.r.t deniability if this is >>> publicly >>> >> accessible. The other reason for not wanting the signature is that i= t >>> would >>> >> be an additional signature to compute with every Commit, making them >>> even >>> >> more expensive. I propose to keep the struct as-is. >>> >> >>> >>> >>> >>> In any case, it seems like it would be useful to have some syntax f= or >>> >>> this. >>> >>> >>> >>> Hope this helps, =E2=80=94RLB >>> >> >>> >> >>> >> TL;DR: >>> >> >>> >> I propose the following: >>> >> >>> >> - Keep the current Commit syntax - Allow all kinds of Proposals for >>> External >>> >> Commits, same as with internal Commits - Do the HPKE-based init >>> secret for >>> >> External Commits - Introduce the ExternalInitSecret Proposal and mak= e >>> it >>> >> mandatory for External Commits - Explore the idea of inline proposal= s >>> >> separately - Do not re-use signed GroupInfo struct and keep the >>> adjusted >>> >> ExternalCommitInfo instead >>> >> >>> >> Raphael >>> >> >>> >>> _______________________________________________ MLS mailing list >>> >>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>> >> >>> >> _______________________________________________ MLS mailing list >>> >> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls >>> >> >>> > >>> > _______________________________________________ >>> > MLS mailing list >>> > MLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> 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 >> > --00000000000019a23905b169eb0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To help flush out additional details needed here, I w= ent ahead and prototyped out external commits in mlspp:


As outlined in the PR, = there are few additional things we need in the spec PR:

1. The ExternalInit proposal type and its handling
This= is largely just what was sketched up-thread.

= 2. Defining the minimal requirements for an external Commit
We pr= obably need a section describing some special additional constraints that a= pply to external Commits, beyond general Commits:
- It MUST c= over an Add proposal for the committer
- It MUST include an inlin= e an ExternalInit proposal
- It MAY cover other proposals
- Commit.path MUST be populated

3. A ne= w SenderType value for external commits and signature validation logic
<= /div>
The above PR defines a new SenderType value "external_joiner= ", and when an MLSPlaintext with that sender type is encountered, uses= the public key from Commit.path.leaf_key_package.=C2=A0 (The latter so tha= t it doesn't have to look up an Add proposal within the Commit.)=C2=A0 = I think that validation strategy is probably the right balance of simplicit= y and correctness.=C2=A0 As far as the SenderType, we could probably re-use= the "new_member" type, with the understanding that:
- new_member + Proposal =3D> Proposal MUST be an Add, and the signatur= e must validate with the public key from Add.key_package
- new_me= mber + Commit =3D> Commit MUST be an external Commit (with Add and Exter= nalInit proposals), and the signature must validate with the public key fro= m Commit.path.leaf_key_package

But if we can nail = those down, I think we have a tool here that's pretty powerful, and not= all that complicated to implement.

--Richard
<= /div>

On Wed, Oct 7, 2020 at 8:45 PM Brendan McMillion <brendan@cloudflare.com> wrote:
I know you&= #39;re all tired of hearing me say this, but I still feel strongly we shoul= d always use asymmetric Commits. If MLS is otherwise secure, then there'= ;s simply no reason not to, and it simplifies implementations. There wouldn= 't have to be a new ExternalInitSecret proposal, validation logic would= n't get substantially more complicated, and there wouldn't be this = worry about bundling several proposals. Otoh, I think allowing inline propo= sals in Commits is a good idea but it's orthogonal to asymmetric Commit= s.

On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert <raphael=3D40wire.com@dmarc.ie= tf.org> wrote:
Good points again!

On= 7 Oct 2020, at 17:38, Richard Barnes <rlb@ipv.sx> wrote:

OK, how about the following proposal (heh):

- Ad= d ExternalInitSecret proposal
- Add an "inline proposals&quo= t; field to Commit that lets the committer send proposals with a commit

Two remaining worries here:

=
- Validation: You want it to be the case that an ExternalInitSecret is= only present for a Commit signed by a new joiner.=C2=A0 So some that infor= mation will have to be passed from MLSPlaintext validation to Commit proces= sing.=C2=A0 Or maybe we don't care about that restriction?=C2=A0 It see= ms like a member sending ExternalInitSecret should at least be SHOULD NOT, = but maybe it's not bad enough to absolutely forbid / have hard checks a= gainst.

Good question. I g= uess you want to detect early on if it is an External Commit or an internal= one, perhaps also to block External Commits by policy. Indeed only the sig= nature and sender type would reveal that.=C2=A0
Should internal C= ommits be allowed to have a ExternalInitSecret proposal that then just gets= ignored? I don=E2=80=99t have strong feelings about it, but I=E2=80=99m le= aning towards the safe approach of saying it MUST not.


- Complexity:= MLSPlaintext signature validation has to find a key to verify the signatur= e.=C2=A0 I guess in this case, it should take the one for the Committer (Co= mmit.update_path.leaf_key_package.public_key), but it should also be the ca= se that that key was added to the group with this Commit.=C2=A0 In any case= , this probably calls for a new sender type.

M= aybe these can both be solved with a flag passed into Commit processing:

if (external_commit) {
=C2=A0 // verify th= at there is an Add corresponding to update_path.leaf_key_package
= } else {
=C2=A0 // verify that ExternalInitSecret is not pres= ent
}

I=E2=80=99= m thinking that the MLSPlaintext framing the External Commit will reference= a previously empty leave (namely the left most empty leave in the tree). N= ormally clients would look up the leave to verify a signature, but in this = case it=E2=80=99s an indication that it is an External Commit. Instead, cli= ents have to parse the list of Add Proposal the precede the Commit to deter= mine who the signer/sender is. Lastly the ExternalInitSecret Proposal MUST = also be there.

As for the sender type, couldn=E2= =80=99t we use new_member here? Both for the Add Proposal and the Commit?


Even if so, that logic should get specified in the commit = processing section of the spec.

I agree that this should be written up in detailed steps to avoid any con= fusion.

Raphael


--RLB


On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.or= g> wrote:
I think that=E2=80=99s exactly the motivation we need for inline proposals= , this surplus of signatures is not specific to this use case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>> Assume for the moment that we are not going to do the above asymme= tric
>> calculation for every commit.=C2=A0 Then we need some extra, optio= nal syntax=C2=A0 to
>> carry `enc`, either as an optional field on Commit or as a new Pro= posal,
>> which is the agreed mechanism for extending Commits.=C2=A0 (If we = do it every
>> time, we can just make this part of Commit.)=C2=A0 In the below, I= =E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a full=
> (ExternInitSecret) proposal packet only to then immediately commit to = it? That
> means a full extra frame of bandwidth, an extra signature for the exte= rnal party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit p= roposal
> instead of, say, a second mode for commits. (E.g. a commit uses init_s= ecret[n]
> iff no kem_output field is included in the commit packet. Otherwise it= uses the
> "external_init_secret" computed as Richard described.)
>
> ATM I can't think of a scenario where we wouldnt want the external= committer to
> also be the one creating the ExternalInitSecret proposal and immediatl= y
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx> wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external co= mmit, as a
>>> prelude to a PR.=C2=A0 This is a little bit of an essay, so tl= ;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a new E= xternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the re= quisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for
>>> each epoch - The public key `pkG` of that key pair is publishe= d along with
>>> with other group metadata - The joiner calls SetupBaseS(pkG, >>> some_public_group_context) to get an encapsulated key `enc` an= d an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to the g= roup with
>>> their external commit - The members of the group call SetupBas= eS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE context `= ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)= ` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending = the encapsulated key
>>> `enc` to the group
>>
>> From the discussion at the interim, I think there is consensus abo= ut this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit MUS= T cover an
>>> Add proposal for the new member.=C2=A0 =C2=A0It does not forbi= d the Commit covering
>>> *other* proposals.=C2=A0 It seems like it might be useful in a= couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal for = your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an Upda= te.
>>>
>>> Whether we do this has some impact on the syntax, as discussed= below.
>>
>> While that is not very explicit in the current PR, my approach was= the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more members,= or Commit
>> to already existing Add Proposals if those are accessible. - Remov= es: The
>> joiner can remove prior appearances of itself (like you pointed ou= t) or
>> Commit to already existing Remove Proposals. - Updates: The joiner= should of
>> course not issue own Updates and Commit to them, but that is alrea= dy the case
>> for internal Commits. The joiner can Commit to already existing Up= date
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by the= policy for
>> a group, nothing else. As a reminder: all clients MUST have the sa= me policy
>> for a certain group in order ta validate/refute Proposals and Comm= its.
>>
>> This pretty much motivates my idea for fully re-using the existing= Commit
>> syntax and only introduce the new ExternalInitSecret Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
>>>
>>> Assume for the moment that we are not going to do the above as= ymmetric
>>> calculation for every commit.=C2=A0 Then we need some extra, o= ptional syntax=C2=A0 to
>>> carry `enc`, either as an optional field on Commit or as a new= Proposal,
>>> which is the agreed mechanism for extending Commits.=C2=A0 (If= we do it every
>>> time, we can just make this part of Commit.)=C2=A0 In the belo= w, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSec= ret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now has = to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not have = to be
>> issued by the new joiner, it could very well be an external Propos= al. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The followin= g things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add Proposal a= ccording to
>> the policy and references it in an internal Commit (no External Co= mmit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to th= e public
>> group data but does not need to communicate with the group. Nothin= g happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to urge= ntly send a
>> message to the group. The new joiner creates the ExternalInitSecre= t Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.=C2=A0 It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.=C2=A0 It=E2=80=99s duplicative, si= nce the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily different) = KP in the
>>> Commit.=C2=A0 And you have potential fate-sharing issues, sinc= e all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define ano= ther
>>> top-level content type (parallel to Proposal and Commit) for t= his purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; = } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it optimizes= out all of
>>> the flexibility to include other proposals.=C2=A0 So maybe it= =E2=80=99s worth
>>> considering an Extensible Together Option, where we can put ex= tra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque kem_outpu= t<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, since= it provides
>>> simplicity and extensibility.=C2=A0 And to be honest, I=E2=80= =99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along jus= t these
>>> lines.=C2=A0 If we do this option, we should probably back-por= t it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing Comm= it syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and this = is
>> something that also occurs in other situations. For example, when = a member
>> wants to add n new members at once to the group, it needs to compu= te n+1
>> signatures for that. You mention the idea of inline proposals: Wou= ld that be
>> a proposal that doesn=E2=80=99t have a signature, but still all ot= her information? If
>> so, I think it would be worthwhile looking at that separately, bec= ause as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of informat= ion about the
>>> group in order to make a well-formed ExternalCommit.=C2=A0 In = earlier iterations
>>> of this style of join, we had a GroupInitKey that carried the = right
>>> information. Following that pattern here, we get something lik= e the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque group_id<0..255&g= t;; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque confirmed_transcript_ha= sh<0..255>;
>>> Extension extensions<0..2^32-1>; } GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used GroupC= ontext and
>> has the full public tree. I agree that the tree hash should be eno= ugh and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a GroupInfo o= bject.=C2=A0 The
>>> only things it is missing are interim_transcript_hash and sign= ature, both
>>> of which might be useful.=C2=A0 So maybe all we need to do her= e is say that
>>> clients can publish GroupInfo unencrypted if they want to enab= le self-adds,
>>> in addition to distributing it in encrypted form in Welcome. >>
>> While the two are awfully similar, the signature on GroupInfo is n= ot required
>> here and might have undesired effects w.r.t deniability if this is= publicly
>> accessible. The other reason for not wanting the signature is that= it would
>> be an additional signature to compute with every Commit, making th= em even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some syn= tax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals fo= r External
>> Commits, same as with internal Commits - Do the HPKE-based init se= cret for
>> External Commits - Introduce the ExternalInitSecret Proposal and m= ake it
>> mandatory for External Commits - Explore the idea of inline propos= als
>> separately - Do not re-use signed GroupInfo struct and keep the ad= justed
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing li= st
>>> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing list <= br> >> MLS@ietf.org= https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

________________________________________= _______
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000019a23905b169eb0e-- From nobody Sun Oct 11 12:19:25 2020 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 F35A83A0114 for ; Sun, 11 Oct 2020 12:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHPi6zxlPBgg for ; Sun, 11 Oct 2020 12:19:21 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 0C7443A0115 for ; Sun, 11 Oct 2020 12:19:20 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id p13so14705810edi.7 for ; Sun, 11 Oct 2020 12:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dHEDsx+Kj/fQjh1MLcej8vq3zNSUn66zX3hfbFqDDeQ=; b=AYnPGD3huRdR856fTlnM6bxNlq+BsTRad9JrudGUrF8s1XOo5Sf+1Yzj5UyiWAgKXo M3bDGqNKDSUUIku8oQQ0g/63mmWp7qKw0K8bF75Gl11wMlYcCcJii2ogFbvEDRkYURBe g1BCyA/dNKesDT+BTfzmUCrZ3/yIXvC1HpRkz/kfxaz12pQ2zvBi25uaRWVqKjGEh5iB 15aL+6Dui+7BSbJ9x0Wgxksj1UOV9dXMYNOsjoB5cwdqvG+MVq4V32mGAMbjpg22RSCB 106h37EyMw6GDcEe4LItDiMMfTYXp40nsGjQ100TWh6AJT3nhJTO98VoJED6eLR/7IVw yw9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dHEDsx+Kj/fQjh1MLcej8vq3zNSUn66zX3hfbFqDDeQ=; b=hZJXTa48SGUuFxj5rBk/z+Y4KMVuyhFoyDt0O7wOVR13fDzli1Wpu7Jga9lwX1j73o J0rmcTbAmlP8L7cvHC33gSv7JFW74Op+h21/V1QrYI4/L5IfwEP4mRbnLCY/vtxVyXFO amtQ7nZowjDMRFmaSZfbLkoaBQySE88INbHnRtKwRldVzU5xCUyypiXbVvOGLSRh+n6w Cof2ram/v9k6f66ODjQt/4O1VEAhdGU/3WjKrVzsbBiLMY5OXBwesPt8smHvo2xJpX78 dHDvRONnuWu8bmivRGxjzBkXk0W8KfxcztsI0d+uw9/D1ITtWntl4TUwgeSutcLJmEvC 0z/g== X-Gm-Message-State: AOAM530+iBYJuTQrTH4+06D6Ww1E6SYnA6uA/Js/UD4VR6bqdnfoIHyd NMGrxHXg/L3kGV64OZdubtGfPw== X-Google-Smtp-Source: ABdhPJxLldZSElx9bXUhZMhozuAX3Y+I705+bqiEwEP4bxt1FC2sapwBV/my0lROr3jVDkJ3LGKAKA== X-Received: by 2002:aa7:c7cd:: with SMTP id o13mr10521519eds.114.1602443959206; Sun, 11 Oct 2020 12:19:19 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id mc4sm9624452ejb.61.2020.10.11.12.19.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Oct 2020 12:19:17 -0700 (PDT) From: Raphael Robert Message-Id: <58B34200-428D-4CB2-A5B8-59B8B6E04355@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_179CF42F-7026-4E7C-8946-6D9480BA58FC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sun, 11 Oct 2020 21:19:16 +0200 In-Reply-To: Cc: Brendan McMillion , Messaging Layer Security WG , Joel Alwen To: Richard Barnes References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 19:19:25 -0000 --Apple-Mail=_179CF42F-7026-4E7C-8946-6D9480BA58FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for implementing it! That=E2=80=99s always good for validation. > On 11 Oct 2020, at 21:09, Richard Barnes wrote: >=20 > To help flush out additional details needed here, I went ahead and = prototyped out external commits in mlspp: >=20 > https://github.com/cisco/mlspp/pull/118 = >=20 > As outlined in the PR, there are few additional things we need in the = spec PR: >=20 > 1. The ExternalInit proposal type and its handling > This is largely just what was sketched up-thread. >=20 > 2. Defining the minimal requirements for an external Commit > We probably need a section describing some special additional = constraints that apply to external Commits, beyond general Commits: > - It MUST cover an Add proposal for the committer > - It MUST include an inline an ExternalInit proposal > - It MAY cover other proposals > - Commit.path MUST be populated This is what we currently already have in the PR: - External Commits MUST reference the Add Proposal that adds the issuing = new member to the group =20 - External Commits MUST be signed by the new member =20 - External Commits MUST contain a `path` field (and is therefore a = "full" Commit) =20 [ - When processing a Commit, both existing and new members MUST use an = empty init secret (all-zero vector of size Hash.length) ] (outdated) - If the Add Proposal is also issued by the new member, its member = SenderType MUST be `new_member` >=20 > 3. A new SenderType value for external commits and signature = validation logic > The above PR defines a new SenderType value "external_joiner", and = when an MLSPlaintext with that sender type is encountered, uses the = public key from Commit.path.leaf_key_package. (The latter so that it = doesn't have to look up an Add proposal within the Commit.) I think = that validation strategy is probably the right balance of simplicity and = correctness. As far as the SenderType, we could probably re-use the = "new_member" type, with the understanding that: > - new_member + Proposal =3D> Proposal MUST be an Add, and the = signature must validate with the public key from Add.key_package > - new_member + Commit =3D> Commit MUST be an external Commit (with Add = and ExternalInit proposals), and the signature must validate with the = public key from Commit.path.leaf_key_package >=20 > But if we can nail those down, I think we have a tool here that's = pretty powerful, and not all that complicated to implement. Thanks for confirming my intuition! Raphael >=20 > --Richard >=20 > On Wed, Oct 7, 2020 at 8:45 PM Brendan McMillion = > wrote: > I know you're all tired of hearing me say this, but I still feel = strongly we should always use asymmetric Commits. If MLS is otherwise = secure, then there's simply no reason not to, and it simplifies = implementations. There wouldn't have to be a new ExternalInitSecret = proposal, validation logic wouldn't get substantially more complicated, = and there wouldn't be this worry about bundling several proposals. Otoh, = I think allowing inline proposals in Commits is a good idea but it's = orthogonal to asymmetric Commits. >=20 > On Wed, Oct 7, 2020 at 1:24 PM Raphael Robert = > = wrote: > Good points again! >=20 >> On 7 Oct 2020, at 17:38, Richard Barnes > wrote: >>=20 >> OK, how about the following proposal (heh): >>=20 >> - Add ExternalInitSecret proposal >> - Add an "inline proposals" field to Commit that lets the committer = send proposals with a commit >>=20 >> Two remaining worries here:=20 >>=20 >> - Validation: You want it to be the case that an ExternalInitSecret = is only present for a Commit signed by a new joiner. So some that = information will have to be passed from MLSPlaintext validation to = Commit processing. Or maybe we don't care about that restriction? It = seems like a member sending ExternalInitSecret should at least be SHOULD = NOT, but maybe it's not bad enough to absolutely forbid / have hard = checks against. >=20 > Good question. I guess you want to detect early on if it is an = External Commit or an internal one, perhaps also to block External = Commits by policy. Indeed only the signature and sender type would = reveal that.=20 > Should internal Commits be allowed to have a ExternalInitSecret = proposal that then just gets ignored? I don=E2=80=99t have strong = feelings about it, but I=E2=80=99m leaning towards the safe approach of = saying it MUST not. >=20 >>=20 >> - Complexity: MLSPlaintext signature validation has to find a key to = verify the signature. I guess in this case, it should take the one for = the Committer (Commit.update_path.leaf_key_package.public_key), but it = should also be the case that that key was added to the group with this = Commit. In any case, this probably calls for a new sender type. >>=20 >> Maybe these can both be solved with a flag passed into Commit = processing: >>=20 >> if (external_commit) { >> // verify that there is an Add corresponding to = update_path.leaf_key_package >> } else { >> // verify that ExternalInitSecret is not present >> } >=20 > I=E2=80=99m thinking that the MLSPlaintext framing the External Commit = will reference a previously empty leave (namely the left most empty = leave in the tree). Normally clients would look up the leave to verify a = signature, but in this case it=E2=80=99s an indication that it is an = External Commit. Instead, clients have to parse the list of Add Proposal = the precede the Commit to determine who the signer/sender is. Lastly the = ExternalInitSecret Proposal MUST also be there. >=20 > As for the sender type, couldn=E2=80=99t we use new_member here? Both = for the Add Proposal and the Commit? >=20 >>=20 >> Even if so, that logic should get specified in the commit processing = section of the spec. >=20 > I agree that this should be written up in detailed steps to avoid any = confusion. >=20 > Raphael >=20 >>=20 >> --RLB >>=20 >>=20 >> On Wed, Oct 7, 2020 at 8:57 AM Raphael Robert = > = wrote: >> I think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use case! >>=20 >> Raphael >>=20 >> > On 7 Oct 2020, at 13:27, Joel Alwen > wrote: >> >=20 >> > On 7 Oct 2020, at 03:20, Richard Barnes > wrote: >> >> Assume for the moment that we are not going to do the above = asymmetric >> >> calculation for every commit. Then we need some extra, optional = syntax to >> >> carry `enc`, either as an optional field on Commit or as a new = Proposal, >> >> which is the agreed mechanism for extending Commits. (If we do it = every >> >> time, we can just make this part of Commit.) In the below, I=E2=80=99= ll assume a >> >> new Proposal, say ExternalInitSecret. >> > Isn't it a bit redundant to have the External party prepare a full >> > (ExternInitSecret) proposal packet only to then immediately commit = to it? That >> > means a full extra frame of bandwidth, an extra signature for the = external party >> > and an extra sig verification for group members. >> >=20 >> > I'm wondering what the motivation is for making this an explicit = proposal >> > instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n] >> > iff no kem_output field is included in the commit packet. Otherwise = it uses the >> > "external_init_secret" computed as Richard described.) >> >=20 >> > ATM I can't think of a scenario where we wouldnt want the external = committer to >> > also be the one creating the ExternalInitSecret proposal and = immediatly >> > committing to it... >> >=20 >> > - Jo=C3=ABl >> >=20 >> >=20 >> > On 07/10/2020 12:36, Raphael Robert wrote: >> >> Thanks Richard for looking at all aspects in detail! >> >>=20 >> >> I thought about these things as well and will comment inline: >> >>=20 >> >>> On 7 Oct 2020, at 03:20, Richard Barnes > wrote: >> >>>=20 >> >>> Hey all, >> >>>=20 >> >>> I wanted to send some thoughts on how to implement external = commit, as a >> >>> prelude to a PR. This is a little bit of an essay, so tl;dr, the = proposal >> >>> is: >> >>>=20 >> >>> - Rather than re-using Proposal/Commit, we should make a new = ExternalCommit >> >>> message, parallel to Proposal/Commit >> >>=20 >> >> I think we are better off with re-using the current Commit syntax = and I=E2=80=99ll >> >> explain why further below. >> >>=20 >> >>> - We should also define a syntax for telling the joiner the = requisite >> >>> information about the group >> >>>=20 >> >>> # HPKE-based init secret >> >>>=20 >> >>> The concept here is as follows: >> >>>=20 >> >>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the key = schedule for >> >>> each epoch - The public key `pkG` of that key pair is published = along with >> >>> with other group metadata - The joiner calls SetupBaseS(pkG, >> >>> some_public_group_context) to get an encapsulated key `enc` and = an HPKE >> >>> context `ctx` - The joiner sends the encapsulated key to the = group with >> >>> their external commit - The members of the group call = SetupBaseS(enc, skG, >> >>> some_public_group_context) to get an equivalent HPKE context = `ctx` - >> >>> Everyone calls `ctx.export(MLS_export_label, init_secret_size)` = to derive >> >>> the init secret >> >>>=20 >> >>> So there are two syntactic requirements: >> >>>=20 >> >>> 1. Publishing the group=E2=80=99s public key `pkG` 2. Sending the = encapsulated key >> >>> `enc` to the group >> >>=20 >> >> =46rom the discussion at the interim, I think there is consensus = about this >> >> part, we just need to add that to the PR. >> >>=20 >> >>>=20 >> >>>=20 >> >>> # What Proposals? >> >>>=20 >> >>> The current PR correctly requires that the external Commit MUST = cover an >> >>> Add proposal for the new member. It does not forbid the Commit = covering >> >>> *other* proposals. It seems like it might be useful in a couple = of cases >> >>> to keep that option open: >> >> * Including PSK proposals for additional >> >>> authentication when joining * Including a Remove proposal for = your prior >> >>> appearance when re-joining >> >>>=20 >> >>> The only current proposal that would be nonsensical is an Update. >> >>>=20 >> >>> Whether we do this has some impact on the syntax, as discussed = below. >> >>=20 >> >> While that is not very explicit in the current PR, my approach was = the >> >> following: >> >>=20 >> >> All Proposals should be allowed in an external Commit: >> >>=20 >> >> - Adds: The joiner (new member) could right away add more members, = or Commit >> >> to already existing Add Proposals if those are accessible. - = Removes: The >> >> joiner can remove prior appearances of itself (like you pointed = out) or >> >> Commit to already existing Remove Proposals. - Updates: The joiner = should of >> >> course not issue own Updates and Commit to them, but that is = already the case >> >> for internal Commits. The joiner can Commit to already existing = Update >> >> Proposals from other members. >> >>=20 >> >> Whether all of the above is allowed should only be governed by the = policy for >> >> a group, nothing else. As a reminder: all clients MUST have the = same policy >> >> for a certain group in order ta validate/refute Proposals and = Commits. >> >>=20 >> >> This pretty much motivates my idea for fully re-using the existing = Commit >> >> syntax and only introduce the new ExternalInitSecret Proposal. >> >>=20 >> >>>=20 >> >>>=20 >> >>> # External commit syntax: Separate or Together >> >>>=20 >> >>> Assume for the moment that we are not going to do the above = asymmetric >> >>> calculation for every commit. Then we need some extra, optional = syntax to >> >>> carry `enc`, either as an optional field on Commit or as a new = Proposal, >> >>> which is the agreed mechanism for extending Commits. (If we do = it every >> >>> time, we can just make this part of Commit.) In the below, = I=E2=80=99ll assume a >> >>> new Proposal, say ExternalInitSecret. >> >>>=20 >> >>> struct { opaque kem_output<0..2^16-1>; } ExternalInitSecret; >> >>=20 >> >> This is exactly the Proposal we need. >> >>=20 >> >>>=20 >> >>> Given the requirement for an Add proposal, the joiner now has to = send a >> >>> =E2=80=9Cflight of messages=E2=80=9D: >> >>>=20 >> >>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit >> >>=20 >> >> I see some more nuance here. The first Add Proposal does not have = to be >> >> issued by the new joiner, it could very well be an external = Proposal. The >> >> scenario I had in mind here is the following: >> >>=20 >> >> A server issues an external Add Proposal for a group. The = following things >> >> can happen: >> >>=20 >> >> a) Ideal scenario: >> >>=20 >> >> - A member of the group comes online, validates the Add Proposal = according to >> >> the policy and references it in an internal Commit (no External = Commit >> >> needed) and sends a Welcome message to the new member >> >>=20 >> >> b) Equally ideal scenario: >> >>=20 >> >> - The new joiner comes online before anyone else, has access to = the public >> >> group data but does not need to communicate with the group. = Nothing happens. >> >>=20 >> >> c) Emergency scenario: >> >>=20 >> >> - The new joiner comes online before anyone else and needs to = urgently send a >> >> message to the group. The new joiner creates the = ExternalInitSecret Proposal >> >> and the Commit and sends both to group. >> >>=20 >> >>>=20 >> >>> Let=E2=80=99s call this the Separate Option. It=E2=80=99s a bit = heavyweight, since each of >> >>> these is signed separately. It=E2=80=99s duplicative, since the = KeyPackage in the >> >>> Add is immediately overwritten by the (necessarily different) KP = in the >> >>> Commit. And you have potential fate-sharing issues, since all = three need >> >>> to succeed or fail. >> >>>=20 >> >>> You could also envision a Together Option, where we define = another >> >>> top-level content type (parallel to Proposal and Commit) for this = purpose: >> >>>=20 >> >>> struct { opaque kem_output<0..2^16-1>; UpdatePath path; } = ExternalCommit; >> >>>=20 >> >>> That would avoid all of the challenges above, but it optimizes = out all of >> >>> the flexibility to include other proposals. So maybe it=E2=80=99s = worth >> >>> considering an Extensible Together Option, where we can put extra = proposals >> >>> into an ExternalCommit >> >>>=20 >> >>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;=20 >> >>> UpdatePath path; } ExternalCommit; >> >>>=20 >> >>> Personally, I kind of like the Flexible Together Option, since it = provides >> >>> simplicity and extensibility. And to be honest, I=E2=80=99ve = been wondering if we >> >>> should allow inline proposals in Commit for a while, along just = these >> >>> lines. If we do this option, we should probably back-port it to = Commit as >> >>> well. >> >>>=20 >> >>=20 >> >> As mentioned above, I=E2=80=99m all for re-using the existing = Commit syntax because >> >> of clarity, simplicity and flexibility. >> >>=20 >> >> I do agree that the amount of signatures is sub-optimal, and this = is >> >> something that also occurs in other situations. For example, when = a member >> >> wants to add n new members at once to the group, it needs to = compute n+1 >> >> signatures for that. You mention the idea of inline proposals: = Would that be >> >> a proposal that doesn=E2=80=99t have a signature, but still all = other information? If >> >> so, I think it would be worthwhile looking at that separately, = because as you >> >> say, it could be back-ported to internal Commits as well. I=E2=80=99= m all for >> >> exploring that idea further. >> >>=20 >> >>>=20 >> >>> # Syntax for what the Joiner Needs >> >>>=20 >> >>> The PR notes that the joiner needs to know a bunch of information = about the >> >>> group in order to make a well-formed ExternalCommit. In earlier = iterations >> >>> of this style of join, we had a GroupInitKey that carried the = right >> >>> information. Following that pattern here, we get something like = the >> >>> following: >> >>>=20 >> >>> struct { CipherSuite cipher_suite; opaque group_id<0..255>; = uint64 epoch;=20 >> >>> opaque tree_hash<0..255>; opaque = confirmed_transcript_hash<0..255>;=20 >> >>> Extension extensions<0..2^32-1>; } GroupKeyPackage; >> >>=20 >> >> This is what the PR currently says, except that the PR used = GroupContext and >> >> has the full public tree. I agree that the tree hash should be = enough and >> >> I=E2=80=99ll change the PR accordingly. >> >>=20 >> >>>=20 >> >>> Note that this object is essentially the same as a GroupInfo = object. The >> >>> only things it is missing are interim_transcript_hash and = signature, both >> >>> of which might be useful. So maybe all we need to do here is say = that >> >>> clients can publish GroupInfo unencrypted if they want to enable = self-adds, >> >>> in addition to distributing it in encrypted form in Welcome. >> >>=20 >> >> While the two are awfully similar, the signature on GroupInfo is = not required >> >> here and might have undesired effects w.r.t deniability if this is = publicly >> >> accessible. The other reason for not wanting the signature is that = it would >> >> be an additional signature to compute with every Commit, making = them even >> >> more expensive. I propose to keep the struct as-is. >> >>=20 >> >>>=20 >> >>> In any case, it seems like it would be useful to have some syntax = for >> >>> this. >> >>>=20 >> >>> Hope this helps, =E2=80=94RLB >> >>=20 >> >>=20 >> >> TL;DR: >> >>=20 >> >> I propose the following: >> >>=20 >> >> - Keep the current Commit syntax - Allow all kinds of Proposals = for External >> >> Commits, same as with internal Commits - Do the HPKE-based init = secret for >> >> External Commits - Introduce the ExternalInitSecret Proposal and = make it >> >> mandatory for External Commits - Explore the idea of inline = proposals >> >> separately - Do not re-use signed GroupInfo struct and keep the = adjusted >> >> ExternalCommitInfo instead >> >>=20 >> >> Raphael >> >>=20 >> >>> _______________________________________________ MLS mailing list=20= >> >>> MLS@ietf.org = https://www.ietf.org/mailman/listinfo/mls = >> >>=20 >> >> _______________________________________________ MLS mailing list=20= >> >> MLS@ietf.org = https://www.ietf.org/mailman/listinfo/mls = >> >>=20 >> >=20 >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mls = >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_179CF42F-7026-4E7C-8946-6D9480BA58FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for implementing it! That=E2=80=99s always good for = validation.

On 11 Oct 2020, at 21:09, Richard Barnes = <rlb@ipv.sx> = wrote:

To help flush out additional = details needed here, I went ahead and prototyped out external commits in = mlspp:

https://github.com/cisco/mlspp/pull/118

As outlined in the PR, = there are few additional things we need in the spec PR:

1. The ExternalInit = proposal type and its handling
This = is largely just what was sketched up-thread.

2. Defining the minimal = requirements for an external Commit
We probably = need a section describing some special additional constraints that apply = to external Commits, beyond general Commits:
- It MUST cover an Add proposal for the committer
- It MUST include an inline an ExternalInit = proposal
- It MAY cover other proposals
- Commit.path MUST be populated

This = is what we currently already have in the PR:

- External Commits MUST reference the Add Proposal that = adds the issuing new member to the group    =   
- External Commits MUST be signed by the = new member      
- External = Commits MUST contain a `path` field (and is therefore a "full" = Commit)      
[ - When = processing a Commit, both existing and new members MUST use an empty = init secret (all-zero vector of size Hash.length) ] (outdated)
- If the Add Proposal is also issued by the new member, = its member SenderType MUST be `new_member`


3. A new SenderType value for external commits and signature = validation logic
The above PR = defines a new SenderType value "external_joiner", and when an = MLSPlaintext with that sender type is encountered, uses the public key = from Commit.path.leaf_key_package.  (The latter so that it doesn't = have to look up an Add proposal within the Commit.)  I think that = validation strategy is probably the right balance of simplicity and = correctness.  As far as the SenderType, we could probably re-use = the "new_member" type, with the understanding that:
- new_member + Proposal =3D> = Proposal MUST be an Add, and the signature must validate with the public = key from Add.key_package
- new_member + Commit = =3D> Commit MUST be an external Commit (with Add and ExternalInit = proposals), and the signature must validate with the public key from = Commit.path.leaf_key_package

But if we can nail those down, I think = we have a tool here that's pretty powerful, and not all that complicated = to implement.

Thanks for confirming my intuition!

Raphael


--Richard

On Wed, Oct 7, 2020 at 8:45 PM Brendan = McMillion <brendan@cloudflare.com> wrote:
I know = you're all tired of hearing me say this, but I still feel strongly we = should always use asymmetric Commits. If MLS is otherwise secure, then = there's simply no reason not to, and it simplifies implementations. = There wouldn't have to be a new ExternalInitSecret proposal, validation = logic wouldn't get substantially more complicated, and there wouldn't be = this worry about bundling several proposals. Otoh, I think allowing = inline proposals in Commits is a good idea but it's orthogonal to = asymmetric Commits.

On Wed, Oct = 7, 2020 at 1:24 PM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
Good points again!

On 7 Oct 2020, at 17:38, Richard Barnes = <rlb@ipv.sx> wrote:

OK, how about the = following proposal (heh):

- Add ExternalInitSecret proposal
- Add = an "inline proposals" field to Commit that lets the committer send = proposals with a commit

Two remaining worries here:

- Validation: You want = it to be the case that an ExternalInitSecret is only present for a = Commit signed by a new joiner.  So some that information will have = to be passed from MLSPlaintext validation to Commit processing.  Or = maybe we don't care about that restriction?  It seems like a member = sending ExternalInitSecret should at least be SHOULD NOT, but maybe it's = not bad enough to absolutely forbid / have hard checks against.

Good question. I guess you want to detect early on if = it is an External Commit or an internal one, perhaps also to block = External Commits by policy. Indeed only the signature and sender type = would reveal that. 
Should internal Commits be = allowed to have a ExternalInitSecret proposal that then just gets = ignored? I don=E2=80=99t have strong feelings about it, but I=E2=80=99m = leaning towards the safe approach of saying it MUST not.


- Complexity: MLSPlaintext signature = validation has to find a key to verify the signature.  I guess in = this case, it should take the one for the Committer = (Commit.update_path.leaf_key_package.public_key), but it should also be = the case that that key was added to the group with this Commit.  In = any case, this probably calls for a new sender type.

Maybe these can both be solved with a flag passed into Commit = processing:

if = (external_commit) {
  // verify that there is = an Add corresponding to update_path.leaf_key_package
} else {
  // verify = that ExternalInitSecret is not present
}

I=E2=80=99m thinking that the MLSPlaintext framing the = External Commit will reference a previously empty leave (namely the left = most empty leave in the tree). Normally clients would look up the leave = to verify a signature, but in this case it=E2=80=99s an indication that = it is an External Commit. Instead, clients have to parse the list of Add = Proposal the precede the Commit to determine who the signer/sender is. = Lastly the ExternalInitSecret Proposal MUST also be there.

As for the sender type, = couldn=E2=80=99t we use new_member here? Both for the Add Proposal and = the Commit?


Even if so, that logic should get specified in the commit = processing section of the spec.

I agree that this should be written up = in detailed steps to avoid any confusion.

Raphael


--RLB


On Wed, Oct 7, 2020 at 8:57 AM Raphael = Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
I = think that=E2=80=99s exactly the motivation we need for inline = proposals, this surplus of signatures is not specific to this use = case!

Raphael

> On 7 Oct 2020, at 13:27, Joel Alwen <jalwen@wickr.com> wrote:
>
> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx>= wrote:
>> Assume for the moment that we are not going to do the above = asymmetric
>> calculation for every commit.  Then we need some extra, = optional syntax  to
>> carry `enc`, either as an optional field on Commit or as a new = Proposal,
>> which is the agreed mechanism for extending Commits.  (If = we do it every
>> time, we can just make this part of Commit.)  In the = below, I=E2=80=99ll assume a
>> new Proposal, say ExternalInitSecret.
> Isn't it a bit redundant to have the External party prepare a = full
> (ExternInitSecret) proposal packet only to then immediately commit = to it? That
> means a full extra frame of bandwidth, an extra signature for the = external party
> and an extra sig verification for group members.
>
> I'm wondering what the motivation is for making this an explicit = proposal
> instead of, say, a second mode for commits. (E.g. a commit uses = init_secret[n]
> iff no kem_output field is included in the commit packet. Otherwise = it uses the
> "external_init_secret" computed as Richard described.)
= >
> ATM I can't think of a scenario where we wouldnt want the external = committer to
> also be the one creating the ExternalInitSecret proposal and = immediatly
> committing to it...
>
> - Jo=C3=ABl
>
>
> On 07/10/2020 12:36, Raphael Robert wrote:
>> Thanks Richard for looking at all aspects in detail!
>>
>> I thought about these things as well and will comment = inline:
>>
>>> On 7 Oct 2020, at 03:20, Richard Barnes <rlb@ipv.sx>= wrote:
>>>
>>> Hey all,
>>>
>>> I wanted to send some thoughts on how to implement external = commit, as a
>>> prelude to a PR.  This is a little bit of an essay, so = tl;dr, the proposal
>>> is:
>>>
>>> - Rather than re-using Proposal/Commit, we should make a = new ExternalCommit
>>> message, parallel to Proposal/Commit
>>
>> I think we are better off with re-using the current Commit = syntax and I=E2=80=99ll
>> explain why further below.
>>
>>> - We should also define a syntax for telling the joiner the = requisite
>>> information about the group
>>>
>>> # HPKE-based init secret
>>>
>>> The concept here is as follows:
>>>
>>> - An HPKE/KEM key pair `(skG, pkG)` is derived off of the = key schedule for
>>> each epoch - The public key `pkG` of that key pair is = published along with
>>> with other group metadata - The joiner calls = SetupBaseS(pkG,
>>> some_public_group_context) to get an encapsulated key `enc` = and an HPKE
>>> context `ctx` - The joiner sends the encapsulated key to = the group with
>>> their external commit - The members of the group call = SetupBaseS(enc, skG,
>>> some_public_group_context) to get an equivalent HPKE = context `ctx` -
>>> Everyone calls `ctx.export(MLS_export_label, = init_secret_size)` to derive
>>> the init secret
>>>
>>> So there are two syntactic requirements:
>>>
>>> 1. Publishing the group=E2=80=99s public key `pkG` 2. = Sending the encapsulated key
>>> `enc` to the group
>>
>> =46rom the discussion at the interim, I think there is = consensus about this
>> part, we just need to add that to the PR.
>>
>>>
>>>
>>> # What Proposals?
>>>
>>> The current PR correctly requires that the external Commit = MUST cover an
>>> Add proposal for the new member.   It does not = forbid the Commit covering
>>> *other* proposals.  It seems like it might be useful = in a couple of cases
>>> to keep that option open:
>> * Including PSK proposals for additional
>>> authentication when joining * Including a Remove proposal = for your prior
>>> appearance when re-joining
>>>
>>> The only current proposal that would be nonsensical is an = Update.
>>>
>>> Whether we do this has some impact on the syntax, as = discussed below.
>>
>> While that is not very explicit in the current PR, my approach = was the
>> following:
>>
>> All Proposals should be allowed in an external Commit:
>>
>> - Adds: The joiner (new member) could right away add more = members, or Commit
>> to already existing Add Proposals if those are accessible. - = Removes: The
>> joiner can remove prior appearances of itself (like you pointed = out) or
>> Commit to already existing Remove Proposals. - Updates: The = joiner should of
>> course not issue own Updates and Commit to them, but that is = already the case
>> for internal Commits. The joiner can Commit to already existing = Update
>> Proposals from other members.
>>
>> Whether all of the above is allowed should only be governed by = the policy for
>> a group, nothing else. As a reminder: all clients MUST have the = same policy
>> for a certain group in order ta validate/refute Proposals and = Commits.
>>
>> This pretty much motivates my idea for fully re-using the = existing Commit
>> syntax and only introduce the new ExternalInitSecret = Proposal.
>>
>>>
>>>
>>> # External commit syntax: Separate or Together
= >>>
>>> Assume for the moment that we are not going to do the above = asymmetric
>>> calculation for every commit.  Then we need some = extra, optional syntax  to
>>> carry `enc`, either as an optional field on Commit or as a = new Proposal,
>>> which is the agreed mechanism for extending Commits.  = (If we do it every
>>> time, we can just make this part of Commit.)  In the = below, I=E2=80=99ll assume a
>>> new Proposal, say ExternalInitSecret.
>>>
>>> struct { opaque kem_output<0..2^16-1>; } = ExternalInitSecret;
>>
>> This is exactly the Proposal we need.
>>
>>>
>>> Given the requirement for an Add proposal, the joiner now = has to send a
>>> =E2=80=9Cflight of messages=E2=80=9D:
>>>
>>> - Proposal(Add) - Proposal(ExternalInitSecret) - Commit
>>
>> I see some more nuance here. The first Add Proposal does not = have to be
>> issued by the new joiner, it could very well be an external = Proposal. The
>> scenario I had in mind here is the following:
>>
>> A server issues an external Add Proposal for a group. The = following things
>> can happen:
>>
>> a) Ideal scenario:
>>
>> - A member of the group comes online, validates the Add = Proposal according to
>> the policy and references it in an internal Commit (no External = Commit
>> needed) and sends a Welcome message to the new member
>>
>> b) Equally ideal scenario:
>>
>> - The new joiner comes online before anyone else, has access to = the public
>> group data but does not need to communicate with the group. = Nothing happens.
>>
>> c) Emergency scenario:
>>
>> - The new joiner comes online before anyone else and needs to = urgently send a
>> message to the group. The new joiner creates the = ExternalInitSecret Proposal
>> and the Commit and sends both to group.
>>
>>>
>>> Let=E2=80=99s call this the Separate Option.  It=E2=80=99= s a bit heavyweight, since each of
>>> these is signed separately.  It=E2=80=99s duplicative, = since the KeyPackage in the
>>> Add is immediately overwritten by the (necessarily = different) KP in the
>>> Commit.  And you have potential fate-sharing issues, = since all three need
>>> to succeed or fail.
>>>
>>> You could also envision a Together Option, where we define = another
>>> top-level content type (parallel to Proposal and Commit) = for this purpose:
>>>
>>> struct { opaque kem_output<0..2^16-1>; UpdatePath = path; } ExternalCommit;
>>>
>>> That would avoid all of the challenges above, but it = optimizes out all of
>>> the flexibility to include other proposals.  So maybe = it=E2=80=99s worth
>>> considering an Extensible Together Option, where we can put = extra proposals
>>> into an ExternalCommit
>>>
>>> struct { Proposal proposals<0..2^32-1>; opaque = kem_output<0..2^16-1>;
>>> UpdatePath path; } ExternalCommit;
>>>
>>> Personally, I kind of like the Flexible Together Option, = since it provides
>>> simplicity and extensibility.  And to be honest, = I=E2=80=99ve been wondering if we
>>> should allow inline proposals in Commit for a while, along = just these
>>> lines.  If we do this option, we should probably = back-port it to Commit as
>>> well.
>>>
>>
>> As mentioned above, I=E2=80=99m all for re-using the existing = Commit syntax because
>> of clarity, simplicity and flexibility.
>>
>> I do agree that the amount of signatures is sub-optimal, and = this is
>> something that also occurs in other situations. For example, = when a member
>> wants to add n new members at once to the group, it needs to = compute n+1
>> signatures for that. You mention the idea of inline proposals: = Would that be
>> a proposal that doesn=E2=80=99t have a signature, but still all = other information? If
>> so, I think it would be worthwhile looking at that separately, = because as you
>> say, it could be back-ported to internal Commits as well. I=E2=80= =99m all for
>> exploring that idea further.
>>
>>>
>>> # Syntax for what the Joiner Needs
>>>
>>> The PR notes that the joiner needs to know a bunch of = information about the
>>> group in order to make a well-formed ExternalCommit.  = In earlier iterations
>>> of this style of join, we had a GroupInitKey that carried = the right
>>> information. Following that pattern here, we get something = like the
>>> following:
>>>
>>> struct { CipherSuite cipher_suite; opaque = group_id<0..255>; uint64 epoch;
>>> opaque tree_hash<0..255>; opaque = confirmed_transcript_hash<0..255>;
>>> Extension extensions<0..2^32-1>; } = GroupKeyPackage;
>>
>> This is what the PR currently says, except that the PR used = GroupContext and
>> has the full public tree. I agree that the tree hash should be = enough and
>> I=E2=80=99ll change the PR accordingly.
>>
>>>
>>> Note that this object is essentially the same as a = GroupInfo object.  The
>>> only things it is missing are interim_transcript_hash and = signature, both
>>> of which might be useful.  So maybe all we need to do = here is say that
>>> clients can publish GroupInfo unencrypted if they want to = enable self-adds,
>>> in addition to distributing it in encrypted form in = Welcome.
>>
>> While the two are awfully similar, the signature on GroupInfo = is not required
>> here and might have undesired effects w.r.t deniability if this = is publicly
>> accessible. The other reason for not wanting the signature is = that it would
>> be an additional signature to compute with every Commit, making = them even
>> more expensive. I propose to keep the struct as-is.
>>
>>>
>>> In any case, it seems like it would be useful to have some = syntax for
>>> this.
>>>
>>> Hope this helps, =E2=80=94RLB
>>
>>
>> TL;DR:
>>
>> I propose the following:
>>
>> - Keep the current Commit syntax - Allow all kinds of Proposals = for External
>> Commits, same as with internal Commits - Do the HPKE-based init = secret for
>> External Commits - Introduce the ExternalInitSecret Proposal = and make it
>> mandatory for External Commits - Explore the idea of inline = proposals
>> separately - Do not re-use signed GroupInfo struct and keep the = adjusted
>> ExternalCommitInfo instead
>>
>> Raphael
>>
>>> _______________________________________________ MLS mailing = list
>>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>>
>> _______________________________________________ MLS mailing = list
>> MLS@ietf.org https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

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

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

= --Apple-Mail=_179CF42F-7026-4E7C-8946-6D9480BA58FC-- From nobody Mon Oct 12 13:59:02 2020 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 671213A08C5 for ; Mon, 12 Oct 2020 13:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiWQGbadPYFq for ; Mon, 12 Oct 2020 13:58:58 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A308D3A08B9 for ; Mon, 12 Oct 2020 13:58:58 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id s4so18923349qkf.7 for ; Mon, 12 Oct 2020 13:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OkRRTL5/l3GaCxDwUePo1y80exGClA2SupRQmJ7pzRU=; b=PuqjdMgqG15dXWdkb1d9qyYPaY/RWrXMbYr51nWBUsG/wXocM0lZ0peMDcZBvOhn75 AUEOF8eA6pJIpFrbw1PUXv1HV266g+FTtQ5ymk5KCvqWK249qFI8PpxbK79RpqsgDRA4 kY9iS8dJ/38LD9mc/VUPg1JArpUf3GvCew2dSnc6KdvZzWIPJZzCmMgZIknD3J1UO6Yv WGiaGrSKuS3v9EOux3KS6WpyrdNAuuLBt8zjka2EeO9viGYyUsHH583wOa4RZ2o1bZiQ 68xthsM8ZrdrrTfCayPjkstm6OyP04p88F3dZcLqqmpEKyMw9lvNOKzO8+PiB4ufEuAj ReKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OkRRTL5/l3GaCxDwUePo1y80exGClA2SupRQmJ7pzRU=; b=BbeiL58eZDVcc0muYahg+ng9MCVvGFMgSakvZyYxALzQfjPiJ/fB9/7E6dUygUfnVT kFlApHP5OW/4pqVKzG5TqsmRbzm96t3b7dd2r2zFcuNpLD0sh/0cNJ+mcoUzfm9ahLzm dI6wwSV4j8plkFNwerKyuizdJaHDuTe6oEy4FRPf/a+Lj9xQvDlXDX353lXvsTuS244n 6QJualfIXa8ksJjdps9sD7VH9mTHQTh+wWMhheuTkSRFNt72efA3lkGuuu+HwnQS3hbL EtjUxYgOA/4/C42hfXDYyOeCo8/5j1Pe4JODQgBrPA7b3uuMpkPyeyRIiCedgFlwiGjD /qzw== X-Gm-Message-State: AOAM530dkoKt22YkVnf0hVRCN+qQ7o3GOwt6qdJKHaY+1pK6OfGQxN0M L5vTBJ//mleh7Vav5YdZU7KoXcF3tWoYmyyiUacZsg== X-Google-Smtp-Source: ABdhPJxA7bu048D0knjl+QJDtM3ZwIUD8mvqfMeCzrLUf6ELzJdeOhIzqh0eesSXjYxqn1vbDH+9Cmwql1tPELEAANk= X-Received: by 2002:a05:620a:15b6:: with SMTP id f22mr11721562qkk.490.1602536337318; Mon, 12 Oct 2020 13:58:57 -0700 (PDT) MIME-Version: 1.0 References: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> In-Reply-To: From: Richard Barnes Date: Mon, 12 Oct 2020 16:58:40 -0400 Message-ID: To: Brendan McMillion Cc: Raphael Robert , Messaging Layer Security WG , Joel Alwen Content-Type: multipart/alternative; boundary="00000000000020410605b17f918f" Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 20:59:01 -0000 --00000000000020410605b17f918f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's a fair point, Brendan. The thing that still worries me, though, is that the KEM operation in an AEC effectively introduces a new independent variable -- who is the sender for purposes of the KEM operation? In the DHKEM case, who holds the private key corresponding to the ephemeral public key? In the external-join case, you need this independent variable, so that the new joiner can join the key schedule. In the internal-commit case, you don't need it, so it's purely a source of potential mischief. It's possible that other mechanisms protect against such mischief, but (a) we would need more than mailing-list proofs that that was the case, and (b) we would need to somehow assure that future extensions to the protocol would interact badly with this mechanism. It seems more conservative to not have the additional choice. Sorry that's not super concrete. Maybe some of the folks doing proofs here have thoughts? --Richard On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion wrote: > Unfortunately the attack outlined above doesn't work because if an > attacker has Alice's state from a previous epoch and Alice has since > Updated, they're unable to encrypt MLSCiphertext or authenticate > MLSPlaintext messages. The attacker could use Alice's signing private key > to send an Add proposal and Commit, but they'd be marked as being from an > external sender. There's no distinction between Alice being in the group > already or the attacker adding Alice to groups she was never in to begin > with -- this is a risk inherent with allowing external joiners, not the > asymmetric Commit mechanism itself. > > On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes wrote: > >> Thanks for this analysis, Jo=C3=ABl. This aligns with my intuition as w= ell, >> and seems like a good rationale for a hard prohibition on AEC / >> ExternalCommit from group members. (Something about which I had waffled= in >> a previous email.) >> >> Another way to think about this: PCS with regard to a member is about >> removing an old version of that member (as represented by an HPKE key an= d >> signing key). AEC is designed to allow joins, which means that >> AEC-from-inside allows the old, compromised version of the member to >> rejoin, which kills PCS. >> >> --Richard >> >> On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert > 40wire.com@dmarc.ietf.org> wrote: >> >>> I second that assessment, my idea behind External Commits was to offer = a >>> mechanism where internal Commits couldn=E2=80=99t be used. External Com= mits should >>> remain optional (this can easily be achieved by not providing the >>> ExternalCommitInfo package to new members) and when they are used they >>> should be used as a last resort mechanism (meaning there really is no w= ay >>> to add a member with an internal Commit). >>> >>> I also think MLS should should remain in the position to cover most >>> scenarios from mainstream consumer messaging to messaging in high secur= ity >>> environments. External Commits make the former much more accessible but >>> shouldn=E2=80=99t jeopardise the latter. >>> >>> Raphael >>> >>> > On 6 Oct 2020, at 18:38, Joel Alwen wrote: >>> > >>> > Hey people, >>> > >>> > To follow up on the discussion at the end of the Interim about whethe= r >>> to use >>> > the new "asymmetric external commit" (AEC) mechanism for internal >>> commits I >>> > wanted to summarize my thoughts here. For brevity let SIC be our >>> current >>> > "symmetric internal commit" mechanism. >>> > >>> > - AEC requires extra asymmetric crypto operations (both for committer >>> and >>> > receiver) compared to SIC which I think we should avoid if we can, >>> even at the >>> > cost of some code complexity. >>> > >>> > - AEC doesn't ensure the committer knows the old epoch's key schedule= . >>> This can >>> > play a deciding role in several types of attacks. >>> > >>> > Consider this execution: >>> > >>> > 1. Alice is in a group. Her state leaks (including her signining key)= . >>> > 2. Alice commits (to arbitrary propal). >>> > >>> > At this point, the adversary can still forge a new AEC from Alice but >>> not an SIC. >>> > >>> > Worse, step 2 could have instead been "Alice sends an update proposal >>> replacing >>> > her leaf HPKE but keeping the her sig keys (e.g. because new >>> credentials are >>> > costly to come by). Someone commits to the new proposal." At this >>> point I'd >>> > expect PCS to have kicked in for Alice (as it does when using SIC). >>> But not for >>> > AECs since Alice's signing key is all thats needed to forge a new AEC= . >>> > >>> > I think it is not worth weakening security this way if we dont have t= o. >>> > (Especially, since in some deployments external commits may not be a >>> supported >>> > feature at all.) >>> > >>> > - As for what may or may not be displaid to users, that's really up t= o >>> the >>> > implementation. IMO our goal should be to make the protocol as secure >>> as we can >>> > subject to reasonable costs. Which aspects of the resulting security >>> properties >>> > are ultimately communicated to users should, in principle, be left up >>> to >>> > implementations. That means we shouldn't be designing away security >>> features >>> > only because we think they might be hard to communicate. (Nor does it >>> seem that >>> > inconceivable to me that some implementation may end up explicitly >>> signaling >>> > whether a commit was external vs internal.) >>> > >>> > - Jo=C3=ABl >>> > >>> > _______________________________________________ >>> > MLS mailing list >>> > MLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --00000000000020410605b17f918f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's a fair point, Brendan.=C2=A0 The thing tha= t still worries me, though, is that the KEM operation in an AEC effectively= introduces a new independent variable -- who is the sender for purposes of= the KEM operation?=C2=A0 In the DHKEM case, who holds the private key corr= esponding to the ephemeral public key?

In the exte= rnal-join case, you need this independent variable, so that the new joiner = can join the key schedule.=C2=A0 In the internal-commit case, you don't= need it, so it's purely a source of potential mischief.=C2=A0 It's= possible that other mechanisms protect against such mischief, but (a) we w= ould need more than mailing-list proofs that that was the case, and (b) we = would need to somehow assure that future extensions to the protocol would i= nteract badly with this mechanism.=C2=A0 It seems more conservative to not = have the additional choice.

Sorry that's not s= uper concrete.=C2=A0 Maybe some of the folks doing proofs here have thought= s?

--Richard


On Wed, Oct 7= , 2020 at 8:24 PM Brendan McMillion <brendan@cloudflare.com> wrote:
Unfortunately the attack outl= ined above doesn't work because if an attacker has Alice's state fr= om a previous epoch and Alice has since Updated, they're unable to encr= ypt MLSCiphertext or authenticate MLSPlaintext messages. The attacker could= use Alice's signing private key to send an Add proposal and Commit, bu= t they'd be marked as being from an external sender. There's no dis= tinction between Alice being in the group already or the attacker adding Al= ice to groups she was never in to begin with -- this is a risk inherent wit= h allowing external joiners, not the asymmetric Commit mechanism itself.

On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes <rlb@ipv.sx> wrote:
Thanks for this ana= lysis, Jo=C3=ABl.=C2=A0 This aligns with my intuition as well, and seems li= ke a good rationale for a hard prohibition on AEC / ExternalCommit from gro= up members.=C2=A0 (Something about which I had waffled in a previous email.= )

Another way to think about this: PCS with regard= to a member is about removing an old version of that member (as represente= d by an HPKE key and signing key).=C2=A0 AEC is designed to allow joins, wh= ich means that AEC-from-inside allows the old, compromised version of the m= ember to rejoin, which kills PCS.

--Richard

On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert <raphael=3D40wire.com@dmarc.ie= tf.org> wrote:
I second that assessment, my idea behind External Commits was to offe= r a mechanism where internal Commits couldn=E2=80=99t be used. External Com= mits should remain optional (this can easily be achieved by not providing t= he ExternalCommitInfo package to new members) and when they are used they s= hould be used as a last resort mechanism (meaning there really is no way to= add a member with an internal Commit).

I also think MLS should should remain in the position to cover most scenari= os from mainstream consumer messaging to messaging in high security environ= ments. External Commits make the former much more accessible but shouldn=E2= =80=99t jeopardise the latter.

Raphael

> On 6 Oct 2020, at 18:38, Joel Alwen <jalwen@wickr.com> wrote:
>
> Hey people,
>
> To follow up on the discussion at the end of the Interim about whether= to use
> the new "asymmetric external commit" (AEC) mechanism for int= ernal commits I
> wanted to summarize my thoughts here. For brevity let SIC be our curre= nt
> "symmetric internal commit" mechanism.
>
> - AEC requires extra asymmetric crypto operations (both for committer = and
> receiver) compared to SIC which I think we should avoid if we can, eve= n at the
> cost of some code complexity.
>
> - AEC doesn't ensure the committer knows the old epoch's key s= chedule. This can
> play a deciding role in several types of attacks.
>
> Consider this execution:
>
> 1. Alice is in a group. Her state leaks (including her signining key).=
> 2. Alice commits (to arbitrary propal).
>
> At this point, the adversary can still forge a new AEC from Alice but = not an SIC.
>
> Worse, step 2 could have instead been "Alice sends an update prop= osal replacing
> her leaf HPKE but keeping the her sig keys (e.g. because new credentia= ls are
> costly to come by). Someone commits to the new proposal." At this= point I'd
> expect PCS to have kicked in for Alice (as it does when using SIC). Bu= t not for
> AECs since Alice's signing key is all thats needed to forge a new = AEC.
>
> I think it is not worth weakening security this way if we dont have to= .
> (Especially, since in some deployments external commits may not be a s= upported
> feature at all.)
>
> - As for what may or may not be displaid to users, that's really u= p to the
> implementation. IMO our goal should be to make the protocol as secure = as we can
> subject to reasonable costs. Which aspects of the resulting security p= roperties
> are ultimately communicated to users should, in principle, be left up = to
> implementations. That means we shouldn't be designing away securit= y features
> only because we think they might be hard to communicate. (Nor does it = seem that
> inconceivable to me that some implementation may end up explicitly sig= naling
> whether a commit was external vs internal.)
>
> - Jo=C3=ABl
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000020410605b17f918f-- From nobody Tue Oct 13 07:58:50 2020 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 61EC63A08A9 for ; Tue, 13 Oct 2020 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 alPW2XeUAY0t for ; Tue, 13 Oct 2020 07:58:44 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 795173A08B2 for ; Tue, 13 Oct 2020 07:58:44 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id n18so24453219wrs.5 for ; Tue, 13 Oct 2020 07:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jAqxinmBjWNpujAuZS4vPzct/I4OhVyR1czb3NgRFGY=; b=KRQ94X9wl8toYOg/jciIme9D+ro+pZ6FhKfbACRmbfL1m5jv4LRR3Ql1VZMCJGaGRr GuLwMnv8oR2HcYd4lAl6CiUNJwv1AFlIrQOBM+HkDbn5VDHntANlJYtDmWFvCTYHE67x 0y0edpR1xxFdnXdxsAiv2KAUIArPQSnRPdaKY+zZQF4rylsRuquNv0vbWeeNcGksNHvO KNYMeZ/6t/YQicmOJdMTtM8kZ9E1AB+4tLnTS3r56Mi1POgx6Co9+3pWiezEWPzxlvwD OuBlUwrymXiZLPysitQvuO748THM/ASV4ZrQ257O4XlGk/9NbFRocgyERFmGn1vBkkJj iCbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jAqxinmBjWNpujAuZS4vPzct/I4OhVyR1czb3NgRFGY=; b=UMQPL+F2io29ZUdsF6Cb5nqv3Vle+JQyNqbdev3jo6GoR9rxxx/ciKYp2zVTY5wwZa 8DcVpiOTkWp0gNf5u9kmRrQ5DtyV0ou5xGbXguAF4eIChQWMosA9Qe6zvm+4SMGkJdSV Bg3SxG1G/UAaymD9vgMozdwZ4s1L1IqUX8BYuW+sW5vduPkLMLJowNx2J0GybWa2fbkq KoR6sy6L/7Fo50B2JQ8IAYQ/utPCp6O3AltApU7vALZ31Rp22HEMfw/xkU07WaZY5Mva ABRBdVZUlpYh5CFSBnyRrsR9R6JrwFI83Aiks1EN0eGDOObVeRnsJNJI/eHvTkZK2q/H 0Qkg== X-Gm-Message-State: AOAM530oKrX9Zf6esqrUVz2deDZq/7OYN0Zx4dy1XIC1UYyKrT6PkWhm TZlPAGdqubXknhqe90Kan8F2xnLcqZx+hWiy X-Google-Smtp-Source: ABdhPJydacxC81xPgQVQSxEtVpLF+PfwXScybqqVEH0e4Jm9D//zL73RZ4bHi4vFP35OU/0SD8JQbQ== X-Received: by 2002:a05:6000:118c:: with SMTP id g12mr46762wrx.246.1602601122353; Tue, 13 Oct 2020 07:58:42 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id p13sm27755wmb.5.2020.10.13.07.58.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2020 07:58:41 -0700 (PDT) To: Richard Barnes , Brendan McMillion Cc: Raphael Robert , Messaging Layer Security WG References: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <4ebdc134-59f5-8331-e9c8-ac3c9f343320@wickr.com> Date: Tue, 13 Oct 2020 16:58:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 14:58:48 -0000 On 08/10/2020 02:25, Brendan McMillion wrote: > Unfortunately the attack outlined above doesn't work So, the attacks I describe do work for the construction I had outlined at the start of this thread. So maybe you are (implicitly) thinking about a different construction? Put simply, AEC is explicitly designed to allow a non-group member to produce a valid commit. I.e. given a signing key certified to Alice and the public group state one can always produce a valid AEC commit from Alice to the group. (This includes any and all AEAD keys, MACs, etc. needed for the commit packet. Otherwise AEC wouldn't full-fill its stated purpose.) Ergo if we use AEC for internal commits too then, to commit on behalf of Alice (who is already in the group), all I need again is her signing key and the public group state all of which is available to the adv in the attacks outlined at the start of the thread. So trying to read between the lines, my guess is that you are actually thinking of a hybrid between AEC+SIC for internal commits? Basically, the init_secret is derived as in AEC (by KEMing to the group) but the current key schedule is also used to derive a secret used for authenticating group membership of the commitor (e.g. AEAD encryption key for an MLSCiphertext, or membersip_key for MACing the MLSPlaintext). If that's the case, we're back to authenticating group membership for internal commits which is an absoluately crucial property IMO. But we're also back to not having full code reuse between external vs. internal commits. And we're definitely paying a price: internal commits require otherwise needles asymmetric crypto operations and commits take more bandwidth. Is their any point beyond a bit (but not full) code reuse between int/ext commits? On 12/10/2020 22:58, Richard Barnes wrote: > Sorry that's not super concrete. Maybe some of the folks doing proofs here > have thoughts? So pure AEC for internal commits is definitely much worse in terms of security. We need internal commitors to prove they know the old epochs key schedule. This plays a central role in the general security guarantees provided by MLS. Moreover, when an internal commitor uses bad randomness the security we get from AEC+SIC is strictly worse than what SIC gives us. Bad randomness ==> secrets chosen by commitor during the commit are known to (or at least easier to guess) by the adversary. In this case, for the new epoch_secret[n] to be secure we can't rely on entropy coming from commit_secret. Instead, we need init_secret[n-1] to have entropy. For SIC that can be the case (depending on past corruptions of course) so we're (potentially) good. But for AEC+SIC we're *always* screwed coz knowing the KEM secret chosen by the commitor lets you compute init_secret[n-1]. IMO this is all a bit moot anyway. Some limited code reuse is just not worth extra asymmetric crypto ops. & extra bandwidth. Even with identical security guarantees I'd say its a bad idea to KEM init_secrets to the group. - Joël On 12/10/2020 22:58, Richard Barnes wrote: > That's a fair point, Brendan.  The thing that still worries me, though, is that > the KEM operation in an AEC effectively introduces a new independent variable -- > who is the sender for purposes of the KEM operation?  In the DHKEM case, who > holds the private key corresponding to the ephemeral public key? > > In the external-join case, you need this independent variable, so that the new > joiner can join the key schedule.  In the internal-commit case, you don't need > it, so it's purely a source of potential mischief.  It's possible that other > mechanisms protect against such mischief, but (a) we would need more than > mailing-list proofs that that was the case, and (b) we would need to somehow > assure that future extensions to the protocol would interact badly with this > mechanism.  It seems more conservative to not have the additional choice. > > Sorry that's not super concrete.  Maybe some of the folks doing proofs here have > thoughts? > > --Richard > > > On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion > wrote: > > Unfortunately the attack outlined above doesn't work because if an attacker > has Alice's state from a previous epoch and Alice has since Updated, they're > unable to encrypt MLSCiphertext or authenticate MLSPlaintext messages. The > attacker could use Alice's signing private key to send an Add proposal and > Commit, but they'd be marked as being from an external sender. There's no > distinction between Alice being in the group already or the attacker adding > Alice to groups she was never in to begin with -- this is a risk inherent > with allowing external joiners, not the asymmetric Commit mechanism itself. > > On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes > wrote: > > Thanks for this analysis, Joël.  This aligns with my intuition as well, > and seems like a good rationale for a hard prohibition on AEC / > ExternalCommit from group members.  (Something about which I had waffled > in a previous email.) > > Another way to think about this: PCS with regard to a member is about > removing an old version of that member (as represented by an HPKE key > and signing key).  AEC is designed to allow joins, which means that > AEC-from-inside allows the old, compromised version of the member to > rejoin, which kills PCS. > > --Richard > > On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert > > > wrote: > > I second that assessment, my idea behind External Commits was to > offer a mechanism where internal Commits couldn’t be used. External > Commits should remain optional (this can easily be achieved by not > providing the ExternalCommitInfo package to new members) and when > they are used they should be used as a last resort mechanism > (meaning there really is no way to add a member with an internal > Commit). > > I also think MLS should should remain in the position to cover most > scenarios from mainstream consumer messaging to messaging in high > security environments. External Commits make the former much more > accessible but shouldn’t jeopardise the latter. > > Raphael > > > On 6 Oct 2020, at 18:38, Joel Alwen > wrote: > > > > Hey people, > > > > To follow up on the discussion at the end of the Interim about > whether to use > > the new "asymmetric external commit" (AEC) mechanism for internal > commits I > > wanted to summarize my thoughts here. For brevity let SIC be our > current > > "symmetric internal commit" mechanism. > > > > - AEC requires extra asymmetric crypto operations (both for > committer and > > receiver) compared to SIC which I think we should avoid if we can, > even at the > > cost of some code complexity. > > > > - AEC doesn't ensure the committer knows the old epoch's key > schedule. This can > > play a deciding role in several types of attacks. > > > > Consider this execution: > > > > 1. Alice is in a group. Her state leaks (including her signining key). > > 2. Alice commits (to arbitrary propal). > > > > At this point, the adversary can still forge a new AEC from Alice > but not an SIC. > > > > Worse, step 2 could have instead been "Alice sends an update > proposal replacing > > her leaf HPKE but keeping the her sig keys (e.g. because new > credentials are > > costly to come by). Someone commits to the new proposal." At this > point I'd > > expect PCS to have kicked in for Alice (as it does when using > SIC). But not for > > AECs since Alice's signing key is all thats needed to forge a new AEC. > > > > I think it is not worth weakening security this way if we dont > have to. > > (Especially, since in some deployments external commits may not be > a supported > > feature at all.) > > > > - As for what may or may not be displaid to users, that's really > up to the > > implementation. IMO our goal should be to make the protocol as > secure as we can > > subject to reasonable costs. Which aspects of the resulting > security properties > > are ultimately communicated to users should, in principle, be left > up to > > implementations. That means we shouldn't be designing away > security features > > only because we think they might be hard to communicate. (Nor does > it seem that > > inconceivable to me that some implementation may end up explicitly > signaling > > whether a commit was external vs internal.) > > > > - Joël > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Tue Oct 13 09:40:07 2020 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 8E0A63A09D6 for ; Tue, 13 Oct 2020 09:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loMsoMauquRm for ; Tue, 13 Oct 2020 09:40:02 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 61BC93A09CC for ; Tue, 13 Oct 2020 09:40:02 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id x20so382158qkn.1 for ; Tue, 13 Oct 2020 09:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q7SUQvkUvh6U1vR1+i3gJ4AS5RL4zsHqyuS4J5ygQ54=; b=I0xWNIRb2zO/6DT12zAa7IWENVlVADR25m8TY1VNozfFCw3UzKzqtuI5DmQ1ol/kLn ark0FId2n4uPJdWV3cBlAKJ9Ngm+GXUtLPC+f7pcUf0Axy1/FWVHAstsuTqFMEo+gVlL v7wFUkyi5kSlDFpjItYGCefRpU8mF3kKT15BU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q7SUQvkUvh6U1vR1+i3gJ4AS5RL4zsHqyuS4J5ygQ54=; b=HzzrIibgzbNIKUW7cvEdrua9MjYfByk+kNCPWjSj7EJNiJg8iPP5s/lldQZdli4J+T 3Uav9qXWz/FDZhtDc4O6jlcwpsIiPMjrzH3f5tWHMfMoEzKRb6o93e/D1kbTYIsX7rgv LT+lxibPLz2enoDCcAFOZt7mFii7QZrzEhaYuAmzhE6wArgHywicVryGbqsGuz2t1EPC IuX2pdsWaxu7iXc6RnAYioWMQ29nJ6WOa4EqW0Kizt8OoCvTGq/5GW/82AzkCvCE2xbt ov2pBe29NpwT45t7ZrTLqFAlWjTQd34FgzIa1HRKxhcqzC25stnYeQtEm+iGSihVymKx 8eaA== X-Gm-Message-State: AOAM530RVURWnP0gAgTCSLz2mzazo+xd45IkygTf14ysEOrN2C/ZjDsR naqvSnG6vSP338dqV4ybJijItrnIdCSfY4s6CxVQPA== X-Google-Smtp-Source: ABdhPJw2ZN/RArA8Ys51YSZOdO28F0Lt+Srl+LCXzVwQkFUYr63byEdcbguwsPmbJx9Hw1af1q3yZmSi17lWhfclF4w= X-Received: by 2002:a37:d55:: with SMTP id 82mr826320qkn.227.1602607201114; Tue, 13 Oct 2020 09:40:01 -0700 (PDT) MIME-Version: 1.0 References: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> <4ebdc134-59f5-8331-e9c8-ac3c9f343320@wickr.com> In-Reply-To: <4ebdc134-59f5-8331-e9c8-ac3c9f343320@wickr.com> From: Brendan McMillion Date: Tue, 13 Oct 2020 09:39:50 -0700 Message-ID: To: Joel Alwen Cc: Richard Barnes , Raphael Robert , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000f00b1405b1901084" Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 16:40:06 -0000 --000000000000f00b1405b1901084 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > So, the attacks I describe do work for the construction I had outlined at > the > start of this thread. So maybe you are (implicitly) thinking about a > different > construction? It doesn't work because MLSPlaintext messages from internal sender types are authenticated with a MAC, derived from the key schedule. An outsider can form a valid asymmetric Commit, but since they don't have the MAC key they'd have to mark the message as being from a new_member sender type. Moreover, when an internal commitor uses bad randomness the security we get > from > AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D> > secrets > chosen by commitor during the commit are known to (or at least easier to > guess) > by the adversary. > Hardening the protocol against bad randomness is too severe of a design constraint, especially given how big the protocol is and that this problem is best solved by using a better-implemented RNG. Even if bad randomness doesn't directly compromise the group, it interferes with the PCS of the ratchet tree. It causes nonce reuse. It breaks the confidentiality of Welcome messages sent to that peer. In the external-join case, you need this independent variable, so that the > new joiner can join the key schedule. In the internal-commit case, you > don't need it, so it's purely a source of potential mischief. > We already have one joint for handling messages from external senders: the new_member sender type. By always using asymmetric commits, we rely on this one joint working like it always has. In the approach that you've been working on in the other thread, we have a lot more moving parts and need to coordinate between three different protocol messages. A subset of the Commit validation logic is: if Commit is from new_member SenderType: - It must contain at least one Add from a new_member SenderType - The identities in the Adds from new_member SenderTypes can't correspond to any existing group members - It must contain exactly one ExternalInit from an external SenderType, signed by one of the keys in an Add that's also from a new_member SenderTyp= e - The Commit itself must be signed by the same key the ExternalInit proposal is if Commit is from internal SenderType: - It can't contain any ExternalInit proposals Note that Commits are no longer valid if all their individual proposals are valid, they need an interaction between several proposals and the Commit itself to succeed. On Tue, Oct 13, 2020 at 7:58 AM Joel Alwen wrote: > On 08/10/2020 02:25, Brendan McMillion wrote: > > Unfortunately the attack outlined above doesn't work > > So, the attacks I describe do work for the construction I had outlined at > the > start of this thread. So maybe you are (implicitly) thinking about a > different > construction? > > Put simply, AEC is explicitly designed to allow a non-group member to > produce a > valid commit. I.e. given a signing key certified to Alice and the public > group > state one can always produce a valid AEC commit from Alice to the group. > (This > includes any and all AEAD keys, MACs, etc. needed for the commit packet. > Otherwise AEC wouldn't full-fill its stated purpose.) > > Ergo if we use AEC for internal commits too then, to commit on behalf of > Alice > (who is already in the group), all I need again is her signing key and th= e > public group state all of which is available to the adv in the attacks > outlined > at the start of the thread. > > So trying to read between the lines, my guess is that you are actually > thinking > of a hybrid between AEC+SIC for internal commits? Basically, the > init_secret is > derived as in AEC (by KEMing to the group) but the current key schedule i= s > also > used to derive a secret used for authenticating group membership of the > commitor > (e.g. AEAD encryption key for an MLSCiphertext, or membersip_key for > MACing the > MLSPlaintext). > > If that's the case, we're back to authenticating group membership for > internal > commits which is an absoluately crucial property IMO. But we're also back > to not > having full code reuse between external vs. internal commits. And we're > definitely paying a price: internal commits require otherwise needles > asymmetric > crypto operations and commits take more bandwidth. Is their any point > beyond a > bit (but not full) code reuse between int/ext commits? > > > > On 12/10/2020 22:58, Richard Barnes wrote: > > Sorry that's not super concrete. Maybe some of the folks doing proofs > here > > have thoughts? > > So pure AEC for internal commits is definitely much worse in terms of > security. > We need internal commitors to prove they know the old epochs key schedule= . > This > plays a central role in the general security guarantees provided by MLS. > > Moreover, when an internal commitor uses bad randomness the security we > get from > AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D> > secrets > chosen by commitor during the commit are known to (or at least easier to > guess) > by the adversary. In this case, for the new epoch_secret[n] to be secure = we > can't rely on entropy coming from commit_secret. Instead, we need > init_secret[n-1] to have entropy. For SIC that can be the case (depending > on > past corruptions of course) so we're (potentially) good. But for AEC+SIC > we're > *always* screwed coz knowing the KEM secret chosen by the commitor lets y= ou > compute init_secret[n-1]. > > > > IMO this is all a bit moot anyway. Some limited code reuse is just not > worth > extra asymmetric crypto ops. & extra bandwidth. Even with identical > security > guarantees I'd say its a bad idea to KEM init_secrets to the group. > > - Jo=C3=ABl > > On 12/10/2020 22:58, Richard Barnes wrote: > > That's a fair point, Brendan. The thing that still worries me, though, > is that > > the KEM operation in an AEC effectively introduces a new independent > variable -- > > who is the sender for purposes of the KEM operation? In the DHKEM case= , > who > > holds the private key corresponding to the ephemeral public key? > > > > In the external-join case, you need this independent variable, so that > the new > > joiner can join the key schedule. In the internal-commit case, you > don't need > > it, so it's purely a source of potential mischief. It's possible that > other > > mechanisms protect against such mischief, but (a) we would need more th= an > > mailing-list proofs that that was the case, and (b) we would need to > somehow > > assure that future extensions to the protocol would interact badly with > this > > mechanism. It seems more conservative to not have the additional choic= e. > > > > Sorry that's not super concrete. Maybe some of the folks doing proofs > here have > > thoughts? > > > > --Richard > > > > > > On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion > > wrote: > > > > Unfortunately the attack outlined above doesn't work because if an > attacker > > has Alice's state from a previous epoch and Alice has since Updated= , > they're > > unable to encrypt MLSCiphertext or authenticate MLSPlaintext > messages. The > > attacker could use Alice's signing private key to send an Add > proposal and > > Commit, but they'd be marked as being from an external sender. > There's no > > distinction between Alice being in the group already or the attacke= r > adding > > Alice to groups she was never in to begin with -- this is a risk > inherent > > with allowing external joiners, not the asymmetric Commit mechanism > itself. > > > > On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes > > wrote: > > > > Thanks for this analysis, Jo=C3=ABl. This aligns with my intui= tion > as well, > > and seems like a good rationale for a hard prohibition on AEC / > > ExternalCommit from group members. (Something about which I ha= d > waffled > > in a previous email.) > > > > Another way to think about this: PCS with regard to a member is > about > > removing an old version of that member (as represented by an > HPKE key > > and signing key). AEC is designed to allow joins, which means > that > > AEC-from-inside allows the old, compromised version of the > member to > > rejoin, which kills PCS. > > > > --Richard > > > > On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert > > 40wire.com@dmarc.ietf.org>> > > wrote: > > > > I second that assessment, my idea behind External Commits > was to > > offer a mechanism where internal Commits couldn=E2=80=99t b= e used. > External > > Commits should remain optional (this can easily be achieved > by not > > providing the ExternalCommitInfo package to new members) an= d > when > > they are used they should be used as a last resort mechanis= m > > (meaning there really is no way to add a member with an > internal > > Commit). > > > > I also think MLS should should remain in the position to > cover most > > scenarios from mainstream consumer messaging to messaging i= n > high > > security environments. External Commits make the former muc= h > more > > accessible but shouldn=E2=80=99t jeopardise the latter. > > > > Raphael > > > > > On 6 Oct 2020, at 18:38, Joel Alwen > > wrote: > > > > > > Hey people, > > > > > > To follow up on the discussion at the end of the Interim > about > > whether to use > > > the new "asymmetric external commit" (AEC) mechanism for > internal > > commits I > > > wanted to summarize my thoughts here. For brevity let SIC > be our > > current > > > "symmetric internal commit" mechanism. > > > > > > - AEC requires extra asymmetric crypto operations (both f= or > > committer and > > > receiver) compared to SIC which I think we should avoid i= f > we can, > > even at the > > > cost of some code complexity. > > > > > > - AEC doesn't ensure the committer knows the old epoch's > key > > schedule. This can > > > play a deciding role in several types of attacks. > > > > > > Consider this execution: > > > > > > 1. Alice is in a group. Her state leaks (including her > signining key). > > > 2. Alice commits (to arbitrary propal). > > > > > > At this point, the adversary can still forge a new AEC > from Alice > > but not an SIC. > > > > > > Worse, step 2 could have instead been "Alice sends an > update > > proposal replacing > > > her leaf HPKE but keeping the her sig keys (e.g. because > new > > credentials are > > > costly to come by). Someone commits to the new proposal." > At this > > point I'd > > > expect PCS to have kicked in for Alice (as it does when > using > > SIC). But not for > > > AECs since Alice's signing key is all thats needed to > forge a new AEC. > > > > > > I think it is not worth weakening security this way if we > dont > > have to. > > > (Especially, since in some deployments external commits > may not be > > a supported > > > feature at all.) > > > > > > - As for what may or may not be displaid to users, that's > really > > up to the > > > implementation. IMO our goal should be to make the > protocol as > > secure as we can > > > subject to reasonable costs. Which aspects of the resulti= ng > > security properties > > > are ultimately communicated to users should, in principle= , > be left > > up to > > > implementations. That means we shouldn't be designing awa= y > > security features > > > only because we think they might be hard to communicate. > (Nor does > > it seem that > > > inconceivable to me that some implementation may end up > explicitly > > signaling > > > whether a commit was external vs internal.) > > > > > > - Jo=C3=ABl > > > > > > _______________________________________________ > > > MLS mailing list > > > MLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > > --000000000000f00b1405b1901084 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, the = attacks I describe do work for the construction I had outlined at the
start of this thread. So maybe you are (implicitly) thinking about a differ= ent
construction?

It doesn't work because M= LSPlaintext messages from internal sender types are authenticated with a MA= C, derived from the key schedule. An outsider can form a valid asymmetric C= ommit, but since they don't have the MAC key they'd have to mark th= e message as being from a new_member sender type.

Moreover, when an interna= l commitor uses bad randomness the security we get from
AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D>= secrets
chosen by commitor during the commit are known to (or at least easier to gu= ess)
by the adversary.

Hardening the proto= col against bad randomness is too severe of a design constraint, especially= given how big the protocol is and that this problem is best solved by usin= g a better-implemented RNG. Even if bad randomness doesn't directly com= promise the group, it interferes with the PCS of the ratchet tree. It cause= s nonce reuse. It breaks the confidentiality of Welcome messages sent to th= at peer.

In the external-join case, you need this independent variable, so = that=20 the new joiner can join the key schedule.=C2=A0 In the internal-commit case= ,=20 you don't need it, so it's purely a source of potential mischief.

We already have one joint for handling= messages from external senders: the new_member sender type. By always usin= g asymmetric commits, we rely on this one joint working like it always has.= In the approach that you've been working on in the other thread, we ha= ve a lot more moving parts and need to coordinate between three different p= rotocol messages. A subset of the Commit validation logic is:

if Commit is from new_member SenderType:
=C2=A0 -= It must contain at least one Add from a new_member SenderType
= =C2=A0 - The identities in the Adds from new_member SenderTypes can't c= orrespond to any existing group members
=C2=A0 - It must cont= ain exactly one ExternalInit from an external SenderType, signed by one of = the keys in an Add that's also from a new_member SenderType
=C2=A0 - The Commit itself must be signed by the same key the ExternalIn= it proposal is
if Commit is from internal SenderType:
=C2=A0 - It can't contain any ExternalInit proposals

<= /div>Note that Commits are no longer valid if all their individual proposal= s are valid, they need an interaction between several proposals and the Com= mit itself to succeed.


On Tue, Oct 13, 2020 at= 7:58 AM Joel Alwen <jalwen@wickr.co= m> wrote:
On 08/10/2020 02:25, Brendan McMillion wrote:
> Unfortunately the attack outlined above doesn't work

So, the attacks I describe do work for the construction I had outlined at t= he
start of this thread. So maybe you are (implicitly) thinking about a differ= ent
construction?

Put simply, AEC is explicitly designed to allow a non-group member to produ= ce a
valid commit. I.e. given a signing key certified to Alice and the public gr= oup
state one can always produce a valid AEC commit from Alice to the group. (T= his
includes any and all AEAD keys, MACs, etc. needed for the commit packet. Otherwise AEC wouldn't full-fill its stated purpose.)

Ergo if we use AEC for internal commits too then, to commit on behalf of Al= ice
(who is already in the group), all I need again is her signing key and the<= br> public group state all of which is available to the adv in the attacks outl= ined
at the start of the thread.

So trying to read between the lines, my guess is that you are actually thin= king
of a hybrid between AEC+SIC for internal commits? Basically, the init_secre= t is
derived as in AEC (by KEMing to the group) but the current key schedule is = also
used to derive a secret used for authenticating group membership of the com= mitor
(e.g. AEAD encryption key for an MLSCiphertext, or membersip_key for MACing= the
MLSPlaintext).

If that's the case, we're back to authenticating group membership f= or internal
commits which is an absoluately crucial property IMO. But we're also ba= ck to not
having full code reuse between external vs. internal commits. And we're=
definitely paying a price: internal commits require otherwise needles asymm= etric
crypto operations and commits take more bandwidth. Is their any point beyon= d a
bit (but not full) code reuse between int/ext commits?



On 12/10/2020 22:58, Richard Barnes wrote:
> Sorry that's not super concrete.=C2=A0 Maybe some of the folks doi= ng proofs here
> have thoughts?

So pure AEC for internal commits is definitely much worse in terms of secur= ity.
We need internal commitors to prove they know the old epochs key schedule. = This
plays a central role in the general security guarantees provided by MLS.
Moreover, when an internal commitor uses bad randomness the security we get= from
AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D>= secrets
chosen by commitor during the commit are known to (or at least easier to gu= ess)
by the adversary. In this case, for the new epoch_secret[n] to be secure we=
can't rely on entropy coming from commit_secret. Instead, we need
init_secret[n-1] to have entropy. For SIC that can be the case (depending o= n
past corruptions of course) so we're (potentially) good. But for AEC+SI= C we're
*always* screwed coz knowing the KEM secret chosen by the commitor lets you=
compute init_secret[n-1].



IMO this is all a bit moot anyway. Some limited code reuse is just not wort= h
extra asymmetric crypto ops. & extra bandwidth. Even with identical sec= urity
guarantees I'd say its a bad idea to KEM init_secrets to the group.

- Jo=C3=ABl

On 12/10/2020 22:58, Richard Barnes wrote:
> That's a fair point, Brendan.=C2=A0 The thing that still worries m= e, though, is that
> the KEM operation in an AEC effectively introduces a new independent v= ariable --
> who is the sender for purposes of the KEM operation?=C2=A0 In the DHKE= M case, who
> holds the private key corresponding to the ephemeral public key?
>
> In the external-join case, you need this independent variable, so that= the new
> joiner can join the key schedule.=C2=A0 In the internal-commit case, y= ou don't need
> it, so it's purely a source of potential mischief.=C2=A0 It's = possible that other
> mechanisms protect against such mischief, but (a) we would need more t= han
> mailing-list proofs that that was the case, and (b) we would need to s= omehow
> assure that future extensions to the protocol would interact badly wit= h this
> mechanism.=C2=A0 It seems more conservative to not have the additional= choice.
>
> Sorry that's not super concrete.=C2=A0 Maybe some of the folks doi= ng proofs here have
> thoughts?
>
> --Richard
>
>
> On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion <brendan@cloudflare.com
> <mailto:brendan@cloudflare.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Unfortunately the attack outlined above doesn't= work because if an attacker
>=C2=A0 =C2=A0 =C2=A0has Alice's state from a previous epoch and Ali= ce has since Updated, they're
>=C2=A0 =C2=A0 =C2=A0unable to encrypt MLSCiphertext or authenticate MLS= Plaintext messages. The
>=C2=A0 =C2=A0 =C2=A0attacker could use Alice's signing private key = to send an Add proposal and
>=C2=A0 =C2=A0 =C2=A0Commit, but they'd be marked as being from an e= xternal sender. There's no
>=C2=A0 =C2=A0 =C2=A0distinction between Alice being in the group alread= y or the attacker adding
>=C2=A0 =C2=A0 =C2=A0Alice to groups she was never in to begin with -- t= his is a risk inherent
>=C2=A0 =C2=A0 =C2=A0with allowing external joiners, not the asymmetric = Commit mechanism itself.
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx
>=C2=A0 =C2=A0 =C2=A0<mailto:rlb@ipv.sx>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks for this analysis, Jo=C3=ABl.= =C2=A0 This aligns with my intuition as well,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and seems like a good rationale for a= hard prohibition on AEC /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ExternalCommit from group members.=C2= =A0 (Something about which I had waffled
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a previous email.)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Another way to think about this: PCS = with regard to a member is about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0removing an old version of that membe= r (as represented by an HPKE key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and signing key).=C2=A0 AEC is design= ed to allow joins, which means that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AEC-from-inside allows the old, compr= omised version of the member to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rejoin, which kills PCS.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--Richard
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Oct 6, 2020 at 12:55 PM Rapha= el Robert
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<raphael=3D40wire.com@dmarc.ietf.org <m= ailto:40wire= .com@dmarc.ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I second that assessmen= t, my idea behind External Commits was to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offer a mechanism where= internal Commits couldn=E2=80=99t be used. External
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Commits should remain o= ptional (this can easily be achieved by not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0providing the ExternalC= ommitInfo package to new members) and when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they are used they shou= ld be used as a last resort mechanism
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(meaning there really i= s no way to add a member with an internal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Commit).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also think MLS should= should remain in the position to cover most
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenarios from mainstre= am consumer messaging to messaging in high
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security environments. = External Commits make the former much more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accessible but shouldn= =E2=80=99t jeopardise the latter.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Raphael
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On 6 Oct 2020, at = 18:38, Joel Alwen <jalwen@wickr.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:jalwen@wickr.com>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hey people,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> To follow up on th= e discussion at the end of the Interim about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0whether to use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the new "asym= metric external commit" (AEC) mechanism for internal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0commits I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wanted to summariz= e my thoughts here. For brevity let SIC be our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "symmetric in= ternal commit" mechanism.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - AEC requires ext= ra asymmetric crypto operations (both for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0committer and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> receiver) compared= to SIC which I think we should avoid if we can,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even at the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> cost of some code = complexity.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - AEC doesn't = ensure the committer knows the old epoch's key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0schedule. This can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> play a deciding ro= le in several types of attacks.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Consider this exec= ution:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 1. Alice is in a g= roup. Her state leaks (including her signining key).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 2. Alice commits (= to arbitrary propal).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> At this point, the= adversary can still forge a new AEC from Alice
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but not an SIC.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Worse, step 2 coul= d have instead been "Alice sends an update
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposal replacing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> her leaf HPKE but = keeping the her sig keys (e.g. because new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0credentials are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> costly to come by)= . Someone commits to the new proposal." At this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0point I'd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> expect PCS to have= kicked in for Alice (as it does when using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SIC). But not for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> AECs since Alice&#= 39;s signing key is all thats needed to forge a new AEC.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think it is not = worth weakening security this way if we dont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have to.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> (Especially, since= in some deployments external commits may not be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a supported
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> feature at all.) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - As for what may = or may not be displaid to users, that's really
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> implementation. IM= O our goal should be to make the protocol as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secure as we can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> subject to reasona= ble costs. Which aspects of the resulting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security properties
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> are ultimately com= municated to users should, in principle, be left
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> implementations. T= hat means we shouldn't be designing away
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security features
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> only because we th= ink they might be hard to communicate. (Nor does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it seem that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> inconceivable to m= e that some implementation may end up explicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signaling
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> whether a commit w= as external vs internal.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - Jo=C3=ABl
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> __________________= _____________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> MLS mailing list >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> MLS@ietf.org <mailto:MLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ht= tps://www.ietf.org/mailman/listinfo/mls
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS@ietf.org <mailto:MLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/mls
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS@ietf.org <mailto:MLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/mls
>
--000000000000f00b1405b1901084-- From nobody Tue Oct 13 15:30:35 2020 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 ABCEC3A11D4 for ; Tue, 13 Oct 2020 15:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWZ6gCvKb1a for ; Tue, 13 Oct 2020 15:30:31 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 B6E7A3A11D3 for ; Tue, 13 Oct 2020 15:30:30 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id k9so1235070qki.6 for ; Tue, 13 Oct 2020 15:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z3/mUlHVnB0Tc9ZUm/Cy3KqsbC5DHONjB8vkEH+nZTw=; b=VNfIn2AHC0Hnbgd03c05UQ4LxRBbYTkKXhmicxe4g+WGYXDpcZOfj7GPEEs3Y5dtKA 9tVbCnpvaJzHiTyTIMdeySHew/Ltw+gO+j58N2qQZAX6/MgKeLWWYEYPCYTGgQ+jxqr7 Xwn2GgzFvl6Jtc9vplqFEJGhXzWrMRBziuSu8AUTUyVG06lHnPEofPKh4B2mkVuujmSn fmZ7/nKDIrKIdTyJ2wdFRGKROTS3FCkF9buXqP5U6yGOSp9nPQQSyvtUN5iScTwZl3TY zpm2wWxbMkFiXDZ911r85d/FgBLZBV/aMC6cC99KJjAog67tii/zzDGcMkUlS6wMnEW5 r2jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z3/mUlHVnB0Tc9ZUm/Cy3KqsbC5DHONjB8vkEH+nZTw=; b=Fa5gsamKF4YcQeS7BWnahv29ZcpjR+hTvI1Y10NMXKSd1lsxvPHgSlwoi3Np4lmcFB IFs+AuoSCLTu1KnOCDLJHRcpN5/zwDMmN+ElFhdU5+IxDqHnWeiaW7F/zsqjMTbUPPXB SH6PkYO2mQ/aHKVUxGhw7RzX1GTgV2JXJTxO3xC17vCMZ7Nzz4cdogDQq+iQf5ZMTShw lhdIWGC8H5rmj+4SWh25JKY+ccfUBZKa4HQgBr2CCY6T3Op755nbgFRCCifwy//1gtqB g5tecaWxnx7Q1S3GgtGAGUBnpIjUYciVK9RL2x0KzFimTmttBmOmfgj3aOV9PxJQG3SP U74g== X-Gm-Message-State: AOAM5338IUmC42mHbFLM3Bz+aPMvt8+wIKcxafKhEOIOI6CLncFQ4d2O dx2BGdmEL1gqWKt6+v51JiRsXiKpV6utHOyuKu27oA== X-Google-Smtp-Source: ABdhPJyoM4oWGU699qq2o/bXS/XR77fdgEjt6nxtXDLoirvg88TQ/ur1wrqqgbm0Xb+vp8WwG1ly9x7JcQmJOSM+tKE= X-Received: by 2002:a05:620a:15b6:: with SMTP id f22mr2306561qkk.490.1602628229323; Tue, 13 Oct 2020 15:30:29 -0700 (PDT) MIME-Version: 1.0 References: <7E1C8351-0C05-40F7-86D2-803AFFE5554E@wire.com> <4ebdc134-59f5-8331-e9c8-ac3c9f343320@wickr.com> In-Reply-To: From: Richard Barnes Date: Tue, 13 Oct 2020 18:30:12 -0400 Message-ID: To: Brendan McMillion Cc: Joel Alwen , Raphael Robert , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000050fd6905b194f6eb" Archived-At: Subject: Re: [MLS] All commits = external commit? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 22:30:34 -0000 --00000000000050fd6905b194f6eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On the complexity point: I think the rules are a bit simpler than what you describe (added numbering for reference): 1. if Commit is from "new_member" SenderType: a. It must have a path b. It must contain at least one Add that matches Commit.path.leaf_key_package [same identity at least; same rules as for someone in the tree] c. It must contain exactly one ExternalInit, provided inline [since external people can't send Proposals] d. The Commit itself must be signed by the key in Commit.path.leaf_key_package.credential 2. if Commit is from "member" SenderType: a. It can't contain any ExternalInit proposals (Re: "The identities in the Adds from new_member SenderTypes can't correspond to any existing group members" - This doesn't hold, because the new joiner might be a new instance of an existing group member.) Having implemented this, it wasn't that bad. The checks here align well with the natural layering. The worst "layering violation" is the need to reach into the Commit.path.leaf_key_package to get the public key to verify the credential, and the signal that this is an external message has to be passed to Commit processing. Other than that, it's a few more lines in Commit handling. And honestly, you have almost the same amount of complexity if you always do AEC. You save steps 1(c) and 2, because the ExternalInit is always there. You still need checks 1(a), 1(b), and the layering violations. --Richard On Tue, Oct 13, 2020 at 12:40 PM Brendan McMillion wrote: > So, the attacks I describe do work for the construction I had outlined at >> the >> start of this thread. So maybe you are (implicitly) thinking about a >> different >> construction? > > > It doesn't work because MLSPlaintext messages from internal sender types > are authenticated with a MAC, derived from the key schedule. An outsider > can form a valid asymmetric Commit, but since they don't have the MAC key > they'd have to mark the message as being from a new_member sender type. > > Moreover, when an internal commitor uses bad randomness the security we >> get from >> AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D> >> secrets >> chosen by commitor during the commit are known to (or at least easier to >> guess) >> by the adversary. >> > > Hardening the protocol against bad randomness is too severe of a design > constraint, especially given how big the protocol is and that this proble= m > is best solved by using a better-implemented RNG. Even if bad randomness > doesn't directly compromise the group, it interferes with the PCS of the > ratchet tree. It causes nonce reuse. It breaks the confidentiality of > Welcome messages sent to that peer. > > In the external-join case, you need this independent variable, so that th= e >> new joiner can join the key schedule. In the internal-commit case, you >> don't need it, so it's purely a source of potential mischief. >> > > We already have one joint for handling messages from external senders: th= e > new_member sender type. By always using asymmetric commits, we rely on th= is > one joint working like it always has. In the approach that you've been > working on in the other thread, we have a lot more moving parts and need = to > coordinate between three different protocol messages. A subset of the > Commit validation logic is: > > if Commit is from new_member SenderType: > - It must contain at least one Add from a new_member SenderType > - The identities in the Adds from new_member SenderTypes can't > correspond to any existing group members > - It must contain exactly one ExternalInit from an external SenderType, > signed by one of the keys in an Add that's also from a new_member SenderT= ype > - The Commit itself must be signed by the same key the ExternalInit > proposal is > if Commit is from internal SenderType: > - It can't contain any ExternalInit proposals > > Note that Commits are no longer valid if all their individual proposals > are valid, they need an interaction between several proposals and the > Commit itself to succeed. > > > On Tue, Oct 13, 2020 at 7:58 AM Joel Alwen wrote: > >> On 08/10/2020 02:25, Brendan McMillion wrote: >> > Unfortunately the attack outlined above doesn't work >> >> So, the attacks I describe do work for the construction I had outlined a= t >> the >> start of this thread. So maybe you are (implicitly) thinking about a >> different >> construction? >> >> Put simply, AEC is explicitly designed to allow a non-group member to >> produce a >> valid commit. I.e. given a signing key certified to Alice and the public >> group >> state one can always produce a valid AEC commit from Alice to the group. >> (This >> includes any and all AEAD keys, MACs, etc. needed for the commit packet. >> Otherwise AEC wouldn't full-fill its stated purpose.) >> >> Ergo if we use AEC for internal commits too then, to commit on behalf of >> Alice >> (who is already in the group), all I need again is her signing key and t= he >> public group state all of which is available to the adv in the attacks >> outlined >> at the start of the thread. >> >> So trying to read between the lines, my guess is that you are actually >> thinking >> of a hybrid between AEC+SIC for internal commits? Basically, the >> init_secret is >> derived as in AEC (by KEMing to the group) but the current key schedule >> is also >> used to derive a secret used for authenticating group membership of the >> commitor >> (e.g. AEAD encryption key for an MLSCiphertext, or membersip_key for >> MACing the >> MLSPlaintext). >> >> If that's the case, we're back to authenticating group membership for >> internal >> commits which is an absoluately crucial property IMO. But we're also bac= k >> to not >> having full code reuse between external vs. internal commits. And we're >> definitely paying a price: internal commits require otherwise needles >> asymmetric >> crypto operations and commits take more bandwidth. Is their any point >> beyond a >> bit (but not full) code reuse between int/ext commits? >> >> >> >> On 12/10/2020 22:58, Richard Barnes wrote: >> > Sorry that's not super concrete. Maybe some of the folks doing proofs >> here >> > have thoughts? >> >> So pure AEC for internal commits is definitely much worse in terms of >> security. >> We need internal commitors to prove they know the old epochs key >> schedule. This >> plays a central role in the general security guarantees provided by MLS. >> >> Moreover, when an internal commitor uses bad randomness the security we >> get from >> AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D> >> secrets >> chosen by commitor during the commit are known to (or at least easier to >> guess) >> by the adversary. In this case, for the new epoch_secret[n] to be secure >> we >> can't rely on entropy coming from commit_secret. Instead, we need >> init_secret[n-1] to have entropy. For SIC that can be the case (dependin= g >> on >> past corruptions of course) so we're (potentially) good. But for AEC+SIC >> we're >> *always* screwed coz knowing the KEM secret chosen by the commitor lets >> you >> compute init_secret[n-1]. >> >> >> >> IMO this is all a bit moot anyway. Some limited code reuse is just not >> worth >> extra asymmetric crypto ops. & extra bandwidth. Even with identical >> security >> guarantees I'd say its a bad idea to KEM init_secrets to the group. >> >> - Jo=C3=ABl >> >> On 12/10/2020 22:58, Richard Barnes wrote: >> > That's a fair point, Brendan. The thing that still worries me, though= , >> is that >> > the KEM operation in an AEC effectively introduces a new independent >> variable -- >> > who is the sender for purposes of the KEM operation? In the DHKEM >> case, who >> > holds the private key corresponding to the ephemeral public key? >> > >> > In the external-join case, you need this independent variable, so that >> the new >> > joiner can join the key schedule. In the internal-commit case, you >> don't need >> > it, so it's purely a source of potential mischief. It's possible that >> other >> > mechanisms protect against such mischief, but (a) we would need more >> than >> > mailing-list proofs that that was the case, and (b) we would need to >> somehow >> > assure that future extensions to the protocol would interact badly wit= h >> this >> > mechanism. It seems more conservative to not have the additional >> choice. >> > >> > Sorry that's not super concrete. Maybe some of the folks doing proofs >> here have >> > thoughts? >> > >> > --Richard >> > >> > >> > On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion < >> brendan@cloudflare.com >> > > wrote: >> > >> > Unfortunately the attack outlined above doesn't work because if an >> attacker >> > has Alice's state from a previous epoch and Alice has since >> Updated, they're >> > unable to encrypt MLSCiphertext or authenticate MLSPlaintext >> messages. The >> > attacker could use Alice's signing private key to send an Add >> proposal and >> > Commit, but they'd be marked as being from an external sender. >> There's no >> > distinction between Alice being in the group already or the >> attacker adding >> > Alice to groups she was never in to begin with -- this is a risk >> inherent >> > with allowing external joiners, not the asymmetric Commit mechanis= m >> itself. >> > >> > On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes > > > wrote: >> > >> > Thanks for this analysis, Jo=C3=ABl. This aligns with my intu= ition >> as well, >> > and seems like a good rationale for a hard prohibition on AEC = / >> > ExternalCommit from group members. (Something about which I >> had waffled >> > in a previous email.) >> > >> > Another way to think about this: PCS with regard to a member i= s >> about >> > removing an old version of that member (as represented by an >> HPKE key >> > and signing key). AEC is designed to allow joins, which means >> that >> > AEC-from-inside allows the old, compromised version of the >> member to >> > rejoin, which kills PCS. >> > >> > --Richard >> > >> > On Tue, Oct 6, 2020 at 12:55 PM Raphael Robert >> > > 40wire.com@dmarc.ietf.org>> >> > wrote: >> > >> > I second that assessment, my idea behind External Commits >> was to >> > offer a mechanism where internal Commits couldn=E2=80=99t = be used. >> External >> > Commits should remain optional (this can easily be achieve= d >> by not >> > providing the ExternalCommitInfo package to new members) >> and when >> > they are used they should be used as a last resort mechani= sm >> > (meaning there really is no way to add a member with an >> internal >> > Commit). >> > >> > I also think MLS should should remain in the position to >> cover most >> > scenarios from mainstream consumer messaging to messaging >> in high >> > security environments. External Commits make the former >> much more >> > accessible but shouldn=E2=80=99t jeopardise the latter. >> > >> > Raphael >> > >> > > On 6 Oct 2020, at 18:38, Joel Alwen > > > wrote: >> > > >> > > Hey people, >> > > >> > > To follow up on the discussion at the end of the Interim >> about >> > whether to use >> > > the new "asymmetric external commit" (AEC) mechanism for >> internal >> > commits I >> > > wanted to summarize my thoughts here. For brevity let SI= C >> be our >> > current >> > > "symmetric internal commit" mechanism. >> > > >> > > - AEC requires extra asymmetric crypto operations (both >> for >> > committer and >> > > receiver) compared to SIC which I think we should avoid >> if we can, >> > even at the >> > > cost of some code complexity. >> > > >> > > - AEC doesn't ensure the committer knows the old epoch's >> key >> > schedule. This can >> > > play a deciding role in several types of attacks. >> > > >> > > Consider this execution: >> > > >> > > 1. Alice is in a group. Her state leaks (including her >> signining key). >> > > 2. Alice commits (to arbitrary propal). >> > > >> > > At this point, the adversary can still forge a new AEC >> from Alice >> > but not an SIC. >> > > >> > > Worse, step 2 could have instead been "Alice sends an >> update >> > proposal replacing >> > > her leaf HPKE but keeping the her sig keys (e.g. because >> new >> > credentials are >> > > costly to come by). Someone commits to the new proposal.= " >> At this >> > point I'd >> > > expect PCS to have kicked in for Alice (as it does when >> using >> > SIC). But not for >> > > AECs since Alice's signing key is all thats needed to >> forge a new AEC. >> > > >> > > I think it is not worth weakening security this way if w= e >> dont >> > have to. >> > > (Especially, since in some deployments external commits >> may not be >> > a supported >> > > feature at all.) >> > > >> > > - As for what may or may not be displaid to users, that'= s >> really >> > up to the >> > > implementation. IMO our goal should be to make the >> protocol as >> > secure as we can >> > > subject to reasonable costs. Which aspects of the >> resulting >> > security properties >> > > are ultimately communicated to users should, in >> principle, be left >> > up to >> > > implementations. That means we shouldn't be designing aw= ay >> > security features >> > > only because we think they might be hard to communicate. >> (Nor does >> > it seem that >> > > inconceivable to me that some implementation may end up >> explicitly >> > signaling >> > > whether a commit was external vs internal.) >> > > >> > > - Jo=C3=ABl >> > > >> > > _______________________________________________ >> > > MLS mailing list >> > > MLS@ietf.org >> > > https://www.ietf.org/mailman/listinfo/mls >> > >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mls >> > >> > _______________________________________________ >> > MLS mailing list >> > MLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/mls >> > >> > --00000000000050fd6905b194f6eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the complexity point: I think the rules are a bit = simpler than what you describe (added numbering for reference):

1. if Commit is from "new_member" SenderType:
=C2=A0 a. It must have a path
=C2=A0 b. It must cont= ain at least one Add that matches Commit.path.leaf_key_package [same identi= ty at least; same rules as for someone in the tree]
=C2=A0 c.= It must contain exactly one ExternalInit, provided inline [since external = people can't send Proposals]
=C2=A0 d. The Commit itself = must be signed by the key in Commit.path.leaf_key_package.credential
<= div>2. if Commit is from "member" SenderType:
=C2=A0 a.= It can't contain any ExternalInit proposals

(= Re: "The identities in the Adds from new_member SenderTypes can't = correspond to any existing group members" - This doesn't hold, bec= ause the new joiner might be a new instance of an existing group member.)

Having implemented this, it wasn't that bad.=C2= =A0 The checks here align well with the natural layering.=C2=A0 The worst &= quot;layering violation" is the need to reach into the Commit.path.lea= f_key_package to get the public key to verify the credential, and the signa= l that this is an external message has to be passed to Commit processing.= =C2=A0 Other than that, it's a few more lines in Commit handling.

And honestly, you have almost the same amount of co= mplexity if you always do AEC.=C2=A0 You save steps 1(c) and 2, because the= ExternalInit is always there.=C2=A0 You still need checks 1(a), 1(b), and = the layering violations.

--Richard
<= br>

On Tue, Oct 13, 2020 at 12:40 PM Brendan McMillion <brendan@cloudflare.com> wrote:
So, the attacks I describe do work f= or the construction I had outlined at the
start of this thread. So maybe you are (implicitly) thinking about a differ= ent
construction?

It doesn't work because M= LSPlaintext messages from internal sender types are authenticated with a MA= C, derived from the key schedule. An outsider can form a valid asymmetric C= ommit, but since they don't have the MAC key they'd have to mark th= e message as being from a new_member sender type.

Moreover, when an interna= l commitor uses bad randomness the security we get from
AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D>= secrets
chosen by commitor during the commit are known to (or at least easier to gu= ess)
by the adversary.

Hardening the proto= col against bad randomness is too severe of a design constraint, especially= given how big the protocol is and that this problem is best solved by usin= g a better-implemented RNG. Even if bad randomness doesn't directly com= promise the group, it interferes with the PCS of the ratchet tree. It cause= s nonce reuse. It breaks the confidentiality of Welcome messages sent to th= at peer.

In the external-join case, you need this independent variable, so = that=20 the new joiner can join the key schedule.=C2=A0 In the internal-commit case= ,=20 you don't need it, so it's purely a source of potential mischief.

We already have one joint for handling= messages from external senders: the new_member sender type. By always usin= g asymmetric commits, we rely on this one joint working like it always has.= In the approach that you've been working on in the other thread, we ha= ve a lot more moving parts and need to coordinate between three different p= rotocol messages. A subset of the Commit validation logic is:

if Commit is from new_member SenderType:
=C2=A0 -= It must contain at least one Add from a new_member SenderType
= =C2=A0 - The identities in the Adds from new_member SenderTypes can't c= orrespond to any existing group members
=C2=A0 - It must cont= ain exactly one ExternalInit from an external SenderType, signed by one of = the keys in an Add that's also from a new_member SenderType
=C2=A0 - The Commit itself must be signed by the same key the ExternalIn= it proposal is
if Commit is from internal SenderType:
=C2=A0 - It can't contain any ExternalInit proposals

<= /div>Note that Commits are no longer valid if all their individual proposal= s are valid, they need an interaction between several proposals and the Com= mit itself to succeed.


On Tue, Oct 13, 2020 at= 7:58 AM Joel Alwen <jalwen@wickr.com> wrote:
On 08/10/2020 02:25, Brendan McMillion wrote:
> Unfortunately the attack outlined above doesn't work

So, the attacks I describe do work for the construction I had outlined at t= he
start of this thread. So maybe you are (implicitly) thinking about a differ= ent
construction?

Put simply, AEC is explicitly designed to allow a non-group member to produ= ce a
valid commit. I.e. given a signing key certified to Alice and the public gr= oup
state one can always produce a valid AEC commit from Alice to the group. (T= his
includes any and all AEAD keys, MACs, etc. needed for the commit packet. Otherwise AEC wouldn't full-fill its stated purpose.)

Ergo if we use AEC for internal commits too then, to commit on behalf of Al= ice
(who is already in the group), all I need again is her signing key and the<= br> public group state all of which is available to the adv in the attacks outl= ined
at the start of the thread.

So trying to read between the lines, my guess is that you are actually thin= king
of a hybrid between AEC+SIC for internal commits? Basically, the init_secre= t is
derived as in AEC (by KEMing to the group) but the current key schedule is = also
used to derive a secret used for authenticating group membership of the com= mitor
(e.g. AEAD encryption key for an MLSCiphertext, or membersip_key for MACing= the
MLSPlaintext).

If that's the case, we're back to authenticating group membership f= or internal
commits which is an absoluately crucial property IMO. But we're also ba= ck to not
having full code reuse between external vs. internal commits. And we're=
definitely paying a price: internal commits require otherwise needles asymm= etric
crypto operations and commits take more bandwidth. Is their any point beyon= d a
bit (but not full) code reuse between int/ext commits?



On 12/10/2020 22:58, Richard Barnes wrote:
> Sorry that's not super concrete.=C2=A0 Maybe some of the folks doi= ng proofs here
> have thoughts?

So pure AEC for internal commits is definitely much worse in terms of secur= ity.
We need internal commitors to prove they know the old epochs key schedule. = This
plays a central role in the general security guarantees provided by MLS.
Moreover, when an internal commitor uses bad randomness the security we get= from
AEC+SIC is strictly worse than what SIC gives us. Bad randomness =3D=3D>= secrets
chosen by commitor during the commit are known to (or at least easier to gu= ess)
by the adversary. In this case, for the new epoch_secret[n] to be secure we=
can't rely on entropy coming from commit_secret. Instead, we need
init_secret[n-1] to have entropy. For SIC that can be the case (depending o= n
past corruptions of course) so we're (potentially) good. But for AEC+SI= C we're
*always* screwed coz knowing the KEM secret chosen by the commitor lets you=
compute init_secret[n-1].



IMO this is all a bit moot anyway. Some limited code reuse is just not wort= h
extra asymmetric crypto ops. & extra bandwidth. Even with identical sec= urity
guarantees I'd say its a bad idea to KEM init_secrets to the group.

- Jo=C3=ABl

On 12/10/2020 22:58, Richard Barnes wrote:
> That's a fair point, Brendan.=C2=A0 The thing that still worries m= e, though, is that
> the KEM operation in an AEC effectively introduces a new independent v= ariable --
> who is the sender for purposes of the KEM operation?=C2=A0 In the DHKE= M case, who
> holds the private key corresponding to the ephemeral public key?
>
> In the external-join case, you need this independent variable, so that= the new
> joiner can join the key schedule.=C2=A0 In the internal-commit case, y= ou don't need
> it, so it's purely a source of potential mischief.=C2=A0 It's = possible that other
> mechanisms protect against such mischief, but (a) we would need more t= han
> mailing-list proofs that that was the case, and (b) we would need to s= omehow
> assure that future extensions to the protocol would interact badly wit= h this
> mechanism.=C2=A0 It seems more conservative to not have the additional= choice.
>
> Sorry that's not super concrete.=C2=A0 Maybe some of the folks doi= ng proofs here have
> thoughts?
>
> --Richard
>
>
> On Wed, Oct 7, 2020 at 8:24 PM Brendan McMillion <brendan@cloudflare.com
> <mailto:brendan@cloudflare.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Unfortunately the attack outlined above doesn't= work because if an attacker
>=C2=A0 =C2=A0 =C2=A0has Alice's state from a previous epoch and Ali= ce has since Updated, they're
>=C2=A0 =C2=A0 =C2=A0unable to encrypt MLSCiphertext or authenticate MLS= Plaintext messages. The
>=C2=A0 =C2=A0 =C2=A0attacker could use Alice's signing private key = to send an Add proposal and
>=C2=A0 =C2=A0 =C2=A0Commit, but they'd be marked as being from an e= xternal sender. There's no
>=C2=A0 =C2=A0 =C2=A0distinction between Alice being in the group alread= y or the attacker adding
>=C2=A0 =C2=A0 =C2=A0Alice to groups she was never in to begin with -- t= his is a risk inherent
>=C2=A0 =C2=A0 =C2=A0with allowing external joiners, not the asymmetric = Commit mechanism itself.
>
>=C2=A0 =C2=A0 =C2=A0On Wed, Oct 7, 2020 at 8:49 AM Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx
>=C2=A0 =C2=A0 =C2=A0<mailto:rlb@ipv.sx>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks for this analysis, Jo=C3=ABl.= =C2=A0 This aligns with my intuition as well,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and seems like a good rationale for a= hard prohibition on AEC /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ExternalCommit from group members.=C2= =A0 (Something about which I had waffled
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in a previous email.)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Another way to think about this: PCS = with regard to a member is about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0removing an old version of that membe= r (as represented by an HPKE key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and signing key).=C2=A0 AEC is design= ed to allow joins, which means that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AEC-from-inside allows the old, compr= omised version of the member to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rejoin, which kills PCS.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--Richard
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Oct 6, 2020 at 12:55 PM Rapha= el Robert
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<raphael=3D40wire.com@dmarc.ietf.org <m= ailto:40wire= .com@dmarc.ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I second that assessmen= t, my idea behind External Commits was to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offer a mechanism where= internal Commits couldn=E2=80=99t be used. External
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Commits should remain o= ptional (this can easily be achieved by not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0providing the ExternalC= ommitInfo package to new members) and when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0they are used they shou= ld be used as a last resort mechanism
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(meaning there really i= s no way to add a member with an internal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Commit).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I also think MLS should= should remain in the position to cover most
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scenarios from mainstre= am consumer messaging to messaging in high
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security environments. = External Commits make the former much more
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accessible but shouldn= =E2=80=99t jeopardise the latter.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Raphael
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On 6 Oct 2020, at = 18:38, Joel Alwen <jalwen@wickr.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:jalwen@wickr.com>> wrot= e:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hey people,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> To follow up on th= e discussion at the end of the Interim about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0whether to use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the new "asym= metric external commit" (AEC) mechanism for internal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0commits I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wanted to summariz= e my thoughts here. For brevity let SIC be our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "symmetric in= ternal commit" mechanism.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - AEC requires ext= ra asymmetric crypto operations (both for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0committer and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> receiver) compared= to SIC which I think we should avoid if we can,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0even at the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> cost of some code = complexity.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - AEC doesn't = ensure the committer knows the old epoch's key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0schedule. This can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> play a deciding ro= le in several types of attacks.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Consider this exec= ution:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 1. Alice is in a g= roup. Her state leaks (including her signining key).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 2. Alice commits (= to arbitrary propal).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> At this point, the= adversary can still forge a new AEC from Alice
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but not an SIC.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Worse, step 2 coul= d have instead been "Alice sends an update
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposal replacing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> her leaf HPKE but = keeping the her sig keys (e.g. because new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0credentials are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> costly to come by)= . Someone commits to the new proposal." At this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0point I'd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> expect PCS to have= kicked in for Alice (as it does when using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SIC). But not for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> AECs since Alice&#= 39;s signing key is all thats needed to forge a new AEC.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think it is not = worth weakening security this way if we dont
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have to.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> (Especially, since= in some deployments external commits may not be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a supported
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> feature at all.) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - As for what may = or may not be displaid to users, that's really
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> implementation. IM= O our goal should be to make the protocol as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secure as we can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> subject to reasona= ble costs. Which aspects of the resulting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security properties
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> are ultimately com= municated to users should, in principle, be left
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0up to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> implementations. T= hat means we shouldn't be designing away
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0security features
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> only because we th= ink they might be hard to communicate. (Nor does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it seem that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> inconceivable to m= e that some implementation may end up explicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signaling
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> whether a commit w= as external vs internal.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> - Jo=C3=ABl
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> __________________= _____________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> MLS mailing list >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> MLS@ietf.org <mailto:MLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ht= tps://www.ietf.org/mailman/listinfo/mls
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS@ietf.org <mailto:MLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/mls
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MLS@ietf.org <mailto:MLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/mls
>
--00000000000050fd6905b194f6eb-- From nobody Wed Oct 14 02:35:27 2020 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 B6F4E3A142F for ; Wed, 14 Oct 2020 02:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 D2nVZI-htDyW for ; Wed, 14 Oct 2020 02:35:23 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 E0FEB3A142D for ; Wed, 14 Oct 2020 02:35:22 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id c22so3934580ejx.0 for ; Wed, 14 Oct 2020 02:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=p5/OX4ZkW2Mg+s8WLaY3sthwbcRzrjMraG/0qysIhQA=; b=tLu/6lHaoRUlZNyhyfcsYChgEaiL1uiVUEcm+TcGkS9fKbaOkkjPIhJFz4ps3UKn48 Wr6REAplK37X7dQKsyocfqdJr0RzmWYPE8KK9dyOyCQG3WfFdyU9K6z7+FlsGjSKZQd4 YApLi4IRDFEmilPJJy9UanuUjqNal1asVkjWHZd93ISONXnAaxBw5dp4GG6THqWKA1BZ A9PYaBm0FlVXRXsPPLHXa+E6SFesqCXadlaOyjALUBkI15ahtxqPXzqjTINSxvnmwX7G 1iC6ZFxifZDTLVyUFkN+c6vAntMHRlr9PeW8ssIUaK0cXmaL3lIb/MgrhOKSeH3L6cNT OM+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=p5/OX4ZkW2Mg+s8WLaY3sthwbcRzrjMraG/0qysIhQA=; b=B9XldgdLbzJHs8VJo9hZSqFiro9nbDLDCHwVagHbHTzHcuSbOQfVkmGUSg0XMDG8AY XRK8WOM9xr4tdLOKNv6O6qHTPiqFxhEyPj4UZ/Hlw9MX+AT+Axa/sXG2OZsU7uBIKwUV +Iq8lSFvVFnp0kzv0jWAmdDMLyBPZ4CSgFtBj+XunGatcJF1LVTkeGqASi9BVCZkhnsq czjYjU0iok4ACFH6L8biyiVmo+DPEa+ckeuZWih1E2MCA+zS6cyUWOhN2n31UDMtJi4F zfa/L8JetGG8cwHaedgwn31BnDEqml0HqalnW4td+GaTzJILTFCN81rYasDlyz85ra6r giZw== X-Gm-Message-State: AOAM533aNpacrNzVanRCi4DLHE08V5lOsGUsPOCFdVk53FFdByQ6MjAo XtQPrdB09lAlIJE3EdMhiQjL0sNhVeb330EbMfA= X-Google-Smtp-Source: ABdhPJyb0g9CwMMzsD7hUYZhtsCJuRhoCDS8MU/m62xsDF02PDw0g+y36YgX6oSifDm2Q1pVZxumwQ== X-Received: by 2002:a17:906:6b98:: with SMTP id l24mr4154531ejr.339.1602668120814; Wed, 14 Oct 2020 02:35:20 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id o12sm1398799ejb.36.2020.10.14.02.35.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 02:35:20 -0700 (PDT) To: Raphael Robert , Richard Barnes Cc: Brendan McMillion , Messaging Layer Security WG References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> <58B34200-428D-4CB2-A5B8-59B8B6E04355@wire.com> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <5ba10ac1-5381-e109-9c29-8849dd96c83c@wickr.com> Date: Wed, 14 Oct 2020 11:35:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <58B34200-428D-4CB2-A5B8-59B8B6E04355@wire.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 09:35:26 -0000 Quick question: is an *explicit* add proposal for the external commitor needed? Or can we leave that implicit since an external commitor is always being added and their new leaf key package is already specified as part of the path field in the commit. - Joël On 11/10/2020 21:19, Raphael Robert wrote: > This is what we currently already have in the PR: > > - External Commits MUST reference the Add Proposal that adds the issuing new > member to the group       From nobody Wed Oct 14 03:43:09 2020 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 B4E3C3A1483 for ; Wed, 14 Oct 2020 03:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlCxP5mgZV6c for ; Wed, 14 Oct 2020 03:43:06 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319B23A1477 for ; Wed, 14 Oct 2020 03:43:06 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id t20so2577612edr.11 for ; Wed, 14 Oct 2020 03:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dV73KVb3fbuUaW93zn1BmuTiF7kgTYruptVXGMYjP8o=; b=qzbuljzvGPs0ZPXBwZfCVnQBEV8dKk9ZWqWsuQ+vcNNXeA9av1U3eh4chnZaRPq+fh wN4+vmNHuqbrjqVvdjgULp8ZVzH/LhKDxst3ZFNASmkm8Zqi2b3sKUO7ViCcdG31ZxC7 04K7vpd1JDtIjf/0cALDJ/uWVk8z5J7niVMu6LpKCWZItNMIz/rO/DpYnvqXyMwZ+ZVe Gsu3s+Dx1DM0WZmpX+9FOBQ1iLtTGKATexWi1xYaCW2EiZ2Ev9HsRW2fU8WbMZXaVy8B lo91po4baSIEu0XvbIWqfYVXCYcl+y9nh1Zz4SGzySUAm0qiEiLqDiYPVzNapc+xkZOk HDdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dV73KVb3fbuUaW93zn1BmuTiF7kgTYruptVXGMYjP8o=; b=FFPGlICJCTaCnA7i/7oVhF3Lg0LGznwFZCXZLRPOS/KagzQcipcfHXDVySftS/RVCy 5OkUdTzExTYYp76rKwXwIKujY8+ymPiNxCsWQiXEK+5xr+Duur9zLlIRdWbLlYmInTR6 JAmkFCM1b3Yvfr8rKYHG21TR0Cgj91zD65zuxqJomROthtB8fYcfbLF69/56+nRozaAl VOZai1yrrNScHwNQHtNrQbv9CqPZ5B2JcVkZm271mtCAViWDEfdKh5ej7y6FJXdrpna5 GTrJq99N9kBrevfMSSUXJHRxE8tReB7LCFhlbHL9aTbOUsDJir5lt3L1muR5cMkBf0VY tDwA== X-Gm-Message-State: AOAM533VDoa2/g338tiI6+xUvEiUNiTO24aDNB3G5sLTRfe285hcpElN RGuE8IB08SORSlgTLSelumkjhA== X-Google-Smtp-Source: ABdhPJzozgeDrGmRZjvMHJ9wZjPbAtE+kyGSiFmkAcwN9rOgcMVyga53Tw2osb2Xfam6EzzA7MIy+g== X-Received: by 2002:aa7:c9c3:: with SMTP id i3mr4503942edt.236.1602672184551; Wed, 14 Oct 2020 03:43:04 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id bn2sm1495301ejb.48.2020.10.14.03.43.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 03:43:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: <5ba10ac1-5381-e109-9c29-8849dd96c83c@wickr.com> Date: Wed, 14 Oct 2020 12:43:02 +0200 Cc: Richard Barnes , Brendan McMillion , Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <0578AFC4-A7DF-4780-8111-DE28D5F9B276@wire.com> References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> <58B34200-428D-4CB2-A5B8-59B8B6E04355@wire.com> <5ba10ac1-5381-e109-9c29-8849dd96c83c@wickr.com> To: Joel Alwen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 10:43:08 -0000 That=E2=80=99s a good question. I can definitely think of cases where = the explicit Add Proposal is desired, for example when an external party = (like a server) issues that Add Proposal. In the scenario where the new = member issues the Add Proposal, it does seem a bit redundant, like you = say. Because an Add Proposal for the new member might already exist, = this mechanism has to be optional, otherwise we would have to force drop = proposals. I see two options: a) We keep it as is. In the case the new member issues the Add Proposal, = it could be an inline proposal (once we have that mechanism) and = therefore the only overhead would be increased payload size, since the = KeyPackage is repeated, but there is no overhead coming from additional = signatures. Pros: - Clarity and simplicity when parsing Commit messages Cons: - Increased payload size b) We infer the Add Proposal from the External Commit if it didn=E2=80=99t= exist so far. Internally clients would have create the Add Proposal and = add it to the beginning of the list. This complicates the parsing logic = a bit, but saves the repetition of the KeyPackage. The complication = comes from the fact that this can really only be optional (as mentioned = above). Pros: - Optimal payload Cons: - More complicated logic I don=E2=80=99t see any negative impact on security just yet, to me it = just looks like a tradeoff between logic simplicity and payload size. I = don=E2=80=99t have a strong opinion on this either way, maybe Richard = can comment on the potential increase in complexity? Raphael > On 14 Oct 2020, at 11:35, Joel Alwen wrote: >=20 > Quick question: is an *explicit* add proposal for the external = commitor needed? > Or can we leave that implicit since an external commitor is always = being added > and their new leaf key package is already specified as part of the = path field in > the commit. >=20 > - Jo=C3=ABl >=20 > On 11/10/2020 21:19, Raphael Robert wrote: >> This is what we currently already have in the PR: >>=20 >> - External Commits MUST reference the Add Proposal that adds the = issuing new >> member to the group =20 From nobody Wed Oct 14 03:52:42 2020 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 84CD23A1496 for ; Wed, 14 Oct 2020 03:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 nhxXgum8pfQy for ; Wed, 14 Oct 2020 03:52:39 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2DF3A1493 for ; Wed, 14 Oct 2020 03:52:39 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id dg9so2586442edb.12 for ; Wed, 14 Oct 2020 03:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=E3aePGvZ0quM0PvZq0MzgnymwhIKU4fYGGwFX7Pjyjo=; b=OVRxY3CVy/QQCrlyawjLUg8vXs3G3K2vJyAgJKQV1OJwhHcdxhbNGCFPyblX0YieTT U8H5SM63N6WBccd2gKJNykg7W7GfUpU/PtEIInJ+d2WpR+hv59AMgQzelSrJZd4p9VLw veFwGFYaC5FZzHzFH2M4ceBBZK7z5MMxKhMFzNi0Awd750V8UfHIqVCJwAC8sjocQ14f q53FytbsKdwpd1vsu2w6V73AiQ9KzBkBZH8zfr8uuaUjfTUqSopg4E9pCXw5sf6JvT/o I5CuNgh3qOM41FHOLqm5RRFNZq5tqLYKG1Uub5UXN/0nRwnL7c8s398u/IC6bJvns2f5 gpEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=E3aePGvZ0quM0PvZq0MzgnymwhIKU4fYGGwFX7Pjyjo=; b=iNm6G/4k7LJ+khsRvibDVs+5CK2hwfC1u1EakWLny0mT3n6ODAQHMhWaYOTvNupWBx RUdIWaQikO2xb0d0CSxiO+CBUR6ck6LRzRCgOIyJu55YKy+mBuzE8p4M+xvPXXZ1wRQQ ID0T6G2vq47d6minJnz126PWhw6/hk4Li6uLcrYbmfZ/BXwc2875ieUMXWbAszOazXBH 2LMcdWlzZTePvjQgWorTRKwvKJ034WCvnE/jkHpA9oxazKdFv//YWjshkv4ecqVlpQSJ 6Dg4J5nnkxcve2V0ovBscbm9IWPOsFs/LarsxcVHCtjWL0kMgru7SK0DJWMLZKsO9lPn ysXQ== X-Gm-Message-State: AOAM533YnNDT8TBL4vG8W9T/XGGI9MKGYR++qPPggNnzIHh5uLohCY+K Bhbx6DWz5lSUe1BjXyGstjppXGodjFcdcNB6Sbc= X-Google-Smtp-Source: ABdhPJwAZ2ew9tT9B+bHucCQC70zgy/Z7vEjTKS70h42q51y6NH7hRo+ia/B6liFNGgG/E2ZchacMw== X-Received: by 2002:a50:c38e:: with SMTP id h14mr4715210edf.174.1602672757455; Wed, 14 Oct 2020 03:52:37 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id l17sm1507350eji.14.2020.10.14.03.52.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 03:52:36 -0700 (PDT) To: Raphael Robert Cc: Richard Barnes , Brendan McMillion , Messaging Layer Security WG References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> <58B34200-428D-4CB2-A5B8-59B8B6E04355@wire.com> <5ba10ac1-5381-e109-9c29-8849dd96c83c@wickr.com> <0578AFC4-A7DF-4780-8111-DE28D5F9B276@wire.com> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: Date: Wed, 14 Oct 2020 12:52:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0578AFC4-A7DF-4780-8111-DE28D5F9B276@wire.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 10:52:41 -0000 On 14/10/2020 12:43, Raphael Robert wrote: > I can definitely think of cases where the explicit Add Proposal is desired, > for example when an external party (like a server) issues that Add Proposal. OK, I think I get it. To make sure: Is the use case for explicitly including the Add proposal in an ext. comm. for the commitor to prove to the group that the server (or whoever else made the proposal) OKed the commitor joining the group? - Joël From nobody Wed Oct 14 04:15:19 2020 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 3A73B3A02BC for ; Wed, 14 Oct 2020 04:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PXSs6tW9k03 for ; Wed, 14 Oct 2020 04:15:16 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6C33A0141 for ; Wed, 14 Oct 2020 04:15:16 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id x1so2717835eds.1 for ; Wed, 14 Oct 2020 04:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=osxPoMhGH4+dP810uQwh2ZUrWBObZ3ATmTFEFv7KgYg=; b=ifcjpZqli+J77MgiSDp8/0dLQq0XiJlsahQ9LLxRT2ciOTdBydMYQZ+v7Ci8irA7mN 8pN3Ougsc5F1cGs8HqS3IJooYRgEgJp9056zUQbArB6xj/OlOo9YEIfGlSB2h/xUf6+6 19EwElr+pBp+IoO911Dzdkp9THtkVLfu6kSh9vUz7Lq/wOIof2ylEZmRQjz4dr1CpoZV F0VQTcX6YnvdW+INzK6ccXBQa5SszHbf6B/Q7habbJGprvOWNDzCruGGBb23NtY9KXBr Eckw6Y/SNbU5Qa32l4lRlXHRj5a5b/EfBRYtobDpdfAapJo+RnMogP3A0fyCMXyWRmvP ATWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=osxPoMhGH4+dP810uQwh2ZUrWBObZ3ATmTFEFv7KgYg=; b=q2Rn/iYuoDjqcy4eP97985CYrIY//cQVNEA+Zay8zVxYmlgLqUUScNg8C8ndM90gRH 6D2XaGZ4dDpMXr4JXHBVv/OW091LdudMFH9iDvFGsiGzlNVr4s9S4Q/uO36G5UHgUCMR j6K2qVDKzhII3cLiPmolUKOEEx+dsWvybMuJHISuPBUriYhV8HxIxr+bu4TPPKT7KN8J RmoYH1f1JZyLpCpKH9sDHxaqz1xY+ZdhSfiYAnWttQomEX4khhtNaVWvD1tfTUHupndU avDzsyaon6vrK85HcQr/xbxM1WjnLjERfL9v6SUC753y6l6rHvmfqmR8VeR4DqEo3qOL ZaOA== X-Gm-Message-State: AOAM530PfDT+2rzVjyznOH9aKeu38zUQMcBP191wl/an5/py007EF12E Ysqk2g7uSJvMlOSqRH/Hge7N4A== X-Google-Smtp-Source: ABdhPJzjItWpvEosDJeKZOLGay1wh8INH7MHCucWrEsd5zGDBDasW+L+fPHzvMVvi+7/2nyzeT0hrw== X-Received: by 2002:a50:c309:: with SMTP id a9mr4667382edb.199.1602674115130; Wed, 14 Oct 2020 04:15:15 -0700 (PDT) Received: from rmbp.fritz.box ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id n10sm1380172edo.55.2020.10.14.04.15.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 04:15:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: Date: Wed, 14 Oct 2020 13:15:13 +0200 Cc: Richard Barnes , Brendan McMillion , Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <09F65ECA-9D11-4494-AFFF-8C49D7FF9A1A@wire.com> <27773A68-7CB9-4613-9AAB-57724F896D3A@wire.com> <0E0C01DC-1BA3-4FD3-9A3F-48A736E5C1C0@wire.com> <58B34200-428D-4CB2-A5B8-59B8B6E04355@wire.com> <5ba10ac1-5381-e109-9c29-8849dd96c83c@wickr.com> <0578AFC4-A7DF-4780-8111-DE28D5F9B276@wire.com> To: Joel Alwen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Syntax and mechanics for external commit X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 11:15:18 -0000 Yes, that=E2=80=99s how you derive who added someone to the group. If = Alice creates and Add Proposal to add Bob, the semantic interpretation = would be =E2=80=9CAlice added Bob=E2=80=9D, regardless of who committed = in the end. Obviously this has to do quite a bit with the application logic and some = applications might not care at all about it. But we should be clear on = what information is conveyed where. Raphael > On 14 Oct 2020, at 12:52, Joel Alwen wrote: >=20 > On 14/10/2020 12:43, Raphael Robert wrote: >> I can definitely think of cases where the explicit Add Proposal is = desired, >> for example when an external party (like a server) issues that Add = Proposal. >=20 > OK, I think I get it. To make sure: Is the use case for explicitly = including the > Add proposal in an ext. comm. for the commitor to prove to the group = that the > server (or whoever else made the proposal) OKed the commitor joining = the group? >=20 > - Jo=C3=ABl From nobody Sun Oct 18 00:41:26 2020 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 578DA3A1525 for ; Sun, 18 Oct 2020 00:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=aylSFta0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B4bIk+Jr 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 3hbM9ijq1l_I for ; Sun, 18 Oct 2020 00:41:19 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9453A1524 for ; Sun, 18 Oct 2020 00:41:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4D669A62 for ; Sun, 18 Oct 2020 03:33:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 18 Oct 2020 03:33:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=x88/2dL2JetebWDTzNVPqfdEJ9vCUeekBZHCo1+zPFE=; b=aylSFta0 KWz19SsB54luIgkYexEdnfYzden64tYSwXTqNkyeRyon7EXib6qbWnOjq/ZYmThe K1MMl5T9PGYtDWo8KS+LDu30AwGFStd53mWgTIygLdBXMfuHk1ELWBWfhNZhderf +3F1/KiDDMQ5z4PPsErWqw93v3gqVg0GhrbRUGdpGf1xEm9QIjHuBEMQloZldKF3 1O1VBzm7qdb3DSAlp9IXZfi4O+AyznW3sMhg83WacV94Myv2DW7QtNYWRU7r9T4a ZWpwYBgQ72gSMHTDJIhqr6FH2ckViSpSikN7E0VP6Ye0gCkB878n3TVnYqIego6m ntxCSx0lngGyCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=x88/2dL2JetebWDTzNVPqfdEJ9vCU eekBZHCo1+zPFE=; b=B4bIk+Jr7F4oGxByLHmmZOfmqGq8tDqyvckshpzkuS60N pOedtH7A0EexqcPZ6X+Fg7ymlxT8dKzr+S6iSfuarJBPc+lk5tk6Pjpps0yGk1ap oMahUhLrj700NKExFRWDW1gm7gmCO9QuJHiCG8nEJFNcVEOs8aYXXbSmTxUjzlgk 4PE8iB5dAL/j8GyEDDUN2j0QpaiK6DDnUb2dNsKmaYr2IMkoIDRcbcnLOm7mSpvV RT2jsICvhq6dytQg9+J8ktRC48G0AXK7sG7Krsfhv509f+S04J5ZB2BQ/HG7EP1/ aStzYk12VR5gkggheFDlYV5yudyBhA5BcO/jIpynA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieekgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddvheehrddugedtrd dukedvnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az54.internal.cloudapp.net (unknown [52.255.140.182]) by mail.messagingengine.com (Postfix) with ESMTPA id B4E2D306467D for ; Sun, 18 Oct 2020 03:33:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2717221766691202185==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201018073350.B4E2D306467D@mailuser.nyi.internal> Date: Sun, 18 Oct 2020 03:33:50 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 07:41:21 -0000 --===============2717221766691202185== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+1/-1/=F0=9F=92=AC0) 1 issues created: - Reuse guard mechanism is described in wrong section (by raphaelrobert) https://github.com/mlswg/mls-protocol/issues/418=20 1 issues closed: - Reuse guard mechanism is described in wrong section https://github.com/= mlswg/mls-protocol/issues/418=20 Pull requests ------------- * mlswg/mls-protocol (+7/-2/=F0=9F=92=AC2) 7 pull requests submitted: - Update paragraph about handshake key schedule. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/424=20 - Remove encrypted sender data from ciphertext AAD. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/423=20 - No redundant ciphertexts (by dajost) https://github.com/mlswg/mls-protocol/pull/422=20 - Review PSK PR. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/421=20 - make confirmation_tag a MAC just like membership_tag (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/420=20 - Authentication Secret (by br-hale) https://github.com/mlswg/mls-protocol/pull/419=20 - use `KDF.Nh` instead of `Hash.length` (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/417=20 2 pull requests received 2 new comments: - #420 make confirmation_tag a MAC just like membership_tag (1 by kkohbro= k) https://github.com/mlswg/mls-protocol/pull/420=20 - #419 Authentication Secret (1 by br-hale) https://github.com/mlswg/mls-protocol/pull/419=20 2 pull requests merged: - Inlclude the signature in the confirmation tag https://github.com/mlswg/mls-protocol/pull/416=20 - use `KDF.Nh` instead of `Hash.length` https://github.com/mlswg/mls-protocol/pull/417=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2717221766691202185== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 18, 2020

Issues

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

1 issues created:

1 issues closed:

Pull requests

mlswg/mls-protocol (+7/-2/=F0=9F=92=AC2)

7 pull requests submitted:

2 pull requests received 2 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============2717221766691202185==-- From nobody Mon Oct 19 07:45:13 2020 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 A7D713A03C9 for ; Mon, 19 Oct 2020 07:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6DGMbPVLKmd for ; Mon, 19 Oct 2020 07:45:10 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E16E3A0365 for ; Mon, 19 Oct 2020 07:45:10 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id k9so7967774qki.6 for ; Mon, 19 Oct 2020 07:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zX85s1IU+71svBOYPRWGY9n54nRNUKZC08blLCO6BkQ=; b=pzZcUBw3hoK3mfn8nALVFv1l12yEmkh5JrxgGmI2RSW/wQqi0gWXzAuFMOy6BwR1uT Miq56vnaikr8Sd/HPOmdWU7dTIm6HZ6GGnkQrMkOAGijFMlxv+JFJ95hsU/0lvw6ttIf uMi04Im2JHGX/weLcFIr8Bm2jzN39IHk9+1vO73TabiRoo9WCu3gSRc73H2p6oUUGZhG bbKK+TEB7fMTKVfmUkM0fOz4jUC/eDui7AwC0mG/J1lraHWdmF/mmcVZzLvMA31v4te4 tOqLzemWYvvyWQ5m5ArHHD5Xj5apuwyF/mc1k6AY67MRoZVB/739xJmbwyxXwEdhLR4C AJQQ== 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=zX85s1IU+71svBOYPRWGY9n54nRNUKZC08blLCO6BkQ=; b=RKCyiSxNBlxgzIWN7EHG6IFK5CzW/c12gjsJUW8nuA2KneRCsOh7enKPXZOMstWwvq lefjfwK1II8PR5D9lrgEf/Pinmzh4H4RBvnvt73KDkRj6hrJ7booyL7mOC3lb1AJC7b9 Tq2EkPAW8y2UPev1QRVewuR9Oq7XWU0Cq2Utz6kJgoTHvK2h40Ed+G4y5Dao65nDXKcc NXGTtgkK7K4/yi8BA8eub3XprS8ZY36TvA5L5ZXtimAR3Vw7e9GzafV+abdRTyQZwVmr 0Th/WCsMyVrPxYWqF90Px5pKNQcv6yycUjjWIPrwMaGiNoaeHvxyDV1U+zq0eSwDXnHa caTg== X-Gm-Message-State: AOAM530SE5gzNFpb9lUMWqNayHTAD9xVLSOO/fgqtHDnQ/d0QHV2d/L7 DihkKFOs7R/kMBkoC1gY52Xyq6LelMAzuYfWZXvET8O5+Nw= X-Google-Smtp-Source: ABdhPJydvB4yzbFO+Y8FvIh0/wloLsgDr8Kz9DnutlqHyCfJSnXAGGbpmqnI8GMQAs0MRYtLfvKf5OlpsmngRIUCbgc= X-Received: by 2002:a05:620a:10b7:: with SMTP id h23mr16112137qkk.132.1603118708769; Mon, 19 Oct 2020 07:45:08 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 19 Oct 2020 10:44:55 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000002b655805b2072994" Archived-At: Subject: [MLS] Extend interim tomorrow? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:45:12 -0000 --0000000000002b655805b2072994 Content-Type: text/plain; charset="UTF-8" Hey all, We are getting so close to done! I think the current round of PRs is close to ready to merge, and once that's done, we'll be at the end of our technical issues and can issue draft-10. However, in order to support that, I think we might need a bit more than the 60 minutes of interim time that is scheduled for tomorrow. Would folks be available to add another 30-60min on after that if we need it? Chairs, I'll let you opine on how this squares with IETF rules. Cheers, --Richard --0000000000002b655805b2072994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

We are getting so c= lose to done!=C2=A0 I think the current round of PRs is close to ready to m= erge, and once that's done, we'll be at the end of our technical is= sues and can issue draft-10.

However, in order to = support that, I think we might need a bit more than the 60 minutes of inter= im time that is scheduled for tomorrow.=C2=A0 Would folks be available to a= dd another 30-60min on after that if we need it?

C= hairs, I'll let you opine on how this squares with IETF rules.

Cheers,
--Richard
--0000000000002b655805b2072994-- From nobody Mon Oct 19 07:46:36 2020 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 6A41A3A03C9 for ; Mon, 19 Oct 2020 07:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jMq2zjFi7jH6 for ; Mon, 19 Oct 2020 07:46:32 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 969073A0B04 for ; Mon, 19 Oct 2020 07:46:32 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id z5so8467079ejw.7 for ; Mon, 19 Oct 2020 07:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ARksPF39HbxBGcfMCPtKzQvmfy0DNB7mzZ4xX5AEnLQ=; b=D6hRnbmiZCQPyAHtACkVCGHaGwjurVW6RXxtIahnZsclmm4/R9QVJ80pc+yh79smeH unvKdLmRN8yeT9f8JbLvgHyyD3vXpZ770UAJXPdx9O8WBVRXhNeOv4D23I47fNhYYQvQ rmw8SawoEypU7iyHvegRn3bk1iT8cYkMA9HayP4XNGp88ENrUDdRevOwXkbVKrkx9bT+ Pnn4qPKTadAfZ2iB1OHklLW4oOhml1V3BtnMmfSqLu6FzB0XzN11AEifzDzbeWiUwg/h yjjuxeJKsrrRTQdePMRpDO3TrbtREuXeQdizHBU9sVowRZTI3BhMmIvmpDpBT1tHUUAc lmNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ARksPF39HbxBGcfMCPtKzQvmfy0DNB7mzZ4xX5AEnLQ=; b=tJ4pZ88Zjc6Qi4j6dYjGNOO756k0xQYhU9LQmd758qHeGdWDw1ezLsbDsgTqgPuVI2 FP7LslQzQrLhOm2CAXM48ZDoOpGubqvFINOUqy/5SbJi/DNPRkjB4h8nAimx9xIz0h46 PguaGW3sGbdhsScj5HaEmQhq4E/6Fg+9/nDC6WHFk3Nq+9NFRpbpRndIIr6bevNLRiBh ixYODUxyiHGGgGiQTHDvnBQN2a3arl9fV9TK4Sjj1vh7yaBrPMRagFIwKRwr5vquooHu foWvyCoc/ap7aiD41ZytygGGS+D4vcgSV31e47/OtTUg3/pxDEMnbThQSVLgWhvlLQl6 S+Hw== X-Gm-Message-State: AOAM531Xg9G968vFXeOFCldWUX1ZU9xmOkcjm6Zi0+PiGgrkgm+CB8Ha M3S7B8jVyWZrc+YgYhdEGyMjrQ== X-Google-Smtp-Source: ABdhPJzYYe0EEZaAF2Qi8YRakyxO4JaUtMrx5Q2sFeV3OW70mW51hBbOAHFrIZk5ddQbkagGsygLRA== X-Received: by 2002:a17:906:3582:: with SMTP id o2mr233980ejb.518.1603118790595; Mon, 19 Oct 2020 07:46:30 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id jw9sm308309ejb.33.2020.10.19.07.46.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 07:46:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: Date: Mon, 19 Oct 2020 16:46:28 +0200 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <3D30BCF9-B8C2-4A18-B65A-0025EC5BF4F2@wire.com> References: To: Richard Barnes X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Extend interim tomorrow? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:46:34 -0000 If this is fine by IETF rules, I=E2=80=99m all for it. Raphael > On 19 Oct 2020, at 16:44, Richard Barnes wrote: >=20 > Hey all, >=20 > We are getting so close to done! I think the current round of PRs is = close to ready to merge, and once that's done, we'll be at the end of = our technical issues and can issue draft-10. >=20 > However, in order to support that, I think we might need a bit more = than the 60 minutes of interim time that is scheduled for tomorrow. = Would folks be available to add another 30-60min on after that if we = need it? >=20 > Chairs, I'll let you opine on how this squares with IETF rules. >=20 > Cheers, > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Mon Oct 19 11:18:39 2020 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 E90FB3A0A71 for ; Mon, 19 Oct 2020 11:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdP2UpJHFcje for ; Mon, 19 Oct 2020 11:18:35 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 0BB0F3A0A6C for ; Mon, 19 Oct 2020 11:18:34 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id k21so756157ioa.9 for ; Mon, 19 Oct 2020 11:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=8p2UDqakvwaz9KCiBQL28W1wvWlH7JIT4fUNqiFdglA=; b=mpSR3gWcDhQYxqWN6qN1PEmeet0EqmEGZ6yCwjh35BAP27cO9gNQYsWnJZa35UgnOV Ictf0qU4xHut2hmYtpTsDQy7pY8qEgeeJ0KY6G+3NaS4Jdxk/H9mcBvSVDgjZiJJ4dTD ft7j4V5YGXf1LBVsTsaPZE+LbO1odD51BKr8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=8p2UDqakvwaz9KCiBQL28W1wvWlH7JIT4fUNqiFdglA=; b=JfSnz4b/rFH5ANWPmJzpKGMpjZE4eGwZV3Y0D3a7aasxMN4jQ2hmNKJkdwxrRrMH/5 4gLN6Zbg1OBYeL12tzzqlBSdpzU0YVBkznjjg7q/JthJIx0SyccYH4Jo92SDQWccJKMO TjUI9Q+tqeIrUQJfOYspuntVWsuSA7j5j2D/gdv0B3U3hVNKhLd6dgwpLU9Na9IdPCq5 qRvyeJ07weJ+vkluK1IcZDtYd5FyZPJMqC410gm4cqqwD5ppGn/yOhNUciCjJJi04Jnj apldDHhadUSujG8V8/JiGdt3+hNNzZ9ZKz4ZweDz8EzaCtil00asKHNpp2HZalUaQ2VG qWTQ== X-Gm-Message-State: AOAM531dZv5tzwUbcAxvoi4MT4zFh+8T7UvHkUyWTYy79fiWeHAMSKAV aMMwA/St+wZg8Nj7nhf1xqES1/NxV4XBOA== X-Google-Smtp-Source: ABdhPJzcmEnzM+DXVkJbxtVXdEjmUmJdVuEE0ovNEGYg+H4p2+16FDiupcXHoWw+EaEFv+Cc83Ag3w== X-Received: by 2002:a05:6638:1189:: with SMTP id f9mr1143847jas.10.1603131514191; Mon, 19 Oct 2020 11:18:34 -0700 (PDT) Received: from [10.178.54.90] (mobile-166-170-30-37.mycingular.net. [166.170.30.37]) by smtp.gmail.com with ESMTPSA id c18sm420863iod.28.2020.10.19.11.18.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Oct 2020 11:18:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Sean Turner Mime-Version: 1.0 (1.0) Date: Mon, 19 Oct 2020 14:18:31 -0400 Message-Id: References: <3D30BCF9-B8C2-4A18-B65A-0025EC5BF4F2@wire.com> Cc: Richard Barnes , Messaging Layer Security WG In-Reply-To: <3D30BCF9-B8C2-4A18-B65A-0025EC5BF4F2@wire.com> To: Raphael Robert X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [MLS] Extend interim tomorrow? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 18:18:37 -0000 I have never extended an interim, but I suspect it depends on chair availabi= lity. Nick is running the meeting tomorrow and has a hard stop after the 1s= t hour. I am not sure I will be back in time for the 2nd hour. spt Sent from my iPhone > On Oct 19, 2020, at 10:46, Raphael Robert wrote: >=20 > =EF=BB=BFIf this is fine by IETF rules, I=E2=80=99m all for it. >=20 > Raphael >=20 >> On 19 Oct 2020, at 16:44, Richard Barnes wrote: >>=20 >> Hey all, >>=20 >> We are getting so close to done! I think the current round of PRs is clo= se to ready to merge, and once that's done, we'll be at the end of our techn= ical issues and can issue draft-10. >>=20 >> However, in order to support that, I think we might need a bit more than t= he 60 minutes of interim time that is scheduled for tomorrow. Would folks b= e available to add another 30-60min on after that if we need it? >>=20 >> Chairs, I'll let you opine on how this squares with IETF rules. >>=20 >> Cheers, >> --Richard >> _______________________________________________ >> 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 Tue Oct 20 11:54:20 2020 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 3FF023A0EFC for ; Tue, 20 Oct 2020 11:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGiy26FUD47g for ; Tue, 20 Oct 2020 11:54:17 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983213A12E1 for ; Tue, 20 Oct 2020 11:54:16 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id t9so2004032qtp.9 for ; Tue, 20 Oct 2020 11:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bHY9mNgKPDHYsOkfQil/nRpv3SViouGcHto7uAMJsGA=; b=P8MRpAcV4fplDbDJEoKm3vK5jM31rSJngHd7ITnSKdqpdbwAdsmx3mbFyTz8mErPTJ 8j4EtijBQudsmSUfd8ejiMvALbxvcvTNcqij/xVUnJ+s+ZkUAQYr6NLhxyR00Un/NaAh CGhtm8WgE1mgaOybCAHo0J0BY1wF9k7ktnjWdYXgkFxQtUakKU66TyXoNxtvrf5baDi+ 41yLytYwUjZhWcoRl+xLwm5A3Y73ebCYzpFfM1mPADxnjDs1vmisl4QHbJmggrdi+M82 tdmNH4ze9pD/2e0jGSB1iJwOJV8mQkDl88xzx8Joq4d9Hg2AGFp0XYYr/xKcUetJKSMc RCag== 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=bHY9mNgKPDHYsOkfQil/nRpv3SViouGcHto7uAMJsGA=; b=QujZq2sr1IYT29Q7qVxzbWfOaxtrwgSvrOm3frcKc5pOw1K/YdhqL8ks+rX35vt2zB yz8wTlvW/nwIDbT8YIB4JPuYxtYjW1SoOafyEQHstTnrkPr1WjAJh5JifEH/JG7TPgoT 8RqBtwgSt6rBjDhp0AwyaKJIUkahDjOMDpw0u6y4SgmtjHUy/qi91slaUo9cj7zCF+tJ B9lHpX1TKAjdvIsIljqamlbD3buZ2V3yxeVr4nH/jF7/ngrxyuTXjOPVYJTZ5odrEET/ az0S9q+4NK7HVjfYRgsTDuulos7TdwnBY8gC3l2Vu8RW8r4uM0yvkX/L4pbhBBjDq1lq ihuA== X-Gm-Message-State: AOAM531LBhbe8gc/8E818Mif9FaXUvFz7X8w8C0Ci6eksINXPH1m4pP6 zbgS4eOGURmL48/9kiKF+1Kz8RlreIR2wRb+CwOB0DEs9wAWhw== X-Google-Smtp-Source: ABdhPJypdzKoprC6jd9fDBiwV5OY3nD9HH/kKChW6LYgJh/JKzNo3XqfnZj3BVMZtBkEiOgzNwo8OhdjnGluLdE2DBo= X-Received: by 2002:ac8:1246:: with SMTP id g6mr3780338qtj.353.1603220054970; Tue, 20 Oct 2020 11:54:14 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Tue, 20 Oct 2020 14:53:59 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000dfadc605b21ec158" Archived-At: Subject: [MLS] Overflow discussion on #406 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 18:54:19 -0000 --000000000000dfadc605b21ec158 Content-Type: text/plain; charset="UTF-8" Our interim call went about 30min past our scheduled end time today. Since we were without chairs for the last 30min, that time was not official WG time, so we couldn't make decisions about PRs. Luckily, we only had one PR remaining, and we couldn't come to agreement on it anyway :) Two remaining questions on PR#406, where the first is more important: 1. Should the GroupKeyPackage / GroupPublicState be signed? On the one hand, having a signature would remove any concerns about copy/paste recombination of the various constituent parts. In particular, it would avoid the public key for one group being reused with another (up to reuse of signature keys across groups). On the other hand, Raphael expressed some concern about deniability, since this would be a public signature by a member of the group over the whole state of the group. Personally, signing seems like the conservative option to me. But I haven't done much analysis here. 2. Which transcript hash(es) should be included? (This is more of an engineering question than a security question) To summarize how the transcript hashes / confirmation tag work: confirmed = H(interim || all_of_commit_besides_confirmation_tag) confirmation_tag = MAC(confirmation_key, confirmed) interim = H(confirmed || confirmation_tag) In a GroupInfo / Welcome based join, the joiner needs the confirmed transcript hash but not the interim. The confirmation tag is provided in the GroupInfo and verified by the joiner, and can then be used to compute the interim transcript hash. (This is a side effect of #416, which moved the signature from interim to confirmed) In other words, the joiner starts at the second line above, since they don't actually see the commit. In an GroupPublicState / Commit based join, the joiner is computing the commit, so they start at the first line. As a result, the joiner needs the interim transcript hash, not the confirmed transcript hash. I have implemented these changes (removing interim from GroupInfo and confirmed from GroupPublicState) in my draft implementation of #406 [1], and they do work. I have filed a small spec PR to remove this [2] and suggested the corresponding changes in #406. --RLB [1] https://github.com/cisco/mlspp/pull/118 [2] https://github.com/mlswg/mls-protocol/pull/428 --000000000000dfadc605b21ec158 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Our interim call went about 30min past our scheduled = end time today.=C2=A0 Since we were without chairs for the last 30min, that= time was not official WG time, so we couldn't make decisions about PRs= .=C2=A0 Luckily, we only had one PR remaining, and we couldn't come to = agreement on it anyway :)

Two remaining questions = on PR#406, where the first is more important:

1. S= hould the GroupKeyPackage / GroupPublicState be signed?

On the one hand, having a signature would remove any concerns about c= opy/paste recombination of the various constituent parts.=C2=A0 In particul= ar, it would avoid the public key for one group being reused with another (= up to reuse of signature keys across groups).

= On the other hand, Raphael expressed some concern about deniability, since = this would be a public signature by a member of the group over the whole st= ate of the group.

Personally, signing seems like t= he conservative option to me.=C2=A0 But I haven't done much analysis he= re.

2. Which transcript hash(es) should be inc= luded?

(This is more of an engineering question th= an a security question)=C2=A0 To summarize how the transcript hashes / conf= irmation tag work:

confirmed =3D H(interim || = all_of_commit_besides_confirmation_tag)
confirmation_tag =3D MAC(= confirmation_key, confirmed)
interim =3D H(confirmed || confi= rmation_tag)

In a GroupInfo / Welcome based jo= in, the joiner needs the confirmed transcript hash but not the interim.=C2= =A0 The confirmation tag is provided in the GroupInfo and verified by the j= oiner, and can then be used to compute the interim transcript hash.=C2=A0 (= This is a side effect of #416, which moved the signature from interim to co= nfirmed)=C2=A0 In other words, the joiner starts at the second line above, = since they don't actually see the commit.

= In an GroupPublicState / Commit based join, the joiner is computing the com= mit, so they start at the first line.=C2=A0 As a result, the joiner needs t= he interim transcript hash, not the confirmed transcript hash.
I have implemented these changes (removing interim from GroupI= nfo and confirmed from GroupPublicState) in my draft implementation of #406= [1], and they do work.=C2=A0 I have filed a small spec PR to remove this [= 2] and suggested the corresponding changes in #406.

--RLB

--000000000000dfadc605b21ec158-- From nobody Wed Oct 21 08:38:50 2020 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 B0ED73A0F35 for ; Wed, 21 Oct 2020 08:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmHEcs65xrph for ; Wed, 21 Oct 2020 08:38:46 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 A926A3A0EB7 for ; Wed, 21 Oct 2020 08:38:46 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id o18so3051972edq.4 for ; Wed, 21 Oct 2020 08:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l1+ppa/2OzvCjP9ndFwPJ+8ANkeAKFG/xC5J80CoD+8=; b=iZxXAoBvdn7sRdeHj9HscWD4hZPENmgVf117QkaX4Jtl+lhfOyLYnquBfl7XX9xDfI chtvt2Aa1I1mGtO8lWcFdPa2+/CwgoYSNJJQqATaDIDnrlCHXD6ahVgs5J2UV4vEWCR0 so2bkWkxUUyYxi6JMuIh6yCBcs+czczawy+cwRfbb+HCsm90iiXDxqUcmSOJ7FF2YWEh 2GoAZfdvNelCKRl79W/2lqwSkoP55xd1ZD2RQ6amTYE5FdZmlDAAO3RwM4zP8tKqK6Uo uKI22UW2F7TEUi6RuHK9huN36kFEKxZpDdDUAuNKD93BxVNxTpgMkRpEnUy17Fzmco1I zoeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=l1+ppa/2OzvCjP9ndFwPJ+8ANkeAKFG/xC5J80CoD+8=; b=sEBRyG+u5tRLmRLdNixQwaZirxlqs4a910YV3cvQrFaB8RfCViufaLvDbeG2rUvETY lir2JLg3id+ZgJcsv0eH5PbemB1EO1fOffW0BYHpvvqylyzQ0p2XGSfKSKI7SB0U4J56 cxFe8eTPiy57LnC0EB836Bq+zgFR2Cmns6lAZ8Ed5OFK0eYAxOh9d6hHi/THSWL/HoDJ syrBqNW+11DpoBbTUJXfBSO7iHQe+cjbotCRpmWacwrsMjoax/iZszXdr9pGpe/Pn84j 9O38lc60zkzu5zQHgkPReNpE4+tkVw69/9m4eHyNTzHOhpPMW57ZGycJyiQ6wHPuMb/t w9gg== X-Gm-Message-State: AOAM530OOKTRDFAnMZ3lY6X2cruJuPrPUzptlAqYYpJNPh+wDT8eNrCN rdWekYmLXK7S9tNK24ZA7NBHR8HoWIjWW5vx X-Google-Smtp-Source: ABdhPJwGfN7s7SPv9RDdLdUjk+fEGYwpNpzYodSHiQM1we5MkFpGUEctkBA2VlIWCft5gBmCOn4Rjg== X-Received: by 2002:a50:d642:: with SMTP id c2mr3801562edj.342.1603294724926; Wed, 21 Oct 2020 08:38:44 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id v1sm2204638eds.47.2020.10.21.08.38.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 08:38:43 -0700 (PDT) From: Raphael Robert Message-Id: <5C460254-14C4-4900-9089-16D670C5424A@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_529FB77B-6A4C-45D7-A6B1-F3C42810CBBB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 21 Oct 2020 17:38:43 +0200 In-Reply-To: Cc: Messaging Layer Security WG To: Richard Barnes References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Overflow discussion on #406 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 15:38:49 -0000 --Apple-Mail=_529FB77B-6A4C-45D7-A6B1-F3C42810CBBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for writing this up, see my comments inline. > On 20 Oct 2020, at 20:53, Richard Barnes wrote: >=20 > Our interim call went about 30min past our scheduled end time today. = Since we were without chairs for the last 30min, that time was not = official WG time, so we couldn't make decisions about PRs. Luckily, we = only had one PR remaining, and we couldn't come to agreement on it = anyway :) >=20 > Two remaining questions on PR#406, where the first is more important: >=20 > 1. Should the GroupKeyPackage / GroupPublicState be signed? >=20 > On the one hand, having a signature would remove any concerns about = copy/paste recombination of the various constituent parts. In = particular, it would avoid the public key for one group being reused = with another (up to reuse of signature keys across groups). >=20 > On the other hand, Raphael expressed some concern about deniability, = since this would be a public signature by a member of the group over the = whole state of the group. >=20 > Personally, signing seems like the conservative option to me. But I = haven't done much analysis here. Joel brought up a question regarding tree signatures yesterday, that he = said he=E2=80=99d describe on this list shortly. I see a lot of overlap = between these discussion and would like to wait for that discussion to = unfold before jumping to conclusions here. >=20 > 2. Which transcript hash(es) should be included? >=20 > (This is more of an engineering question than a security question) To = summarize how the transcript hashes / confirmation tag work: >=20 > confirmed =3D H(interim || all_of_commit_besides_confirmation_tag) > confirmation_tag =3D MAC(confirmation_key, confirmed) > interim =3D H(confirmed || confirmation_tag) >=20 > In a GroupInfo / Welcome based join, the joiner needs the confirmed = transcript hash but not the interim. The confirmation tag is provided = in the GroupInfo and verified by the joiner, and can then be used to = compute the interim transcript hash. (This is a side effect of #416, = which moved the signature from interim to confirmed) In other words, = the joiner starts at the second line above, since they don't actually = see the commit. >=20 > In an GroupPublicState / Commit based join, the joiner is computing = the commit, so they start at the first line. As a result, the joiner = needs the interim transcript hash, not the confirmed transcript hash. >=20 > I have implemented these changes (removing interim from GroupInfo and = confirmed from GroupPublicState) in my draft implementation of #406 [1], = and they do work. I have filed a small spec PR to remove this [2] and = suggested the corresponding changes in #406. This looks fine to me, the hashes are now swapped in the PR. Raphael=20 >=20 > --RLB >=20 > [1] https://github.com/cisco/mlspp/pull/118 = > [2] https://github.com/mlswg/mls-protocol/pull/428 = __________________________= _____________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_529FB77B-6A4C-45D7-A6B1-F3C42810CBBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for writing this up, see my comments inline.

On 20 Oct 2020, at 20:53, Richard Barnes <rlb@ipv.sx> wrote:

Our interim call went about 30min past our = scheduled end time today.  Since we were without chairs for the = last 30min, that time was not official WG time, so we couldn't make = decisions about PRs.  Luckily, we only had one PR remaining, and we = couldn't come to agreement on it anyway :)

Two remaining questions on PR#406, = where the first is more important:

1. Should the GroupKeyPackage / = GroupPublicState be signed?

On the one hand, having a signature would remove any = concerns about copy/paste recombination of the various constituent = parts.  In particular, it would avoid the public key for one group = being reused with another (up to reuse of signature keys across = groups).

On the other hand, Raphael expressed some concern about = deniability, since this would be a public signature by a member of the = group over the whole state of the group.

Personally, signing seems like the = conservative option to me.  But I haven't done much analysis = here.

Joel brought up a question regarding tree signatures = yesterday, that he said he=E2=80=99d describe on this list shortly. I = see a lot of overlap between these discussion and would like to wait for = that discussion to unfold before jumping to conclusions = here.


2. Which transcript hash(es) should be = included?

(This = is more of an engineering question than a security question)  To = summarize how the transcript hashes / confirmation tag work:

confirmed =3D H(interim || = all_of_commit_besides_confirmation_tag)
confirmation_tag =3D MAC(confirmation_key, confirmed)
interim =3D H(confirmed || = confirmation_tag)

In a GroupInfo / Welcome based join, = the joiner needs the confirmed transcript hash but not the = interim.  The confirmation tag is provided in the GroupInfo and = verified by the joiner, and can then be used to compute the interim = transcript hash.  (This is a side effect of #416, which moved the = signature from interim to confirmed)  In other words, the joiner = starts at the second line above, since they don't actually see the = commit.

In an GroupPublicState / Commit based join, the joiner is = computing the commit, so they start at the first line.  As a = result, the joiner needs the interim transcript hash, not the confirmed = transcript hash.

I have implemented these changes (removing interim from = GroupInfo and confirmed from GroupPublicState) in my draft = implementation of #406 [1], and they do work.  I have filed a small = spec PR to remove this [2] and suggested the corresponding changes in = #406.

This looks = fine to me, the hashes are now swapped in the PR.

Raphael 


--RLB

[1] = https://github.com/cisco/mlspp/pull/118
[2] https://github.com/mlswg/mls-protocol/pull/428
_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_529FB77B-6A4C-45D7-A6B1-F3C42810CBBB-- From nobody Thu Oct 22 10:50:16 2020 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 1DE333A09F9 for ; Thu, 22 Oct 2020 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv9ODSy4pwjt for ; Thu, 22 Oct 2020 10:50:12 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 88E873A09BE for ; Thu, 22 Oct 2020 10:50:12 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id c5so1801036qtw.3 for ; Thu, 22 Oct 2020 10:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YyuAJu2m1hoCDHbSeV2PTTUywkSxst33sicQ8gQXz4c=; b=1pnXL9t9duWjZs6Y13MuDQe8cl7bslebYpHmNVGDxTOk0KOwZD7pCeKg+VDDsSNXlP sZyt9HPJX2+uSTr3XP8t5VnAZ07nU/qhIEoFK997PYe4JDuVzQRrwKWh1Xu5hy8ndMu5 FESkneNpsvqeWkVukG/ROY5dYK4VQOO/TO3PeYHOBzzsLfI66GKamoxIN/WBKOWd451r NBH7QPNDrSmagJ9Q2SrC2tF477jQ3TtrRmCm27HJxzww4Akqp5OByzqCgxvigl7edivJ 44aBqLrJRlKTw8qCCwg0secPfUpgzV1+IEh4VbSCyFcjjazu6tmC8Vm3iiYhRbOtrJ+W TNnQ== 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=YyuAJu2m1hoCDHbSeV2PTTUywkSxst33sicQ8gQXz4c=; b=qR+DlCVIC3g45uNW/PedpQWxDJRHqRJj4bfxYsJ4YsRfszCqjlHLvH42fblzJAM91D FO5AZc7/YrhFqfYYU9gzok0GIkmvYT1vhgMu6ehokTWgGsvXKRGWs5vYZEKx/77rQirc zT1ipohS7ZEfwYyJ6Et2uYs+Eg0q0CYboZp9TRS2f159l2yhg4Iz54NEtJyZcnKl8M0M FxJ2f03ReB2IYPokq5l89A1o3FziK35yBoGT/UUsSvK9Au/Aye9nmjs9QBs8/+WsuXHf P3RwIspEcLdQr6+COLJ2qV/k3MyXmLfO4hSYrZB9lS1mhixggg7o9wxhzqsZt3RKeJx8 ZGWg== X-Gm-Message-State: AOAM5326mb2IkbHMFz/NHHEpysxDy26sj8NL3lLk9FpfCxqCGgpGylhc Bgu2x94nz2CQcQ0CfQlFwJv8uEhsI8YFgqE/pZumLXdNaf7XEA== X-Google-Smtp-Source: ABdhPJwnZHWtc4pZiUwc0LJQOot4Jowc/y6GPJsgqL1T+bTL3LdEiX8pNer2T2tv873/Fk7tDjP92AygKyTiEBjTpXk= X-Received: by 2002:ac8:74d:: with SMTP id k13mr3109226qth.191.1603389005915; Thu, 22 Oct 2020 10:50:05 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Thu, 22 Oct 2020 13:49:49 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000227edc05b2461884" Archived-At: Subject: [MLS] Deniability as external to the MLS protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 17:50:14 -0000 --000000000000227edc05b2461884 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, Some recent and soon-to-be-proposed changes involving signatures over the group's ratchet tree have raised concerns about the deniability of the protocol. I'd like to propose that we can safely punt deniability to a different layer, and not worry about it in the core protocol. The basic idea here is that signing keys only need to be denied to the degree they are associated with an identity, so if the Authentication Service is deniable, all artifacts generated by MLS are as well. For example, supposed an application were set up in the following way: * Signature keys are only used with a single group (thus so are KeyPackages= ) * MLS credentials have no meaningful identity data (e.g., BasicCredential with identity=3DH(public_key)) * Group members authenticate one another by exchanging signature public keys over a 1:1 deniable channel (e.g., X3DH) (Here we have instantiated a distributed, deniable Authentication Service as a full mesh of 1:1 deniable channels.) In this setup, as far as an external observer knows, the whole group could have been generated by a single participant, which seems like a not-bad definition of deniablity. The MLS messages could be generated by anyone holding the relevant signature private keys, and the deniable signature key distribution means that anyone in the group could be the holder of those private keys. This model is still compatible with things like pre-publishing KeyPackages for asynchronous add. You could obviously do an "add first, authenticate when the joiner comes online" scheme. You might also be able to do something more proactive by pre-publishing some deniable data along with the KeyPackage. My goal here is to argue that there is at least one way of operating MLS in a deniable mode, pretty much regardless of what the protocol itself does. If this argument seems plausible to folks, it should then be safe to make some changes that had been gated on deniability concerns: * Updating #406 so that the GroupPublicState is signed by the member that issues it * Updating the path hash / parent hash scheme as recommended in Jo=C3=ABl's forthcoming proposal (and which I expect will look like what Benjamin and Karthik suggested back in January) I would also be open to adding something like the above discussion to the architecture document, if people thought it would be useful for posterity. Best, --Richard --000000000000227edc05b2461884 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

Some recent and soon-to-be-proposed change= s involving signatures over the group's ratchet tree have raised concer= ns about the deniability of the protocol.=C2=A0 I'd like to propose tha= t we can safely punt deniability to a different layer, and not worry about = it in the core protocol.

The basic idea here is that signing keys on= ly need to be denied to the degree they are associated with an identity, so= if the Authentication Service is deniable, all artifacts generated by MLS = are as well.

For example, supposed an application were set up in the= following way:

* Signature keys are only used with a single group (= thus so are KeyPackages)
* MLS credentials have no meaningful identity d= ata (e.g., BasicCredential with identity=3DH(public_key))
* Group member= s authenticate one another by exchanging signature public keys over a 1:1 d= eniable channel (e.g., X3DH)

(Here we have instantiated a distribute= d, deniable Authentication Service as a full mesh of 1:1 deniable channels.= ) =C2=A0In this setup, as far as an external observer knows, the whole grou= p could have been generated by a single participant, which seems like a not= -bad definition of deniablity.=C2=A0 The MLS messages could be generated by= anyone holding the relevant signature private keys, and the deniable signa= ture key distribution means that anyone in the group could be the holder of= those private keys.

This model is still compatible with things= like pre-publishing KeyPackages for asynchronous add.=C2=A0 You could obvi= ously do an "add first, authenticate when the joiner comes online"= ; scheme.=C2=A0 You might also be able to do something more proactive by pr= e-publishing some deniable data along with the KeyPackage.
My goal here is to argue that there is at least one way of operatin= g MLS in a deniable mode, pretty much regardless of what the protocol itsel= f does.=C2=A0 If this argument seems plausible to folks, it should then be = safe to make some changes that had been gated on deniability concerns:
<= br>* Updating #406 so that the GroupPublicState is signed by the member tha= t issues it
* Updating the path hash / parent hash scheme as recommended= in Jo=C3=ABl's forthcoming proposal (and which I expect will look like= what Benjamin and Karthik suggested back in January)

I would also b= e open to adding something like the above discussion to the architecture do= cument, if people thought it would be useful for posterity.

Best,--Richard
--000000000000227edc05b2461884-- From nobody Thu Oct 22 11:38:35 2020 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 B990D3A097E for ; Thu, 22 Oct 2020 11:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpQR0-aKn0uP for ; Thu, 22 Oct 2020 11:38:32 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 585E93A097C for ; Thu, 22 Oct 2020 11:38:32 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id z5so3782367ejw.7 for ; Thu, 22 Oct 2020 11:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nXy0kyEkheIhxGKCb8HEfC9d3ciHao1VbsZXoQNuKEw=; b=fzDHIUi62GFUGaDZD6M2ujpVZ8EIusiXtLlhuqPHQPGktrCgObKYooLLRSnuOu+qMG osH3rsNNhUSgT5PIHMiQyF/VDjws4Uxmn6eTFpRL9JD79TZgGitEaupYDgLpAB5fXSDI UvNg0ELpv9k233PusRiANItTByxegURSK5K9s62kLFudEOM3l3fXE7yl6R/L7ugFJ1i9 zUz4Wi6CKzYEqY7jNtg0sOt+/l6YB67Rf/3CmYeB/jehcP1j7R25IlnJg1wXW1gRhIOO wYwhoYoW6viO2DJUi7E+K92Od/Yn2WCnCKcMyUHG57m5FydjhMeBXPoSvZAivEaK1zaV Z0Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nXy0kyEkheIhxGKCb8HEfC9d3ciHao1VbsZXoQNuKEw=; b=EuP8ya9JInQUVq7WZyewQNGLNQp7CniG/NGLWfTjtX64aWOGYHbZENKt3fTnDnxBnp E+QIb9+DEElpf3qxn3IwENB3iP0cVKT0OiIqvne3/KDFUVW+xuFrSQz1w1P8iBRetrUr qUVFkf584qOGjzMZ8WWFAjAJ5kpBOi7GK3YnodkkypFBnkpGcQPJtubywgNcuXYQR3E6 jRJ42e0yQMSgDsY7d+cT+/i4BSvoLsnMooXw/onW4DH6+j0EHLn6LgzXGEq0Z3PJIkCO 5T11CDgrvTcSQZBiWGydqJ9ETjptiDOYhIu7kUVXfkLNOnl0lzzXIsHujDZGKeMWNpKX hPZQ== X-Gm-Message-State: AOAM530IU6YkplEh3fpBs0NnhLV6zmRyWBkLeCKKOF8vVdtFWGZFMIqd qKvPovhfHOoMt9/I1vRon6e/cV62bWehArcgJfvzoQX1 X-Google-Smtp-Source: ABdhPJz5amzYVs+33eyik8KptiMyyNKefeAzaiYJpomkc6nJSbVxl0laLpAyL/9cdnI3/UPkAgDPYDpFpxuryowMa4c= X-Received: by 2002:a17:906:2894:: with SMTP id o20mr3515362ejd.221.1603391910816; Thu, 22 Oct 2020 11:38:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chelsea Komlo Date: Thu, 22 Oct 2020 12:38:19 -0600 Message-ID: To: Richard Barnes Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000047b2f305b246c5ad" Archived-At: Subject: Re: [MLS] Deniability as external to the MLS protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 18:38:35 -0000 --00000000000047b2f305b246c5ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, This approach of per-conversation non-attributable signing keys ensures "conversation/participation unlinkability", which implies deniability. This is certainly a viable option for implementations at a level above MLS, with the caveat that it has sharp edges as nothing in MLS forces signing keys to be used for exactly one group. Further, ensuring both async conversations and single-use-keys may be tricky. It would be great for future versions of MLS to think about how to move deniability within the protocol itself, but most importantly I think it is best to keep the core protocol simple to understand and implement. Allowing deniability protections to be implemented at a layer above MLS seems like a good compromise towards finalizing the first version of the protocol. Best, Chelsea On Thu, Oct 22, 2020 at 11:50 AM Richard Barnes wrote: > Hey all, > > Some recent and soon-to-be-proposed changes involving signatures over the > group's ratchet tree have raised concerns about the deniability of the > protocol. I'd like to propose that we can safely punt deniability to a > different layer, and not worry about it in the core protocol. > > The basic idea here is that signing keys only need to be denied to the > degree they are associated with an identity, so if the Authentication > Service is deniable, all artifacts generated by MLS are as well. > > For example, supposed an application were set up in the following way: > > * Signature keys are only used with a single group (thus so are > KeyPackages) > * MLS credentials have no meaningful identity data (e.g., BasicCredential > with identity=3DH(public_key)) > * Group members authenticate one another by exchanging signature public > keys over a 1:1 deniable channel (e.g., X3DH) > > (Here we have instantiated a distributed, deniable Authentication Service > as a full mesh of 1:1 deniable channels.) In this setup, as far as an > external observer knows, the whole group could have been generated by a > single participant, which seems like a not-bad definition of deniablity. > The MLS messages could be generated by anyone holding the relevant > signature private keys, and the deniable signature key distribution means > that anyone in the group could be the holder of those private keys. > > This model is still compatible with things like pre-publishing KeyPackage= s > for asynchronous add. You could obviously do an "add first, authenticate > when the joiner comes online" scheme. You might also be able to do > something more proactive by pre-publishing some deniable data along with > the KeyPackage. > > My goal here is to argue that there is at least one way of operating MLS > in a deniable mode, pretty much regardless of what the protocol itself > does. If this argument seems plausible to folks, it should then be safe = to > make some changes that had been gated on deniability concerns: > > * Updating #406 so that the GroupPublicState is signed by the member that > issues it > * Updating the path hash / parent hash scheme as recommended in Jo=C3=ABl= 's > forthcoming proposal (and which I expect will look like what Benjamin and > Karthik suggested back in January) > > I would also be open to adding something like the above discussion to the > architecture document, if people thought it would be useful for posterity= . > > Best, > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000047b2f305b246c5ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

This appro= ach of per-conversation non-attributable signing keys ensures "convers= ation/participation unlinkability", which implies deniability.

This is certainly a viable option for implementations at = a level above MLS, with the caveat that it has sharp edges as nothing in ML= S forces signing keys to be used for exactly one group. Further, ensuring b= oth async conversations and single-use-keys may be tricky.

It would be great for future versions of MLS to think about how to= move deniability within the protocol itself, but most importantly I think = it is best to keep the core protocol simple to understand and implement. Al= lowing deniability protections to be implemented at a layer above MLS seems= like a good compromise towards finalizing the first version of the protoco= l.=C2=A0

Best,
Chelsea

On Thu, Oct = 22, 2020 at 11:50 AM Richard Barnes <rlb@i= pv.sx> wrote:
Hey all,

Some recent and soon-to-be-proposed c= hanges involving signatures over the group's ratchet tree have raised c= oncerns about the deniability of the protocol.=C2=A0 I'd like to propos= e that we can safely punt deniability to a different layer, and not worry a= bout it in the core protocol.

The basic idea here is that signing ke= ys only need to be denied to the degree they are associated with an identit= y, so if the Authentication Service is deniable, all artifacts generated by= MLS are as well.

For example, supposed an application were set up i= n the following way:

* Signature keys are only used with a single gr= oup (thus so are KeyPackages)
* MLS credentials have no meaningful ident= ity data (e.g., BasicCredential with identity=3DH(public_key))
* Group m= embers authenticate one another by exchanging signature public keys over a = 1:1 deniable channel (e.g., X3DH)

(Here we have instantiated a distr= ibuted, deniable Authentication Service as a full mesh of 1:1 deniable chan= nels.) =C2=A0In this setup, as far as an external observer knows, the whole= group could have been generated by a single participant, which seems like = a not-bad definition of deniablity.=C2=A0 The MLS messages could be generat= ed by anyone holding the relevant signature private keys, and the deniable = signature key distribution means that anyone in the group could be the hold= er of those private keys.

This model is still compatible with t= hings like pre-publishing KeyPackages for asynchronous add.=C2=A0 You could= obviously do an "add first, authenticate when the joiner comes online= " scheme.=C2=A0 You might also be able to do something more proactive = by pre-publishing some deniable data along with the KeyPackage.

My goal here is to argue that there is at least one way of ope= rating MLS in a deniable mode, pretty much regardless of what the protocol = itself does.=C2=A0 If this argument seems plausible to folks, it should the= n be safe to make some changes that had been gated on deniability concerns:=

* Updating #406 so that the GroupPublicState is signed by the membe= r that issues it
* Updating the path hash / parent hash scheme as recomm= ended in Jo=C3=ABl's forthcoming proposal (and which I expect will look= like what Benjamin and Karthik suggested back in January)

I would a= lso be open to adding something like the above discussion to the architectu= re document, if people thought it would be useful for posterity.

Bes= t,
--Richard
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls



=
--00000000000047b2f305b246c5ad-- From nobody Fri Oct 23 02:59:56 2020 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 CF1EF3A0B37 for ; Fri, 23 Oct 2020 02:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 YZBLrpdoED32 for ; Fri, 23 Oct 2020 02:59:53 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 C31EA3A0B36 for ; Fri, 23 Oct 2020 02:59:52 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id n15so1144457wrq.2 for ; Fri, 23 Oct 2020 02:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Pso9avB9YvlPPzakSxvJstgBPIgXq9/TxtALwUchJpM=; b=Ne4TeGhLySXzLh/OnmxsSV4sak664BvcSyDJ6tPR7jW4YxPm81bDvBWr+Eil44nxwE 1lVey9RmN1RBS77+DhemOEV34atG7YCBOfy987NQJBRTaBTli378vT0mD58Lg9+qOaah fpgXEN2kIdfMUa3JhK/8d7jxJVSH3/q/s5bWOkLzGOTUwe4SAhAj4nozEN/BAjbz4xrn ooz6KBeqwvgZDRud6QHqp7ed2N7bvWKI/uAkDPvIWpXLmJY7nE1Vx5ntWDjZxggkjgSW qDpT2k2EeUtTgRVs41I5OMT08Xu3YRqmTUHGyZQpB2KgTIw/u/7PiiXAmfNXQZa8zDlg AZNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=Pso9avB9YvlPPzakSxvJstgBPIgXq9/TxtALwUchJpM=; b=jvd6822ZiBnJgmYrhilO797fJ8sotDuScPzf8+nq++2R7z+8/5IV3DVKpT8KuM0DjA DS+e2I7RUs5EtQyUKhTWcif73ubw2EuMTSjlv7+AlK+bMbrBPHLDrb+sQQRDRJ/6Lt/D h4X2o+XnpsJPUnIBFqtl+jxUUaMtHRl/z68Uf1ZXPuUxseOGA+9GRu99QU6y1qs43n6X P6sOHv+IEjNG9oTFLv1GtbfjN6cMTU7fM7vVMamTcyjuDaZkL1UwK1ib1vO8wSSb34Dy +M7ngalMkIFwiixi47XXY06GdiatubTwBvC5KDbK1YjKBn/3oRnS9PRdwldhCgTQP8cr fhHg== X-Gm-Message-State: AOAM533lHEjXstYVR05hNWxDxOsjuY1Y7T2VVTlfV7SK9GE93qkp15p8 eT9/u8aSCyJhMXTEa4DkoeibjQ== X-Google-Smtp-Source: ABdhPJzEs8zWd29SoKC3rRh6tlNMKiSCEDps9o3IKCx8pbtlMu0znTuUhDzLfFiizTaceoykSZhoMA== X-Received: by 2002:a5d:5090:: with SMTP id a16mr1637661wrt.281.1603447191084; Fri, 23 Oct 2020 02:59:51 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id c14sm2196746wrv.12.2020.10.23.02.59.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 02:59:50 -0700 (PDT) To: Messaging Layer Security WG Cc: Jost Daniel , Marta Mularczyk From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <7b86078a-55dc-7d80-0a75-e900bed61694@wickr.com> Date: Fri, 23 Oct 2020 11:59:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] On the Insider Security of MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 09:59:55 -0000 Hey Everyone, Daniel Jost, Marta Mularczyk and I wanted to let you know about the results of some analysis we've done for MLS. There's a fair bit to unpack here (so please forgive the long email) and we encourage you to look at the full writeup [1] but we'll try to summarize the most salient points here. Also at the end we mention some limitations of our results. [1] Alwen, Jost, Mularczyk - On the Insider Security of MLS. https://ia.cr/2020/1327 What We Analyzed ---------------- We analyzed how the cryptographic core of MLS behaves in the face of insider attacks. By "core" we mean (a CGKA protocol implicit within MLS which includes) TreeKEM, signatures, tree hashing, parent hash, confirmation_tag, membership_tag, transcript hashing and the basic key schedule. We only considered the MLSPlaintext framing mode. Insiders -------- By "insiders" we mean adversaries with all of the following capabilities: - participate in groups as a member (including by deviating from the protocol) - leak other parties entire local states with all their keys - set the output of parties PRNGs (aka. "bad randomness") - control the network completely (think: a corrupt DS) - register/deliver arbitrary Key Packages (again: corrupt DS) - register arbitrary Sig keys with the AS (e.g.: badly generated keys, copied keys, keys for which they don't know the sk, etc.) - the adversary orchestrates the execution as they see fit: e.g. the can tell Alice to propose adding Bob, Charlie to commit and then have the network deliver packet P to Dave. - the adversary is fully adaptive; at each moment during the execution the adv. can decide which action to take next based upon their entire view of execution up to that point. Security Property ----------------- Our goal was to determine when a given epoch_secret is secure. In other words, given a complete execution (in particular, the adversary’s actions) decide if a particular epoch_secret is guaranteed to be secure. We encoded the security guarantees we could prove using a "safe predicate" which takes as input an execution and a particular epoch and returns true/false indicating if that epoch_secret is secure. What We Found ------------- By and large, the privacy and authenticity guarantees are what we hoped for from MLS (especially with the inclusion of membership_tags for MLSPlaintext proposals). Still, there were at least 2 surprises for us 1) "Weak vs. Strong Tree Authentication". See subsequent email with that subject for more on this as we might consider changing how tree_hash and parent_hash are computed in light of what we found. But in a nutshell, we show that MLS has weaker security guarantees than maybe expected for parties joining a group because of how MLS defines parent_hash. We analyzed security for the original proposal for parent_hash and the one MLS uses now and found that the former provides strictly stronger guarantees for new members. Nor is this an issue with limited proof techniques. We found attacks that work against MLS now but not if we define parent_hash to include tree_hash as first proposed. 2) ECDSA vs. EdDSA : We found that we could have proven stronger security if only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produced with a bad PRNG (i.e. not enough entropy) can result in sigs that reveal the signing keys. EdDSA signatures are deterministic and so aren't susceptible to this. ECDSA can also be de-randomized (RFC 6979) to avoid the problem. Other Conclusions ----------------- We still think that MLS would benefit significantly from: 1) Better hardening against bad randomness. (This can be done cheaply, simply & doesn't have to break compatibility, yet has a clear & quantifiable benefit for security. PR incoming with a generic & protocol specific trick for doing just that...) 2) Including a separate HPKE key in KeyPackages in DS for encrypting the welcome message secrets (rather than using the initial leaf HPKE key for that purpose as done now). - Daniel, Joël, Marta Some Limits Of Our Results -------------------------- - We analyzed security of a single honestly generated group, running concurrently with any number of adversarially generated "fake" groups. But we didn't analyze how concurrent honestly generated groups might interact. (To be clear, that's only to keep the results tractable, not because we think there's some kind of deeper problem precluding meaningful security in the more general setting.) - We didn't consider MLSCiphertext framing. Intuitively, that mode "only" adds better meta-data protection compared to MLSPLaintexts. Metadata hiding was outside the scope for us. We focused on privacy and authenticity for MLSPlaintext for now with the understanding that MLSCiphertext framing provides at least as good security in those terms. So what we show applies to both types of framing. - We didn't analyze full Secure Group Messaging, only the core CGKA functionality. (Although we feel it's pretty easy & immediate to extend our CGKA results to meaningful security statements for the full SGM protocol.) We also don’t cover any of the “extended features of MLS”: e.g. exporter keys, PSKs, external proposals & commits, state recovery procedures, protocol downgrade/upgrades etc. MLS is a beast. Much remains to be covered. (But we do think that, as with SGM, the core analysis we’re reporting on can reasonably easily be extended to cover several, if not most, of those features.) For more on what we left out / simplified see Section 4.5 in the writeup. - Our safe predicate isn't tight. But it only errs on the side of caution. I.e. whenever it says an epoch_secret is secure we have proven this to be the case (in our adversarial model of course). But sometimes it says an epoch_secret is *insecure* although it actually still is. This is due to a few things: 1) The predicate doesn't account for parties’ position in the ratchet trees. Sometimes, an attack may or may not reveal an epoch_secret depending on the order of the leaves people are assigned to in the ratchet tree. For simplicity, our predicate always assumes the worst case ordering (from a security perspective). 2) The safe predicate pessimistically assumes that just 1 sig produced by an honest party using bad randomness already leaks the parties signing key. Of course, that might not really be the case, e.g. (if EdDSA is being used, etc). From nobody Fri Oct 23 03:00:09 2020 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 80D1A3A0B45 for ; Fri, 23 Oct 2020 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 oRU_98RfdVbz for ; Fri, 23 Oct 2020 03:00:05 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071723A0B62 for ; Fri, 23 Oct 2020 03:00:05 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id l20so227555wme.0 for ; Fri, 23 Oct 2020 03:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:cc:from:subject:autocrypt:message-id:date:user-agent :mime-version:content-language; bh=+2uFyL6V48crF8rpmhqpJNu+bcYYExBjO9Ie04sKHLQ=; b=rQu3WeOOwrLcqcRIqoh/qCaZ10NVsicGTZtqDRTdrqRiDrJcr6MccpUIBax4AWA05m eN+jbhIKbTe7kmbkFri0TxyfvKXWepKYHvCJK5VYPjAm816MdWWIYRm743r9BUATgCNO vVOWzt9zkPthVqu50V35pmsDkpQdbyQT6T/X0IL1Wrk/WVnVSx9rqtMu/4kHSCk9UA2S sh9fp+wK7hS1RhuHj0eBgFQhshNfQAaXgdFVmYbS4TWD1demvI2zaxnRuhjZDNgNMoYH u+kFrg1m4I1SBTiMOvwSigk4tf+KHla4ofOgR4BrjKZl1/RP7xYr8z8eVwOERCbgkUl7 6OZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language; bh=+2uFyL6V48crF8rpmhqpJNu+bcYYExBjO9Ie04sKHLQ=; b=oxkUK3MIdfW2mkyQJ1xBNIpBl62AYBIBvc8Xq9apfFv9Bm2OiV3v3XPivhaUtcerIm Skg42KaLzmPxRtFBe8UJEQforpDSfABQZ0kbetYR0DoY6u6/ulglbSOgEA0lImfYeR2V EdM80TXTFLadlpfCPfxDwbnv5oe6LoDHDzWfyploabCsGUatJRgLWxo/itLF90BCf3oM /Zq7dfw1RO8SI2SFKiQl5wW8g1soCf0WWS6rJdIq3uzZnyDZy1cWe3Xh9wYwDPYIM8Bx 75nJViWsSsQ4pjIdP91cuYPbDO659gTONXtg3+OrCA5ijsn29s/fSQLvOETjMDX/1yry 7K9Q== X-Gm-Message-State: AOAM530suw1Jkrjrgu3PkyjbVLj1/PHr8e+vz8S/4mRdlP9F9QNbGIxE Dik/1nNKnGcMZoVCH93Q+1xEyw== X-Google-Smtp-Source: ABdhPJxDx357JXocNXQYHlseq1j+YTAjWolrxNapyXmnvbBLJWijZlvWSGMNlkJVgeVOPyA7KPfSzw== X-Received: by 2002:a7b:cd96:: with SMTP id y22mr1533103wmj.126.1603447203281; Fri, 23 Oct 2020 03:00:03 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id y4sm2299225wrp.74.2020.10.23.03.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 03:00:02 -0700 (PDT) To: Messaging Layer Security WG Cc: Jost Daniel , Marta Mularczyk From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: Date: Fri, 23 Oct 2020 12:00:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------D327DA4C35DE5DCC6429AFEE" Content-Language: en-US Archived-At: Subject: [MLS] Weak vs. Strong Tree Authentication X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 10:00:09 -0000 This is a multi-part message in MIME format. --------------D327DA4C35DE5DCC6429AFEE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hey everyone, In the course of our insider security analysis of MLS (detailed in our previous email titled “On the Insider Security of MLS” on the list today and available here [1]) we noticed a trade-off MLS is making between deniability and security that we believe merits extra attention. MLS initially considered two "tree-signing" methods (see below), where method 1 seemed more secure but was less deniable than method 2. MLS went with method 2, since at the time additional security of method 1 was unclear. We now have a much clearer understanding of what we’re giving up by opting for method 2 so we wanted to share that with everyone. Put simply, method 2 provides a fair bit weaker security guarantees for people joining a new (possibly adversarially generated) group than does method 1. [1] Alwen, Jost, Mularczyk - On the Insider Security of MLS. https://ia.cr/2020/1327 Two Constructions ----------------- In more detail, the issue centers on how the parent_hash is defined. A party joining a group authenticates the group’s ratchet tree by verifying the sigs at each leaf. Some of those leaves include a parent_hash value which, in turn, fixes values stored higher up in the ratchet tree. Intuitively, this is meant to provide some security guarantees to the new member. Basically, the hope was that if all keys in a ratchet tree are signed by group members and you trust all the group members you should be in a secure group. It turns out though that exactly how parent_hash is defined is critical to whether we really achieve this intuition or not. We are aware of 2 definitions considered in the past. For lack of better terminology we'll call them: "weak parent_hash" : What MLS does now. parent_hash of a node only covers the HPKE pks on the path from root to the node. Roughly speaking, we have that: - root.parent_hash := 0 - node.parent_hash := H(node.parent.pk, node.parent.parent_hash). "strong parent_hash" : Define parent_hash to include tree_hash (and tree_hash to *not* include parent_hash). The tree_hash of a node covers all values in the subtree rooted at that node (except the parent_hashes and signatures). So basically something like this: - leaf.tree_hash := H(leaf.data) - node.tree_hash := H(node.data, node.lchild.tree_hash, node.rchild.tree_hash) - root.parent_hash := 0 - node.parent_hash := H(node.parent.tree_hash, node.parent.parent_hash). In an effort to preserve a modicum of deniability, the working group opted for the "weak" approach. It was felt that this way a signature at a leaf would only weakly bind the signing party to the session it was signing in. Conversely, signing a strong parent_hash would provide irrefutable evidence that the signing key's owner was in a group with (at least some) of the other members in the group. As far as we know, at the time the security implications of this decision (beyond deniability), were not well understood. Different Security Guarantees ----------------------------- Here's what we found about these 2 variants. Consider an MLS execution where Alice joins a session using a valid looking welcome message and ratchet tree *possibly produced somehow by a malicious insider*. (Think of an “insider” as an attacker that can participate as a group member in MLS sessions, can leak honest parties states at will, and that can completely control the DS and the AS. For a more complete explanation of their capabilities see the email with subject “On the Insider Security of MLS” in this mailinglist.) Alice's session continues, e.g. parties issue proposals, commit and send application messages. We asked ourselves: When (if ever) does the session Alice joined become “secure”? A bit more precisely, when can we prove that (in our adversarial model) the epoch_secret of a given epoch E looks random to the adversary? We answered this by defining 2 properties of the execution that suffice for us to prove such a claim for any given epoch E. Call a signature key pair "leaked" if it's secret key was either chosen by the adversary or explicitly revealed to the adversary in the course of a leaking the key’s owner’s local state. We call a ratchet tree "bad" if at least one leaf is assigned a leaked key pair. - Property 1: The ratchet tree for epoch E is not bad. (When MLS uses strong parent_hashes then this property suffices to prove security for E.) - Property 2: No key pair at a leaf of E was ever part of a bad ratchet tree. This includes ratchet tree's for other epochs in other sessions. (When MLS uses weak parent_hashes then this property suffices to prove security for E.) This difference in what we need to prove security for strong and weak hashes is not just a limit of our proof techniques. In fact, we can build concrete attacks that demonstrate the different guarantees. The attacks succeed against weak parent_hashes but fails against strong parent_hashes. See the end of this email for an example. The Argument for Strong parent_hashes ------------------------------------- In our opinion the difference between the 2 properties is big. Suppose you find yourself in an epoch E and are trying to decide if it’s secure. Property 1 means that E’s security depends only on the security of the keys involved in that epoch; that is keys you can see belonging to parties you are aware of. So if you believe that everyone in E is honest and is using an unleaked key you can already conclude you're getting privacy. But Property 2 means that to reach the same conclusion about E you'd further have to assume the same thing about all sorts of other epochs (of other groups!) which just happen to involve a key pair also used in E. That seems like a *much* worse guarantee. In particular, there's no reason to believe you'd even be aware of all those other groups, let alone who was in them and what keys everyone was using. To us, this motivates switching over to strong parent_hashing. On the flip side we would lose the deniability benefits that the weak parent_hashes give us now. We believe this "loss" to be worth it though. First, our (Joël and Marta) take is that deniability is at most "nice to have" but nowhere near as crucial as privacy and authenticity are. Second, we don't think that even with weak parent_hashes we could make any claims that MLS is deniable in some reasonable and holistic sense. So by giving up this particular mechanism it doesn't look like we're really losing any general deniability feature of the entire protocol. If we want deniability in some form for MLS then we believe we'll have to revisit much of what MLS does anyway. Thus, our take is that we'd rather have a stronger, (in particular more locally based) privacy guarantee when joining a new group than the incomplete deniability guarantee we have now. - Daniel, Joël, Marta An Attack Separating Strong from Weak parent_hashs -------------------------------------------------- The basic vulnerability exploited by this attack is that signing a weak parent_hash only authenticates the HPKE keys on a direct path but not which parties were then told each of the secret keys on that path. This lets an insider that knows many keys on a path construct a new ratchet tree where they seem to only know fewer of the keys (near the root). So when the party is then removed from this fake group some of the secrets they know will remain part of the group state. That in turn lets them compute epoch_secrets even after being removed from the group thus breaking privacy. The attack is described bellow and depicted in the figure attached to this email. Suppose MLS uses weak parent_hashes. 1) Bob is an insider attacker. He's in a group G1 with 3 leaves. From left to right they are assigned to Alice, Bob and Charlie. Alice performs a commit in G1 resulting in ratchet tree T1. (Notice Bob now knows the HPKE sk at the parent of Alice and Bob.) 2) Bob creates a fake ratchet tree T2 with 3 leaves as follows. He copies all nodes from Alice’s leaf to the root from T1 to T2. Next he places a fresh key package for Charlie the sibling leaf to Alice (i.e. Bob’s former leaf in T1). Finally he places himself in the rightmost leaf. He also samples any values he needs for the new groups application key schedule (e.g. an init_secret from a fake previous epoch). Call the resulting group G2. 3) Next Bob creates a proposal to add Dave to G2 and commits to it initiating a new epoch E’. He produces a corresponding welcome message which he sends to Dave. 4) Once Dave joins, Bob proposes to remove himself from the group. Dave commits to the proposal which initiates epoch E. At this point Property 1 for E is satisfied (as T2 only has Alice, Charlie and Dave at the leaves). But in reality, Bob still knows the HPKE sk at the parent of Alice and Charlie as that wasn’t blanked out or overwritten when Dave did his commit removing Bob from T2. Worse, that commit by Dave includes a ciphertext encrypting a secret to the sk which is intended to let Alice and Charlie compute the commit_secret. That lets Bob compute the commit_secret and thus too the epoch_secret for E. So E isn't secure. Notice the above attack fails when MLS uses strong parent_hashes. Copying Alice’s leaf and parent node from T1 to T2 forces Bob to also copy her sibling leaf from T1 to T2. Bob can no longer pretend he is not the sibling of Alice. Thus, when Bob is removed from G2 by Dave the parent node of Alice will be blanked and so Dave will encrypt the secret for the grandparent straight to Alice’s leaf. In other words, Bob can no longer process the commit and he is truly out of G2 as intended leaving E in a secure state. Finally, to add to the discussion in the “Overflow from discussion on #406” email thread, it looks like this attack is *not* prevented by having the GroupKeyPackage signed (e.g. by the sender of a welcome packet = the most recent group member to commit). Dave gets the GroupKeyPackage for G2 from Bob and Bob can create and sign it no problem as he is in G2, knows its key schedule and the whole public part of T2. So everything would check out just fine for Dave. --------------D327DA4C35DE5DCC6429AFEE Content-Type: image/png; name="attack on weak parent hashing.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attack on weak parent hashing.png" iVBORw0KGgoAAAANSUhEUgAACPcAAARuCAYAAAC1aUCOAAAgAElEQVR4AezdCbQsVXkoYCa5 DBJmBJVBZgQFEWRQwQFUEMhDwDgEI2rQiIK8hKhxIBoHfGK8YkCIA6JxgkSNgggRFVEMoiEI DxCJCkiQQXiIMniF/62/b6pP3XN77qo+1ed8dddd1ae7atfeX+2uqr37r10rhIkAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgUYKrNDIXMkUAQIECBAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIhuEclIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQINBQAcE9Dd0xskWAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IEBAcI86QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKChAoJ7GrpjZIsA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQICA4B51gAABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECBAgEBDBQT3NHTHyBYBAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABwT3qAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AIGGCgjuaeiOkS0CBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECgnvUAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQINFRDc09AdI1sECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEBPeoAwQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAgAABAgQaKiC4p6E7RrYIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQICO5RBwgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAg0VEBwT0N3 jGwRIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQENyjDhAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBBoqIDgnobuGNkiQIAAAQIECBAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgILhHHSBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECDQUAHBPQ3dMbJFgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAQHCP OkCAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgoQKCexq6Y2SLAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAgOAedYAAAQIECBAgQIAAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIBAQwUE9zR0x8gWAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIECBAgQIAAAcE96gABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBhgoI 7mnojpEtAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAoJ71AECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECDRUQ3NPQHSNbBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAT3qAMECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgQIAAAQIEGioguKehO0a2CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CAjuUQcIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQINFRAcE9Dd4xsESBA gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIEBDcow4QIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQaKiA4J6G7hjZIkCAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQICC4Rx0gQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg 0FABwT0N3TGyRYAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQEBwjzpAgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoKECgnsaumNkiwABAgQIECBAgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgIDgHnWAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAQEMFBPc0dMfIFgECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAHBPeoAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgYYKCO5p6I6R LQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQKCe9QBAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAg0VENzT0B0jWwQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQE96gDBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECBBoqILinoTtGtggQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgI7lEH CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECDRUQHBPQ3eMbBEgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAQ3KMOECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAgAABAgQIEGiogOCehu4Y2SJAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECAguEcdIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQINBQAcE9 Dd0xskWAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIEBAcI86QIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKChAoJ7GrpjZIsAAQIECBAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQICA4B51gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAgEBDBQT3NHTHyBYBAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB wT3qAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIGGCgjuaeiOkS0CBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECgnvUAQIECBAgQIAAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQINFRDc09AdI1sECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIECBAgQIAAAQIEBPeoAwQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQa KiC4p6E7RrYIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQICO5RBwgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAg0VEBwT0N3jGwRIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQENyjDhAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgQIAAAQIECBBoqIDgnobuGNkiQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgILhHHSBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECDQUAHBPQ3dMbJF gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAQHCPOkCAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQIECgoQKCexq6Y2SLAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAgOAedYAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIBAQwUE9zR0x8gWAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAcE96gAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBhgoI7mnojpEtAgQIECBAgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAoJ71AECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECDRUQ3NPQHSNbBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAT3qAMECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEGioguKeh O0a2CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECAjuUQcIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQINFRAcE9Dd4xsESBAgAABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIEBDcow4QIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQaKiA4J6G7hjZIkCAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQICC4 Rx0gQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg0FABwT0N3TGyRYAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQEBwjzpAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAgAABAgQIECBAoKECgnsaumNkiwABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAgIDgHnWAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAQEMF BPc0dMfIFgECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAHBPeoAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgYYKCO5p6I6RLQIE5k7g7rvvjv/8z/+s /f///b//t2MhTz755Dj22GPjpS99aRxwwAHxlKc8Jfbaa6+Oy3pz4QioFwtnXyspgYUocNpp p8Ub3vCGOPLII+PAAw+MPffcM7bffvuFSKHMBAgsQAHtjwW406egyNofU7CTZJHAAhG49dZb 4y1veUv8xV/8RbzwhS+MZz/72fGkJz0p3vSmN1Uu8Nvf/jbe9ra3xTHHHBMvetGLYv/9948n P/nJcdRRR1W+LQnOjYC259y4T8tWv/SlL8VJJ5000v/3ve99ccYZZ8SXv/zluPnmmxtRZMe0 RuwGmZgCgc9+9rMjfe/zePH+978/Pv3pT8c3v/nNuP3226egtLI47QKCe6Z9D8o/AQKVC3z0 ox+NFVZYofb/66yzTse8b7311rHSSists/2NN96447LeXDgC6sXC2dfTVtKHHnoozjzzzHjr W98aV1111bRlX34bIpDBPCuvvPIy575VVlmlIbmTDQIECNQroP1Rr6/URxPQ/hjNzVoECFQv cMUVV8Saa64ZK6644jLthVe96lWVb+y2225rbWt2v+Dznve8yrclwbkRGLXt2YS+jybkYW72 2uS2moF86623XixatGiZ401xTMg+++zT32CDDZb7v8YaayyzzuMf//jWD/5/+MMfJleAWVua lmPaQqvbc1HeudjmrOrY6D//+I//ONZdd91YddVVl/ke9/vur7322sssn32bz3jGM+IjH/lI PPjgg40us8xNr4Dgnundd3JOgEBNAu9617vaJ+S8KM8RdE4//fT42te+Fpdccklcdtllcfnl l8f3v//9eO9739teNk/0W2yxRVx44YXxgx/8oLXM9773vfjGN77Ritg/4YQTIi/qiwuCnD/w wAMdS/H73/8+PvCBD7SXFdzTkWnBvaleLLhdPhUFPu6449rHqtVXXz1uuOGGqci3TDZPIDu8 MlCsOE8K7mnePpIjAgTqEdD+qMdVquMLaH+MbygFAgSqE/j1r38d+eNb0V6oI7inyO1vfvOb eMUrXtHeluCeQmZ+zEdpezah76MJeZgfNWCwUuQNbI961KPax4EMfL7nnnu6rvzwww/HT3/6 0zj77LNbo4sVx6ott9wyvvjFL3ZdbxIfNP2YttDq9lyUdy62OYm6Xcc28ve/tdZaq/3df+xj Hxs52m636b777ovrr7++9Rtiji5YBCNvtdVWkaOBmQhULSC4p2pR6REgMPUCr3vd61on7jz5 /td//VfP8tx5553tk3xesL/4xS/uuXx++O53v7u9zo033th1+Xvvvbe9nOCerkwT+yB/dHnJ S14yse1129C01ou59pvr7Xfbn/Ph/WzgFB0WOT/llFPmQ7GUYQ4FijvkBPfM4U6waQIEJiqg /TFR7qnZWFOuX7U/RqsyTdl/o+XeWvNdYJrr5+c+97l2+7PO4J6sA9/5znfa2xLcMz+/FcO0 PZvQ99GEPMzPmtC9VM9//vPbx4HnPOc53Rec9cmSJUtajw4s+svyx/5TTz111lKT/bPJx7SF VrdHLe845+9RtznZWtqcre2xxx7t7/5Tn/rUoTJ26aWXxs4779xe//jjj48cOclEoCoBwT1V SUqHAIF5I3DEEUe0TrwXX3xx3zLlc2uLi/Scv/zlL++7Ti5w4IEHttbLEX56TUXagnt6KU3m s4MPPjhy6N4mTNNYL+bab66334R6U1cespOzqJM5z9HKTATGEVh//fVbdUpwzziK1iVAYJoE tD+maW9NLq9Nun4trvWmqV06135zvf3J1VRbmkaBaa6fX/3qV9vtz7qDe/JxYMXxT3DPNNb0 /nkepu3ZhL6PJuShv+r8WuJ//a//NdZxIAOCiuNI9nHkkwDmamryMW2h1e1RyzvO+XvUbc5V fZ3r7T7taU9rf3fz9bBTjoB66KGHttPIY8lcPqJv2PxbvtkCgnuavX/kjgCBORDYZ599Yvvt tx9oy6MG91xwwQWtE3t2SvSaiov/aepE7VWeaf5sxx13FNwzxg6ca7+53v4YdI1f9eabb241 VvKOhHycoInAuAL57Po8/wnuGVfS+gQITIuA9se07KnJ5rNJ16/T2C6da7+53v5ka6utTZvA NNfPc889t/1DWd3BPf/5n//Z3lb+KGqafwLDtD2b0PfRhDzMv1rQu0TjBvf8+Mc/bh9H8noq RwKaq6nJx7SFVrdHLe845+9RtzlX9XWutztucE/mPwN8nvvc57aPASeccMJcF8v254mA4J55 siMVgwCB6gS23XbbePWrXz1QgqMG99x///2x0korxUc/+tGe25nGTtSeBZrSD3/yk5+0LsKM 3DPaDpxrv7ne/mhq1iKwcAWG6WBduEpKToDAfBLQ/phPe7OasjTt+nXa2qVz7TfX26+mFkpl vgpMe/0U3DNfa+bclEvbc27cp2mr4wb35KN41lprrfaP+4985CPnrPhNDu6ZM5Qp2vC0n7+n iLqV1SqCezKhX/ziF7H66qu3jwFf/vKXp41CfhsoILingTtFlggQmFuBtddee+Bn4I4a3JMl fMxjHhP5nNRe07R1ovYqyzR/9r//9/8W3DPGDpxrv7ne/hh0ViWwIAV0sC7I3a7QBBa0gPbH gt79HQvftOvXaWuXzrXfXG+/Y6XyJoH/EZj2+im4R1WuUkDbs0rN+ZnWuME9qbLhhhu2f9jP EYrn6tE8gnumu45O+/l72vSrCu7Jchf7LttU22yzTSxZsmTaOOS3YQKCexq2Q2SHAIG5FcgR dfIk2+9xWUUuxwnuyVFgXv/61xdJdZxPWydqx0JM+ZuXX3555F0VuS+M3DP8zpxrv7ne/vBi 1iBAQAerOkCAwEIS0P5YSHt7sLI28fp1mtqlc+0319sfrJZZaqEKzIf6Kbhnodbeesqt7VmP 63xKddzgnmK0leJaai77lgX3TG/NnA/n72nTrzK450c/+lE7wC+PBf2e5jFtVvI7eQHBPZM3 t0UCBBoscMcdd0Q+RzsvvAeZxgnueec73xnvfe97e26muPDfeOONOy6XUb6Zhyqm//f//l9c eeWV8c1vfrM1v/vuu6tIdqg08jmk+QPH7Onee++Nhx9+ePbbHf/O5W677ba44oor4uKLL45f /vKXHZcb5M30WG+99doXX1U3wPJZtz/4wQ/iggsuiO9973uR9W+QaVrqRd1+/azq2H4VdbTI d9XfuarTK/I5zPw3v/nNMIu3vtf5/e40VXl865R+v/eqPJb029agnzex/tXhNNcdrPfdd1/X O+l+97vfxXnnnRcf/OAH4wtf+EI8+OCDPXdflfssh/P+2c9+1jpf5DkjX+d740zDnF9zO/fc c8/Am8u8dft+5zVG2pgIEIjW9Z/2h/ZH8V2o4/q1SHvUtkeur/1RKPaeV73/qryOyJxX2V6o Mq3eqoN9Ok79LrZQpXdVPlVea1ddPwu3qspapFfM8zq7U79Uk4J7cv/cddddXdsORVmmcZ5l 63Ytn231YdoFuS+zjTXuVOX3ocjLqG3PYfs+iu3lvIrjVaYzSh6mrU2Z5fzVr34VP/zhD+Oi iy6KDE65884725x5/EnPOqdxg3te97rXta+jctSeb3zjG0Nnt6r91i+4pynHtGHrdr/jVVW/ nQy94wZcoV956zh/99vm7KxP0rjKPrnZ5Rjm7yqDe3K7m2yySftY8PSnP33grNRx7ht44yMu WNe14YjZmZerCe6Zl7tVoQgQmJTAOME9g+SxUyfqTTfdFNkw2G677eIRj3hE66Igg3/youBf /uVfBkm2vUxeHHz+85+PZzzjGbHyyiu3RqjZYYcdWvOVVlop9tlnn/jnf/7n9vJVvsiT/EEH HdQaDWfrrbeOddZZp1WWxYsXtzaTP6C++93vbj2+LB3WXHPNVrm7/RiYjb03v/nN8djHPjZW W221ls/222/fMsqRd5761KfGP/3TPw30Q+gZZ5wRf/Inf9L2LfZD5jHzPPv/a1/72oFp8jmr OWLTpptu2r6gy+eurrjiiq2/80LvxBNP7NlRUuSnHPTVpHpRp98g0FVtv+o6mnmv+jtXdXqD +BbLZIBiHjue8IQntBooeTzKjope08tf/vLWsSqPMzkscR53ykFz+f049thjI48JmVbW9VGP b73y0euzKo8lvbbT77Om1786nUbtYO1n2uvzHLHv4IMPji233LJ1PF511VVjxx13jNe85jXx 85//vDVk7jve8Y5Yd9114ylPeUrrPJD185nPfGY72Tr2WSZ+zTXXxCtf+crYaKONWue3bbfd tvUdWbRoUeu9V7ziFa1l2hnp8iK/f3lez3Ll96q4hsh8z56y8/CQQw6J7MzI72tuO7+TeT7t NGUa6bfXXntF5m/99dePvI7IgIWcsvP/fe97X+tcnLZpl+e9fERp5v+SSy7plKz3CBDoIKD9 0QFlwLeqPk5XeS6s6vp1NkUVbY9MU/tjtuyyf1ex/6qun0UOq2wvVJlWkb9x5uPU7zq8q/Rp +vGlyrIWdSCvP88+++xWX8yjHvWodh9J9u88+9nPjnPOOae16FwH9+QPon/7t38bu+yyS/t6 Otu12Y445phj4j/+4z+KIi03/6u/+qt4yUteEq961aviuOOOize84Q3x6le/Ol72spfFEUcc EV/60peWWyffyL6+7KPK6+ZsL+f/o446Kg477LCB+rg6JjrrzVHa6rlv9t577/jHf/zH5W7I yzbMn//5n8fmm2/eahcU1/65L4cNbqjy+zCr2DFI23OUvo/Z2xnneJVpjZuHaWhTls3yevdd 73pXbLXVVq02Y/bpHn744fGc5zyn1f+03377xSc/+clW2/OFL3xhedXKX48T3JN97sU1VM4/ 8pGPDJW/qvZbsdFOwT3jHNOKdMeZj1K3RzleDdK32OkY/Rd/8RetY++LXvSi1o1enco6zDF6 mPJWcX2Z+R1mm0X56jIu0p89r6JPbnaa4/5ddXDPc5/73PbxIK8byoGKnfJaxblvEnW6yHsd 14ZF2ubLCwjuWd7EOwQIEBhYYNKd69lwWWONNVrBITkqTd4hlKMM5Q+ORWMhLzYHmXJEm/wR LtfLQKEM4smTcDFdeOGFkcEx+Xl2MnQLqimWH3aeec+LpHzOaJH3nGdwTzYssuGWP5p+61vf agW7FMtkJ8rs6YYbbojHPe5xrSCDf/u3f1tmJIW8Q+jUU09tj8CTP2zeeuuts5NY5u+jjz46 svGW/7Ojoth2/qhbvF+eZ8fKIFMGK+WPsZne/vvv3ypbcfdSPm/5qquuanUS5ef5Q2oG7HSa ivwUwT1Nqxd1+XWy6PReVduvso5mPqv+zlWdXifLXu+dcMIJ8eQnP7kdhJP1sl9wT35vMhio CGbLdYrgnk9/+tOVHd965bvXZ1UfS3ptq99nTa5/dTsN0sHaz2/Qz2+55ZbW8TjrYp7zPvax j8W1114bV199dZx88smtOplBMHmuyg717JTNKUfvyXUygKW446nqfZbn3ez0z0Z/Hu9zpKDy 6HYPPPBA6weQzFsuk+eiXufq/P7ljxDl71+WIX/cmj3ljysZNFxcB+Ry+b9bcE+WPc+vT3zi E1smxfIZ3JP5zvNnfpamecdl/ujxuc99rnQnSiIAACAASURBVHWeL5bNYKJ+nRuz8+lvAgtR QPtj9L1e5XG66nNhVdevZZ2q2h6ZZnGs1v4oC8+8rmL/VVk/i5xV2V6oMq0if+PMx63fVXtX 6dP040uVZS3qQAZ6F9ed2V781Kc+1Wo/Z39OXn9n8MgWW2wRL3jBC+LjH/94+5iUQTJ1TrN/ CP/6178em222WTz/+c+PL3/5y60+m+zTyR/g/+7v/q7V75TX2i996Us73rB1/PHHt26Q+aM/ +qN2GfL4muvkDQTdbtj77Gc/274hrjger7XWWq2gp7xur2Iat62ebaXs18op+/XyBr23vOUt cemll7Yssr8r2zZF/tNikKnq78PsbQ7S9hyl76O8nXGPV5nWqHmYpjZlYZYjduUNJnnTSKdA sKzz2cZce+21W/Up626dU6Zf1Nvi5pV+28t2bd4Imu30XDf7rDN4YdCp6v1WbLfqY1qR7jjz Uer2uMerbr+d5HEpf4so6lax33M/Zt9lt32Yx+jZ63Q7Rg9T3iquL3PfDLPNYl/WZVykX8yr 7JMr0qxqXnVwT/kcmHXri1/8YtesVnXum0SdzkLUcW3YFccHLQHBPSoCAQIExhCYZOf6mWee 2epEyAZxpynv9ikuOntdHOS6+SiPYijADPDJcnSaMkK4GGEmI7brmvJu/iLv2QmQd11kNHN2 5OSUP/gVnx944IHLZSPzlp/nD7B5Qd1pykeYFI2qnXbaqWNHS6f1siFZbLsIQui0XK/3Mmgq 78TKdLLT5q1vfWvXu6t233339vbe9KY3dUy2yE92rje9XlTh1xFhwDer2v64dbTq71zV6Q3I 2XGxcudAv+CeIoF8FF1Rj/N79ZnPfKay41uxjVHmdR5LRslPsU7T6l/dToN0sBY248zzHJP1 L+tiBp4UQTrlNPPu4SIYphxcmp34eVx/z3veU168/XrcfZZBPDkyVuYtO5fycZPdphzpLpfJ ZTPApgga7bZ8BvMW37+cdwruKa9b/gGlW3BPefmzzjqrnX4un3f0/sM//MMyAcTF8nl+zDuJ ivzkjzY5UpKJAIHuAtof3W2G+WTc43Sd58Jxr1+rbnuka3Gc1v7oX8vG3X+5hXHrZ6ZRZXuh yrT6C/Zeoo76Pa531T5NPr5UXdbc26eddlr7hpEcyaZbsEo+xjyvdYt+nTwuTTK4J2+0y6Cc bgE4WZYMRCqClPImuvzRstOUfW1Fn1yWY5DRoP/rv/6r3S7J/r9sA9QxjdNWz3b9hz70odYN PVlXOk052meWOdtYGfjTb6rz+5DbHqbtOWzfRx3Hq2HyMK1tyiOPPLJVR66//vqe1aNo104y uGfXXXeNHD2s0/8cLT4D2g499NBWMF72UedIVR/+8If7ttHLBa1zv5XrT5XHtHL+R31dzttc 9y3mMTpHkCuuf9/4xjf2LVYe7zOoMdfJkdW6PdawSGjY8lZxfTnsNjOv45wT+v0+VWefXOE8 zrzq4J7sUyzqVM5POeWUrtmr+txXZ52u49qwK4wP2gKCe9oUXhAgQGB4gUl1rudjmzICPANU uk05Yk1xgZCN5W5TNhIyuCWXzVFkMhK411T+kS5HC6pj+v73v9/Oe0bP5x0N5Y6KvCMjL5Cz IyXv9J895d0cRdl73UVRDoDKO2cGmaq4eM47uIr85TCyvaaiIZDLd+uoKtKahnpRhV8vr36f VbX9cepo1d+5qtPrZzjI50W9HbQBnmUo6nH+mJ8dalUc3wbJa69l6jyW9Npuv8+aVP8yr3U7 DdPB2s+u1+cZQFnUw7wbuNuUPyLkclm/867cQaZx9lmmn3e+5jZzxJv8IaPflHcGFneK5Wh7 vabsZCrKnfN+wT0//elP28sPEtzzwx/+sL18pp+d/P2mv/7rv26vk9co3YKO+6XjcwILQUD7 o5q9PO5xus5z4bjXr1W3PVK8OG9of/Svf+Puv9zCuPWzyvZClWn11+u/RB31exzvOnyaenyp o6z5yJoikD4fV9VvytEsyj+2desz6ZfOoJ+XfwjNETu/9rWv9V01AxKy3ZDHzRzptlvgfY4w XRxbn/SkJ/VNN8ue7e58HFEGjdQ15X4u8jVsW71Y/rrrruuavRyVqUg/R6XoN9X5fchtD9v2 HKbvo47jVeZ50DxMY5sy26ZZP7L/t1ugX1Fn8vMcSWuSwT3Z5s4bhLr932OPPVqjDuU+ytG4 su85RybLUXcHnercb3Ue0wYtX6/lBq3bRRrjHK96/XaS6f/93/99+1i17777FpvsOc/HjueT CPrV3SKRYcpbxfVlbneYbebydRrX2SdXGI8zL19v5Otxpw984APtOpXHuW43ded26jj31VGn 67g2HNd5oawvuGeh7GnlJECgFoFJda7nCT+H7us15eO5igZy3inUbfo//+f/tJfrNgxled17 7rmn3TGRDYw6pnLjIjt2Oo2EkNbdOkXyLqei7CeddFLXLOZjf4rlDjjggK7LlT8Y9+I5767K uzVyu9kZlI966TW9973vbXnvvPPOXZ/VXpQh502vF+P69bIa5LOqtj9OHa36O1d1eoM49ltm 2A6xTK+Oetwvn/0+r/NY0m/bvT5vUv3LfNbtNEp96uXX7bMcfaCohzfffHO3xeLtb397e7ls jA8yjbPP/vVf/7W9vUHuECvyk0MtF+X50pe+VLy93Dx/DCiWy3m/4J4cXrdYfpDgnnLZt9pq q+W23+mNvNZYb7312ttJcxMBAp0FtD86uwz7bvlYNZ/aH3W0PdK2OA/kXPujd22rov0xbv2s sr1QZVq95fp/Wlf9Hse7Dp86r7XHqZ9Vl/X2229vP2oqR3r87//+7/6VICKyz6Q4Jk0yuGfQ 69osxItf/OJ2HjPAo9OU/Vv5OPaiLLlvek35WODsU8q+v7qnIk/DHvNz+fe///09s5c3DRbp 5+ij/aY6vw+57WHbnoMuX9fxatA8T2ubsnyjSK82bVFv8lF9Ofp7nVMGDxV1ttcNpeU8ZDBe 7oMMPsp1H/3oR0eO7NNvqnu/lc93VR/T+pVtkM8H/X6V0yr2Tc6rukbN9HNk5+IGqkz78ssv L292udff+c53Wvs6H0E+6DRMecc5f5fzM8w2i/XqMq6zT67I+zjzqoN7ytdRafo3f/M3XbNX x7mvjjpdLlNTfmfsijrPPhDcM892qOIQIDBZgUl2rudFYq8pf5gsLrbyua6dpowcL184dRoF p9N6e++9dyvtLbfcstPHY79Xblxk5/qtt946dJo/+MEP4tvf/nbP9fICuzDKO6gGmca9eC6P FvSsZz1rkE3GkiVLei5XlCHnTa8X4/r1hBjgw6q2P2odrfo7V3V6AxAOtMi4jcMq6vFAGR1g obqOJQNsuusiTal/5QzW6TRKfSrnbZDX5buP8lja6ZFcRTr5SKniuJsd9YNMo+6zTHuXXXZp by+PYYNOF154YXu9JzzhCT1XK8qT8zqDe7beeuue+Sh/mHc1FvnKu8nKI/iVl/OawEIX0P6o pgaMc5wuclDXuXCc69c62h5Z3uL4nPMqrtvqvKYdx6/Yt+PMq9j+OPWzStsq0xrHtFi3rvo9 qnedPk07vtRR1vKjWfOx7INOJ598cvuYNMngnmGua8sBLNk/1+1GtfL17/7779+TIANhDjvs sJ7LVPXhqMf8XK/b47iKvOUP5EX622yzTfF2z3ld34fc6LBtz0GXr+t4NWiep7VNme3y4tF7 OT/++OPjRz/6Udf6kaPR50izdU6jBPcU+bnrrrvioIMOatf57F/vFchY934rn+/qOKYV5R51 Puj3q5x+cTzJeRXXqOW082arIv1+QWSHHHJIa2S18vr9Xg9T3iquLzM/w2yzyH9hUKVx3X1y Rd7HmVcd3PPmN7+5XZ/SMvsae011nPuqrNN1XBv28vDZsgKCe5b18BcBAgSGEphk53reOd9r GuTO+vJw03kR8eMf/7hXku3Piud85l1Cwwwl2k6gz4ty4yKfaVvllKMB5B0zeUF0+umnty+i Nt9884E2M87Fc46OUH5Gb0ZdVzGVL6qbXi/G8avCqqrtj1pHq/7OVZ1eFcaZxriNwyrqcVVl 6ZbOuMeSbukO8n5T6t8gea3CaZT6NEjeZi+TQ30Xx9NedbD8A8Kgx/FR91kO41/kKefXXnvt 7Gx3/TsfGVZet9dw+OXlmhLcM/v41u/57F0hfEBgngtof1Szg0c9Tg+y9XHPhaNev9bV9sgy l88bvc6ZuWx+XizfbcS32cf8Ktulo/oNsm8HWaaK7Y9TP6u0rTKtQex6LVNn/R7Vey585ur4 UkdZN9100/ax4l3velev3b/MZ+Vr86YG9+RjcIvHjeXx8Mtf/vIyZSj+uPvuuyODf4pjZrcg hn//939vLZP9WpOYivzkfJhjfgZj5I99vabyyCzDBBd0SnPc70OmOWzbc5Dl6zxeDZLnaW9T vvSlL21/J4q6mO4ZAJePc87RbfKx1JOaxgnuyTzmtftjH/vYdpm22267yGPE7GkS+618vhvm +zfoMW12mYb9e5Dv1+w0izoy7PGq2zVqOf1bbrklVl111da+y+Nbt+DF7LfJY/4FF1xQXr3v 62HKW8X1ZWZomG0WBajLuM4+uSLv48yrDu55zWte0z4OpGkey0aZxjn3VVmn67g2HMVjoa4j uGeh7nnlJkCgEoFJdq5X8ePbJz7xiWUuIvJCPh/h1e//Ouus015vlFF1+mGXGxe77bZbv8V7 fn7jjTe2Ip/zzoh81m1eLK277rqx0047tZ53XFyQZsNqkGmci+dyx3ZuNzuhqpiKMuS86fVi HL8qrKra/qh1tOrvXNXpVWGcaYzbOKyiHldVliKdqo8lRbqjzJtS/zrlvQ6nUepTp7z1e++o o45qn9vOOeecrovnUN/FcTdHxxlkGnWffeYzn2lvK7d52223DbK51jK/+tWvllk3H0XZbSrK U9V5pLydctmH6TDMuxrL+fJorrKq1wRmBLQ/ZizGeVU+Vs2X9kddbY90Lh+fq7huq/Oatqrr /1HrVxXbH6d+VmlbZVqjehbr1Vm/R/WehE/V19qj1s+qyzr7uvVTn/pUsav7zqchuCcLUQ7a OfHEE7uWqzyCUbeRIQ499NAY5BFWXTcy5AdVH/PLmx8nuKfq70Pma9i25yDL13m8GiTP096m zBFc99lnn2WuPcp1Ml/nzafZTs+bOeuexg3uyfx9/vOfX6Y8OSLR7GkS+618vhumrZ55HfSY Nrtcw/w9yPdrdnrlulHFNers9IsbnnM7r3vd62Z/3Po7A02f+MQndvys15vDlHfU8/fs7Q+z zWLduozr7JMr8j7OvOrgnjyPF5aPeMQj+v6mU+S96nNfVXW66mvDorzmgwkI7hnMyVIECBDo KDBtnevl52DmxURG2F599dUD/89Hf9UxlRsXwwzHXM5LRsnn41KygZdly4bgxz/+8cghWosp y1pcRE0iuKf8GLDcbjbmqpiKMuS8ioZLnfWiqsbHqG5VbX/UOlq1bdXpjeo6e70mNQ5n523Y v+s6lgybj/LyTal/5TzV6TRKfSrnbdDXd9xxR/sOuqc+9anx+9//frlVs2M2G915vB3mzuBR 91n5x4rcZqc7+pbL5P+8kcuWzw8nnXRSt0WXWa6K80h5Q+WyD9thuN5667XzlkPZmwgQWF5A +2N5k1HeKR+r5kv7o662R/qWzy9VnDfqvKat6vp/lHqV61Sx/XHqZ5W2VaY1qmexXp31e1Tv On3qutYetX5WXdYrrrhimePKMCM2lq+Xh7k+L+rSMPNy3Rj2unaTTTZpl7HXdW22N8ojQ5T7 sDKvWRdyRIjzzz9/mKyPtWzVx/xyZkYJ7qnr+5D5GrbtOcjydR6vBslz+TsyrW3KP/zhD3HK KadEPrqtXB9nv86RP7773e+Wq1jlr6sI7snr96K/Osuw9tprL9f/MIn9Nolj2jg7YJDv1+z0 y3WiimvU2enn6JLFNtZYY43lRo3Km6AXLVoUwwSpFtsYpryjnr+LbRXzYbZZrFOUP+dVGtfZ J1fkfZx5lcE9S5YsiXz8fGE5SPuzrnNfVXW66mvDcfbVQlxXcM9C3OvKTIBAZQLT1rk+O6L2 5z//eWUW4yRUblw873nPGzqpLFfxTObNNtssLrrooo5p1BXck43OTkMP53CdxUVbzjOfVUzl NKu4qK6zXgzS+OjmV4VVVdsftY5WbVt1elUYZxpNahyOU6b0retYMk6+mlL/ijLU7TRKfSry Nuz8zDPPbB+nX/SiF0XeRZzTfffdF1/72tcizyl5zH3+858/1GMpR91nZ5xxRjs/ud0cMnfQ afYdoqeddlrXVas+j5Q3VC77sD+CrL766u3y5/PITQQILC+g/bG8ySjvlI9V86X9UVfbI32r Pm/UeU1b1fX/KPUq16li++PUzyptq0xrVM9ivTrr96jedflkunW1SUatn1WXNUfbKB9XPvvZ zxa7uu+8/AN4k4N71l9//XYZ+13XvvKVr2wvOzsQKEc22Hnnnfu6VLlAed9U0edUztuwwT11 fh8yX8O2PQdZvs7j1SB5ng9tynKdyePFF77whXjb294WBx54YJRHl8+6mqO233777eVVKn1d RXBPZmjbbbdtf88z3/kYrvI0if1WPt8N21Yf5phWLtcwrwf5fs1Or87jVbGtbCsU23nnO99Z vN2a/83f/E3rprFON4sts2CHP4Yp76jn79mbHWabxbpF2XNe9Tmhrj65Iu/jzKsM7snfqsqO 3R7XWeS37nNfFXW66mvDouzmgwkI7hnMyVIECBDoKDBtneuzn4V5+eWXdyzXpN8sNy6G7VzP Bl5xcZR3Rt10001ds19XcM+ee+4Zb3rTm5bb7oMPPhjlHyqHeY78comV3ijKW9VFdZ31YpDG Rze/UpFHflnV9keto1XbVp3eyLCzVmxa43BW9gb6s+5jyUCZ6LJQU+pfZm8STqPUpy50fd9+ ylOeEu9///vjta99bauTMO+KfdSjHtUarSd/VHnSk54UX/3qV/umM3uBUfdZ+ZiVx/irrrpq dtJd/y7ffZPr9nre+zDnkQwELpYf5Ln05bIP02H43//93+3t5Payk8dEgMDyAtofy5uM8k75 WDVf2h91tT3StzgP5LyKTv06r2nL59JsZ3Samt7+GKd+VmlbZVqd9sMw79VZv0f1rsOn7mvt Ub8fVZf1gQceiNVWW619bPnwhz88cHWYhuCe+++/vzXaTnHs7Hdde91117VH9UiX4oaDHD07 RxHNx/VMciryXdUxv5z3YYJ76v4+ZL6GbXsOsnydx6tB8lz+nuc+nKY2ZT6Sq9+o5+n7pS99 KbbYYov2MeSDH/xguZpV+rqK4J6HH344yqPU5n7JR+2Up0nst/L5bpi2+rDHtHK5hnk9yPdr dnp1Hq+KbZUDMzbaaKNIj5xy9OR111231adULDvMfJjyluvHONe3w2yzKEudxnX1yRV5H2de ZXDPwQcf3D5ePf3pT++ZrUmc+6qo01VfG/ZE8eFyAoJ7liPxBgECBAYXmLbO9WxM5B0NxUXZ 6aefPnhhIyJ/eKtjKjcuhulczxFfNt9883Z58i6HXlN5O+XHcuXdEvm80U6PPxn34jmfAV14 P+c5z+mVveU+u+eee5Z7L98o0st5FZ3rddaLcf06AgzxZlXbL9edYepo1bZVpzcEZc9Fm9Y4 7JnZDh9O4ljSYbMDv9WU+jcpp1Hq08CYpQWz0zyPo7/4xS9a72b5suPz3/7t3+LKK68caqSe UrKtl6Pus7zbKzuHiuN8dloOOmUQUrFe3s2YnZ7dplVWWaW9bL/zyIUXXthets7gnhzGush/ /ohx5513dsu+9wksaAHtj2p2/6jH6UmcC8e5fq2j7ZHixfE55/3OG+WR5LqdN+q8ph3Hr4ra VcX2R62fmf8qbatMqwrbuur3qN5V+zT5+FJ1WbM+/PEf/3H72PKa17xm4CoyDcE95R+8Br2u LdfvYqSf448/vtXnlY/zmORU9TG/nPdBg3sm8X3IfA3b9hx0+fL+rKovsHDsl4dpblPmI7ay /uWjzfpNv/71r2OHHXZoLX/EEUf0W3zkz6sI7skAvvL3Km8omj0C/CT2W/l8N0xwzyjHtFHA +9XtTmmWXau4Ru20jXwvb/wqtlX8npJBZflouG79993SKt4fprxVXF/mdofZZpHPotw5r9K4 zj65Iu/jzKsK7slAmryRMP3y0W75Pew2Tercl9sft07XcW3YzcX7ywsI7lnexDsECBAYWGDa OtezYIsXL25fjD7jGc8YuKz5fO+8CMnGU9VTuXExTODE7MZRDtXaa8pHrBQXpOXgnqLx2OmH xOKzXG+33XbrmPzjH//4eO9739vxs29/+9vtbeZz1PPOq0GmXC+fx9ypgVCUIedVXVTXVS/G 9RvEqtcyVW1/1Dqaeavatur0evkN+lmTGoeD5rm83CSOJeXtDfu6KfVvUk6j1KdhTXP5f/3X f20dn7/zne+MsnrPdcbZZ29961vb542jjz6653bKHx5zzDHt9XJo6F5TeSjzu+++u9ei8fd/ //ftdLv9SFtOoFz2QTsMswOj6JjNc9uf//mfl5Ps+Do7tz760Y9GPuPeRGAhCWh/VLO3y8eq +dT+qKPtkeLaH4PXuyraH6PWzyKXVbYXqkyryN+o87rq9zjeVfpM4lp7nPpZZVmzDpR/qMyR EHI0n0GmHHWzOCY19bFcObJzkcdBrmuz3Jdddll7nbXXXjty9Mw111wzTjnllEFYKl2myHvO q+pzKjI4aHDPJL4Pmadh256DLl/X8WrQPE9rm7Jw+6u/+quiyvScf+ADH2h9b/7kT/6k53Lj fFhFcE8+Arz8vXrHO97RMUt177fy+W7QtnpmdJRjWscC9nlz0O9XOZmya9XHq/J2cgS1Ylvb bLNN62aqfIz7CSecUF5sqNfDlHec83c5U8Nss1ivKHfOqzSus0+uyPs48yqCe/IxjfkbVNpl gM8///M/98zSpM59mYkq6nTV14YFjv6+QqL7XHBPdxufECBAoK9AjvRSvsD5sz/7s77rDLNA Oe1+P75l0EixfHYAdJvyjp8MUimW7feMz0wnh5vMi/4DDjigW7JjvX/FFVe08/Pc5z534LTK jZIszy233NJz3XzsSlHuRz/60e1l84fdfL/TBWqO6FCsk3dWzJ4ySjmjrr/4xS/O/qj990tf +tJ2GkceeWT7/V4v9tprr67eRX5y3vR6UYVfL6d+n1W1/VHraOav6u9c1en1Mxzk8+LZ2zka yKBTHfV40G3PXm4Sx5LZ2xzm76bUv0k5FfUpH4tV5/TNb36zdWx+6lOf2nHktnG2Pc4+y6HI s7MovyP5aMccAaHflAEueS7KdfJ8nWn0mjIotfgO9ko/R//Zdttt28tmfvpN5XqyaNGi+MlP ftJvlTjttNPa28hHbN5xxx0913nb297WXj47p/qd/3sm5kMCUyag/VHNDhv1OF0+xuVxtN/x Zy7aH1W3PVK8OGfkXPujdx2sov0xav0sclZle6HKtIr8jTOvo36P412lT9OPL1WWtagDhx9+ ePv48slPfrJ4u+s8+6Z22mmn9jpHHXVU12Wr+KC8T3IEnkEeb5TX1hkQn8fLQa5ry/l85jOf 2S7bVlttFdku6nddX16/qtd1HPOLvF1++eXLlLF4f/a8bJ/5qeN8m9sctu1ZLD9I30cdx6ty nnvlYVrblEVwTz7Cqng83ey6Uf67CPZ7z3veU3670tflUcaGCQgvMvGP//iP7TqfdTlHy+g2 ym7d+638vZrEMa0wGHQ+zPerSLPO41WxjZznOTCDeYrtvfCFL2w9NnHQm3jLaRWvhylvFdeX ud1htlnksyhzzqtqB2TadfbJFXkfZ559hUXZM9Bn2Onf//3fI39LyjTy+5Y3p/Wbyt/RXK+u c1/mo4o6Xce1of6+frVk6eeCewZzshQBAgQ6CuTjnIqTfM6HCUzpmGDpzbxYKqedF3G9puxk KJbPEV9yOM9uUzaQsqMgl887gvJio9uUnScZkLLhhhvW9liub33rW+28Z1DLoFPe2ZVBOkW5 s1HXbcpo8OxYyeFwc/lsBBeP4crnn2fDsdv0hCc8ob2N7IgoT/nIlPyxs9fIAffdd19kuYp8 5kVKjlLQbcoRF/JH2ozunj1NY70Y12+2wbB/V7H9Uetokdeqv3NVp1fkc5R5DiWco1IV9Tvr e7+pznrcb9udPp/UsaTTtgd5ryn1bxJOs+tTjlBR15Tnt6KhneeA/fbbr3Uezw67Aw88MA46 6KA47LDD4pWvfGXkcfnss88eqIMx8zvuPsuR6PKcld+r7PzrFHxauPzmN7+JfOZ6LrvxxhvH DTfcUHzUdZ53Qhbf2Tw/dpve/va3x7777tsOHMp1+gXezO6M2G677eL222/vtonIUfVyKOtM O0cUykei9ZuK/VaU4dRTT+23is8JzBsB7Y9qduWox+lJnAuzhONcv1bZ9si81HndVtc17Th+ VdSwcbc/av0s571K2yrTKudxlNdV1+/Mw7jeVflMw/GlqrIW+z77ZHbdddfWdWD2OeU5rtuU +/7QQw9tX8PmdeCzn/3sbotX8n75ujavzbMfrVffTx4vizv9B72uLWf061//+jLl+9u//dvy xxN5XecxPwuQj0AuruFzn3ebJvF9GLbtOXv5fn0fdRyvhsnDNLYpi+CerCOHHHJIz77TDJDZ ZZddWqMv5bGprqn4TmeeMgBv0CmPFS95yUva9T3X33333fu2p+vcb5M+pg1qlcsNU7eLdOs+ XhXbKeblUY1zf77sZS8rPhp6Pkp5x72+HGWbdRrX2Sc39A7psML222/f/v4+5SlP6bBE57dy 9J0cACB/n8t6ktcPl1xySeeFZ707iXNfeZNV1Omqrw3195X3UPfXgnu62/iEAAECywhccMEF 8bGPfSwy4v5DH/pQvOENb4jHPe5xUawMsAAAIABJREFU7ZN8nqzzf3Y2vPvd727dhZ4RubnO MFHc//RP/9QadjdHySnSzPmznvWs1nY//vGPt/OVo8ZkfvIZr+XGRi6fw4Z++MMfjs9//vPt 5csv8vFa+eNlLpvRw3/5l3+5TEdK3i3whS98odWxnHfFX3rppeXVx36djdzMew6hWnTmFOXN C6C8uDjjjDP6/kiZo+7kEM65bgbs5JDF5cCmfKzV+973vtYPntlI/MpXvtJ2zX2VgT1bbLFF 9Oo0yTv5ijuvdt555/aPu9koyqj94nnovVDSM4OkijJmmXOIwSLAKIN98kIvf0zOwJ78sbM8 TXO9qMKvbDHs61G3X1UdLfJb9Xeu6vSKfA46P+ecc+If/uEfony3Zdbv/F7lD+35fZs9Taoe z97uIH9P4lgySD6KZZpa/+py6laf8piY57IcLraOKUddyxGCimNzv3meLzPgp1PAbdX7LO/6 3WeffVp523TTTeMTn/jEMndJZcBPnsOKu8fyOmDQ640Mttl8881baecoPtdee+0yvBnAk3ea 5vkx0yzOgemTo/+ddNJJ8dnPfnaZdYo/yh2GOfzwwQcf3DoH5/DD5TsU87z4rne9q93h8eQn Pzn6PV6z2EZ5BMLM0yCjEBbrmhOYJgHtD+2PPMaN0v4Yt+2R35NJXbfVcU076vV/VceHUbZf 9XVElqVK2yrTGte5ivpdtXdVPnVda5fNR6mf5fWrKmuRZgaqv+AFL2hdl2ZATPahla8Zc7nz zjuv9SN+XreWR0TLY2T2H2Uf3ewbsYr0x5kX17XZJ5bXx0cccUTrR7rsZyvfsJU/mOaNX8Xo m8Nc187OXwYrZLmyX6jTo+NnL1/V33Ue8/M7W/T/FeXLMub/7CfL/oPsq5s91fV9GLbt2W35 Xn0fRVmqOF5lWqPmYdralEVwT/4onsFfGQyT38PZ049//OPYf//9W/3AvUZSn73eIH9nX23W 13zczItf/OJWPS3q62qrrRZ5w2b2V+exavb/7CN73ete17pBJkfVL9bLtne23cvHjV55qWu/ zcUxrVc587NR6nadx6te+c3zVd4kXezXrIfDTqOUt9jGqOfvUbY5KeMq++QKp1Hnea2R3/38 Tar8OL7c3/mb01ve8pY4/fTTl/ve53vvfOc749WvfnWUA4LyJrZ8f9ibFus693VyqaJOZ7pV Xhvq7+u0p5Z/T3DP8ibeIUCAQEeBHIYzOxpypJi8KM87drLhno+ryLvS83++zve23HLLyB/i MugkG+R5982gU6637rrrtjoM8ke1TDODiHK7ObJAXhgUUzYKcsSMfD8/z+Vy+Vwv/850dthh h2LxjvMMIsk7D/IiJS9W8iL1MY95TOvv/DHv6KOP7nlnUsdEB3gzo3pn5z3t8kfKdMty5ud5 MdlvykbPK17xivazstPj6U9/emSHSpYhG9zXXHNNO5lsiBU/5mYnTQYY9ZuygZmNyjTKdYso 4gyKGrRxltu4+OKLI0eFKEY6yeet5r7KH4yzkZjPie704+a014uq/Prtp26fj7L9KutoOV9V f+eqTq+c116vs1Muj4l5B0Iec4rvb36n8rjXaYj0SdfjXvnv9NkkjiWdttvpvSbXvzqcutWn 7NDL43ied6ue8k66DNTN0dfy2J7DE2cwSp4DcwSc/Lsc1JLLFP/zsx/96EfLZKmOfZZBvNnZ kee0PPfk//zO5TkoOzzz7wzq+Zd/+ZfIZYeZcnjfDODJc09eA+QIQTm6XT7WK9N+1ate1b6r sJNDLtdpKjoM0yqXyXxlp2den+S5L8+le++9d8s2z4H5d57rhzmX/sd//Ec88YlPbB2Djjvu uKHL3inf3iPQRAHtj2r3SpXH6TrOhbNLO8r16+w0Rm17ZDqTvm6r+pq2Cr/ZnsP8Pez2q6yf s/NZpW2Vac3O57B/j1O/6/Kuwmdaji9VlLW8z88///zWD+J5fZv9UjkyZV4zFtfoGRSed7Sf fPLJ7Wvy4to8529961vLyVXyuriuzUfI5pTXtXnDXbZ/sw2Rd/I/4xnPaPW9jXpdOzujGTiU 5Xn9618/+6Na/67zmJ91Oh/Xm/uy6LvM/oN0zLZN9iukY6epju/DsG3Pbsv36vuYXZZxjleZ 1jh5mKY25Xe/+91W/c/vXAa35cgoWXeyjziPB3vssUerzzjbqznybq+R6Gfvg0H/nn0DW/k4 M+jrzG/+bpB9vHnMmB2wOEhe6thvc3FM61fWUep2ncerfvnNUZ2zHuQN06NMo5S3vJ1hry9z 3VG2OQnjqvvkyk6jvM7z0KDf8dnL5TEp+xGzX+3lL395qx9v2KCecp7rOPeV0y+/HrdOl9Oq 4tpQf19ZtPtrwT3dbXxCgACBBSWQwyzmcNSf+9znWiP2ZIMqO06macofBvPH1q9+9avx6U9/ ulWebkMm5wVWjlQwzI+JaZGPP8s7snKUgG5pD2KWkdF5QZ4dN/k/G/rFKD6DrD+pZaquF1X5 jVr+ud5+Od9V21adXjmvC+31JI4lc21aRX2ZZqc8/mbncnYU5g8F+QNPtylHgMs7snL0oPKo ennn8LDnkG7bGOT9u+66q/VM8jxP5/98Pnm+N+6Ud67nyHEZIJR3E+ZjumY/eivPU+eee258 73vfa50706tbB2XRYZidHeUAoOyczEctZDoZzJND8t92223jZt/6BAhMsUAV56K5Lv4kzoVV XL9OS9sj92fV9aIKv3Hq2Vxvv5z3Km2rTKucx1FeN7F+V+EzLceXKspa3u/5g36OnJHXizma S16Hl6+5r7766tZID7lM9v/kzVF5TZyj50xyymveHJmy6uvaHB0zA+87jRQ6yfI1bVuT+D5M osxzfbxqepsyH9OT/dHlKfOco1lmWzXbwfndr6IdXN5G01/Xtd/K5a7rmFbexnx4nXU0fxOY 3Wcy6bI16fpylLJPY5/cKOUcd51JnPvqqNNVXxuO6zgf1xfcMx/3qjIRIECAAAECBAgQINBR IANKMrAng0/y8ZnDTjk8d3GXzkUXXTTs6vN++W7BPfO+4ApIgAABAgQIECBAYAyBDIbfaaed WqNrjpGMVQkQIECAQGMF9Mk1dtfI2BQJCO6Zop0lqwQIECBAgAABAgQIjCfwqU99qhWck4+P K98FPGiqeVfwWmut1UojHwtgWlZAcM+yHv4iQIAAAQIECBAgMIhAjgaRNxFceeWVgyxuGQIE CBAgMHUC+uSmbpfJcAMFBPc0cKfIEgECBAgQIECAAAEC9Qh87GMfa3War7766pHDzw475eOo 1lxzzVYaH//4x4ddfd4vL7hn3u9iBSRAgAABAgQIEBhBIEf9zEf77rfffnH77bcvk0KO2rP7 7rvHwQcfvMz7/iBAgAABAvNJQJ/cfNqbyjJXAoJ75kredgkQIECAAAECBAgQmLjAnXfeGeut t14rOOe1r31t5Eg8g07Z6f6GN7yhtW6mkWmZlhW4/PLLWz551/EWW2yx7If+IkCAAAECBAgQ ILBABTKop3i87ymnnLKMwhlnnBGrrbZaXHPNNcu87w8CBAgQIDCfBPTJzae9qSxzJSC4Z67k bZcAAQIECBAgQIAAgTkR+O53vxvrrrtuq3P9gAMOGKgT/frrr49DDjmktc4666wTl1xyyZzk vekb/dCHPtT+0WLRokXx85//vOlZlj8CBAgQIECAAAECtQu8+MUvbl8nn3/++e3tfetb32o9 9teooG0SLwgQIEBgHgvok5vHO1fRJiIguGcizDZCgAABAgQIECBAgECTBH71q1/FMcccExts sEGrk32PPfaIE088MbJT/cILL2z9P/PMM+Md73hH7L333q1lcrSe17zmNXHrrbc2qShznpc7 7rgjNttss3bAVHFHcs5XXHHF2GSTTeKwww6b83zKAAECBAgQIECAAIG5EshRefImgV133TW+ +c1vxrnnnhvHHXdcK7DnIx/5yFxly3YJECBAgMDEBfTJTZzcBueRgOCeebQzFYUAAQIECBAg QIAAgeEElixZEnnn7LHHHhuHHnpoZJDPpptuGo997GNj9913b43W8/rXvz6+/vWvRy5rWl7g 3nvvjb/7u7+LD37wg3Haaae1AqTOOuusyGepn3rqqXHyySdHBkqZCBAgQIAAAQIECCxkgRtv vLF1s8DOO+8c22yzTeRoPj/60Y8WMomyEyBAgMACFtAnt4B3vqKPLCC4Z2Q6KxIgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBCoV0BwT72+UidAgAABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECAwsoDgnpHprEiAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECgXgHBPfX6Sp0AAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIDAyAKCe0amsyIBAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBegUE99Tr K3UCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECIwsI7hmZzooECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE6hUQ3FOvr9QJECBAgAABAgQIECBAgAAB AgQIECBAgAABAgQIECBAgAABAgQIjCwguGdkOisSIECAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQqFdAcE+9vlInQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgMLKA4J6R6axIgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoF4BwT31 +kqdAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAwMgCgntGprMiAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgXoFBPfU6yt1AgQIECBAgAABAgQIECBA gAABAgQIECBAgAABAgQIECBAgAABAiMLCO4Zmc6KBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBOoVENxTr6/UCRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIECIwsILhnZDorEiBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIEKhXQHBP vb5SJ0CAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIDCygOCekemsSIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKBeAcE99fpKnQABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECBAgMDIAoJ7RqazIgECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAIF6BQT31OsrdQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIAAAQIjCwjuGZnOigQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgTqFRDc U6+v1AkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAiMLCC4Z2Q6KxIgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBCoV0BwT72+UidAgAABAgQIECBAgAAB AgQIECBAgAABAgQIECBAgAABAgQIECAwsoDgnpHprEiAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECgXgHBPfX6Sp0AAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgQIDAyAKCe0amsyIBAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBegUE 99TrK3UCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECIwsI7hmZzooECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE6hUQ3FOvr9QJECBAgAABAgQIECBA gAABAgQIECBAgAABAgQIECBAgAABAgQIjCwguGdkOisSIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQqFdAcE+9vlInQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIECBAgMLKA4J6R6axIgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoF4B wT31+kqdAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAwMgCgntGprMiAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgXoFBPfU6yt1AgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAiMLCO4Zmc6KBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBOoVENxTr6/UCRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIAAAQIECIwsILhnZDorEiBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIEKhX QHBPvb5SJ0CAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIDCygOCekemsSIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKBeAcE99fpKnQABAgQIECBAgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgMDIAoJ7RqazIgECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAIF6BQT31OsrdQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgQIAAAQIjCwjuGZnOigQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgTq FRDcU6+v1AkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAiMLCC4Z2Q6KxIg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBCoV0BwT72+UidAgAABAgQIECBA gAABAgQIECBAgAABAgQIECBAgAABAgQIECAwsoDgnpHprEiAAAECBAgQaLbAzTdHnHpqxCGH ROyyS8TGG0dsuWXE054W8epXR3ztaxEPPNDsMsgdAQIECBAgQIAAAQIECBAgUJPAbbdFfOxj EYcdFrHbbhGPfnTE5ptH7L13xMtfHvHFL0b89rc1bVyyBAgQIECAAAECwwgI7hlGy7IECBAg QIAAgSkQuOmmiKOPjlh55YgVVuj9f4MNIk46SZDPFOxWWSRAgAABAgQIECBAgAABAtUI3HFH xBvfGLFoUe9Og+xUeOQjI048MeK++6rZtlQIECBAgAABAgRGEhDcMxKblQgQIECAAAECzRT4 9KcjVlutf9/c7KCfJz85Ikf6MREgQIAAAQIECBAgQIAAAQLzWCCH8V177eE7DrbZJuLaa+cx jKIRIECAAAECBJotILin2ftH7ggQIECAAAECAwu84x3D982Vg3w22STiqqsG3pwFCRAgQIAA AQIECBAgQIAAgWkSOP30wYb5LXcWlF9nUNB3vjNNJZZXAgQIECBAgMC8ERDcM292pYIQIECA AAECC1ngrLPGC+wp+uo23zzi9tsXsqSyEyBAgAABAgQIECBAgACBeSjw9a+PF9hTdByst17E DTfMQyBFIkCAAAECBAg0W0BwT7P3j9wRIECAAAECBPoK/OQnEYsWVRPck311Bx/cd5MWIECA AAECBAgQIECAAAECBKZF4LbbRnsUVxHQM3u+++4RDz00LaWXTwIECBAgQIDAvBAQ3DMvdqNC ECBAgAABAgtZ4AUvqC6wp+iv+8Y3FrKoshMgQIAAAQIECBAgQIAAgXkkcMwx1XccfOYz8whI UQgQIECAAAECzRcQ3NP8fSSHBAgQIECAAIGuAtdeG7HiitX30e23X9dN+oAAAQIECBAgQIAA AQIECBCYFoE77ohYddXqOw4e//hpEZBPAgQIECBAgMC8EBDcMy92o0IQIECAAAECC1XgPe+p vn8uR+9ZeeWIO+9cqKrKTYAAAQIECBAgQIAAAQIE5onAmWfW03GQnQfXXTdPkBSDAAECBAgQ INB8AcE9zd9HckiAAAECBAgQ6Cqw77719dF94QtdN+sDAgQIECBAgAABAgQIECBAYBoEXvSi +joOPvjBaRCQRwIECBAgQIDAvBAQ3DMvdqNCECBAgAABAgtVYLPN6uujO+mkhaqq3AQIECBA gAABAgQIECBAYJ4I7LFHfR0Hxx03T5AUgwABAgQIECDQfAHBPc3fR3JIgAABAgQIEOgo8PDD EYsW6aPriONNAgQIECBAgAABAgQIECBAIGLzzevrODjiCMIECBAgQIAAAQITEhDcMyFomyFA gAABAgQI1CHwyEfW10f3139dR46lSYAAAQIECBAgQIAAAQIECExMYJtt6us4+NM/nVgxbIgA AQIECBAgsNAFBPcs9Bqg/AQIECBAgMBUC2y7bX19dIsXTzWNzBMgQIAAAQIECBAgQIAAAQL7 7ltfx8Eb38iXAAECBAgQIEBgQgKCeyYEbTMECBAgQIAAgToEDjmkvj66Cy6oI8fSJECAAAEC BAgQIECAAAECBCYm8OpX19dxcOaZEyuGDREgQIAAAQIEFrqA4J6FXgOUnwABAgQIEJhqgY99 rJ4+uj/6o4gHH5xqGpknQIAAAQIECBAgQIAAAQIEzjuvno6DlVeOuP12vgQIECBAgAABAhMS ENwzIWibIUCAAAECBAjUIZD9aKuvXn0/3Z/9WR25lSYBAgQIECBAgAABAgQIECAwUYH774/Y cMPqOw7233+ixbAxAgQIECBAgMBCFxDcs9BrgPITIECAAAECUyuQI+vccUfEm95UbR/dqqtG 3HBDxC1xy9TayDgBAgQIECBAgAABAgQIEFjoAg89FPGrX0XEhz5UbcfBiitGXHppxC36DRZ6 HVN+AgQIECBAYHICgnsmZ21LBAgQIECAAIHKBC6+OGLHHSOe97yIu++O2HTT6vrp3vzmiJ/G T2P1WD2OjCPj9jDMdmU7TkIECBAgQIAAAQIECBAgQGACAldcEbHnnhFPfnLEH+57MGKnnarr OMjhfvNuow02iDjooIgbb5xAiWyCAAECBAgQILCwBQT3LOz9r/QECBAgQIDAlAncdlvEy14W kTfJrbBCxKJFEddeG5GddmuuOX4/XY6qvWRJxF/HX8cK//Nvg9ggPhGfiIfj4SnTkl0CBAgQ IECAAAECBAgQILCwBO65J+LYYyNWXnlpH0HO8wah+PnPq3k815OeFPG730V88IMznRBrrbX0 7+xQMBEgQIAAAQIECNQiILinFlaJEiBAgAABAgSqFXj44Yizzlp6U1wG9eT/ffeNuOaame1c cEHEOuvM9K0Vyw0632+/paMAFSmeHWfHRrFRO8jnafG0uCquKj42J0CAAAECBAgQIECAAAEC BBok8JWvLDuy7667Rlx2WSmD+ccmm4zecbDbbss+iis3uPnmM+ntvPPSx3WVNuklAQIECBAg QIBANQKCe6pxlAoBAgQIECBAoDaBK6+M2Guvmb6yjTdeGuiTAT+zp+uui8i+tEEDenK5VVaJ +Mu/XDpiz+z07o6749g4NlaKlVpBPqvEKq2/7417Zy/qbwIECBAgQIAAAQIECBAgQGAOBG64 Yelju4u+gLzxZ/HiiD/8oUNmbr454ulPH67jIIcPPuqoiPvuWz7BHMXnxBMjVl11aZq57JFH Ln1s1/JLe4cAAQIECBAgQGBEAcE9I8JZjQABAgQIECBQt8Ds/rGVVlraP3bnnb23/NBDEZ/8 ZMT22/fuq8tHeh1++NLHevVOMeKH8cPYLXZrj+LzmHhMnBPn9FvN5wQIECBAgAABAgQIECBA gEBNAr//fcRJJ0WsttpM+/+ggyIyfqfv9MUvRuTQPkVEUKd53g10wAERl1/eN7nIu42e9ayZ 9NZbL+KMMyI63ZnUPzVLECBAgAABAgQIzBIQ3DMLxJ8ECBAgQIAAgSYI5MjWm2020ye2yy4R 3//+8Dm79tqIU06JOP74iJe8JOKVr4x4+9sjzj474je/GS69JbEkFsfiWCvWagf5HBQHxS/i F8MlZGkCBAgQIECAAAECBAgQIEBgLIFvfztihx1m+g223joiH9c99PTzn0ecdlrECSdE/Omf Rrz85RFvfWvEpz8d8etfD5dc8UzxDTecydg++0RcffVw6ViaAAECBAgQIEBgOQHBPcuReIMA AQIECBAgMHcCP/tZxIEHzvSBrbnm0rvwOg6lPUfZvCVuiSPjyHaAzxqxRpwYJ8aD8eAc5chm CRAgQIAAAQIECBAgQIDAwhC49dalo/rm069ysJ0ctSefivXAAw0q/113RRx7bEQOQZyZfMQj lv59r0d8N2gvyQoBAgQIECAwZQKCe6Zsh8kuAQIECBAgMD8FcijtxYsjHvnImcCeHEr7ppua W95z49x4XDyuHeSzXWwXF8VFzc2wnBEgQIAAAQIECBAgQIAAgSkVyEdwn3VWxPrrz/QbPPOZ gz1qe86KfMklETvtNJPhLbeMOO+8OcuODRMgQIAAAQIEpllAcM807z15J0CAAAECBOaFwMUX R+y440xf11ZbRZx//nQU7b64rzVqz6JY1AryWTFWbI3qc3vcPh0FkEsCBAgQIECAAAECBAgQ INBwgSuuiNhzz5l+g002WRro0/BsL83ekiWd72a68capyL5MEiBAgAABAgSaIiC4pyl7Qj4I ECBAgACBBSeQj64/+uiIYijruhoaAAAgAElEQVTtHKX6jW+MuP/+6aO4Pq6P/WK/9ig+68a6 sTgWx0Px0PQVRo4JECBAgAABAgQIECBAgEADBH7726X9BCuvvDSwJ59ylf0I99zTgMwNm4Vf /jLi8MNnIpTWWGPp88RyKGMTAQIECBAgQIBAXwHBPX2JLECAAAECBAgQqFbg4YeX3mG3wQYz fVr77htxzTXVbmcuUjs7zo6NYqN2kM/T4mlxVVw1F1mxTQIECBAgQIAAAQIECBAgMLUCX/lK xKabzvQb7LprxGWXTW1xZjKeBdt885mC7bxzxKWXznzuFQECBAgQIECAQEcBwT0dWbxJgAAB AgQIEKhH4MorI/baa6YPa+ONlwb6ZMDPfJnujrvj2Dg2VoqVWkE+q8Qqrb/vjXvnSxGVgwAB AgQIECBAgAABAgQI1CJwww0Rz3veTL/BOussfarVH/5Qy+bmJtHf/W7pqD2rrrq0oDmk8ZFH Rtxxx9zkx1YJECBAgAABAlMgILhnCnaSLBIgQIAAAQLTLzC73yqH0s5+qzvvnP6ydSvBD+OH sVvs1h7F5zHxmDgnzum2uPcJECBAgAABAgQIECBAgMCCFcinU510UsRqq80E9hx0UMTNN89j kuuui3jWs2YKvN56EWecETGf7oCax7tP0QgQIECAAIHJCgjumay3rREgQIAAAQILUCBHnN5s s5m+ql12ifj+9xcGxJJYEotjcawVa7WDfA6Kg+IX8YuFAaCUBAgQIECAAAECBAgQIECgj8C3 vx2xww4z/QZbbx1xwQV9VpovHxfPLt9wwxmAffaJuPrq+VJC5SBAgAABAgQIVCIguKcSRokQ IECAAAECBJYX+NnPIg48cKZvas01l96FN6+G0l6+2B3fuSVuiSPjyHaAzxqxRpwYJ8aD8WDH 5b1JgAABAgQIECBAgAABAgTmu8Ctty4d1TefSrXCCktH7TnxxIgHHpjvJe9Qvrvuijj22Igc 6jgxHvGIpX/f6xHfHbS8RYAAAQIECCxAAcE9C3CnKzIBAgQIECBQr0AOpb14ccQjHzkT2JND ad90U73bnYbUz41z43HxuHaQz3axXVwUF01D1uWRAAECBAgQIECAAAECBAhUIvDQQxFnnRWx /voz/QbPfGbEtddWkvx0J3LJJRE77TQDs+WWEeedN91lknsCBAgQIECAQAUCgnsqQJQEAQIE CBAgQKAQuPjiiB13nOmD2mqriPPPLz41T4H74r7WqD2LYlEryGfFWLE1qs/tcTsgAgQIECBA gAABAgQIECAwrwWuuCJizz1n+g022WRpoM+8LvSwhVuypPNdUzfeOGxKlidAgAABAgQIzBsB wT3zZlcqCAECBAgQIDCXAr/+dcTRR0cUQ2nn6NFvfGPE/ffPZa6ave3r4/rYL/Zrj+Kzbqwb i2NxPBQPNTvjckeAAAECBAgQIECAAAECBIYU+O1vl/YTrLzy0sCefPpU9iPcc8+QCS2kxX/5 y4jDD5+JhFpjjYh8blkOmWwiQIAAAQIECCwwAcE9C2yHKy4BAgQIECBQrcDDDy+9w26DDWb6 mvbdN+Kaa6rdznxO7ew4OzaKjdpBPk+Lp8VVcdV8LrKyESBAgAABAgQIECBAgMACEvjKVyI2 3XSm32DXXSMuu2wBAYxb1ATcfPMZwJ13jrj00nFTtT4BAgQIECBAYKoEBPdM1e6SWQIECBAg QKBJAldeGbHXXjN9SxtvvDTQJwN+TMMJ3B13x7FxbKwUK7WCfFaJVVp/3xv3DpeQpQkQIECA AAECBAgQIECAQEMEbrgh4nnPm+k3WGedpU+b+sMfGpLBacrG7363dNSeVVddCppDJx95ZMQd d0xTKeSVAAECBAgQIDCygOCekemsSIAAAQIECCxUgdn9STmUdvYn3XnnQhWprtw/jB/GbrFb exSfx8Rj4pw4p7oNSIkAAQIECBAgQIAAAQIECNQskE+NOumkiNVWmwnsOeigiJtvrnnDCyH5 666LeNazZmDXWy/ijDMi3Gm1EPa+MhIgQIAAgQUtILhnQe9+hSdAgAABAgSGFciRoDfbbKYP aZddIr7//WFTsXwvgSWxJBbH4lgr1moH+RwUB8Uv4he9VvMZAQIECBAgQIAAAQIECBCYc4Fv fztihx1m+g223jriggvmPFvzKwPFM9I33HAGep99Iq6+en6VU2kIECBAgAABAiUBwT0lDC8J ECBAgAABAt0EfvaziAMPnOkzWnPNpXfhGUq7m9j4798St8SRcWQ7wGeNWCNOjBPjwXhw/MSl QIAAAQIECBAgQIAAAQIEKhS49dalo/rm06JWWGHpqD0nnhjxwAMVbkRSywrcdVfEscdG5JDK if6IRyz9+16P+F4Wyl8ECBAgQIDAfBAQ3DMf9qIyECBAgAABArUJ5FDaixdHPPKRM4E9OZT2 TTfVtkkJzxI4N86Nx8Xj2kE+28V2cVFcNGspfxIgQIAAAQIECBAgQIAAgckLPPRQxFlnRay/ /ky/wTOfGXHttZPPy4Ld4iWXROy008wO2HLLiPPOW7AcCk6AAAECBAjMTwHBPfNzvyoVAQIE CBAgUIHAxRdH7LjjTN/QVltFnH9+BQlLYmiB++K+1qg9i2JRK8hnxVixNarP7XH70GlZgQAB AgQIECBAgAABAgQIVCFwxRURe+4502+wySZLA32qSFsaQwosWdL57qwbbxwyIYsTIECAAAEC BJopILinmftFrggQIECAAIE5FPj1ryOOPjqiGEo7R3V+4xsj7r9/DjNl0y2B6+P62C/2a4/i s26sG4tjcTwUDxEiQIAAAQIECBAgQIAAAQITEfjtb5f2E6y88tLAnnwqVPYj3HPPRDZvI70E fvnLiMMPn4m4WmONpc9Vz+AfEwECBAgQIEBgigUE90zxzpN1AgQIECBAoFqBhx9eeofdBhvM 9AHtu2/ENddUux2pjS9wdpwdG8VG7SCfp8XT4qq4avyEpUCAAAECBAgQIECAAAECBHoIfOUr EZtuOtNvsOuuEZdd1mMFH82NQO6ozf8/e/cCXlV553s8VxJDEEiABil3qgawXKQtyq0wzFEx He0pamvNOKd20Dk66djTKbbTNtqpSlunpqPVgVPtyYy1ClNUlKOWWtFQOE5jKYKAN+4R5A4J lyQkv/P812r2yj07yb6stfd3PU8esvd+13v5rLX3Zv3zX+870jtQkyZJ69fHpy+0igACCCCA AAIIRECA5J4IIFIFAggggAACCARfYNMm6bLLvJhPQYGb6GMJP2z+FDimYypRidKU5iT5ZCjD eVytan92mF4hgAACCCCAAAIIIIAAAggEVuD996Urr/TiBgMGuKtAnTsX2CElfsdPnZJKS6U+ fdwDZ1M0FxdLhw4l/tgZIQIIIIAAAggknADJPQl3SBkQAggggAACCHRHoHWcx6bStjjP4cPd qYWy8RSoVKWmaVpoFp9hGqYVWhHPLtE2AggggAACCCCAAAIIIIBAggjU1bmrOmVne4k9RUXS 3r0JMsBkGMb27dK8ed4BzMuTli6VuKMrGY4+Y0QAAQQQQCBhBEju8dmhrKmp0Xe/+13dfvvt +uIXv6i//Mu/1KWXXqr/8T/+h896SncQiLLAM8+4V81LlnT/3x/+0L04e/ZZ/1xl20Lc3/2u dPvt0he/KP3lX0qXXirx3o7yiUT1CHQuYDM0jxjhxXYmT5Y2bOh8H171p0C96lWmMvVTv1CS T5GKtEu7/NlheoUAAggggEAPBYgb9BCO3RJPgLhB4h1TRoSADwXWrpUKC724wbhx0ssv+7Cj dKlrgaa12AcP9g7o7NnSli1d70sJBBBAAAEEEEDABwIk9/jgIDTvwkcffaTc3FylpqYqJSUl 9HOlzffJhkAyCVjSi91BkZXlXWylpHi/29QaNvftoEFtf3JyvHK2z/jx0n/8hxTPOXI/+kjq 27dlv6xvvLeT6axmrD4S2LFDWrDAe0va29NyCeP5MeEjnkB3pUpVKlZxKMEnRzkqValqVRvo cdF5BBBAAAEEmgSIGzRJ8G/SCxA3SPpTAAAEoimwf787q6+t4mQhPJu1x1Z3Ons2mq1Sd0wE jh6VSkokiy/bwc3MdB9Xs8R3TPxpBAEEEEAAAQR6LEByT4/portjdXW1/vZv/5bknugyU3tQ BDZvlj72Me+v8HaLzIkTHffe7sJ47z1p+XJpyhRvvzFjpJUrO94vFq+cPCl95Sten0juiYU6 bSAQErCptMvKpNxc721oU2nv2RMqwi8JIvCCXtBojQ4l+Vyki/SKXkmQ0TEMBBBAAAEEJOIG nAUINBMgbtAMg18RQKA3Ag0NUnm5lJ/vxQ3mzpW2betNrezrS4GKCmniRO9AW+x49WpfdpVO IYAAAggggAACJkByj4/Pg4qKCpJ7fHx8/Nq1H/zgB7rxxhv92r2e9+vqq70Lrf/238Kvp75e uusub1+73eZnPwt//2iUfP11rz8k90RDmDoRaFfgtdekCRO8t9/YsdKLL7ZblCcTROC0Tjuz 9mQpy0nySVWqM6vPQR1MkBEyDAQQQACBZBcgbpDsZ0DPxk/coJUbcYNWIDxEIHkFNm6Upk/3 4gZDh7qJPskrkgQjt++A9u4C2707CQbPEBFAAAEEEEAgaAIk9/j4iG3cuJHkHh8fH7927XOf +5ym21Voom3XXutdWfckIcYSgmyaVfvJyJA2bIifkEUKmvrSk7HEr+e0jEAgBY4ckRYtkpqm 0rbZlhcvls6cCeRw6HQPBN7Vu5qv+aFZfAZqoMpUpgY19KA2dkEAAQQQQMA/AsQN/HMsgtQT 4gYdHC3iBh3A8DQCiS9QU+PGCdLT3ZCdrdZkcYTOJg5PfJUkG+G+fdLChV7MNifHXb/dkn/Y EEAAAQQQQAABnwiQ3OOTA9FeN/70pz+R3NMeDM91KjBhwgSSe9oTeust7+LMEmtsJqB4bX/6 k9cXknvidRRoNwkEbIU+m0p70CDvLTdnjrR1axIMniG2K7BcyzVEQ0JJPjM1U5u1ud2yPIkA AggggEAQBIgbBOEo+a+PxA06OCbEDTqA4WkEEltg1Spp+HAvbjB1qvTGG4k9ZkbXiYCdECNH eifEpEnS+vWd7MBLCCCAAAIIIIBA7ARI7omddbdbIkjXbbKk3+Gdd95xEsKYuaedU8EWzO7X z7swy81tp1CMniK5J0bQNJPMAps2SZdd5r3lCwrcRB9L+GFLboFjOqYSlShNaU6ST4YynMfV qk5uGEaPAAIIIBBIAeIGgTxsce00cYNO+IkbdILDSwgknsD770t2z13T5NoDBrirM507l3hj ZUTdFDh1Siotlfr0cU8Qmwq6uFg6dKibFVEcAQQQQAABBBCIrADJPZH1jGhtBOkiypkUlX39 618nuaezIz14sHfFbktzxetqneSezo4SryHQK4HW8RebStviL4cP96padk5AgUpVapqmhWbx GaZhWqEVCThShoQAAgggkMgCxA0S+ehGZ2zEDbpwJW7QBRAvIxB8gbo6d7Wl7GwvTFhUJO3d G/yxMYIIC2zfLs2b550oeXnS0qUSd45FGJrqEEAAAQQQQCBcAZJ7wpWKQzmCdHFAD3CTf/jD H5Sbm0tyT0fH8J13vAsxuyVn+vSOSkb/eZJ7om9MC0kpYDMnjxjhvdUnT5Y2bEhKCgYdpkC9 6lWmMvVTv1CST5GKtEu7wqyBYggggAACCMRXgLhBfP2D1jpxgy6OGHGDLoB4GYHgC6xdKxUW enGDceOkl18O/rgYQRQFmtZ8b578OXu2tGVLFBulagQQQAABBBBAoH0Bknvad/HFs7EK0jU2 Nqq6uv2lKOrr61VTUxMRj4aGBu3YsUO///3vnR/73Z4L2hYrr+64bNq0SXl5eU5iT0pKiiK1 LJevjtm113pX3jZnbne3O+7w9rdZe3772+7WINn5umOH9Pvfuz/2e0/O4a6Se+yi8ejR+M0s 1H0Z9kAgrgL2VlywwHuL9+3r3oUXr8m54opB4z0SqFKVilUcSvDJUY5KVapa1faoPnZCAAEE EEAgVgLEDWIl3f12/BY7IG4QxjEkbhAGEkUQCKbA/v3urL62upLd82ez9tiqS2fPBnM89DoO AharLSmRbIpoO4kyM93HHfxdJQ49pEkEEEAAAQQQSAIBknt8fJDDCdKdOXNGn//853XjjTfq K1/5im6//XbdeeedWrRokW644QZt3bq1zQj/5m/+RrNmzVJhYaEGDx6s9PT0Fskgu3btUklJ icaNG6eMjAwnYaSgoMDZ59e//nWb+rp6wvpwyy23aMiQIcrOztaFF17o1J2VleU8Z/1ur59N 9d5xxx368pe/7IzpH/7hH/S1r31Nt912m2wc1113nZMwZGUtCekLX/iCbr75Zv3P//k/HYe/ +7u/c8pdf/31Ki8vb6rS+fe9997TwoUL9dd//deycuZmdVu9v/vd70JlY+0VajiMX5YuXeoc 58zMzFBijyX3DBgwQEVFRW1+zCWcrbfHLJw2ul2mN8k9Tz3l/dXfLr4efbR7zdv76JZbpCFD 3Kv/Cy+U7NaerCz3ua98RWrnvdZhI+0l95w8Kd19t2RTjdjFofUzPV0aM0a6/Xbpj3/ssDpe QCBZBWwq7bIyKTfXe4vbVNp79iSrCOPurcALekGjNTqU5HORLtIreqW31bI/AggggAACURMg buDSxjtuYL3wa+yAuEGYbz/iBmFCUQyBYAnYPXkWEs7P9+IGc+dK27YFaxz01kcCFRXSxIne CWWx29WrfdRBuoIAAggggAACiSxAco+Pj264QbpBgwa1SOyw5I5+/fpp2rRpevvtt9uM8Npr r9Ull1yi1NTU0H5NM738x3/8h3JycvT3f//3eu2113T06FG98847uueee0Jlv/jFL7aps70n 6urqnGQZSx6y5KCnn35alozUtJ09e1bLly/XJz7xCSfByBKKbJ/W21e/+lV96lOfCiUa2fjs p3///pozZ06L5J6rr77aGVtTGfvXxjllyhQ9/vjjLaq25J7x48eHxtW0jz23Zs2aUNlYeYUa 7MYvlsRl/bOfyy+/PDSWgQMHhp5vet3+NePOtkgds87a6PFrPUnuOXxYsoQmS5KxZJnRo6Xn nw+/C3Y+fu1r7v4FBdLTT0vNzmHn9p7ly6VPfMItY77tnMNtGmyd3PPSS+5aQldfLT37rJuZ cPq0mzD0z/8s2XrOdmvRl78snTjRpjqeQCAZBV57TZowwYuljB0rvfhiMkow5kgLnNZpZ9ae LGU5ST6pSnVm9Tmog5FuivoQQAABBBDotQBxA5cw3nED64Vdc8ci1tLdk4a4QRdixA26AOJl BIIrsHGjNH26FzcYOtRN9AnuiOi5bwTq69u/22z3bt90kY4ggAACCCCAQGIKkNzj4+MaTpDO un///feHkjpsNh6boaa9JJnWQ3355ZdD+1lyzy9/+UuNGDFCmzdvbl3UeXzrrbeGyq9cubLd Mk1PWhLPZz/7Waf83Llz9dFHHzW91ObfU6dOycpYcs3s2bN12pIa2tleeeWVUPtW9s0332yn lPvU4sWLQ2X/8R//scNy9sK3vvUtp2xubq5Wd5JlH02vTjsY5ou//e1vQ2NuStYKc1enWDSO WXfa77Js8+SeqVOlF15o/+eJJ6R/+ifp85+XBgxwZ8H5i7+QHnpI6uDcardtS+L57GfdCIDd 0tPJOaxTpyQrYwlEtuZyV+00T+7JyZHOP1/qbFasXbukiy9267/oIqmqqt0u8yQCySBw5Ii0 aJGb72ZvOZvoavHilnl3yeDAGKMv8K7e1XzND83iM1ADVaYyNSh4S4pGX4sWEEAAAQTiJUDc oKV8vOMG1hs/xw6IG/w5jkDcoOUbh0cIJJhATY0bJ2i6189WUbI4AvfLJdiB9sNw9u2TFi70 MsgszrtkiWTJP2wIIIAAAggggEAUBEjuiQJqpKoMJ0j34YcfauTIkc7MN5bQYrPhhLtZMkfT bDWjRo2SzQD0+9//vsPdbTabpvKf+9znOixnL9iSYFbWZpA5dOhQp2XtxcOHDzsz8dg+ttRW R5slrTT1wWYZ6mizGYeaytlSXZ1t69evd8r+5Cc/6ayYM+tQU52R9uq04TBf7G2QLlrHLMzu d12seXJP//7urTd2+017P5/5jFRYKPXtK33609K990o2ZWo33h+64Qb3wmzgQCmMc1h2t5/1 y7INOjmHnYE2T+6xCMP//b9dj//dd6WMDLf+Sy/tOoGo6xopgUCgBBob3TvsBg3yYiZz5nRv RbxADZjO+kZguZZriIaEknxmaqY2q/1EaN90mo4ggAACCCSNAHGDtoc6nnED6000Yy1tR9u9 Z4gbNIshEDfo3slDaQQCIrBqlTR8uBc3sPsD33gjIJ2nm8EVsBNv5EjvxJs0SVq/PrjjoecI IIAAAggg4FsBknt8e2ikroJ0lZWVsiSTYcOGqcISF3qwNSWr2L9fs+WHOtlsea6m8hfbLCId bM8991yonCUchbvZDDtN9T/zzDPt7vbYY4+FytiSXB1tv/vd70Ll+vTp02mC0fe//33l5+eH lRjV1L9IenU0hu4+35sgXTSPWXfH0WH55sk9V17ZYbEWL9gSWc895y55ZUk3F1wg2R16XW22 j5W3n26cw7JZopr26+AcdppuntxjawmFu33pS179tlwXGwJJIrBpk3TZZd7pb6vklZdLlvDD hkAsBI7pmEpUojSlOUk+GcpwHlerOhbN0wYCCCCAAAIdChA3aEsT77iB9civsQPiBm3PF2dp beIG7cDwFALBEnj/fcnChU1hOZvMu6xMOncuWOOgtwEWsJndS0ulPn3cEzE1VSouDu+m0QAP m64jgAACCCCAQGwFSO6JrXe3WussSLds2TJlZWVp/vz5OnjwYLfqbV64ecDp9ddfb/5Sm9/3 7t0bClD169evzetNT0yePDlUzgJH4W6/+c1vQvvZOvXtbTU1NbK2m/r9rs1m0s72pS99SRdc cEGo3AMPPNBOKfvDcKOTIPX1r3+93ddbP9nUrv0bKa/WbfT0cW+CdNE8Zj0dT5v9epLc01TJ 0aNSUZF3hX/55dKHHza92vbfyZO9st04h/Wb33j7dXAOO401T+4ZN65t+x0989prXv32Huxq +a+O6uF5BAIi0DouYhNdWVzEJspiQyAeApWq1DRNC83iM0zDtEIr4tEV2kQAAQQQQMARIG7Q 9kSId9zAeuTX2AFxg7bnS+gZ4gYhCn5BIEgCdl+frYKUne2FzCwEuHdvkEZBXxNKYPt2ad48 74TMy5OWLuUOtYQ6yAwGAQQQQACB+AmQ3BM/+y5bbi9Id/r0ad18881OoGjGjBlqaGjosp7O CjQPOO2zNWI72ez1pvK5ubntlrRkm6Yy9u+2bdvaLdfek1u3bm2x73b7j3A726233hoq197M QLbElyU+2bJdhYWFTtmLLrqonZqkpqXGrO1wtuZji4RXOG2GW6anQbpYHLNwx9Bpud4k91jF tuD2xz/uXVjZOVHdzowLljDWdJuP/duNc1h2HjXft4NzWD1N7rH+2l0fTW08+2ynZLyIQJAF bEbjESO8091y7jZsCPKI6HuiCNSrXmUqUz/1CyX5FKlIu7QrUYbIOBBAAAEEAiRA3MB/cQM7 ffwaOyBu0MWbm7hBF0C8jIC/BNaulQoLvbiB3T/38sv+6iO9SVKBprXlBw/2TtDZs6UtW5IU hGEjgAACCCCAQKQESO6JlGQU6mkdpLMkjE9+8pMtgkTLly/vVcvNA07Hjx/vtK5wknt++ctf tujfRx991GmdzV88cOBAi30tOae9zZYja+r3xz72MdXZLRrNtgcffFADBgxw1rn/yU9+Eir7 ms160mq74YYbNHPmzFbPdvywqV37NxJeHbfU/Vd6GqSLxTHr/mja2aO3yT1W5VNPeRdUliBz 551tG/rlL1uW6cY5rAMHWu7bwTnc4+Qe663N2NOU3GNTvbIhkGACO3ZICxZ4p3nfvu5deEyl nWAHOgGGU6UqFas4lOCToxyVqlS1qk2A0TEEBBBAAIGgCBA38F/cwM4dv8YOiBuE8c4mbhAG EkUQiK/A/v3urL5N97/ZrD0WIjt7Nr79onUE2gjYrHAlJZJNRW3x3MxM93F7N5y22ZknEEAA AQQQQACBtgIk97Q18c0zzYN0w4cP1/nnn+8kotj68WlpaU6wKCcnRxs3buxxnyMdcLLlr5rX Wd2N/6ha2eb7LrE5VTvYmi8jtXLlyhalxo8frzvuuMN5zmbx6dOnj1PvTTfd1KJc02v//u// 3uL5zh4071+iJPfE6ph15hrWa5FI7rG78JoupuyCqn9/qVVymGwJt6bkGfu3G+ewU7b5vh2d wz2duceghg71+nfrrWHRUQiBIAjYW7GsTLKJ4ZreRjaV9p49Qeg9fUxmgRf0gkZrdCjJ5xJd onVal8wkjB0BBBBAIIYCxA38Fzeww+/X2EFPk3uIG7S8qYy4QQw/5GgKgWYCNoF9ebmUn+/F DebO7d6k282q41cEYidQUSFNnOiduGPGSKtXx659WkIAAQQQQACBhBEgucfHh7J5kM4CQ1// +tdVX1/v9Pi+++4LBYtGjBihgwcP9mgkkQ44LV26NNQvq7uqqirsfjWfGcj2feSRRzrc92c/ +1monQU2xcOft3Xr1jnPb9q0qekp2ew8Vl92draOWrb8n7emGX5sqbNwt0h7hdtuOOXCCdKd O3euzVJusTpm4Yyh0zKRSO6xBi680LuQsgwCW4ar+WZrIDdlFti/3TiHZUvbNd+3o3O4N8k9 zSMY3/pW857zOwKBFbCJ1SZM8N4+Y8dKL74Y2OHQ8SQUOK3Tzqw9WcpyknxSlerM6nNQPfv/ WRISMmQEEEAAgR4KEDfwX9zADqVfYwfEDcJ8oxE3CBOKYgjETsDubZ0+3Ysb2L1vlujDhkBg BOzvOu3d1bZ7d2CGQO/Vhu4AACAASURBVEcRQAABBBBAIP4CJPfE/xh02IPmQbri4uI25a6/ /vpQwGjWrFltlqdqs0M7T0Q64NQ8UGR1b968uZ1W23/qrbfeCo3H9n25k0WSbdYcm7XIytks Rnv37nUqvfnmm/XpT3+6RQPN+/TTn/409NqECRNCM/yEnuzil0h7ddFct15uPs7pdrXbzmbP 33XXXS1eab5fNI9Zi0Z78iASyT223nFenhcJsESc1hdQv/1ty9e7cQ7rrbda7tvROdzT5J4z Z6SmOYet77/4RU8k2QcB3wgcOSItWuSd1jY78eLFkp3qbAgEUeBdvav5mh+axWegBqpMZWpQ QxCHQ58RQAABBAIgQNzg5Q6PUrziBtYhv8YOml//Ezfo4NQhbtABDE8jEB8Bm4Tb4gTp6W7I zSbktjjCiRPx6Q+tItBrAbs5dOFCL4ack+OuR//nm7p7XT8VIIAAAggggEBCC5Dc4+PD2zxI d9ttt7Xp6alTpzRp0qRQ0GiRXdl0c4t0wKmurk4DBw4M9emZZ54Ju0fPP/98aL8BAwaotra2 030tkaep/9///vfVFLj73//7f7fYr7GxUWPGjHHKTrTpLyVt2LDBedx8hp8WO3XwoKk9+zeI y3K1l9wTy2PWAWt4T0ciuWf7du/CyZJjPvYxyeb0bb7Z2kADB3rlunEO6/nnvf0GDJA6Ood7 mtyzYYNXv2VBHD7cvOf8jkBgBCxebnfYDRrkndJz5khbtwZmCHQUgU4Flmu5hmhIKMlnpmZq s8JPeO60cl5EAAEEEECgmQBxA//FDezw+DV20NPkHuIGxA2afezwKwIxE1i1Sho+3IsbTJki vfFGzJqnIQSiK2An+MiR3gk+aZK0fn1026R2BBBAAAEEEAi8AMk9Pj6EXQXprOs7d+5Ufn5+ KHD08MMPd2tE0Qg4fec73wn1pzsJR7fffntov29/+9tdjqNpCS4bw6hRo/TQQw8pNzdX1dXV bfa99957Q3VbYs9Xv/pVfeYzn2lTrqsnouHVVZvhvt7cY9q0ae3uNn78eN1///1tXovVMWvT cHeeiERyzxe/6F0wWXLPPfe034PvfMcr152kudtv9/br7BzuaXKPzbpk/bafv/3b9vvOswj4 XMBWTbzsMu9ULihwE30s4YcNgUQSOKZjKlGJ0pTmJPlkKMN5XK22/09JpHEzFgQQQACB2AoQ N+jcu/l1cqziBtYjv8YOmnsQN+jg3CFu0AEMTyMQO4H335euvNKLG/Tv765mdO5c7PpASwjE RODUKam0VOrTxz3hbcZ2W8Hh0KGYNE8jCCCAAAIIIBA8AZJ7fHzMNm7cGAoI3XrrrR321O68 sqWpLHiUkZGh3/3udx2Wbf1C84DTsWPHWr/c4rEtfdVUvm/fvi1ea/7AZhT6xCc+4ZQ977zz tM+mmuxi279/f2iZrXHjxsnqCGcrLCwM9al///762w4SHj788EPHxvq/cOFCJwno5z//eThN tCjTNH77N1JeLRroxYNdu3aFLD5mM9K02mwGI1vKbOXKla1ekeMdq2PWpvFwn7jmGu+q3q7w u7stW+btb8kxdrtPRzPr2Pn3iU+45c87TwrjHNb+/ZJNo2p1jxtnqB33sHlyj83AE87SX9aH 3Fy3fltYnIu8jn15xZcCreMVNpW2xSuYgMqXh4tORVCgUpWapmmhWXyGaZhWaEUEW6AqBBBA AIFkFiBu0PXRj3XcwHrk19gBcYMuzhfiBl0A8TIC0RWwybSXLJGys93wl4XYioqkvXuj2y61 IxB3AZttft4878TPy5OWLpW4Ey7uh4YOIIAAAggg4DcBknv8dkSa9efVV18NBYS+aHcOdbLd cMMNobK2LNYf//jHTkq7L1lySvOAkwV5Ots2b94cKm/JRDYtc0fbBx98oKFDhzrlp0yZ0ukS VidPnpQtF2V9KSgo0Pt2e0aY27/8y7+E+mT7/9d//VeHe15zzTWhsv369VONLdrcjS2aXt3o RqdFL7nkktAY//CHP7Qoa0ukWbKVJVK1t8XqmLXXdljPzZzpXeDMnRvWLk4hG++NN3r7WmTg U5/qOjnmgw8kS6JpSgQ6frzjNk+elKZPd8vaNCRdncPNk3usjbFj5SQHddSCJd41jd+W+7Kp T9gQCJCAzTQ8YoT3Npw82ZZHDNAA6CoCvRSoV73KVKZ+6hdK8ilSkXap8/979bJZdkcAAQQQ SAIB4gZdH+RYxg2sN36PHRA3aOecIW7QDgpPIRBbgbVrpcJCL25g98299FJs+0BrCMRVoGkN +8GDvTfC7NnSli1x7RaNI4AAAggggIC/BEju8dfx0OnTp7Vs2TJZ8Gnq1KmhRI3s7GzZUlVL ly7Vm2++2aLXNlPP6NGjQ2UtySUrK0s333yzswTT0aNHW5R/4okn9K//+q+66qqrWuwzb948 /fSnP9Vjjz0WKm+zvVh/HnzwQc2cObNF+WuvvdZZCuupp54KlW/+i83YM3v2bGef4cOH6/HH H28x283x48f1i1/8QiNGjHDKWP02O1B3tkOHDqlPnz7O/pNsXdpOtueffz7U/85mQmpdRay8 Wrfbk8d216YtTWbngHkcOHDAqcamajfnb33rW51WG4tj1mkHmr/4299KdtdcWZn0pS95FzWW bGO38Hz3u+4dDDYDU+sfW57ujjukOXMkm2XK9rEfW8f4F7+Qwp3H12bLsYso29cW+X78cYvU er20hB+rrylrwRJwwjmHm5J7Bg1yk4yuu85NJLL3UvO+NTRIzzzjzSJ06aWSJR2xIRAQgR07 pAULvLegvR3tLrzmp3lAhkI3EYiIQJWqVKziUIJPjnJUqlLVqjYi9VMJAggggEByCBA38F/c wM68oMQOiBv8OYZA3CA5PjAZpe8FLLfOZvW11YiaQn62StGZM77vOh1EIDoC9reckhLJpry2 N4XN+m6Pq1niOzrg1IoAAggggECwBEju8dnxsmSMzMxMnX/++bKllSxpx5apGjZsmPLy8mRJ Pvfcc0+LXpeUlDgJHVbe1pC35ZVGjhyp/Px8J8lnS6vsbku0sdl9bGYdK3/hhRc67VxwwQVO G9Z203bu3DknecbattetP1be9rPHVo9Ncd3RZslBtgzUrFmzlJ6e7vxYu9ZXm/3HnrOknl// +teysj3ZbrrpJieZ5dFHH+10dxuL9dsSXyyYFe4WS69w+9RZubVr1+pTn/qUM07zNWsb8//6 X/9LZtDVFotj1lUfnNcXLvQyAuxCpic/di7brDg33CBZ0lpHy3B11iE7L20ps1mzpPR098dm 27Glz+wiy56zpJ5f/zr8qVKbknseecRt2dqw/o0aJdkyYJ/+tPTZz0oDB7rRDZtp6IknyIjo 7Djxmq8EbGI3y8trWknO3r42lfaePb7qJp1BIG4CL+gFjdboUJLPJbpE67Qubv2hYQQQQACB YAkQN+j+8Yp23MB6FKTYAXGDZjEG4gbdf0OxBwIRELD72crLpfx8L+RnE3Vv2xaByqkCgUQQ qKiQJk703iBjxkirVyfCyBgDAggggAACCPRCgOSeXuCxa/cEbAYhm2XoV7/6lfNjv7eeVah7 Nbqljxw5oueee67TZcKa6rUlv35rM8IkwWbLqNlSXM8++2yHS3F1xRCtY9ZVu7593e6c+N3v pF/9yv2x31vNjNXrvlviz3/+p5vMs2aN9NFHva6SChCIpcBrr0kTJnixB8uve/HFWPaAthAI hsBpnXZm7clSlpPkk6pUZ1afgzoYjAHQSwQQQAABBKIgEK1rUOIG7R8s4gbtu/TqWeIGveJj 5+QQsHsum1a3t5uB7B46S/RhQwCBVgL19e3fPbd7d6uCPEQAAQQQQACBZBEguSdZjjTjRAAB BBBAIIoCR45IixZ5U2nbrMGLFzOVdhTJqTpBBN7Vu5qv+aFZfAZqoMpUpgY1JMgIGQYCCCCA AAIIIIAAAgggINXUuHECmwTbknpsQmyLI5w4gQ4CCHQqsG+f1HyW+5wcd917S/5hQwABBBBA AIGkEiC5J6kON4NFAAEEEEAgsgK2qpzdYTdokDdbz5w50tatkW2H2hBIdIHlWq4hGhJK8pmp mdqszYk+bMaHAAIIIIAAAggggAACSSCwapUtX+jFDaZMkd54IwkGzhARiKSAvZFGjvTeSJMm SevXR7IF6kIAAQQQQAABnwuQ3OPzA0T3EEAAAQQQ8KvApk3SZZd5MYWCAjfRxxJ+2BBAoPsC x3RMJSpRmtKcJJ8MZTiPq1Xd/crYAwEEEEAAAQQQQAABBBCIs8D770tXXunFDfr3d1cZOncu zh2jeQSCKnDqlFRaKvXp476xUlOl4mLp0KGgjoh+I4AAAggggEA3BEju6QYWRRFAAAEEEEBA ah1HsKm0LY5w+DA6CCAQCYFKVWqapoVm8RmmYVqhFZGomjoQQAABBBBAAAEEEEAAgagL1NW5 qwZlZ3uJPUVF0t69UW+aBhBIDoHt26V587w3WF6etHSpxB13yXH8GSUCCCCAQNIKkNyTtIee gSOAAAIIINB9AZsBeMQIL3YwebK0YUP362EPBBDoXKBe9SpTmfqpXyjJp0hF2qVdne/Iqwgg gAACCCCAAAIIIIBAHAXWrpUKC724wbhx0ksvxbFDNI1AogpYIk95uTR4sPeGmz1b2rIlUUfM uBBAAAEEEEh6AZJ7kv4UAAABBBBAAIGuBXbskBYs8GIFffu6d+ExlXbXdpRAoDcCVapSsYpD CT45ylGpSlWr2t5Uy74IIIAAAggggAACCCCAQEQF9u93Z/W1VYJSUiSbtcdWDzpzJqLNUBkC CLQWOHpUKimRbGpte/NlZrqPq1niuzUVjxFAAAEEEAi6AMk9QT+C9B8BBBBAAIEoCthU2mVl Um6ul9hjU2nv2RPFRqkaAQTaCLygFzRao0NJPpfoEq3TujbleAIBBBBAAAEEEEAAAQQQiKVA Q4M7eUh+vhc3mDtX2rYtlr2gLQQQUEWFNHGi90YcM0ZavRoYBBBAAAEEEEggAZJ7EuhgMhQE EEAAAQQiKfDaa9KECV5MYOxY6cUXI9kCdSGAQHcETuu0M2tPlrKcJJ9UpTqz+hzUwe5UQ1kE EEAAAQQQQAABBBBAICICGzdK06d7cYOhQ91En4hUTiUIINB9gfr69u/S2727+3WxBwIIIIAA Agj4ToDkHt8dEjqEAAIIIIBAfAWOHJEWLZKaptK22XwXL2Yq7fgeFVpHwBN4V+9qvuaHZvEZ qIEqU5ka1OAV4jcEEEAAAQQQQAABBBBAIEoCNTVunCA93U3ssdWALI5w4kSUGqRaBBDonsC+ fdLChV7mXU6OtGSJZMk/bAgggAACCCAQWAGSewJ76Og4AggggAACkRVobHTvsBs0yLv2nzNH 2ro1su1QGwIIREZguZZriIaEknxmaqY2a3NkKqcWBBBAAAEEEEAAAQQQQKAdgVWrpOHDvbjB lCnSG2+0U5CnEEAg/gL2hh050nvDTpokrV8f/37RAwQQQAABBBDokQDJPT1iYycEEEAAAQQS S2DTJumyy7xr/YICN9HHEn7YEEDAvwLHdEwlKlGa0pwknwxlOI+rVe3fTtMzBBBAAAEEEEAA AQQQCJzA++9LV17pxQ3693dX/zl3LnBDocMIJJfAqVNSaanUp4/7BrapuouLpUOHksuB0SKA AAIIIJAAAiT3JMBBZAgIIIAAAgj0VKD19b1NpW3X94cP97RG9kMAgXgIVKpS0zQtNIvPMA3T Cq2IR1doEwEEEEAAAQQQQAABBBJIoK7OXc0nO9tL7CkqkvbuTaBBMhQEkkHgrbekGTO8N3Je nrR0qcSdfclw9BkjAggggECCCJDckyAHkmEggAACCCDQXQGbmXfECO+afvJkacOG7tZCeQQQ 8ItAvepVpjL1U79Qkk+RirRLu/zSRfqBAAIIIIAAAggggAACARJYu1YqLPTiBuPGSS+9FKAB 0FUEEGgpYIk85eXS4MHeG3v2bGnLlpbleIQAAggggAACvhQguceXh4VOIYAAAgggED2BHTuk BQu8a/i+fd278JhKO3rm1IxALAWqVKViFYcSfHKUo1KVqla1sewGbSGAAAIIIIAAAggggEBA Bfbvd2f1tdV7UlIkm7XHVvU5cyagA6LbCCDQUuDoUamkRLIpvO1NnpnpPq5mie+WUDxCAAEE EEDAXwIk9/jreNAbBBBAAAEEoiZgU2mXlUm5uV5ij02lvWdP1JqkYgQQiKPAC3pBozU6lORz iS7ROq2LY49oGgEEEEAAAQQQQAABBPws0NDgTuqRn+/FDebOlbZt83Ov6RsCCPRYoKJCmjjR e8OPGSOtXt3j6tgRAQQQQAABBKIrQHJPdH2pHQEEEEAAAV8IvPaaNGGCd60+dqz04ou+6Bqd QACBKAqc1mln1p4sZTlJPqlKdWb1OaiDUWyVqhFAAAEEEEAAAQQQQCBoAhs3StOne3GDoUPd RJ+gjYP+IoBANwXq69u/G3D37m5WRHEEEEAAAQQQiLYAyT3RFqZ+BBDwjcDx48f13HPPqd4u WNgQSBKBI0ekRYukpqm0bZbdxYuZSjtJDj/DRCAk8K7e1XzND83iM1ADVaYyNaghVIZfEEAA AQQQQACBZBeweMHTTz+tM6w9lOynQlKNv6bGjROkp7uJPbZKj8URTpxIKgYGiwAC+/ZJCxd6 GX45OdKSJRKxdM4NBBBAAAEEfCNAco9vDgUdQQCBaAs88sgjSklJUUFBgUpKSvTWW29Fu0nq RyBuAo2N7h12gwZ51+Rz5khbt8atSzSMAAJxFmhUo8pVriEaEkrymamZ2qzNce4ZzSOAAAII IIAAAv4QePbZZ524Qf/+/bVo0SK9+eab/ugYvUAgSgKrVknDh3txgylTpDfeiFJjVIsAAsEQ sA+GkSO9D4ZJk6T164PRd3qJAAIIIIBAgguQ3JPgB5jhIYCAJ/Dtb39bffr0cQJ1luRjPzNn ztQvfvEL1dhtSmwIJIjApk3SZZd51+AFBW6ijyX8sCGAAALHdEwlKlGa0pwknwxlOI+rVQ0O AggggAACCCCQ1AJlZWU677zzWsQNpk6dqocfflhHjx5NahsGn1gC778vXXmlFzfo399dlefc ucQaJ6NBAIEeCpw6JZWWSn36uB8UNiV4cbF06FAPK2Q3BBBAAAEEEIiEAMk9kVCkDgQQCIyA BeOWLl2qSZMmtQjW9evXT8XFxVqzZo0ayYAIzPGkoy0FWl9321Tadt19+HDLcjxCAAEETKBS lZqmaaFZfIZpmFZoBTgIIIAAAggggEBSC5w4ccKJG8yYMaNF3CArK0vXXXedVq1apXNkQCT1 ORLkwdfVuavsZGd7iT1FRdLevUEeFX1HAIGoCdjM9zNmeB8YeXnS0qUS8fOokVMxAggggAAC nQmQ3NOZDq8hgEBCC1RWVjrLc+Xl5bUI2F188cVasmSJDhw4kNDjZ3CJJWAz5o4Y4V1rT54s bdiQWGNkNAggEHmBetWrTGXqp36hJJ8iFWmXdkW+MWpEAAEEEEAAAQQCJrB161YtXrxYgwcP bhE3+PjHP+48v2PHjoCNiO4ms8DatVJhoRc3GDdOeumlZBZh7AggEJaAJfKUl0uDB3sfILNn S1u2hLU7hRBAAAEEEEAgcgIk90TOkpoQQCCgAmfOnNHy5cs1f/58paamhgJ26enpznP2Wn19 fUBHR7cTXcBiyQsWeNfWffu6d+FxI2miH3nGh0BkBapUpWIVhxJ8cpSjUpWqVrWRbYjaEEAA AQQQQACBAArU1tY6M/bYzD0ZGRmhuEFaWpoTNygvL9fp06cDODK6nAwC+/e7s/raqjopKZLN 2mOr7Zw5kwyjZ4wIIBAxAVuesqREsqnC7cMkM9N9XM0S3xEzpiIEEEAAAQS6ECC5pwsgXkYA geQS2L59u3P33dChQ0PBupSUFA0bNkyvv/56cmEwWl8L2FTaZWVSbq6X2GNTae/Z4+tu0zkE EPC5wAt6QaM1OpTkc4ku0Tqt83mv6R4CCCCAAAIIIBA7gd27d+uee+7RqFGjWsQNBg0apGee eSZ2HaElBLoQaGhwJ9vIz/fiBnPnStu2dbEjLyOAAAKdCVRUSBMneh8sY8ZIq1d3tgevIYAA AggggECEBEjuiRAk1SCAQGIJnDt3TmvWrJHdlZeZmencmffhhx8m1iAZTWAFLM9swgTvGnrs WOnFFwM7HDqOAAI+Ezit086sPVnKcpJ8UpXqzOpzUAd91lO6gwACCCCAAAIIxE+goaFBFRUV WrRokXJycpxEnz/96U/x6xAtI9BMYONGafp0L24wdKib6NOsCL8igAACPRewWe7bu+tw9+6e 18meCCCAAAIIINClAMk9XRJRAAEEkl1g//79+s///M9kZ2D8PhA4ckRatEhqmkrbZr9dvJip tH1waOgCAgkp8K7e1XzND83iM1ADVaYyNaghIcfLoBBAAAEEEEAAgZ4KHD16VL/85S97ujv7 IRAxgZoaN06Qnu4m9tjqORZHOHEiYk1QEQIIIOAJ7NsnLVzoZRL27SstWSJZ8g8bAggggAAC CERcgOSeiJNSIQIIIIAAApEVaGx077AbNMi7Vp4zR9q6NbLtUBsCCCDQWqBRjSpXuYZoSCjJ Z6ZmarM2ty7KYwQQQAABBBBAAAEEEIijwKpV0vDhXtxgyhTpjTfi2CGaRgCB5BGwD6CRI70P oEmTpPXrk2f8jBQBBBBAAIEYCZDcEyNomkEAAQQQQKAnAps2SZdf7l0bFxS4iT6W8MOGAAII xErgmI6pRCVKU5qT5JOhDOdxtapj1QXaQQABBBBAAAEEEEAAgXYEPvhAuuoqL27Qv7+7Ws65 c+0U5ikEEEAgWgKnTkmlpVKfPu4Hkk09XlwsHToUrRapFwEEEEAAgaQTILkn6Q45A0YAAQQQ CIJA6+thm0rbrocPHw5C7+kjAggkqkClKjVN00Kz+AzTMK3QikQdLuNCAAEEEEAAAQQQQMC3 AnV17uo32dleYk9RkbR3r2+7TMcQQCAZBN56S5oxw/tgysuTli6VuFMxGY4+Y0QAAQQQiLIA yT1RBqZ6BBBAwAQOHTqkJ598UmfOnAEEgS4FbCbbESO8a+DJk6UNG7rcjQIIIIBATATqVa8y lamf+oWSfIpUpF3aFZP2aQQBBBBAAAEEEEhEgbNnz+rxxx9XdTUzIybi8Y30mNaulcaP9+IG 48ZJL70U6VaoDwEEEOihgCXylJdLgwd7H1SzZ0tvv93DCtkNAQQQQAABBEyA5B7OAwQQQCAG Aj/5yU+UkpKi/v37a9GiRXrzzTdj0CpNBE1gxw5pwQLvmrdvX/cuPKbSDtqRpL8IJIdAlapU rOJQgk+OclSqUtWqNjkAGCUCCCCAAAIIIBBBgaeeesqJG2RnZ+u6667TmjVr1MgsBxEUToyq DhxwZ/W11W5SUiSbtcdWweFessQ4vowCgYQTOHpUKimRbEpy+9DKzHQf19Qk3FAZEAIIIIAA ArEQILknFsq0gQACSS/wve99T+edd54TqLMkH/uZOnWqHn74YR07dizpfZIdwKbSLiuTcnO9 xB6bSnvPnmSXYfwIIBAEgef1vEZpVCjJ5xJdonVaF4Su00cEEEAAAQQQQMA3Ag899JBzQ1BT zMD+vfjii/XjH/9YByyjgy2pBZomwcjP9+IGc+dK27YlNQuDRwCBoAhUVEgTJ3ofYGPGSKtX B6X39BMBBBBAAAHfCJDc45tDQUcQQCDRBU6cOKGlS5dqxowZLZJ8srKyuCsv0Q9+J+N7/XVp wgTv2nbsWOnFFzvZgZcQQAABHwqc1mln1p4sZTlJPqlKdWb1OaiDPuwtXUIAAQQQQAABBPwp YEt5L1++XPPnz1dqamoodpCenu48Z6/V2d0hbEklsHGjNH26FzcYOtRd7SapEBgsAggEX6C+ vv27G3fvDv7YGAECCCCAAAIxEiC5J0bQNIMAAgg0F9i6dasWL16swYMHh4J1dlfexz/+cef5 nTt3Ni/O7wkocOSItGiR1DSVts1Ku3gxU2kn4KFmSAgklcA7ekfzNT80i89ADVSZytSghqRy YLAIIIAAAggggEBvBd59912VlpZq5MiRLeIGQ4cOdeIG9jpbYgvYqjUWJ0hPdxN7bFUbiyOc OJHY42Z0CCCQ4AL79kkLF3oZi337SkuWSJb8w4YAAggggAACnQqQ3NMpDy8igAAC0RWora3V qlWrnJl7MjIyQgG7tLQ056688vJynT59OrqdoPaYCjRNpT1okHcNO2eOtHVrTLtBYwgggEDU BBrVqHKVa4iGhJJ8ZmqmNmtz1NqkYgQQQAABBBBAIFEFGhoatGbNGidukJmZGYob2A1Cl156 qTNDcI1lgbAllMCqVdLw4V7cYMoU6Y03EmqIDAYBBJJdwD7oRo70PugmTZLWr092FcaPAAII IIBApwIk93TKw4sIIIBA7AR2796tu+++u81deTa7T4WtS8wWeIFNm6TLL/euWQsK3Km0LeGH DQEEEEg0gaM6qhKVKE1pTpJPhjKcx9WqTrShMh4EEEAAAQQQQCAmAgcOHNCPfvQjXXzxxS2S fPr3769nnnkmJn2gkegKfPCBdNVVXtygf393FZtz56LbLrUjgAACcRE4dUoqLZX69HE/+GyK 8+Ji6dChuHSHRhFAAAEEEPC7AMk9fj9C9A8BBJJOwO7Ks2SeRYsWKScnR9nZ2TpiazixBVag 9XWqTaVt16mHDwd2SHQcAQQQCFugUpWapmmhWXyGaZhWaEXY+1MQAQQQQAABBBBAoK1AZWWl Ezfo16+fUlNTxTJdbY2C9ExdnbsqTXa2l9hTVCTt3RukUdBXBBBAoIcCb70lzZjhfQDm5UlL l0rcEdlDUHZDAAEEEEhUAZJ7EvXIMi4EEEgIAUvqefHFFxNiLMk6CJthdsQI79p08mRpw4Zk 1WDcCCCQrAL1lX8Q2QAAIABJREFUqleZytRP/UJJPkUq0i7tSlYSxo0AAggggAACCERE4OTJ k3ruueciUheVxEdg7Vpp/HgvbjBunPTSS/HpC60igAACcROwRJ7ycmnwYO8DcfZs6e2349Yl GkYAAQQQQMBvAiT3+O2I0B8EEEAAgYQQ2LFDWrDAuxbt29e9C4+ptBPi8DIIBBDooUCVqlSs 4lCCT45yVKpS1aq2hzWyGwIIIIAAAggggAACwRQ4cMCd1ddWoUlJkWzWHlud5syZYI6HXiOA AAIRETh6VCopkWzqc/twzMx0H9fURKR6KkEAAQQQQCDIAiT3BPno0XcEEEAAAd8J2FTaZWVS bq6X2GNTae/Z47uu0iEEEEAgbgLP63mN0qhQks8lukTrtC5u/aFhBBBAAAEEEEAAAQRiJdA0 OUV+vhc3mDtX2rYtVj2gHQQQQCAAAhUV0sSJ3gflmDHS6tUB6DhdRAABBBBAIHoCJPdEz5aa EUAAAQSSTOD116UJE7xrzrFjJVZVS7KTgOEigEDYAqd12pm1J0tZTpJPqlKdWX0O6mDYdVAQ AQQQQAABBBBAAIEgCWzcKE2f7sUNhg51V6EJ0hjoKwIIIBAzgfr69u+i3L07Zl2gIQQQQAAB BPwkQHKPn44GfUEAAQSiIFBVVaXHHntM1dXVUaidKk3gyBFp0SKpaSptmy128WKm0ubsQAAB BMIReEfvaL7mh2bxGaiBKlOZGtQQzu6UQQABBBBAAAEEEOilQE1NjR5++GEdtaVQ2KIiYKvJ WJwgPd1N7LHVZiyOcOJEVJqjUgQQQCCxBPbtkxYu9DIj+/aVliyRLPmHDQEEEEAAgSQSILkn iQ42Q0UAgeQU+MEPfqCUlBSdd955uu6667RmzRo12hzQbL0WaJpKe9Ag79pyzhxp69ZeV00F CCCAQFIJNKpR5SrXEA0JJfnM0ixt1uakcmCwCCCAAAIIIIBAPAQef/xxJ26QlZXlxA1WrVql c+fOxaMrCdnmqlXS8OFe3GDKFOmNNxJyqAwKAQQQiK6AfaCOHOl9oE6aJK1fH902qR0BBBBA AAEfCZDc46ODQVcQQACBaAjcc889Ov/8851AnSX52E9hYaF+/OMf68CBA9FoMinq3LRJuvxy 71qyoMCdSpu8qaQ4/AwSAQSiJHBUR1WiEqUpzUnyyVSm87hazD4XJXKqRQABBBBAAAEE9LOf /UyDBg1qETcYNWqULJ6wm6VPenyGfPCBdNVVXtygf393dRnypnpMyo4IIICAdOqUVFoq9enj fsDaVOrFxdKhQ+gggAACCCCQ8AIk9yT8IWaACCCAgC0PdUbLly/X/PnzlZqaGgrYpaenO8/Z a3V1dVCFIdD6+tGm0rbrx8OHw9iZIggggAACYQlUqlLTNC00i88wDdMKrQhrXwohgAACCCCA AAIIdF+gtrZWNmOPzfibkZERihukpaU5cYPy8nKdPn26+xUn4R4WXrHVYrKzvcSeoiJp794k xGDICCCAQLQE3npLmjHD+6DNy5OWLpW48zJa4tSLAAIIIOADAZJ7fHAQ6AICCCAQS4F3331X paWlGjlyZChYZ7P5DB06VIsXL5a9zta+gM38OmKEd804ebK0YUP7ZXkWAQQQQKB3AvWqV5nK 1E/9Qkk+RSrSLu3qXcXsjQACCCCAAAIIINCpQFVVlZYsWaKxY8e2iBsMGDBAixYt0h//+MdO 90/mF9eulcaP9+IG48ZJL72UzCKMHQEEEIiigCXylJdLgwd7H7yzZ0tvvx3FRqkaAQQQQACB +AmQ3BM/e1pGAAEE4irQ0NCgNWvWOHflZWZmtgjYXXrppVq6dKmqq6O3DMrbb78dmNmCduyQ FizwrhH79nXvwmMq7biewjSOAAJJIlClKhWrOJTgk6MclapUtapNEgGGiQACCCCAAAIIxEfA 4gYVFRVOQk9OTk6LuMH48eOdBKDDUZzG9p133tEpmz43AJutem6z+trqMCkp7qw9tmrMmTMB 6DxdRAABBIIucPSoVFIi2RTr9iGcmek+rqkJ+sjoPwIIIIAAAi0ESO5pwcEDBBBAIDkFDhw4 oB/96Ee6+OKLWwTr+vfv7wTyIq1id/nZbEE/+clPIl11ROuzqbTLyqTcXC+xx6bS3rMnos1Q GQIIIIBAGALP63mN0qhQks8n9Un9Xr8PY0+KIIAAAggggAACCPRW4OjRo3r44Yc1derUFnGD 8847TytXruxt9W32t9mDbCnxb3zjG21e89MTTZNG5Od7cYO5c6Vt2/zUS/qCAAIIJIlARYU0 caL3gTxmjLR6dZIMnmEigAACCCSDAMk9yXCUGSMCCCDQDYHKykrnrrx+/fqpb9++OnnyZDf2 Dq/oiy++6AQD77vvvvB2iEOp11+XJkzwrgXHjpVefDEOHaFJBBBAAIGQwGmddmbtyVKWk+ST qlRnVp+DOhgqwy8IIIAAAggggAAC0RWwmXhtWe9BgwYpLS1Nu3fvjniDmzZtcuIGd9xxR8Tr jlSFGzdK06d7cYOhQ93VYSJVP/UggAACCPRAoL6+/bs1o/Bd1YPesQsCCCCAAAK9EiC5p1d8 7IwAAggkroAtyfW6ZbhEYbNpvW3mnjvvvDMKtfeuyiNHpEWLvKm0bRbXxYuZSrt3quyNAAII RFbgHb2j+ZofmsUnT3kqU5ka1BDZhqgNAQQQQAABBBBAoEOBM2fO6JVXXunw9d688MEHHzhx gxtuuKE31URlX1vlxeIE6eluYo+tAmNxhBMnotIclSKAAAII9ERg3z5p4UIvA7NvX2nJEsmS f9gQQAABBBAIqADJPQE9cHQbAQQQCLLAsWPHlJqaqpkzZ/pmGE1TaQ8a5F3zzZkjbd3qmy7S EQQQQACBZgKNalS5yjVEQ0JJPrM0S5u1uVkpfkUAAQQQQAABBBAIokBjY6NsRuExtqSKj7ZV q6Thw724wZQp0htv+KiDdAUBBBBAoKWAfXCPHOl9cE+aJK1f37IMjxBAAAEEEAiIAMk9ATlQ dBMBBBBINIHPfOYzSk9P10cffRT3oW3aJF1+uXeNV1DgTqVtCT9sCCCAAAL+FjiqoypRidKU 5iT5ZCrTeVytan93nN4hgAACCCCAAAIIdCrw+c9/3pm9Z/Pm+Cdvf/CBdNVVXtygf3931Zdz 5zodAi8igAACCPhB4NQpqbRU6tPH/SBPTZWKi6VDh/zQO/qAAAIIIIBA2AIk94RNRUEEEEAA gUgK/OhHP3KCdA8++GDY1R4/Lv3qV9KNN0rTpkkXXCBZIs7kydIXviD9/OdSd3KFWl/X2VTa dl13+HDYXaIgAggggIBPBCpVqWmaFprFZ5iGaYVWhN07mwnoD/qD/kn/pM/qs7pIF2mgBupC Xag5mqO7dJf+n/4fS3+FLUpBBBBAAAEEEECgdwJPPPGEEzf4x3/8x7Arsuv8lSulv/kbafp0 6eMfl4YMkS65RPqrv5J+9jNp796wq1NdnZvEY6u5pKS4P0VF3asj/NYoiQACCCAQVYG33pJm zPA+0PPypKVLpe7c4Wl1/PM/S3/xF1JhoZSfL40dK9kM9XfeKb36qkTmZ1QPI5UjgAACySxA ck8yH33GjgACCERZYOfOnXrooYd09OjRNi3ZjD1ZWVkaN26cznVxwWPr2duSyOef7117NQXV Wv+bmemudb9/f5smWzxhM7KOGOHVZwlCGza0KMIDBBBAAIGACdSrXmUqUz/1CyX5FKlIu7Sr 05H8Xr/XDM0I7ZPSyW8TNEHLtbzT+ngRAQQQQAABBBBAIDwBW7b7hz/8ofa3cxF/5swZDRo0 SHl5eaqxwEAnW22t+/dZS+RpHSdo/dhu7LnuOmnHjk4qlLR2rTR+vFffuHHSSy91vg+vIoAA Agj4XMASecrLpcGDvQ/42bOlt9/uvOP/9V/SvHnePq2/XJo/tmXArI3uJA113jqvIoAAAggg 4AiQ3MOJgAACCCAQNYHvfOc7zl12lsRz3XXXadWqVS0Seb7yla84rz/22GMd9mHjxpZJOM2v kzr7feBA6Te/aVutBe8WLPCuw+zuO0sc6iK/qG1FPIMAAggg4FuBKlWpWMWhFJ0c5ahUpapV bYs+16lOt+rWULnOknpav3azbtZZnW1RHw8QQAABBBBAAAEEuifwyCOPOHEBW7Z7/vz5Wr58 uepsupw/b01xhX+2WRI62N5/v2USTmexguav5eRITz/dttIDB9xZfW3VFiufne2u5nLmTNuy PIMAAgggEFABuxm1pESyjE/7sLc7Ru1x62RSS9D5p3+Smr4Umn+RdPW7TfV24kRAgeg2Aggg gIAfBUju8eNRoU8IIIBAggjcd999zl12KSkpTrDO/h01apTuuece7d69W/v27VNOTo4uuOAC nbK5s1ttdkdc86mvu7peav16Rob0+ONupU1Taefmeok9dn21Z0+rRnmIAAIIIJAwAs/reY3S qFDyzif1SdksPbad1mnN1dzQa62Td8J5fLkuV7WqE8aLgSCAAAIIIIAAArEWWLp0qYYNGxaK GVjcYOjQoVq8eLHeeecdnTx5UkOGDFFubq4OWNZNq80mUrAVUVrHA8J9bH+rtRt+bGuazKF5 fXPnStu2tWqUhwgggAACiSNQUSFNnOh9kYwZI61e7Y7P7ga1qd7C/VJpr9yECdJHHyWOFyNB AAEEEIirAMk9ceWncQQQQCDxBWpra50Ze2zmnoyMjFDALi0tzbkr7+qrr3aes4Sf5psFz/r3 7921k11PWYLPK69IL7/s1cVU2s2l+R0BBBBIbIFTOqW7dJcylekk8lyki2TLd92oG3uV2NOU /HOtrlWDGhIbkdEhgAACCCCAAAJRFGhoaNCaNWucGX/79OkTihtYos+ll16q66+/3nnutttu a9GLqipp2DDvWr+9v6mG85wl+PzqV9KmTVJ6ulvfBRdITz3VojkeIIAAAggkqoDdFXr//ZJN 6WZfHLbGY3W1dOedvf+Ssfouv1w6y8y/iXr6MC4EEEAglgIk98RSm7YQQACBJBfYs2ePvv/9 72v06NEtgnWW9JOZmal169Y5QvX1UmFhZK6d7PrJllA+dkz60pek731PYirtJD8RGT4CCCSl wBZt0WzN1hqt0b/p3yKS2NOU4PNT/TQpTRk0AggggAACCCAQaYGPPvpIDzzwgMaPH98ibmDL dqWmpmrlypWhJmfPjlzcwP6eu3u39LWvuauysIpKiJlfEEAAgeQR2LlT+tznpPJyadWqyH3J WIB68eLkcWSkCCCAAAJREyC5J2q0VIwAAggg0JGA3ZVXUVHh3H1nST15eXlO0M6W56qrq9Mj j0T22onrp46OBM8jgAACySdgy2gVqCCiyT0DNVBHdCT5MBkxAggggAACCCAQRYHKykrdeOON ysrK0sCBA524Qf/+/XX48GE980zk4wZ//ddRHAxVI4AAAggER8CW4xo/PrJfNNnZ0q5dwTGg pwgggAACvhQguceXh4VOIYAAAokrcOzYMecuvClTprS4C2/48OG66aabdO5cg0aOjOy1kyX3 nHeedPJk4royMgQQQACB8ARslp2mGXci+e8SLQmvA5RCAAEEEEAAAQQQ6FSgpqZGjzzyiC6/ /HJnth5bnst+CgoKdO211+r06dP6zGciHzdIS3Nn7+m0c7yIAAIIIJD4AitWRP5LxgLUJSWJ b8cIEUAAAQSiKkByT1R5qRwBBBBAoEngxIkTWrx4sfr16+cE5WwpriuvvFLl5eXOXXdN5f7w h+hcO9n1k12XsSGAAAIIJLfAHM2JSnLPZ/SZ5IZl9AgggAACCCCAQC8Fzpw5o3vvvVf5+flO 3CAtLU2zZ8/Wo48+qv3794dq37dPSk2NTuzgX/811Ay/IIAAAggkq8CXvhSdL5lhw6TGxmRV ZdwIIIAAAhEQILknAohUgQACCCDQucCqVaucO+zsTruhQ4fqvvvu08GDB9vd6Qc/iM61kyX3 3HJLu03yJAIIIIBAkgjUqEYZyohKck+a0liaK0nOI4aJAAIIIIAAApEXsKW7R48e7ST12NLd 3/72t7V37952G3rssejFDRYsaLdJnkQAAQQQSCaBvLzofdG8/XYySTJWBBBAAIEIC5DcE2FQ qkMAAQQQaCmwZMkSZxrt7OxslZaW6tSpUy0LtHr01a9G79rpL/6iVWM8RAABBBBIKoFt2haV xJ6m5b3+qD8mlSeDRQABBBBAAAEEIiHw+OOPy2b3TU9P1z/8wz/IlvPubPvud6MXNxg/vrOW eQ0BBBBAIOEFTpyI3peM3X36wgsJT8gAEUAAAQSiJ0ByT/RsqRkBBBBIeoGVK1c6iT0jR47U H/8Y3h88r746etdPhYVJf0gAQAABBJJa4FW9GtXknhdEkC6pTzAGjwACCCCAAALdFli3bp0y MzM1aNAgvfrqq2HtH82bggYMCKsLFEIAAQQQSFSBd96JXnDaknuWLUtUOcaFAAIIIBADAZJ7 YoBMEwgggECyCtx///3Kz8/X292YbvS///foXT9NmZKsR4JxI4AAAgiYwHqtj2pyz2/1W6AR QAABBBBAAAEEuiHwf/7P/1Hfvn1lST7hbrffHr24QUFBuL2gHAIIIIBAQgrs2hW9LxlL7vn3 f09INgaFAAIIIBAbAZJ7YuNMKwgggAACYQrccUf0rp9sViA2BBBAAIHkFdipnVFN7rFlv9gQ QAABBBBAAAEEoivwgx9EL24wdWp0+07tCCCAAAI+F6itlVJTo/dF88orPgegewgggAACfhYg ucfPR4e+IYAAAkko8LOfRe/a6RvfSEJQhowAAgggEBKoU53O1/lRSfDJUY5O63SoLX5BAAEE EEAAAQQQiI7AypXRixt8+cvR6TO1IoAAAggESGDcuOh80VjSUFVVgCDoKgIIIICA3wRI7vHb EaE/CCCAQJIL7NsXvZsjKiqSHJfhI4AAAgjoBt0QleSea3QNuggggAACCCCAAAIxEKipkbKz o/N31+XLYzAAmkAAAQQQ8LfAnXdG50vmU5/y97jpHQIIIICA7wVI7vH9IaKDCCCAQPIJzJwZ +eunESOkc+eSz5IRI4AAAgi0FHhGz0QluedJPdmyIR4hgAACCCCAAAIIRE3guusiHzfo3186 eTJqXaZiBBBAAIGgCLzxRuS/ZFJSpH/5l6AI0E8EEEAAAZ8KkNzj0wNDtxBAAIFkFnjttchf P5WXJ7MoY0cAAQQQaBJoVKMu02URTfD5pD6pBjU0NcG/CCCAAAIIIIAAAlEW2L5dysiIbOxg yZIod5rqEUAAAQSCI/BXfxXZL5lhw6RTp4IzfnqKAAIIIOBLAZJ7fHlY6BQCCCCAQCTvwrvs MqmBv7lyUiGAAAII/FlgndYpU5kRSfBJV7pe1avYIoAAAggggAACCMRYoKQkcn93vfBC6fTp GA+A5hBAAAEE/CuwbZvUt2/kvmieesq/Y6VnCCCAAAKBESC5JzCHio4igAACySVQXS198pO9 v34aOlTaty+57BgtAggggEDXAg/r4Ygk9/yLmFa7a21KIIAAAggggAACkReoq5Pmzu193OD8 86UtWyLfP2pEAAEEEAi4wMqVUlpa779ovvGNgEPQfQQQQAABvwiQ3OOXI0E/EEAAAQRaCNTW Snv3SpMn9/z6adQo6a23JFllbAgggAACCLQSuE/3KU1pPUrySVWqvqfvtaqRhwgggAACCCCA AAKxErBL/SNHpDlzeh43GDxYWrdOqhVxg1gdN9pBAAEEAiNgXzQ//7nUp0/Pv2huvVV1Z86o sbExMMOmowgggAAC/hUguce/x4aeIYAAAkkrYMsPT58ulZZKNTVScbGUmtq9a6grr5QOHpS0 fLk0dqybKZS0ogwcAQQQQKAjgef0nD6mj3UrwWeQBmm5lndUJc8jgAACCCCAAAIIRFnAZu25 4grJluY6e1b62tek9PTuxQ1sCe9du6Tf6DcapVHaru1R7jXVI4AAAggERmD1amncOGnrVun1 16WRI7v3JdOvn/Too6qurtZVV12lu+66KzBDp6MIIIAAAv4VILnHv8eGniGAAAJJKXDunFRU 5F4r2U0RtryxbW+8IVnCTkZGx9dRNkvqjBnSyy//me7oUSk/391h6lTJ1vpiQwABBBBAoJVA tapVqlIVqKDTJJ8hGqJv69s6ruOtauAhAggggAACCCCAQCwFvvIV91Lf4gAVFW7Lb78tfeEL UlZWx3GDlBTJwgMrVkg2icJZndVojXb+DzhWY/WRPorlMGgLAQQQQMCPAn/4g9S3r/tlcu21 bg8tk/SBB6QRIzr/khkwQPr7v5c+cr9PHnzwQaWkpDg/jz76qB9HS58QQAABBAIkQHJPgA4W XUUAAQSSQeCOO9zrI5upp7y87Yhtyu0nnnBn9bnlFunmm6XvfEd67DHpww/blnfurGiK7F11 lVRf304hnkIAAQQQQEBqUIPWa71+rB/ra/qavqwvq0Ql+qF+qApV6JzOwYQAAggggAACCCAQ Z4G77/b+rmp/Z229nTzpJu9YuUWL3NmAbcKEf/s3aefO1qWlLdqiARrgJPhM0zTVqKZtIZ5B AAEEEEgOAfuiKChwv2gKC931H1uP/M03pQcflO68U/ryl91knvvuk9askWxquWabLcd10003 Ock96enpevbZZ5u9yq8IIIAAAgh0T4Dknu55URoBBBBAIIoC99/vBejuvTeCDT39tGS389kt epYRxIYAAggggAACCCCAAAIIIIAAAoETePJJb9nuW2+NXPdf1avKUpaT4HO1riapO3K01IQA AggER+D4cWniRDeGPHiw9N57Eel7bW2t5s2b5yT45OTkaMOGDRGpl0oQQAABBJJPgOSe5Dvm jBgBBBDwpUDU82+iljnkS046hQACCCCAAAIIIIAAAggggEBCCbz6qrfk1tVXS7asdyS3J/Wk UpXqJPjcqghmDkWyk9SFAAIIIBAdgdpaad48N7EnJ0eKcALO8ePHNXHiRCfBZ/DgwXovQolD 0cGgVgQQQAABvwqQ3OPXI0O/EEAAgSQSeP11L0AX1ZWzulrzK4nMGSoCCCCAAAIIIIAAAggg gAACQRHYskUaMMD9m+u0aVJNlFbOult3O8k9KUrRA2pnza+ggNFPBBBAAIHwBRobpZtucr9k 0tOlKC2dtXPnThUUFDgJPoWFhTpy5Ej4faQkAggggAACkkju4TRAAAEEEIirwNatUl6ee+00 dapUXR3F7thtfddc4zaWmemugxzF5qgaAQQQQAABBBBAAAEEEEAAAQR6J1BVJY0Y4V7Kjx4t HTjQu/q62vs23eYk+NgsPk/oia6K8zoCCCCAQNAFvvlN90smJUV66KGojqayslK5ublOgs+s WbN09uzZqLZH5QgggAACiSVAck9iHU9GgwACCARK4OBBadw499pp2DBp794YdP/UKWn6dLfR 88+XNm2KQaM0gQACCCCAAAIIIIAAAggggAAC3RU4eVKaPNm9hM/Pl7Zv724N3S9fpzpdoSuc BJ9sZatCFd2vhD0QQAABBIIhsGyZl9hz110x6fPq1auVkZHhJPhcf/31amhoiEm7NIIAAggg EHwBknuCfwwZAQIIIBBIgbjm2MQlqyiQh4lOI4AAAggggAACCCCAAAIIIBAXgbo66Yor3L+5 ZmdLFTHMsTmpk5qsyU6CT77ytV0xyCqKizKNIoAAAkkssHq1lJHhftFcf70UwySbZcuWOck9 KSkpuitGSUVJfKQZOgIIIJAwAiT3JMyhZCAIIIBAcAR8sTpWTNcDC86xoacIIIAAAggggAAC CCCAAAII+EHgttvcv7empkpPxGF1rCpVaYRGOAk+ozVaBxTl9cD8gE4fEEAAgWQRqKyUcnPd L5pZs6Q4LI/1zW9+M5Tg81CUlwNLlsPKOBFAAIFEFyC5J9GPMONDAAEEfChwxx1egK68PI4d fP11KSvL7cxVV0n19XHsDE0jgAACCCCAAAIIIIAAAggggIAJ3H23e6mekiI98ED8TLZoiwZo gJPgM03TVKOa+HWGlhFAAAEEIiOwc6dUUOB+0RQWSkeORKbebtbS2Niom266yUnwSU9P17PP PtvNGiiOAAIIIJBsAiT3JNsRZ7wIIIBAnAXuv98L0N17b5w7Y80//bSUluZ26pZbfNAhuoAA AggggAACCCCAAAIIIIBA8go8+aRks/VYYs+tt8bf4VW9qixlOQk+V+tqndO5+HeKHiCAAAII 9Ezg+HFp4kT3S2bwYOm993pWT4T2qq2t1bx585wEn5ycHG3YsCFCNVMNAggggEAiCpDck4hH lTEhgAACPhXwbR6N7zKOfHoA6RYCCCCAAAIIIIAAAggggAACURR49VVvgt2rr5ZsWW8/bE/q SaUq1UnwuVU+yDjyAwp9QAABBIImUFsrzZvnJvbk5Eg+SaQ5fvy4Jk6c6CT4DB48WO/FOeEo aIeV/iKAAALJJEByTzIdbcaKAAIIxFHA9ytg+WatsDgeJJpGAAEEEEAAAQQQQAABBBBAIE4C W7ZIAwa4f3OdNk2q8dkKWHfrbie5J0UpekBxXCssTseHZhFAAIFACzQ2Sjfd5H7JpKdLPlsC a+fOnSooKHASfAoLC3UkTkuFBfoY03kEEEAgCQRI7kmCg8wQEUAAgXgLbN0q5eW5105Tp0rV 1fHuUTvt2+2A11zjdjIzU1qzpp1CPIUAAggggAACCCCAAAIIIIAAApEWqKqSRoxwL8lHj5YO HIh0C5Gp7zbd5iT42Cw+T+iJyFRKLQgggAAC0Rf45jfdLxlb8/Ghh6LfXg9aqKysVG5urpPg M2vWLJ09e7YHtbALAggggEAiC5Dck8hHl7EhgAACPhA4eFAaN869dho2TNq71wed6qgLp05J 06e7nT3/fGnTpo5K8jwCCCCAAAIIIIAAAggggAACCERA4ORJafJk91I8P1/avj0ClUapijrV 6Qpd4STCnWHmAAAgAElEQVT4ZCtbFaqIUktUiwACCCAQMYFly7zEnrvuili10aho9erVysjI cBJ8rr/+ejU0NESjGepEAAEEEAioAMk9AT1wdBsBBBAIgkAgc2UClY0UhLOAPiKAAAIIIIAA AggggAACCCDQvkBdnXTFFe7fXLOzpYoA5Mqc1ElN1mQnwSdf+douH2cjtc/OswgggEDyCKxe LWVkuF80118vBSBZZtmyZU5yT0pKiu7yeTJS8pxIjBQBBBDwhwDJPf44DvQCAQQQSDiBQK9y FYh1xBLulGFACCCAAAIIIIAAAggggAACSSZw223u31tTU6UnArTKVZWqNEIjnASf0RqtA/Lp OmJJdj4xXAQQQKCFQGWllJvrftHMmiUFaJmrb37zm6EEn4d8uoxYC2seIIAAAgjERIDknpgw 0wgCCCCQfAJ33OEF6MrLAzj+11+XsrLcQVx1lVRfH8BB0GUEEEAAAQQQQAABBBBAAAEE/Clw 993uJXdKivTAA/7sY2e92qItGqABToLPNE1TjWo6K85rCCCAAAKxFNi5UyoocL9oCgulI0di 2Xqv22psbNRNN93kJPikp6fr2Wef7XWdVIAAAgggEHwBknuCfwwZAQIIIOA7gfvv9wJ0997r u+6F36Gnn5bS0tzB3HJL+PtREgEEEEAAAQQQQAABBBBAAAEEOhR48knJZuuxxJ5bb+2wmO9f eFWvKktZToLP1bpa53TO932mgwgggEDCCxw/Lk2c6H7JDB4svfdeIIdcW1urefPmOQk+OTk5 2rBhQyDHQacRQAABBCInQHJP5CypCQEEEEBAUsLlwyRMphKnJwIIIIAAAggggAACCCCAAALx F3j1VW+i3KuvlmxZ7yBvT+pJpSrVSfC5VQHOVAryQaDvCCCAQJNAba00b56b2JOTIwU8Ieb4 8eOaOHGik+AzePBgvRfQRKWmw8O/CCCAAAK9EyC5p3d+7I0AAggg0EwgYVeyCvwaY80OEr8i gAACCCCAAAIIIIAAAgggECeBt9+WBgxw/+Y6bZpUkyArWd2tu53knhSl6AEFcI2xOJ0PNIsA AghEVKCxUbrpJvdLJj1dSpClrHbu3KmCggInwaewsFBHjx6NKBuVIYAAAggER4DknuAcK3qK AAII+Fpg61YpL8+9dpo6Vaqu9nV3u9c5u43wmmvcwWVmSmvWdG9/SiOAAAIIIIAAAggggAAC CCCQ5AJVVdKIEe6l9ejR0oEDiQVym25zEnxsFp8n9ERiDY7RIIAAAkEQ+OY33S8ZW/PxoYeC 0OOw+1hZWanc3FwnwWf27Nk6e/Zs2PtSEAEEEEAgcQRI7kmcY8lIEEAAgbgJHDwojRvnXjsN Gybt3Ru3rkSv4VOnpOnT3UGef760aVP02qJmBBBAAAEEEEAAAQQQQAABBBJI4ORJafJk95I6 P1/avj2BBvfnodSpTlfoCifBJ1vZqlBF4g2SESGAAAJ+FVi2zEvsuesuv/ayV/1avXq1MjIy nASfG264QQ0NDb2qj50RQAABBIInQHJP8I4ZPUYAAQR8JZBUOS9JkcXkq9OLziCAAAIIIIAA AggggAACCARcoK5OuuIK92+u2dlSRQLnvJzUSU3WZCfBJ1/52q4EzGIK+PlI9xFAIAEFVq+W MjLcL5rrr5cSOOll2bJlTnJPSkqKvvWtbyXgwWRICCCAAAKdCZDc05kOryGAAAIIdCqQlKtV JfT6Y50ebl5EAAEEEEAAAQQQQAABBBBAoNsCf/d37t9bU1OlJ5JgtaoqVWmERjgJPqP/P3v3 AlZXeed7HNhEEEnEIB1yElFsUoODj5yYsXijKXWKKbaJvWFHrJc45lDjpVZpc04vYk8utbF2 LFbLdGqjKSaOOrQ9tDMmlZp02rTF2sSSpEZFRWpMNSIhMZDA7zzvWt0bSLhsNmvvvS7f7ZMC e631rv/7eTddrLV/e70q1B75bP6xCb8C2AABBBCIo0Brq5SdbR9oLrpICsB0VbW1tZGAT319 fRxxaRoBBBBAwG0ChHvcNiLUgwACCHhIYNmywQt0a9d6qPDJlrp5s5SRYXd+4ULp8OHJtsj2 CCCAAAIIIIAAAggggAACCPhOoK7OPnVOSZHWrPFd90bt0J/0J+Uoxwr4zNd89ahn1HVZgAAC CCAQo0B7u5Sfbx9oioqkt96KsSFvbTYwMKDq6mor4BMKhdTU1OStDlAtAggggEDMAoR7YqZj QwQQQCDYAqtWDV6gW7EigBYbNkhpaTbCkiUBBKDLCCCAAAIIIIAAAggggAACCIwu0Ngombv1 mGDP0qWjr+fXJS1qUYYyrIBPpSp1REf82lX6hQACCCReoKtLKi62DzJ5edLu3YmvIYl77O3t VXl5uRXwycrK0tatW5NYDbtGAAEEEEiUAOGeREmzHwQQQMBHAuRa/jaYgU84+ehFTVcQQAAB BBBAAAEEEEAAAQQcE2hpGbzhbWWlZKb1DuKjUY1KVaoV8FmqACacgjjo9BkBBOIv0NsrlZfb wZ6sLOk3v4n/Pl24h66uLhUXF1sBn7y8PO0OWMDJhUNCSQgggEDcBQj3xJ2YHSCAAAL+EmBG qqPGM7Bzkx3lwI8IIIAAAggggAACCCCAAAIISGprk3Jy7Pdc58+XegI+I9UdusMK96QoRWsU oLnJ+G1AAAEE4iEwMCBVV9sHmVBICviUVO3t7crPz7cCPkVFRdq3b1881GkTAQQQQMAlAoR7 XDIQlIEAAgh4QWDHDmn6dPvcad48af9+L1Qd5xrNxw8XLbJRpkyRNm6M8w5pHgEEEEAAAQQQ QAABBBBAAAF3CnR2SgUF9ilyYaG0Z48760x0Vf9L/8sK+Ji7+KzTukTvnv0hgAAC/hGorbUP MmbOx+98xz/9mkRPWltblZ2dbQV8ysrKdOjQoUm0xqYIIIAAAm4WINzj5tGhNgQQQMBFAnv3 SrNn2+dOM2dKHR0uKi7ZpRw4IJWW2jjTpknbtiW7IvaPAAIIIIAAAggggAACCCCAQEIFurul khL71Dg3V9q1K6G7d/XO+tSnClVYAZ9MZWqLtri6XopDAAEEXCnQ0DAY7PnSl1xZYrKKam5u Vnp6uhXwqaqqUn9/f7JKYb8IIIAAAnEUINwTR1yaRgABBPwiQHYlipEk/RQFEqsggAACCCCA AAIIIIAAAgj4UaCvT6qosN9zzcyUtpBdOWaYu9WtEpVYAZ9c5WqXSD8dg8QTCCCAwGgCzc1S erp9oPn0pyXCK8dINTQ0WOGelJQULV++/JjlPIEAAggg4H0Bwj3eH0N6gAACCMRVgFmnJsDL vGUTwGJVBBBAAAEEEEAAAQQQQAABvwjU1Njvt6amSuuYdWrUYe1UpwpUYAV8ClWoPWLeslGx WIAAAgiEBVpbpexs+0Bz0UUS006FZY75WltbGwn41NfXH7OcJxBAAAEEvC1AuMfb40f1CCCA QNwFli0bvEC3dm3cd+f9HWzeLGVk2GgLF0qHD3u/T/QAAQQQQAABBBBAAAEEEEAAgVEE6urs U+CUFGnNmlFW4umIwJ/0J+Uoxwr4zNd89agnsoxvEEAAAQSOEmhvl/Lz7QNNUZH01ltHrcCP QwUGBgZUXV1tBXxCoZCampqGLuZ7BBBAAAGPCxDu8fgAUj4CCCAQT4FVqwYv0K1YEc89+azt DRuktDQbb8kSn3WO7iCAAAIIIIAAAggggAACCCBgCzQ2SuZuPSbYs3QpKtEKtKhFGcqwAj6V qtQRHYl2U9ZDAAEEgiPQ1SUVF9sHmbw8affu4PR9Ej3t7e1VeXm5FfDJysrS1q1bJ9EamyKA AAIIuEmAcI+bRoNaEEAAARcJDM2nXHediwrzSimrV5OM8spYUScCCExK4KAO6iW9pN/r93pF r+iwxr5jmXnj4jW9Nql9sjECCCCAAAIIIIBA8gVaWgZvXFtZKZlpvXlEL9CoRqUq1Qr4LBXJ qOjlWBMBBAIh0NsrlZfb11ezsqTf/CYQ3Xaqk11dXSouLrYCPnl5edpNMMopWtpBAAEEkipA uCep/OwcAQQQcKcAM0s5NC7MaeYQJM0ggICbBPZrvx7Vo7pKVylf+dabESlD/jekkM7ROfqW vqU39MYxpd+sm63lxyyQtEZrdJNu0hW6Qgu1UOfqXJ2n80Za1ZfPfVff1S26RVfqSn1EH1Gp SjVXc33ZVzqFAAIIIIAAAt4WaGuTcnLs91znz5d6mFkqpgGtU13kL2nztzAPBBBAAAFJAwNS dbV9kAmFJKaWiull0d7ervz8fCvgU1RUpH379sXUDhshgAACCLhHgHCPe8aCShBAAAFXCOzY IU2fbp87zZsn7d/virK8WYT52OLixTbmlCnSxo3e7AdVI4AAApJ61KPVWq1c5VpvQJhPGX9A H9DX9XX9TD/TM3/778f6sW7TbZqlWZqqqbpH90SmGdiojdank4tVPKLpbM1WmtIib3CY0JAJ EAXlYcI8Jhw1NCyVrvRxu9+vfj2oB/VlfVnP6blx12cFBBBAAAEEEEBgMgKdnVJBgX2qW1go 7dkzmdbYtkY1kb+v12kdIAgggAACtbX2QcbM+Vhfj8ckBFpbW5WdnW0FfMrKynTo0KFJtMam CCCAAALJFiDck+wRYP8IIICAiwT27pVmz7bPnWbNkjo6XFScV0s5eFAqLbVRp02Ttm3zak+o GwEEAizQohbN0IxI6MTcted5PT+mSJ/69D19zwr4XKyL1a52zdRMq43Rwj2mQbPd3bo7sq8g hXtM/820ZSaoEw74RBPuMXdDCq9/vI7XC3phzLFhIQIIIIAAAgggEKtAd7dUUmKf4ubmSrt2 xdoS24UFzN+/Faqw/p7LVKa2aEt4EV8RQACB4Ak0NAwGe5YvD17/49Dj5uZmpaenWwGfqqoq 9ff3x2EvNIkAAgggkAgBwj2JUGYfCCCAgAcEDhwYnkHZvt0DRXulxKGpqZkzSU15ZdyoEwEE LIG7dFfkbjIn62Rt0qYJybyoF3WaTlOGMiIBlLHCPaZxM/VXOKwStHBPGDfsFU24x9wlKexl vt6re8PN8BUBBBBAAAEEEHBMoK9Pqqiw33PNzJS2kEFxzLZb3SpRifU3nblT5i6RmnIMl4YQ QMA7As3NUnq6faCpqpIIoTg2dg0NDVa4JyUlRcsJTTnmSkMIIIBAogUI9yRanP0hgAACLhQw s0ctWmSfN5nZozZN7H1bF/bIhSXt3Ml8Zy4cFkpCAIGxBVZqZSQ0YoI92xTb3cde0ksy24cD KOOFe0xV4XWDGu4JT38WTbjnEl0S8TJuEw1gjf0qYCkCCCCAAAIIIGAL1NTY1w1SU6V1zB7l +MuiU50qUIH1d12hCrVHzHfmODINIoCAewVaW6XsbPtAU1YmMX2U42NVW1sbCfjUM92Z4740 iAACCCRCgHBPIpTZBwIIIOBygWXLBi/QPfSQy4v1cnmbN0vm441mvuiFC6XDh73cG2pHAAGf C6zTOqUq1XpzwXzdrM2T6vF6rY8EUAj3jE8ZDkNFE+7pUIcu02U6W2dbU5qN3zprIIAAAggg gAACExOoq7NPZc3p7Jo1E9uWtaMXaFObcpRj/d08X/PVo57oN2ZNBBBAwKsC7e1Sfr59oCkq kvbt82pPXF33wMCAqqurrYBPKBRSU1OTq+ulOAQQQACBYwUI9xxrwjMIIIBAoARWrRq8QLdy ZaC6npzObtggpaXZ6EuWJKcG9ooAAgiMI/CaXtMJOiESxrlG14yzRXSLz9f5VpuEe8b3mki4 Z/zWWAMBBBBAAAEEEIhdoLFRMnfrMcGepUtjb4ctoxNoUUtkSttKVeqIjkS3IWshgAACXhTo 6pKKi+2DTF6etHu3F3vhmZp7e3tVXl5uBXyysrK0detWz9ROoQgggAAC5m73PBBAAAEEAisw NGdy3XWBZUh8x1evHkxUrViR+P2zRwQQQGAcgSt0RSTYY+4c84beGGeL6BY/okcI90RHFZnG LJo790TZJKshgAACCCCAAAITFmhpkTIy7FPYykrJTOvNI/4CjWqM3EVzqUhUxV+cPSCAQFIE enul8nL7IJOVJRE0ScgwdHV1qbi42Ar45OXlaTeBqoS4sxMEEEDACQHCPU4o0gYCCCDgQQEz Q1T4Ah0zRCVhAIfOhbZ2bRIKYJcIIIDAyAJmKoCUIf9drItHXjGGZ9/VuzpOx4k794yPx517 xjdiDQQQQAABBBCIr0Bbm5STY7/nOn++1MMMUfEFP6r1OtVF/ipfI+ZCO4qHHxFAwOsCAwNS dbV9kAmFJKaISuiItre3Kz8/3wr4FBUVaR9ToSXUn50hgAACsQoQ7olVju0QQAABDwvs2CFN n26fO82bJ+3f7+HOeLV083HHxYvtQZgyRdq40as9oW4EEPCZwFf11cibCCbkc5/uc7SHF+gC R8I9h3VYPZrcO0wDGrDuSvSsntXTelpmOjKnHn3qkwkzHf3Yr/0y+x3vEWu4p1vd4zU94vIu dWmbtukpPWV9fVtvj7geTyKAAAIIIIBAMAQ6O6WCAvuUtbBQ2rMnGP12Wy9rVGP9bZ6qVK3T OreVRz0IIIBA7AK1tfZBxsz5WF8feztsGbNAa2ursrOzrYBPWVmZDh06FHNbbIgAAgggkBgB wj2JcWYvCCCAgGsE9u6VZs+2z51mzZI6OlxTWvAKOXhQKi21B2PaNGnbtuAZ0GMEEHCdQJGK hoV7zJ18nHzcr/t1g24Yt8nw3YPylR9Z91W9qmVapjN0hqZoilWnWX6RLtLjejyy3njf7NEe LddyzdIsZSrTam+u5lptZitbJoBk3jzpV/94TVnLTTDmUl2qUpVqtmYrRzlWbd/Wt63lB3RA K7RCMzXTev4EnWD1wwSARntEE+65U3dqgRboLJ2lGZph1T+RabxMyGi91ltthBSS6bsZf/M1 TWkqU5ke02OjlcjzCCCAAAIIIOBTge5uqaTEPlXNzZV27fJpRz3QLfP3YoUqrL8hzd+tW7TF A1VTIgIIIDCOQEPDYLBn+fJxVmZxPAWam5uVnp5uBXyqqqrU3x/ddZB41kTbCCCAAAKjCxDu Gd2GJQgggIDvBA4cGJ4l2b7dd130XoeGpq1mziRt5b0RpGIEfCVg7oQTDtWEv+7TvqT0Mbz/ cLjnh/qhspSlG3WjdZcdU9ef9WcNna7gcl0+bq0v6AUVqtAKxGzURvWqN7KN+d7cqWi6plsO Jtzyul6PLB/tG1PLhbpQczRnmJ8J95g76Ziw0Af1QbWoRV/T1yLr3KE7RmtS0YR7btftOkfn yAR6wl7RhnvMXYrO03nWdiYsZUI8Q+8o9KSelAk8mXY/pU9prCDSqJ1gAQIIIIAAAgh4TqCv T6qosN9zzcyUtpAlSfoYmr8nS1Ri/V2Wq1ztEmmrpA8KBSCAQOwCzc1Serp9oKmqkgiTxG7p 0JYNDQ1WuCclJUXLCVs5pEozCCCAQHwECPfEx5VWEUAAAdcJmFmgFi2yz5vMLFCbNrmuxOAW tHMn86QFd/TpOQKuEjBhmXBIxHw9Tsclrb5wHSbc86AeVIEK9JyeG7GepVoaqfsJPTHiOuEn r9bV1rrmzj+Nagw/Pezrf+u/Ze5kY2ooVrHe0TvDlo/1wzf0jUgtJtzzaX3a+rR1OET0MX0s svwj+sioTUUT7glv/Ef9MdJmNOGel/SSdacf0z8T8BltejNzh6NTdIrVtnHjgQACCCCAAAL+ F6ipsa8bpKZK65gFyjUD3qlO6+9h8/ebCaqbv9N4IIAAAp4TaG2VsrPtA01ZmcQ0UK4Zwtra 2kjAp55p0lwzLhSCAAIIHC1AuOdoEX5GAAEEfCqwbNngBbqHHvJpJ73crc2bJfOxSDPP9MKF 0uHDXu4NtSOAgEcFfqlfRkIi5o0DM21Vsh5m/+a/43W8TtSJMoGb0R7mDjzh9T+qj462mvX8 +/S+yLqX6JJR1x0aGDJTakX7+I1+E2nf3EnIvPlipuUKPzZog8y0XNM0TY/okfDTx3ydSLjH bGzaNAbjhXve1btWYMmsm6EMmTsZjfVYq7WR/jytp8dalWUIIIAAAggg4HGBujr7lNSclq5Z 4/HO+LB8M11uePrX+Zo/akDbh12nSwgg4AeB9nYpP98+0BQVSfuSc5dgP1DGow8DAwOqrq62 Aj6hUEhNTU3x2A1tIoAAAghMUoBwzyQB2RwBBBDwgsCqVYMX6Fau9ELFAa1xwwYpLc0erCVL AopAtxFAIJkCrWqNBDlM+MPc9j9Zj3BYx3y9WTePWcbQOw6ZqaTGenxOn4v0cbVWj7rqw3o4 st5CLRx1vaMXDL2LTqpStVLHHnjNnXIO6uDRmw77eaLhnmjXv0t3RfoVzTRm5q5F4Wm/qlQ1 rEZ+QAABBBBAAAH/CDQ2SuZuPSbYs3Spf/rlt56YaV5NQNv8jVypSh3REb91kf4ggIAfBbq6 pOJi+yCTlyft3u3HXnq+T729vSovL7cCPllZWdq6davn+0QHEEAAAb8JEO7x24jSHwQQQOAo gaF5keuuO2ohP7pPYPXqwSTWiujvFOG+jlARAgh4UeB1vR4Jfpg3DEw45bCScyexoeGezdo8 JmeHOiJ1T9XUMdc1C3+n38ncpWisxx/0h0ib5+icsVYdtuzocI8xjeURbVgn3HY06/erX2aa s7DtWHcOCrdrvp6v861tTtfpQ5/mewQQQAABBBDwiUBLi5SRYZ+KVlZKZlpvHu4VMFPLmr/T zd905m6TPBBAAAFXC/T2SuXl9kEmK0siMOLq4erq6lJxcbEV8MnLy9NugliuHi+KQwCB4AkQ 7gnemNNjBBAIkICZ6Sl8gY6Znjw08EPnUFu71kOFUyoCCHhdwIQ/zDRY4fCH+foX/SUp3Rpa w2t6bcwazPLw+tnKHnPdsRaau9S8qBet8M8DeiDS5qk6dazNhi0bGu75O/3dsGUT+SGasM7Q 9qJZf+iUYcZru7YPbWLU76/W1ZZFmtJ0SIdGXY8FCCCAAAIIIOA9gbY2KSfHfs91/nypp8d7 fQhixXWqi/ytukbMoRbE1wB9RsATAgMDUnW1fZAJhSSmevLEsLW3tys/P98K+BQVFWkfU6h5 YtwoEgEEgiFAuCcY40wvEUAggAI7dkjTp9vnTvPmSfv3BxDBq102H5NcvNgevClTpI0bvdoT 6kYAAQ8KXKbLIm8UmADIL/QLR3vRpCZ9Xp8ft81wWMd87VLXmOvHGu55Ra+oXvW6VJdqpmZa /T5JJ6lYxTpX50YcZmnWmPsfunBouGe+5g9dNKHvownrDG0wmvV/oB9E+mRcZ2u2zDRm4/2X o5zIdrHeiWhorXyPAAIIIIAAAu4Q6OyUCgrsU8/CQmnPHnfURRXRCdSoxvobzdzFZ53WRbcR ayGAAAKJFKittQ8yZs7H+vpE7pl9TVKgtbVV2dnZVsCnrKxMhw7xQZ9JkrI5Aggg4IgA4R5H GGkEAQQQcJfA3r3S7Nn2udOsWVJHh7vqo5ooBA4elEpL7UGcNk3ati2KjVgFAQQQmLyAuc3/ 0GDNLbpl8o0OaWGJlugiXTTkmZG/HVqD0+Gendqpz+gzMneiMfspU5n+Tf+mF/RCpJg/6U8R h1jDPRWqiLQ30W+iCesMbTOa9e/SXZE+mX6bO/mYfkb7n5n+jAcCCCCAAAII+EOgu1sqKbFP OXNzpV27/NGvIPWiT30yf2+av+sylakt2hKk7tNXBBBwu0BDw2CwZ/lyt1dLfSMINDc3Kz09 3Qr4VFVVqb+/f4S1eAoBBBBAIJEChHsSqc2+EEAAgQQIHDgwPBOyPboZNxJQGbuYsMDQlNbM maS0JgzIBgggEItAj3qUr/xICOQ0nRZLM6Nuc77OV7WqR10eXhCvcI+5e01IIat/BSoY9c5E ToR7LtEl4e5M+Gs0YZ2hjUaz/tF37mlX+9Am+B4BBBBAAAEEAiLQ1ydVVNjvuWZmSlvIhHh2 5LvVrRKVWH/b5ipXu0RKy7ODSeEI+EmguVlKT7cPNFVVEqEQz45uQ0ODFe5JSUnRckJanh1H CkcAAf8IEO7xz1jSEwQQQEBmNqdFi+zzJjOb06ZNoHheYOdO5lfz/CDSAQS8J/CgHoyEe0zI 5nE97kgnzJRO6UrXj/SjcduLR7hngzZE+jVDM/SqXh21Dj+Ge8ydeoa6/l6/H7X/LEAAAQQQ QAAB/wrU1NjXDVJTpXXM5uT5ge5Up0xo3fydV6hC7RHzq3l+UOkAAl4WaG2VsrPtA01ZmcR0 Tl4eTav22traSMCnnunVPD+edAABBLwtQLjH2+NH9QgggMAwgWXLBi/QPfTQsEX84GWBzZsl 83FKMz/1woXS4cNe7g21I4CABwQGNKALdEEkCGLu3vOu3p105XfqTp2kk7Rf+8dta2gIxYlp uY7oiE7VqZE+fU/fG7OGP+qPkXWHTsv1vJ7X1bp61D4M3c5td+4x4zpTMyP9ekAPjGlw9MK/ 6C9HP8XPCCCAAAIIIOAxgbo6+9TSnF6uWeOx4il3VIE2tSlHOdbfefM1X+ZunDwQQACBhAu0 t0v5+faBpqhI2rcv4SWwQ+cFBgYGVF1dbQV8QqGQmpqanN8JLSKAAAIIRCVAuCcqJlZCAAEE 3C+watXgBbqVK91fLxVOUGDDBiktzR7kJUsmuDGrI4AAAhMXMJ/4PV2nR4IgS7REJhwS6+PP +rOylKXv6DtRNeF0uMdMUTC0zRf14ph1/Ew/i6w/NNzzK/3Kev5NvTni9m4O95iCv61vR/q1 QAtG7MNIT/5cP7e2e0tvjbSY5xBAAAEEEEDAAwKNjZK5W48J9ixd6oGCKXFCAi1qUYYyrL/Z KlUpE27ngQACCCRMoKtLKi62DzJ5edLu3QnbNTuKv0Bvb6/Ky8utgE9WVpa2bt0a/52yBwQQ QACBYwQI9xxDwhMIIICA9wSG5j6uu8579VNxlAKrVw8muFasiHIjVkMAAQRiFzB3qclXfiQM csvp/NkAACAASURBVKNujCngY+74cqbO1If14ajfZBgaxHlbb4/ZiQ51RGo8QSeMuO7Q0I1p 20xfMNbjc/pcpM3/of8RWXWzNlvPj3Y3oWf1bGS7ClVEtpvoN7nKtdoJKRTVpuH1zbRnYz0O 67DMp7nDvk0a/xN35q5NszVbC7VwrKZZhgACCCCAAAIuFmhpkTIy7FPKykpZ03q7uFxKi1Gg UY1KVar1t95SkeCKkZHNEEBgogK9vVJ5uX2QycqSCH5MVNAT63d1dam4uNgK+OTl5Wk3AS5P jBtFIoCAvwQI9/hrPOkNAggEUMDM2BS+QMeMTQF4AQyde23t2gB0mC4igECyBUww50JdGAmD mLu9jHfXm6E1b9EWFapQ5+pcdat76KJRvzdhnnD4xHx9WS+Puq5Z8Jyei6yfpjT1qe+Y9Q/p kExIJ9zuN/XNY9YJP/Fj/VgzNMMKI5n1TWAmPJXYg3pQ0zU9vOoxX80npsP7OE/nHbM8mif6 1a/jdFyknfGmVTh6/YM6OOZuzF2Z3qv3Wu2fqBO1VaN/4s4Ee67UlcpTnpiWa0xWFiKAAAII IOBagbY2KSfHfs91/nyphxmbXDtWThRWp7rI35FrxNxrTpjSBgIIjCEwMCBVV9sHmVBIYsqm MbC8v6i9vV35+flWwKeoqEj7mHrN+4NKDxBAwFMChHs8NVwUiwACCAwX2LFDmj7dPneaN0/a v3/4cn7yocCRI9LixfagT5kibdzow07SJQQQcJuAuduLeZNgmqZZbxRkKlPX6Br9Wr8e8U48 JlzzS/1SVaqyPjls1jUhkfEe67RO9+pe6w4x4YCM+Vqucv2L/kX/pn+LNGGmCGtQg+7RPcPC R2b9xVpsTf+1Xusj65tvzF133qP3WH0wgR2zr6FBoHf0jr6hb1h3KzL1/0Q/ibwxcpkukwn2 nKbTdIfuGNauCdOYWu7W3ZqneZFtTC1X6Sp9S9/S9/Q9vaAXhm139A//rn9Xver1SX1yWBuX 6lKrPz/Sj4ZtMtr6ptb7dJ81BsM2GPKDmV7rI/qItZ8pmqIv6Asyd2oKPw7ogDZog87SWTpZ J1tjHV7GVwQQQAABBBDwjkBnp1RQYJ9CFhZKe/Z4p3YqjV2gRjXW33nmLj7mb2weCCCAQNwE amvtg4yZ87G+Pm67oWH3CLS2tio7O9sK+JSVlenQoUPuKY5KEEAAAZ8LEO7x+QDTPQQQ8K/A 3r3S7Nn2udOsWVJHh3/7Ss+OEjh4UCottQd/2jRp27ajVuBHBBBAID4CJhDyf/R/dIpOiYRP pmqqylSmT+lTWqRFmqu51p1uTLDlA/qAFaiJthrT7kk6ybprjgnRvE/vs+76Y+64Y+6WY8JF 4ccRHbHubmOeN8vN3YHM+mY787Npp0hF4dUjX1/Ta7pW11qBFVOj2f4iXaRzdI6ylS0TjNmh HZH1v6KvyEyNZdY1IRcT4Dn6Ye6EY+60M7SWOZqjAhVYYSJTt1k+3hsrJSpRjnIi/Q+3Ye6a Y2o7VacO2/Vo65s6s5RlBbCGbTDCDz/Tz/RBfTAyZuZOPjM10/rZ7PN6Xa/X9foIW/IUAggg gAACCLhdoLtbKimxTx1zc6Vdu9xeMfU5JWAC7GaKWPM3rAnmm7tp8kAAAQQcF2hoGAz2LF/u ePM06F6B5uZmpaenWwGfqqoq9ff3u7dYKkMAAQR8JEC4x0eDSVcQQCA4AgcODM92bN8enL7T 078JDE13zZxJuosXBgIIJFxgm7bpLt0l86lgE4gxAZmP6WNWGOR+3a9X9ErCa5rIDk046Bk9 o5/qp3pYD8tMpzVaiMVMi7VTO0e8S9FE9unmdc1UaMbgET1i3bHnV/qVzFRmPBBAAAEEEEDA mwJ9fVJFhf2ea2amtIVshzcHchJVmylxTRjcBHxylatdIt01CU42RQCBowWam6X0dPtAU1Ul Ee44Wsj3Pzc0NFjhnpSUFC0n3OX78aaDCCDgDgHCPe4YB6pAAAEEohYwszItWmSfN5lZmTZt inpTVvSbwM6dzMvmtzGlPwgggAACCCCAAAIIIICAAwI1NfZ1g9RUaR2zMjkg6s0mOtVp3U3S BHzMnS7NHSd5IIAAApMWaG2VsrPtA01ZmcS0TJMm9WoDtbW1kYBPPdOyeXUYqRsBBDwkQLjH Q4NFqQgggIARWLZs8ALdQw9hEniBzZsl8zFMM6/1woXS4cOBJwEAAQQQQAABBBBAAAEEEAiy QF2dfYpoThPXrAmyBH03Am1qs6Z+NQGf+Zovc1dKHggggEDMAu3tUn6+faApKpL27Yu5KTb0 vsDAwICqq6utgE8oFFJTU5P3O0UPEEAAARcLEO5x8eBQGgIIIHC0wKpVgxfoVq48eik/B1Zg wwYpLc1+cSxZElgGOo4AAggggAACCCCAAAIIBF2gsVEyd+sxwZ6lS4OuQf/DAmb61QxlWFN0 VarS19PNhvvMVwQQiINAV5dUXGwfZPLypN2747ATmvSaQG9vr8rLy62AT1ZWlrZu3eq1LlAv Aggg4BkBwj2eGSoKRQCBoAsMzW9cd13QNej/MQKrVw8mv1asOGYxTyCAAAIIIIAAAggggAAC CPhboKVFysiwTw0rKyUzrTcPBMICjWpUqlKtgM9SkfwKu/AVAQSiFOjtlcrL7YNMVpZEgCNK uGCs1tXVpeLiYivgk5eXp90Ev4Ix8PQSAQQSLkC4J+Hk7BABBBCYuICZeSl8gY6ZlybuF5gt hs7ZtnZtYLpNRxFAAAEEEEAAAQQQQACBoAu0tUk5OfZ7rvPnSz3MvBT0l8SI/a9TnRXuMVN0 rRFzto2IxJMIIHCswMCAVF1tH2RCIYmpl4414hm1t7crPz/fCvgUFRVpH1O28apAAAEEHBcg 3OM4KQ0igAACzgrs2CFNn26fO82bJ+3f72z7tOYjAfOxzMWL7RfLlCnSxo0+6hxdQQABBBBA AAEEEEAAAQQQGEmgs1MqKLBPBQsLpT17RlqL5xCwBWpUYwV8zF181mkdLAgggMD4ArW19kHG zPlYXz/++qwRWIHW1lZlZ2dbAZ+ysjIdOnQosBZ0HAEEEIiHAOGeeKjSJgIIIOCQwN690uzZ 9rnTrFlSR4dDDdOMfwUOHpRKS+0XzbRp0rZt/u0rPUMAAQQQQAABBBBAAAEEAi7Q3S2VlNin gLm50q5dAQeh++MK9KlPFaqwAj6ZytQWbRl3G1ZAAIEACzQ0DAZ7li8PMARdj1agublZ6enp VsCnqqpK/f390W7KeggggAAC4wgQ7hkHiMUIIIBAsgQOHBie0di+PVmVsF/PCQxNhc2cSSrM cwNIwQgggAACCCCAAAIIIIDA+AJ9fVJFhf2ea2amtIWMxvhorGEJdKtbJSqxAj65ytUukQrj pYEAAiMINDdL6en2gaaqSiKkMQIST40k0NDQYIV7UlJStJxQ2EhEPIcAAgjEJEC4JyY2NkIA AQTiK2BmV1q0yD5vMrMrbdoU3/3Rug8Fdu5kPjcfDitdQgABBBBAAAEEEEAAAQTCAjU19nWD 1FRpHbMrhVn4GqVApzpVoAIr4FOoQu0R87lFScdqCARDoLVVys62DzRlZRLTKwVj3B3sZW1t bSTgU890bg7K0hQCCARZgHBPkEefviOAgGsFli0bvED30EOuLZPC3C6webNkPr5p5sNeuFA6 fNjtFVMfAggggAACCCCAAAIIIIBAFAJ1dfapnjndW7Mmig1YBYERBNrUphzlWAGf+ZqvHvWM sBZPIYBA4ATa26X8fPtAU1Qk7dsXOAI6PHmBgYEBVVdXWwGfUCikpqamyTdKCwgggEDABQj3 BPwFQPcRQMB9AqtWDV6gW7nSffVRkccENmyQ0tLsF9WSJR4rnnIRQAABBBBAAAEEEEAAAQSO FmhslMzdekywZ+nSo5fyMwITE2hRizKUYQV8KlWpIzoysQZYGwEE/CXQ1SUVF9sHmbw8afdu f/WP3iRUoLe3V+Xl5VbAJysrS1u3bk3o/tkZAggg4DcBwj1+G1H6gwACnhYYmsO47jpPd4Xi 3SSwevVgYmzFCjdVRi0IIIAAAggggAACCCCAAAITEGhpkTIy7FO8ykrJTOvNA4HJCjSqUalK tQI+S0VibLKebI+AZwV6e6Xycvsgk5UlEcTw7FC6qfCuri4VFxdbAZ+8vDztJjDmpuGhFgQQ 8JgA4R6PDRjlIoCAfwXMDErhC3TMoOTfcU5az4bO9bZ2bdLKYMcIIIAAAggggAACCCCAAAKx CbS1STk59nuu8+dLPcygFBskW40oUKc6K9yTohStEXO9jYjEkwj4WWBgQKqutg8yoZDEFEp+ Hu2E9629vV35+flWwKeoqEj7mOot4WPADhFAwB8ChHv8MY70AgEEPC6wY4c0fbp97jRvnrR/ v8c7RPnuEzAf51y82H6RTZkibdzovhqpCAEEEEAAAQQQQAABBBBAYESBzk6poMA+pSsslPbs GXE1nkRgUgI1qrECPuYuPuu0blJtsTECCHhMoLbWPsiYOR/r6z1WPOV6QaC1tVXZ2dlWwKes rEyHDh3yQtnUiAACCLhKgHCPq4aDYhBAIIgCe/dKs2fb506zZkkdHUFUoM8JETh4UCottV9s 06ZJ27YlZLfsBAEEEEAAAQQQQAABBBBAIHaB7m6ppMQ+lcvNlXbtir0ttkRgLIE+9alCFVbA J1OZ2qItY63OMgQQ8ItAQ8NgsGf5cr/0in64UKC5uVnp6elWwKeqqkr9/f0urJKSEEAAAfcK EO5x79hQGQIIBEDgwIHhWYvt2wPQabqYXIGhabKZM0mTJXc02DsCCCCAAAIIIIAAAgggMKZA X59UUWG/55qZKW0hazGmFwsnL9CtbpWoxAr45CpXu0SabPKqtICAiwWam6X0dPtAU1UlEbZw 8WD5o7SGhgYr3JOSkqLlhMn8Maj0AgEEEiZAuCdh1OwIAQQQGC5gZklatMg+bzKzJG3aNHw5 PyEQN4GdO5kHLm64NIwAAggggAACCCCAAAIIOCdQU2NfN0hNldYxS5JzsLQ0pkCnOlWgAivg U6hC7RHzwI0JxkIEvCrQ2iplZ9sHmrIyiWmSvDqSnqu7trY2EvCpZxo4z40fBSOAQPIECPck z549I4BAwAWWLRu8QPfQQwHHoPuJF9i8WTIf+zTzaC9cKB0+nPga2CMCCCCAAAIIIIAAAggg gMCoAnV19imbOW1bs2bU1ViAQFwE2tSmHOVYAZ/5mq8e9cRlPzSKAAJJEmhvl/Lz7QNNUZG0 b1+SCmG3QRQYGBhQdXW1FfAJhUJqamoKIgN9RgABBCYsQLhnwmRsgAACCExeYNWqwQt0K1dO vj1aQCAmgQ0bpLQ0+8W4ZElMTbARAggggAACCCCAAAIIIICA8wKNjZK5W48J9ixd6nz7tIhA NAItalGGMqyAT6UqdURHotmMdRBAwO0CXV1ScbF9kMnLk3bvdnvF1OdDgd7eXpWXl1sBn6ys LG3dutWHvaRLCCCAgLMChHuc9aQ1BBBAYFyBoXmK664bd3VWQCC+AqtXDybNVqyI775oHQEE EEAAAQQQQAABBBBAYFyBlhYpI8M+VauslMy03jwQSJZAoxqVqlQr4LNUJM2SNQ7sFwHHBHp7 pfJy+yCTlSURqHCMloYmLvDWW29p7ty5VsAnLy9PuwmaTRyRLRBAIFAChHsCNdx0FgEEki1g ZkIKX6BjJqRkjwb7jwgMnSNu7drI03yDAAIIIIAAAggggAACCCCQWIG2Niknx37Pdf58qYeZ kBI7AOxtRIE61VnhnhSlaI2YI25EJJ5EwAsCAwNSdbV9kAmFJKZC8sKo+b7G9vZ25efnWwGf oqIi7WOKON+POR1EAIHYBQj3xG7HlggggMCEBHbskKZPt8+d5s2T9u+f0OasjED8BMzHQBcv tl+cU6ZIGzfGb1+0jAACCCCAAAIIIIAAAgggMKJAZ6dUUGCfmhUWSnv2jLgaTyKQFIEa1VgB H3MXn3Val5Qa2CkCCExSoLbWPsiYOR/r6yfZGJsj4JxAa2ursrOzrYBPWVmZDh065FzjtIQA Agj4SIBwj48Gk64ggIB7BfbulWbPts+dZs2SOjrcWyuVBVTg4EGptNR+kU6bJm3bFlAIuo0A AggggAACCCCAAAIIJF6gu1sqKbFPyXJzpV27El8De0RgLIE+9alCFVbAJ1OZ2qItY63OMgQQ cJtAQ8NgsGf5crdVRz0IqLm5Wenp6VbAp6qqSv39/agggAACCBwlQLjnKBB+RAABBJwWOHBg eGZi+3an90B7CDgkMDSFNnMmKTSHWGkGAQQQQAABBBBAAAEEEBhLoK9Pqqiw33PNzJS2kJkY i4tlSRToVrdKVGIFfHKVq10ihZbE4WDXCEQv0NwspafbB5qqKonQRPR2rJlQgYaGBivck5KS ouWE0BJqz84QQMAbAoR7vDFOVIkAAh4VMLMdLVpknzeZ2Y42bfJoRyg7OAI7dzJ/XHBGm54i gAACCCCAAAIIIICACwRqauzrBqmp0jpmO3LBiFDCWAKd6lSBCqyAT6EKtUfMHzeWF8sQSLpA a6uUnW0faMrKJKY7SvqQUMDYArW1tZGATz3Tx42NxVIEEAicAOGewA05HUYAgUQKLFs2eIHu oYcSuWf2hcAkBDZvlszHRc382wsXSocPT6IxNkUAAQQQQAABBBBAAAEEEBhNoK7OPvUyp19r 1oy2Fs8j4C6BNrUpRzlWwGe+5qtHPe4qkGoQQMAWaG+X8vPtA01RkbRvHzIIuF5gYGBA1dXV VsAnFAqpqanJ9TVTIAIIIJAoAcI9iZJmPwggEDiBVasGL9CtXBm47tNhrwts2CClpdkv4iVL vN4b6kcAAQQQQAABBBBAAAEEXCfQ2CiZu/WYYM/Spa4rj4IQGFOgRS3KUIYV8KlUpY7oyJjr sxABBBIs0NUlFRfbB5m8PGn37gQXwO4QiF2gt7dX5eXlVsAnKytLW7dujb0xtkQAAQR8JEC4 x0eDSVcQQMA9AkNzEddd5566qASBCQmsXj2YUFuxYkKbsjICCCCAAAIIIIAAAggggMDoAi0t UkaGfcpVWSmZab15IOA1gUY1KlWpVsBnqUioeW38qNfHAr29Unm5fZDJypIIRvh4sP3btbfe ektz5861Aj55eXnaTUDNv4NNzxBAIGoBwj1RU7EiAgggEJ2AmdEofIGOGY2iM2MtFwsMnVtu 7VoXF0ppCCCAAAIIIIAAAggggIA3BNrapJwc+z3X+fOlHmY08sbAUeWIAnWqs8I9KUrRGjG3 3IhIPIlAIgUGBqTqavsgEwpJTGmUSH325bBAe3u78vPzrYBPUVGR9jG1nMPCNIcAAl4TINzj tRGjXgQQcLXAjh3S9On2udO8edL+/a4ul+IQGF/AfHx08WL7RT1lirRx4/jbsAYCCCCAAAII IIAAAggggMCIAp2dUkGBfYpVWCjt2TPiajyJgKcEalRjBXzMXXzWaZ2naqdYBHwnUFtrH2TM nI/19b7rHh0KnkBra6uys7OtgE9ZWZkOHToUPAR6jAACCPxNgHAPLwUEEEDAIYG9e6XZs+1z p1mzpI4OhxqmGQSSLXDwoFRaar+4p02Ttm1LdkXsHwEEEEAAAQQQQAABBBDwnEB3t1RSYp9a 5eZKu3Z5rgsUjMCIAn3qU4UqrIBPpjK1RVtGXI8nEUAgzgINDYPBnuXL47wzmkcgcQLNzc1K T0+3Aj5VVVXq7+9P3M7ZEwIIIOAiAcI9LhoMSkEAAe8KHDgwPPuwfbt3+0LlCIwoMDS9NnMm 6bURkXgSAQQQQAABBBBAAAEEEBhZoK9Pqqiw33PNzJS2kH0YGYpnPSvQrW6VqMQK+OQqV7tE es2zg0nh3hRobpbS0+0DTVWVRPjBm+NI1aMKNDQ0WOGelJQULSe8NqoTCxBAwN8ChHv8Pb70 DgEEEiBgZi1atMg+bzKzFm3alICdsgsEkiGwcyfzziXDnX0igAACCCCAAAIIIICA5wVqauzr Bqmp0jpmLfL8eNKBkQU61akCFVgBn0IVao+Yd25kKZ5FwGGB1lYpO9s+0JSVSUxb5DAwzblF oLa2NhLwqWfaObcMC3UggEACBQj3JBCbXSGAgD8Fli0bvED30EP+7CO9QiAisHmzZD5maubt XrhQOnw4sohvEEAAAQQQQAABBBBAAAEEjhWoq7NPocxp1Jo1xy7nGQT8JNCmNuUoxwr4zNd8 9ajHT92jLwi4T6C9XcrPtw80RUXSvn3uq5GKEHBIYGBgQNXV1VbAJxQKqampyaGWaQYBBBDw hgDhHm+ME1UigIBLBVatGrxAt3KlS4ukLAScFtiwQUpLs1/8S5Y43TrtIYAAAggggAACCCCA AAK+EWhslMzdekywZ+lS33SLjiAwpkCLWpShDCvgU6lKHdGRMddnIQIIxCjQ1SUVF9sHmbw8 affuGBtiMwS8I9Db26vy8nIr4JOVlaWtW7d6p3gqRQABBCYpQLhnkoBsjgACwRUYmm+47rrg OtDzgAqsXj2YbFuxIqAIdBsBBBBAAAEEEEAAAQQQGF2gpUXKyLBPnSorJTOtNw8EgiLQqEal KtUK+CwVybagjDv9TKBAb69UXm4fZLKyJAIOCcRnV8kWeOuttzR37lwr4JOXl6fdBNuSPSTs HwEEEiRAuCdB0OwGAQT8JWBmJgpfoGNmIn+NLb2ZgMDQOenWrp3AhqyKAAIIIIAAAggggAAC CPhboK1Nysmx33OdP1/qYWYifw84vRtRoE51VrgnRSlaI+akGxGJJxGIRWBgQKqutg8yoZDE 1ESxKLKNxwXa29uVn59vBXyKioq0jynpPD6ilI8AAtEIEO6JRol1EEAAgSECO3ZI06fb507z 5kn79w9ZyLcIBEnAfOx08WL7l2HKFGnjxiD1nr4igAACCCCAAAIIIIAAAiMKdHZKBQX2qVJh obRnz4ir8SQCgRCoUY0V8DF38VmndYHoM51EIO4CtbX2QcbM+VhfH/fdsQME3CrQ2tqq7Oxs K+BTVlamQ4cOubVU6kIAAQQcESDc4wgjjSCAQFAE9u6VZs+2z51mzZI6OoLSc/qJwCgCBw9K paX2L8W0adK2baOsyNMIIIAAAggggAACCCCAgP8FurulkhL7FCk3V9q1y/99pocIjCXQpz5V qMIK+GQqU1u0ZazVWYYAAuMJNDQMBnuWLx9vbZYj4HuB5uZmpaenWwGfqqoq9ff3+77PdBAB BIIrQLgnuGNPzxFAYIICBw4MzzBs3z7BBlgdAb8KDE29zZxJ6s2v40y/EEAAAQQQQAABBBBA YEyBvj6posJ+zzUzU9pChmFMLxYGR6Bb3SpRiRXwyVWudonUW3BGn546KtDcLKWn2weaqiqJ EIOjvDTmXYGGhgYr3JOSkqLlhN68O5BUjgAC4woQ7hmXiBUQQMCPAi+9JN1zj7RwoXTmmZL5 NN2MGdI550if/az07/8+fLotM/vQokX2eZOZfWjTJj+q0CcEJiGwc+fo89WZ26Gaiw/XXy+9 //2SCQCddJI0d65UXi6tXCm1tU1i52yKAAIIIIAAAggggAACCDgrYKbWeuAB6WMfk4qLpZNP lvLzpbPPli6/XHr4YWnfvuH7rKmxrxukpkrrmH1oOA4/BV6gU50qUIEV8ClUofZocL66wzqs X+gXukk36Xydb62XoxzN0Rx9QB/QV/VVPaNnAm8IgI8ETBrUTG+/bJl03nnSKadIOTnSnDnS ggXS174m/eEPwzvc2iplZ9sHmrIyiemHhvvwU+AFamtrIwGf+qOmq3vllVd07733qrKyUn// 93+v3NxczZgxQ/PmzVN1dbU2bNigd955J/CGACCAgPsFCPe4f4yoEAEEHBR45RU7X5CWZp8H mWmJR/tnsgerV0tm1iHzaTvzoQhzge5HP3KwIJpCwE8CTz8tZWTYv1TmSrb59NCjj0qnnTb6 L9rQX8CLLz72woWffOgLAggggAACCCCAAAIIuF7A3Jj0i1+Ujjtu/NOYrCx73a4uyXzewfxs TnHWrHF9NykQgaQIbNd2nagTrYDPGq3RgAb0qB61Qjwp1rNj/+/79X79Ur9MSu3sFAFHBAYG 7Gtls2ePf5AxB5TSUslcbzOPT3/a3qao6Nh0qSPF0QgC3hYYGBiQmZbL3L2nsLBQBw8e1Kuv vqrrr79eoVAoEvwxy0f6l52drS9+8YvqNnOs8kAAAQRcKkC4x6UDQ1kIIOC8gPlUnbkt9tAs QTTfm/Ol3buln/9cuvtu5+uiRQR8JfDII9L3vy+98YZ0wQUT/4UzyTuTquOBAAIIIIAAAggg gAACCCRY4Gc/k048ceKnMeaGC888I23dKn35ywkumt0h4DGBTdqk1VotM1XXpbo0ikjPsYGf 23SbjuiIx3pOuYEXMEnQSy6Z+EHGfNr0S1+yP4Fq7vTT3h54SgAQGE3g0KFDWrp0qV577TWt X79eWVlZIwZ5Rgr3hJ+bM2eOdprUNg8EEEDAhQKEe1w4KJSEAALOC9x558TPm4YGf6ZPl377 W+frokUEfCnw4ovSqadO7pfu2msl82kmHggggAACCCCAAAIIIIBAAgQaGqRQKPbTGHPXHvOh IB4IIDC+wF7t1d/r72MK9oSjPh/VR9WnvvF3xhoIuEHg9dcl8wnSoRecJ/r9ZZdJhw+7oTfU gIDrBb7xjW8oNTV1wsGecMDnxBNP1BYznQMPBBBAwGUChHtcNiCUgwACzgs89NDkzpvC51n5 +VJHh/P10SICvhIwty096yxnfum+/nVf0dAZBBBAAAEEEEAAAQQQcKfAk0/aU3GHz/9j/Tp1 qvTcc+7sI1Uh4BYBE8hZoAWTCvaEAz436Aa3dIs6EBhdoLdXKitz5lrZLbeMvh+WIICAJfDY Y49NKtgTDvjk5ubqRfMhVh4IIICAiwQI97hoMCgFAQScFzB/e8UyFddoF/IWLHC+RlpERuEM 4QAAIABJREFUwFcCV13lzMUK80topujiExK+ennQGQQQQAABBBBAAAEE3Cbw5puSuVvvaNcB Jvr8mWdyYwW3jTH1uEvgS/qSI8GecMDnMT3mrg5SDQJHC3zhC84dZMxB6cc/PnoP/IwAAn8T eOWVV2Kaiisc6Dn6a2lpqQa4uzyvLwQQcJEA4R4XDQalIICA8wKXX+7suZM5f/rJT5yvkxYR 8IXAtm12IGeiV7/HWv/cc5meyxcvDjqBAAIIIIAAAggggIA7BW691fnrBg884M6+UhUCyRZ4 Ta8pS1mOhntO1+nqVW+yu8b+ERhZoL1dyshw9kBzxhmkSEfW5lkEdNVVV8U8FdfRwZ7wz48+ +iiyCCCAgGsECPe4ZigoBAEEnBYwd+1JTXX23MlkEEpLna6U9hDwicBnPuP8L5z5pXvqKZ8A 0Q0EEEAAAQQQQAABBBBwk8A77zh7t9/w5xZOPZXPKLhpnKnFPQK36lZHgz3hu/f8SD9yTyep BIGhAjfeGJ9rZYQNhirzPQKWQEdHh0KhkOPhnpKSEoQRQAAB1wgQ7nHNUFAIAgg4LXD33fE5 dzKBoY4Op6ulPQQ8LmDmD582LT6/dOZCCA8EEEAAAQQQQAABBBBAwGGBRx6JzymMCfk884zD xdIcAj4QKFRhXMI9n9QnfaBDF3wnYKbyOeWU+BxozAfseCCAwDCB+vp6x4M94bv3vPTSS8P2 xQ8IIIBAsgQI9yRLnv0igEDcBT784ficO5mLdA8+GPfy2QEC3hL45S/j9ws3Z463LKgWAQQQ QAABBBBAAAEEPCFw9dXxO41ZscITBBSJQMIE/qw/xyXYY+7eM1VTNaCBhPWFHSEQlcCf/hS/ g8xJJ0VVAishECSBj370o3EL99x///1BoqSvCCDgYgHCPS4eHEpDAIHJCbzvffE7f/ra1yZX G1sj4DuBH/4wfr9wxx3HPe1994KhQwgggAACCCCAAAIIJF9gwYL4ncb88z8nv39UgICbBP5L /xW3cI8J+LypN93UXWpBQPp//y9+Bxnz6VMztyQPBBCICJx11llxC/d88YtfjOyHbxBAAIFk ChDuSaY++0YAgbgKxGuGIHPuxEW6uA4djXtRYPXq+F6w+OtfvahCzQgggAACCCCAAAIIIOBi gblz43caU1np4o5TGgJJEFirtXEN92zX9iT0il0iMIbA978fv4OMuUC9c+cYO2cRAsETyMvL i1u458orrwweKD1GAAFXChDuceWwUBQCCDgh8J73xO/86aabnKiQNhDwkcA998TvF85csNi/ 30dYdAUBBBBAAAEEEEAAAQTcIFBSEr/TmE9+0g09pAYE3COwXuvjGu7Zrd3u6SyVIGAEHn44 fgcZc63s5ZdxRgCBIQKnnHJK3MI9119//ZA98S0CCCCQPAHCPcmzZ88IIBBngbPPjt/5k7lJ CQ8EEBgisGFD/H7hTjxxyI74FgEEEEAAAQQQQAABBBBwRmDhwvidxtx8szM10goCfhHYrM1x Dff0qMcvVPTDLwK/+EX8DjKpqdKhQ36Roh8IOCJw7rnnxi3cc8cddzhSI40ggAACkxUg3DNZ QbZHAAHXCnzmM/E7f/rJT1zbbQpDIDkCzz0Xv1+40tLk9Im9IoAAAggggAACCCCAgK8FvvCF +J3GPPCAr+noHAITFnhDbyhNaXEJ+JyqUydcDxsgEHeBzk7JhHDMXXac/jd7dtzLZwcIeE3g 6quvjlu459FHH/UaB/UigIBPBQj3+HRg6RYCCEiPPOL8eZM5D8vKkg4cQBgBBI4ROP30+PzS rVp1zK54AgEEEEAAAQQQQAABBBCYrMDTT8fnFMa8l9vRMdnq2B4B/wmcr/PjEu65STf5D4se +UPgH/4hPgcak07lgQACwwSeeOKJuIR7MjIy9M477wzbFz8ggAACyRIg3JMsefaLAAJxFzB/ b5nZfJz+YIS5IxAPBBAYQeB//2/nf+FCIWn37hF2xlMIIIAAAggggAACCCCAwOQEjhyRTjnF +dOYD3xgcnWxNQJ+FfiOvhOXcM+v9Wu/ktEvrwt861vOH2TMxe7f/c7rMtSPgOMCPT09mj59 uuMBn8suu8zxWmkQAQQQiFWAcE+scmyHAAKeEPi//9fZ86cpU6Tnn/dE1ykSgcQLvP22NH26 s79011+f+H6wRwQQQAABBBBAAAEEEAiMwA9+4OwpjHnPdcuWwPDRUQQmJNCrXp2u0x0N+HxU H51QDayMQEIF3n3X+RTpxz+e0C6wMwS8JPDNb37T0XBPKBTSc8895yUCakUAAZ8LEO7x+QDT PQSCLmCmz5ozx7kLdbffHnRR+o/AOAL19c79wp18svSXv4yzQxYjgAACCCCAAAIIIIAAArEL mLv3vP/9zp3GXHFF7LWwJQJBEHhcjytVqY4EfE7QCdqhHUFgo49eFli/3rmDzNSpfPLUy68F ao+7wLvvvqszzzzTsYDPjTfeGPea2QECCCAwEQHCPRPRYl0EEPCkwK5dUk7O5M+hLr5YOnzY kwQUjUBiBf75nyf/C2duk/XUU4mtm70hgAACCCCAAAIIIIBAIAVef12aNWvypzElJVJPTyAJ 6TQCExJYruWTDveYgNB6rZ/QflkZgaQJ3Hbb5A8yqanSo48mrQvsGAGvCLz00ks6+eSTJx3w ueCCC9Tb2+uVblMnAggERIBwT0AGmm4iEHSBX/1Kes97Yj+H+tCHJDPjEA8EEIhCwJz0mI+r mvvRx/LvhBOkxx+PYkesggACCCCAAAIIIIAAAgg4I2BmXDjttNhOYcxpzznnSJ2dztRCKwj4 XaBf/bpZN8cc8JmiKWpQg9+Z6J+fBMxt4m64IfaDzHHHSWYeSR4IIBCVwG9/+1vNmDEj5oBP WVmZ3nzzzaj2xUoIIIBAIgUI9yRSm30hgEBSBV5+WTr//ImdQ6WnS+aDFdyxJ6lDx869KvDN b0pZWRP7pTvzTOmPf/Rqj6kbAQQQQAABBBBAAAEEPCywd6+0cOHETmHS0qRrr5UOHvRwxykd gSQJ/EA/UI5yJhTyOU2n6Wk9naSK2S0CkxRoaJCmTZvYgeb00yXzyVUeCCAwIYGOjg6ZkE5K SkrU/0KhkG666Sb19fVNaF+sjAACCCRKgHBPoqTZDwIIuEJgYEB67DH7E3Vj3VDk+OOlqirJ TOnFAwEEJiHw2mvS9dePf+Fi7lzJXOAgSTcJbDZFAAEEEEAAAQQQQAABJwSefFK68ELJBHdG u3ZgZhK+9FLpmWec2CNtIBBcgTf1pm7VrcpV7pghHxPquVt365AOBReLnvtD4K9/lW6+WZo+ ffSDjDn4FBZK99wjMS2QP8adXiRNoKmpSeeee65SU1NHDflkZmbqE5/4hNra2pJWJztGAAEE ohEg3BONEusggIAvBV55xc4SfPnL0lVXSZ/7nPT1r0tNTVJPjy+7TKcQSJ6AuRDxn/8prVol 3Xij9NnPSl/8olRfL+3cmby62DMCCCCAAAIIIIAAAgggMIrA669LDz4offWr9t15li6V6uqk DRuYunsUMp5GIGaBIzqiX+qXukt3WVN2fVaf1W26Tf+if9GzejbmdtkQAdcKmA+4PfWUdNdd dtjHXCu7/Xbp3nulbdtcWzaFIeBVAXMnn+9///v6yle+oquvvlo1NTW688479cQTT2j//v1e 7RZ1I4BAwAQI9wRswOkuAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCA gHcECPd4Z6yoFAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQCBgAoR7 AjbgdBcBBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEDAOwKEe7wzVlSK AAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAgggEDABwj0BG3C6iwACCCCA AAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIOAdAcI93hkrKkUAAQQQQAABBBBA AAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBAImADhnoANON1FAAEEEEAAAQQQQAABBBBA AAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ8I4A4R7vjBWVIoAAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAggggAACCARMgHBPwAac7iKAAAIIIIAAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAgh4R4Bwj3fGikoRQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ QAABBBBAAAEEAiZAuCdgA053EUAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ QAABBLwjQLjHO2NFpQgggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIB EyDcE7ABp7sIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC3hEg3OOd saJSBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAgYAJEO4J2IDTXQQQ QAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAHvCBDu8c5YUSkCCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIBAwAQI9wRswOkuAggggAACCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAgHcECPd4Z6yoFAEEEEAAAQQQQAABBBBAAAEE EEAAAQQQQAABBBBAAAEEEEAAAQQQQCBgAoR7AjbgdBcBBBBAAAEEEEAAAQQQQAABBBBAAAEE EEAAAQQQQAABBBBAAAEEEEDAOwKEe7wzVlSKAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAIIIIAAAgggEDABwj0BG3C6iwACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAIIIOAdAcI93hkrKkUAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAAB BBAImADhnoANON1FAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQ8I4A 4R7vjBWVIoAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCARMgHBPwAac 7iKAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAgh4R4Bwj3fGikoRQAAB BBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEAiZAuCdgA053EUAAAQQQQAAB BBBAAAEEEEAAAQQQQAABBBBAAAEEEEAAAQQQQAABBLwjQLjHO2NFpQgggAACCCCAAAIIIIAA AggggAACCCCAAAIIIIAAAggggAACCCCAAAIBEyDcE7ABp7sIIIAAAggggAACCCCAAAIIIIAA AggggAACCCCAAAIIIIAAAggggAAC3hEg3OOdsaJSBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAA AQQQQAABBBBAAAEEEEAAgYAJEO4J2IDTXQQQQAABBBBAAAEEEEAAAQQQQAABBBBAAAEEEEAA AQQQQAABBBBAAAHvCBDu8c5YUSkCCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCA AAIIIIBAwAQI9wRswOkuAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCA gHcECPd4Z6yoFAHfCmzeLN1+u/T2277tIh1DAAEEEEAAAQQQQAABBBBAAIEYBbhuECMcm/le 4KAO6iW9pN/r93pFr+iwDo/Z5yM6otf02pjrsBABBBBAAAEEEEAAAQTcKUC4x53jQlUIBEZg YEB63/uklBSprs6Zbn/3u9Itt0hXXil95CNSaak0d64zbdMKAp4V+I//kFavju3fN74hfe97 UlOT1NHhDoKeHukrX5FuuEG6/HLpH/9ROucc6Zpr3FEfVSCAAAIIIIAAAggggIAjAlw3cISR RnwisF/79age1VW6SvnKV8pR/4UU0jk6R9/St/SG3jim1zfrZmv5MQskrdEa3aSbdIWu0EIt 1Lk6V+fpvJFW9eVz39V3dYtu0ZW6Uh/RR1SqUs0VFxR9OdjhTnGtLCzBVwQmJdDY2KjVq1fH 9O+b3/ymHn74YT311FPau3fvpOpgYwQQQCAIAoR7gjDK9BEBFws89ZQd7DHhnoICqb9/8sWa ME8oNNiuaTs9ffx2zb4ffFD68pel554bf33WQMBTAib0Mn26lJEx/JfD/IKYf2lpUk6OdPLJ x/7Lyhq+zZlnSg8/LB05kjyCN96QTjhheF2mH5dckrya2DMCCCCAAAIIIIAAAgg4LuCm6wam c1w7cHyIaTAKgR71aLVWK1e5VpwnVan6gD6gr+vr+pl+pmf+9t+P9WPdpts0S7M0VVN1j+6R uVuPeWzURpntilU84h5na7bSlDYsLmQCREF5mDCPCUcNDUyla/wLiv3q14N6UF/Wl/WcuKDo qdcL18o8NVwU616BRYsW6aSTTtJxxx2nlJSUY/6lpaUpJydHJ5988rB/J5544rB1Q6GQFixY oPvvv1+9vb3u7TCVIYAAAkkUINyTRHx2jQAC0mc+M/y9+Z//3BkVkzkwQZ1wbiGacM/NNw+u f/zx0gsvOFMLrSDgOgGTXvu7vxt8wc+eLb3zzuhlmo/K7t4tPfqo9D//5+B2p58uPfHE6Nsl Ykl3t3TttYM1Ee5JhDr7QAABBBBAAAEEEEAgYQJuum5gOs21g4QNPTv6m0CLWjRDMyKhE3PX nuf1/Jg+ferT9/Q9K+BzsS5Wu9o1UzOtNkYL95gGzXZ36+7IvoIU7jH9N0EoE9QJB3yiCfeY uyGF1z9ex+sFcUFxzBenWxdyrcytI0NdHhP47W9/q6lTp0ZCO7NmzdLbb789ai8OHjyo559/ Xg888IA+9KEPKTU11dr2ve99r/7D3F2LBwIIIIDAMAHCPcM4+AEBBBIp8Oabx95E5OMfd7aC 8E1Kogn3zJo1mA8woaB773W2FlpDwFUClZWDL/gPfzj60g4flr70pcFtU1Ol++6Lfvt4rLl5 82A9hHviIUybCCCAAAIIIIAAAggkRcBt1w0MAtcOkvJSCOxO79JdkbvJnKyTtUmbJmTxol7U aTpNGcqIBFDGCveYxs3UX+GwStDCPWHcsFc04R5zl6Swl/l6r7igGHb03FeulXluyCjYnQLv f//7I+GeCy64YEJF/vrXv9bZZ58d2f7zn/+8+p2Y7mFCVbAyAggg4F4Bwj3uHRsqQ8D3Avfc Y4d7/uEfBt+XnzJF2rPHua7n5tptRxPuMZmA8J1+zNdNE7te4lzRtIRAIgQWLx58wccSiDGB oPAvjPkF+81vElH1yPt49tnBWmLpy8it8iwCCCCAAAIIIIAAAggkWcBt1w0MB9cOkvyiCNDu V2plJDRigj3btC2m3r+kl2S2DwdQxgv3mJ2E1w1quCc8/Vk04Z5LdEnEy7hNNIAV06CyUXwE uFYWH1daDZzAhRdeGAnnmO8n+ujr69Nll10WaWPx4sU6YqZq4IEAAgggIMI9vAgQQCBpAmee aU/LtX794PvyJiuwerVzJZ18st12NOGejg7pssuks8+W7r7buRpoCQFXCkz2gsX27cN/cc2n m5L1+OMfB2sh3JOsUWC/CCCAAAIIIIAAAgg4LuC26wamg1w7cHyYaXAEgXVap1SlWqER83Wz No+wVvRPrdf6SACFcM/4buEwVDThng516DJdprN1tjWl2fits4ZrBbhW5tqhoTBvCUw23GN6 awI+FRUVkYDP7bff7i0EqkUAAQTiJEC4J06wNIsAAmML/Pd/2+/FP/WU1NsrhUM4Jtwze7Y0 MDD29tEuDbcbTbgn2jZZDwFfCEz2goW5HerUqYOhmuzs5LEQ7kmePXtGAAEEEEAAAQQQQCBO Alw3iBMszbpe4DW9phN0QiSMc42ucaTm83W+1SbhnvE5JxLuGb811vCMANfKPDNUFOpuASfC PaaHL7/8so4//vhIwKepqcndHac6BBBAIAEChHsSgMwuEEDgWIGrrx4e4rn11sGMgAn4mNCP Ew/CPU4o0oYvBSZ7wcKg5OUN/uKaBF2ybo9KuMeXL1E6hQACCCCAAAIIIBBsAa4bBHv8g9z7 K3RFJNhj7hzzht5whOMRPUK4J0pJwj1RQvltNa6V+W1E6U+SBJwK95jyb7311ki4Z86cOTp8 +HCSesVuEUAAAXcIEO5xxzhQBQKBEnjnHSkra/j0W21tgxkBE+75zGecISHc44wjrfhQYLIX LP785+G/tKWlyUMi3JM8e/aMAAIIIIAAAggggEAcBLhuEAdUmvSEQJvaIsGeFKXoYl3sWN3v 6l0dp+PEnXvGJyXcM76RL9fgWpkvh5VOJV7AyXDPM888Ewn3pKSk6F//9V8T3yH2iAACCLhI gHCPiwaDUhAIisB3vytNmSLt2TO8xxdcMJgVyMiQ3nxz+PJYfoo13NPdHcve7G06OqTf/U76 r/+SzG3E//rX2Nvq6pK2bbPvZGS+vv127G2xJQLDBCZ7wWLZssFfWHPXnk2bhjUf1Q9maq+X XrJ/Ucwvi/nePDfRx3jhHjPP3759ybuz0ET7w/oIIIAAAggggAACCARcwAvXDcwQxXrtgOsG AX+Bj9H9r+qrw8I99+m+Mdae+KILdIEj4Z7DOqwe9Uy8gCFbDGjAuivRs3pWT+tpmenInHj0 qU8myHT0Y7/2y+wzmkes4Z5uxXZBsUtd2qZtekpPWV/fFhcAoxknx9fhWpnjpDQYTAEnwz1G cMaMGZGAz0UXXRQV6sDAgN544w09++yzevrpp/Xaa84cY6LaeYwrdXV1adu2bXrqqaesr2/z ZlCMkmyGgL8FCPf4e3zpHQKuFCgpkT7+8WNL++EPB7MC5u4999xz7DoTfSaacM+dd0oLFkhn nWX+ULSDRyarMJHHyy9LN94onXLKYB+OP15KTbV/Nu1+7WuS+fTheA+TQ1i/3q4pFJKys6Wi IvtrWppUViY99th4rbAcgXEEJnPBwrxAzS9p+N/994+zs6MW79ghLVkivec9Umam9L732fP0 mVSfee7aayWzTrSPkcI95ir7HXdI5v9wTJrQ1Gp+oU4/XbrhBukPf4i2ddZDAAEEEEAAAQQQ QACBBAu47bqB6f5krx1w3SDBLyKP7q5IRcPCPeZOPk4+7tf9ukE3jNukuWuQ+S9f+ZF1X9Wr WqZlOkNnaIqmRJZfpIv0uB6PrDfeN3u0R8u1XLM0S5nKtNqbq7lWm9nKlgkgrdM69Wv8D/+Y UMylulSlKtVszVaOcqy6vq1vW2Uc0AGt0ArN1Ezr+RN0gtUHEwAa6xFNuOdO3akFWqCzdJZm aIZVv5lGLdqHCRqt13qrjZBCMn0342++pilNZSrTY+ICYLSejqzHtTJHGGkEAafDPRUVFZFw TygU0ptjfCp8z549Wr58uWbNmqXMzEydccYZmjt3rqZMmaLs7GxdcMEFWrdunfrH+YDpbbfd pn/6p3/Sddddp5tvvlm33HKLampqdO211+ryyy9Xc3PziAP9+OOPq6qqylrvpptukvl3zTXX 6BOf+MSI+zQhpPXr12vBggUyfTM1FhUVWV/T0tJUVlamx3gzaERrnkQgqAKEe4I68vQbgSQJ /P739nvsP//5sQUcOCBNmzaYFzjzzGPXmegz0YR7br9dOuccyQR6wlmFiYR7VqyQTCbBbPuP /yi1tEgHD9qVHjkiPfecnTEwy01u4dVXR++FCZCfd57d1hln2CEeE/YJP558Upo7117+qU9J fWNfiwhvxlcEjhWI5YKFOXH63OfskIx5QRcWSj/96bFtj/aMecHefLO9fX6+tGGD9O6QT9Md OiQ9+qg0Z469zk03RfciPzrc85//KRUUSJWVUlOT/UtnfilNYOjrX5emT7eTd1dcEV3ibrT+ 8DwCCCCAAAIIIIAAAgg4LuDG6wamk5O5dsB1A8dfJr5s0NwJJxyqCX/dp31J6Wt4/+Fwzw/1 Q2UpSzfqRusuO6auP+vPqlNdpObLdfm4tb6gF1SoQisQs1Eb1aveyDbme3OnoumabrVpwi2v 6/XI8pG+MXVcqAs1R3MidZjaTbjH3EXHBIU+qA+qRS36mr4WWecO3TFSc5Hnogn33K7bdY7O kQn0hL2iDfeYuxSdp/Os7UxYyoR4ht5V6Ek9KRN4Mu1+Sp/SeGGkSOF8MzkBrpVJXCub3GuI rS0Bp8M9JlxjpuQK/3viiSdGlH7hhRdUWFios846Sxs3blRv75BjTG+v7rvvPk2fPt1qx4Rm Xn999GPM5z//eX3wgx/UiSeeGNmv2b8J4JSWluqno1wTb2xsPGabqVOn6kMf+tAx4R5zN6Hz zjvPat+EkEyIx4R9wo8n/z979wEvSVUmCvyRMwOIpCFJEhUUBUFhSYokAcUVEX3qYAAFTM/1 LaCswBoIIoqgIGGeIgKKgKIomEiGJ2IAHrAsoAgILChJ4iDf+309W3Xr3unu26H6Tg3zL35D 1606derU/5yquvfU16cuvbQVmJT73WuvveIpD4MKGp8E5msBwT3zdfU7eAJTL7DffrOfuXcK jH7f+8YCbDJ2IN/UM8zUS3BPkX81PqCX4J78Pevtb59d3hyh5+Mf7/xGoZe/fOy4Dj642OP4 z3wjUY7wk8edAT5/7zC6cb7OrBghaMaM8Xn4iUDPAtUOi5e9LOJ732v/7+tfj/jYxyL23DNi ueVmj4Lz6ldHfPGLY1Fsvew0g3hyiKxs4NtvH3HvvZ23yki/TJNpc6iqIlqu0xaGiiFsAAAg AElEQVTVk3fJJWdHCX67y7cG8yuzRZRcRtHddVennC0nQIAAAQIECBAgQGCKBZrcb5AU1T8/ Jus70G8wxY1nHt9dBssUQSL5uWgsOteOqChHBvfMjJmxZqwZ18V1bcuzf+xflvv8aP/Atdhw Rsxopc2Rf74R3ygWj/v8efw8ciSbLMNGsVE8FD0Mgx0RR8fRZTkyuOdN8abYKXYqA4j2iD3K 9bvGruP2OfGHXoJ7im1+H78v8+0luOe2uK010k8eXwb4dHq9WY5wtEas0co73UxTIKCvbHZf nL6yKWhsz+5d1B3cc/jhh48LsDnhhBPaAs6YMaOVLkfpySCbdtPPf/7zVoBOBsxstNFG8dAk r1rIkYBWXnnlcv//+q//2i7bccvuuuuuWGqppVrb5Kg9jzzyyLj1+cNtt91Wvm4sA3z+3uFh UO5/jTXWaOWVx2ciQICA4B5tgACBKRPI30+WWSbiiCM67zLflJPP84t/w/6+0k9wT5ZqqaVm 73uyDrpMmwOAFOV84xs7H1M130z/7nfPmTbjHjbaaHZ+OQrQLbfMmaa65KtfHdv35ZdX15gn 0KNAtcNi2rSIV7yi878ttpj9brg8QTbfPCK/dnrllRE50k6v0957z260yy8fcd99k2+VowRl ufKkyWGquk3V3vV8d93FF3dLPXvdzTePDdeVQ3dNFkA0eY5SECBAgAABAgQIECAwpMC80G+Q h9hr34F+gyEbxHy2+WVxWRkkkoEf+dqquTUVwT1LxBIxLaZFBtx0mnIEniL97rF7p2St5RvE BmXanWPnjmmrAUP5Wq1epl/GL8u8cxShHCEoX8tVTOfGuZGv5Vo2lo2z4+xicdvPfoJ7MoPM Nw0mC+55PB5vBSxl2sVisciRjLpNX42vlsd0eegA7GZVyzp9ZfrKamlIMqk7uOe4444rg2sy KOfgDt+e3mCDDcp0O+/c5R6z//5luk9lP/ck0+c+97ky/bbbbjtJ6tmrp0+f3noFWLvXfz3+ +OOtwKI8lsUWWyxyxKFu01e/+tVy/5d7GNSNyjoC84WA4J75opodJIFmCJx22uw37dxxR/fy 5CAiRdBMDsIxSfB018z6De7pNf2tt84ewCTLmbEE11/ftRjxmc/M/tvoJS+JyACmidMxx4wd 85snH8W4ZZIBSLn/jJkwEehboNph0eWPnXH55tCf3/nO7OG3svGttlpEjuwz2ZTbFCd1D99u KLPLce+L7S64oFw8x0w1uGfddedY3XHBPvuM5Z+97iYCBAgQIECAAAECBOaqwLzQb5BAvfQd 6DeYq01pntz5b+I3ZSBHBn88J54z146jCNbJzw/GB7uWozriUL5Kqtt0QBxQHuNRcVTHpGfG mWW6XWKXjumqK6oj6CwQC8Sn49PV1a35HCXnsXhsjuUTF/Qb3NNr+mPimPK4enmNWY5aVLz2 a+/QATixnmr/WV9ZhL6y2pvV/Jhh3cE9xxxzTBnckgExhx56aFvWAw44oEx31FFd7jFnnlmm 22WXye8xDz/88LhXbV2d75DtMl1xxRWt/H/b7kFQRFSP5809PAzK0YUWXnjhVp57exjURd4q AvOHgOCe+aOeHSWBRgjk4B+vfe3kRfnyl8eet+dz/fx50KmXDrdq3r2m33//sTK+6lXVHDrP z5rVfl2+omyVVcbyO7v7l4fKTLbccvY266xTLjJDoHeBQTositz/9reI3XYba7TZGP/yl2Lt nJ+bbDKW9sc/nnN9pyWXXjq23cYbd0o1flz89dbrnG7imvymQxE8lMOKGb1nopCfCRAgQIAA AQIECEypwLzQb5AgvfQd6DeY0qbzrNjZ3XF3GfiRQTUZoDIrOnQmjfiIq8E9V8QVXfd2R9xR lnuZWKZr2lz56/h15ChF3abfxm/LPDeNTbslLddNDO5Jz0GnXoN1ivx7Sf+P+Efka84K28lG Dyry3jK2bG2zTugALExG9qmvLEJf2cia1/yUcd3BPYccckgZjJPBPSeeeGJHzl//+tdx2WWT 3GN++9syv01zRPcepnwdV+47/73pTW/qusUee+wRO+ywQ9s0OZLPKqusUuZ1do8Pg7bccsvW Nut4GNTW1UIC85OA4J75qbYdK4G5KHDttbOfoecINjnIRrd/+TfEQguNPXPPkXwGnXrpcKvm 3Uv6Z56JWHnlsfIdcEA1h/7nf/nLsbwyziCtepnylWWZPkcO6uftSL3kLc18IDBMh0Xy5Hj5 q68+1njzfdxt3h8c+fqrIoAmP2+8sXfcG24Yv+1NN7XftjpyTz/BPVneBRYY28eFF7bP31IC BAgQIECAAAECBEYuMK/0GyTEZH0H+g1G3lyelTvI4I98DVYR/JGff4kuX6QZoUK1DHfGnV33 lOuL9EvH0l3TdluZo9TcGre2gn9OjpPLPNeKtbptVq6rBvesHCuXyweZ6SVYp5pvL+mrrw1L r2ujtw7AGTGjZbFgLBhPRB+vR68W0HxvAvrKZvft6Svrrb1I1VGg7uCe9773vWUwTAbXfCdH ie9zytFvbr311sjgn5NPPrnMb621ervH3HXXXbHooou2tltooYXitttua1uCG2+8MRZYYIG4 5JJL2q7/5S9/We47j+XaHh8GzZgxo7XdggsuGE94GNTW1kIC84uA4J75paYdJ4G5LPD+9489 P68+5+91/pprBjuAyTrcJubaS/o77xx/LJ/97MRc+vv5jDPG55exCRtuOPm/5ZYb2+7uwb+M 1F9hpX72CAzbYZES55wz1gjzZP7wh+f0Oeus8WnuvXfONJ2W3HPP+G3PPLN9ykGDezK3HLGn uBB94hPt87eUAAECBAgQIECAAIGRC8wr/QYJMVnfgX6DkTeXZ+0O9ow9y6CWDAD5Sfyk1mO9 MC6MD0ebv90n7KUI1snPB+PBCWvH/zhocM/tcXucGCfGbrFbTI/preNePpaPjWKj2Dw2Lx1W j9XH77DDT9Xgns1isw6pelvcS7BONade0p8RZ5THlK7rxXqRrzGb7L/lYrlyu2FGI6qW13wH AX1ls2H0lXVoIBb3KlB3cM/2229fBsQsssgi8eCD3e9LWc7bb7+9NcLPbrvtFtOnT29tv/zy y8dGG20Um2++eZnf6vnl1R6nIsAmg3IOOuigtlu9+93vjhe/+MVt1+XCM844o9x35rPeeuvF hhtuOOm/5ZZbrtzubg+DOvpaQWB+EBDcMz/UsmMkMJcFHn88YvnlI/bbL+I3v+nt3ze+Mfa8 PZ+7v/e9gx3EZB1uE3PtJX2+KrWIBcjPjG8YZjrmmPH55Ug+11/f+7877hhm77adbwXq6LDI 0Xty6KjihJg2LeKpp8aTZvRbsT4/243uM36LsZ8ybXXbTu9KHia4Z9VVx/aR4+abCBAgQIAA AQIECBCYcoF5qd8gcSbrO9BvMOVN6Fmzw2/EN8pAjgwA+VB8qNZje1e8K7aOrSfNc5TBPTfG jbFP7BM5Ek3uZ5vYJk6P0+OWuKUs1/VxfekwSHDPTrFTmdcgM70E61Tz7SX9MXFMeUx53DmS Tx5nr//l689MIxbQVzYbWF/ZiBvasz/7OoN7Zs2aFUsttVQZ2LLTTt2v7zlyzj777BM5wk0G z2yzzTZx+umnxy23VO4x119f5tdPcE+OspN55r8ll1wy7r///nGVmUE3iy22WHzta18bt7z6 wzHHHFPmkfnkSD7XX399z//u8DCoymmewHwpILhnvqx2B01gagVysI18Pp9v5+lnetGLxp65 L7tsxKOP9rP17LSTdbhNzLGX9DniYjXeIEfeGWaaOHLPH/84TG62JdCjQB0dFrmrDTYYf0JM PNFPOWX8+rvu6rGAETHx665f+lL7bYcJ7nnOc8bKd8gh7fO3lAABAgQIECBAgACBkQrMS/0G CTFZ34F+g5E2l2d15n+Pv8cqsUoZBLJ2rF3r8W4ZW8b/jP85aZ6jCu7J0WsWioVax7dmrNlx ZKJhg3t2jp0nPcZuCXoJ1qlu30v6iSP3/DF0AFYNGzGvr2x2Negra0RznJcLUWdwz09+8pNx wTAXXnhhR5ocFSdfmZVBM2uuuWbktu2mDKYpgnT6Ce7JvHbeeedy2yOPPHJc9oceemhkfk9N /PJrJdXEkXv+6GFQRccsAQK9CAju6UVJGgIEhhLYeuuIbbftP4svfGHsmXsG0wwSRDNZh9vE UvWS/sknI5ZYYqxsn/zkxFz6+zlH6qkGC119dX/bS01gIIE6OiyeeSZihRXGN+Dbbx9fnB// ePz6664bv77bT/nO4erJ0eFdxTFocE9+Pbj6HvGZM7uVxjoCBAgQIECAAAECBEYkMC/1GyTB ZH0H+g1G1FDmk2xnxswyuCeDbL4d367lyPOVTgvHwnFWnDVpfqMI7jk3zi2Pa9VYNf4cf+5Y jmdjcE+O1FN1vTp0AHZsAHNrhb6yCH1lc6v1Pav2W2dwz+67714G02ydvzB2mM4999wy3aqr rhp//nOXe8wQwT3VYKOVVlopHs9zJnKw+kciX/t17LHHdijh7MU5Uk8RWJSfV3sY1NXLSgIE 5hQQ3DOniSUECNQocOONs5/Nf/3r/Wf6t79FLL742LP9V76y/zwm63CbmGOv6d/whrFy7bjj xFy6//zQQ+PXZ3zE9Olj+Z188vj1k/30l79MlsJ6Am0E6uiwuOmmsYabQTgrrxzxj3+M31l+ UyHfy1cE6Vxwwfj13X666KKx7ZZbLiJ7yNtNgwb3VCPrFlkkYsJQqu12ZRkBAgQIECBAgAAB AvUKzGv9Bnn0vfQd6Deot53MT7k9E8/EVrFVGQiSo/c8HrMfHg7jcGQcGcvH8vFIPDJpNtUg lAfjwa7p74w7y7IuHUu3Tft0PB1rxVplulPilLbpioW/j9+Xaauv5bo5bo4ZMaPtMVS3aeLI PVmv02N6eVwnR38dgH8JHYBF+xjZp76yCH1lI2te81PGdQX3ZCDNAgss0AqGyddg/T77gNtM Tz/9dKy11lpl0MwpOZJ8lynzKQJsqiP33HzzzTFjxoxWoE6XzeOlL31puf3J//0w5/jjj49l l102Hpr48GdCRs8880xMnz59ju0nJOv44188DOpoYwWB+UVAcM/8UtOOk8BcEvjIR2Y/1//v AOa+S/G2t40928/YgOuv7y+LXjrcqjn2mv6yy8bKteiiEb2+6jS3W3DBiIm/433+82P5bbdd tUTd53/wg9nb/fWv3dNZS2AOgTo6LN785rGGmyfoEUfMsZvWgo9/fCzdfvu1T9Nu6YEHjm13 6KHtUsxeNmhwz8EHj+X/nvd0zt8aAgQIECBAgAABAgRGJjCv9RskRC99B/oNRtZk5ouM74l7 Yp1YpwwEeVe8KzI4ZNDpP+I/YslYMr4YX+wpi7qDe26Km8pjybxvjVu7luPiuLhMXw3uuSqu ai2/P+6fY/umB/dkgT8fny+Pa7vovQPwB/GD1nZ/DR2Ac1R8nQv0lUXoK6uzRc23edUR3HPb bbe1XnGVQTgZ4HPeeed19LzpppvKYJlMf+utk9xjLr64TF8N7rnqqqtay++f5AugZ511Vrn9 +uuvH08++WTrNWAf/ehHO5axuuLzn/98uf12fTwM+sEPftDa7q8eBlU5zROY7wQE98x3Ve6A CUydQAaw5IAdb3zj4Pu84oqxZ+8ZO/DBD/aXV/GK4IUW6m27Iv3CC0+e/q1vHStbBiH1MuXo Q7vsMmfKWbMiNttsLL8ur44tN86AqfXWa59fmcgMgU4Cr3vdWIPbeYB30X/lK2Pb58n50pd2 Hlnn0Ucj1l9/dvp8p92dd3Yq1djyu++OWHLJ2dtkQ888Ok3V4J4cgaeXV39lGZZeenb+q64a cd99nXK3nAABAgQIECBAgACBEQnMi/0GSdFr34F+gxE1nPkk2xylZpVYpQwGeX+8f6AAnxzx 5YXxwtgxdowcQaeXqRrc80A80HWTO+KOsoxLxVJt01YDbzLvu+KutumKhQfEAWWeq8VqxeK4 Iq5oLW83mtDv4nflNjvFTuU2g8w8J57Tymuh6K1DsUifrz3rNs2KWbFZbFaW88K4sFvy1roc tWm9WC92iTYdipNuLUFfAvrK9JX11WAk7iSw1VZblcErGejT7/SrX/0qVl555VYeiyyySJx6 6qlds6iOxJPBPXfdNck95oADyvKttlrlHnPFFa3lDz7YfcS6WbNmtYJ5itF/3vSmN0WW844e vwGe22+22WZlGS7s4WFQvv5rvfXWi13aPVzqqmMlAQLPNgHBPc+2GnU8BBoikK/Uyt8z8pn/ C14Q8dhjgxUsA1jyWX3mk//yzTwPdO9TKHeUbwfKUXWKbf/+93JV25mJ6Scrc67PYJ0i/8MO i3i6Sx9JDjySsQq33dZ293HPPRHrrjs7v2nTIn71q/bpcmm6ZEDRc58bYSTGzk7WdBHIP6yK xrv99l0STliVQTdvecvYtpnHy18+eXBMfmMig2gyfQYCdfsj6eGHI17xitlpV1kl4pZbJhRi wo/V4J7cR55IWc5OU15EiuPPi8of/tAppeUECBAgQIAAAQIECIxIYF7sN0iKfvoO9BuMqPHM R9lmYM4/xT+VwSA52stko95Uea6MK+N58bzYPDaPh+Ph6qqO8xnMUw3u+VP8qWPaXHFdXFem XzAWjKfiqTnSPxFPRAbpFPkeG8fOkaZY8J34Tqwaq7aCkTJ9BswUrxKbGTNjhVihSDru82fx szL/V8Yrx63r54d/xD9i0Vi0zOvv0b1DcWL6x6J7J2iOyrRurNvKf1pMi19F5w7ADOx5W7wt nhvPDa/l6qcWB0xb9BVl35W+sgERbUYgYsMNNywDVzbffPOeSXIEnne84x2x4IILtrZfddVV 48orr5x0+yeeeCIySKcItjn22C73mO98JzLfHXfcsZV+4YUXLl/DNXPmzFhhhfb3mImF+Nzn PlfuL/f79re/fWKSrj/fc889se6667bymDZtWmRAU6cpA3ve9ra3xXOf+9zwWq5OSpYTmH8E BPfMP3XtSAmMXCCDTP793yPe8Y7ZQThF3EB+brBBxCc+EXHDDZMXI0ex+eIXIw4/PGLLLcfH EGReG24Y8W//FnHiiRHf+Mac+X3rW7PX5YhB1TLsttvsfM86a/w2ndLvuWfESSdF5FDanaYc TKT66rCXvSzixz+OeOS/X1+ewT75+2fuOwN7Lr64U06zl+eIirvuOrvcGdSUw5PffPPYNrm/ c8+N2Hjj2cOA/+IXY+vMEegqkA0zR9vJd8Dts8/4k2PxxSMyOi3fR3zaaXP+y5PtoIMitt02 YqmlxrZda62ImTO7R7VVC5Wj5Wyzzezt11gj4owzxkfrZcBP5rfmmrPTZKdKL994KIJ7cmz8 HIFnr71mBxKdc874smUv/AUXjI0itOmmEZMM01otvnkCBAgQIECAAAECBIYTmFf7DfKoB+07 0G8wXJuxdUSO9nJEHBHLxrKtgJDFY/HYN/aNX8Qv2o7Ek8E1l8VlsXfsHQvEAq20GSQy2fT1 +HqcECe0RogpgnDy81XxqvhCfCFOj9PLLPIVYV+Jr8Txcfy44KNM//p4fev1X+fEOWX6nMlR d1aKlVrHkAE7ua9qINBD8VAcHUe3RivK8n83vlsG2OwZe0YG9qwda8fhcXiZbwbSZDmOi+Pi ZfGyMn2W4x3xjvhcfC5OiVPilpjkS0N5jse34sQ4Md4YbxyXz26xW+t4zorxHYqd0mdZT4qT WnVQFnTCTL5ea9fYtbWfRWKR+Eh8JHKkpmJ6NB6Nc+Pc2Dg2jhVjxVZdF+t81iigr2x2xKq+ shob1fyZ1fe///34yle+Ehnw8vrXv35c0EsGz3zsYx+Lk08+OU477bRx/3LZkUceGfvvv/+4 gKBll122tfzvk31bu8J9xRVXxEorrVQG7Jxwwgnx1FNjwaYPPfRQHH300bHKKqvEZZddFt/9 7nfLcu65556RgT1rr712HJ4PpXqYHn744cignCKg6Nprr+1hq/FJ8vVau+66ayuPHPnnIx/5 SNxceRj06KOPxrnnnhsbb7xxrLjiivELD4PGA/qJwHwqILhnPq14h01gFAIZBLPYYrNfxTV9 +uxXRq2zTkTO55DVGT+QcQOTTfk7W75GK4Nh8rVeOXBHxhDkW31yQI587p/LcnSbtdeeM7dN NpkdXJQDeOT63C63yVFu8i08mVd16pQ+4wSyDPvuW03dfv7yyyPyzUbFSEELLBCRIzpmgE4e 99579xdDkEFA+QWRfD1YBijlsaZj/pzHsN9+3QcmaV9KS+drgYnRbtXIt17nl1129kmYDfr0 0zu/hqsb9DPPRJx/fsTWW88+0fNkz5N15ZUjFlxw9rIM6vn2tyMybS9TEdzzpS/NTp3bZfny ApCvActviOT7i/OCkidnjjT09a+PD/zpZT/SECBAgAABAgQIECAwlMC82m+QBz1s34F+g6Ga jo0jIgNCPhYfizVijTL4ZJlYJraJbWKv2CteF6+LDWPD1kg3GdyybWzbCqjpFS/zXT6Wb42a k0E0G8QGrVF/csSdHC0ng4uKKV/vlaPb5PJcn6MDZfrcLn/OfF4QLyiSl593xp3xznhnK2Al y5jbbx1bx6axaSwdS0cGxtwQY98MPCwOi3w1VqbNIJcM4qlOOQrOxHKsH+vHmrFmK5Aoy5zr M3BpsmmT2CSWi+XK4y/yyVFzsmxrxfgOxU7ps5xLxpKtoKrJ9nlxXBzbx/ZlneVIPtNjeuvn 3Od+sV/cHV1GJp5sB9Z3F9BXpq+sewuxtkeB7bbbrgxyKYJdev3MUXoy4OalL31pzJgxI84/ //zoJ6inWsQ777wz3vnOd7YCYXL/OQrP1ltvHZtuumksvfTSkUE8N1S+fX7YYYfFQgst1Cp7 Bs8cd9z4e0w173bzhx56aGvbDNAZZrr44otj++23jwyEynJn0ND06dNbP2e599tvv7i72yj1 w+zctgQIzHMCgnvmuSpTYAIEmiyQbxPKzsocMCT/ZeddMYrPIOXOtwf97GcRZ589e8Seq66K eOKJQXKyDYEGCuQ4/D/96ewGno0853NZnVMG/px33uxgnh/9KOLee+vMXV4ECBAgQIAAAQIE CBDoS0C/QV9cEncQ+EP8IY6JY+J98b5WQEwGyOwRe7SCQb4cX47b4/YOWzZjcQYHXRPXxEVx UZwZZ0a+UqtTEEu+FuvGuLHtKEXNOJrhS5GvQkuDs+Ps1og9V8VVka8yM82HAvrK5sNKd8h1 Czz99NNxzTXXxEUXXRRnnnlm/OxnP+sYHJOBRDfeeGPkNv1O+bqsCy+8MO7LkeRrmB544IFW Wc8+++zWiD1XXXVV5CvHTAQIEKgKCO6papgnQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIAAAQIECBAg0CABwT0NqgxFIUCAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IFAVENxT1TBPgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoEECgnsaVBmK QoAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKAqILinqmGeAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAQIMEBPc0qDIUhQABAgQIECBAgAABAgQIECBA gAABAgQIECBAgAABAgQIECBAgEBVQHBPVcM8AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIECBAgQIAAgQYJCO5pUGUoCgECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AIGqgOCeqoZ5AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAg0SENzToMpQ FAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJVAcE9VQ3zBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBBokILinQZWhKAQIECBAgAABAgQIECBAgAAB AgQIECBAgAABAgQIECBAgAABAgSqAoJ7qhrmCRAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgQIAAAQIECDRIQHBPgypDUQgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAEC BAhUBQT3VDXMEyBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIEGiQgOCeBlWG ohAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBCoCgjuqWqYJ0CAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQINAgAcE9DaoMRSFAgAABAgQIECBAgAABAgQI ECBAgAABAgQIECBAgAABAgQIECBQFRDcU9UwT4AAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIAAAQIECBAgQKBBAoJ7GlQZikKAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECgKiC4p6phngABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgECDBAT3NKgy FIUAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAVUBwT1XDPAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIEGCQjuaVBlKAoBAgQIECBAgAABAgQIECBA gAABAgQIECBAgAABAgQIECBAgACBqoDgnqqGeQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIECBAgQIAAAQINEhDc06DKUBQCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECVQHBPVUN8wQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgM6iPHoAACAASURB VAABAgQaJCC4p0GVoSgECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEqgKC e6oa5gkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAg0SEBwT4MqQ1EIECBA gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIVAUE91Q1zBMgQIAAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBBokIDgngZVhqIQIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQqAoI7qlqmCdAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECDQIAHBPQ2qDEUhQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgUBUQ 3FPVME+AAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgQQKCexpUGYpCgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoCoguKeqYZ4AAQIECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAgwQE9zSoMhSFAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAQFVAcE9VwzwBAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgACBBgkI7mlQZSgKAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgaqA 4J6qhnkCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECDRIQ3NOgylAUAgQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAlUBwT1VDfMECBAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIEGiQguKdBlaEoBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBKoCgnuqGuYJECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQINEhAcE+DKkNRCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECFQF BPdUNcwTIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaJCA4J4GVYaiECBA gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIEKgKCO6papgnQIAAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAg0CABwT0NqgxFIUCAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIFAVENxT1TBPgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAoEECgnsaVBmKQoAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKAq ILinqmGeAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAQIMEBPc0qDIUhQAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgEBVQHBPVcM8AQIECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgQYJCO5pUGUoCgECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAIGqgOCeqoZ5AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAg0SENzToMpQFAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQJV AcE9VQ3zBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBBokILinQZWhKAQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgSqAoJ7qhrmCRAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECDRIQHBPgypDUQgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAhUBQT3VDXMEyBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIEGiQgOCeBlWGohAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBCo CgjuqWqYJ0CAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQINAgAcE9DaoMRSFA gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBQFRDcU9UwT4AAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKBBAoJ7GlQZikKAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECgKiC4p6phngABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAgECDBAT3NKgyFIUAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBA VUBwT1XDPAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIEGCQjuaVBlKAoB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBqoDgnqqGeQIECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQINEhDc06DKUBQCBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECVQHBPVUN8wQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAgQaJCC4p0GVoSgECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE qgKCe6oa5gkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAg0SEBwT4MqQ1EI ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIVAUE91Q1zBMgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBBokIDgngZVhqIQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQqAoI7qlqmCdAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECDQIAHBPQ2qDEUhQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg UBUQ3FPVME+AAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgQQKCexpUGYpC gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoCoguKeqYZ4AAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAgwQE9zSoMhSFAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAQFVAcE9VwzwBAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAgACBBgkI7mlQZSgKAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA gaqA4J6qhnkCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECDRIQ3NOgylAU AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAlUBwT1VDfMECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEGiQguKdBlaEoBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBKoCgnuqGuYJECBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAgQINEhAcE+DKkNRCBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CFQFBPdUNcwTIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaJCA4J4GVYai ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIEKgKCO6papgnQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg0CABwT0NqgxFIUCAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIFAVENxT1TBPgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAoEECgnsaVBmKQoAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QKAqILinqmGeAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAQIMEBPc0qDIU hQABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgEBVQHBPVcM8AQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgQYJCO5pUGUoCgECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAIGqgOCeqoZ5AgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAgAABAg0SENzToMpQFAIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQJVAcE9VQ3zBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBBokILinQZWh KAQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgSqAoJ7qhrmCRAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECDRIQHBPgypDUQgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAhUBQT3VDXMEyBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAgQIEGiQgOCeBlWGohAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBCoCgjuqWqYJ0CAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQINAgAcE9DaoM RSFAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBQFRDcU9UwT4AAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQKBBAoJ7GlQZikKAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECgKiC4p6phngABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAgECDBAT3NKgyFIUAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIBAVUBwT1XDPAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIEGCQjuaVBl KAoBAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBqoDgnqqGeQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQINEhDc06DKUBQCBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECVQHBPVUN8wQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAgAABAgQaJCC4p0GVoSgECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAA AQIEqgKCe6oa5gkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAg0SEBwT4Mq Q1EIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIVAUE91Q1zBMgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBBokIDgngZVhqIQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQqAoI7qlqmCdAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAgQIECDQIAHBPQ2qDEUhQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIE CBAgUBUQ3FPVME+AAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgQQKCexpU GYpCgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoCoguKeqYZ4AAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAgwQE9zSoMhSFAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAQFVAcE9VwzwBAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIECBAgACBBgkI7mlQZSgKAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAg QIAAgaqA4J6qhnkCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECDRIQ3NOg ylAUAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAlUBwT1VDfMECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIEGiQguKdBlaEoBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBKoCgnuqGuYJECBAgAABAgQIECBAgACBngT+67/+K668 8sq48cYb4+mnn+5pG4kIECBAgAABAgQIECBAgAABAgQIEOhfQHBP/2a2IECAAAECBAgQmCKB Bx54IH7/+9+P/N//+3//b44j+uxnPxsf+MAH4q1vfWvssssusfnmm8crX/nKOdJZMH8JaBfz V3072jkFZs2aFSeddFKsvvrqscACC8Tznve8WHLJJVuf3//+9+fcwJKWwDe+8Y046qijBvp3 7LHHxplnnhk//elPIwOqTAQIECBAgMDkAhdccMFA9928Xx999NFxyimnxIUXXhh33HHH5Dub ghR///vf47DDDosDDzww3vzmN8drXvOa2HTTTWPfffedgr3bBQECBAgQIECAQBMEBPc0oRaU gQABAgQIECBAoK3AqaeeGv/jf/yPkf9bbrnl5tj/euutFwsuuOC4fa+yyipzpLNg/hLQLuav +na04wX++te/xkYbbdS6Lu6www5x1113tRLkw6W8Vi+++OLxxz/+cfxGfmoJvO51r4vll18+ Fl100XH3leIel/ebvBetuOKK4/5NmzZtXPqFFlootttuu/jyl78cTz75JF0CBPoU+Mc//hEz Z86Mj3/843Hdddf1ubXkBJoloD13r48MellhhRViscUWG3cvnezem/fiDFwu0uXnC1/4wlag 7dwcqfDee++NpZZaaly5smw777xzdwhrCRAgQIAAAQIEnjUCgnueNVXpQAgQIECAAAECzz6B T37yk2XnZXaw5ig6J598clx88cWtV8H83//7f+Pqq6+OX/7yl/GZz3ymTJudnGuvvXZceuml 8etf/7qV5uc//3n8+Mc/bn378qMf/Wirg7baYfvEE0/MAfjUU0/FcccdV+YruGcOovlygXYx X1b7fH/Q+QBxp512al0PM8CneLiVI6xVr6XnnHPOfG81GUDeu5ZZZpnSLUdBSsdO02OPPRY3 33xz6/736le/ujViUpqvu+66kaMSmAgQ6F3ggx/8YHnuLbHEEnHLLbf0vrGUBBomoD33XiEZ zLfyyiuX538G7D/00EMdM3jmmWfiP//zP+Ob3/xmvPSlLy23W2eddeL888/vuN1UrHj44Yfj ne98Z1kmwT1ToW4fBAgQIECAAIFmCAjuaUY9KAUBAgQIECBAgEAbgYMOOqjVaZkPMG+99dY2 KcYW3X///WUHZz703GeffcZWdpj71Kc+VW5z++23t031yCOPlGkE97QlmvKFGfT1lre8Zcr3 W93hvNoummDXhDJU69J8bwL5aooiiOd73/veuI2233771rpll1028lpcndR3VWNsfosttig9 t9pqq7EVPcz94he/iJe85CXl9h/+8Icjg69MBAhMLpDBdMW1LD9POOGEyTeKCNeynpgkmmKB QdvzFBezMbt77WtfW57/O+64Y8/lyleSHnzwweW2+VrSfEXp3JyuuOKKsjyCe+ZmTdg3AQIE CBAgQGBqBQT3TK23vREgQIAAAQIECPQhsNdee7U6LS+//PJJt/r73/9ednDmw5oZM2ZMuk0m 2HXXXVvb5Qg/nabiIZDgnk5CU7t89913j1e84hVTu9M2e5sX20UT7JpQhjbVadEkAjliTNHm 8xvj1SkDSzLgJK/DEyf1PVFk9s//9E//VHrmfL9TjiC25557lnm8/vWvL0dT6jcv6QnMTwL5 ELy4luVnjurYy+Ra1ouSNFMtMGh7nupyNmV/ea8szv9BAmIyIKjYfuGFF26NHju3ju13v/td WZZBjmVuldt+CRAgQIAAAQIEhhMQ3DOcn60JECBAgAABAgRGKLDNNtvEhhtu2NMeBg3uueSS S1odoxdddFHH/RSduIJ7OhJN6YoXvehFgnsGFG+CXRPKMCDffL1Zvuowr4WrrbZaXw7quz3X sME9mWsG+BSvSsu6yVdOmggQ6C5wxx13tALjcvSrfPVqr5NrWa9S0k2lwKDteSrL2KR9DRvc c+2115YBNXnfzZGA5tb0+9//viyL4J65VQv2S4AAAQIECBCYegHBPVNvbo8ECBAgQIAAAQI9 CmywwQax//7795R60OCexx9/PBZccME49dRTO+5HcE9Hmilf8R//8R+tjmwj9/RP3wS7JpSh fzlbpMCKK67YOvc22mijnkHUd2eqOoJ7Mvc//elPscQSS5QP+C688MLOO7WGAIGBBFzLBmKz EYHGCQwb3JMjFS6zzDLlPXfppZeea8couGeu0dsxAQIECBAgQGCuCgjumav8dk6AAAECBAgQ INBNYNq0aXHSSSd1S1KuGzS4JzOYPn16fPKTnyzzmjgjuGeiyNz7+X/9r/8luGdA/ibYNaEM A/LN95sNEtyjvjs3m7qCe3IPhXPeq9Zff/2YNWtW5x1bQ4BA3wLFOdaEwOK+C28DAgRKgWGD ezKj5z73uWVwT76a6+mnny7zn8oZwT1TqW1fBAgQIECAAIHmCAjuaU5dKAkBAgQIECBAgEBF IEfUyQeV3V6XVUkewwT35MOa97///dXsxs0L7hnHMdd+uPrqqyO/IZv10YQHbPNSu2iCXRPK MNca77Ngx/0G96jv7pVeZ3DPNddcUz5ozOtSt5HoupfKWgIEJgq4lk0U8TOBeVdg2OCeYhSv 4m+Aufn3iOCeebcdKjkBAgQIECBAYBgBwT3D6NmWAAECBAgQIEBgZAL33Xdf7LzzzpGdqL1M wwT3HHnkkfGZz3ym426KDtxVVlmlbZocJSH3X9f04IMPxh/+8If46U9/2vp84IEH6sq6p3ye euqpyOCqidMjjzwSzzzzzMTFHX/OtPfee2/87ne/i8svvzzuvPPOjmknW5EeK6ywQvkAu87O 9DvuuCN+/etfxyWXXBI///nPI9teL9O80i5GadeLU6apuwx1tdEsW93nW9359WpcTVfnuVfk 209wT931XZQhP+vwrbP9VMvWz3ydwT2531VXXbW8Pm699dY9FWUU7aSnHQ+RqI76H2L34zYd 9N4xLpP//iFf9XLbbbe17kF5H8r5XDbolHWb9+x2U/7O8tBDD7Vb1XbZk08+GY899ljbdb0u bFp5inI//PDDxWzbz1Fcy+655574zW9+Ez/5yU8iH87ff//95b6zfWe7GuVU5/WvrvOxqe2j 7vNylPWaeU/Wnqv7n8y8zr9rcr95Dek0ws2jjz4a3//+9+P444+Pc889N/KaM6pp2OCegw46 qLzX5qg9P/7xj/sqap1tarLgnqzjv/3tbx3d+yq4xAQIECBAgAABAo0RENzTmKpQEAIECBAg QIAAgWEEhgnumWy/7YI4/vznP0d28D7/+c+PRRZZpNXRm8E/+VD129/+9mRZzrE+O2DPOeec 2G677WKhhRZqjVDzghe8oPW54IILxjbbbBPnnXfeHNsNuyAfzOy2226tkXDWW2+9WG655VrH 8vnPf76VdXa4f+pTn2q9uiwdllpqqdZx58OhTlM+uDrkkENi9dVXj8UXX7xltOGGG7accuSd rbbaKr7+9a/39ODylFNOib333rs0Luoiy5nlnvjvgAMO6FSsccv/9Kc/tUZrWmONNcpO+iWW WCIWWGCB1s/5oPwTn/hE1wegRVmqQV9NahejshsHOckPdZRhFG207vOt7vwmYe24us5z77rr rht3fhXXuWWWWWbc8jwHi/Oujvpud3DD+I6i/bQrY7/L6g7u2WmnncprWd5DqgEDE8tWVzv5 l3/5l3jLW94S7373u+ODH/xgfOhDH4r3ve998c53vjPe/OY3tx7WTtx3/pz3yLyuZ7oPfOAD rX/77rtv/PM//3Pb+8Iw9d9u/8Msq+PeUd3/DTfcEO9617tipZVWat0vN9hgg8h78WKLLdZa lkaZZrJpxowZrd8/8veGfGVMtoFqEGyWO60z73wgnfevvD9vueWW8ZWvfGWOwN3c53ve855Y a621In8HyXtjvsL01a9+dU8Ps5tWnvTLQO78HWvjjTduBcPlNS0t2k11X8vyd9R8/eu6667b cszfg974xjfGjjvu2CrLDjvsEP/n//yfyPp/05ve1K5IAy0bxfWvjvOxie2jCjzseTkV18Z+ 2nMe2yDmw/xdk/vM0Vd33333WGeddVrXkEUXXTRe9KIXxXvf+974fpTi3gAAIABJREFU4x// 2HqF5BFHHBHLL798bL755q3fLfLatP3221ero9b5YYJ78u+04nf//Pzyl7/cc9mGbVPtdtQu uCcDvA4//PDYZJNNyr+d8n6QdXDggQfGb3/723ZZWUaAAAECBAgQIDAPCQjumYcqS1EJECBA gAABAgQ6C0xlcE8+gFlyySVbwSE5Ik1+KzJHGMoO6qLTNx9s9jrliDavfOUrW9tmsFAG8eTD k2K69NJLI4NjMu+99torugXWFNv0+pllz4fM66+/fln23E8G92QHcT6Ayk72n/3sZ61gl+L4 suO43XTLLbfE8573vNbDsx/96Efjvn2b38Q96aSTyhF4MmDp7rvvbpdNuWy//faL7IjPf/kQ sth/Pggollc/8+HlZFMGK+WD08zrNa95TevYilEJ8lvFGdSQx5fr84FrBuy0m4qyFME9TWsX o7Br59BtWR1lqLuN1n2+1Z1fN89u6+o+966//vpx51g+lMs2nw/5q+dczhfnXR31PfEYh/Wt u/1MLN+gP9cd3JPBNcU1KT/PP//8tkWrs518+MMfbt0fpk2bNm7fRWBJp9dqfuMb34iJ22TQ WAaOTBytZtj6b4sw4MK67h25+7yPZ52lVd5DcrSK6oh5TzzxRHzzm99s3ZszTZ5j3e79eR5m 0EoRoJptoAjuOfPMMyf9nSWDrYpRNfL+n4G8H/vYx+IXv/hFK8g174vVNpZ1321qWnmyrB/9 6Edj0003LYOb0qhTcE+d17IcfTGDrjJwp90oH9nms/6LcyLt6prqvv7VdT42sX2keV3n5VRc G/tpz3lsw5r383fNXXfd1fr9Os+x/PvltNNOixtvvDHy94rPfvazretRBtfl3x557cngw5xy 9J7cJgMK+xmFqLVxj/9Lh9xH/ssRYnuZMlg2g5jzWpzb5d85ne5vE/Orq01NzDd/nhjc88Mf /jDWXHPNeO1rXxsXXnhh6++X/PsmA4v+/d//vfX3V94j3vrWt3b98kK7fVlGgAABAgQIECDQ HAHBPc2pCyUhQIAAAQIECBAYQmCqgntmzpzZ6jjNB13tpv3337/sNO70cLW6Xb56o3idSgb4 5HG0m3KkhWKUmfz27Simo48+uix7PtzLb4/naBDF8Ph77LFHuX7XXXdtW4QsW3Z8Z6d9PsBt N+UrR4oO8o022qjnDuZ8KFZ0yBcPLdvl32lZBky9/e1vb+WRndsf//jH53iQXGz78pe/vNzX wQcfXCwe91mUJR/MNr1dDGs37sAH/KGOMgzbRus+3+rOb0Da1majPPdyB8VruTo9DJ9Y9jrq u27fYdvPxGMc5ue6g3uKgMTiunTCCSe0Ld4o2knen1ZeeeXymvmv//qvbfddXZgPfzOAJMub o/a0e4VU3fVf3X8/83XfOzKIJ0eQyWPP4Nl8fWWnKUfPyzSZNgNii0DUTunz9ZJFG8j75Fln ndXz7yyZ9gtf+EIrSCjt2005Ckfmn/fQDPyZbGpaebK81QfivVzPhr2Wve1tb2uZ3XzzzV25 MrA7besM7qnucNjr3yjOxya1j1Gcl6O6Nlbrtd/2PIx5L3/X5N8Mee3JtvziF7+4bZBOBi4W gYjVLwvk9S1/T//0pz9dPcRa56vBPS972cvie9/7Xtt/OcJoBjjuueeerVFN8++aDED94he/ OOl1uCjwKNpUkXd+Vus+v3Sy7LLLdh09NoOoii+L5JdJ8j5sIkCAAAECBAgQmPcEBPfMe3Wm xAQIECBAgAABAm0EpiK4J1/blN+szuCUTlOOVlM8WMuHYN2m7PTN4JZMnyPJ5IgK3aavfvWr Zd45YlDd0y9/+csy//yGbn4zNR8sFlN+szwfxmbn8dlnn10sHveZ30wvjr/bN2KrQVA5GkIv 07AP2PJbq0XZ8nUY3abioXOmz1fOtJuKvOaFdjGsXbvj73dZHWUYpo3Wfb7VnV+/nhPTj/Lc y31NdXDPKHyHaT8TvYf9ue7gnuOOO668vuW1qVNQ4qjayec+97ly/9tuu21PPPmapxwdbuJo PbnxKOq/p0K1SVT3vSNHqsg6yhHo7rvvvjZ7HL8oR40oRnXJ0fu6TelW3JvWXnvt1nnb6+8s Rfqbbrqp4y6+9rWvlfnn6DaTTU0rT1He4h4/6uCefC1W1kf+3tSunRflyc9cn6NujCq4Z5jr 36jOxya1j1Gdl3VfG6ttppjvpz0PYz7Z3zVZnrz3FNegfOVfpymDFTNdnoM5ssxUTdXgnryu ZiBSp39bbLFFa9St9M3XhuXfK1deeWXkyGq9TKNqU8W+q8E9OdrRxRdfXKzq+JlBhmme9jmS 2WQBox0zsoIAAQIECBAgQGCuCQjumWv0dkyAAAECBAgQIFCnwFQE92RHaL6WotuUr+cqOrXz 25HdpmOOOaZM28tw9w899FDZIZsdxnVP1U7i/EZtu2/OpnO3juActr44/qOOOqpjEfM1IUW6 XXbZpWO66ophgkNuvfXW1mhCuc/sAM9XA3SbPvOZz7SsX/KSl8Rvf/vbtkmL8udn09vFMHZt D36AhXWUYZg2Wvf5Vnd+A5CO22SU517uaKqDe0bhO0z7GYddww91B/dUvfKadOihh7Yt5aja Sb5CpQhAyf1fffXVbfdfLLziiita94BO19fq8czN+2Pd947vfOc75b2vlxGOCq98BU9xz7ng gguKxW0/i3T52c+9KdMfe+yxbfMsFmZgcZF/jijUy1Skb0p5ssz9XM+GuXf95je/Kb0mq7cs 1xve8IbWqIm9uPabZpjr3yjPxya0j1Gel3VfG9vVez/tObcf1Hyyv2sy7xzNssj/jjvuaFfc 1rJ/+7d/K9NlcOpUTdXgnm5fQqiWJ1+tlW0kg+/y2FZbbbXIkX26TaNsU8V+q+f0uuuuWyye 9HOfffYp7TN41USAAAECBAgQIDBvCQjumbfqS2kJECBAgAABAgQ6CExVcE8+kOw2ZUd20am9 zDLLdEya39CudoB3GglnYgZbbrllK/911lln4qqhf652Emdwz9133z1Qnr/+9a/jsssu67pt PtAtnPKbo71Mwzxgq44U9KpXvaqX3cWsWbO6pivKn59NbxfD2HVF6GNlHWUYtI3Wfb7VnV8f jF2Tjurcy532+/BwmPoele+g7acr+oAr6w7uOeSQQ8pral6TTjzxxI4lG1U7yWCV4rqYr3Xs NuVrHnfYYYe2SUZV/213NsnCuu8dm2yySWmU50iv06WXXlput/HGG3fdrKiDfu9Nmb7T67iK HWbQVpH/+uuvXyzu+lmkb0p5srD9XM+GuZZlYEfxGtL8/PCHPxzXXHNNR68cwfE///M/O64f ZsWg179Rn49NaB+jPi/rujZ2qv9+2nPmMah5t79rMt/qqEC5j2z/naa8RxXlyGCTqZoGCe4p yva3v/0tdtttt7Lc+TfZX/7yl2L1uM9Rt6ncWfWcXm+99cbtv9sP1SDNrNNuX9rolo91BAgQ IECAAAECc0dAcM/ccbdXAgQIECBAgACBmgWmKrjnzjvv7FryXF90Vi+99NId01Zfj5Dpr732 2o5pqytmzJjRyj9Hn+l1WPjq9t3mq53EK6+8crekA63LkYdyFIR8sHzyySeXTmuttVZP+Q36 gO2ZZ56JPJ6iXnLkijqmIr/8bHq7GNSuDqcijzrKMGgbrft8qzu/wmhUn8Oee1mufh8eDlPf o/IdtP2Mol7qDu5573vfW17j8pqUowb0Ow3bTu66665YdNFFW+XIQIZOgSI33nhjZADpJZdc 0raIo6r/tjvrsrDue0e+DqV630iHXqd8bU11226vzqqm6+felHWWgRzdpupINL0+TG5aefL4 +rmeDXMty3299a1vHVd36ZH7f81rXhP/+3//79a5mq9eG/U06PVv1Ofj3G4fU3Fe1nVt7NRG +mnPmceg5t3+rinKlq+gK/Lvdv357Gc/W6ar6/fyogzdPocJ7sl88+/N1VdfvSz785///Hjk kUfG7XIq2lTusHpO93o9zu2yvHkPLurpwgsvHFd+PxAgQIAAAQIECDRbQHBPs+tH6QgQIECA AAECBHoUmKrgngcffLBriXoN7jnjjDPKTtXsXM1O2RzufrJ/yy23XLndoCPrdDqAaifxZptt 1ilZz8tvv/321ugR+S3X6dOnt8q9/PLLx0YbbRSbb755eRzZSd7LNOgDtmqdpHU+UKhjKjrF 87Pp7WJQuzqcijzqKMOgbbTu863u/Aqjuj7rPveyXP0+PBymvkflO2j7qateqvnUHdyTr0gq rkmLLLLIpNekLMso2kkRgJplOeigg6qHXM6/+93vjhe/+MXlzxNnRlX/E/cz2c913zvOOuus so7S5957752sCOX6e+65Z9y2+WrLTlPRDvKzrntTsa9hg3uaUJ48ln6uZ8Ncy3Jfjz76aGyz zTbj6q9aRzmfAdv5Sq4MgB7VNOj1b9TnY9VibrSPqTov67g2dmob/bTnzGOU5vvuu2+Z/7e+ 9a1ORW6196IcOTLZVE3DBvdkOc8555zyGPMYckSu6jRVbap6TvcT3JNlzRF7Cv9PfOIT1eKb J0CAAAECBAgQaLiA4J6GV5DiESBAgAABAgQI9CYwrwX3HHPMMWWnanau5jejr7/++p7/5eu/ 6p6qncQ77bTTwNnnaAQ5xH4+rMpjy4dap59+euTrJoopj7XoVB51cE/1FWC5z+yUr2Mqyp+f dT2QGlW7GPbhZB1edZRh0DZat2vd+dXhm3mM6tzLvPt9eDhMfY/Kd9D2U1f9VPOpM7gnXyG4 1FJLldfUya7fo2wnOQpdcW1ccsklY+KIJBmUuthii8XXvva1Kse4+VHV/7id9PBD3feO6kgV aTRxtIduRcq0hWt+HnXUUR2TV9PVdW8qdia45xUFRV+fTz/9dJxwwgmRrzKr1s/E+Rz15Kqr ruor714TD3r9G/X5WDWYG+11qs7LOq6Nneq63/vzKM3vu+++cmSbrbbaKp566qk5ip2BkxmE muXIYM+pnOoI7sm/OYu/cfIYpk2bNu44p6pNVc/pfoN7Vl111fJalK+fNBEgQIAAAQIECMw7 AoJ75p26UlICBAgQIECAAIEuAvNacM/Eb0L/8Y9/7HJ0U7Oq2km88847D7TTPK58tUd2dq+5 5prxk5/8pG0+owruyQdoE18rkq+GqT7IyDLWMVXzrOuB1KjaRS+BFu3s6nAq8qijDIO20bpd 686vMBrmM8s0qnMvy9Xvw8Nh6ntUvoO2n2HqpdO2dQb35HW2ej3q9oqNUbeTPN68fxTlOfLI I8cRHHrooa0Hv+0e+BYJR1X/Rf69ftZ97zjllFNKl/TJV/X0Ok0cRehLX/pSx00L+/ys695U 7ExwT/vgnn7unzk6z7nnnhuHHXZY7LrrrlEdkTHrLEc6/K//+q+CvLbPQa9/oz4f53Z7narz Mity2Gtjp8bQ7/15lOZZxpkzZ5bXuje/+c2RI4/l9Nhjj8XFF1/c+vsgy/Da17629lcMdzIq ltcR3JN5bbDBBuUx5rHkq7iKaaraVPWc7je45znPeU5Z/kMOOaQouk8CBAgQIECAAIF5QEBw zzxQSYpIgAABAgQIECAwucC8FtyTI/VUO9evvvrqyQ9yxCmqncSDBPfkw6rimPIboX/+8587 lnhUwT2veMUr4uCDDx633yeffDKWWGKJsmyf/OQnx60f9IfiWPOzrgeoo2oXvQRatLMb1Kbd dnWUYdA2Wrdr3fm18+pn2ajPvSxLvw8Ph6nvUfkO2n76qYte09YZ3LP77ruX17ett966YxGm op3kzqvBRiuttFI8/vjjrTLl6DP5asZjjz22Yxlzxajqv+tO26ys+95RPSfyvnHddde12Wv7 RdVRP3LbSy65pH3CEb9yR3BP++CeTvfPfCXXZKMFZju74IILYu211y7P4+OPP75j/Q66YtDr 36jPx1H8LlUY9dJep+q8zDINe20sjmviZ7/351GaZ9ny1bt5nT/ggANawWsLLLBArLzyyq3R ejII+aUvfWlcdNFFEw9jSn6uI7jnmWeeiRVWWKE8X9MzX3NZTFPVpqrndD/BPXlPzjop2kEG Y5kIECBAgAABAgTmHQHBPfNOXSkpAQIECBAgQIBAF4F5LbgnO4bz29lFx+rJJ5/c5ejmXPWX v/xlzoVDLql2Evcb3JPfWl9rrbXK48lvrXabqvuqvpYrv/k6Y8aMtq8rqXaW54O0dlOnB2xv eMMbyrLtuOOO7TbtuOyhhx5qu66ou/ysK7hnVO1iGLu2Bz/AwjrKUG03/bTRul3rzm8AznKT qTj3cmf9Pjwcpr5H5Tto+ymxa5ypK7gnHxYXD+nyNVh5jO2mqWonxb7z4W1xjSzubxmwkK8d 6nRNLbYdVf0X+ffzWee9I0cryuCmwiUDOnqd8kF4sV2O9JIBIZ2mIl1+1nVvKvbVS7BEkbb4 bFp5slz9XM+GuZblK7by+PMVb5NNf/3rX+MFL3hBK/1ee+01WfK+1w96/Rv1+Ti328dUnZdF hQ1zbSzymPjZT3vObUdpnqP0ZP5/+tOfWsXMe08GMv7oRz+KP/zhD1M+Us9EqzqCe2666aZx hhm4VB01dKraVPWc7ie4pxqwl69Hm/j6zIlmfiZAgAABAgQIEGiWgOCeZtWH0hAgQIAAAQIE CAwoMK8F9+Rhfv7zny87h7fbbruej/wHP/hBa7t8EFTnVO0k7idwIsswsaM7XzvRbcph+YuH C9XgnuJBWLuO5mJdbrfZZpu1zf6FL3xhfOYzn5lj3WWXXVbub9FFF4077rhjjjTtFuR2Cy64 YNuH0UX587POB6ijaBfD2LVzGWRZHWUYpo3W7Vp3foOY5jZTce7lfvp9eDhsfY/Cd5j2M2j9 dNqujuCefG1UXj/zGpQBPuedd16n3U1ZOykKcNZZZ5XX3PXXX78VjJKvavzoRz9aJOn6OYr6 77rDDivrvnd8/OMfL13222+/Dnudc/GBBx5YbpevNus2jerelPucH4N7hrmWFe3nX/7lX7pV WbnuuOOOa9Xz3nvvXS6ra2aY698oz8cmtNepOC+Lehz22ljkU/3s9/48SvPvfOc7rTZ8xRVX VIvYmPk6gnvyVWNVwyOOOGKO45uKNlU9p/sJ7skRTovyv+c975mj7NUFGdx46qmnxt13311d bJ4AAQIECBAgQGAuCgjumYv4dk2AAAECBAgQIFCfQL7uo+iozM93vOMdtWVezfeBBx7omm8G jRTpl1pqqa5pZ82a1QpSKdJfeOGFXdPnyhxKPTtwd9lll0nT9pvgd7/7XVn2nXbaqa/Nqx3M eTx33XVX1+1zqP7iuFdbbbUybT4MyOXtgmXyW8DFNvkt2YlTfrs8R644//zzJ65q/fzWt761 3P5tb3tb2zQTF77yla/saF2UJT+b3i6GtZvoMsjPdZRhmDZa9/lWd36DmOY2U3Hu5X6e85zn tM6ffKVGL9Ow9T0K32HaTy/H3E+arbbaqrweZaBPv9OvfvWr1mtO8vqT37zPh2/dpqlqJ0UZ sv4ymKe4Tr7pTW9qlbPXwMpR1H9Rtn4/67x35GuaMtgpXfJ1kXfeeeekxcmHqnlvy23y/p95 dJsK8/ys896U+8xXiBb5r7vuut2KUa4r0jelPFmw4nq28MILl+XsNDPMtawI7slX+OSIJpNN +SqjdPr0pz89WdK+1w9z/Rvl+diE9jEV52VRYcNeG4t8qp/9tOfcbpTmP/3pT1v55z0u/zZr 2vS6172uPP5+v8iQx/KVr3yl3D4dcySmdiOpTUWbqt7X8/eAXl71mPecpZdeunUM+Qrl++67 r2MVHXbYYeWxZgDZZH/bdczICgIECBAgQIAAgVoFBPfUyikzAgQIECBAgACBuSWQr3Oqdlb3 G5zSqdz5YKyabz7k6TZlx2qRPkd8yaHZu035sCcfkOU206ZNi3xg22nKwJ4MSnnuc58bo3gt 189+9rOy7BnU0s/0xBNPRAbpFMeeD6g6Tfmt3uxQztdjZfp8uFY8AJg5c2bkQ7BO08Ybb1zu Ix8yVqd8xUk+LO307dLHHnss8riKMmandb4uoNOUoyPkA9UcHWPiNC+2i2HsJh7/oD8PW4Zh 2miWue7zre78BnGdinMvXzeRI14V506OlNbLNGx91+07bPvp5Zh7TbPhhhuWnptvvnmvm7VG 4Mng1by/ZH3ktfTKK6+cdPupaCcTC/G5z32uPMYs69vf/vaJSbr+XHf9d91Zl5V13jtyNzmy XdZbmuSD4XbBrEVxHn744cjXTWbaVVZZJW655ZZiVdvPUd+b8tU6WZb8l7+LTDY1rTxZ3onX s6zfyaZBr2VFcE967bHHHl1/58gAgU022aQ1Slq2/bqnYa9/ozgfm9Q+RnleTqzLYa+N1fz6 bc+jNs+/VTIAP9t8/j6/ww47RP5NloE0u+66a+y2227xz//8z/Gud70r8vfsb37zmz0FvlWP eZj56qh522+/fc9Z5d8Wb3nLW8rrXx7fy1/+8q7BMaNuU9Xgnryn5N+Tnf4GygPNui+OP1/v mK9J6zYV9ZjHmv9OOumkbsmtI0CAAAECBAgQmCIBwT1TBG03BAgQIECAAAEC9Qlccsklcdpp p7W+PfmFL3whPvShD8Xznve8cR2u2Qm55557xqc+9an40pe+1BrVILfpddSAr3/963HCCSe0 Rm0pOjXz81WvelXkPk8//fTygHLEmPwm5/HHH192mhbb5PDvX/ziF+Occ84p00+cyddrZYd3 bpPfvPzIRz4SGaxUTPntz3PPPTfy4VJ+c/IXv/hFsWroz3yolWXPV0G87GUvG2eYD5DzAcQp p5wy6QPFLEiOurPSSiu18siAnfSrBjc99NBDcfTRR7ceUOYDr+9+97vl/rKuMrBn7bXXjsMP P7zjceU3z4tvnL7kJS8pHwhkB3eOEnHIIYd03DZXpGUGSBX1k8ecQ84XwUUZ7JMPyvPhQwb2 5OvDqtO83C6Gtas6DDo/SBnqbKNZ7rrPt7rzG8R2VOfet771rTjxxBPjjW98Y3nO5Lmz9dZb x1FHHRVf/vKX4/LLL+9Y5EHqe2Jmw/rW3X4mlq/Xn7///e+3rrV5Ta2+FiQ983r5sY99LE4+ +eTWvS3vVcW/XHbkkUfG/vvvH9WAoGWXXba1vNdAqyznqNpJJ4MMTMmg1eJ6e+2113ZK2nH5 sPXfMeM+Vwx775i4uxw9YZtttmnZrLHGGnHGGWeMG2UnA37ynliMfpQPZLv9/jLKe1Mee/F7 QgafFPWZn3k/zQe+eT+vTk0rT5at0/Usf//IY8jfSzpNg17LiuCeDMbLYKgMBsjfVyZOeW68 5jWvaV0LOo0+OHGbXn6u+/pX1/nYxPaRnnWfl53qqI5rY7/teZTmE48z23CO8le9VnSbz799 MuBnsi9QTNxPLz/n7/h5/cpXy+2zzz7jyrT44otHBvrn3znFPbf6mb//HHTQQbHttttGjsZa HMNaa63Vuj53+4JAUbZRtqkiuCf/NswRePbaa69W4Gj+zVktWwaA5RcgilHjNt1001aQaVHG Tp/5CuTimPOzlxFmO+VlOQECBAgQIECAQH0Cgnvqs5QTAQIECBAgQIDAFAnkkOr5jcMcKSY7 WPObitlhucEGG8Tzn//81r+cz2XrrLNO5IOzDDrJYI0f/vCHPZUyt1l++eVbnaQZcJL5ZQBR 7jO/iZoPVospO1BzVItcnuszXabP7fLnzOcFL3hBkbzjZwaS5LdI80FvdqLmQ9Hp06e3fs6A lv3226/rNzI7ZtxlRX4Te2LZ0y0fKKZZHmeuz4cCvUzZif3Od76zFYSUx5AmGQiQHcl5DPkQ 7YYbbiizyk714gFAdk5nkNFkUz4sywdkmX9uW3yzNIOiqp3Z3fLJgIT8FnExGskCCyzQqqt8 wJCd/XvvvXfbju95vV3UYdfNtZd1/Zah7jZalLHu863u/Ipy9vo5inMvA+jyOpQjhuS1Nq8N eV3Ln/ManOfKvvvu27WI/dZ3p8wG9R1V++lUzk7Lt9tuu3EPyfL61eu/DAxI8xzlZcaMGa1X D/YT1FMt0yjaSTX/ifM5MkMeZwawDjMNWv/D7LPdtoPeO9rllYHB+RA875F5L8t/OfpC3tOy zvPnDOr59re/HZm22zTKe1O2mcUWW6z1Kqvid5ziWpDlzWtBtu/q1LTyZNkyMCnLmmXO61jx u07+7pG/H47iWnbVVVe12n8Gmd9///2t0avSMn+32nLLLWOLLbZo/a6V9Z0jnHQbvbHq2+v8 qK5/w56PTWwfhWmd52WRZ7vPYa+N/bbnUZpXjy9HjskvXeRImnntz1eGrb766q2/Z/I+lj8X QfoT74G57pprrqlmN/T8xODkifvs5ec8X/NvzfzbIL/c0e41XN0KOqo2VQT35PUlp9xPli+v b+mfowLmtTn/Ds2/c/Jvp/x7rte/lX7729/Gi1/84tZ184Mf/OCk96FuBtYRIECAAAECBAjU JyC4pz5LOREgQIAAAQIECBCoRSCHTc/XJ5x99tmtEXvy4VC+UmVemrLjODvoL7roojjzzDNb x9NpqPh8SH3jjTf23NlcOOQr0PKbqPlN0k55F2k7fea3pzP4IL/lmv/ywW0xik+nbebW8jrb RR12wzo0oQx5DHW6jiK/fp2n4tzrt0yZvq76rru+BjmWZ8M2U9VO8hUteY3OUQXqmJpS/3Xf O/72t7/FT3/609Z9P+/9OZ/LTM0T6Odalu0/f4erTlmvOQJljsyUdZ0ji8yrdd2U87HqW+f8 KM/Luq+NdR73oHnl79MZoJMBbJ/85CfL0TXb5ZejeeaIVWeddda4UVJf+MIX9v33QLv8m7ps lG2qeswZ+HPeeee1gnnydYr33ntvdbV5AgQIECBAgACBeVhAcM88XHmKToAAAQIECBAgQIAA AQIECBAgQIAAAQIE5pZABo9kYE+OhHPqqaf2XYx8bVYxis4SXK4TAAAgAElEQVRPfvKTvre3 AQECBAgQIECAAIH5RUBwz/xS046TAAECBAgQIECAAAECBAgQIECAAAECBAjUKPC1r32tFZyT r7jr9bVP1d3/4x//iGWWWaaVx2c/+9nqKvMECBAgQIAAAQIECFQEBPdUMMwSIECAAAECBAgQ IECAAAECBAgQIECAAAECvQmcdtpprcCcJZZYIvKVY/1OTz75ZCy11FKtPE4//fR+N5eeAAEC BAgQIECAwHwjILhnvqlqB0qAAAECBAgQIECAAAECBAgQIECAAAECBOoTuP/++2OFFVZoBecc cMABkSPx9Do988wz8aEPfai1beaReZkIECBAgAABAgQIEGgvILinvYulBAgQIECAAAECBAgQ IECAAAECBAgQIECAwCQCV111VSy//PKtIJ1ddtklbrjhhkm2iLj55ptjjz32aG2z3HLLxZVX XjnpNhIQIECAAAECBAgQmJ8FBPfMz7Xv2AkQIECAAAECBAgQIECAAAECBAgQIECAwJAC99xz Txx44IGx4oortgJ2tthii/jEJz4R+aqtSy+9tPVv5syZccQRR8SWW25Zjtbz3ve+N+6+++4h 925zAgQIECBAgAABAs9+AcE9z/46doQECBAgQIAAAQIECBAgQIAAAQIECBAgQGDkArNmzYof /OAH8YEPfCD23HPPyCCfNdZYI1ZfffV4+ctf3hqt5/3vf3/88Ic/jExrIkCAAAECBAgQIECg NwHBPb05SUWAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIEBgygUE90w5uR0S IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ6E1AcE9vTlIRIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQmHIBwT1TTm6HBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBHoTENzTm5NUBAgQIECAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBKZcQHDPlJPbIQECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AIHeBAT39OYkFQECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIEpFxDcM+Xk dkiAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgNwHBPb05SUWAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIEBgygUE90w5uR0SIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQ6E1AcE9vTlIRIECAAAECBAgQIECAAAECBAgQIECAAIH/ z97dQNdZ1fniz1slgUJTipVAi4y0DAHfCCPtKIjtIC3XesWrHQGNzHWcyhWtM7i0omLE64yZ uTgT8O3WN1YVZhwYQcPVZYtDi17EdqBFHW2F6PCnSCjtQAMBSkz6+699cnNO2ibpSZucnJfP WSsrOefZz96//dkn62St55v9ECBAgAABAgQIECBAgEDBBYR7Ck5uQAIECBAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQL5CQj35OekFQECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAIGCCwj3FJzcgAQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgTyExDuyc9JKwIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIFFxDu KTi5AQkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAjkJyDck5+TVgQIECBA gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQKLiDcU3ByAxIgQIAAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBDIT0C4Jz8nrQgQIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgUXEC4p+DkBiRAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECCQn4BwT35OWhEgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAouIBw T8HJDUiAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIEAgPwHhnvyctCJAgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBQcAHhnoKTG5AAAQIECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIBAfgLCPfk5aUWAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECg4ALCPQUnNyABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgACB/ASEe/Jz0ooAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIBAwQWE ewpObkACBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAEC+QkI9+TnpBUBAgQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgACBggsI9xSc3IAECBAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIE8hMQ7snPSSsCBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBRcQ7ik4uQEJECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQI5Ccg3JOfk1YECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECi4g 3FNwcgMSIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQyE9AuCc/J60IECBA gAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIFFxAuKfg5AYkQIAAAQIECBAgQIAA AQIECBAgQIAAAQIECBAgQIAAAQIECBAgkJ+AcE9+TloRIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQKLiAcE/ByQ1IgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAAB AgQIECBAID8B4Z78nLQiQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgUHAB 4Z6CkxuQAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAQH4Cwj35OWlFgAAB AgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAoOACwj0FJzcgAQIECBAgQIAAAQIE CBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgfwEhHvyc9KKAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAQMEFhHsKTm5AAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgQI ECBAgAABAvkJCPfk56QVAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAAQIECBAgQIAAgYIL CPcUnNyABAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBPITEO7Jz0krAgQI ECBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBAgAABAgUXEO4pOLkBCRAgQIAAAQIECBAg QIAAAQIECBAgQIAAAQIECBAgQIAAAQIECOQnINyTn5NWBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAouINxTcHIDEiBAgAABAgQIECBAgAABAgQIECBAgAABAgQIECBA gAABAgQIEMhPQLgnPyetCBAgQIAAAQIECBAgQIAAAQIE8hB47rnn4gc/+EFcf/31cdVVV8WH P/zh6OjoiM7Ozujt7c2jB00IECBAgAABAgQIECBAgAABAgSGCwj3DNfwMwECBAgQIECAAAEC BAgQIECAwCEJbN26NS699NKYPn16VFVVjfjV0NAQF110Udx3332HNIaTCBAgQIAAAQIECBAg QIAAAQKVKCDcU4mrbs4ECBAgQIAAAQIECBAgQIAAgQkSeP755+P9739/1NXVjRjoGSnoU11d Ha2trfH0009PUBW6IUCAAAECBAgQIECAAAECBAiUr4BwT/murZkRIECAAAECBAgQIECAAAEC BCZV4PHHH49zzjkn71DP/kGfl7/85fHQQw9Nao06J0CAAAECBAgQIECAAAECBAiUuoBwT6mv oPoJECBAgAABAgQIECBAgAABAlMg8Nxzz8WCBQsOOdgzFPQ59dRT48knn5yCGRiSAAECBAgQ IECAAAECBAgQIFAaAsI9pbFOqiRAgAABAgQIECBAgAABAgQIFJXAO9/5zsMO9gwFfC688MKi mptiCBAgQIAAAQIECBAgQIAAAQLFJCDcU0yroRYCBAgQIECAAAECBAgQIECAQAkI/PSnP43q 6uoJC/ekkM9tt91WAjNXIgECBAgQIECAAAECBAgQIECg8ALCPYU3NyIBAgQIECBAgAABAgQI ECBAoKQFzjvvvAkN9qRwT3Nzc+zdu7ekXRRPgAABAgQIECBAgAABAgQIEJgMAeGeyVDVJwEC BAgQIECAAAECBAgQIECgTAUeeeSRCd+1Z+j2XPfdd1+ZqpkWAQIECBAgQIAAAQIECBAgQODQ BYR7Dt3OmQQIECBAgAABAgQIECBAgACBihP4whe+MOG79gyFez7xiU9UnKcJEyBAgAABAgQI ECBAgAABAgQOJiDcczAhxwkQIECAAAECBAgQIECAAAECBLICl19++aSFe9785jdnx/EDAQIE CBAgQIAAAQIECBAgQIDAoIBwj3cCAQIECBAgQIAAAQIECBAgQIBA3gL/9b/+10kL9yxYsCDv OjQkQIAAAQIECBAgQIAAAQIECFSKgHBPpay0eRIgQIAAAQIECBAgQIAAAQIEJkDg9a9//aSF e1760pdOQIW6IECAAAECBAgQIECAAAECBAiUl4BwT3mtp9kQIECAAAECBAgQIECAAAECBCZV 4J3vfOekhXuWLFkyqbXrnAABAgQIECBAgAABAgQIECBQigLCPaW4amomQIAAAQIECBAgQIAA AQIECEyRwMc+9rFJC/e8+93vnqJZGZYAAQIECBAgQIAAAQIECBAgULwCwj3FuzYqI0CAAAEC BAgQIECAAAECBAgUncBdd901aeGeW265pejmqyACBAgQIECAAAECBAgQIECAwFQLCPdM9QoY nwABAgQIECBAgAABAgQIECBQQgL9/f3xwhe+cMIDPvX19fHUU0+VkIRSCRAgQIAAAQIECBAg QIAAAQKFERDuKYyzUQgQIECAAAECBAgQIECAAAECZSPwmc98ZsLDPR/84AfLxsdECBAgQIAA AQIECBAgQIAAAQITKSDcM5Ga+iJAgAABAgQIECBAgAABAgQIlLHAP/5jxCWXRDzzzLMxd+7c CQv4zJw5M3bt2hVXXHFFfPGLX4yBgYEyVjQ1AgQIECBAgAABAgQIECBAgMD4BIR7xuelNQEC BAgQIECAAAECBAgQIECg4gQeeCDi/PMjqqoGv268MeInP/lJHHHEEYcd8KmpqYnbb789/vVf /zXb19lnnx2bN2+uOGcTJkCAAAECBAgQIECAAAECBAiMJCDcM5KK1wgQIECAAAECBAgQIECA AAECBKKvL6K9PaK+PhfsWb48YseOQZybbrop6urqsqGcqqqqcf1cXV0d1113Xaaz3t7eWLVq VdTW1mb6SKGfFStWRE9Pj5UgQIAAAQIECBAgQIAAAQIECFS0gHBPRS+/yRMgQIAAAQIECBAg QIAAAQIERhZYvz7itNNyoZ758yPWrTuw7Y9+9KOYPXv2uEI9KQQ0ffr0+Jd/+ZcDOtyyZUss XLgw219TU1OsWbPmgHZeIECAAAECBAgQIECAAAECBAhUioBwT6WstHkSIECAAAECBAgQIECA AAECBPIQ6O6OaG3NhXoaGiLa2iL27Bn95J07d2Z23XnBC16QDeWMtotP2q1n+fLl8Zvf/GbU DgcGBjKBnlmzZmX7W7RoUWzdunXUcxwgQIAAAQIECBAgQIAAAQIECJSrgHBPua6seREgQIAA AQIECBAgQIAAAQIExiEwMBCxenXEjBm5YM/ixRHbtuXfycMPP5y5zdYFF1wQJ510UqSwT7pt 14knnhgpnPN3f/d38eCDD+bdYXd3d7S2tkYKBKWwUH19fbS1tcWesZJGefeuIQECBAgQIECA AAECBAgQIECgNASEe0pjnVRJgAABAgQIECBAgAABAgQIEJg0gc2bIxYsyIV6mpoiJupOWGkX nsN9bNiwIZqbm7O7+MybNy/Wrl17uN06nwABAgQIECBAgAABAgQIECBQEgLCPSWxTIokQIAA AQIECBAgQIAAAQIECEy8wO7dEStXRtTWDgZ76uoGn/f0TPxYh9tjX19ftLe3Z3bvGbrl17Jl y2L79u2H27XzCRAgQIAAAQIECBAgQIAAAQJFLSDcU9TLozgCBAgQIECAAAECBAgQIECAwOQI dHZGzJmT262npSVi06bJGWsie+3q6oqlS5dmd/FpbGyMjo6O6O/vn8hh9EWAAAECBAgQIECA AAECBAgQKBoB4Z6iWQqFECBAgAABAgQIECBAgAABAgQmX6CrK2LJklyop7ExoqMjotSyMZ2d nTF37txsyKelpSU2btw4+YBGIECAAAECBAgQIECAAAECBAgUWEC4p8DghiNAgAABAgQIECBA gAABAgQITIVAX19Ee3tEfX0u2LN8ecSOHVNRzcSM2dvbG6tWrYra2tpMyKempiZWrFgRPcV4 X7GJmbJeCBAgQIAAAQIECBAgQIAAgQoUEO6pwEU3ZQIECBAgQIAAAQIECBAgQKCyBNavjzjt tFyoZ/78iHXrysdgy5YtsXDhwuwuPk1NTbFmzZrymaCZECBAgAABAgQIECBAgAABAhUtINxT 0ctv8gQIECBAgAABAgQIECBAgEA5C3R3R7S25kI9DQ0RbW0Re/aU36wHBgYygZ5Zs2ZlQz6L Fi2KrVu3lt9kzYgAAQIECBAgQIAAAQIECBCoKAHhnopabpMlQIAAAQIECBAgQIAAAQIEKkFg YCBi9eqIGTNywZ7FiyO2bSv/2Xd3d0dra2tUV1dnQj719fXR1tYWe8ox0VT+y2mGBAgQIECA AAECBAgQIECAQEQI93gbECBAgAABAgQIECBAgAABAgTKSGDz5ogFC3KhnqamiEq8Q9WGDRui ubk5u4vPvHnzYu3atWW00qZCgAABAgQIECBAgAABAgQIVIqAcE+lrLR5EiBAgAABAgQIECBA gAABAmUtsHt3xMqVEbW1g8GeurrB5z09ZT3tMSfX19cX7e3tkXbvqaqqynwtW7Ystm/fPuZ5 DhIgQIAAAQIECBAgQIAAAQIEiklAuKeYVkMtBAgQIECAAAECBAgQIECAAIFDEOjsjJgzJ7db T0tLxKZNh9BRmZ7S1dUVS5cuzQZ8Ghsbo6OjI/r7+8t0xqZFgAABAgQIECBAgAABAgQIlJOA cE85raa5ECBAgAABAgQIECBAgAABAhUl0NUVsWRJLtTT2BjR0REhszLy26CzszPmzp2bDfm0 tLTExo0bR27sVQIECBAgQIAAAQIECBAgQIBAkQgI9xTJQiiDAAECBAgQIECAAAECBAgQIJCv QF9fRHt7RH19LtizfHnEjh359lC57Xp7e2PVqlVRW1ubCfnU1NTEihUroqeS719WuW8HMydA gAABAgQIECBAgAABAiUhINxTEsukSAIECBAgQIAAAQIECBAgQIDAoMD69RGnnZYL9cyfH7Fu HZ3xCmzZsiUWLlyY3cWnqakp1qxZM95utCdAgAABAgQIECBAgAABAgQITLqAcM+kExuAAAEC BAgQIECAAAECBAgQIHD4At3dEa2tuVBPQ0NEW1vEnj2H33el9jAwMJAJ9MyaNSsb8lm0aFFs 3bq1UknMmwABAgQIECBAgAABAgQIEChCAeGeIlwUJREgQIAAAQIECBAgQIAAAQIEhgQGBiJW r46YMSMX7Fm8OGLbtqEWvh+uQHd3d7S2tkZ1dXUm5FNfXx9tbW2xR3LqcGmdT4AAAQIECBAg QIAAAQIECEyAgHDPBCDqggABAgQIECBAgAABAgQIECAwGQKbN0csWJAL9TQ1Rbhz1GRID/a5 YcOGaG5uzu7iM2/evFi7du3kDahnAgQIECBAgAABAgQIECBAgEAeAsI9eSBpQoAAAQIECBAg QIAAAQIECBAopMDu3RErV0bU1g4Ge+rqBp/39BSyisocq6+vL9rb2yPt3lNVVZX5WrZsWWzf vr0yQcyaAAECBAgQIECAAAECBAgQmHIB4Z4pXwIFECBAgAABAgQIECBAgAABAgRyAp2dEXPm 5HbraWmJ2LQpd9xPhRHo6uqKpUuXZgM+jY2N0dHREf39/YUpwCgECBAgQIAAAQIECBAgQIAA gf8nINzjrUCAAAECBAgQIECAAAECBAgQKAKBrq6IJUtyoZ7GxoiOjghZkqldnM7Ozpg7d242 5NPS0hIbN26c2qKMToAAAQIECBAgQIAAAQIECFSUgHBPRS23yRIgQIAAAQIECBAgQIAAAQLF JtDXF9HeHlFfnwv2LF8esWNHsVVaufX09vbGqlWrora2NhPyqampiRUrVkSP+6RV7pvCzAkQ IECAAAECBAgQIECAQAEFhHsKiG0oAgQIECBAgAABAgQIECBAgMBwgfXrI047LRfqmT8/Yt26 4S38XEwCW7ZsiYULF2Z38Wlqaoo1a9YUU4lqIUCAAAECBAgQIECAAAECBMpQQLinDBfVlAgQ IECAAAECBAgQIECAAIHiFujujmhtzYV6Ghoi2toi9uwp7rpVFzEwMJAJ9MyaNSsb8lm0aFFs 3boVDwECBAgQIECAAAECBAgQIEBgUgSEeyaFVacECBAgQIAAAQIECBAgQIAAgQMFBgYiVq+O mDEjF+xZvDhi27YD23qluAW6u7ujtbU1qqurMyGf+vr6aGtriz0SWsW9cKojQIAAAQIECBAg QIAAAQIlKCDcU4KLpmQCBAgQIECAwEQL9Pb2xtVXXx1XXHFFXHzxxfH6178+zjrrrPjv//2/ T/RQ+iNQvAK33RbR3n5oX3/7t4NX67/znYjt24tjjr29EVdfHXHFFREXXxzx+tdHnHVWhN/r 4lgfVVSkwObNEQsW5EI9TU0R7uhU+m+FDRs2RHNzc3YXn3nz5sXatWtLf2JmQIAAAQIECBAg QIAAAQIECBSNgHBP0SyFQggQIECAAAECUyewY8eOmD59evY/z6uqqjIXqJYuXTp1RRmZQKEF Uujl2GMjjjgid+W9qir3c01NRGNjxHHHHfh15JG5dumc00+P+OY3I/r7Cz2L3Hg7dkQcddS+ daXa/F7njPxEoEACu3dHrFwZUVs7+CtZVzf4vKenQAUYZtIF+vr6or29PdLuPUN/Ry1btiy2 F0vgc9IFDECAAAECBAgQIECAAAECBAhMpoBwz2Tq6psAAQIECBAgUGICTz/9dPzFX/xF9qKU cE+JLaByJ07gF7+IeNGLcsGYefMixroKv3dvxIMPRtx8c8SZZ+bOe8lLIm69deLqOpSennoq 4l3vytUk3HMois4hcMgCnZ0Rc+bkfgVbWiI2bTrk7pxY5AJdXV2R/n4aCvg0NjZGR0dH9E9l 2LPIzZRHgAABAgQIECBAgAABAgQIHFxAuOfgRloQIECAAAECBCpK4Mc//nH2gpRwT0Ut/SFP 9tOf/nRceumlh3x+0Z74hjfkrsZfcEH+Zf7+9xEf+Uju3OrqiC98If/zJ6Plj36Uq0e4ZzKE 9UngAIGuroglS3K/emnjr46Oqd3Q64AivTBpAp2dnTF37tzs31QtLS2xcePGSRtPxwQIECBA gAABAgQIECBAgEB5Cwj3lPf6mh0BAgQIECBAYNwCW7ZsyV6IEu4ZN19FnvDGN74xFi5cWH5z v+ii3FX5QwnEpEDQ0G290j147rln6oy2bMnVcihzmbrKjUyg5AT6+iLa2yPq63O/dsuXR6Q7 5XlUlkBvb2+sWrUqamtrM39b1dTUxIoVK6JnrJ3gKovIbAkQIECAAAECBAgQIECAAIE8BYR7 8oTSjAABAgQIECBQKQL333+/cE+lLPYEzfOMM84Q7hnJ8uc/z13ZTyGftBPQVD3uvz9Xi3DP VK2CcStAYP36iNNOy/26zZ8fsW5dBUzcFMcUSMHpFIIdulVXU1NTrFmzZsxzHCRAgAABAgQI ECBAgAABAgQIDBcQ7hmu4WcCBAgQIECAAIEQ7vEmGI/Ar3/968zFSjv3jKA2MBBx9NG5q/zT p4/QqEAvCfcUCNowlSrQ3R3R2pr7dW9oiGhri9izp1JFzHt/gYGBgUygZ9asWdmQz6JFi2Lr 1q37N/WcAAECBAgQIECAAAECBAgQIHCAgHDPASReIECAAAECBAhUtoBwT2Wv/3hnf+WVVwr3 jIX2whfmrvanW3P194/VevKOCfdMnq2eK1ogZfhWr46YMSP3q754ccS2bRXNYvJjCHR3d0dr a2tUV1dnPj/r6+ujra0t9kiCjaHmEAECBAgQIECAAAECBAgQICDc4z1AgAABAgQIECCwj4Bw zz4cnowh8G//9m8xffp04Z7RjH7969zV/nRbroULR2s5+a8L90y+sREqTmDz5ogFC3K/5k1N Ee60VHFvg0Oe8IYNG6K5uTm7i8+8efNi7dq1h9yfEwkQIECAAAECBAgQIECAAIHyFhDuKe/1 NTsCBAgQIECAwLgFChHu2bt3bzz99NMj1vb73/8+emDAmYsAACAASURBVHt7Rzw23hfTLTB+ +9vfxt133535Sj+n10rxUSizfG1+9rOfxbHHHpu9KDlRt+UqqjW76KLcVfulS/OlybV73/ty 56dde374w9yxfH9K79ff/jbi7rsHv9LPh/IePli4Z+/eiCeemLqdhfL10I5AEQjs3h2xcmVE be3gr3j69U7Pe3qKoDgllJRAX19ftLe3R9q9p6qqKvO1bNmy2L59e0nNQ7EECBAgQIAAAQIE CBAgQIDA5AsI90y+sREIECBAgAABAiUlkE+457nnnos3v/nNcemll8a73vWuuOKKK+Kv/uqv YsWKFfG2t70tfvWrX+0z5z/7sz+Lc889N/Mf6i984QujtrY2hodBHnrooVi5cmWk/1qvq6vL XNw6/vjjM+d8+9vf3qevfJ6k8f/8z/88Zs+enblgduqpp2b6PuKIIzKvpZr3r3F4v+973/vi 7W9/e2Y+f/mXfxkf+MAH4vLLL480j+XLl2cCQ6l9CiG95S1vicsuuyze+973Zgz+x//4H5l2 f/qnfxpr9tvC4cEHH4y3vvWt8c53vjNSu2SW+k793nnnncNLyLxWSLN9Bh/jyerVqzNrPG3a tOyFyHRBsrGxMdIFyf2/kks+j8Nds3zGGHebwwn3fOtbuWBP2rXnS18a3/Dpd+jP/zxi9uyI +vqIU0+NmDcv4ogjBl9717si9vs9G3OAkcI9Tz0V8clPRrzylRHTpg3Wm9IKL3lJxBVXRKRt STwIENhHoLMzYs6c3K93S0vEpk37NPGEwLgFurq6YunSpdnP1fSZ2tHREf1TdSvHcc/ACQQI ECBAgAABAgQIECBAgMBkCwj3TLaw/gkQIECAAAECJSaQb7jnuOOOy16EGvpv86OPPjr+6I/+ KH75y1/uM+uLLrooXvayl0V1dXX2nKFwzze/+c048sgj4/3vf3/cdddd8cQTT8Svf/3ruOaa a7JtL7744n36G+1J+g/4FJZJ4aEUDvrnf/7nSEGkoceePXvi5ptvjvnz52fapEBROmf/x7vf /e541atelQ0aDc1vxowZcd555+0T7nnDG96QmdtQm/Q9zfPMM8+Mr3/96/t0ncI9p59+enZe Q+ek1+6444592hbKbJ9B83iSAlyptvT16le/OjuXmTNnZl8fOp6+J+OxHhO1ZmONccjHDiXc s2tXRAo0DW3p8Qd/EHH77fmXkN6PH/jA4PnHHx/xz/8cMew9HHv2RNx8c8T8+YNtku8I7+ED Btw/3PODH0ScdFLEG94Q8Z3vRDz8cMSzzw4Ghv7n/4w49tiI6uqIt7/ddiQHYHqhEgW6uiKW LMmFehobIzo6bHZVie+FyZxzZ2dnzJ07N/vZ2tLSEhs3bpzMIfVNgAABAgQIECBAgAABAgQI lIiAcE+JLJQyCRAgQIAAAQKFEsgn3JNq+cxnPpO9+NTc3JzZpWakoMzwuteuXZs9J4V7brrp pjjppJPiF7/4xfBm2Z/f8573ZNvfeuut2ddH+iGFeF73utdl2i9atCh27NgxUrPMa88880yk Nilc89rXvjaeTaGGER7/+q//mh0/tb3vvvtGaDX40qpVq7JtP/ShD43aLh246qqrMm2nT58e 3/ve98ZsO5lmYw6cx8Ef/vCH2TkPhbXyOC3bZDLWLNv5RPwwPNyTtuf4P/9n5K8bb4z42Mci 3vzmiHTFP+2C8yd/EvG5zw0GZvKtJYV4Xve6wfTAokURY7yH45lnIlKbtCvQa1978HGGh3uO PDLimGMixtoV66GHIk47bbD/P/zDiN/9Lt9ZaEegrARSdq69fXADrfTrlr6WLx/717OsAEym 4AJpV8D0N0UKKqe/PWpqajI7Cfa471vB18KABAgQIECAAAECBAgQIECgmASEe4ppNdRCgAAB AgQIECgCgXzCPY8++mi8+MUvzlx4Sheg0o44+TxSmGNot5qTTz450u4/d99996inpt1shtq/ 8Y1vHLVdOpBuB5baph1kdu7cOWbbdHDXrl2RduJJ56RbbY32SKGVoRrSLkOjPdKOQ0Pt0q26 xnr85Cc/ybT9+7//+7GaZY5NptlBBz9Ig8MN90zWmh2k7PwPDw/3zJgRsXDh6F8LFkQ0N0cc dVTE2WdH/PVfR/z4x5HZaSffEd/2tsHkwMyZEXm8hyPtEpTqGkobjDXO8HBPTU3E978/VuvB Yw88EFFXN9j/WWcdPEB08B61IFBSAuvX5zJu6dcsbZi1bl1JTUGxJSywZcuWzC1Mh/62aGpq OuB2nyU8PaUTIECAAAECBAgQIECAAAEC4xQQ7hknmOYECBAgQIAAgXIXOFi45957740UzDnx xBPjxym8MM7H0EWq9D3dQmusR7o911D709IuIqM8vvvd72bbpbBRvo+0w85Q/7fddtuIp33t a1/Ltkm35Brtceedd2bbveAFLxgzYPSpT30qZs2alXcoaqjGiTQbbR7jef1wwj2TuWbjmcOY bYeHe5YuHbNp9mDa5uO73x285VVKA5xwQkTa2edgj3ROap++xvEejrRL1NB5o7yHM0MPD/ec csrBqskdv+SSXP/pdl0eBCpAoLs7orU199ZvaIhoaxtfVq8CmEyxAAIDAwOZQE/6m2Hob4G0 8+DWrVsLMLohCBAgQIAAAQIECBAgQIAAgWISEO4pptVQCwECBAgQIECgCATGCvd8+ctfjiOO OCLOP//8ePzxxw+p2qGLU+n7j370ozH72L59e/Zi1tFHHz1q21e+8pXZdilwku9j3bp12fNe 9rKXjXhauj1GGnuo7gfSbiYjPC655JI44YQTsu2uvfbaEVpF7N27NxOOuvLKK0c8PtKLQ2NP pNlI44z3tcMJ90zmmo13HqO2P5Rwz1BnTzwRsWxZLh3w6ldHPPro0NEDv7/ylbm243gPZ7YR GQr3jPIezgw2PNwzb96B44/2yl135epKv4Oj3MJutNO9TqCUBAYGIlavzm2IlX61Fi+O2Lat lGah1nIU6O7ujtbW1qiurs78nVFfXx9tbW15h4TL0cScCBAgQIAAAQIECBAgQIBApQkI91Ta ipsvAQIECBAgQOAgAiOFe5599tm47LLLMheUXvOa10T6T/JDfQwPqjzyyCNjdpOOD7WfPn36 iG1T2GaoTfo+nv9m/9WvfrXPudtGuYL7nve8J9tupJ2B0i2+Uugp3barubk50/YP//APR6x3 6FZjaex8H8PnNxFm+Y57sHaHGu4pxJodrPa8jh9OuCcN0NsbMWdOLhyT3hNPP33g0CkwNhTQ Sd/HsyNDeh8NP3eU93Acargn1VtdnRvjO985sH6vECgDgc2bI9Ld9YZ+nZqaItasKYOJmUJZ CWzYsCH7d0b622DevHmxdu3aspqjyRAgQIAAAQIECBAgQIAAAQIjCwj3jOziVQIECBAgQIBA xQrsH+5JQYyXv/zl2XBLuph08803H7LP8KDK7t27x+wnn3DPTTfdtE9tO3bsGLPP4Qcfe+yx fc5N4ZyRHulWZEN1v+hFL4q+dOulYY9/+Id/iMbGxnjuuefi7//+77Nt70q7nuz3eNvb3hbn nHPOfq+O/XRo7PR9IszGHi3/o4ca7inEmuU/izFaHm64J3X9rW/l0gIpNfBXf3XggDfdtG+b cbyH47HH9j13lPfwIYd7UrVpx56hxEO6N5EHgTISSB9DK1dG1NYOvs3r6gaf9/SU0SRNpawE 0t8g7e3tkXbvGfr7YNmyZZF2O/QgQIAAAQIECBAgQIAAAQIEyldAuKd819bMCBAgQIAAAQKH JDA83DN37tw45phjMmGUr33ta1FTU5O5kHTkkUfGli1bDqn/oQtRExVUSbe/Gt7n0yPtjDJK pant8HPTxbLRHsNvI3Xrrbfu0+z000+P973vfZnX0i4+L3jBCzL9vuMd79in3dCxb3zjG/u8 frAnw2ssh3BPodbsYK4HPT4R4Z60e09NTS4cM2NGxH7hsEi3cBsKz6Tv43gPZ9oOP3e09/Ch 7tyTkNIWJkNjvOc9B2XTgECpCHR27ru5VktLxKZNpVK9OitdoKurK5YuXZr9OyaFjDs6OqK/ v7/SacyfAAECBAgQIECAAAECBAiUpYBwT1kuq0kRIECAAAECBA5dYHi4J4VKrrzyyvj973+f 6fBv/uZvsheRTjrppHj88cfHPdBEB1VWr16drSn1/bvf/S7vmobvDJTO/eIXvzjquV/4whey 4/yX//Jfsu3+7//9v5nXf/azn2VfS7vzpP7Sf9U/8cQT2deHdvhJtzkbz2OizcYz9lht89m5 J11k3P82boVas7Fqz+vYRIR70kCnnpoLx6SQTLoN1/DH6tX7Hh/HezjSre2Ggjfp+2jv4cMJ 98yalRvjqquGV+5nAiUp0NUVsWRJ7m3d2BjR0REhE1GSy1nxRXd2dkYKYw/9rdDS0hIbN26s eBcABAgQIECAAAECBAgQIECg3ASEe8ptRc2HAAECBAgQIHCYAsPDPa2trQf09qd/+qfZC0jn nnvuAbeoOuCE/V4YuviUvk/ELjTDAyapz1/84hf7jTj605///OfZuaRz165dO2rjVGvasSi1 SzsYDd3+4rLLLouzzz57n/OG13Tddddlj51xxhnZHX6yL+bxQxpz6GsizPIYMq8mw+e5cOHC Ec9Jr3/kIx/Z59jw89K8JmvN9hn0UJ5MRLhn796IY4/NpQhSAOf/+//2reaHP9z3+Djew/Hz n+977mjv4UMN9zz3XER1dW6MG27Yt3bPCJSQQNo0K21uVV+fe0svXx4xnjvhldB0lVpBAr29 vbFq1aqora3N/p2yYsWK6HF/uQp6F5gqAQIECBAgQIAAAQIECJS7gHBPua+w+REgQIAAAQIE xikwPNxz+eWXH3D2M888E694xSuyYZN08Wg8j6GQSvo+EUGVvr6+mDlzZrae2267Le9ybr/9 9ux56XYWzz///JjnpiDPUP2f+tSnMvWnwM9XvvKVfc7bu3dvvOQlL8m0felLX5o5ds8992Se D9/hZ5+TxngyNOZEmY0x1LgODQ/pjCfcU8g1G9eE9m88EeGebdtyKYIU7HnRiyIGBvYdKSUO Zs7MtRvHezhuvz13Xtp+ZLT38KGGe+65J9f/tGkRu3btW7tnBEpEYP36iNNOy72d58+PWLeu RIpXJoE8BdItU9Pn8dDfDU1NTbFmzZo8z9aMAAECBAgQIECAAAECBAgQKGYB4Z5iXh21ESBA gAABAgSmQOBg4Z5U0n/8x3/ErFmzshePPv/5z+dd6dAFp4kMqnz84x/P1jKesNEVV1yRPe+j H/3oQecwdAuuVPvJJ58cn/vc52L69Onx9NNPH3DuX//1X2f7TsGed7/73bFgwYID2uXzwmSY 5TPuwdoM9/ijP/qjEZuffvrp8ZnPfOaAY4VaswMGHs8LExHuufjiXJoghXuuuWbkCj7+8Vy7 8QTmrrgid95Y7+FDDfekXZdS3enrL/5i5Nq9SqCIBbq7I9ImdENv44aGiLa2iD17irhopRE4 DIF0K8wU6Bn+d9qiRYti69ath9GrUwkQIECAAAECBAgQIECAAIGpFhDumeoVMD4BAgQIECBA oMgE0n99D4VJ3vOe94xaXdq1Jd2eKrWtq6uLO++8c9S2ww8M9Z2+P/nkk8MPHfBzuvXVUPuj jjrqgONDL6TdhObPn59p29DQEI888sjQoVG/d3d3Z2+zNW/evEh95PNobm7O1jRjxoz4i1EC D48++mjGJdX/1re+NRMC+upXv5rPEAe0GTKYSLMDBjmEFx566KGsxYvSjjT7PdIORmlno1tv vXW/I5HxLtSaHTB4vi+86U25RMDSpfmelWv35S/nzk/JgjPPHH1nnfT+S1uJpHYpfZDHezhS auHIIwfPmTcvoebG3v+n4eGetANPPrf+SjVMnz7Yf1NTxM6d+/fqOYGiFUgbZK1eHTFjRu7X cPHiiLSZlgeBShBIf+ek26tWV1dnPqvr6+ujra0t9ki2VcLymyMBAgQIECBAgAABAgQIlKGA cE8ZLqopESBAgAABAgQOR2D9+vXZwMbFadeRMR5ve9vbsm3TrbE2b948RuvIhHmGB1VSOGSs xy9+8Yts/ylIlG7nNNrjN7/5TaTbT6T+zzzzzDFv+fXUU09lb1tx/PHHR1dX12jdHvD6Zz/7 2WxNaaxNmzYd0GbohTe96U3ZtkcffXT09vYOHcr7ewpATZZZ3kWM0fBlL3tZtr5/+7d/26dl ukVaClulC4wjPQq1ZiONnddr55yTSwUsWpTXKZlGab6XXpo7NwV2XvWqg4djfvObiBSiGQoC 7d49+phPPRWxcOFg2+OPjzjYe3h4uCeNccopkQkHjTZCCt4NzT/d7utnPxutpdcJFJ1A+ihK G6WlX6X0ld7y7kxUdMukoAIJbNiwIYYHk1Ogee3atQUa3TAECBAgQIAAAQIECBAgQIDARAkI 90yUpH4IECBAgAABAiUs8Oyzz8aXv/zlSMGVlpaWbFgj/Zd3ul3V6tWr47777ttnhmmnnj/4 gz/Itk0BlCOOOCIuu+yyzG2YnnjiiWz7G2+8Ma6//vq48MIL92m/ePHiuO666+JrX/tatm3a 7SXV8g//8A9xzjnn7NP+oosuytwK61vf+la2/fAf0o49r33tazPnzJ07N77+9a/vszvQ7t27 44YbboiTTjop0yb1n3YHGs9j586d8YIXvCBz/ite8YoxT7399tuz9Y+1C9JInRTKbKSxx/Na 2ukp3ZosrX/yeOyxxzKnp9u7JeerrrpqzO4KsWZjFjD84A9/GJF22+noiLjkklwyIKUD6usj rr56cCuQtAPT/l/p1nTve1/EeedFpF2mhlIFL35xxA03RPT3Dx9p9J/Tbjmvfe3g+XPnRnz9 6ykVl2ufAj+pv5NOGmyTAjj5vIeHwj3HHTcYMlq+fDDxkH6XhteWtju57bbcLkJnnRWRQkce BEpAIP16rFwZUVs7+OtRVzf4vKenBIpXIoFJFEjh6Pb29kh/1w0FhpctWzbuv4EmsURdEyBA gAABAgQIECBAgAABAgcREO45CJDDBAgQIECAAIFKEEiBjGnTpsUxxxwT6fZKKbST/rP7xBNP jGOPPTZzMeiaa67Zh2LlypWZUEdqf/LJJ2dui/XiF784Zs2alQn5/Pu//3u2fQrapJ190s46 qe2pp56aGeOEE07I9J/GHXr09/dnwjNp3HQ81ZLap/PS89RP+g/00R4pHJRuA3XuuedGbW1t 5iuNm+pMu/+k11Ko59vf/naktofyeMc73pG5OPalL31pzNPTXFLd6UJaCsGM51FIs/HUNVLb tCvAq171qsw8k2+yTnP+4Ac/GMngYI9CrNnBasgcf+tbc6GcoXDOeL+n93LaFedtb4tIobXn n89r6H0apfdlupXZuecOphRSUiFtPZJufVZTM/haCvV8+9sR+b6Hh8I9X/zi4FDpvFTfyScP 3gbs7LMjXve6iJkzI6qrB3cauvHGfYM/+xTpCYHiEujsjJgzJ/cr3NISMcbGasVVvGoIFEgg 7VS4dOnSzGd0+pxubGyMjo6OvD6rC1SiYQgQIECAAAECBAgQIECAAIFRBIR7RoHxMgECBAgQ IECAQOkLpN2D0g5D//RP/5T5Sj8P31HoUGf4n//5n/Hd7353zNuEDfWdLqT9MO0IUwGPdBu1 dCuu73znO6PeiutgDJO1Zgcbt2iPpx2w7rwz4p/+afAr/TxsV6wJqTsFf/7lXyJSmOeOOyJ2 7JiQbnVCoBAC6Y50S5bkQj3pLnJp8608coWFKM8YBIpSoLOzM1KIeGgXn7Rr48aNG4uyVkUR IECAAAECBAgQIECAAAECgwLCPd4JBAgQIECAAAECBAgQIECAQEkJ9PVFtLcP3jFvaIOtdLc5 2bSSWkbFTqFAb29vrFq1KrOjYQr5pN0NV6xYET3uYzeFq2JoAgQIECBAgAABAgQIECAwuoBw z+g2jhAgQIAAAQIECBAgQIAAAQJFJrB+fcRpp+V265k/P2LduiIrUjkESkQg3TZ04cKF2V18 0q1M16xZUyLVK5MAAQIECBAgQIAAAQIECFSOgHBP5ay1mRIgQIAAAQIECBAgQIAAgZIV6O6O aG3NhXoaGiLa2iL27CnZKSmcQFEIDAwMZAI9s2bNyoZ8Fi1aFFu3bi2K+hRBgAABAgQIECBA gAABAgQIRAj3eBcQIECAAAECBAgQIECAAAECRSswMBCxenXEjBm5YM/ixRHbthVtyQojUJIC 3d3d0draGtXV1ZmQT319fbS1tcUeCbqSXE9FEyBAgAABAgQIECBAgEB5CQj3lNd6mg0BAgQI ECBAgAABAgQIECgbgc2bIxYsyIV6mpoi3DGobJbXRIpUYMOGDdHc3JzdxWfevHmxdu3aIq1W WQQIECBAgAABAgQIECBAoDIEhHsqY53NkgABAgQIECBAgAABAgQIlIzA7t0RK1dG1NYOBnvq 6gaf9/SUzBQUSqCkBfr6+qK9vT3S7j1VVVWZr2XLlsX27dtLel6KJ0CAAAECBAgQIECAAAEC pSog3FOqK6duAgQIECBAgAABAgQIECBQhgKdnRFz5uR262lpidi0qQwnakoESkCgq6srli5d mg34NDY2RkdHR/T395dA9UokQIAAAQIECBAgQIAAAQLlIyDcUz5raSYECBAgQIAAAQIECBAg QKBkBbq6IpYsyYV6GhsjOjoiZAhKdkkVXkYCnZ2dMXfu3GzIp6WlJTZu3FhGMzQVAgQIECBA gAABAgQIECBQ3ALCPcW9PqojQIAAAQIECBAgQIAAAQJlLdDXF9HeHlFfnwv2LF8esWNHWU/b 5AiUnEBvb2+sWrUqamtrMyGfmpqaWLFiRfS4X17JraWCCRAgQIAAAQIECBAgQKD0BIR7Sm/N VEyAAAECBAgQIECAAAECBMpCYP36iNNOy4V65s+PWLeuLKZmEgTKVmDLli2xcOHC7C4+TU1N sWbNmrKdr4kRIECAAAECBAgQIECAAIFiEBDuKYZVUAMBAgQIECBAgAABAgQIEKggge7uiNbW XKinoSGirS1iz54KQjBVAiUsMDAwkAn0zJo1KxvyWbRoUWzdurWEZ6V0AgQIECBAgAABAgQI ECBQvALCPcW7NiojQIAAAQIECBAgQIAAAQJlJTAwELF6dcSMGblgz+LFEdu2ldU0TYZAxQh0 d3dHa2trVFdXZ0I+9fX10dbWFnsk9SrmPWCiBAgQIECAAAECBAgQIFAYAeGewjgbhQABAgQI ECBAgAABAgQIVLTA5s0RCxbkQj1NTRHu5FPRbwmTLyOBDRs2RHNzc3YXn3nz5sXatWvLaIam QoAAAQIECBAgQIAAAQIEplZAuGdq/Y1OgAABAgQIECBAgAABAgTKWmD37oiVKyNqaweDPXV1 g897esp62iZHoOIE+vr6or29PdLuPVVVVZmvZcuWxfbt2yvOwoQJECBAgAABAgQIECBAgMBE Cwj3TLSo/ggQIECAAAECBAgQIECAAIGMQGdnxJw5ud16WloiNm2CQ4BAOQt0dXXF0qVLswGf xsbG6OjoiP7+/nKetrkRIECAAAECBAgQIECAAIFJFRDumVRenRMgQIAAAQIECBAgUOkCzz77 bKUTmH8FCnR1RSxZkgv1NDZGdHREuLZfgW8GU65Ygc7Ozpg7d2425NPS0hIbN26sWA8TJ0CA AAECBAgQIECAAAEChyMg3HM4es4lQIAAAQIECBAgQIDAGAI9PT0xc+bMSLclufnmm+P3v//9 GK0dIlD6An19Ee3tEfX1uWDP8uURjz1W+nMzAwIExi/Q29sbq1atitra2kzIp6amJlasWBHp 89GDAAECBAgQIECAAAECBAgQyF9AuCd/Ky0JECBAgAABAgQIECAwLoGvfvWr2R0LqqqqMjsY fOITn4jf/va34+pHYwKlILB+fcRpp+VCPfPnR6xbVwqVq5EAgckW2LJlSyxcuDD7mdjU1BRr 1qyZ7GH1T4AAAQIECBAgQIAAAQIEykZAuKdsltJECBAgQIAAAQIECBAoNoH+/v644447Yvny 5TFt2rTsRc20c8FrXvOaWL16dTzzzDPFVrZ6CIxLoLs7orU1F+ppaIhoa4vYs2dc3WhMgECZ CwwMDGQCPbNmzcp+Hi5atCi2bt1a5jM3PQIECBAgQIAAAQIECBAgcPgCwj2Hb6gHAgQIECBA gAABAgQIHFTg0Ucfjfb29pg3b172ombazWfGjBmZW5T8+Mc/PmgfGhAoJoGBgYjVqyNmzMgF exYvjti2rZiqVAsBAsUm0N3dHa2trVFdXZ35PKyvr4+2trbYIxFYbEulHgIECBAgQIAAAQIE CBAoIgHhniJaDKUQIECAAAECBAgQIFAZAvfee28m0HPUUUftE/Q5/fTTMwGgnTt3VgaEWZas wObNEQsW5EI9TU0R7rBTssupcAJTIrBhw4Zobm7Ofg6m8OvatWunpBaDEiBAgAABAgQIECBA gACBYhcQ7in2FVIfAQIECBAgQIAAAQJlK7B79+743//7f8fZZ5+dvbiZdvNJuxhccsklcffd d5ft3E2sNAV2745YuTKitnYw2FNXN/i8p6c056NqAgSmVqCvry8Tak2fe+nzL30tW7Ystm/f PrWFGZ0AAQIECBAgQIAAAQIECBSZgHBPkS2IcggQIECAAAECBAgQqEyBX/3qV7Fq1aqYPXt2 9gJnuo2XB4FiEejsjJgzJ7dbT0tLxKZNxVKdOggQKGWBrq6uWLp0afbzr7GxMTo6OqK/v7+U p6V2AgQIECBAgAABAgQIECAwYQLCPRNGqSMCBAgQIECAAAECBAgcvsCePXvi5ptvjgsvvDAe ffTRw+9QDwQOU6CrK2LJklyop7ExoqMjwjX3w4R1OgECBwh0dnbG3LlzsyGflpaW2Lhx4wHt vECAAAECBAgQIECAAAECBCpNQLin0lbcfAkQPYnNAQAAIABJREFUIECAAAECBAgQIECAQB4C fX0RafOo+vpcsGf58ojHHsvjZE0IECBwiAK9vb2Znexqa2szIZ+amppYsWJF9Lj/3yGKOo0A AQIECBAgQIAAAQIEykFAuKccVtEcCBAgQIAAAQIECBAgQIDABAqsXx9x2mm5UM/8+RHr1k3g ALoiQIDAQQS2bNkSCxcuzO7i09TUFGvWrDnIWQ4TIECAAAECBAgQIECAAIHyFBDuKc91NSsC BAgQIECAAAECBAgQIDBuge7uiNbWXKinoSGirS1iz55xd+UEAgQIHLbAwMBAJtAza9asbMhn 0aJFsXXr1sPuWwcECBAgQIAAAQIECBAgQKCUBIR7Smm11EqAAAECBAgQIECAAIFxCOzevXsc rTWtZIGBgYjVqyNmzMgFexYvjti2rZJVzJ0AgWIR6O7ujtbW1qiurs6EfOrr66OtrS32SB4W yxKpgwABAgQIECBAgAABAgQmWUC4Z5KBdU+AAAECBAgQIECAAIGpENi1a1cceeSRcf7558fN N98czz///FSUYcwSENi8OWLBglyop6kpwp1vSmDhlEigAgU2bNgQzc3N2V185s2bF2vXrq1A CVMmQIAAAQIECBAgQIAAgUoTEO6ptBU3XwIECBAgQIAAAQIEKkLgS1/6UvbiZ1VVVcyePTs+ +MEPxq9+9auKmL9JHlwgbey0cmVEbe1gsKeubvB5T8/Bz9WCAAECUyXQ19cX7e3tkXbvSZ9v 6WvZsmWxffv2qSrJuAQIECBAgAABAgQIECBAYNIFhHsmndgABAgQIECAAAECBAgQKLzAwMBA 3HHHHZnbmDQ0NGQvgKaLoGeddVasXr06nnrqqcIXZsSiEOjsjJgzJ7dbT0tLxKZNRVGaIggQ IJCXQFdXVyxdujT7+dbY2BgdHR3R39+f1/kaESBAgAABAgQIECBAgACBUhIQ7iml1VIrAQIE CBAgQIAAAQIEDkHgySefzIR5zjzzzOxF0BTySbseLF++PBMC2rt37yH07JRSE+jqiliyJBfq aWyM6OiIcC281FZSvQQIDAl0dnbG3Llzs59vLS0tsXHjxqHDvhMgQIAAAQIECBAgQIAAgbIQ EO4pi2U0CQIECBAgQIAAAQIECOQncO+998bKlStj1qxZ2QuhKehz6qmnZm5z8thjj+XXkVYl JdDXF9HeHlFfnwv2LF8eYblLahkVS4DAKAK9vb2xatWqqK2tzXy21dTUxIoVK6LHfQZHEfMy AQIECBAgQIAAAQIECJSagHBPqa2YegkQIECAAAECBAgQIDABAs8880ysWbMmzjvvvKiurs4G faZNmxYXXXRR3HXXXRMwii6KQWD9+ojTTsuFeubPj1i3rhgqUwMBAgQmVmDLli2xcOHC7Gda U1NT5rNuYkfRGwECBAgQIECAAAECBAgQKLyAcE/hzY1IgAABAgQIECBAgACBohJ4+OGHM7v2 vPjFL85eEL3uuuuKqkbFjF+guzuitTUX6mloiGhri9izZ/x9OYMAAQKlIjAwMJAJ9AzfoW7R okWxdevWUpmCOgkQIECAAAECBAgQIECAwAECwj0HkHiBAAECBAgQIECAAAEClSnQ398ft99+ e7zlLW+JXbt2VSZCGcx6YCBizZqIY4/NBXsWL47Ytq0MJmcKBAgQyFOgu7s7Wltbs7vT1dfX R1tbW+yRcMxTUDMCBAgQIECAAAECBAgQKCYB4Z5iWg21ECBAgAABAgQIECBAgACBwxDYvDli wYJcqKepaTDocxhdOpUAAQIlLbBhw4Zobm7O7kw3b968WLt2bUnPSfEECBAgQIAAAQIECBAg UHkCwj2Vt+ZmTIAAAQIECBAgQIAAAQJlJrB7d8TKlRG1tYPBnrq6wec9PWU2UdMhQIDAIQj0 9fVlbj+Zdu+pqqrKfC1btiy2b99+CL05hQABAgQIECBAgAABAgQIFF5AuKfw5kYkQIAAAQIE CBAgQIAAAQITJtDZGTFnTm63npaWiE2bJqx7HREgQKBsBLq6umLp0qXZgE9jY2N0dHREui2l BwECBAgQIECAAAECBAgQKGYB4Z5iXh21ESBAgAABAgQIECBAoEQFduzYUaKVl07ZXV0RS5bk Qj2NjREdHRGuUZfOGqqUAIGpEejs7Iy5c+dmQz4tLS2xcePGqSnGqAQIECBAgAABAgQIECBA IA8B4Z48kDQhQIAAAQIECBAgQIAAgfwFuru7Y9q0aXHWWWfF6tWro7e3N/+TtTyoQF9fRHt7 RH19LtizfHnEY48d9FQNCBAgQOD/CaTPplWrVkVtbW0m5FNTUxMrVqyIHvcz9B4hQIAAAQIE CBAgQIAAgSIUEO4pwkVREgECBAgQIECAAAECBEpZ4HOf+1x2N4SqqqpItz1573vfG/fee28p T6soal+/PqK5ORfqmT8/Yt26oihNEQQIEChJgS1btsTChQuzn1tNTU2xZs2akpyLogkQIECA AAECBAgQIECgfAWEe8p3bc2MAAECBAgQIECAAAECUyaQgjxpB4Tp06dnL5imoM/pp58e7e3t 8fjjj09ZbaU4cHd3RGtrLtTT0BDR1haxZ08pzkbNBAgQKC6BgYGBTKBn1qxZ2c+sRYsWxdat W4urUNUQIECAAAECBAgQIECAQMUKCPdU7NKbOAECBAgQIECAAAECBCZfIN3eJO2AcP7552cv mKaQzxFHHBHLly+Pzs7O6O/vn/xCSnSEgYGItIHEscfmgj2LF0ds21aiE1I2AQIEilgg3Vay tbU1qqurM59ZDQ0N0dbWFnskKYt41ZRGgAABAgQIECBAgACByhAQ7qmMdTZLAgQIECBAgAAB AgQITLlA2gFh1apVMXv27H2CPieeeGLm9d/85jdTXmMxFbB5c8SCBblQT1PTYNCnmGpUCwEC BMpRYMOGDdHc3Jz9rJo3b16sXbu2HKdqTgQIECBAgAABAgQIECBQIgLCPSWyUMokQIAAAQIE CBAgQIBAuQg8//zzccstt8SFF14YtbW12YunNTU1ccEFF8QPf/jDSZnqG9/4xvjEJz4xKX1P ZKe7d0esXBlRWzsY7KmrG3ze0zORo+iLAAECBMYS6Ovry9xGsr6+Pvs5tWzZsnjkkUfGOs0x AgQIECBAgAABAgQIECAwKQLCPZPCqlMCBAgQIECAAAECBAgQyEfgd7/7Xebi6SmnnJK9ePrl L385n1PH1Sbd+ivdZmVxuqdVET86OyPmzMnt1tPSErFpUxEXrDQCBAiUuUBXV1csXbo0+xnV 2NgYHR0dbilZ5utuegQIECBAgAABAgQIECg2AeGeYlsR9RAgQIAAAQIECBAgQKACBfbu3Rt3 3nlnXHbZZdEzCVvUpN2C0s5A5557blHqdnVFLFmSC/U0NkZ0dET09xdluYoiQIBAxQl0dnbG 3LlzsyGflpaW2LhxY8U5mDABAgQIECBAgAABAgQITI2AcM/UuBuVAAECBAgQIECAAAECBAos kHYHmjlzZqQgUbE8+voi2tsj6utzwZ7lyyMee6xYKlQHAQIECAwJ9Pb2xqpVq7K3lEyh0RUr VkxKKHVoTN8JECBAgAABAgQIECBAgEASEO7xPiBAgAABAgQIECBAgACBihB4xzvekdlx4ac/ /WlRzHf9+ojm5lyoZ/78iHXriqI0RRAgQIDAGAJbtmyJhQsXZnfxaWpqijVr1oxxhkMECBAg QIAAAQIECBAgQODwBIR7Ds/P2QQIECBAgAABAgQIECBQIgLf/va3Mxdir7zyynFVPDAQcc89 EZ//fMTVV0e8//0Rn/50RLqO+/DD4+oq07i7O6K1NRfqaWiIaGuL2LNn/H05gwABAgSmRmBg YCAT6Jk1a1Y25LNo0aLYunXruAt67LHH4sYbb4zPfOYzsXLlyvjoRz8a119/fWzYsCH63Z9x 3J5OIECAAAECBAgQIECAQDkKCPeU46qaEwECBAgQIECAAAECBCpY4D/+4z9GnP2ePXti9uzZ 0djYGOnWKgd77NoV8aEPRRx/fC6IU1W178/V1RFnnRVx000RKQQ01iMdT4GgY4/N9bF4ccS2 bWOd5RgBAgQIFLNAd3d3tLa2RnV1dSbk09DQEG1tbZE+cw72+O53vxuvec1rIt3eq6qqasSv FB5673vfG7/73e8O1p3jBAgQIECAAAECBAgQIFDGAsI9Zby4pkaAAAECBAgQIECAAIFKE0jB nnSR9KyzzoqOjo74z//8z30IrrrqqszF089+9rP7vL7/ky9/OaKxMRfC2T/UM9LzM8+M+OUv 9+9p8PnmzRELFuT6a2oaDPqM3NqrBAgQIFBqAmmXnebm5mxAZ968ebF27doRp/HQQw/Fueee m207WrBn+OtHHnlk/O3f/m3s3bt3xD69SIAAAQIECBAgQIAAAQLlLSDcU97ra3YECBAgQIAA AQIECBCoKIF0G5PhF0OPOuqo+LM/+7P40Y9+lLkg+sQTT8Sxxx4bM2fOPCD4k6DS3U+uuCIX whkpxDPWa8ccE/G97+XId++OWLkyorZ2sM+6usHnPT25Nn4iQIAAgfIQ6Ovri/b29qivr89+ Fi1btiweeeSR7ATvvvvuzC5ywz+rxvPzxRdfHM8991y2Pz8QIECAAAECBAgQIECAQGUICPdU xjqbJQECBAgQIECAAAECBCpG4N///d9j1apVkW5lMvyC6amnnpq5VUo6ll7/ULrn1n6Pv/zL Qw/2DIV+pk2LuOuuiHRbr7RDz9DraeeeLVv2G9BTAgQIECg7gQceeCAuuOCC7GdQCpQ++OCD sXXr1sytIYd/Nh3Kz29961vt4FN27xoTIkCAAAECBAgQIECAwNgCwj1j+zhKgAABAgQIECBA gAABAiUq8Oyzz8Y3v/nNWLRoUVRXV2cvstbV1UVDQ0NMmzYt7rnnnuzs1qzJBXGGAjmH+v34 4yMeeyzi7W8fvL1XR8fgrkDZwfxAgAABAmUv0NnZGXPnzo3zzjsvenp64pRTTsl+Fh1KqGf4 Oddee23Z+5kgAQIECBAgQIAAAQIECOQEhHtyFn4iQIAAAQIECBAgQIAAgTIVePjhhzO3Sjn5 5JMzF1aHbpmSLrru2rUrnn464kUvmrhwTwoFXX55xM6dETt2lCmqaREgQIDAQQV2794d27dv j6uvvnrCgj0p5DN9+vTo7u4+6PgaECBAgAABAgQIECBAgEB5CAj3lMc6mgUBAgQIECBAgAAB AgQIjCHw1FNPxTe+8Y248MILI+3cM7T7QdrR5yc/+Ul8+tMTG+xJ4Z66uoiurjGKcogAAQIE KkJg586dmTDO0GfPRH1///vfXxF+JkmAAAECBAgQIECAAAECEcI93gUECBAgQIAAAQIECBAg ULYCjz32WHzoQx+KY445JhvoecUrXhGf+tSn4nvf+1488sgjmbmfdtrEh3tSwOdv/qZsaU2M AAECBPIU+OpXv5r9DJqoYE/qZ9asWdHf359nFZoRIECAAAECBAgQIECAQCkLCPeU8uqpnQAB AgQIECBAgAABAgRGFEgXO6+99tpsqGf27NnxsY99LH75y18e0P6BByYn2JPCPQsXHjCcFwgQ IECgwgTe9KY3TUq4JwV8fvzjH1eYpukSIECAAAECBAgQIECgMgWEeypz3c2aAAECBAgQIECA AAECZSuwa9euOP/88zMXUo899ti47rrr4rnnnht1vt/+9uSFe446atRhHSBAgACBChF4yUte Mmnhni996UsVomiaBAgQIECAAAECBAgQqGwB4Z7KXn+zJ0CAAAECBAgQIECAQFkJPP/883Hu uedmLqK+4Q1viJ07dx50fp///OSFe9LuPbt3H7QEDQgQIECgjAUaGhomLdxz9dVXl7GcqREg QIAAAQIECBAgQIDAkIBwz5CE7wQIECBAgAABAgQIECBQ8gLf+c53MhdQL7744ti7d29e8/lf /2tywz2PPppXGRoRIECAQBkKpNtE1tTUTFq458orryxDNVMiQIAAAQIECBAgQIAAgf0FhHv2 F/GcAAECBAgQIECAAAECBEpWIO3c861vfWvM23DtP7lvfnPywj21tRH9/fuP6DkBAgQIVJLA 8ccfP2nhnmuvvbaSKM2VAAECBAgQIECAAAECFSsg3FOxS2/iBAgQIECAAAECBAgQIJAEfvSj yQv3vPjFjAkQIECg0gXOPvvsSQv33HLLLZXOa/4ECBAgQIAAAQIECBCoCAHhnopYZpMkQIAA AQIECBAgQIAAgdEE+voiGhsnJ+CzYsVoo3qdAAECBCpF4OMf//ikhHtqa2tj165dlcJongQI ECBAgAABAgQIEKhoAeGeil5+kydAgAABAgQIECBAgACBJHDJJZMT7vne9/gSIECAQKUL3Hvv vZMS7lm8eHGl05o/AQIECBAgQIAAAQIEKkZAuKdiltpECRAgQIAAAQIECBAgQGA0gfvvj6ip mdiAzyteETEwMNqIXidAgACBShJ4/etfP+EBn3Xr1lUSobkSIECAAAECBAgQIECgogWEeyp6 +U2eAAECBAgQIECAAAECBIYE3vGOiQ33uOY6JOs7AQIECNx3332RbqNVVVU1IV8XXHABVAIE CBAgQIAAAQIECBCoIAHhngpabFMlQIAAAQIECBAgQIAAgdEFenoizjhjYgI+H/7w6OM4QoAA AQKVKfB3f/d3ExLsaWpqikceeaQyEc2aAAECBAgQIECAAAECFSog3FOhC2/aBAgQIECAAAEC BAgQIHCgwK9/HXHCCYcX8HnLWyL6+w/s2ysECBAgQODyyy8/rIDPzJkzY9OmTSAJECBAgAAB AgQIECBAoMIEhHsqbMFNlwABAgQIECBAgAABAgRGFvje9yL+8R8jfve7iAULxh/wqa6OWLUq 4tmBPfGh+FDsil0jD+RVAgQIEKg4gWeeeSY++MEPxlNPPRWrV6+Ourq6cYd8Tj311Ni6dWv8 4Ac/iG984xsVZ2jCBAgQIECAAAECBAgQqGQB4Z5KXn1zJ0CAAAECBAgQIECAAIGMwH33RUyf HpECOjfdFNHXF7F6dcTxx+cX8klhoLvuGsRcFsuiKqrinDgnnovnCBMgQIBAhQv09/fHRRdd lAnzvOpVr4r0/Je//GUsX748r4DP9OnTo62tLZ599tm44447Ytq0aZmv9LMHAQIECBAgQIAA AQIECFSGgHBPZayzWRIgQIAAAQIECBAgQIDAKALbt0fMmTMY4pk3L+Lxx3MNe3sjbrkl4h3v iDj99IgZMyJqaiKamiLOPjviIx+J+OlPc+3TT9+P70dd1GUCPstjeQzEwL4NPCNAgACBihJY uXJlJsRTXV0dN9xwwz5z37JlSya485rXvCZOPPHEzI4+KczT3NycCf/ceOON8eSTT2bPSQGf V7/61Zn+jj766Lj//vuzx/xAgAABAgQIECBAgAABAuUrINxTvmtrZgQIECBAgAABAgQIECBw EIGenoiXvWww2HPccREPPniQE/I8/NX4aibck3bwSbfo8iBAgACByhS49tprs7vzXHPNNROC sHPnzki36KqqqooTTjghHn744QnpVycECBAgQIAAAQIECBAgULwCwj3FuzYqI0CAAAECBAgQ IECAAIFJFEi33vqTPxkM9jQ0RNxzz8QO9tH4aDbgc31cP7Gd640AAQIEil7glltuiZqamkwI 513veteE1tvV1RWzZ8/O9H3GGWfss7vPhA6kMwIECBAgQIAAAQIECBAoCgHhnqJYBkUQIECA AAECBAgQIECAQCEF9u6NaG0dDPbU1kbcdtvEj7439sY7452ZgE9N1MStcevED6JHAgQIEChK gY0bN8aRRx6ZCd8sWrQonn/++QmvsxBjTHjROiRAgAABAgQIECBAgACBQxIQ7jkkNicRIECA AAECBAgQIECAQCkLXHXVYLCnqiri+kncVKcv+uL8OD8T8GmIhvhJ/KSU2dROgAABAnkIDN9V 56Uvfemk7qrT2dkZtbW1mRDRpZdeGntTetWDAAECBAgQIECAAAECBMpOQLin7JbUhAgQIECA AAECBAgQIEBgLIGvfCUX7Pnwh8dqOTHHeqInXh4vzwR8jovj4oF4YGI61gsBAgQIFJ3Azp07 Y/78+ZmwzQknnBAPP/zwpNf42c9+NjNeVVVVfPKTn5z08QxAgAABAgQIECBAgAABAoUXEO4p vLkRCRAgQIAAAQIECBAgQGCKBL7//Yi6usFwz/LlEQMDhSnkkXgk5sScTMDnlDglHo/HCzOw UQgQIECgYALPPvts/PEf/3EmaHPMMcfE/fffX7CxP/CBD2TGra6ujhtuuKFg4xqIAAECBAgQ IECAAAECBAojINxTGGejECBAgAABAgQIECBAgMAUC9x3X8T06YPBnnPPjXjuucIWdF/cF9Nj eibgc06cE89FgQso7HSNRoAAgYoSGBgYiP/23/5bJmAzbdq0WLduXUHnv//4a9euLej4BiNA gAABAgQIECBAgACByRUQ7plcX70TIECAAAECBAgQIECAQBEIbN8eMWfOYLBn3ryIx6do45zv x/ejLuoyAZ/lsTwGokBbBxXBGiiBAAEC5SywcuXKKd85J+0c9OpXvzpTx9FHH13QnYPKeW3N jQABAgQIECBAgAABAsUgINxTDKugBgIECBAgQIAAAQIECBCYNIGenoiXvWww2HPccREPPjhp Q+XV8Vfjq5lwT1VUxYfiQ3mdoxEBAgQIFK/AtddemwnUVFVVxTXXXDOlhe7cuTNOPfXUTD0n nHBCPPzww1Naj8EJECBAgAABAgQIECBAYGIEhHsmxlEvBAgQIECAAAECBAgQIFCEAn19EX/y J4PBnoaGiHvuKY4iPxofzQZ8ro/ri6MoVRAgQIDAuAVuueWWqKmpyYRp3vWud437/Mk4oaur K2bPnp2p6Ywzzognn3xyMobRJwECBAgQIECAAAECBAgUUEC4p4DYhiJAgAABAgQIECBAgACB wgns3RvR2joY7KmtjbjttsKNfbCR9sbeeGe8MxPwqYmauDVuPdgpjhMgQIBAkQls3Lgxjjzy yEyIZtGiRfH8888XTYXFXFvRICmEAAECBAgQIECAAAECJSQg3FNCi6VUAgQIECBAgAABAgQI EMhf4KqrBoM9VVUR1xfh5jh90Rfnx/mZgE9DNMRP4if5T05LAgQIEJhSgeG747z0pS8tyt1x Ojs7o7a2NhM+uvTSS2NvSr16ECBAgAABAgQIECBAgEBJCgj3lOSyKZoAAQIECBAgQIAAAQIE xhL4yldywZ4Pf3isllN7rCd64uXx8kzA57g4Lh6IB6a2IKMTIECAwEEFdu7cGfPnz8+EZk44 4YR4+OGHD3rOVDX47Gc/m6mzqqoqPvnJT05VGcYlQIAAAQIECBAgQIAAgcMUEO45TECnEyBA gAABAgQIECBAgEBxCXz/+xF1dYPhnuXLIwYGiqu+/at5JB6JOTEnE/A5JU6Jx+Px/Zt4ToAA AQJFIvDss8/GH//xH2cCM8ccc0zcf//9RVLZ6GV84AMfyNRbXV0dN9xww+gNHSFAgAABAgQI ECBAgACB/5+9uwGPq6r3PT7JJG0TkkIhhjYNIDYNhb6gBw7Q0CI5LQIKCNGAltOKyCMvRxr0 0mr7qKR49SI04Im8aQs5CiJcoKX1mJqqvKktRQJR8OJpQ5VJgZKAIaUkJGXmd5+1xpm8NJPM TPZk9sx8hycmM3ut//6vz540eZ78XNu1AoR7XHtpaAwBBBBAAAEEEEAAAQQQQCBWgeZmqaAg GOxZuFDq6Ym1QnLGN6tZBSqwAZ8FWqAepUjjyeHirAgggEBSBPx+v6qqqmxQJjc3V1u3bk1K H7GedGjfTU1NsZZgPAIIIIAAAggggAACCCCAQJIFCPck+QJwegQQQAABBBBAAAEEEEAAAWcE 2tqk0tJgsKesTGpPsQ1wGtWoHOXYgE+1quWXy7cccuayUQUBBBBIGYHly5en7A44ZsehiooK 239hYWFK7DiUMm8MGkUAAQQQQAABBBBAAAEExkGAcM84IHMKBBBAAAEEEEAAAQQQQACBxAp0 dUlz5waDPUVF0q5diT1foqqv13ob7vHIoxVakajTUBcBBBBAIEaBtWvX2mCMx+PRmjVrYpzt juEdHR0qLy+36ygpKZHP53NHY3SBAAIIIIAAAggggAACCCAwqgDhnlGJGIAAAggggAACCCCA AAIIIOBmgb4+adGiYLAnL0/avt3N3Y7e22qtDgd86lU/+gRGIIAAAggkVODhhx9Wdna2DcVc fvnlCT1Xoou3traquLjYrmX27Nnq7OxM9CmpjwACCCCAAAIIIIAAAggg4IAA4R4HECmBAAII IIAAAggggAACCCCQHIFAQFq6NBjs8XqljRuT04eTZw0ooGVaZgM+2crWBm1wsjy1EEAAAQRi ENixY4fy8/NtGKayslK9vb0xzHbn0HRckzul6QoBBBBAAAEEEEAAAQQQcE6AcI9zllRCAAEE EEAAAQQQQAABBBAYZ4FVq4LBHo9Hqk+jTW761KfFWmwDPnnK0zZtG2dZTocAAgggMHCXmzlz 5qTVLjebN2+W1+u1oaUlS5YoYNKyPBBAAAEEEEAAAQQQQAABBFwrQLjHtZeGxhBAAAEEEEAA AQQQQAABBEYSWLeuP9izcuVII1PzWJe6NE/zbMCnSEXaqZ2puRC6RgABBFJQoKOjQzNnzrTh l5KSEvl8vhRcxcgt19XV2fV5PB7V1taOPJijCCCAAAIIIIAAAggggAACSRUg3JNUfk6OAAII IIAAAggggAACCCAQj0Bjo5STEwz3VFdLfn88Vdw/Z4/2qFSlNuAzQzPUrnb3N02HCCCAQIoL dHd3a/78+Tb4MnnyZLW0tKT4iiK3X1NTY9eZlZWlhoaGyAM5ggACCCCAAAIIIIAAAgggkFQB wj1J5efkCCCAAAIIIIAAAggggAACsQqT/Io8AAAgAElEQVQ0N0sFBcFgz8KFUk9PrBVSa3yz mlWgAhvwWaAF6lGaLzi1Lg/dIoBAmgn4/X5VVVXZwEtubq62bt2aZiscvJyh621qaho8gGcI IIAAAggggAACCCCAAAKuECDc44rLQBMIIIAAAggggAACCCCAAALRCLS1SaWlwWBPWZnUniEb 2TSqUTnKsQGfalXLrzTdqiiaNwFjEEAAgQQKLF++PON2sjE7FVVUVNh1FxYWpvVORQl861Aa AQQQQAABBBBAAAEEEEioAOGehPJSHAEEEEAAAQQQQAABBBBAwCmBri5p7txgsKeoSNq1y6nK qVFnvdbbcI9HHq3QitRomi4RQACBFBJYu3atDbh4PB6tWbMmhTofe6sdHR0qLy+36y8pKZHP 5xt7USoggAACCCCAAAIIIIAAAgg4JkC4xzFKCiGAAAIIIIAAAggggAACCCRKoK9PWrQoGOzJ y5O2b0/Umdxdd7VWhwM+9ap3d7N0hwACCKSQwMMPP6zs7Gwbbrn88stTqHPnWm1tbVVxcbE1 mD17tjo7O50rTiUEEEAAAQQQQAABBBBAAIExCRDuGRMfkxFAAAEEEEAAAQQQQAABBBItEAhI S5cGgz1er7RxY6LP6N76AQW0TMtswCdb2dqgDe5tls4QQACBFBHYsWOH8vPzbailsrJSvb29 KdK5821i4bwpFRFAAAEEEEAAAQQQQAABJwQI9zihSA0EEEAAAQQQQAABBBBAAIGECaxaFQz2 eDxSPZvVqE99WqzFNuCTpzxt07aE2VMYAQQQSHeBgbvVzJkzh91qJG3evFler9eGnZYsWaKA SdnyQAABBBBAAAEEEEAAAQQQSKoA4Z6k8nNyBBBAAAEEEEAAAQQQQACBkQTWresP9qxcOdLI zDrWpS7N0zwb8ClSkXZqZ2YBsFoEEEDAAYGOjg7NnDnThlhKSkrk8/kcqJoeJerq6qyLx+NR bW1teiyKVSCAAAIIIIAAAggggAACKSxAuCeFLx6tI4AAAggggAACCCCAAALpLNDYKOXkBMM9 1dWS35/Oq419bXu0R6UqtQGfGZqhdrXHXoQZCCCAQIYKdHd3a/78+TbAMnnyZLW0tGSoRORl 19TUWJ+srCw1NDREHsgRBBBAAAEEEEAAAQQQQACBhAsQ7kk4MSdAAAEEEEAAAQQQQAABBBCI VaC5WSooCAZ7Fi6UenpirZAZ45vVrAIV2IDPAi1Qj4DKjCvPKhFAYCwCfr9fVVVVNriSm5ur rVu3jqVc2s4d6tTU1JS2a2VhCCCAAAIIIIAAAggggIDbBQj3uP0K0R8CCCCAAAIIIIAAAggg kGECbW1SaWkw2FNWJrWzIc2I74BGNSpHOTbgU61q+cUWRyOCcRABBDJeYPny5exIE+W7wOxw VFFRYb0KCwvZ4ShKN4YhgAACCCCAAAIIIIAAAk4LEO5xWpR6CCCAAAIIIIAAAggggAACcQt0 dUlz5waDPUVF0q5dcZfKqInrtd6GezzyaIVWZNTaWSwCCCAQi8DatWttUMXj8WjNmjWxTM3Y sR0dHSovL7duJSUl8vl8GWvBwhFAAAEEEEAAAQQQQACBZAkQ7kmWPOdFAAEEEEAAAQQQQAAB BBAYJNDXJy1aFAz25OVJ27cPOsyTUQRWa3U44FOv+lFGcxgBBBDIPIGHH35Y2dnZNqRy6aWX KhAIZB5CnCtubW1VcXGxtZs9e7Y6OzvjrMQ0BBBAAAEEEEAAAQQQQACBeAQI98SjxhwEEEAA AQQQQAABBBBAAAFHBczfV5cuDQZ7vF5p40ZHy2dEsYACWqZlNuCTrWxt0IaMWDeLRAABBKIR 2LFjh/Lz8204pbKyUr29vdFMY8wAAQwHYPAlAggggAACCCCAAAIIIDDOAoR7xhmc0yGAAAII IIAAAggggAACCBwssGpVMNjj8Uj1bDpzMFCUr/SpT4u12AZ88pSnbdoW5UyGIYAAAukrMHDX mTlz5rDrzBgu9ebNm+X1em1IasmSJex+NAZLpiKAAAIIIIAAAggggAACsQgQ7olFi7EIIIAA AggggAACCCCAAAKOC6xb1x/sWbnS8fIZV7BLXZqneTbgU6Qi7dTOjDNgwQgggEBIoKOjQzNn zrRhlJKSEvl8vtAhPscpUFdXZz09Ho9qa2vjrMI0BBBAAAEEEEAAAQQQQACBWAQI98SixVgE EEAAAQQQQAABBBBAAAFHBRobpZycYLinulry+x0tn7HF9miPSlVqAz4zNEPtas9YCxaOAAKZ K9Dd3a358+fbIMrkyZPV0tKSuRgOr7ympsa6ZmVlqaGhweHqlEMAAQQQQAABBBBAAAEEEBgq QLhnqAjPEUAAAQQQQAABBBBAAAEExkWguVkqKAgGexYulHp6xuW0GXOSZjWrQAU24LNAC9Qj gDPm4rNQBBCQ3+9XVVWVDaDk5uZq69atqDgoMNS3qanJweqUQgABBBBAAAEEEEAAAQQQGCpA uGeoCM8RQAABBBBAAAEEEEAAAQQSLtDWJpWWBoM9ZWVSOxvLJMS8UY3KUY4N+FSrWn6xNVJC oCmKAAKuE1i+fDk7yyT4qpidkSoqKqxzYWEhOyMl2JvyCCCAAAIIIIAAAgggkNkChHsy+/qz egQQQAABBBBAAAEEEEBg3AW6uqS5c4PBnqIiadeucW8ho064XuttuMcjj1ZoRUatncUigEBm Cqxdu9YGTjwej9asWZOZCOO06o6ODpWXl1vvkpIS+Xy+cTozp0EAAQQQQAABBBBAAAEEMkuA cE9mXW9WiwACCCCAAAIIIIAAAggkVaCvT1q0KBjsycuTtm9PajsZc/LVWh0O+NSrPmPWzUIR QCDzBB5++GFlZ2fbsMmSJUsUCAQyD2GcV9za2qri4mJrPnv2bHV2do5zB5wOAQQQQAABBBBA AAEEEEh/AcI96X+NWSECCCCAAAIIIIAAAggg4AoB8/fVpUuDwR6vV9q40RVtZUQTAQW0TMts wCdb2dqgDRmxbhaJAAKZJbBjxw7l5+fbkEllZaV6e3szCyCJq8U+ificGgEEEEAAAQQQQAAB BDJCgHBPRlxmFokAAggggAACCCCAAAIIJF9g1apgsMfjkerZPGbcL0if+rRYi23AJ0952qZt 494DJ0QAAQQSJcDuMYmSjb7u5s2b5fV62TUpejJGIoAAAggggAACCCCAAAJRCxDuiZqKgQgg gAACCCCAAAIIIIAAAvEKrFvXH+xZuTLeKswbq0CXujRP82zAp0hF2qmdYy3JfAQQQCDpAh0d HZo5c6YNlZSUlMjn8yW9p0xtoK6uzl4Hj8ej2traTGVg3QgggAACCCCAAAIIIICA4wKEexwn pSACCCCAAAIIIIAAAggggMBAgcZGKScnGO6prpb8/oFH+Xq8BfZoj0pVagM+MzRD7Wof7xY4 HwIIIOCYQHd3t+bPn28DJYWFhWppaXGsNoXiE6ipqbHXIysrSw0NDfEVYRYCCCCAAAIIIIAA AggggMAgAcI9gzh4ggACCCCAAAIIIIAAAggg4KRAc7NUUBAM9ixcKPX0OFmdWvEKNKtZBSqw AZ8FWqAecWHitWQeAggkT8Dv96uqqsoGSXJzc9XU1JS8ZjhzWIDrEqbgCwQQQAABBBBAAAEE EEDAMQHCPY5RUggBBBBAAAEEEEAAAQQQQGCgQFubVFoaDPaUlUntbBAzkCfpXzeqUTnKsQGf alXLL7ZUSvpFoQEEEIhJYPny5ewQE5PY+A02OypVVFSwo9L4kXMmBBBAAAEEEEAAAQQQSHMB wj1pfoFZHgIIIIAAAggggAACCCCQDIGuLmnu3GCwp6hI2rUrGV1wztEE1mu9Dfd45NEKrRht OMcRQAAB1wisXbvWBkc8Ho9qa2td0xeN9At0dHSovLzcXqeSkhL5fL7+g3yFAAIIIIAAAggg gAACCCAQkwDhnpi4GIwAAggggAACCCCAAAIIIDCaQF+ftGhRMNiTlydt3z7aDI4nU2C1VocD PvWqT2YrnBsBBBCISuDhhx9Wdna2DY0sWbJEgUAgqnkMGn+B1tZWFRcX22s1e/ZsdXZ2jn8T nBEBBBBAAAEEEEAAAQQQSAMBwj1pcBFZAgIIIIAAAggggAACCCDgFgHz99WlS4PBHq9X2rjR LZ3RRySBgAJapmU24JOtbG3QhkhDeR0BBBBIusCOHTuUn59vwyKVlZXq7e1Nek80MLIA12xk H44igAACCCCAAAIIIIAAAtEIEO6JRokxCCCAAAIIIIAAAggggAACUQmsWhUM9ng8Uj2bwERl 5oZBferTYi22AZ885WmbtrmhLXpAAAEEBgmwC8wgjpR6snnzZnm9XnZbSqmrRrMIIIAAAggg gAACCCDgJgHCPW66GvSCAAIIIIAAAggggAACCKSwwLp1/cGelStTeCEZ2nqXujRP82zAp0hF 2qmdGSrBshFAwI0CHR0dmjlzpg2HlJSUyOfzubFNehpBoK6uzl4/j8ej2traEUZyCAEEEEAA AQQQQAABBBBAYKgA4Z6hIjxHAAEEEEAAAQQQQAABBBCIWaCxUcrJCYZ7qqslvz/mEkxwgcAe 7VGpSm3AZ4ZmqF3tLuiKFhBAINMFuru7NX/+fBsMKSwsVEtLS6aTpOz6a2pq7HXMyspSQ0ND yq6DxhFAAAEEEEAAAQQQQACB8RYg3DPe4pwPAQQQQAABBBBAAAEEEEgzgeZmqaAgGOxZuFDq 6UmzBWbYcprVrAIV2IDPAi1Qj7igGfYWYLkIuErA7/erqqrKBkJyc3PV1NTkqv5oJjYBrmds XoxGAAEEEEAAAQQQQAABBEIChHtCEnxGAAEEEEAAAQQQQAABBBCIWaCtTSotDQZ7ysqkdjZ6 idnQjRMa1agc5diAT7Wq5RdbMbnxOtETApkgsHz5cnZ6SbMLbXZiqqioYCemNLuuLAcBBBBA AAEEEEAAAQQSK0C4J7G+VEcAAQQQQAABBBBAAAEE0lagq0uaOzcY7CkqknbtStulZuTC1mu9 Dfd45NEKrchIAxaNAALJFVi7dq0NgHg8HtXW1ia3Gc7uqEBHR4fKy8vt9S0pKZHP53O0PsUQ QAABBBBAAAEEEEAAgXQTINyTbleU9SCAAAIIIIAAAggggAAC4yDQ1yctWhQM9uTlSdu3j8NJ OcW4C6zW6nDAp171435+TogAApkr8PDDDys7O9uGP5YsWaJAIJC5GGm68tbWVhUXF9trPHv2 bHV2dqbpSlkWAggggAACCCCAAAIIIDB2AcI9YzekAgIIIIAAAggggAACCCCQUQLm76tLlwaD PV6vtHFjRi0/oxYbUEDLtMwGfLKVrQ3akFHrZ7EIIJAcgR07dig/P9+GPiorK9Xb25ucRjhr wgW41gkn5gQIIIAAAggggAACCCCQJgKEe9LkQrIMBBBAAAEEEEAAAQQQQGC8BFatCgZ7PB6p ns1cxos9aefpU58Wa7EN+OQpT9u0LWm9cGIEEEh/AXZzSf9rPHSFmzdvltfrZZemoTA8RwAB BBBAAAEEEEAAAQQGCBDuGYDBlwgggAACCCCAAAIIIIAAAiMLrFvXH+xZuXLksRxNH4EudWme 5tmAT5GKtFM702dxrAQBBFwj0NHRoZkzZ9qQR0lJiXw+n2t6o5HECtTV1dnr7vF4VFtbm9iT UR0BBBBAAAEEEEAAAQQQSEEBwj0peNFoGQEEEEAAAQQQQAABBBBIhkBjo5STEwz3VFdLfn8y uuCcyRLYoz0qVakN+MzQDLWrPVmtcF4EEEhDge7ubs2fP98GPAoLC9XS0pKGq2RJIwnU1NTY 65+VlaWGhoaRhnIMAQQQQAABBBBAAAEEEMg4AcI9GXfJWTACCCCAAAIIIIAAAgggELtAc7NU UBAM9ixcKPX0xF6DGakv0KxmFajABnwWaIF6xBsh9a8qK0Ag+QJ+v19VVVU22JGbm6umpqbk N0UH4y7A+2DcyTkhAggggAACCCCAAAIIpJAA4Z4Uuli0igACCCCAAAIIIIAAAggkQ6CtTSot DQZ7ysqkdjZsScZlcM05G9WoHOXYgE+1quUXWzi55uLQCAIpKrB8+XJ2bEnRa+d022YHp4qK CnZwchqWeggggAACCCCAAAIIIJDyAoR7Uv4SsgAEEEAAAQQQQAABBBBAIHECXV3S3LnBYE9R kbRrV+LOReXUEViv9Tbc45FHK7QidRqnUwQQcJ3A2rVrbZDD4/GotrbWdf3R0PgLdHR0qLy8 3L4vSkpK5PP5xr8JzogAAggggAACCCCAAAIIuEyAcI/LLgjtIIAAAggggAACCCCAAAJuEejr kxYtCgZ78vKk7dvd0hl9uEFgtVaHAz71qndDS/SAAAIpJrBp0yZ5vV4b4liyZIkCgUCKrYB2 EyXQ2tqq4uJi+96YPXu2Ojs7E3Uq6iKAAAIIIIAAAggggAACKSFAuCclLhNNIoAAAggggAAC CCCAAALjK2D+vrp0aTDY4/VKGzeO7/k5m/sFAgpomZbZgE+2srVBG9zfNB0igIBrBHbs2KH8 /Hwb3qisrFRvb69reqMRdwjwHnHHdaALBBBAAAEEEEAAAQQQcIcA4R53XAe6QAABBBBAAAEE EEAAAQRcJbBqVTDY4/FI9WzK4qpr46Zm+tSnxVpsAz55ytM2bXNTe/SCAAIuFWBXFpdeGBe2 tXnzZnZ3cuF1oSUEEEAAAQQQQAABBBAYfwHCPeNvzhkRQAABBBBAAAEEEEAAAVcLrFvXH+xZ udLVrdKcCwS61KV5mmcDPkUq0k7tdEFXtIAAAm4V6Ojo0MyZM+2OPSUlJfL5fG5tlb5cIlBX V2ffLx6PR7W1tS7pijYQQAABBBBAAAEEEEAAgfEVINwzvt6cDQEEEEAAAQQQQAABBBBwtUBj o5STEwz3VFdLfr+r26U5lwjs0R6VqtQGfGZohtrV7pLOaAMBBNwk0N3drfnz59ugRmFhoVpa WtzUHr24WKCmpsa+b7KystTQ0ODiTmkNAQQQQAABBBBAAAEEEEiMAOGexLhSFQEEEEAAAQQQ QAABBBBIOYHmZqmgIBjsWbhQ6ulJuSXQcBIFmtWsAhXYgM+pOlXv6b0kdsOpEUDAbQJ+v19V VVU2oJGbm6umpia3tUg/Lhbg/ePii0NrCCCAAAIIIIAAAgggMC4ChHvGhZmTIIAAAggggAAC CCCAAALuFmhrk0pLg8GesjKpnY1X3H3BXNpdoxqVoxwb8KlWtfxi6yeXXiraQmDcBZYvX87O K+Ounl4nNDs/VVRUsPNTel1WVoMAAggggAACCCCAAAJRChDuiRKKYQgggAACCCCAAAIIIIBA ugp0dUlz5waDPUVF0q5d6bpS1jUeAuu13oZ7PPJohVaMxyk5BwIIuFxg7dq1NpDh8XhUW1vr 8m5pz80CHR0dKi8vt++nkpIS+Xw+N7dLbwgggAACCCCAAAIIIICAYwKEexyjpBACCCCAAAII IIAAAgggkHoCfX3SokXBYE9enrR9e+qtgY7dJ7Baq8MBn3rVu69BOkIAgXET2LRpk7xerw1j LFmyRIFAYNzOzYnSU6C1tVXFxcX2PTV79mx1dnam50JZFQIIIIAAAggggAACCCAwQIBwzwAM vkQAAQQQQAABBBBAAAEEMknA/H116dJgsMfrlTZuzKTVs9ZECgQU0DItswGfbGVrgzYk8nTU RgABlwrs2LFD+fn5NoRRWVmp3t5el3ZKW6kmwHsr1a4Y/SKAAAIIIIAAAggggMBYBQj3jFWQ +QgggAACCCCAAAIIIIBAigqsWhUM9ng8Uj2bq6ToVXRv233q02IttgGfPOVpm7a5t1k6QwAB xwXYXcVxUgoOEdi8eTO7Qg0x4SkCCCCAAAIIIIAAAgikrwDhnvS9tqwMAQQQQAABBBBAAAEE EIgosG5df7Bn5cqIwziAwJgEutSleZpnAz5FKtJO7RxTPSYjgEBqCHR0dGjmzJl2x56SkhL5 fL7UaJwuU06grq7Ovs88Ho9qa2tTrn8aRgABBBBAAAEEEEAAAQSiFSDcE60U4xBAAAEEEEAA AQQQQACBNBFobJRycoLhnupqye9Pk4WxDFcK7NEelarUBnxmaIba1e7KPmkKAQScEeju7tb8 +fNt4KKwsFAtLS3OFKYKAhEEampq7PstKytLDQ0NEUbxMgIIIIAAAggggAACCCCQ2gKEe1L7 +tE9AggggAACCCCAAAIIIBCTQHOzVFAQDPYsXCj19MQ0ncEIxCXQrGYVqMAGfE7VqXpP78VV h0kIIOBuAb/fr6qqKhu0yM3NVVNTk7sbpru0EOB9lxaXkUUggAACCCCAAAIIIIDAKAKEe0YB 4jACCCCAAAIIIIAAAgggkC4CbW1SaWkw2FNWJrWzgUq6XNqUWEejGpWjHBvwqVa1/GLLqJS4 cDSJQAwCy5cvZweVGLwY6pyA2TGqoqKCHaOcI6USAggggAACCCCAAAIIuEyAcI/LLgjtIIAA AggggAACCCCAAAKJEOjqkubODQZ7ioqkXbsScRZqIjCywHqtt+EejzxaoRUjD+YoAgiklMDa tWttsMLj8ai2tjaleqfZ9BDo6OhQeXm5fR+WlJTI5/Olx8JYBQIIIIAAAggggAACCCAgiXAP bwMEEEAAAQQQQAABBBBAIM0F+vqkRYuCwZ68PGn79jRfMMtztcBqrQ4HfOpV7+peaQ4BBKIT 2LRpk7xerw1VLFmyRIFAILqJjELAYYHW1lYVFxfb9+Ls2bPV2dnp8BkohwACCCCAAAIIIIAA AggkR4BwT3LcOSsCCCCAAAIIIIAAAgggMC4C5u+rS5cGgz1er7Rx47iclpMgEFEgoICWaZkN +GQrWxu0IeJYDiCAgPsFduzYofz8fBumqKysVG9vr/ubpsO0FuA9mdaXl8UhgAACCCCAAAII IJCxAoR7MvbSs3AEEEAAAQQQQAABBBDIBIFVq4LBHo9HqmeTlEy45Cmxxj71abEW24BPnvK0 TdtSom+aRACBwQLskjLYg2fuEdi8eTO7SbnnctAJAggggAACCCCAAAIIOCBAuMcBREoggAAC CCCAAAIIIIAAAm4UWLeuP9izcqUbO6SnTBboUpfmaZ4N+BSpSDu1M5M5WDsCKSfQ0dGh8vJy u2NPSUmJfD5fyq2BhtNboK6uzr4/PR6Pamtr03uxrA4BBBBAAAEEEEAAAQTSXoBwT9pfYhaI AAIIIIAAAggggAACmSjQ2Cjl5ATDPdXVkt+fiQqs2e0Ce7RHpSq1AZ8ZmqF2tbu9ZfpDAAFJ 3d3dqqiosMGJwsJCtbS04IKAKwVqamrs+zQrK0sNDQ2u7JGmEEAAAQQQQAABBBBAAIFoBAj3 RKPEGAQQQAABBBBAAAEEEEAghQSam6WCgmCwZ+FCqacnhZqn1YwTaFazClRgAz6n6lS9p/cy zoAFI5BKAn6/X1VVVTYwkZubq6amplRqn14zTID3a4ZdcJaLAAIIIIAAAggggEAaCxDuSeOL y9IQQAABBBBAAAEEEEAg8wTa2qTS0mCwp6xMamcjlMx7E6TgihvVqBzl2IBPtarlF1tNpeBl pOUMEWAnlAy50Gm0THaaSqOLyVIQQAABBBBAAAEEEMhgAcI9GXzxWToCCCCAAAIIIIAAAgik l0BXlzR3bjDYU1Qk7dqVXutjNektsF7rbbjHI49WaEV6L5bVIZCiAnV1dXbHHo/Ho9ra2hRd BW1nokBHR4fKy8vt+7ekpEQ+ny8TGVgzAggggAACCCCAAAIIpLAA4Z4Uvni0jgACCCCAAAII IIAAAgiEBPr6pEWLgsGevDxp+/bQET4jkDoCq7U6HPCpV33qNE6nCGSAwObNm+X1em04YsmS JQoEAhmwapaYTgKtra0qLi627+HZs2ers7MznZbHWhBAAAEEEEAAAQQQQCDNBQj3pPkFZnkI IIAAAggggAACCCCQ/gLm76tLlwaDPV6vtHFj+q+ZFaanQEABLdMyG/DJVrY2aEN6LpRVIZBi Ajt27FB+fr4NRVRWVqq3tzfFVkC7CAQFeC/zTkAAAQQQQAABBBBAAIFUFSDck6pXjr4RQAAB BBBAAAEEEEAAgX8KrFoVDPZ4PFI9m53wvkhxgT71abEW24BPnvK0TdtSfEW0j0BqC7DbSWpf P7o/WIBdqA424RUEEEAAAQQQQAABBBBwvwDhHvdfIzpEAAEEEEAAAQQQQAABBCIKrFvXH+xZ uTLiMA4gkFICXerSPM2zAZ8iFWmndqZU/zSLQLoIdHR0qLy83O7YU1JSIp/Ply5LYx0ZLlBX V2ff1x6PR7W1tRmuwfIRQAABBBBAAAEEEEAgFQQI96TCVaJHBBBAAAEEEEAAAQQQQGAYgcZG KScnGO6prpb8/mEG8RICKSqwR3tUqlIb8JmhGWpXe4quhLYRSE2B7u5uVVRU2ABEYWGhWlpa UnMhdI1ABIGamhr7/s7KylJDQ0OEUbyMAAIIIIAAAggggAACCLhDgHCPO64DXSCAAAIIIIAA AggggAACMQk0N0sFBcFgz8KFUk9PTNMZjEBKCDSrWQUqsAGfU3Wq3tN7KdE3TSKQ6gJ+v19V VVU2+JCbm6umpqZUXxL9I3CQAO/zg0h4AQEEEEAAAQQQQAABBFwsQLjHxReH1hBAAAEEEEAA AQQQQACB4QTa2qTS0mCwp6xMamdDk+GYeC1NBBrVqBzl2IBPtarlF1tUpcmlZRkuFmBHExdf HFpzVIAdqhzlpBgCCCCAAAIIIIAAAggkUIBwTwJxKY0AAggggAACCCCAAAIIOC3Q1SXNnRsM 9hQVSbt2OX0G6iHgPoH1Wm/DPR55tEIr3NcgHSGQRgJ1dXV2xx6Px6Pa2to0WhlLQWB4gY6O DpWXl9v3fUlJiXw+3/ADeRUBBBBAAAEEEEAAAQQQSKIA4Z4k4nNqBBBAAAEEEEAAAQQQQCAW gb4+adGiYLAnL0/avj2W2YxFIPO0/gcAACAASURBVLUFVmt1OOBTr/rUXgzdI+BSgc2bN8vr 9dqQw5IlSxQIBFzaKW0h4KxAa2uriouL7Xt/9uzZ6uzsdPYEVEMAAQQQQAABBBBAAAEExihA uGeMgExHAAEEEEAAAQQQQAABBMZDwPx9denSYLDH65U2bhyPs3IOBNwjEFBAy7TMBnyyla0N 2uCe5ugEgTQQ2LFjh/Lz8224obKyUr29vWmwKpaAQPQCfA9Eb8VIBBBAAAEEEEAAAQQQGH8B wj3jb84ZEUAAAQQQQAABBBBAAIGYBVatCgZ7PB6pnk1LYvZjQnoI9KlPi7XYBnzylKdt2pYe C2MVCCRZgF1LknwBOL1rBNi9yjWXgkYQQAABBBBAAAEEEEBgiADhniEgPEUAAQQQQAABBBBA AAEE3Cawbl1/sGflSrd1Rz8IjK9Al7o0T/NswKdIRdqpnePbAGdDIM0EOjo6VF5ebnfsKSkp kc/nS7MVshwEYhOoq6uz3w8ej0e1tbWxTWY0AggggAACCCCAAAIIIJAgAcI9CYKlLAIIIIAA AggggAACCCDghEBjo5STEwz3VFdLfr8TVamBQGoL7NEelarUBnxmaIba1Z7aC6J7BBwQePfd d/XII4/oW9/6lr74xS/q05/+tL7whS9o9erV+vnPf6533nnnoLN0d3eroqLCBhkKCwvV0tJy 0BheQCATBWpqauz3RVZWlhoaGjKRgDUjgAACCCCAAAIIIICAywQI97jsgtAOAggggAACCCCA AAIIpK/Ae+9JmzZJa9dKX/2qtHy59L3vSQ8+KL399sHrbm6WCgqCwZ6FC6WenoPH8AoCmSrQ rGYVqMAGfE7VqXpP7x1E8Rf9RXfrbn1b39ZVukrf1Dd1u27Xc3pOAQUOGs8LCKSiwIsvvqjP fOYzmjRpUni3EbPjyNCPCRMm6FOf+pSeffZZu0y/36+qqio7Ljc3V01NTam4fHpGICEC0Xx/ 7Nu3T48++qhuvvlmmTCQ+fj+979vQ3ZdXV0J6YuiCCCAAAIIIIAAAgggkLkChHsy99qzcgQQ QAABBBBAAAEEEBgngZdeksyuO3l5/bfX8ngGf2125znrLOmpp4JNmQ0Wpk0Ljpk1a/jwzzi1 z2kQcK1AoxqVoxwb8LlCV9g+e9Wr23SbZmqmfd0T4X+P0lGqVa3e1buuXR+NITCSwP79+3XF FVfI6/WGgzwFBQU699xzdeWVV9ode66++mqdd955OvTQQ8NjzE4kn/vc57Ry5Ur7GjuTjKTM sUwWMDtbnXbaafb7ZPLkyXr11Vctx3PPPacLLrhAEydODH9fDRemM997oTBdJjuydgQQQAAB BBBAAAEEEHBGgHCPM45UQQABBBBAAAEEEEAAAQQOEnj/fek//kPyegcHeYYGe4Y+v/DCYJjn 3nuDAZ9duw4qzQsIIPBPgfVar2N1rF7Wy3pST9qvIwV6hnv9SB2pR/UongiklEBbW5s+9rGP hYMFJ598sjZt2qSeCFu89fX1acuWLVqwYEF4zowZM3TCCSeotrY2pdZOswiMp0BHR4fKy8t1 ww03yATqzK3uTCBuaJgn0nMz9tJLL5W5bR4PBBBAAAEEEEAAAQQQQGAsAoR7xqLHXAQQQAAB BBBAAAEEEEAggkB7u3T66bGFegaGfMrKpJdflvbvj3ACXkYAgbDAfu3Xj/Vj5So3wj49w8V6 +l/LUpbWaE24Hl8g4GaB9vZ2ffjDH7bhAnMrrnvuuUeBQPS3mXvooYdUWFho5xcXF+vvf/+7 m5dLbwgkXcCEeoYG6iKFeSK9Pm/ePL7Xkn4laQABBBBAAAEEEEAAgdQWINyT2teP7hFAAAEE EEAAAQQQQMCFAmbjhNNOiz/YEwr5HH20tHevCxdISwi4TOARPSIT0OmP68T3VZ3qXLYy2kFg sEBvb68WLlxogzmHH364nnnmmcEDonz24osvavr06bbORz/6UbsjSZRTGYZAxgns27dPc+fO td8vkcI70bx+3HHHqbOzM+P8WDACCCCAAAIIIIAAAgg4I0C4xxlHqiCAAAIIIIAAAggggAAC YYHLLx97sCcU8FmwQPL7w6X5AgEEhgj8WX9WvvLHHOwxcSCvvPqtfjvkDDxFwD0CN910kw0Y 5OTk6De/+c2YGnv++eeVn59v633jG98YUy0mI5DOAhdeeOGYgz2h8M/555+fzlSsDQEEEEAA AQQQQAABBBIoQLgngbiURgABBBBAAAEEEEAAgcwTePZZKSvLuXCPCfn89KeZ58iKEYhWYLEW OxLsCe31c7yO1wEdiPb0jENg3ATefvttTZkyxYYMvvWtbzly3ltvvdXWy8vLs7cdcqQoRRBI I4EtW7Y4FuwJBXz++7//O42EWAoCCCCAAAIIIIAAAgiMlwDhnvGS5jwIIIAAAggggAACCCCQ EQJnneVssMeEe445Rvrgg4zgY5EIxCTwhJ5wNNgTCvj8VCTqYroQDB4Xge9///s2ZFBcXCxz myAnHuY2Xx/5yEds3ZUrVzpRkhoIpJXASSed5Hi4Z968eWllxGIQQAABBBBAAAEEEEBgfAQI 94yPM2dBAAEEEEAAAQQQQACBDBB4800pO9v5cI8J+Dz9dAYAskQEYhS4QlckJNxzjs6JsROG I5B4gdNOO82GDFatWuXoyW655RZbt6yszNG6FEMg1QV27tzpeLAntHvPSy+9lOo89I8AAggg gAACCCCAAALjLEC4Z5zBOR0CCCCAAAIIIIAAAgikr8D69YkJ9phwz/XXp68bK0MgHoGAApqq qQkJ90zURO2TMzujxLM25iAwVKCjo0PZ2dk2aLB9+/ahh8f0fGCAwXzNAwEEggKh4FsokOPk 5+9973swI4AAAggggAACCCCAAAIxCRDuiYmLwQgggAACCCCAAAIIIIBAZIHrrktcuOccNhKJ DM+RjBRoV3tCgj2hW3M1qzkjXVm0OwWeffZZG+wxAZ8DBw443uSUKVNs/S1btjhem4IIpKrA smXLErZzz5IlS1KVhb4RQAABBBBAAAEEEEAgSQKEe5IEz2kRQAABBBBAAAEEEEAg/QQuuSRx 4Z65c9PPixUhMBaBFrUkNNzzC/1iLO0xFwFHBR577DEbMpg2bZqjdUPF5syZY+uvN1vQ8UAA AStw1llnJSzc8/GPfxxlBBBAAAEEEEAAAQQQQCAmAcI9MXExGAEEEEAAAQQQQAABBBCILHDB BYkL95SVRT4vRxDIRIFn9ExCwz0P6aFMZGXNLhV48MEHbcjg2GOPTUiHp5xyiq3/wx/+MCH1 KYpAKgosXLgwYeEe8z3HAwEEEEAAAQQQQAABBBCIRYBwTyxajEUAAQQQQAABBBBAAAEERhC4 8srEhXvOOGOEE3MIgQwUeFWvJjTc83v9PgNVWbJbBZ588kkbMpg0aZICgYDjbU6fPt3W37Bh g+O1KYhAqgpUV1cnLNxz4YUXpioLfSOAAAIIIIAAAggggECSBAj3JAme0yKAAAIIIIAAAggg gED6CXz3u4kL9/z7v6efFytCYCwCverVBE1IWMDHJ99Y2mMuAo4K7Nq1Kxwy8PmcfW/u27dP OTk5tv4zzzzjaN8UQyCVBa6//vrw953H43H06+XLl6cyDb0jgAACCCCAAAIIIIBAEgQI9yQB nVMigAACCCCAAAIIIIBAego891ziwj3335+eZqwKgbEIfEKfSEi45wSdMJa2mIuA4wJmt57S 0lIbLrjrrrscrf/QQw/ZuoWFhXr//fcdrU0xBFJZYOvWrY4GegYGhBobG1OZht4RQAABBBBA AAEEEEAgCQKEe5KAzikRQAABBBBAAAEEEEAgPQXMnVKOPtr5gM+ECdLbb6enGatCYCwCd+rO hIR7Vmv1WNpiLgIJEbj66qtt0GDBggWO1r/gggts3YsvvtjRuhRDINUFent7NWXKFMcDPpMn T1ZPT0+q89A/AggggAACCCCAAAIIjLMA4Z5xBud0CCCAAAIIIIAAAgggkN4Ct9/ufLjn2mvT 24zVIRCvQLe6VapSRwM+h+gQva7X422JeQgkTGDHjh3KysqyQYNf/vKXjpxn27Zt4Zpbtmxx pCZFEEgngRtvvNHxcM8NN9yQTkSsBQEEEEAAAQQQQAABBMZJgHDPOEFzGgQQQAABBBBAAAEE EMgMgb4+qbzcuYDPoYdKb76ZGXasEoF4BH6sHzsa7rlB/NE1nuvAnPER+MxnPmODBmVlZXp7 jFu67d+/XyeeeKKtV1lZOT4L4CwIpJiA+T4pKSlxLOAzdepU7du3L8UUaBcBBBBAAAEEEEAA AQTcIEC4xw1XgR4QQAABBBBAAAEEEEAgrQT+8hdp8uSxB3yys6XNm9OKhsUg4LhAQAF9Xp93 JOCzQAvUq17He6QgAk4J7Nq1S+aWPh6PR2eddZbef//9uEp/8MEH+uxnP2vrTJo0SS+88EJc dZiEQCYI/OEPf9DEiRPHHPDJzc3VE088kQlkrBEBBBBAAAEEEEAAAQQSIEC4JwGolEQAAQQQ QAABBBBAAAEETChn0qT4Az5ZWdJtt+GIAALRCJjbc52hM8YU8Jmt2epQRzSnYwwCSRX41a9+ Ja/Xa4MGFRUVeuONN2Lqp6urS+eff344qHDPPffENJ/BCGSiwH333aecnJzw940J2MXyYebe e++9mUjHmhFAAAEEEEAAAQQQQMAhAcI9DkFSBgEEEEAAAQQQQAABBBAYKvD889JRR8Ue8Dnk EOmRR4ZW4zkCCIwkYHbc+ZK+FFfA51ydq3f0zkjlOYaAqwTWr18vswuICRcUFxfrjjvuUJ+5 L+QID7/fr4aGBpWWltp52dnZuuWWW0aYwSEEEBgo8PTTT9vvt1hCPWas2W3rF7/4xcBSfI0A AggggAACCCCAAAIIxCxAuCdmMiYggAACCCCAAAIIIIAAAtEL/OMf0te/LuXljR7yMbfhqq6W du+Ovj4jEUBgsMCv9Wt9TB+LKuRztI7Wj/Qj+eUfXIRnCKSAwOOPP66ioqLw7iElJSW66qqr tGHDBj333HP629/+pueff16PPfaYli9frmOOOSY81oQNNnPfxxS4yrToNoG33npLX//616O6 TZfZrefLX/6yXn/9dbctg34QQAABBBBAAAEEEEAgBQUI96TgRaNlBBBAAAEEEEAAAQQQSD2B N9+U1q2Tzj9fmjVLMrvzmNt2zZghLV4s3XoroZ7Uu6p07FYBE9Z5Uk/qa/qaTtJJmqZpyla2 jtSR+qg+qqt0lX6lX6lPI+904tb10RcCIYF//OMfNmgwadKkcHBnpF1FQmGDWG/lFTofnxFA ICiwZ88e3XnnnTr33HNVXl6u/Px85eXlaebMmTrnnHN0++23q62tDS4EEEAAAQQQQAABBBBA wDEBwj2OUVIIAQQQQAABBBBAAAEEEEAAAQQQQACB8RcwYZ27777bhgqmTp2qrKyscNjnyCOP 1KJFi1RfXy+fzzf+zXFGBBBAAAEEEEAAAQQQQAABBBAYswDhnjETUgABBBBAAAEEEEAAAQQQ QAABBBBAAAH3CPT19Wnv3r3q7e11T1N0ggACCCCAAAIIIIAAAggggAACcQsQ7ombjokIIIAA AggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCRWgHBPYn2pjgACCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIBA3AKEe+KmYyICCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAokVINyTWF+qI4AAAggggAACCCCAAAIIIIAA AggggAACCCCAAAIIIIAAAggggAACCCAQtwDhnrjpmIgAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAIIIIAAAggggAACCCCAQGIFCPck1pfqCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAgjELUC4J246JiKAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCA AAIIIIAAAgggkFgBwj2J9aU6AggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAJxCxDuiZuOiQgggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAII JFaAcE9ifamOAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggEDcAoR7 4qZjIgIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACiRUg3JNYX6oj gAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIBC3AOGeuOmYiAACCCCA AAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIBAYgUI9yTWl+oIIIAAAggggAAC CCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCMQtQLgnbjomIoAAAggggAACCCCAAAII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCQWAHCPYn1pToCCCCAAAIIIIAAAggggAACCCCA AAIIIIAAAggggAACCCCAAAIIIIAAAnELEO6Jm46JCCCAAAIIIIAAAggggAACCCCAAAIIIIAA AggggAACCCCAAAIIIIAAAggkVoBwT2J9qY4AAggggAACCCCAAAIIIIAAAggggAACCCCAAAII IIAAAggggAACCCCAQNwChHvipmMiAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAKJFSDck1hfqiOAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAA AgggELcA4Z646ZiIAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggEBi BQj3JNaX6ggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIxC1AuCdu OiYigAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIJBYAcI9ifWlOgII IIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACcQsQ7ombjokIIIAAAggg gAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCRWgHBPYn2pjgACCCCAAAIIIIAA AggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIBA3AKEe+KmYyICCCCAAAIIIIAAAggggAAC CCCAAAIIIIAAAggggAACCCCAAAIIIIAAAokVINyTWF+qI4AAAggggAACCCCAAAIIIIAAAggg gAACCCCAAAIIIIAAAggggAACCCAQtwDhnrjpmIgAAggggAACCCCAAAIIIIAAAggggAACCCCA AAIIIIAAAggggAACCCCAQGIFCPck1pfqCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAAC CCCAAAIIIIAAAgjELUC4J246JiKAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCAAAII IIAAAgggkFgBwj2J9aU6AggggAACCCCAAAIIIIAAAggggAACCCCAAAIIIIAAAggggAACCCCA AAJxCxDuiZuOiQgggAACCCCAAAIIIJDKAk8/La1YIXV2pvIq6B0BZwW61a3d2q0/6o96Va/q gA6MeIIP9IH2aM+IYziIAAIIIIAAAggggAACCCCAAAIIIIAAAmMTINwzNj9mI4AAAggggAAC CCCAQAoKBAJSebnk8Uhr1ox9AXfeKV13nbR0qfTJT0qnnSbNmjX2ulRAINEC7+pd/V/9X31B X9BUTZVnyH9eeXWSTtKtulVv6s2D2qlRjT1+0AFJa7VWy7Vcl+pSnatzdYpO0XzNH25oWr52 p+7UdbpOS7VUn9QndZpO0yzxD0NaXmwWhQACjgo88MADuummm+L6uOWWW3Tffffp8ccfV3t7 u6N9UQwBBBBAAAEEEEAAAQQQSKYA4Z5k6nNuBBBAAAEEEEAAAQQQSIrA448Hgz0m3HP00ZLf P7Y2TJjH6+2vaerm5ERX05y7oUH65jelF1+Mbg6jEBirwH7t1026SUfoCBvnyVKWPq6P6zv6 jhrVqOZ//rdJm3S9rlepSlWoQt2m22R26zGPX+vXMvPmaM6w7ZSpTNnKHhQXMgGiTHmYMI8J Rw0MTOVo9H8Y/PKrQQ36pr6pF8U/CpnyfmGdCCDQL/DpT39aU6ZM0YQJE+TxeA76yM7O1mGH HaaioqJBH4ceeuigsV6vV2eeeabuuusu9fb29p+ArxBAAAEEEEAAAQQQQACBFBQg3JOCF42W EUAAAQQQQAABBBBAYGwCn//84CDOli1jq2dmf/BBMKRjgj2xhHtqavp7ycuTWlvH3gsVEBhJ 4Ak9oWmaFg6dmF17dmrnSFPUpz79SD+yAZ/FWqy/6W+arum2RqRwjylo5tWpLnyuTAr3mPWb IJQJ6oQCPtGEe8xuSKHxecpTq/hHYcQ3JwcRQCCtBXbs2KHCwsJwaKe0tFSdI9xTtbu7Wzt3 7tTdd9+tRYsWKSsry86dMWOGNm7cmNZWLA4BBBBAAAEEEEAAAQTSW4BwT3pfX1aHAAIIIIAA AggggAACQwTeekuaOLE/UGOCOFVVQwaN4WmodrQ795SWDu6lvn4MJ2cqAqMI3Kybw7vJFKlI v9FvRpkx+PArekUf1oc1URPDAZSRwj1mtrn1VyiskmnhnpBeyCuacI/ZJSnkZT7Xi38UQo58 RgCBzBQ49dRTw+Ge008/PSaEbdu26cQTTwzP/+pXvyr/WLdsjKkDBiOAAAIIIIAAAggggAAC zggQ7nHGkSoIIIAAAggggAACCCCQIgK33RYM9/zrv/aHanJzpb17nVnAEUcE60Yb7jnnnP4+ TNDoN7FlLZxpmioZIfA9fS8cGjHBnj/pT3Gte7d2y8wPBVBGC/eYk4TGZmq4J3T7s2jCPefo nLCXcYs1gBXXRWUSAggg4GKBBQsWhMM55utYH319fbrooovCNS688EJ9YLZc5IEAAggggAAC CCCAAAIIpJAA4Z4Uuli0igACCCCAAAIIIIAAAmMXOOEEydyW68EHB4dqbrpp7LVNhaKi2MI9 bW3SRRdJJ54o1dU50wNVEBgqcL/uV5aybGjEfH5aTw8dEtPzB/VgOIBCuGd0ulAYKppwT5va dJEu0ok60d7SbPTqjEAAAQTSW2Cs4R6jYwI+Z599djjgs2LFivRGY3UIIIAAAggggAACCCCQ dgKEe9LukrIgBBBAAAEEEEAAAQQQiCTwhz8EgzePPy719vYHccyOOWVlUiAQaWb0r8ca7om+ MiMRiE9gj/boEB0SDuN8UV+Mr9CQWRWqsDUJ9wyBGeZpLOGeYabzEgIIIJDRAk6Eewzg3//+ d+Xl5YUDPo899lhGu7J4BBBAAAEEEEAAAQQQSC0Bwj2pdb3oFgEEEEAAAQQQQAABBMYgcNll g0M8X/va4N17TOhnrA/CPWMVZL7TApfq0nCwx+wc86bedOQUP9fPCfdEKUm4J0oohiGAAALD CDgV7jGlv/a1r4XDPTNnztSBAweGOSMvIYAAAggggAACCCCAAALuEyDc475rQkcIIIAAAggg gAACCCCQAIGuLik/Xxp4+62//GVwuMfcrmusD8I9YxVkvpMCf9FfwsEejzxarMWOle9RjyZo gti5Z3RSwj2jGzECAQQQiCTgZLinubk5HO7xeDxat25dpNPyOgIIIIAAAggggAACCCDgKgHC Pa66HDSDAAIIIIAAAggggAACiRK4804pN1fau3fwGU4/vT/gM3Gi9NZbg4/H+mws4Z59+2I9 W3B8W5v07LNSU5Nkbj3W0RFfHTPrnXekP/1JMrsYmc+dnfHXYmbyBb6tbw8K99yhOxxt6nSd 7ki454AOaL/2j7m3gAJ2Z6IX9IKe0lMytyRz4tGnPpkw09DHu3pX5pyjPeIN9+xTfP8ovKN3 9Cf9SY/rcfu5U3wjj3aNOI4AAu4VcDLcY1Y5bdq0cMBn4cKFUS08EAjozTff1AsvvKCnnnpK e/Y48/MlqpPHOeidd97Rn/70Jz3++OP2cye/1MUpyTQEEEAAAQQQQAABBNwhQLjHHdeBLhBA AAEEEEAAAQQQQCDBAh/9qFRVdfBJ/uu/+sM9Ho90220Hj4nllWjDPTfeKJ15pjR3rvkjUzB4 lJMT/Zn+/nfp2mulo47q7z8vT8rKCj43NW+4QTI7Fo32CASkBx8M9uP1SgUF0vHHBz9nZ0tn nCE98shoVTjuRoHjdfygcI/ZycfJx126S/+h/xi1pNk1yPw3VVPDY33y6Sv6io7TccpVbvj4 Qi3Uo3o0PC6aL/Zqr1ZplUpVqkmaZGvO0ixbt0AFMiGk+3W//PKPWs4EY87TeTpNp6lMZTpM h9nefqAf2Lnv6T19V9/VdE23rx+iQ+w6TAAo0iOacM+NulFn6kzN1VxN0zTbu7mNWrQPEzJ6 UA/aGl55ZdZtrr/5nK1snaEz9Ij4Ro7Wk3EIIOAeAafDPWeffXY43OP1evXWCMnuvXv3atWq VSotLdWkSZN03HHHadasWcrNzVVBQYFOP/103X///fL7R/75cv3112vJkiW64oorVFNTo+uu u05XX321Lr/8cn3uc5/TL3/5y2HBH330UV1yySV23PLly2U+vvjFL+ozn/nMsOc0IaQHH3xQ Z555pszaTI/HH3+8/Zydna0zzjhDj/BL3bDWvIgAAggggAACCCCAgNsFCPe4/QrRHwIIIIAA AggggAACCIxZ4I9/DAZetmw5uNR770mTJ/cHZE444eAxsbwSbbhnxQrppJMkE+gxoSLzEW24 57vflcwuQ2bOWWdJTzwhN/pDXQAAIABJREFUdXcHu/zgA+nFF6Xa2uDx4mLJ54u8AvN/PJ8/ Pzj2uOOCIR4T9gk9tm6VZs0KHq+ulvoi5xdCU/jsEgGzE04oVBP6/A/9Iyndhc4fCvf8l/5L +crXtbrW7rBj+vof/Y/WaE2458/pc1H12qpWHatjbSjm1/q1etUbnme+NrsVHa7DbV0TcHlD b4SPD/eF6WWBFmimZoZ7Mf2bcI/ZSccEhSpVqSf0hG7QDeExtaodrpx9LZpwzwqt0Ek6SSbQ E/KKNtxjdiiar/l2nglLmRDPwB2FtmqrTNjJ1K1WtUYKIkVcBAcQQACBJAk4He4x4RpzS67Q x4YNG4ZdWWtrq4499ljNnTtXv/71r9XbO+DnS2+v7rjjDh1++OG2jgnNvPFG5J8vX/3qV1VZ WalDDz00fF5zfhPAOe200/SLX/xi2B4eeOCBg+YUFhZq0aJFB4V7zG5C8+fPt/VNCMmEeEzY J/TYunWrDSaZ81ZXV6uPX+pCNHxGAAEEEEAAAQQQQCAlBAj3pMRlokkEEEAAAQQQQAABBBAY i8CXvywdfbQU6f9UffXVwfBKKGRjbm0V7yPacE+ofktL/7lHC/eYv88sWxYcb3bo+eY3I6/p X/+1v+43vhE62+DPu3cHdw0y6zYBn/0R7opkbmUW2iHosssG1+CZewVMWCYUEjGfJ2hC0poN 9WHCPQ1q0NE6Wi/qxWH7uVJXhvveoOH/4Dpw4mW6zI43u/88oAcGHgp//Qf9QWY3G9PHHM1R l6LY0krS9/X9cC8m3HOxLtbZOjscILpAF4SPf1KfDJ9v6BfRhHtCc1rUEq4ZTbhnt3bbnX7M 2kzAJ9LtzczuRkfpKFvbmPFAAAEEUkXA6XBPbW3toIBNfX39sBSXXXaZHWd26TEhm+Eef/jD H2xAxwRm5syZo65Rtkw0OwEdeeSR4fN//etfH67soNdee+01HXLIIXaO2bXn3XffHXTcPNm9 e3f4dmMm4LM/wi915vxHHXWUrWXWxwMBBBBAAAEEEEAAAQRSR4BwT+pcKzpFAAEEEEAAAQQQ QACBOATM3zYKC6U1ayJPfv75/iCMCbqM5W8dsYZ7TFeHHBI8/2jhnu98p7/Pz3428noG1jTr ueKKg8f29Ehz5gTrmV2AWlsPHjPwlZ/8pP/cTz018Ahfu1XgST0ZDomY4Ie5ZVWyHqFwT57y dKgOlQnbRHqY3XdC48/X+ZGGhV8vV3l4/Dk6J/z60C8GhobMbbWieWzX9nBts5OQ2SHI3JYr 9HhID8nclmuyJuvn+nno5YM+xxLuMZNNTWMwWrinRz02rGTGTtREmV2MRnr8RD8Jr+cp8Y08 khXHEEDAPQJOh3vq6urC4RoTyvlGhBR0eXl5eNw554zw8+XKK8Pjvmu2Vxzlceutt4bHf/zj Hx9ldPDw9OnT7S3Ahrv9V09Pjw0WmbVMnDhRZsehkR4/+clPwud/il/qRqLiGAIIIIAAAggg gAACrhIg3OOqy0EzCCCAAAIIIIAAAggg4LTA+vWS1yu1tY1c+V/+pT+8kp8vjfJ/vI5YLJ5w TzRzXnlFys0N9pidLb30UsQW7IH/83+Ct/k68UTJhJeGPm6+uX+9n4vi7kfGI3QLsUsuGVqN 524UeE7PhYMcJvxxhI5IWpuhsI75XKOaEfsYuOOQuZXUaI9rdE14nTfppojD79N94XHn6tyI 4wYeGLiLTpay9D19b+Bh+7XZKadb/7wv3kFHgy/EGu6JdvzNujm8pmhuY2Z2LArd9usS8Y0c 4XLxMgIIuEzA6XDPzTffHA63mEDM6tWrh13xNddcEx53000j/Hy5777wuHPPHf3ny759+wbd auuP5v6xIzyefvppW//54X6hkzRwPZ+L4pc6s7tQTk6OrXkJv9SNIM8hBBBAAAEEEEAAAQTc JUC4x13Xg24QQAABBBBAAAEEEEDAYYFTT5U+9anRi951V3/Yxex2Y57H84gmqDO0bjRzrryy v79/+7ehFYZ/fuDA8K+b25NNndpf7+eRNxwZVKCiIjjnIx8Z9DJPXCrwht4IBz9MqMaEUw4o wpsiwWsYGO55Wk+PeLY2tYX7LlThiGNDB5/VszI7FY30eF7Ph+uepJNGGho+NjTcY0zjeUQb 1gnVjma8X36Z25yFbEfaOShU13yuUIWd8xHxjTzQha8RQMC9Ak6He1atWhUO45hwz+233x5x 8c8++6yefHKUny/PPx+ud9JJ0f18MbfjMuc2HxdffHHE85sDF1xwgRYvXjzsGLOTz9SpU8O1 fh7lL3UVFRV2zkf4pW5YV15EAAEEEEAAAQQQQMCNAoR73HhV6AkBBBBAAAEEEEAAAQQcEfjz n4NhFLOLTUvLyB/mrgRmhx8T7DEfZiefeB7RBHWG1h1tTiAgHXlkf2/XXDO0QmzPt2/vr2XW apyieZjblZnxZueg99+PZgZjkilgwh/mNlih8If5/LpeT0pLA3vYoz0j9mCOh8YXqGDEsaMd NDvVvKJXZMI/d+vucN1jdMxoU+3xgeGeI3VkVHOGGxRNWGfgvGjGD7xlmPH6s6L7Rr5Ml1mH bGXrffGNPNCdrxFAwJ0CTod7rrrqqnAYxoRrNm3aFPPCze43r7zyikz45+677w7XO+aY6H6+ vPbaa5owYYKd5/V6tXv37mF7ePnll5WVlaWmpqZhj2/fvj18brOWP0f5S91ll11m52VnZ+t9 fqkb1pYXEUAAAQQQQAABBBBwmwDhHrddEfpBAAEEEEAAAQQQQAABxwSuvXZwiCUU3In2c3Nz 7K2MFtQZruJoc/bsGbyOtWuHqxL9a/feO7heWZk0a9boH4cd1j/vjfg2MIm+SUY6InCRLgoH WkwA5Lf6rSN1Q0Ue02P6qr4aehrxcyisYz6/o3cijjMHxhLueVWv6nbdrvN0nqZrul37FE3R HM3RKTolbFGq0hF7CB0cGO45WSeHXo75czRhnYFFoxl/r+4Nr8e4lqlM5jZmo/13mA4Lz4t3 J6KBvfI1AgggkGgBp8M9lZWV4UBMbm6u3nln5J9LZn2vvvqq3eHnvPPO0/Tp0+38KVOmaM6c OTrllFPC9UpLo/v5YmqGAjYmlPOVr3xlWMYrrrhC8+bNG/aYefHee+8Nn9vUKSsr06xZs0b9 OOyww8Lz3uCXuoi+HEAAAQQQQAABBBBAwE0ChHvcdDXoBQEEEEAAAQQQQAABBBwT6OmRpkyR vvxl6bnnovt44IH+8IoJAF11VeztjBbUGa7iaHOef35wXw8+OFyV6F+7+ebB9cxOPi+9FP1H W1v052JkcgUe0APhIIcJgFyn6xxt6Ev6khZq4ag1Ex3ueVkv6/P6vMxuNOZcZ+gM3aN71KrW cG8v6aWwRTzhnrN1drhWrF9EE9YZWDOa8Tfr5vB6zJrNTj5mjdH+Z25/xgMBBBBIBQEnwz0H DhzQIYccEg62nH32yP+2m51zPv/5z8vscGPCM2eccYbuuecetbYO+Pny0kvherGEe8wuO6am +cjPz9dbb7016HKY0M3EiRP105/+dNDrA5/cfPPN4RqmjtnJ56WXXor6o41f6gZy8jUCCCCA AAIIIIAAAq4WINzj6stDcwgggAACCCCAAAIIIBCvwH33BQMsO3fGVmH27P7gy+TJ0nvvxTZ/ tKDOcNVGm2Pu1DBwtyGz885YHkN37vnb38ZSjbluFtiv/ZqqqeEQyIf1YUfbrVCF/l3/PmrN RIZ7zA42XnntGo/W0RF3JxpruOccnTPqOiMNiCasM3BuNOOH7tzzN/GNPNCQrxFAIH0EnAz3 /Pa3vx0UhnnsscciQpldccwts0xo5uijj5aZO9zDhGlCIZ1Ywj2m1jnnnBOee+ONNw4qv3r1 apl6fX19g14f+GTozj1/45e6gTx8jQACCCCAAAIIIIBAWgkQ7kmry8liEEAAAQQQQAABBBBA ICSwcKH08Y+HnkX/+T//c2xBmtGCOsN1Mtqc3l4pL6+/r//9v4erEv1rZqeegWGhP/4x+rmM TD2BBjWEwz0mZPOoHnVkEeaWTjnK0c/0s1HrJSrc85AeCq9tmqbJJ1/EXtIt3GN26hno+kfx jRzx4nMAAQRSWsDJcM/5558fDtMsNL8sRng89NBD4XHTpk2TzzfCz5cxhHsGho2Ki4vVY7ae lPTuu+/K3PbrlltuidBh8GWzU08oWGQ+/5Ff6kb04iACCCCAAAIIIIAAAqksQLgnla8evSOA AAIIIIAAAggggMCwAi+/HAyv3H//sIdHfPEf/5AmTeoPv8yfP+Lwgw6OFtQ5aIKkaOZUVfX3 9IlPDFcl8mtdXYOPBQLS9On99e6+e/Dx0Z69/vpoIzjuJoGAAjpdp4eDIGb3nh4F/3g4lj5v 1I2aoil6V++OWmZgCOUdvTPi+D3aE+61QAURx36gD3SMjgmP/ZF+FHGsOdCilvDYgbfl2qmd ukyXDbuOgXPctnOPua7TNT28prsV2zfy6+IbecQ3DAcRQMA1Ak6Fe0yQJisry4ZhzG2wWlpa hl3jBx98oGOOOSYcmvnRj0b5+dLSEh47cOeenTt36rLLLrNBnWFP9M8XP/axj4Xn3/3PX8pu u+02TZ48WV1Df4kbUigQCGj69OkHzR8yLOLT1/mlLqINBxBAAAEEEEAAAQQQcJsA4R63XRH6 QQABBBBAAAEEEEAAgTEL/K//JU2ZIv3z//wcc72lS/uDL2aHm5deir5ENEGdodWimfPkk/09 TZggtbUNrTL8czMvO1sa+rehH/ygv96ZZw4/d7hXt2wJznv77eGO8ppbBfZqrz6ij4SDIF/S l2TCIfE+/kf/o3zl64f6YVQlEhHu+av+Gl6Pqf+KXhmxl0Y1hscPDPf8Xr+3r7+ltw6a7+Zw j2n2B/pBeE1nKvpv5C3aYue9Lb6RD7rovIAAAq4TcCLcs3v3bnuLK7O7jQn4PPLIIxHX+de/ /jUcljHjX3lllJ8vjY3h8QPDPb///e/t62+9dfDPl4En/9nPfhaeP3PmTPX29trbgK1YsWLg sIhf/+AHPwjPPzOGX+q2bNli573NL3URbTmAAAIIIIAAAggggICbBAj3uOlq0AsCCCCAAAII IIAAAgiMWcCEWEyw57Ofjb/U00/3B19MuKemJvpaRxwRnOv1xj4nJ2fkOZde2t+XCSBF8zA7 D5177sEjDxyQTj65v95jjx08ZugrJixVVjZ8vaFjee4+AbNDzVRNDYdBrtW1cQV8zI4vJ+gE fUKfkNk9J5rHwHBPpzpHnNKmtnCPh+iQiGMHBm9M/df0WsSx5sA1uiZct0Ql4bFP62n7+nA7 Cr2gF8JzztbZ4TmxfnGEjrB1vIruH4bQeHPbs5EeB3RAJ+vkcI+PafRvZLNrU5nKdK6G+Ydh pJNxDAEEEEiSwOmnnx4Or5igT6yPZ555RkceeaStkZubq3Xr1o1YwuzoM/BWV6+9NsrPl2uu CY8vKRnw8+Xpp+3r77wz8o51Bw4csGGe0DkvvvhimT7bokxym/knn3xyuIfHovilztz+q6ys TOcO90viiDocRAABBBBAAAEEEEAAgWQJEO5JljznRQABBBBAAAEEEEAAAccFzC21zN8oTCDn +OOl7u74TmFCLLm5/cGXww6TOkfOI9gT+f2S2VXHnN987N8/+vmHzhmpZ3PMhHVC9b/1LemD EbIVq1dL+fnS7t3D97F3rzRjRrDeoYdKzzwz/DjzqjExgaIPfUjiDg6Rndx+xARzFmhBOAxi dnsZbcebgWv6nX6nY3WsTtEp2qd9Aw9F/NqEeQaGe/6uv0ccaw68qBfD47OVrT71DTv+fb0v E9IJ1b5Ftww7zry4SZs0TdNsIMmMN6GZ0O3EGtSgw3X4sHOf0BPh+vMV4z36/lnRL78maEK4 zn6N/A/D0PHdGvkfMrMr0wzNsPUP1aF6RpG/kU2wZ6mW6kP6kLgt17CXnBcRQMCFArNmzQoH V0455ZSoOzQ78HzhC19Qdna2nT9t2jT97ne/G3X++++/LxPSCYVtbrllhJ8vmzbJ1P3EJz5h x+fk5IRvw9XQ0KDDDx/+58vQJm699dbw+cx5ly1bNnTIiM/37t2rGTNm2BqHHnqoTKAp0sME e5YuXaoPfehD4rZckZR4HQEEEEAAAQQQQAAB9wkQ7nHfNaEjBBBAAAEEEEAAAQQQiEHABE2+ 8x3pC1+QTAgnFHwxn8vLpRtukP7f/xu9oNnJ5oc/lGprpYqKwXVMrVmzpG9/W7r9dumBBwbX e/jh4Otmt6CB5z/vvGDNn/1s8HjzLNKciy6S7rhDMrfTGu7x3nvBkE3oPP/yL9JvfiO9+25w tAn7mL9bmXObYE9j43BV+l8zd2L45CeDfZtAk7ml2c6d/cfN+R56SJo7VzK3D9u2rf8YX6Wm gNntZY3WaLIm20DIJE3SF/VFbdO2YXfiMeGaJ/WkLtElylKWHWtCIqM97tf9qle93SEmFMAx n/9N/6b/1H/qHt0TLmFuEfZj/Vi36bZB4SMz/kJdaG//9aAeDI8PfWF23SlWsV2HCeyY8w0M A3WpS9/X9+2ORWYNm7U5HLK5SBfJBHs+/P/bu4MQrco2DMCERBGTFIhMDOkQGLUQNNeWswuJ UihaZi5GWs9OEcSdgS2kyMSd/EwSiDjoVpPh37nIRULUIhBcuBAlIUK4f54z/4zzxYyMFTQv 73VgmDnfd875nud6UAe8ed9M5liOLT4yFaapWk7mZN7KW0vXVy2f5JN8kS/yTb7Jz/l56Z6V fvgu3+XLfJkP8+HIM97Le0M//8noXwyrXV91fpWvhhms9Dn1Wm2vtTd7h895Ns9mJjOplZoW j4d5mPM5n+3Znk3ZNMx68T3fCRAgsN4ELl++nDNnzqQCL/v27RsJvVR45siRIzl9+nTOnj07 8lWvHT9+PIcOHcryQNDGjRuH139bS+r6/xjXr1/P5s2blwI7p06dyh9/PA6b3r9/PydOnMj4 +HiuXbuWS5cuLdW5f//+VLBncnIyx+oXyzUcDx48SIVyFgNFN2/eXMNdo5fU9lp79+4dnlEr /8zMzOSnZb/UPXz4MOfPn8/27duzadOm/NcvdaOAzggQIECAAAECBAiscwHhnnU+IOURIECA AAECBAgQIPBkgQrBPPfcwlZcExML20a99lpSP9cWWc8/n5w9++Rn1Lv1/z21lVYFYmpbr/Hx ZOvWZNu2hdVttmxZeK1WuJmcHH3ejh0LwaJXXll4r+6p62uVm7GxheeM3pGsdk8FaKqGTz/9 8x2j599/n7z77uOVgp55JqmdICqgUz1//HHyyy+j9zzprEJAU1NJbQ1WwaHqswzrvHqYnk7u 3HnSE7zXmkAFQo7kSF7Nq0vhkxfzYt7O2/koH+WDfJA38sawyk0FW97JO6kwzVqPeu7LeXlY MacCNK/n9WHVn1ptp1bKqXDR4lHbe9XqNvV6vV+rA9X1dV+d13PezJuLl498v53bOZiDQ2il 6qxn7M7u7MqujGUsFY75MY8TfkdzNLU9Vl1bQZcK8Sw/aiWcP9eyLduyJVuGIFHVXe9XeOlJ x47syEt5aan/xWfUqjlV19ZsHbl9teurxhfywhCqGrlhhZMruZKpTC3NrFbymcjEcF6fOZ3p 3Ik/yCvQeYkAgXUksGfPnqWQy2LYZa3fa5WeCtzs3LkzBw4cyIULF/I0oZ7lDLdv387BgweH IEx9fq3Cs3v37uzatStjY2OpEM+PyxLkR48ezYYNG4baKzxz8uTovy/Ln73Sz4cPHx7urYDO 3zmuXLmSqampVBCq6q7Q0MTExHBedU9PT+eOX+r+DrF7CRAgQIAAAQIECPwrAsI9/wq7DyVA gAABAgQIECBAgMA/I/DgwcIqP99+m9RXhX4WV/H5K59Q249dvZrMzi6s2DM/n/z++195knta EvghP+TzfJ7P8tkQhqlwzPt5fwiDfJ2v82t+XfftVEDoRm5kLnM5l3OpLbVWC7LU1li3cmvF lYrWfaNrKLC2Qqv+ZzM7rNgzn/nUNmYOAgQIEHh6gUePHuXGjRuZm5vLuXPncvXq1VXDMRUk unXrVuqepz1qu6yLFy/m7t27T3vritffu3dvqHV2dnZYsWd+fj615ZiDAAECBAgQIECAAIE2 BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECBDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfN uamaAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECg AwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7p YMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ aFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUC BAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR7 2pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQIECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAEC BDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuama AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECgAwHh ng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECA AIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMha JECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAjPrG9PAAABnElEQVQQIECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECg AwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAIE2BYR72pybqgkQ IECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQEO7pYMhaJECAAAECBAgQIECA AAECBAgQIECAAAECBAgQIECAAAECBAgQaFNAuKfNuamaAAECBAgQIECAAAECBAgQIECAAAEC BAgQIECAAAECBAgQIECgAwHhng6GrEUCBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQ IECAAIE2BYR72pybqgkQIECAAAECBAgQIECAAAECBAgQIECAAAECBAgQIECAAAECBDoQ+B90 x5WuMGorJgAAAABJRU5ErkJggg== --------------D327DA4C35DE5DCC6429AFEE-- From nobody Fri Oct 23 03:36:51 2020 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 AABDF3A0B93 for ; Fri, 23 Oct 2020 03:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de 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 dI5l_HFSKZsk for ; Fri, 23 Oct 2020 03:36:47 -0700 (PDT) Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [134.147.53.149]) (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 AC96D3A0B91 for ; Fri, 23 Oct 2020 03:36:47 -0700 (PDT) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 4CHgdS3RVxz8S7G; Fri, 23 Oct 2020 12:36:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1603449404; bh=k87lCEFZzMND5aU/JPEKk6c8LHlEvIi4k0QhSQ9C4O0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Ba3vtcHk+E+TURzaP47I0pIjEessL3pVKAPAczPW2uP1vKvROZCy/UZnAyKV4PeEK Xo8yNlXYMrBlJ5G28f159lCw5M4DF8uTscHGyYUjW26AJgnUwfkTyk1o2Ps8wfiuIy Lb5O2EvRCDawYnezwXVtnWae+x2H78T9EANNAIMI= Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 4CHgdS1rjKz8SHq; Fri, 23 Oct 2020 12:36:44 +0200 (CEST) X-RUB-Notes: Internal origin=134.147.42.236 X-Envelope-Sender: Received: from mail2.mail.ruhr-uni-bochum.de (mail2.mail.ruhr-uni-bochum.de [134.147.42.236]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 4CHgdR5Vx7z8S5V; Fri, 23 Oct 2020 12:36:43 +0200 (CEST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.2 at mx1.mail.ruhr-uni-bochum.de Received: from [IPv6:2a05:3e00:9:2100:60af:a89b:a0c2:f34c] (dyn-c43f2c0ab98afa0600129000.nds.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:9:2100:60af:a89b:a0c2:f34c]) by mail2.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 4CHgdR5L1wzDh0v; Fri, 23 Oct 2020 12:36:43 +0200 (CEST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.4 at mail2.mail.ruhr-uni-bochum.de To: mls@ietf.org, Joel Alwen References: Cc: Jost Daniel , Marta Mularczyk From: =?UTF-8?Q?Paul_R=c3=b6sler?= Autocrypt: addr=paul.roesler@rub.de; prefer-encrypt=mutual; keydata= mQMuBFMPNo4RCACsEL23jO1k25wZhdphKuPdmEnxvjbtZavn1ZkALMxWJ4bYHPxNkpZWCT9h v0ZizDoosjlIvh0lK0nZgK0MLwjG/swrG/qUoZPIxStbXSVZPPwSdTaa+nzN0HD2y30zDExP 9WtchiEnGPB8WLCjkx5qscrBZV+PzI5akdK2CGBDthVvYzu4oLMZ89akJfM82ap9fGf0pfMh 4Qj4zIH6Vt6PIDn/r3d1GNW00RlEaq+MerAp3WkO+BwZ/2yCM+WJFG4w8tI3p+CjUlZehU2o WBxAmaLLHK3HOrCxiyGWZtIXy5plSfBjDomrlnlIiaDiC0N+MleHF8+IqxAo0XKySXn3AQDm UVBV0DpdIxm8dk2BCT5pMdnZFxzoBbSt57Tv9htwcwgAqpCy5Fhfcm5fVdhkeuaX86izCPfn 1k6FDt/3VUZ7lwcLJL9qYp1treUptfrUJ/DOeZN5LAyULj2Aijjy2Tni3RrDR9+1NvLTla4v bJpndEWI0nof1l8za+sfeQn8YnSylZLFt/Blx3MAe0MnNi9ZbGk50fdKjNsBwCwcZP/1Gyen s05rk2aaL07n5guCz/0bmlQFANCyi3lH+EcHJ0I4wYriBA4xJ3wDJmrCtjhsAtHNnc6pqvgE S2h2J7gAGa7A+ktFJhAxmVSx02GzakjNenx/SWMT2zlIZ/tu1T3wdX3SghUvX62p37FXPObF EbaEJZc9j4jUqnaJHbj/q717Gwf/S3mVyiMaIVzfbxmngGVfaf89vHRh7sWvkt9+TarR7Xen M2Bwi9wKgJ6pshkAnIe6VCGx4+JNH5SUiaxVr6TyrK9GcDkfCEwcVGwDBmeKdtv5Psb2Ho6t tTIWPwj/eQAJn283X18izF1xYYDFSct835R3hG6baP1FJZmMSm+CxV8C+uZXB/Yom/p4NblJ ujLJPGVampAZYs3ZVLrQBuxrXhGrDimFY9TLgO3ZN4gN4gQ3OvvBzmagwGMJdszTaRNE3JGE /qzvlvIs3KTLpQzybxZWwl7SO8b7A+i6+Yp9uN6thrpX7/TdnKcvnMezNYMRjuXvRGmaZ7c2 thgDF83fY7QvUGF1bCBSw7ZzbGVyICh1bml2ZXJzaXR5KSA8cGF1bC5yb2VzbGVyQHJ1Yi5k ZT6IewQTEQgAIwUCVAXA1QIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEBbS1xKc azdG8XQBANG5xd6Uukm6eXmJRQoSoeax2AfsW7CU7oTb1svXQkqDAPkBhHVZXPjA52Y9en+d brtzeMJsONBXZ/HkU7BexNZ5SrQiUGF1bCBSw7ZzbGVyIDxwYXVsLnJvZXNsZXJAcnViLmRl Poh7BBMRCAAjBQJTDzbHAhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQFtLXEpxr N0adkwD+KNzRjN+3gxZvDrOY47ABAFB06XM4lFzRYQy+JDJDgJYA+wa7pcSo2W8PnxbRGva5 Q1X/hB609vglzwzuw7qgMj1FuQINBFMPNo4QCACURJWG4Av5adB3/YMbhXGSSjNbANrLN2m8 /ovdqBx/pvF+1EeVg8UaHoqzmTCNOWjf5b11fQ/MzqsBp5OHWEmzXPv3en9IojoLXzgb9F4Z LFl/j+xfU4uOmyurKIKxbG2HzC/yFr2E0s0icXeMDp+kmdrtVWHikTTkSVzkEiRf6BfIZ3gu 0xR36vegSN5vqF8fF0zRo7C/96QmpjmjQxl02NDpsnyjtisp+nWYsbp1hcZr3PecSaNtcn/v hiBlKlO0aDUOj65o4JTgC8Pe4G8Hzk9bIiFqwKg6eI2HvrYcGEMMa70bJEZedAEjP/6BA2O5 dPNS8AJnYCFCxwOVnaqfAAMHCACGChurcAtQIbsN4ukQr27Bkky32sYl9HCWPlhp9dvrqQJG 4s46ArNKPL7t/k5hB6L5vLFhzT78kpPGFohF4sM/+Jp+b8TZvqfSQqvOet0K78TAn6rky3Ks uVQd5js0RWNVmFjD3NovonkR3gQl9s5gzOi9A+QnesMsKqz+mFimDVh3X6oajU4OMtcLxOEF ++hIv+kuG98fEvI9ABOm5PitWE1rdGwxx5DiM1UovlK8nC6iataAVTK15FAu3XYzoOOZpR5N cdKe1+qNBXLz7WsL+TVSFXfnK4ZQxsOY8vl1wZZi9hdGpMEoLf00xe0gIzzNMFNOUaEynZlz P6WRrstHiGEEGBEIAAkFAlMPNo4CGwwACgkQFtLXEpxrN0bDswEA2Aq8+20ke9jg6DBbiJ5W TfRAWsgy0qEM+vSIlyhvNqMA/0G4l/CwYBH/MTSUHJG0K8nKY1iGy3kd/0WK1jicEnZG Message-ID: Date: Fri, 23 Oct 2020 12:36:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] On the Insider Security of MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 10:36:50 -0000 Hi Joël, this sounds indeed promising and interesting! One point on the security of EdDSA: On 23.10.20 12:00, Joel Alwen wrote: > 2) ECDSA vs. EdDSA : We found that we could have proven stronger security if > only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produced with a bad > PRNG (i.e. not enough entropy) can result in sigs that reveal the signing keys. > EdDSA signatures are deterministic and so aren't susceptible to this. ECDSA can > also be de-randomized (RFC 6979) to avoid the problem. While EdDSA (and deterministic ECDSA) is not vulnerable to weak randomness, it can be attacked equally devastatingly via fault attacks (e.g., bit flips), which we demonstrate in [2]. Since attacks against randomness and bit flips during signing can both be practical, a compromise between the benefits of both signing variants, like XEdDSA, could probably fit better. Cheers, Paul [2] Attacking Deterministic Signature Schemes using Fault Attacks. Poddebniak, Somorovsky, Schinzel, Lochter, Rösler. https://eprint.iacr.org/2017/1014.pdf From nobody Fri Oct 23 04:03:52 2020 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 5329E3A0BA5 for ; Fri, 23 Oct 2020 04:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DoEkOxRi5yUM for ; Fri, 23 Oct 2020 04:03:49 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3060F3A0BA4 for ; Fri, 23 Oct 2020 04:03:49 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id ce10so1791626ejc.5 for ; Fri, 23 Oct 2020 04:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r0L/i8aJR9odIWatHmAEwrSc+kUxie7xkoDS6AwYi3c=; b=EUzfRMiQHb3RYQ7cE98F//XM7e7JNj6HrZiR3bbjXdeh1UinfTHfeSJ118YP7bWcsN pm1WRzw7ZCGZfOj6KuPgLqUjLhuVWDUXfIMoSVEeMoZPv6VR40wuQS+swig1FfgKQF3O SBBFLRTHpKX4mr3LjTu39q6G5uFxQ4S34dw6UJQqfT/sSpilk+oNG9ZZhd6D8P2ycaEi O8U1oeU7JHVNxSC7RzA6gYA4J2xetC68DXVkNsEOm0gF0V9CJLGu+adXW5RCE5KmNPKi 8n6WJns2uyfay9t92ZNcjpAS/0qduMTdPRJg/Twp3kA5U0DIy/1xsXzSZmMLQJc4uXzv JcKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r0L/i8aJR9odIWatHmAEwrSc+kUxie7xkoDS6AwYi3c=; b=HTV721OsVBG+RmYsVvYWkq4GuPAnkm5g1n5EKc7RZShle5M2vC1IaUpXDtv0SaW5E6 02WoFfuY4UCzkX/EIvqia7f9VUxg0iVJncBewpWvzZbk8ugHjSVAF3JWUDf55Ousrbfq aU+7OXWcnSFDVOr6G/U1GDn6R0UxwHncmuqmuG6I4XEyDzopli5u4mmZ6SKOVe2SSv3B WxhSEKj3e239bsDd06yVNENECGc2gKatC2mMwVHFFgPdAi2HbSmzMxmdOlFTJwKw6uQs Hvt7u1+2n6zr5bj5Iuiw8ihL2QGal5xkB9nEUO8jfo8UdKi2FJYa6YUgJEOdmfQhpJDK 7i3A== X-Gm-Message-State: AOAM533dIaR/bva+hSwiUKoBn3w+B6w5+ZTqYdkHun5PJfr3Y42j/OsU odg5NSlLKm8Ji64pYz1XrSzBZA== X-Google-Smtp-Source: ABdhPJyl1YOLFx3t1hxgAORmIUxvcI/HlJkkEqHSz69HFHvhIlwqnScgdGnotarucIcdK7wezUhV+A== X-Received: by 2002:a17:906:138a:: with SMTP id f10mr1436360ejc.360.1603451027232; Fri, 23 Oct 2020 04:03:47 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id g23sm586966edp.33.2020.10.23.04.03.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2020 04:03:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: <7b86078a-55dc-7d80-0a75-e900bed61694@wickr.com> Date: Fri, 23 Oct 2020 13:03:44 +0200 Cc: Messaging Layer Security WG , Jost Daniel , Marta Mularczyk Content-Transfer-Encoding: quoted-printable Message-Id: References: <7b86078a-55dc-7d80-0a75-e900bed61694@wickr.com> To: Joel Alwen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] On the Insider Security of MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 11:03:51 -0000 Joel, Marta, Daniel, Many thanks for the analysis! I will look at this in more detail, but it = sounds we should address these concerns including revisiting past = choices. Raphael > On 23 Oct 2020, at 11:59, Joel Alwen wrote: >=20 > Hey Everyone, >=20 > Daniel Jost, Marta Mularczyk and I wanted to let you know about the = results of > some analysis we've done for MLS. There's a fair bit to unpack here = (so please > forgive the long email) and we encourage you to look at the full = writeup [1] but > we'll try to summarize the most salient points here. Also at the end = we mention > some limitations of our results. >=20 > [1] Alwen, Jost, Mularczyk - On the Insider Security of MLS. = https://ia.cr/2020/1327 > =09 > What We Analyzed > ---------------- > We analyzed how the cryptographic core of MLS behaves in the face of = insider > attacks. By "core" we mean (a CGKA protocol implicit within MLS which = includes) > TreeKEM, signatures, tree hashing, parent hash, confirmation_tag, > membership_tag, transcript hashing and the basic key schedule. We only > considered the MLSPlaintext framing mode. >=20 >=20 > Insiders > -------- > By "insiders" we mean adversaries with all of the following = capabilities: > - participate in groups as a member (including by deviating from the = protocol) > - leak other parties entire local states with all their keys > - set the output of parties PRNGs (aka. "bad randomness") > - control the network completely (think: a corrupt DS) > - register/deliver arbitrary Key Packages (again: corrupt DS) > - register arbitrary Sig keys with the AS (e.g.: badly generated keys, = copied > keys, keys for which they don't know the sk, etc.) > - the adversary orchestrates the execution as they see fit: e.g. the = can tell > Alice to propose adding Bob, Charlie to commit and then have the = network deliver > packet P to Dave. > - the adversary is fully adaptive; at each moment during the execution = the adv. > can decide which action to take next based upon their entire view of = execution > up to that point. >=20 >=20 >=20 > Security Property > ----------------- > Our goal was to determine when a given epoch_secret is secure. In = other words, > given a complete execution (in particular, the adversary=E2=80=99s = actions) decide if a > particular epoch_secret is guaranteed to be secure. We encoded the = security > guarantees we could prove using a "safe predicate" which takes as = input an > execution and a particular epoch and returns true/false indicating if = that > epoch_secret is secure. >=20 >=20 > What We Found > ------------- > By and large, the privacy and authenticity guarantees are what we = hoped for from > MLS (especially with the inclusion of membership_tags for MLSPlaintext > proposals). Still, there were at least 2 surprises for us > 1) "Weak vs. Strong Tree Authentication". See subsequent email with = that > subject for more on this as we might consider changing how tree_hash = and > parent_hash are computed in light of what we found. But in a nutshell, = we show > that MLS has weaker security guarantees than maybe expected for = parties joining > a group because of how MLS defines parent_hash. We analyzed security = for the > original proposal for parent_hash and the one MLS uses now and found = that the > former provides strictly stronger guarantees for new members. Nor is = this an > issue with limited proof techniques. We found attacks that work = against MLS now > but not if we define parent_hash to include tree_hash as first = proposed. >=20 > 2) ECDSA vs. EdDSA : We found that we could have proven stronger = security if > only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produced = with a bad > PRNG (i.e. not enough entropy) can result in sigs that reveal the = signing keys. > EdDSA signatures are deterministic and so aren't susceptible to this. = ECDSA can > also be de-randomized (RFC 6979) to avoid the problem. >=20 >=20 > Other Conclusions > ----------------- > We still think that MLS would benefit significantly from: > 1) Better hardening against bad randomness. (This can be done = cheaply, simply > & doesn't have to break compatibility, yet has a clear & quantifiable = benefit > for security. PR incoming with a generic & protocol specific trick for = doing > just that...) >=20 > 2) Including a separate HPKE key in KeyPackages in DS for encrypting = the > welcome message secrets (rather than using the initial leaf HPKE key = for that > purpose as done now). >=20 >=20 > - Daniel, Jo=C3=ABl, Marta >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Some Limits Of Our Results > -------------------------- > - We analyzed security of a single honestly generated group, running > concurrently with any number of adversarially generated "fake" groups. = But we > didn't analyze how concurrent honestly generated groups might = interact. (To be > clear, that's only to keep the results tractable, not because we think = there's > some kind of deeper problem precluding meaningful security in the more = general > setting.) >=20 > - We didn't consider MLSCiphertext framing. Intuitively, that mode = "only" adds > better meta-data protection compared to MLSPLaintexts. Metadata hiding = was > outside the scope for us. We focused on privacy and authenticity for > MLSPlaintext for now with the understanding that MLSCiphertext framing = provides > at least as good security in those terms. So what we show applies to = both types > of framing. >=20 > - We didn't analyze full Secure Group Messaging, only the core CGKA > functionality. (Although we feel it's pretty easy & immediate to = extend our CGKA > results to meaningful security statements for the full SGM protocol.) = We also > don=E2=80=99t cover any of the =E2=80=9Cextended features of MLS=E2=80=9D= : e.g. exporter keys, PSKs, > external proposals & commits, state recovery procedures, protocol > downgrade/upgrades etc. MLS is a beast. Much remains to be covered. = (But we do > think that, as with SGM, the core analysis we=E2=80=99re reporting on = can reasonably > easily be extended to cover several, if not most, of those features.) = For more > on what we left out / simplified see Section 4.5 in the writeup. >=20 > - Our safe predicate isn't tight. But it only errs on the side of = caution. I.e. > whenever it says an epoch_secret is secure we have proven this to be = the case > (in our adversarial model of course). But sometimes it says an = epoch_secret is > *insecure* although it actually still is. This is due to a few things: >=20 > 1) The predicate doesn't account for parties=E2=80=99 position in = the ratchet trees. > Sometimes, an attack may or may not reveal an epoch_secret depending = on the > order of the leaves people are assigned to in the ratchet tree. For = simplicity, > our predicate always assumes the worst case ordering (from a security = perspective). >=20 > 2) The safe predicate pessimistically assumes that just 1 sig = produced by an > honest party using bad randomness already leaks the parties signing = key. Of > course, that might not really be the case, e.g. (if EdDSA is being = used, etc). >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Oct 23 08:05:56 2020 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 5FA7B3A0EC2 for ; Fri, 23 Oct 2020 08:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjjUSetekjtG for ; Fri, 23 Oct 2020 08:05:53 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 DB02D3A0EC4 for ; Fri, 23 Oct 2020 08:05:52 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id z5so2836528ejw.7 for ; Fri, 23 Oct 2020 08:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j3vnQu2ME9c19RkoVW2NHBzvF41M8CNuXNmoqHdOJ4c=; b=BlLntIkuN+eWqmAnw03VQ132pE3PMIMewq/jQlnjCin1YErKjbKkK2njav8bDVLIPR w30qOEHA1gTBzWt+fWu8e/i71Q86BI6GYDeVL1a8CkWSCc2flPKOhJC6/wtC89vIqbGI t7WEKrAorrPDs5lOK04LxY7A1uK8mVrBJj5iuqqfCfJ+K8PojGY3jUqfW4gQ+MX2ERt0 XT7DgdnlYaiicR6bzZTtmO9C+eeVQvdEKgxPkExRZ5+lrkj1NGzO1V0XQZpuAuzgQ0GT Oub2QN44Raw3svFWrxPyxhBbvRoyuZqfNNqOik2X+KxZSmPYPbOlyvn1DhOMS3gmswZY 8VKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j3vnQu2ME9c19RkoVW2NHBzvF41M8CNuXNmoqHdOJ4c=; b=KM6o3otTirjGiDP2jDMw8CJrH5E+j95lqlxlwo2OOJLmozdpPT93MHjMJvemcFN7dW ngzFmFqlE9SabKhT++fuhOyeuA0+w9xzac85G5tCeJ2HPBTmSvEshVuxCKGA1d8OXbgc YsWojVQC4QpOpV31GDDZqI3slNdg6Is+3vUz5T1xPzLjS+OTEC3dNpPAcIPQypAlw5+Q RqGPujMUPvh0clIfyy64AKrrBeGGRMupr11WDgonQPwvrS5q1whFqbp6ufKWz2iXBSrJ +ky4/zyUXMSB+TdlmtiZ0QcgB8IwePtSE5QnAc4K+N3NOdaIjICDYm4iAr3A9xQOUY0i 4nsQ== X-Gm-Message-State: AOAM530bIhJZVrA0ATcJyPpZ6mMZUj/e1wAT6dlDCaGTsebUvOoB6uNa gek7JD/XxTHJt7qkAra4W80MVzDQp5Kfq1WS X-Google-Smtp-Source: ABdhPJy/uRHHzb47iRUGXkQRs1rEzigAliJUBXSgUw+Ub3WaqcyKy/T0sY4yD9akCscKTz2wSlxDLQ== X-Received: by 2002:a17:906:b197:: with SMTP id w23mr2558568ejy.166.1603465551044; Fri, 23 Oct 2020 08:05:51 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id hb6sm964345ejb.65.2020.10.23.08.05.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2020 08:05:50 -0700 (PDT) From: Raphael Robert Message-Id: <96652990-A5DD-4D5C-8B79-73656A0C10C7@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_63E934F7-6B5E-4B4F-A474-64C764204582" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 23 Oct 2020 17:05:49 +0200 In-Reply-To: Cc: Richard Barnes , Messaging Layer Security WG To: Chelsea Komlo References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Deniability as external to the MLS protocol X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 15:05:55 -0000 --Apple-Mail=_63E934F7-6B5E-4B4F-A474-64C764204582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Richard, I=E2=80=99m fully aligned on the idea that we have to revisit past = choices and define more clearly what we want to achieve in terms of = deniability. As you say, having one way of achieving that is what we = should aim for. The lead that the core protocol should be agnostic to the question of = deniability/unlinkability also really resonates. I do however have some = concerns with the approach you propose. Concretely, it looks like you = are proposing to choose between one the following: a) Have a bootstrap protocol to distribute deniable signature keys to = all potential future members, or b) Add members to groups without being able to authenticate them right = away For me a) is not very practical, I don=E2=80=99t see how you can do that = without losing the asynchronicity of the MLS bootstrapping mechanism. = And b) is simply very dangerous, because you send encrypted messages to = members that are not authenticated. Again, I=E2=80=99m all for addressing the authentication concerns, but = if we want to claim that MLS has a deniable mode we should describe one = that is actually practical. I don=E2=80=99t have a good comprehensive = proposal to make at this point, the only thing I can think of right now = is that we reduce the scope of deniability to just cover application = messages. In that case we could say that the MLSPlaintext framing = application messages can be signed with deniable signature keys (small = spec adaptation necessary). The signing member who just have to make = sure all recipients have the deniable signature key, but that doesn=E2=80=99= t break asynchronicity, the member can just fan out those keys when = needed. With that proposal we would however punt on membership = deniability.=20 For completeness, there were quite a few talks about deniability in = different forums over the past years. Folks have very varying views on = the question, often with good arguments. We discussed concepts like = publishing signature keys after a while or using time-lock puzzles. In = certain scenarios this can work, but it is equally simple to find = scenarios where this doesn=E2=80=99t work so well. So the minimum = attempt was to limit what signatures cover, and it turns out that this = comes at a certain price. Raphael > On 22 Oct 2020, at 20:38, Chelsea Komlo = wrote: >=20 > Hi Richard, >=20 > This approach of per-conversation non-attributable signing keys = ensures "conversation/participation unlinkability", which implies = deniability. >=20 > This is certainly a viable option for implementations at a level above = MLS, with the caveat that it has sharp edges as nothing in MLS forces = signing keys to be used for exactly one group. Further, ensuring both = async conversations and single-use-keys may be tricky. >=20 > It would be great for future versions of MLS to think about how to = move deniability within the protocol itself, but most importantly I = think it is best to keep the core protocol simple to understand and = implement. Allowing deniability protections to be implemented at a layer = above MLS seems like a good compromise towards finalizing the first = version of the protocol.=20 >=20 > Best, > Chelsea >=20 > On Thu, Oct 22, 2020 at 11:50 AM Richard Barnes > wrote: > Hey all, >=20 > Some recent and soon-to-be-proposed changes involving signatures over = the group's ratchet tree have raised concerns about the deniability of = the protocol. I'd like to propose that we can safely punt deniability = to a different layer, and not worry about it in the core protocol. >=20 > The basic idea here is that signing keys only need to be denied to the = degree they are associated with an identity, so if the Authentication = Service is deniable, all artifacts generated by MLS are as well. >=20 > For example, supposed an application were set up in the following way: >=20 > * Signature keys are only used with a single group (thus so are = KeyPackages) > * MLS credentials have no meaningful identity data (e.g., = BasicCredential with identity=3DH(public_key)) > * Group members authenticate one another by exchanging signature = public keys over a 1:1 deniable channel (e.g., X3DH) >=20 > (Here we have instantiated a distributed, deniable Authentication = Service as a full mesh of 1:1 deniable channels.) In this setup, as far = as an external observer knows, the whole group could have been generated = by a single participant, which seems like a not-bad definition of = deniablity. The MLS messages could be generated by anyone holding the = relevant signature private keys, and the deniable signature key = distribution means that anyone in the group could be the holder of those = private keys. >=20 > This model is still compatible with things like pre-publishing = KeyPackages for asynchronous add. You could obviously do an "add first, = authenticate when the joiner comes online" scheme. You might also be = able to do something more proactive by pre-publishing some deniable data = along with the KeyPackage. >=20 > My goal here is to argue that there is at least one way of operating = MLS in a deniable mode, pretty much regardless of what the protocol = itself does. If this argument seems plausible to folks, it should then = be safe to make some changes that had been gated on deniability = concerns: >=20 > * Updating #406 so that the GroupPublicState is signed by the member = that issues it > * Updating the path hash / parent hash scheme as recommended in = Jo=C3=ABl's forthcoming proposal (and which I expect will look like what = Benjamin and Karthik suggested back in January) >=20 > I would also be open to adding something like the above discussion to = the architecture document, if people thought it would be useful for = posterity. >=20 > Best, > --Richard > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = >=20 >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_63E934F7-6B5E-4B4F-A474-64C764204582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Richard,

I=E2=80=99m = fully aligned on the idea that we have to revisit past choices and = define more clearly what we want to achieve in terms of deniability. As = you say, having one way of achieving that is what we should aim = for.
The lead that the core protocol should be = agnostic to the question of deniability/unlinkability also really = resonates. I do however have some concerns with the approach you = propose. Concretely, it looks like you are proposing to choose between = one the following:

a) Have a bootstrap protocol to distribute deniable signature = keys to all potential future members, or
b) Add = members to groups without being able to authenticate them right = away

For me a) = is not very practical, I don=E2=80=99t see how you can do that without = losing the asynchronicity of the MLS bootstrapping mechanism. And b) is = simply very dangerous, because you send encrypted messages to members = that are not authenticated.

Again, I=E2=80=99m all for addressing the authentication = concerns, but if we want to claim that MLS has a deniable mode we should = describe one that is actually practical. I don=E2=80=99t have a good = comprehensive proposal to make at this point, the only thing I can think = of right now is that we reduce the scope of deniability to just cover = application messages. In that case we could say that the MLSPlaintext = framing application messages can be signed with deniable signature keys = (small spec adaptation necessary). The signing member who just have to = make sure all recipients have the deniable signature key, but that = doesn=E2=80=99t break asynchronicity, the member can just fan out those = keys when needed. With that proposal we would however punt on membership = deniability. 

For completeness, there were quite a few talks about = deniability in different forums over the past years. Folks have very = varying views on the question, often with good arguments. We discussed = concepts like publishing signature keys after a while or using time-lock = puzzles. In certain scenarios this can work, but it is equally simple to = find scenarios where this doesn=E2=80=99t work so well. So the minimum = attempt was to limit what signatures cover, and it turns out that this = comes at a certain price.

Raphael


On 22 Oct 2020, at 20:38, Chelsea Komlo <chelsea.komlo@gmail.com> wrote:

Hi Richard,

This approach of per-conversation = non-attributable signing keys ensures "conversation/participation = unlinkability", which implies deniability.

This is certainly a viable option for = implementations at a level above MLS, with the caveat that it has sharp = edges as nothing in MLS forces signing keys to be used for exactly one = group. Further, ensuring both async conversations and single-use-keys = may be tricky.

It would be great for future versions of MLS to think about = how to move deniability within the protocol itself, but most importantly = I think it is best to keep the core protocol simple to understand and = implement. Allowing deniability protections to be implemented at a layer = above MLS seems like a good compromise towards finalizing the first = version of the protocol. 

Best,
Chelsea

On Thu, Oct = 22, 2020 at 11:50 AM Richard Barnes <rlb@ipv.sx> wrote:
Hey = all,

Some recent and soon-to-be-proposed = changes involving signatures over the group's ratchet tree have raised = concerns about the deniability of the protocol.  I'd like to = propose that we can safely punt deniability to a different layer, and = not worry about it in the core protocol.

The = basic idea here is that signing keys only need to be denied to the = degree they are associated with an identity, so if the Authentication = Service is deniable, all artifacts generated by MLS are as well.

For example, supposed an application were set = up in the following way:

* Signature keys = are only used with a single group (thus so are KeyPackages)
* MLS credentials have no meaningful identity data (e.g., = BasicCredential with identity=3DH(public_key))
* Group = members authenticate one another by exchanging signature public keys = over a 1:1 deniable channel (e.g., X3DH)

(Here we have instantiated a distributed, deniable = Authentication Service as a full mesh of 1:1 deniable channels.) =  In this setup, as far as an external observer knows, the whole = group could have been generated by a single participant, which seems = like a not-bad definition of deniablity.  The MLS messages could be = generated by anyone holding the relevant signature private keys, and the = deniable signature key distribution means that anyone in the group could = be the holder of those private keys.

This model is still compatible with things like = pre-publishing KeyPackages for asynchronous add.  You could = obviously do an "add first, authenticate when the joiner comes online" = scheme.  You might also be able to do something more proactive by = pre-publishing some deniable data along with the KeyPackage.

My goal here is to = argue that there is at least one way of operating MLS in a deniable = mode, pretty much regardless of what the protocol itself does.  If = this argument seems plausible to folks, it should then be safe to make = some changes that had been gated on deniability concerns:

* Updating #406 so that the GroupPublicState = is signed by the member that issues it
* Updating the path = hash / parent hash scheme as recommended in Jo=C3=ABl's forthcoming = proposal (and which I expect will look like what Benjamin and Karthik = suggested back in January)

I would also be = open to adding something like the above discussion to the architecture = document, if people thought it would be useful for posterity.

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



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

= --Apple-Mail=_63E934F7-6B5E-4B4F-A474-64C764204582-- From nobody Fri Oct 23 11:23:55 2020 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 ECA723A1092 for ; Fri, 23 Oct 2020 11:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4HryzIQTqaT for ; Fri, 23 Oct 2020 11:23:51 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 56B5F3A1030 for ; Fri, 23 Oct 2020 11:23:51 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id w25so2461536edx.2 for ; Fri, 23 Oct 2020 11:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3BmXGkmRP07OGfocwl+MJDxiWTso+l2uzmZOHXn3sPE=; b=wTbke1Fp1U8DtVEjQFYzVqYsBR1+uWrQPUOy7Hic2slkYC6OE3Nn6i5J9ULWtZG86n Ag6G+XsQDFb0kq4cViI4Nh4v29pmXLGczt53SevsnppC4ExdnlwuV0LUq211qZMIr2iZ rcZIkTooJWoe9mbJOJ/H9g8puOo+1+6vve2sjfDTVWc7zlo9ca7kA05umEwN49xxRaLm RTUisiewuFIqidQ0FeKim22pxbUuBWFGVsw4dp9iSS+X5/VXFS961JKz8DoZW8OeEVMa zluH+9p9jwwMe8F/4ZiOKA7v8SmHPh2OuRp5hAJsjRCsyie91Vk2WGMxLjdR+iWBJgw3 NFBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3BmXGkmRP07OGfocwl+MJDxiWTso+l2uzmZOHXn3sPE=; b=FRCknK6eENqOPf1eMVL6bRimORGlhHskvsK0M5mvwX0AGL/QWe5AMAFhYQYpbCbLZI CbH9MCKjWDB5E7MW6IyLekblYTqYtHhskE8WyXqGGhj4pA0IAxCslkKwMYmivTR9PZ2H qNvzBtyHXLIgvQxXRjehrVxEz7BfL0tMpWfOn89UWX+GZ5aHSv+pvi/cyoNEHYj93fIx DiT6uMAh/C93ywyecIJlO96LGHoxD8J0Mzsm8/qr3MYz8wkF3ij2Lne6eDZSvswii4XL /HLHP7rKTxPd0ZhnOPc4b3ciPlt5PPrnztEPrf759IT4xEz0Gc0DWollYJ1VY4nhUUJ8 cVfA== X-Gm-Message-State: AOAM530+6Ojf/9wtxqSjLJXwMF7XAQBTwDwE1hs3i/kwMj/MndVjizTx zJP7NhPL6MKp3yz/CB1a893lYQ== X-Google-Smtp-Source: ABdhPJwPf/rXRxruo9foiA2EdFtAOTRTKzzVB+2KaKzwjZaNev7uazaDaaQ7HTIfGNuCZjyf0xDVzg== X-Received: by 2002:a05:6402:1684:: with SMTP id a4mr3434463edv.79.1603477429263; Fri, 23 Oct 2020 11:23:49 -0700 (PDT) Received: from ?IPv6:2a02:8109:9f40:4a60:2d14:535f:5c94:33fb? ([2a02:8109:9f40:4a60:2d14:535f:5c94:33fb]) by smtp.gmail.com with ESMTPSA id u23sm1202692ejy.87.2020.10.23.11.23.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Oct 2020 11:23:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Raphael Robert In-Reply-To: Date: Fri, 23 Oct 2020 20:23:47 +0200 Cc: Messaging Layer Security WG , Jost Daniel , Marta Mularczyk Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joel Alwen X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [MLS] Weak vs. Strong Tree Authentication X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 18:23:54 -0000 Thanks for the detailed write-up! A few thoughts that came to mind when = I read it: - When we discussed the weak parent hash construction vs strong tree = hash, it was obvious that a malicious insider could create fake trees = and trick new joiners. Creating fake trees is a possibility that=E2=80=99s= always been there (and still is) in MLS: the attacker places a bunch of = KeyPackages in leaves, the attacker commits (thus populating their = direct path) and invites a new member at the same time. The new member = can only verify a parent hash/tree hash that the attacker created. The = group looks valid to the new member, but in fact all other members of = the group could be fake until we=E2=80=99ve seen an update from them. = What you now describe has a new quality (at least to me): the = impossibility evict the malicious insider from a group. - In the example you describe, it is clear that Dave did not manage to = cryptographically evict Bob from the group. What=E2=80=99s maybe worth = clarifying is that Alice and Charlie are no longer able to participate = in G2, since Bob swapped his position with Charlie. This would lead to a = different tree hash for Alice and Charlie, hence the group context would = be a different one, hence they would have different inputs to the key = schedule. They would detect that when Bob Commits (from his fake = position in the tree) to add Dave, because Bob would produce a = confirmation_tag that would look wrong to Alice and Charlie. In the end = this means that Dave thinks he ist talking to to whoever is left in the = group after he evicted Bob (in this case Alice & Charlie), while in fact = only Bob can decrypt his messages. At some point Dave might notice that = nobody else interacts with the group anymore, but the damage might = already be done if he sent messages to the group in the meantime. - Regarding External Commits: Did I get this right that your point is = that just signing GroupPublicState isn=E2=80=99t enough and that you=E2=80= =99d need the strong tree hash construction instead? - The reason why Bob couldn=E2=80=99t be evicted by Dave is because Bob = had the liberty of reshuffling the leaves. Or in other words, we can = conclude that the current parent hash does not fully protect the tree = invariant, only one aspect of it. Going for fully hashing the tree nodes = as described locks down the whole tree structure, making any reshuffling = impossible. Maybe there is a more lightweight approach that would yield = the same result without =E2=80=9Cprovid[ing] irrefutable evidence that = the signing key's owner was in a group with (at least some) of the other = members in the group=E2=80=9D, but I can=E2=80=99t think of anything = right now. - To follow up on the last point, what the current parent hash scheme = is missing, is that it doesn=E2=80=99t convey to whom the secrets in a = direct path of a member were made available. The only way to convey this = is to show who was below the heads of the copath nodes when the new node = secrets were KEMed to the copath during Commit. The full tree hash = provides that information. The unwanted side-effect is that it fully = reveals the identity of the leaves, especially their long-term identity. = If there was a way to dissociate the identity from the position of the = leaves in the tree, the side-effect might be alleviated. But again, I = don=E2=80=99t see how to achieve that right now. That=E2=80=99s all for now, I=E2=80=99ll think about this some more. Raphael > On 23 Oct 2020, at 12:00, Joel Alwen wrote: >=20 > Hey everyone, >=20 > In the course of our insider security analysis of MLS (detailed in our = previous > email titled =E2=80=9COn the Insider Security of MLS=E2=80=9D on the = list today and available > here [1]) we noticed a trade-off MLS is making between deniability and = security > that we believe merits extra attention. >=20 > MLS initially considered two "tree-signing" methods (see below), where = method 1 > seemed more secure but was less deniable than method 2. MLS went with = method 2, > since at the time additional security of method 1 was unclear. We now = have a > much clearer understanding of what we=E2=80=99re giving up by opting = for method 2 so we > wanted to share that with everyone. Put simply, method 2 provides a = fair bit > weaker security guarantees for people joining a new (possibly = adversarially > generated) group than does method 1. >=20 > [1] Alwen, Jost, Mularczyk - On the Insider Security of MLS. = https://ia.cr/2020/1327 >=20 >=20 > Two Constructions > ----------------- > In more detail, the issue centers on how the parent_hash is defined. A = party > joining a group authenticates the group=E2=80=99s ratchet tree by = verifying the sigs at > each leaf. Some of those leaves include a parent_hash value which, in = turn, > fixes values stored higher up in the ratchet tree. Intuitively, this = is meant to > provide some security guarantees to the new member. Basically, the = hope was that > if all keys in a ratchet tree are signed by group members and you = trust all the > group members you should be in a secure group. >=20 > It turns out though that exactly how parent_hash is defined is = critical to > whether we really achieve this intuition or not. We are aware of 2 = definitions > considered in the past. For lack of better terminology we'll call = them: >=20 > "weak parent_hash" : What MLS does now. parent_hash of a node only = covers the > HPKE pks on the path from root to the node. Roughly speaking, we have = that: > - root.parent_hash :=3D 0 > - node.parent_hash :=3D H(node.parent.pk, = node.parent.parent_hash). >=20 > "strong parent_hash" : Define parent_hash to include tree_hash (and = tree_hash to > *not* include parent_hash). The tree_hash of a node covers all values = in the > subtree rooted at that node (except the parent_hashes and = signatures). So > basically something like this: > - leaf.tree_hash :=3D H(leaf.data) > - node.tree_hash :=3D H(node.data, node.lchild.tree_hash, = node.rchild.tree_hash) > - root.parent_hash :=3D 0 > - node.parent_hash :=3D H(node.parent.tree_hash, = node.parent.parent_hash). >=20 >=20 > In an effort to preserve a modicum of deniability, the working group = opted for > the "weak" approach. It was felt that this way a signature at a leaf = would only > weakly bind the signing party to the session it was signing in. = Conversely, > signing a strong parent_hash would provide irrefutable evidence that = the signing > key's owner was in a group with (at least some) of the other members = in the > group. As far as we know, at the time the security implications of = this decision > (beyond deniability), were not well understood. >=20 >=20 > Different Security Guarantees > ----------------------------- > Here's what we found about these 2 variants. Consider an MLS execution = where > Alice joins a session using a valid looking welcome message and = ratchet tree > *possibly produced somehow by a malicious insider*. (Think of an = =E2=80=9Cinsider=E2=80=9D as an > attacker that can participate as a group member in MLS sessions, can = leak honest > parties states at will, and that can completely control the DS and the = AS. For a > more complete explanation of their capabilities see the email with = subject =E2=80=9COn > the Insider Security of MLS=E2=80=9D in this mailinglist.) Alice's = session continues, > e.g. parties issue proposals, commit and send application messages. >=20 > We asked ourselves: When (if ever) does the session Alice joined = become > =E2=80=9Csecure=E2=80=9D? A bit more precisely, when can we prove that = (in our adversarial > model) the epoch_secret of a given epoch E looks random to the = adversary? >=20 > We answered this by defining 2 properties of the execution that = suffice for us > to prove such a claim for any given epoch E. >=20 > Call a signature key pair "leaked" if it's secret key was either = chosen by the > adversary or explicitly revealed to the adversary in the course of a = leaking the > key=E2=80=99s owner=E2=80=99s local state. We call a ratchet tree = "bad" if at least one leaf is > assigned a leaked key pair. >=20 > - Property 1: The ratchet tree for epoch E is not bad. (When MLS uses = strong > parent_hashes then this property suffices to prove security for E.) >=20 > - Property 2: No key pair at a leaf of E was ever part of a bad = ratchet tree. > This includes ratchet tree's for other epochs in other sessions. (When = MLS uses > weak parent_hashes then this property suffices to prove security for = E.) >=20 > This difference in what we need to prove security for strong and weak = hashes is > not just a limit of our proof techniques. In fact, we can build = concrete attacks > that demonstrate the different guarantees. The attacks succeed against = weak > parent_hashes but fails against strong parent_hashes. See the end of = this email > for an example. >=20 >=20 > The Argument for Strong parent_hashes > ------------------------------------- > In our opinion the difference between the 2 properties is big. Suppose = you find > yourself in an epoch E and are trying to decide if it=E2=80=99s = secure. Property 1 means > that E=E2=80=99s security depends only on the security of the keys = involved in that > epoch; that is keys you can see belonging to parties you are aware = of. So if > you believe that everyone in E is honest and is using an unleaked key = you can > already conclude you're getting privacy. >=20 > But Property 2 means that to reach the same conclusion about E you'd = further > have to assume the same thing about all sorts of other epochs (of = other groups!) > which just happen to involve a key pair also used in E. That seems = like a *much* > worse guarantee. In particular, there's no reason to believe you'd = even be aware > of all those other groups, let alone who was in them and what keys = everyone was > using. To us, this motivates switching over to strong parent_hashing. >=20 > On the flip side we would lose the deniability benefits that the weak > parent_hashes give us now. We believe this "loss" to be worth it = though. First, > our (Jo=C3=ABl and Marta) take is that deniability is at most "nice to = have" but > nowhere near as crucial as privacy and authenticity are. Second, we = don't think > that even with weak parent_hashes we could make any claims that MLS is = deniable > in some reasonable and holistic sense. So by giving up this particular = mechanism > it doesn't look like we're really losing any general deniability = feature of the > entire protocol. If we want deniability in some form for MLS then we = believe > we'll have to revisit much of what MLS does anyway. >=20 > Thus, our take is that we'd rather have a stronger, (in particular = more locally > based) privacy guarantee when joining a new group than the incomplete > deniability guarantee we have now. >=20 >=20 >=20 > - Daniel, Jo=C3=ABl, Marta >=20 >=20 >=20 >=20 >=20 >=20 > An Attack Separating Strong from Weak parent_hashs > -------------------------------------------------- > The basic vulnerability exploited by this attack is that signing a = weak > parent_hash only authenticates the HPKE keys on a direct path but not = which > parties were then told each of the secret keys on that path. This lets = an > insider that knows many keys on a path construct a new ratchet tree = where they > seem to only know fewer of the keys (near the root). So when the party = is then > removed from this fake group some of the secrets they know will remain = part of > the group state. That in turn lets them compute epoch_secrets even = after being > removed from the group thus breaking privacy. The attack is described = bellow and > depicted in the figure attached to this email. >=20 > Suppose MLS uses weak parent_hashes. > 1) Bob is an insider attacker. He's in a group G1 with 3 leaves. =46rom = left to > right they are assigned to Alice, Bob and Charlie. Alice performs a = commit in G1 > resulting in ratchet tree T1. (Notice Bob now knows the HPKE sk at the = parent of > Alice and Bob.) >=20 > 2) Bob creates a fake ratchet tree T2 with 3 leaves as follows. He = copies all > nodes from Alice=E2=80=99s leaf to the root from T1 to T2. Next he = places a fresh key > package for Charlie the sibling leaf to Alice (i.e. Bob=E2=80=99s = former leaf in T1). > Finally he places himself in the rightmost leaf. He also samples any = values he > needs for the new groups application key schedule (e.g. an init_secret = from a > fake previous epoch). Call the resulting group G2. >=20 > 3) Next Bob creates a proposal to add Dave to G2 and commits to it = initiating a > new epoch E=E2=80=99. He produces a corresponding welcome message = which he sends to Dave. >=20 > 4) Once Dave joins, Bob proposes to remove himself from the group. = Dave commits > to the proposal which initiates epoch E. >=20 > At this point Property 1 for E is satisfied (as T2 only has Alice, = Charlie and > Dave at the leaves). But in reality, Bob still knows the HPKE sk at = the parent > of Alice and Charlie as that wasn=E2=80=99t blanked out or overwritten = when Dave did his > commit removing Bob from T2. Worse, that commit by Dave includes a = ciphertext > encrypting a secret to the sk which is intended to let Alice and = Charlie compute > the commit_secret. That lets Bob compute the commit_secret and thus = too the > epoch_secret for E. So E isn't secure. >=20 > Notice the above attack fails when MLS uses strong parent_hashes. = Copying > Alice=E2=80=99s leaf and parent node from T1 to T2 forces Bob to also = copy her sibling > leaf from T1 to T2. Bob can no longer pretend he is not the sibling of = Alice. > Thus, when Bob is removed from G2 by Dave the parent node of Alice = will be > blanked and so Dave will encrypt the secret for the grandparent = straight to > Alice=E2=80=99s leaf. In other words, Bob can no longer process the = commit and he is > truly out of G2 as intended leaving E in a secure state. >=20 > Finally, to add to the discussion in the =E2=80=9COverflow from = discussion on #406=E2=80=9D > email thread, it looks like this attack is *not* prevented by having = the > GroupKeyPackage signed (e.g. by the sender of a welcome packet =3D the = most recent > group member to commit). Dave gets the GroupKeyPackage for G2 from Bob = and Bob > can create and sign it no problem as he is in G2, knows its key = schedule and the > whole public part of T2. So everything would check out just fine for = Dave. > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Oct 23 11:28:26 2020 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 DC5583A0A07 for ; Fri, 23 Oct 2020 11:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCPCnuVniIXg for ; Fri, 23 Oct 2020 11:28:23 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04763A09EF for ; Fri, 23 Oct 2020 11:28:22 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id 188so2051173qkk.12 for ; Fri, 23 Oct 2020 11:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vaNIc/ZRvXKjSof8s49P2B4UiKn0aH9uGqOb2ar7lBs=; b=xuKn/xVKrXXm9jkiiyWV5MSJzx2bL0fqx+5tph95uyDje+l5XnJTNmF6xq3bcrFxV+ TenMC8DaGm3j6QwZzX4/BpVN0vRqSr8xC8BnCK4ciO5EGTE06HDrVULVzblmnwDYMoGr 17uEEvykiSl7tdAzErGoRVfA6oIxic5tyTsGh0l2+Tf5HLuXQyEqoj+9K83g2g/n85zR zACSFppBqbWOemdxEg+w/woGODZnW1QLGKSE1fNDZt/5FYjDyBJ61PhHCP0sqe/3r9Ew Vp3LTsYINBpqMKZQ0wfoxfo0dEJIzWYUFkkVSNIpq42ocqseTCMtTTEURFepglfI3UtV EjZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vaNIc/ZRvXKjSof8s49P2B4UiKn0aH9uGqOb2ar7lBs=; b=jbOa1UdzBxIxABArdeBXhF4/8vkYDtbvozJ2abL+ug/PfHWntyqZuHG6/PyAaD4YoB u3cl1VcM4XlSO7YVcfxUASykf/19kLsVeyq8wloIaGQH+plLSvw3ejUJn2sDkriXlIW8 1o/RMJGZYmSFwqr4vg39tMKYsBgcFBPJlvRBrxtHYlOxeVPkgnaZa79RrqzXyNDk5Pb5 CjSgsvWdsS/zcnrkbSAyWacDAo9/K7/Fyhp3WubT/+OnDT3E0wtpvpIfUKsrVEL2Owyl sD5OPBSlxcNb8kiWc0AUc5wz/50gXSvMZo3SkLIS8AyMtWzTmGmJFAbTqv9Hq5/BXtIA Td8A== X-Gm-Message-State: AOAM530wtVN6PpK8dCP+gVp6Hhvrzu+MkKQh0xqwKHsDWMtJiVBP6PET UGD6lUa9BaBpyIGc1AFClf8BHOafdGYi1YyvXTUTgMonf6o= X-Google-Smtp-Source: ABdhPJynRGBcuPgm1I/kfn+TdGCwpWhxz+YzlgQZo4GpezKla3yM5tR5N13/VZsrGtT5chgiqKb2IBuy7DsdfKVLffw= X-Received: by 2002:a37:86c4:: with SMTP id i187mr3608253qkd.371.1603477701371; Fri, 23 Oct 2020 11:28:21 -0700 (PDT) MIME-Version: 1.0 References: <5C460254-14C4-4900-9089-16D670C5424A@wire.com> In-Reply-To: <5C460254-14C4-4900-9089-16D670C5424A@wire.com> From: Richard Barnes Date: Fri, 23 Oct 2020 14:28:01 -0400 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000cbc25b05b25abec8" Archived-At: Subject: Re: [MLS] Overflow discussion on #406 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 18:28:25 -0000 --000000000000cbc25b05b25abec8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems like the only outstanding question here is whether a signature is required on GroupPublicState. That seems like a straightforward addition that we could handle during WGLC, between draft-10 and draft-11, before feature freeze. That way we can go ahead and start getting wider review while we resolve these last issues. Unless I hear an objection here before Monday US ET, I'll go ahead and merge #406 and work on getting draft-10 out the door. --Richard On Wed, Oct 21, 2020 at 11:38 AM Raphael Robert wrote: > Thanks for writing this up, see my comments inline. > > On 20 Oct 2020, at 20:53, Richard Barnes wrote: > > Our interim call went about 30min past our scheduled end time today. > Since we were without chairs for the last 30min, that time was not offici= al > WG time, so we couldn't make decisions about PRs. Luckily, we only had o= ne > PR remaining, and we couldn't come to agreement on it anyway :) > > Two remaining questions on PR#406, where the first is more important: > > 1. Should the GroupKeyPackage / GroupPublicState be signed? > > On the one hand, having a signature would remove any concerns about > copy/paste recombination of the various constituent parts. In particular= , > it would avoid the public key for one group being reused with another (up > to reuse of signature keys across groups). > > On the other hand, Raphael expressed some concern about deniability, sinc= e > this would be a public signature by a member of the group over the whole > state of the group. > > Personally, signing seems like the conservative option to me. But I > haven't done much analysis here. > > > Joel brought up a question regarding tree signatures yesterday, that he > said he=E2=80=99d describe on this list shortly. I see a lot of overlap b= etween > these discussion and would like to wait for that discussion to unfold > before jumping to conclusions here. > > > 2. Which transcript hash(es) should be included? > > (This is more of an engineering question than a security question) To > summarize how the transcript hashes / confirmation tag work: > > confirmed =3D H(interim || all_of_commit_besides_confirmation_tag) > confirmation_tag =3D MAC(confirmation_key, confirmed) > interim =3D H(confirmed || confirmation_tag) > > In a GroupInfo / Welcome based join, the joiner needs the confirmed > transcript hash but not the interim. The confirmation tag is provided in > the GroupInfo and verified by the joiner, and can then be used to compute > the interim transcript hash. (This is a side effect of #416, which moved > the signature from interim to confirmed) In other words, the joiner star= ts > at the second line above, since they don't actually see the commit. > > In an GroupPublicState / Commit based join, the joiner is computing the > commit, so they start at the first line. As a result, the joiner needs t= he > interim transcript hash, not the confirmed transcript hash. > > I have implemented these changes (removing interim from GroupInfo and > confirmed from GroupPublicState) in my draft implementation of #406 [1], > and they do work. I have filed a small spec PR to remove this [2] and > suggested the corresponding changes in #406. > > > This looks fine to me, the hashes are now swapped in the PR. > > Raphael > > > --RLB > > [1] https://github.com/cisco/mlspp/pull/118 > [2] https://github.com/mlswg/mls-protocol/pull/428 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > --000000000000cbc25b05b25abec8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems like the only outstanding question here is w= hether a signature is required on GroupPublicState.=C2=A0 That seems like a= straightforward addition that we could handle during WGLC, between draft-1= 0 and draft-11, before feature freeze.=C2=A0 That way we can go ahead and s= tart getting wider review while we resolve these last issues.

Unless I hear an objection here before Monday US ET, I'= ll go ahead and merge #406 and work on getting draft-10 out the door.
=

--Richard

On Wed, Oct 21, 2020 at 11:38 AM Raphael R= obert <raphael@wire.com> wrot= e:
Thanks for writing this up, see my comments in= line.

On 20 Oct 2020, at 20:53, = Richard Barnes <rlb@ipv.= sx> wrote:

Our interim call went= about 30min past our scheduled end time today.=C2=A0 Since we were without= chairs for the last 30min, that time was not official WG time, so we could= n't make decisions about PRs.=C2=A0 Luckily, we only had one PR remaini= ng, and we couldn't come to agreement on it anyway :)

Two remaining questions on PR#406, where the first is more importan= t:

1. Should the GroupKeyPackage / GroupPublicStat= e be signed?

On the one hand, having a signature w= ould remove any concerns about copy/paste recombination of the various cons= tituent parts.=C2=A0 In particular, it would avoid the public key for one g= roup being reused with another (up to reuse of signature keys across groups= ).

On the other hand, Raphael expressed some c= oncern about deniability, since this would be a public signature by a membe= r of the group over the whole state of the group.

= Personally, signing seems like the conservative option to me.=C2=A0 But I h= aven't done much analysis here.
=
Joel brought up a question regarding tree signatures yesterday, t= hat he said he=E2=80=99d describe on this list shortly. I see a lot of over= lap between these discussion and would like to wait for that discussion to = unfold before jumping to conclusions here.


2. Which transcript has= h(es) should be included?

(This is more of an engi= neering question than a security question)=C2=A0 To summarize how the trans= cript hashes / confirmation tag work:

confirme= d =3D H(interim || all_of_commit_besides_confirmation_tag)
confir= mation_tag =3D MAC(confirmation_key, confirmed)
interim =3D H= (confirmed || confirmation_tag)

In a GroupInfo= / Welcome based join, the joiner needs the confirmed transcript hash but n= ot the interim.=C2=A0 The confirmation tag is provided in the GroupInfo and= verified by the joiner, and can then be used to compute the interim transc= ript hash.=C2=A0 (This is a side effect of #416, which moved the signature = from interim to confirmed)=C2=A0 In other words, the joiner starts at the s= econd line above, since they don't actually see the commit.

In an GroupPublicState / Commit based join, the joiner is= computing the commit, so they start at the first line.=C2=A0 As a result, = the joiner needs the interim transcript hash, not the confirmed transcript = hash.

I have implemented these changes (removing i= nterim from GroupInfo and confirmed from GroupPublicState) in my draft impl= ementation of #406 [1], and they do work.=C2=A0 I have filed a small spec P= R to remove this [2] and suggested the corresponding changes in #406.
=

This looks fine to me, the hashes a= re now swapped in the PR.

Raphael=C2=A0

<= /blockquote> --000000000000cbc25b05b25abec8-- From nobody Fri Oct 23 13:01:18 2020 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 0E3B53A0AFA for ; Fri, 23 Oct 2020 13:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63qdfTB240EY for ; Fri, 23 Oct 2020 13:01:13 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 CADD73A0AF7 for ; Fri, 23 Oct 2020 13:01:12 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id de3so1332661qvb.5 for ; Fri, 23 Oct 2020 13:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UzAKdmtq65x6lj4v8WPaYMtpa0IYv05YQNdm/gpomeY=; b=ZcsHBWbjewy3Xn9mLJkyczCRNLMGnYU6TPAVSqjAMYLUJenoX8kNRlLAmIPYMjwEPB YvnnOCiycO1JBtEK0xTLxI6HpXitPH/lYyHxqoR57+gHknNhhQ3h5FhtsNk5U1TD1lUS ahitxXjIEzs0o1pkiA1GBF5FhXndTRyVPKTsE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UzAKdmtq65x6lj4v8WPaYMtpa0IYv05YQNdm/gpomeY=; b=j9aWwhqkned25zGZyumKLT/JHcpbf2KphGg1siegwoN5ElTKyNk/ONTykfcqtHqkON gpHRE0QS6aoHiuGVs09dzxU2TTzDr+t8ttDo8ga0p78Uau4MUycys/0zHSqWJHmhRpoO unzF464Ad0hF0mFOapU4iMrOviBHrzDCcbk8hXKW6MkLaX+4ihAyJ5YFEwubV8b9brg7 X6iCq1opMvQsfjfoREDA+0HP4AVsVyFYruYunAxL2vwHvzfEmPxG4urV8SZOj2TYxWie jfwdGvDHQV2f4dc2cY8zoWwcpEX6YExLanBDydFV8u/MUN2OHWT5TlNC/f7u7hNJSgZq Ziww== X-Gm-Message-State: AOAM532js2MKo+cfiO1hWmIldpejTtx1qEEBXlgXf7EzJ8BkVZtclpKr MxnRVuRO8agGSCz+mQ7C2vJ3Lo2QDCOF1lklU2stXA== X-Google-Smtp-Source: ABdhPJyFg9Sv4lAnu1ghhB4mKzVNxtQffiyL1PWamoghHlVjfiL2A6O2X3EPogRNQcE+KIX4bkqvwsHNRPCAL9+AoyY= X-Received: by 2002:a0c:e585:: with SMTP id t5mr811563qvm.6.1603483271571; Fri, 23 Oct 2020 13:01:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brendan McMillion Date: Fri, 23 Oct 2020 13:01:00 -0700 Message-ID: To: Raphael Robert Cc: Joel Alwen , Jost Daniel , Messaging Layer Security WG , Marta Mularczyk Content-Type: multipart/alternative; boundary="000000000000ce540705b25c0a5a" Archived-At: Subject: Re: [MLS] Weak vs. Strong Tree Authentication X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 20:01:17 -0000 --000000000000ce540705b25c0a5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Joel, Thanks as well. The bar we were having trouble meeting at the interim in NY was finding a meaningful attack that distinguished the two constructions. But since you've now done that, I definitely agree we should move to the stronger one. On Fri, Oct 23, 2020 at 11:24 AM Raphael Robert wrote: > Thanks for the detailed write-up! A few thoughts that came to mind when I > read it: > > - When we discussed the weak parent hash construction vs strong tree > hash, it was obvious that a malicious insider could create fake trees and > trick new joiners. Creating fake trees is a possibility that=E2=80=99s al= ways been > there (and still is) in MLS: the attacker places a bunch of KeyPackages i= n > leaves, the attacker commits (thus populating their direct path) and > invites a new member at the same time. The new member can only verify a > parent hash/tree hash that the attacker created. The group looks valid to > the new member, but in fact all other members of the group could be fake > until we=E2=80=99ve seen an update from them. What you now describe has a= new > quality (at least to me): the impossibility evict the malicious insider > from a group. > > - In the example you describe, it is clear that Dave did not manage to > cryptographically evict Bob from the group. What=E2=80=99s maybe worth cl= arifying > is that Alice and Charlie are no longer able to participate in G2, since > Bob swapped his position with Charlie. This would lead to a different tre= e > hash for Alice and Charlie, hence the group context would be a different > one, hence they would have different inputs to the key schedule. They wou= ld > detect that when Bob Commits (from his fake position in the tree) to add > Dave, because Bob would produce a confirmation_tag that would look wrong = to > Alice and Charlie. In the end this means that Dave thinks he ist talking = to > to whoever is left in the group after he evicted Bob (in this case Alice = & > Charlie), while in fact only Bob can decrypt his messages. At some point > Dave might notice that nobody else interacts with the group anymore, but > the damage might already be done if he sent messages to the group in the > meantime. > > - Regarding External Commits: Did I get this right that your point is tha= t > just signing GroupPublicState isn=E2=80=99t enough and that you=E2=80=99d= need the strong > tree hash construction instead? > > - The reason why Bob couldn=E2=80=99t be evicted by Dave is because Bob = had the > liberty of reshuffling the leaves. Or in other words, we can conclude tha= t > the current parent hash does not fully protect the tree invariant, only o= ne > aspect of it. Going for fully hashing the tree nodes as described locks > down the whole tree structure, making any reshuffling impossible. Maybe > there is a more lightweight approach that would yield the same result > without =E2=80=9Cprovid[ing] irrefutable evidence that the signing key's = owner was > in a group with (at least some) of the other members in the group=E2=80= =9D, but I > can=E2=80=99t think of anything right now. > > - To follow up on the last point, what the current parent hash scheme is > missing, is that it doesn=E2=80=99t convey to whom the secrets in a direc= t path of > a member were made available. The only way to convey this is to show who > was below the heads of the copath nodes when the new node secrets were > KEMed to the copath during Commit. The full tree hash provides that > information. The unwanted side-effect is that it fully reveals the identi= ty > of the leaves, especially their long-term identity. If there was a way to > dissociate the identity from the position of the leaves in the tree, the > side-effect might be alleviated. But again, I don=E2=80=99t see how to ac= hieve that > right now. > > That=E2=80=99s all for now, I=E2=80=99ll think about this some more. > > Raphael > > > On 23 Oct 2020, at 12:00, Joel Alwen wrote: > > > > Hey everyone, > > > > In the course of our insider security analysis of MLS (detailed in our > previous > > email titled =E2=80=9COn the Insider Security of MLS=E2=80=9D on the li= st today and > available > > here [1]) we noticed a trade-off MLS is making between deniability and > security > > that we believe merits extra attention. > > > > MLS initially considered two "tree-signing" methods (see below), where > method 1 > > seemed more secure but was less deniable than method 2. MLS went with > method 2, > > since at the time additional security of method 1 was unclear. We now > have a > > much clearer understanding of what we=E2=80=99re giving up by opting fo= r method > 2 so we > > wanted to share that with everyone. Put simply, method 2 provides a fai= r > bit > > weaker security guarantees for people joining a new (possibly > adversarially > > generated) group than does method 1. > > > > [1] Alwen, Jost, Mularczyk - On the Insider Security of MLS. > https://ia.cr/2020/1327 > > > > > > Two Constructions > > ----------------- > > In more detail, the issue centers on how the parent_hash is defined. A > party > > joining a group authenticates the group=E2=80=99s ratchet tree by verif= ying the > sigs at > > each leaf. Some of those leaves include a parent_hash value which, in > turn, > > fixes values stored higher up in the ratchet tree. Intuitively, this is > meant to > > provide some security guarantees to the new member. Basically, the hope > was that > > if all keys in a ratchet tree are signed by group members and you trust > all the > > group members you should be in a secure group. > > > > It turns out though that exactly how parent_hash is defined is critical > to > > whether we really achieve this intuition or not. We are aware of 2 > definitions > > considered in the past. For lack of better terminology we'll call them: > > > > "weak parent_hash" : What MLS does now. parent_hash of a node only > covers the > > HPKE pks on the path from root to the node. Roughly speaking, we have > that: > > - root.parent_hash :=3D 0 > > - node.parent_hash :=3D H(node.parent.pk, node.parent.parent_hash= ). > > > > "strong parent_hash" : Define parent_hash to include tree_hash (and > tree_hash to > > *not* include parent_hash). The tree_hash of a node covers all values i= n > the > > subtree rooted at that node (except the parent_hashes and signatures). > So > > basically something like this: > > - leaf.tree_hash :=3D H(leaf.data) > > - node.tree_hash :=3D H(node.data, node.lchild.tree_hash, > node.rchild.tree_hash) > > - root.parent_hash :=3D 0 > > - node.parent_hash :=3D H(node.parent.tree_hash, > node.parent.parent_hash). > > > > > > In an effort to preserve a modicum of deniability, the working group > opted for > > the "weak" approach. It was felt that this way a signature at a leaf > would only > > weakly bind the signing party to the session it was signing in. > Conversely, > > signing a strong parent_hash would provide irrefutable evidence that th= e > signing > > key's owner was in a group with (at least some) of the other members in > the > > group. As far as we know, at the time the security implications of this > decision > > (beyond deniability), were not well understood. > > > > > > Different Security Guarantees > > ----------------------------- > > Here's what we found about these 2 variants. Consider an MLS execution > where > > Alice joins a session using a valid looking welcome message and ratchet > tree > > *possibly produced somehow by a malicious insider*. (Think of an > =E2=80=9Cinsider=E2=80=9D as an > > attacker that can participate as a group member in MLS sessions, can > leak honest > > parties states at will, and that can completely control the DS and the > AS. For a > > more complete explanation of their capabilities see the email with > subject =E2=80=9COn > > the Insider Security of MLS=E2=80=9D in this mailinglist.) Alice's sess= ion > continues, > > e.g. parties issue proposals, commit and send application messages. > > > > We asked ourselves: When (if ever) does the session Alice joined become > > =E2=80=9Csecure=E2=80=9D? A bit more precisely, when can we prove that = (in our > adversarial > > model) the epoch_secret of a given epoch E looks random to the adversar= y? > > > > We answered this by defining 2 properties of the execution that suffice > for us > > to prove such a claim for any given epoch E. > > > > Call a signature key pair "leaked" if it's secret key was either chosen > by the > > adversary or explicitly revealed to the adversary in the course of a > leaking the > > key=E2=80=99s owner=E2=80=99s local state. We call a ratchet tree "bad"= if at least one > leaf is > > assigned a leaked key pair. > > > > - Property 1: The ratchet tree for epoch E is not bad. (When MLS uses > strong > > parent_hashes then this property suffices to prove security for E.) > > > > - Property 2: No key pair at a leaf of E was ever part of a bad ratchet > tree. > > This includes ratchet tree's for other epochs in other sessions. (When > MLS uses > > weak parent_hashes then this property suffices to prove security for E= .) > > > > This difference in what we need to prove security for strong and weak > hashes is > > not just a limit of our proof techniques. In fact, we can build concret= e > attacks > > that demonstrate the different guarantees. The attacks succeed against > weak > > parent_hashes but fails against strong parent_hashes. See the end of > this email > > for an example. > > > > > > The Argument for Strong parent_hashes > > ------------------------------------- > > In our opinion the difference between the 2 properties is big. Suppose > you find > > yourself in an epoch E and are trying to decide if it=E2=80=99s secure.= Property > 1 means > > that E=E2=80=99s security depends only on the security of the keys invo= lved in > that > > epoch; that is keys you can see belonging to parties you are aware of. > So if > > you believe that everyone in E is honest and is using an unleaked key > you can > > already conclude you're getting privacy. > > > > But Property 2 means that to reach the same conclusion about E you'd > further > > have to assume the same thing about all sorts of other epochs (of other > groups!) > > which just happen to involve a key pair also used in E. That seems like > a *much* > > worse guarantee. In particular, there's no reason to believe you'd even > be aware > > of all those other groups, let alone who was in them and what keys > everyone was > > using. To us, this motivates switching over to strong parent_hashing. > > > > On the flip side we would lose the deniability benefits that the weak > > parent_hashes give us now. We believe this "loss" to be worth it though= . > First, > > our (Jo=C3=ABl and Marta) take is that deniability is at most "nice to = have" > but > > nowhere near as crucial as privacy and authenticity are. Second, we > don't think > > that even with weak parent_hashes we could make any claims that MLS is > deniable > > in some reasonable and holistic sense. So by giving up this particular > mechanism > > it doesn't look like we're really losing any general deniability featur= e > of the > > entire protocol. If we want deniability in some form for MLS then we > believe > > we'll have to revisit much of what MLS does anyway. > > > > Thus, our take is that we'd rather have a stronger, (in particular more > locally > > based) privacy guarantee when joining a new group than the incomplete > > deniability guarantee we have now. > > > > > > > > - Daniel, Jo=C3=ABl, Marta > > > > > > > > > > > > > > An Attack Separating Strong from Weak parent_hashs > > -------------------------------------------------- > > The basic vulnerability exploited by this attack is that signing a weak > > parent_hash only authenticates the HPKE keys on a direct path but not > which > > parties were then told each of the secret keys on that path. This lets = an > > insider that knows many keys on a path construct a new ratchet tree > where they > > seem to only know fewer of the keys (near the root). So when the party > is then > > removed from this fake group some of the secrets they know will remain > part of > > the group state. That in turn lets them compute epoch_secrets even afte= r > being > > removed from the group thus breaking privacy. The attack is described > bellow and > > depicted in the figure attached to this email. > > > > Suppose MLS uses weak parent_hashes. > > 1) Bob is an insider attacker. He's in a group G1 with 3 leaves. From > left to > > right they are assigned to Alice, Bob and Charlie. Alice performs a > commit in G1 > > resulting in ratchet tree T1. (Notice Bob now knows the HPKE sk at the > parent of > > Alice and Bob.) > > > > 2) Bob creates a fake ratchet tree T2 with 3 leaves as follows. He > copies all > > nodes from Alice=E2=80=99s leaf to the root from T1 to T2. Next he plac= es a > fresh key > > package for Charlie the sibling leaf to Alice (i.e. Bob=E2=80=99s forme= r leaf in > T1). > > Finally he places himself in the rightmost leaf. He also samples any > values he > > needs for the new groups application key schedule (e.g. an init_secret > from a > > fake previous epoch). Call the resulting group G2. > > > > 3) Next Bob creates a proposal to add Dave to G2 and commits to it > initiating a > > new epoch E=E2=80=99. He produces a corresponding welcome message which= he sends > to Dave. > > > > 4) Once Dave joins, Bob proposes to remove himself from the group. Dave > commits > > to the proposal which initiates epoch E. > > > > At this point Property 1 for E is satisfied (as T2 only has Alice, > Charlie and > > Dave at the leaves). But in reality, Bob still knows the HPKE sk at the > parent > > of Alice and Charlie as that wasn=E2=80=99t blanked out or overwritten = when Dave > did his > > commit removing Bob from T2. Worse, that commit by Dave includes a > ciphertext > > encrypting a secret to the sk which is intended to let Alice and Charli= e > compute > > the commit_secret. That lets Bob compute the commit_secret and thus too > the > > epoch_secret for E. So E isn't secure. > > > > Notice the above attack fails when MLS uses strong parent_hashes. Copyi= ng > > Alice=E2=80=99s leaf and parent node from T1 to T2 forces Bob to also c= opy her > sibling > > leaf from T1 to T2. Bob can no longer pretend he is not the sibling of > Alice. > > Thus, when Bob is removed from G2 by Dave the parent node of Alice will > be > > blanked and so Dave will encrypt the secret for the grandparent straigh= t > to > > Alice=E2=80=99s leaf. In other words, Bob can no longer process the com= mit and > he is > > truly out of G2 as intended leaving E in a secure state. > > > > Finally, to add to the discussion in the =E2=80=9COverflow from discuss= ion on > #406=E2=80=9D > > email thread, it looks like this attack is *not* prevented by having th= e > > GroupKeyPackage signed (e.g. by the sender of a welcome packet =3D the > most recent > > group member to commit). Dave gets the GroupKeyPackage for G2 from Bob > and Bob > > can create and sign it no problem as he is in G2, knows its key schedul= e > and the > > whole public part of T2. So everything would check out just fine for > Dave. > > hashing.png>_______________________________________________ > > 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 > --000000000000ce540705b25c0a5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Joel,

Thanks as well. Th= e bar we were having trouble meeting at the interim in NY was finding a mea= ningful attack that distinguished the two constructions. But since you'= ve now done that, I definitely agree we should move to the stronger one.

On Fri, Oct 23, 2020 at 11:24 AM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wr= ote:
Thanks for = the detailed write-up! A few thoughts that came to mind when I read it:

=C2=A0- When we discussed the weak parent hash construction vs strong tree = hash, it was obvious that a malicious insider could create fake trees and t= rick new joiners. Creating fake trees is a possibility that=E2=80=99s alway= s been there (and still is) in MLS: the attacker places a bunch of KeyPacka= ges in leaves, the attacker commits (thus populating their direct path) and= invites a new member at the same time. The new member can only verify a pa= rent hash/tree hash that the attacker created. The group looks valid to the= new member, but in fact all other members of the group could be fake until= we=E2=80=99ve seen an update from them. What you now describe has a new qu= ality (at least to me): the impossibility evict the malicious insider from = a group.

=C2=A0- In the example you describe, it is clear that Dave did not manage t= o cryptographically evict Bob from the group. What=E2=80=99s maybe worth cl= arifying is that Alice and Charlie are no longer able to participate in G2,= since Bob swapped his position with Charlie. This would lead to a differen= t tree hash for Alice and Charlie, hence the group context would be a diffe= rent one, hence they would have different inputs to the key schedule. They = would detect that when Bob Commits (from his fake position in the tree) to = add Dave, because Bob would produce a confirmation_tag that would look wron= g to Alice and Charlie. In the end this means that Dave thinks he ist talki= ng to to whoever is left in the group after he evicted Bob (in this case Al= ice & Charlie), while in fact only Bob can decrypt his messages. At som= e point Dave might notice that nobody else interacts with the group anymore= , but the damage might already be done if he sent messages to the group in = the meantime.

- Regarding External Commits: Did I get this right that your point is that = just signing GroupPublicState isn=E2=80=99t enough and that you=E2=80=99d n= eed the strong tree hash construction instead?

=C2=A0- The reason why Bob couldn=E2=80=99t be evicted by Dave is because B= ob had the liberty of reshuffling the leaves. Or in other words, we can con= clude that the current parent hash does not fully protect the tree invarian= t, only one aspect of it. Going for fully hashing the tree nodes as describ= ed locks down the whole tree structure, making any reshuffling impossible. = Maybe there is a more lightweight approach that would yield the same result= without =E2=80=9Cprovid[ing] irrefutable evidence that the signing key'= ;s owner was in a group with (at least some) of the other members in the gr= oup=E2=80=9D, but I can=E2=80=99t think of anything right now.

=C2=A0- To follow up on the last point, what the current parent hash scheme= is missing, is that it doesn=E2=80=99t convey to whom the secrets in a dir= ect path of a member were made available. The only way to convey this is to= show who was below the heads of the copath nodes when the new node secrets= were KEMed to the copath during Commit. The full tree hash provides that i= nformation. The unwanted side-effect is that it fully reveals the identity = of the leaves, especially their long-term identity. If there was a way to d= issociate the identity from the position of the leaves in the tree, the sid= e-effect might be alleviated. But again, I don=E2=80=99t see how to achieve= that right now.

That=E2=80=99s all for now, I=E2=80=99ll think about this some more.

Raphael

> On 23 Oct 2020, at 12:00, Joel Alwen <jalwen@wickr.com> wrote:
>
> Hey everyone,
>
> In the course of our insider security analysis of MLS (detailed in our= previous
> email titled =E2=80=9COn the Insider Security of MLS=E2=80=9D on the l= ist today and available
> here [1]) we noticed a trade-off MLS is making between deniability and= security
> that we believe merits extra attention.
>
> MLS initially considered two "tree-signing" methods (see bel= ow), where method 1
> seemed more secure but was less deniable than method 2. MLS went with = method 2,
> since at the time additional security of method 1 was unclear.=C2=A0 W= e now have a
> much clearer understanding of what we=E2=80=99re giving up by opting f= or method 2 so we
> wanted to share that with everyone. Put simply, method 2 provides a fa= ir bit
> weaker security guarantees for people joining a new (possibly adversar= ially
> generated) group than does method 1.
>
> [1] Alwen, Jost, Mularczyk - On the Insider Security of MLS. https://i= a.cr/2020/1327
>
>
> Two Constructions
> -----------------
> In more detail, the issue centers on how the parent_hash is defined. A= party
> joining a group authenticates the group=E2=80=99s ratchet tree by veri= fying the sigs at
> each leaf. Some of those leaves include a parent_hash value which, in = turn,
> fixes values stored higher up in the ratchet tree. Intuitively, this i= s meant to
> provide some security guarantees to the new member. Basically, the hop= e was that
> if all keys in a ratchet tree are signed by group members and you trus= t all the
> group members you should be in a secure group.
>
> It turns out though that exactly how parent_hash is defined is critica= l to
> whether we really achieve this intuition or not. We are aware of 2 def= initions
> considered in the past. For lack of better terminology we'll call = them:
>
> "weak parent_hash"=C2=A0 =C2=A0: What MLS does now. parent_h= ash of a node only covers the
> HPKE pks on the path from root to the node. Roughly speaking, we have = that:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- root.parent_hash :=3D 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- node.parent_hash :=3D H(node.parent.pk, no= de.parent.parent_hash).
>
> "strong parent_hash" : Define parent_hash to include tree_ha= sh (and tree_hash to
> *not* include parent_hash). The tree_hash of a node covers all values = in the
> subtree rooted at that node=C2=A0 (except the parent_hashes and signat= ures). So
> basically something like this:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- leaf.tree_hash :=3D H(leaf.data)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- node.tree_hash :=3D H(node.data, node.lchi= ld.tree_hash, node.rchild.tree_hash)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- root.parent_hash :=3D 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- node.parent_hash :=3D H(node.parent.tree_h= ash, node.parent.parent_hash).
>
>
> In an effort to preserve a modicum of deniability, the working group o= pted for
> the "weak" approach. It was felt that this way a signature a= t a leaf would only
> weakly bind the signing party to the session it was signing in. Conver= sely,
> signing a strong parent_hash would provide irrefutable evidence that t= he signing
> key's owner was in a group with (at least some) of the other membe= rs in the
> group. As far as we know, at the time the security implications of thi= s decision
> (beyond deniability), were not well understood.
>
>
> Different Security Guarantees
> -----------------------------
> Here's what we found about these 2 variants. Consider an MLS execu= tion where
> Alice joins a session using a valid looking welcome message and ratche= t tree
> *possibly produced somehow by a malicious insider*. (Think of an =E2= =80=9Cinsider=E2=80=9D as an
> attacker that can participate as a group member in MLS sessions, can l= eak honest
> parties states at will, and that can completely control the DS and the= AS. For a
> more complete explanation of their capabilities see the email with sub= ject =E2=80=9COn
> the Insider Security of MLS=E2=80=9D in this mailinglist.) Alice's= session continues,
> e.g. parties issue proposals, commit and send application messages. >
> We asked ourselves: When (if ever) does the session Alice joined becom= e
> =E2=80=9Csecure=E2=80=9D? A bit more precisely, when can we prove that= (in our adversarial
> model) the epoch_secret of a given epoch E looks random to the adversa= ry?
>
> We answered this by defining 2 properties of the execution that suffic= e for us
> to prove such a claim for any given epoch E.
>
> Call a signature key pair "leaked" if it's secret key wa= s either chosen by the
> adversary or explicitly revealed to the adversary in the course of a l= eaking the
> key=E2=80=99s owner=E2=80=99s local state. We call a ratchet tree &quo= t;bad" if at least one leaf is
> assigned a leaked key pair.
>
> - Property 1: The ratchet tree for epoch E is not bad. (When MLS uses = strong
> parent_hashes then this property suffices to prove security for E.) >
> - Property 2: No key pair at a leaf of E was ever part of a bad ratche= t tree.
> This includes ratchet tree's for other epochs in other sessions. (= When MLS uses
> weak parent_hashes=C2=A0 then this property suffices to prove security= for E.)
>
> This difference in what we need to prove security for strong and weak = hashes is
> not just a limit of our proof techniques. In fact, we can build concre= te attacks
> that demonstrate the different guarantees. The attacks succeed against= weak
> parent_hashes but fails against strong parent_hashes. See the end of t= his email
> for an example.
>
>
> The Argument for Strong parent_hashes
> -------------------------------------
> In our opinion the difference between the 2 properties is big. Suppose= you find
> yourself in an epoch E and are trying to decide if it=E2=80=99s secure= . Property 1 means
> that E=E2=80=99s security depends only on the security of the keys inv= olved in that
> epoch; that is keys=C2=A0 you can see belonging to parties you are awa= re of. So if
> you believe that everyone in E is honest and is using an unleaked key = you can
> already conclude you're getting privacy.
>
> But Property 2 means that to reach the same conclusion about E you'= ;d further
> have to assume the same thing about all sorts of other epochs (of othe= r groups!)
> which just happen to involve a key pair also used in E. That seems lik= e a *much*
> worse guarantee. In particular, there's no reason to believe you&#= 39;d even be aware
> of all those other groups, let alone who was in them and what keys eve= ryone was
> using. To us, this motivates switching over to strong parent_hashing.<= br> >
> On the flip side we would lose the deniability benefits that the weak<= br> > parent_hashes give us now. We believe this "loss" to be wort= h it though. First,
> our (Jo=C3=ABl and Marta) take is that deniability is at most "ni= ce to have" but
> nowhere near as crucial as privacy and authenticity are. Second, we do= n't think
> that even with weak parent_hashes we could make any claims that MLS is= deniable
> in some reasonable and holistic sense. So by giving up this particular= mechanism
> it doesn't look like we're really losing any general deniabili= ty feature of the
> entire protocol. If we want deniability in some form for MLS then we b= elieve
> we'll have to revisit much of what MLS does anyway.
>
> Thus, our take is that we'd rather have a stronger, (in particular= more locally
> based) privacy guarantee when joining a new group than the incomplete<= br> > deniability guarantee we have now.
>
>
>
> - Daniel, Jo=C3=ABl, Marta
>
>
>
>
>
>
> An Attack Separating Strong from Weak parent_hashs
> --------------------------------------------------
> The basic vulnerability exploited by this attack is that signing a wea= k
> parent_hash only authenticates the HPKE keys on a direct path but not = which
> parties were then told each of the secret keys on that path. This lets= an
> insider that knows many keys on a path construct a new ratchet tree wh= ere they
> seem to only know fewer of the keys (near the root). So when the party= is then
> removed from this fake group some of the secrets they know will remain= part of
> the group state. That in turn lets them compute epoch_secrets even aft= er being
> removed from the group thus breaking privacy. The attack is described = bellow and
> depicted in the figure attached to this email.
>
> Suppose MLS uses weak parent_hashes.
> 1) Bob is an insider attacker. He's in a group G1 with 3 leaves. F= rom left to
> right they are assigned to Alice, Bob and Charlie. Alice performs a co= mmit in G1
> resulting in ratchet tree T1. (Notice Bob now knows the HPKE sk at the= parent of
> Alice and Bob.)
>
> 2) Bob creates a fake ratchet tree T2 with 3 leaves as follows. He cop= ies all
> nodes from Alice=E2=80=99s leaf to the root from T1 to T2. Next he pla= ces a fresh key
> package for Charlie the sibling leaf to Alice (i.e. Bob=E2=80=99s form= er leaf in T1).
> Finally he places himself in the rightmost leaf. He also samples any v= alues he
> needs for the new groups application key schedule (e.g. an init_secret= from a
> fake previous epoch). Call the resulting group G2.
>
> 3) Next Bob creates a proposal to add Dave to G2 and commits to it ini= tiating a
> new epoch E=E2=80=99. He produces a corresponding welcome message whic= h he sends to Dave.
>
> 4) Once Dave joins, Bob proposes to remove himself from the group. Dav= e commits
> to the proposal which initiates epoch E.
>
> At this point Property 1 for E is satisfied (as T2 only has Alice, Cha= rlie and
> Dave at the leaves). But in reality, Bob still knows the HPKE sk at th= e parent
> of Alice and Charlie as that wasn=E2=80=99t blanked out or overwritten= when Dave did his
> commit removing Bob from T2. Worse, that commit by Dave includes a cip= hertext
> encrypting a secret to the sk which is intended to let Alice and Charl= ie compute
> the commit_secret. That lets Bob compute the commit_secret and thus to= o the
> epoch_secret for E. So E isn't secure.
>
> Notice the above attack fails when MLS uses strong parent_hashes. Copy= ing
> Alice=E2=80=99s leaf and parent node from T1 to T2 forces Bob to also = copy her sibling
> leaf from T1 to T2. Bob can no longer pretend he is not the sibling of= Alice.
> Thus, when Bob is removed from G2 by Dave the parent node of Alice wil= l be
> blanked and so Dave will encrypt the secret for the grandparent straig= ht to
> Alice=E2=80=99s leaf. In other words, Bob can no longer process the co= mmit and he is
> truly out of G2 as intended leaving E in a secure state.
>
> Finally, to add to the discussion in the =E2=80=9COverflow from discus= sion on #406=E2=80=9D
> email thread, it looks like this attack is *not* prevented by having t= he
> GroupKeyPackage signed (e.g. by the sender of a welcome packet =3D the= most recent
> group member to commit). Dave gets the GroupKeyPackage for G2 from Bob= and Bob
> can create and sign it no problem as he is in G2, knows its key schedu= le and the
> whole public part of T2. So everything=C2=A0 would check out just fine= for Dave.
> <attack on weak parent hashing.png>_____________________________= __________________
> 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
--000000000000ce540705b25c0a5a-- From nobody Fri Oct 23 14:18:17 2020 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 BD9473A0A6F; Fri, 23 Oct 2020 14:15:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774976.5087.6585010113171592914@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:49 -0700 Archived-At: Subject: [MLS] mls - Requested session has been scheduled for IETF 109 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:53 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mls Session 1 (1:00 requested) Thursday, 19 November 2020, Session III 1600-1800 Room Name: Room 7 size: 507 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/mls.ics Request Information: --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack privacypass masque Key Participant Conflict: acme artarea dispatch perc People who must be present: Sean Turner Richard Barnes Benjamin Kaduk Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 24 07:39:19 2020 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 37F923A0C1F for ; Sat, 24 Oct 2020 07:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 ic0AI38lXbvd for ; Sat, 24 Oct 2020 07:39:15 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 E89153A0C1B for ; Sat, 24 Oct 2020 07:39:14 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id g12so6161465wrp.10 for ; Sat, 24 Oct 2020 07:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZeIYmDJ+iVcDiMyTMFWk1dhf17q0CxKJZvdGQp4xzHI=; b=Ryq4/+ZwUEz2lLfl/iFCM94clI9et6z+ularuYig6+2K7+MIn+SzjkV0CTHK7OxLgE fsQqOH+CznOSNsfFNVw/vwVjsE1eFLy4lBFKq85GGAI72vlSfKokmKqwXaWTpFS38766 xLr1rew2bfsB1cQh0hjC5pFVxM9yLs0ktwa+tqdhxDpk2MhSPlBYmFjWHu84V0uZVGTH aFnhkmzt8Udx/JuYGoVB72KgJ++88FC9rCt6iwl5H56gIIXHpwJmKl75zLjSMXMxEM6V 9nvWtL05bhMtW8pxfp7CcWzR1u99vQRDQgEckwmBYYeBq/Oi3T49DQG+zXEPoEnfP67+ rLIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ZeIYmDJ+iVcDiMyTMFWk1dhf17q0CxKJZvdGQp4xzHI=; b=LKPAWqdvE+91WV6AOEcYaW9Grp8QTt7PGu1caC9f++IoVmi8eSyPzTL3VCEHBo22Ff KpW3vjHz2Jbtt6ySyXGpctSOxsFrOY4LhqeIgkcA+aLa1YPZSZ8YTSJgmUzw3twKbSv6 iVQtx8vcJpijmLzd6f6Iicm4fIFUZ3WoJytUNluuDP6R0JQz9wqQ+t8I5aulipSgMPke 8+zpTLSkay1q19PaePW+Zp1ELtDIHzTgXONk290c2IcgRLby3Ld5xz6bq3lNZfowexKZ QcI/mCi6KjPBKw/ekqeASYZhyQUliU9Hsm+R+76NuBFbn/aUt4sDHT2KeJ2edBQuHhei Aatw== X-Gm-Message-State: AOAM533sU7JcXohqsRdHndr7gjeNPtK/1EbeAPhdmPJ618Sjo6NIZLHo GJazzMsAeqrudMrfcpV31nxR1A== X-Google-Smtp-Source: ABdhPJz5t5g1QAebUy9tf9VHijmCOsdqRIUUW8XgNwab0jawr4PL3riy/Eu88hGsT7jYqsNOmQpPVg== X-Received: by 2002:adf:9507:: with SMTP id 7mr7912519wrs.365.1603550352932; Sat, 24 Oct 2020 07:39:12 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id m14sm11470306wro.43.2020.10.24.07.39.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Oct 2020 07:39:12 -0700 (PDT) To: Raphael Robert Cc: Messaging Layer Security WG , Jost Daniel , Marta Mularczyk References: From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <16986fbd-1007-8446-5bc6-ee033473863f@wickr.com> Date: Sat, 24 Oct 2020 16:39:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] Weak vs. Strong Tree Authentication X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 14:39:17 -0000 Responding inline... On 23/10/2020 20:23, Raphael Robert wrote: > What’s maybe worth clarifying is that Alice and Charlie are no longer able to participate in G2 Yup, "fake" groups remain a possibility also using strong parent_hashes. Seems kinda unavoidable since we want MLS to support adding contacts to groups before the contact comes online. So an attacker can make a "fake" group using that feature of the protocol. What I do find kinda cool though is that even for arbitrary "fake" group (states) we still get the assurance that if your MLS client thinks you’re in a group with members you believe are honest (and didn't suffer state leakage) then you can conclude that at least have privacy, though not necessarily liveness. The possibility remains that some members may be "artificial" not even being aware of the session. What you get with strong (but not weak) parent_hashes is that u at least know *at most* those people can read your messages. (With the usual "in the adversarial model we analyzed" disclaimer.) > Or in other words, we can conclude that the current parent hash does not fully protect the tree invariant, only one aspect of it I think this is kinda the gist of the attack. Using weak parent_hashes lets an insider create a ratchet tree that passes verification by new members yet breaks the tree invariant. All the joiner really needs to verify about a ratchet tree is that for each node v some leaf L in v's subtree attests to having generated the v's HPKE keys and to whom it sent the sk. In order to decide which secrets in the group state need deprecating when we remove (or update) a member, we need to know who learnt each secret; that is who either chose or was told the secret. The "tree invariant" is a short description of that info. Reformulated, it says a key assigned to a node v is known to all users at merged leaves in v's sub-tree. Having that info in parent_hash is sufficient to make removes (and updates) work. So really, tree_hash has a ton of redundant info in it and who has which leaf doesn't matter); at least for doing removes and updates. > - Regarding External Commits: Did I get this right that your point is that just signing GroupPublicState isn’t enough and that you’d need the strong tree hash construction instead? Yeah, having the sender of the commit/welcome msg sign the new epoch's GroupPublicSate wouldn't stop the attack I outlined. But it may well stop other attacks and using a parent_hash committing to the full tree invariant would prevent the attack. > Maybe there is a more lightweight approach that would yield the same result without “provid[ing] irrefutable evidence that the signing key's owner was in a group with (at least some) of the other members in the group”, but I can’t think of anything right now. Maybe like this. - ML(node) = all leaves below node *not* in node.unmerged_leaves. - PK(node) = list of all HPKE pks at ML(node). - root.parent_hash = 0 - node.parent_hash = (node.parent.pk, PK(node.parent), node.parent.parent_hash) We use the HPKE pk of a leaf as a proxy for the identity at the leaf. Here's the rationale for this. Recall "Property 1" which should suffice to ensure privacy; namely there is no leaf with an exposed signing key pair. So thats our assumption. Suppose a joiner to accept a ratchet tree T and consider some non-blank node in v in T. The joiner must have computed the same value for PK(v) as did is authenticated via the parent_hash at a leaf bellow v. We've assumed the sig key at that leaf isn't exposed so the party at that leaf is honest (and didn't suffer state leakage). So they really sampled key pair (v.pk, v.sk) and sent it to exactly the set of HPKE keys PK(v). After that it wasn't leaked from their state and they only ever used v.sk to decrypt stuff. So, there's no way for the adv. to learn v.sk from that party. That leaves one of 3 ways for the adv. to still learn v.sk: 1) by knowing an sk for a pk \in PK(v) 2) by corrupting someone who knows v.sk 3) by having some one send them v.sk somehow. But none of those can happen. By having the joiner recompute PK(node) when verifying T we get that each pk \in PK(v) must appear in a leaf of T. By assumption that leaf is signed by an unexposed sig key, i.e. by an honest party (that hasn't suffered from state leakage). Honest parties dont send v.sk and only use it to decrypt stuff. Since there sig key is unexposed they also didnt suff from state leakage. Thus, none of the three remaining options for the adv. to learn v.sk works. Summing up, there's no way the adv. can learn v.sk. As this holds for all nodes in the tree we get that the entire ratchet tree has secure secrets which is enough to argue security for the epoch. Does that make sense? :-) As for deniability... well maybe it’s a little better to only sign the (parent_hash covering) the HPKE pk keys of the leaves in node's subtree... I dunno. I guess I can deny a ratchet tree that shows me as, say, having sent node.pk to some parties (rather the HPKE leaks at their leaves). But to deny it I have to claim the signature key at the receiving leaf was used to try and incriminate me. (Same thing if the tree shows me having received a key from someone.) So it's only "deniable" if I can plausibly argue that other sig keys in the group were used to try and frame me. Better than nothing maybe? - Joël From nobody Sun Oct 25 00:41:05 2020 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 970043A1477 for ; Sun, 25 Oct 2020 00:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=MTKKoD3Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LfmbdCtB 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 uJ28N3fCZppH for ; Sun, 25 Oct 2020 00:40:58 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B543A09D3 for ; Sun, 25 Oct 2020 00:40:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8A0BD779 for ; Sun, 25 Oct 2020 03:35:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 25 Oct 2020 03:35:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=25VEQwAcmnyz/u1YCL2p2pb1StfbwZty7Y7dplTor3o=; b=MTKKoD3Y B99XTFQ75Lgpui34p4NCc/mXjVSFowdHCYoo1VMPYeu+UKFlfAfFyhmgWdXE8Fit gZnexLdxtsbQ7v27Bm55Iv5GiPCNiiMd7+dyAmYw0AzKDQqziUFSVmQ6JJ8sQG62 UA8F+kSezrhEYVO0iD+vgNbiscfP/qz5sxV5QJZgnQgc253tTY+mqvD9w+MAP5xf WWS1UpRsxADbmg8a7/YfrsWHkG78gQVvcFQjGSW07y/odKomEpVU+NQFLrs4G9r5 FrMqdIy/PN4SHH3UY7UmerOa5v/eDGgDg1HpA72HLIsqx4Q63+bEkw2MG9pf9JWx 2mkS97t+BUHvOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=25VEQwAcmnyz/u1YCL2p2pb1Stfbw Zty7Y7dplTor3o=; b=LfmbdCtBF5msu2r9Q2PiCs5wdTVcU7LiMXLz5hkJJKiXa GdZhqFAhPSDMestMGvWEz5Xc23olwPxrwhUI3F1frep4YEP3jN2WGs7EV0slkt9m jmxdqn1zqDO3+4+kTdsxU4E98kdaT8qTWZgJAiug7fbQPP46wN/71gWZM+5L0nHj Yxk3KF/SY9w7ldKKz+uFHqo+KJ5XTPojweDp6ZF/k+pnCRfOhk5N3p4y49+zQSn8 dXGq4/V9JjAcd2KrAQHUwxu7knzjcoTRT3U5/d7EBUCtTvLZ9/vs5Z0BXat2AEKB YiZDINHP9YBnrCtDQcoo9g1wiYM6EULotUSt4dtrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeefgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepgedtrdejledrjeehrdegud enucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60.internal.cloudapp.net (unknown [40.79.75.41]) by mail.messagingengine.com (Postfix) with ESMTPA id E218C3064610 for ; Sun, 25 Oct 2020 03:35:14 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6948646022951889150==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20201025073514.E218C3064610@mailuser.nyi.internal> Date: Sun, 25 Oct 2020 03:35:14 -0400 (EDT) Archived-At: Subject: [MLS] Weekly github digest (MLS Working Group summary) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 07:41:01 -0000 --===============6948646022951889150== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+1/-0/=F0=9F=92=AC0) 1 issues created: - Track Expected Types of Deployments (by Bren2010) https://github.com/mlswg/mls-architecture/issues/75=20 * mlswg/mls-protocol (+2/-10/=F0=9F=92=AC10) 2 issues created: - Remove the concept of leaf indices (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/432=20 - Adopt TLS-Style Key Schedule (by kkohbrok) https://github.com/mlswg/mls-protocol/issues/426=20 8 issues received 10 new comments: - #432 Remove the concept of leaf indices (2 by bifurcation, kkohbrok) https://github.com/mlswg/mls-protocol/issues/432=20 - #426 Adopt TLS-Style Key Schedule (2 by bifurcation, kkohbrok) https://github.com/mlswg/mls-protocol/issues/426=20 - #411 Track Expected Types of Deployments (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/411=20 - #374 Derive an "authentication secret" (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/374 [functionality]=20 - #373 Address DoS by malicious insiders (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/373 [discussion] [editoria= l] [enhancement]=20 - #368 Proof of prior membership in the group / Resumption (1 by bifurcat= ion) https://github.com/mlswg/mls-protocol/issues/368 [enhancement] [securit= y] [work in progress]=20 - #367 Negotiate PSKs (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/367 [enhancement] [securit= y] [work in progress]=20 - #269 Randomize values in the common framing header (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/269 [enhancement] [privacy= ] [work in progress]=20 10 issues closed: - Remove the concept of leaf indices https://github.com/mlswg/mls-protoco= l/issues/432=20 - Adopt TLS-Style Key Schedule https://github.com/mlswg/mls-protocol/issu= es/426=20 - Address DoS by malicious insiders https://github.com/mlswg/mls-protocol= /issues/373 [discussion] [editorial] [enhancement]=20 - Advertize a global app generation for a sender https://github.com/mlswg= /mls-protocol/issues/160 [enhancement] [security] [work in progress]=20 - Prevent suppression of Handshake messages https://github.com/mlswg/mls-= protocol/issues/142 [enhancement]=20 - Track Expected Types of Deployments https://github.com/mlswg/mls-protoc= ol/issues/411=20 - Randomize values in the common framing header https://github.com/mlswg/= mls-protocol/issues/269 [enhancement] [privacy] [work in progress]=20 - Proof of prior membership in the group / Resumption https://github.com/= mlswg/mls-protocol/issues/368 [enhancement] [security] [work in progress]=20 - Negotiate PSKs https://github.com/mlswg/mls-protocol/issues/367 [enhanc= ement] [security] [work in progress]=20 - Derive an "authentication secret" https://github.com/mlswg/mls-protocol= /issues/374 [functionality]=20 Pull requests ------------- * mlswg/mls-protocol (+6/-13/=F0=9F=92=AC8) 6 pull requests submitted: - Secret Tree: clarifications and typos (by fxguenther) https://github.com/mlswg/mls-protocol/pull/431=20 - Allow ReInit proposals from preconfigured senders (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/430=20 - Update changelog for draft-10 (by bifurcation) https://github.com/mlswg/mls-protocol/pull/429=20 - Remove interim transcript hash from GroupInfo (by bifurcation) https://github.com/mlswg/mls-protocol/pull/428=20 - Groupcontext as context (by kkohbrok) https://github.com/mlswg/mls-protocol/pull/427=20 - RLB edit (by bifurcation) https://github.com/mlswg/mls-protocol/pull/425=20 5 pull requests received 8 new comments: - #431 Secret Tree: clarifications and typos (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/431 [editorial]=20 - #423 Remove encrypted sender data from ciphertext AAD. (4 by Bren2010, = bifurcation) https://github.com/mlswg/mls-protocol/pull/423=20 - #422 No redundant ciphertexts (1 by raphaelrobert) https://github.com/mlswg/mls-protocol/pull/422=20 - #419 Authentication Secret (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/419=20 - #337 Replace DKDF by n-PRF in key schedule; minor fix (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/337 [discussion] [key schedu= le] [security] [work in progress]=20 13 pull requests merged: - Update changelog for draft-10 https://github.com/mlswg/mls-protocol/pull/429=20 - Secret Tree: clarifications and typos https://github.com/mlswg/mls-protocol/pull/431 [editorial]=20 - Review PSK PR. https://github.com/mlswg/mls-protocol/pull/421=20 - Remove interim transcript hash from GroupInfo https://github.com/mlswg/mls-protocol/pull/428=20 - Allow ReInit proposals from preconfigured senders https://github.com/mlswg/mls-protocol/pull/430=20 - Allow proposals by value in Commit https://github.com/mlswg/mls-protocol/pull/414=20 - No redundant ciphertexts https://github.com/mlswg/mls-protocol/pull/422=20 - Remove encrypted sender data from ciphertext AAD. https://github.com/mlswg/mls-protocol/pull/423=20 - Groupcontext as context https://github.com/mlswg/mls-protocol/pull/427=20 - RLB edit https://github.com/mlswg/mls-protocol/pull/425=20 - Update paragraph about handshake key schedule. https://github.com/mlswg/mls-protocol/pull/424=20 - make IANA reference for Signature Schemes more precise https://github.com/mlswg/mls-protocol/pull/415=20 - Authentication Secret https://github.com/mlswg/mls-protocol/pull/419=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6948646022951889150== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday October 25, 2020

Issues

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

1 issues created:

mlswg/mls-protocol (+2/-10/=F0=9F=92=AC10)

2 issues created:

8 issues received 10 new comments:

10 issues closed:

Pull requests

mlswg/mls-protocol (+6/-13/=F0=9F=92=AC8)

6 pull requests submitted:

5 pull requests received 8 new comments:

13 pull requests merged:

Repositories tracked by this digest:

--===============6948646022951889150==-- From nobody Mon Oct 26 05:57:47 2020 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 35C0A3A0AB8 for ; Mon, 26 Oct 2020 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-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 nqgAczQFRlVm for ; Mon, 26 Oct 2020 05:57:44 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA26F3A0ABB for ; Mon, 26 Oct 2020 05:57:44 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id a6so7812889edx.6 for ; Mon, 26 Oct 2020 05:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h1UUaC0XrhNAPUHOrzm0SbVQNLQexSD8L6BMOthWG/g=; b=LO6UjfZGWZXKRnFIUhPUkRHz+sI9VS9gnt9hBd3/SQPTm0txTd5B51Rdg52A8WYMbX DAnVori68WkbPb+lKoaXFsRvOeMKQZVAuFv1dUwo+jCLQWtY8JNV55+d0wSSY4GICjsR buihEam9Mf1VzVELVFcJ8TH/IWEjt0FguDi0J41lqCLblAD6l+DK+YyF3p/MNjHY9oO+ 7ABPiBuqdRyJbGSv4KRqAcoBFECbbeMURtwXiEGasbf3dURm1tuI1W4QU9QGcXjARdwf +6urBAGQgkt1S0qd7M08wobV+f7srkE87MfKQES67yHXnksalows8l11I9k+xp8Mw9Z0 K2Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=h1UUaC0XrhNAPUHOrzm0SbVQNLQexSD8L6BMOthWG/g=; b=c3CupOhC8nlDB4mgUV7nDrZZ4MfUN6G0vDpXLIBE7mAKBT4gPoJLf14Vl+CDNx4Zhp Lg4kKRAospBUMvu5SDbPDAofAELPcuF3r8UmhhBFhu52vhPqGy6K0DLTzRzRXDHSvtLX 0W3L1nh4lZSk2hzJhqf0NZPxXX3xIvqmgmu1iY3HAiO2bz4fH/r8DavCUuFZOl5APe05 RgAMNOGwSEnkEGJBld99czFy+P7NkfnrfzWDjA3i7aXtLStY09L5KxlTsnEHVEzIbF05 zhnrql3Yu7SKTbGzaVNMAdKHJVkfRo4CFSDZzvcfRbOofnUVwg2XKS+Kp6Kd4N72wHDD vzKA== X-Gm-Message-State: AOAM5338MOFUNtJ8P9+b7JfhtH8A/vwMY5yk7JkTD/uxfxqSTXZZMcyf Yg3ryqjrmjqbhgx31XvExx12fQ== X-Google-Smtp-Source: ABdhPJwzla0QycMAGwAxvl6yh2NyLfZeEkvRc+9x+QdazXkfd4ByItHXKK+6q3IdpukF0XKNpZ3S/A== X-Received: by 2002:a05:6402:7d3:: with SMTP id u19mr16120226edy.65.1603717062971; Mon, 26 Oct 2020 05:57:42 -0700 (PDT) Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id w1sm5788604ejv.82.2020.10.26.05.57.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 05:57:42 -0700 (PDT) To: =?UTF-8?Q?Paul_R=c3=b6sler?= , mls@ietf.org Cc: Jost Daniel , Marta Mularczyk References: From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: Date: Mon, 26 Oct 2020 13:57:41 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] On the Insider Security of MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 12:57:46 -0000 Yeah, EdDSA, and especially (randomized) ECDSA, really aren't ideal choices from a security perspective. But I think their main advantage over other schemes (like XEdDSA) is that they are widely implemented (at production quality) and even part of various standards (e.g. FIPS) which people have to adhere to. For MLS that's available implementations are a must. (Thats why MLS doesn't use UPKE like in rTreeKEM though the security benefits are clear.) Do you happen to know if there are any alternative schemes with better properties (like XEdDSA) that have at least some amount of production quality implementations? - Joël On 23/10/2020 12:36, Paul Rösler wrote: > Hi Joël, > > this sounds indeed promising and interesting! One point on the security > of EdDSA: > > On 23.10.20 12:00, Joel Alwen wrote: >> 2) ECDSA vs. EdDSA : We found that we could have proven stronger security if >> only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produced with a bad >> PRNG (i.e. not enough entropy) can result in sigs that reveal the signing keys. >> EdDSA signatures are deterministic and so aren't susceptible to this. ECDSA can >> also be de-randomized (RFC 6979) to avoid the problem. > > While EdDSA (and deterministic ECDSA) is not vulnerable to weak > randomness, it can be attacked equally devastatingly via fault attacks > (e.g., bit flips), which we demonstrate in [2]. Since attacks against > randomness and bit flips during signing can both be practical, a > compromise between the benefits of both signing variants, like XEdDSA, > could probably fit better. > > Cheers, > Paul > > [2] Attacking Deterministic Signature Schemes using Fault Attacks. > Poddebniak, Somorovsky, Schinzel, Lochter, Rösler. > https://eprint.iacr.org/2017/1014.pdf > From nobody Mon Oct 26 14:55:13 2020 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 0A5A83A0F4D for ; Mon, 26 Oct 2020 14:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1pZas9_dQU5 for ; Mon, 26 Oct 2020 14:55:09 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DF93A1039 for ; Mon, 26 Oct 2020 14:55:09 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id k9so9933261qki.6 for ; Mon, 26 Oct 2020 14:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+6CRmlrQG+/macBrfotXNaQdL7Wrv95Xn2V1BceK0D0=; b=xRbivG9uJGm4fUbF8h/8YJbA0lFEIYhX0zZret7FYB2OPDlgXAlJqqRiM/XvkBZcow kTOUUgKfUpbbnSNhqrFu6rI28b3slJSQKneOxDWotPORr8/K/94OjKN9MPcOHNXELfQe /2l25F0jmdlj5rRHk1LeUSp23jMMY0usQzyrzvTBbPLRuSsfIC7jECFxzzl4hreI1xsM dPpgu6biEPUmVuL/Dxlx/WW2dVEBDrM9WKdpWrnZP3rN71+fG0w4g38DbkltX0vSipBo nwUYn5iIUl57tHz1sIZ+GGRRLHL+PbgtpZCl09IsJAzHdQ/to/VJlvOHWaolPK5doWlP 47Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+6CRmlrQG+/macBrfotXNaQdL7Wrv95Xn2V1BceK0D0=; b=N0aOh078FmpiBpAotEI66Zafo5bAz/AI6xdqZ0SXiBSjDZ89girkgpGcuTAi5eeiW2 uqqqTDj/QnT5CqNvra+mZe0BNq+RSQT3gd3bh/sU3z99DGtkZO5W9hcBBRc6bzenKwVK wveYZfLM0twWqOTvuRujH765E1tZHoCEwmh+QGD6IC/DbbpMzOp8SEM4A7624o+JDhMf 7+G/M/et01kuhoRiR+Cg5GpkONujz47mzLhZK9o/JN4e38ynI2fSacXTSiJtLsglCtzu P0VeGqFMwaPzVYHumkqPrYL6m3kGcIz3wLldVRlzjQlkjHJ2qDDaS27cIj4UijEj0OWr HLLw== X-Gm-Message-State: AOAM5306LDoyKDt+Bh53K2y5NYL6zlB3CwMxvqFNzqIXI0lLPGbmf9i4 eDryihASA3jGB7WlxfaaQDoCMqO9YPdEYRQZ6NjkGQ== X-Google-Smtp-Source: ABdhPJxTZIxuj1rZ2JPhKFsQwj0FM9Nm12+FyRVAl5knozN96YojA3IAkG4uPNOq6O6czYTfjMJnsaMsotrObODC9Z4= X-Received: by 2002:a37:86c4:: with SMTP id i187mr19491862qkd.371.1603749308026; Mon, 26 Oct 2020 14:55:08 -0700 (PDT) MIME-Version: 1.0 References: <5C460254-14C4-4900-9089-16D670C5424A@wire.com> In-Reply-To: From: Richard Barnes Date: Mon, 26 Oct 2020 17:54:55 -0400 Message-ID: To: Raphael Robert Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d0631a05b299fbe3" Archived-At: Subject: Re: [MLS] Overflow discussion on #406 X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 21:55:13 -0000 --000000000000d0631a05b299fbe3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey all, I didn't hear an objection, but Jo=C3=ABl did point out a pretty significan= t risk to me of not having a signature over at least the HPKE public key in the GroupPublicState. So I have merged #406 and posted #433 as a follow-up to add a signature over the group ID, epoch, and HPKE public key. https://github.com/mlswg/mls-protocol/pull/433 Please send any comments on that by Wednesday US ET. If there are no objections by then, I'll merge that, issue draft-10, and ask the chairs to issue WGLC on draft-10. While we're in WGLC, we have at least two issues to discuss: 1. Is the signature in #433 sufficient, or should it cover more of the GroupPublicState? 2. How should we refactor the tree signing / parent hash scheme to address the issues raised by Jo=C3=ABl, Daniel, and Marta? Cheers, --Richard On Fri, Oct 23, 2020 at 2:28 PM Richard Barnes wrote: > It seems like the only outstanding question here is whether a signature i= s > required on GroupPublicState. That seems like a straightforward addition > that we could handle during WGLC, between draft-10 and draft-11, before > feature freeze. That way we can go ahead and start getting wider review > while we resolve these last issues. > > Unless I hear an objection here before Monday US ET, I'll go ahead and > merge #406 and work on getting draft-10 out the door. > > --Richard > > On Wed, Oct 21, 2020 at 11:38 AM Raphael Robert wrote: > >> Thanks for writing this up, see my comments inline. >> >> On 20 Oct 2020, at 20:53, Richard Barnes wrote: >> >> Our interim call went about 30min past our scheduled end time today. >> Since we were without chairs for the last 30min, that time was not offic= ial >> WG time, so we couldn't make decisions about PRs. Luckily, we only had = one >> PR remaining, and we couldn't come to agreement on it anyway :) >> >> Two remaining questions on PR#406, where the first is more important: >> >> 1. Should the GroupKeyPackage / GroupPublicState be signed? >> >> On the one hand, having a signature would remove any concerns about >> copy/paste recombination of the various constituent parts. In particula= r, >> it would avoid the public key for one group being reused with another (u= p >> to reuse of signature keys across groups). >> >> On the other hand, Raphael expressed some concern about deniability, >> since this would be a public signature by a member of the group over the >> whole state of the group. >> >> Personally, signing seems like the conservative option to me. But I >> haven't done much analysis here. >> >> >> Joel brought up a question regarding tree signatures yesterday, that he >> said he=E2=80=99d describe on this list shortly. I see a lot of overlap = between >> these discussion and would like to wait for that discussion to unfold >> before jumping to conclusions here. >> >> >> 2. Which transcript hash(es) should be included? >> >> (This is more of an engineering question than a security question) To >> summarize how the transcript hashes / confirmation tag work: >> >> confirmed =3D H(interim || all_of_commit_besides_confirmation_tag) >> confirmation_tag =3D MAC(confirmation_key, confirmed) >> interim =3D H(confirmed || confirmation_tag) >> >> In a GroupInfo / Welcome based join, the joiner needs the confirmed >> transcript hash but not the interim. The confirmation tag is provided i= n >> the GroupInfo and verified by the joiner, and can then be used to comput= e >> the interim transcript hash. (This is a side effect of #416, which move= d >> the signature from interim to confirmed) In other words, the joiner sta= rts >> at the second line above, since they don't actually see the commit. >> >> In an GroupPublicState / Commit based join, the joiner is computing the >> commit, so they start at the first line. As a result, the joiner needs = the >> interim transcript hash, not the confirmed transcript hash. >> >> I have implemented these changes (removing interim from GroupInfo and >> confirmed from GroupPublicState) in my draft implementation of #406 [1], >> and they do work. I have filed a small spec PR to remove this [2] and >> suggested the corresponding changes in #406. >> >> >> This looks fine to me, the hashes are now swapped in the PR. >> >> Raphael >> >> >> --RLB >> >> [1] https://github.com/cisco/mlspp/pull/118 >> [2] https://github.com/mlswg/mls-protocol/pull/428 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> --000000000000d0631a05b299fbe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I didn't hear a= n objection, but Jo=C3=ABl did point out a pretty significant risk to me of= not having a signature over at least the HPKE public key in the GroupPubli= cState.=C2=A0 So I have merged #406 and posted #433 as a follow-up to add a= signature over the group ID, epoch, and HPKE public key.

Please send any comments on that by Wednesday US ET.=C2=A0 If = there are no objections by then, I'll merge that, issue draft-10, and a= sk the chairs to issue WGLC on draft-10.

While we&= #39;re in WGLC, we have at least two issues to discuss:
1. Is the= signature in #433 sufficient, or should it cover more of the GroupPublicSt= ate?
2. How should we refactor the tree signing / parent hash= scheme to address the issues raised by Jo=C3=ABl, Daniel, and Marta?
=

Cheers,
--Richard


On = Fri, Oct 23, 2020 at 2:28 PM Richard Barnes <rlb@ipv.sx> wrote:
It seems like the only outstanding quest= ion here is whether a signature is required on GroupPublicState.=C2=A0 That= seems like a straightforward addition that we could handle during WGLC, be= tween draft-10 and draft-11, before feature freeze.=C2=A0 That way we can g= o ahead and start getting wider review while we resolve these last issues.<= br>

Unless I hear an objection here before Monday = US ET, I'll go ahead and merge #406 and work on getting draft-10 out th= e door.

--Richard

On Wed, Oct 21, 2020 at 11:38= AM Raphael Robert <raphael@wire.com> wrote:
Thanks for writing this up, see my comments inline.<= br>

On 20 Oct 2020, at 20:53, Richar= d Barnes <rlb@ipv.sx= > wrote:

Our interim call went about= 30min past our scheduled end time today.=C2=A0 Since we were without chair= s for the last 30min, that time was not official WG time, so we couldn'= t make decisions about PRs.=C2=A0 Luckily, we only had one PR remaining, an= d we couldn't come to agreement on it anyway :)

Two remaining questions on PR#406, where the first is more important:

1. Should the GroupKeyPackage / GroupPublicState be s= igned?

On the one hand, having a signature would r= emove any concerns about copy/paste recombination of the various constituen= t parts.=C2=A0 In particular, it would avoid the public key for one group b= eing reused with another (up to reuse of signature keys across groups).
=

On the other hand, Raphael expressed some concern= about deniability, since this would be a public signature by a member of t= he group over the whole state of the group.

Person= ally, signing seems like the conservative option to me.=C2=A0 But I haven&#= 39;t done much analysis here.

Joel brought up a question regarding tree signatures yesterday, that he= said he=E2=80=99d describe on this list shortly. I see a lot of overlap be= tween these discussion and would like to wait for that discussion to unfold= before jumping to conclusions here.


2. Which transcript hash(es) sh= ould be included?

(This is more of an engineering = question than a security question)=C2=A0 To summarize how the transcript ha= shes / confirmation tag work:

confirmed =3D H(= interim || all_of_commit_besides_confirmation_tag)
confirmation_t= ag =3D MAC(confirmation_key, confirmed)
interim =3D H(confirm= ed || confirmation_tag)

In a GroupInfo / Welco= me based join, the joiner needs the confirmed transcript hash but not the i= nterim.=C2=A0 The confirmation tag is provided in the GroupInfo and verifie= d by the joiner, and can then be used to compute the interim transcript has= h.=C2=A0 (This is a side effect of #416, which moved the signature from int= erim to confirmed)=C2=A0 In other words, the joiner starts at the second li= ne above, since they don't actually see the commit.

<= /div>
In an GroupPublicState / Commit based join, the joiner is computi= ng the commit, so they start at the first line.=C2=A0 As a result, the join= er needs the interim transcript hash, not the confirmed transcript hash.

I have implemented these changes (removing interim f= rom GroupInfo and confirmed from GroupPublicState) in my draft implementati= on of #406 [1], and they do work.=C2=A0 I have filed a small spec PR to rem= ove this [2] and suggested the corresponding changes in #406.

This looks fine to me, the hashes are now s= wapped in the PR.

Raphael=C2=A0

<= /blockquote>
--000000000000d0631a05b299fbe3-- From nobody Thu Oct 29 11:22:15 2020 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 1FF773A07D3 for ; Thu, 29 Oct 2020 11:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7dIFzI9X2r4 for ; Thu, 29 Oct 2020 11:22:12 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 284973A097D for ; Thu, 29 Oct 2020 11:22:12 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id v19so4015647edx.9 for ; Thu, 29 Oct 2020 11:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMApxUqcxAy7E3UBkRY1WJUh1fqcANk0uRoxQrWmY90=; b=ZmV4EmpMmZPAi9hVg8yC43VGCZZYHfGg+EV8D0ByqG3L46LOzYHeKVLoEOIIenFhib MW6du0Y1uhXcDXgrs22WWrwKntjEzeQiGgEp7qkuKSCUFbeMqIY+4Z2Q9cCjQcDbXO3e JG6k/eFDfmdGaXMe6gVstWlGNjettMRt+ZdGPVnTAokazqdmXD2dGXwEvdZMMMrHAJX4 vF0/2R/Qu/pfSgZflaSyOkzYWRHXHYeyOFZY/4mW0IjXmbdvc9Va3TNXEbUG6vObkfh0 aMC6i0AFfqY2yyom1GpQeCiGVbBpqiuKLOh66R8HnC92gTvAJKQyvHk7egorJ9KJwErP EKwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jMApxUqcxAy7E3UBkRY1WJUh1fqcANk0uRoxQrWmY90=; b=pezyTfa6e/t3xFwRXQegQ8o+Bw508isKFXAj+rR1SVqoVXxzdycVhRYAX6VSD4SYLJ t4vEnLxNB6WIP3tBW6xv/lplL1rTNbMKxXjx1vuRvXl0QbxP9aVU0hEg3C9Oq8xedhfa 9VGktXf0BzW7XENGb/8iBI7pu2D7GNfhmBc3EybdYnJLFYjiKKyo4SrDq2ccw93gHplk R7pooP/H19RsaCiCgzwOSgbGSkM16AlVanVaYgxD+A0vzN7HY+IH0J/9e22LVCt6wmSC PGaFOtQBcNimlsFIb5kGPRZqkhR3hISkLuaTOvKnJFePMDGBdgWioKqVhaBYeiY8rPVe 4zJg== X-Gm-Message-State: AOAM53254ONSpD1u0AJkuVABw0RGAcDJo1FdkZhIMLMjqxoH7a08LSal gz8p/carlH/kZN5O18wFOtHg8EKfsUGoixwtwWQ= X-Google-Smtp-Source: ABdhPJxoUzxU2lLsQzj2hrnnuhwCyA1H31GP5k1WhAgQIYJboRtFHKlXEFEyTF8XEujK1RFdf4U5x6Ky/hQTYPamoJc= X-Received: by 2002:aa7:d404:: with SMTP id z4mr5266384edq.334.1603995730562; Thu, 29 Oct 2020 11:22:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Natanael Date: Thu, 29 Oct 2020 19:21:59 +0100 Message-ID: To: Joel Alwen Cc: =?UTF-8?B?UGF1bCBSw7ZzbGVy?= , mls@ietf.org, Jost Daniel , Marta Mularczyk Content-Type: multipart/alternative; boundary="000000000000bdd7e505b2d35b85" Archived-At: Subject: Re: [MLS] On the Insider Security of MLS X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 18:22:14 -0000 --000000000000bdd7e505b2d35b85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Randomness Improvements for Security Protocols - randomness wrapper, for use with deterministic signatures https://tools.ietf.org/html/rfc8937 Does this have the properties you need? Den m=C3=A5n 26 okt. 2020 13:57Joel Alwen skrev: > Yeah, EdDSA, and especially (randomized) ECDSA, really aren't ideal > choices from > a security perspective. But I think their main advantage over other schem= es > (like XEdDSA) is that they are widely implemented (at production quality) > and > even part of various standards (e.g. FIPS) which people have to adhere to= . > For > MLS that's available implementations are a must. (Thats why MLS doesn't > use UPKE > like in rTreeKEM though the security benefits are clear.) > > Do you happen to know if there are any alternative schemes with better > properties (like XEdDSA) that have at least some amount of production > quality > implementations? > > - Jo=C3=ABl > > On 23/10/2020 12:36, Paul R=C3=B6sler wrote: > > Hi Jo=C3=ABl, > > > > this sounds indeed promising and interesting! One point on the security > > of EdDSA: > > > > On 23.10.20 12:00, Joel Alwen wrote: > >> 2) ECDSA vs. EdDSA : We found that we could have proven stronger > security if > >> only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produced > with a bad > >> PRNG (i.e. not enough entropy) can result in sigs that reveal the > signing keys. > >> EdDSA signatures are deterministic and so aren't susceptible to this. > ECDSA can > >> also be de-randomized (RFC 6979) to avoid the problem. > > > > While EdDSA (and deterministic ECDSA) is not vulnerable to weak > > randomness, it can be attacked equally devastatingly via fault attacks > > (e.g., bit flips), which we demonstrate in [2]. Since attacks against > > randomness and bit flips during signing can both be practical, a > > compromise between the benefits of both signing variants, like XEdDSA, > > could probably fit better. > > > > Cheers, > > Paul > > > > [2] Attacking Deterministic Signature Schemes using Fault Attacks. > > Poddebniak, Somorovsky, Schinzel, Lochter, R=C3=B6sler. > > https://eprint.iacr.org/2017/1014.pdf > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000bdd7e505b2d35b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Randomness Improvements for Security Pr= otocols - randomness wrapper, for use with deterministic signatures=C2=A0


=
Does this have the properties you need?=C2=A0
=
Den m= =C3=A5n 26 okt. 2020 13:57Joel Alwen <jalwen@wickr.com> skrev:
Y= eah, EdDSA, and especially (randomized) ECDSA, really aren't ideal choi= ces from
a security perspective. But I think their main advantage over other schemes=
(like XEdDSA) is that they are widely implemented (at production quality) a= nd
even part of various standards (e.g. FIPS) which people have to adhere to. = For
MLS that's available implementations are a must. (Thats why MLS doesn&#= 39;t use UPKE
like in rTreeKEM though the security benefits are clear.)

Do you happen to know if there are any alternative schemes with better
properties (like XEdDSA) that have at least some amount of production quali= ty
implementations?

- Jo=C3=ABl

On 23/10/2020 12:36, Paul R=C3=B6sler wrote:
> Hi Jo=C3=ABl,
>
> this sounds indeed promising and interesting! One point on the securit= y
> of EdDSA:
>
> On 23.10.20 12:00, Joel Alwen <jalwen@wickr.com> wrote:
>>=C2=A0 2) ECDSA vs. EdDSA : We found that we could have proven stro= nger security if
>> only EdDSA were used vs. if ECDSA is permitted. ECDSA sigs produce= d with a bad
>> PRNG (i.e. not enough entropy) can result in sigs that reveal the = signing keys.
>> EdDSA signatures are deterministic and so aren't susceptible t= o this. ECDSA can
>> also be de-randomized (RFC 6979) to avoid the problem.
>
> While EdDSA (and deterministic ECDSA) is not vulnerable to weak
> randomness, it can be attacked equally devastatingly via fault attacks=
> (e.g., bit flips), which we demonstrate in [2]. Since attacks against<= br> > randomness and bit flips during signing can both be practical, a
> compromise between the benefits of both signing variants, like XEdDSA,=
> could probably fit better.
>
> Cheers,
> Paul
>
> [2] Attacking Deterministic Signature Schemes using Fault Attacks.
> Poddebniak, Somorovsky, Schinzel, Lochter, R=C3=B6sler.
> https://eprint.iacr.org/2017/1014.pdf
>

_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000bdd7e505b2d35b85-- From nobody Sat Oct 31 13:35:39 2020 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 1966F3A0EA5; Sat, 31 Oct 2020 13:35:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <160417653705.18617.10284935812888787728@ietfa.amsl.com> Date: Sat, 31 Oct 2020 13:35:37 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-protocol-10.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 20:35:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Protocol Authors : Richard Barnes Benjamin Beurdouche Jon Millican Emad Omara Katriel Cohn-Gordon Raphael Robert Filename : draft-ietf-mls-protocol-10.txt Pages : 85 Date : 2020-10-31 Abstract: Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-protocol-10 https://datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-protocol-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/