From nobody Thu Jul 2 17:22:34 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 9140C3A0A1E; Thu, 2 Jul 2020 17:20:35 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563558.30173.12468981113166304018@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:35 -0700 Archived-At: Subject: [MLS] mls - Requested session has been scheduled for IETF 108 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, 03 Jul 2020 00:20:46 -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 (0:50 requested) Tuesday, 28 July 2020, Session II 1300-1350 Room Name: Room 7 size: 7 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/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): 50 Minutes Number of Attendees: None Conflicts to Avoid: Chair Conflict: cfrg pearg tls quic wpack privacypass 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 Mon Jul 6 10:04:40 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 66B443A1578 for ; Mon, 6 Jul 2020 10:04:39 -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 (4096-bit key) header.d=matrix.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShJ0l6ZafPhp for ; Mon, 6 Jul 2020 10:04:38 -0700 (PDT) Received: from polemos.matrix.org (polemos.matrix.org [94.237.46.156]) (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 4A14B3A16F3 for ; Mon, 6 Jul 2020 10:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matrix.org; s=polemos; h=Content-Transfer-Encoding:From:Message-ID:Subject:Date: MIME-Version:To:Content-Type:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eepxV/3K9HPH7QuPK8cxNTrBdG+Kbp45cwsjhw+bQCI=; b=1sxl1ZW00JJB940uoHdO3nLojm uJ1o85qN3t9nuklT/7FpOWO9fS36RXPxpnoWHmvYgnmH0IDm/HBYC3lCQud9Z9BXUdalFPQspzz5n 8PHBolUdkbHNpAl2kUmaV0KQT37KpO2FcvdCMOoEtYkF8Ts3GTJOaZJz3ap5iDDxD5KPUR4KwhBJP XqhfdotQeocyPPF/244pGypBY0hnQFxjt+x32BXHdypGxsoClFg+ix1wLt4XNeYx6CzyoqGPBICHl Xx+ZfwhDq+gVNOMLxuxev9bxKYQg66zeNYyqjOU768/RC1TPjlo+VGofQZ0kUuPe9VwU/2aW9SC6+ 9ofr3dePfQDFizTdngbieOTtPqbveJRQoPuialG+dLldphmKTIz3Hnf/CjLI/Mdd9M81nZgqDpvGl nxh8E/WxJNkBEHBOmPh0c5vrN3M8NwrDtbwqhlLbhy4dEbiJAQ/sGzl3D4O5Xntic8+se5GEmdOvp PwVeqk85sL37PSuKbKVQ4dkxyPAuSfineYIKB5DK+gpCvSgBr9F7lzrYoX9hGU6J8W+X6ja0c1Vx4 Hv3SykXrhnh82ObOH1Ni9yysp5zISe/MfU4m3UUewMSOHi+bFGvajzqIlvBc3gsJMhX5IugG49KK5 4dcqoF2ATAH90JaDlDgOuXEP8FT/V9rIiHGj3Kjko=; Received: from [127.0.0.1] (helo=localhost) by polemos.matrix.org with esmtp (Exim 4.89) (envelope-from ) id 1jsUXk-00030j-Mc for mls@ietf.org; Mon, 06 Jul 2020 17:04:36 +0000 Content-Type: text/plain; charset="utf-8" To: mls@ietf.org User-Agent: SOGoMail 3.2.6 MIME-Version: 1.0 Date: Mon, 06 Jul 2020 18:04:36 +0100 Message-ID: <2d1b-5f035980-1-53713100@74279099> X-Forward: 192.252.163.163 From: "Hubert Chathi" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [MLS] =?utf-8?q?Circular_dependency_in_node_hash_calculation=3F?= 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, 06 Jul 2020 17:04:39 -0000 I may be missing something, but it seems to me like there is a circular= dependency in the definition of the hash of a parent node. In the "Tr= ee Hashes" section, it says that when computing the hash of a parent no= de, you use the ParentNodeHashInput struct, which includes an item that= is a ParentNode (which I assume is the data concerning the node that y= ou are hashing), as well as the hashes of the two children. However, P= arentNode contains an item called parent=5Fhash, which I assume is the = hash of the node's parent. Thus to calculate the hash of a node, you = need to calculate the hash of its parent, but that requires calculating= the hash of both its children, meaning that you need to calculate the = hash of node that you were trying to calculate in the first place. Am I reading it wrong (and if so, can there be more clarification added= ), or is there a bug in the definitions? Also, when calculating the hash of a struct, is there a prescribed seri= alization format to use, or is it up to the application to define the s= erialization format? Thanks Hubert From nobody Mon Jul 6 13:43: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 87FAA3A0A8D for ; Mon, 6 Jul 2020 13:43:40 -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 epv-DsJ381ob for ; Mon, 6 Jul 2020 13:43:38 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 B3AB53A0A8C for ; Mon, 6 Jul 2020 13:43:38 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 22so40641648wmg.1 for ; Mon, 06 Jul 2020 13:43:38 -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=ofW7sbbmnuku+q8wr9k0xagljrDAlnncTb/dP0iXYGU=; b=xfCdYi7JeUe5ud2d+rVUEvBEqPudqyVb6HO5Kn6B3A/FuEF8kIAufnNDCR6CjO2BUg D+8UVR1Qgr+E7u6QZ6unwololF1AOs5mGQLVk9WNanQqPKU+b5pRDO74zRqKVM2gH3fl Lzxsqcr8wC6ws+dgEXGM7LIUQiAx2Vu5YzS0gePEsWr2hWtUL/hECTHm9j547B/Icd2e xylMI89ZJg2ROKmrSWINLsXkrBguj8jXEnDBZ7MvG/P3Y/PeYh3qgG0i0/Q29PfwjMAL hKhXJI3B+OQiUvI6AQqKJI5Y0zVeHSQYGQxKNICcd/El3ttxyONj1Ch/VHGyjCouvfbQ h3dQ== 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=ofW7sbbmnuku+q8wr9k0xagljrDAlnncTb/dP0iXYGU=; b=oWuE5AyDmVBLq0MDbKfMct7KkXH50CccLuYWJsbS1dw/sA3EHuBsAYglQXqhZWi8Ku fILwTlUQc56U6QmM1G1iaKARRZgV48P20c6ySk0SPnRaKwAlTERPch8M5JGqEofODmY6 hZq+RrBzCw5Mo5pGrRO4L3lpqFi97u1oSyK8E1jUP1GK//xkRETxPz20nIiwrJPvFw9d hOL34fXYVmmzvldpqhMZCxHCVRL65o9hNlc4Yrks1WDqK1wpEaCS1qciCz11/6B3Lm1w fVeP13NqdEG6cG6ZllH+X1tu/u3eERt19G/Bo1b4eF7KHIrmrg4f/iN/adAZi3Iqbovm R9Gg== X-Gm-Message-State: AOAM5330vsaMXEghRzRj6ROcm4Dpyg4MGWMmWkM4wwVKePvISHqREG/A GNMOlU4fNGdlq57bExO+7MAtB7Xj20s= X-Google-Smtp-Source: ABdhPJwSZpQV/7b1WHGuB5ChAccI59rDLihi5d2mcS+pifRXcuBx3jthXrONbcbKVLbbT54snZoOCQ== X-Received: by 2002:a1c:4c16:: with SMTP id z22mr896801wmf.103.1594068216983; Mon, 06 Jul 2020 13:43:36 -0700 (PDT) Received: from [192.168.178.21] ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id l8sm25207572wrq.15.2020.07.06.13.43.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 13:43:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Raphael Robert In-Reply-To: <51A5B187-EAAB-4126-BE29-C18ADAFFB179@wire.com> Date: Mon, 6 Jul 2020 22:43:05 +0200 Cc: Messaging Layer Security WG Content-Transfer-Encoding: quoted-printable Message-Id: <4BB46738-4B7D-472C-B8DA-A51A93B33DD9@wire.com> References: <2d1b-5f035980-1-53713100@74279099> <51A5B187-EAAB-4126-BE29-C18ADAFFB179@wire.com> To: Hubert Chathi X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Circular dependency in node hash calculation? 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, 06 Jul 2020 20:43:41 -0000 (forgot to include the list) > On 6 Jul 2020, at 22:05, Raphael Robert wrote: >=20 > Hi Hubert, >=20 > I admit this looks a bit confusing. The parent_hash field of a = ParentNode is not to be calculated at that point in time. Instead, it = should already be there. It gets populated by processing a Commit = message, where a LeafNode gets updated and its entire direct path is = also updated. In other words, calculating the tree hash is strictly a = top down operation. >=20 > Regarding the serialisation: MLS uses the TLS presentation language = specified in RFC8446. >=20 > Raphael >=20 >> On 6 Jul 2020, at 19:04, Hubert Chathi wrote: >>=20 >> I may be missing something, but it seems to me like there is a = circular dependency in the definition of the hash of a parent node. In = the "Tree Hashes" section, it says that when computing the hash of a = parent node, you use the ParentNodeHashInput struct, which includes an = item that is a ParentNode (which I assume is the data concerning the = node that you are hashing), as well as the hashes of the two children. = However, ParentNode contains an item called parent_hash, which I assume = is the hash of the node's parent. Thus to calculate the hash of a node, = you need to calculate the hash of its parent, but that requires = calculating the hash of both its children, meaning that you need to = calculate the hash of node that you were trying to calculate in the = first place. >>=20 >> Am I reading it wrong (and if so, can there be more clarification = added), or is there a bug in the definitions? >>=20 >> Also, when calculating the hash of a struct, is there a prescribed = serialization format to use, or is it up to the application to define = the serialization format? >>=20 >> Thanks >>=20 >> Hubert >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Mon Jul 6 19:42: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 A69863A094B for ; Mon, 6 Jul 2020 19:42:03 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-SbzssFNqua for ; Mon, 6 Jul 2020 19:42:01 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3083A0948 for ; Mon, 6 Jul 2020 19:42:01 -0700 (PDT) X-ASG-Debug-ID: 1594089718-0e394569e974680001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id xmfFcZeh2D3ZU3W3; Mon, 06 Jul 2020 19:41:58 -0700 (PDT) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from skywalker.ern.nps.edu (172.20.4.117) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Mon, 6 Jul 2020 19:41:58 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.173) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Mon, 6 Jul 2020 19:41:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dXUBTXvmvrIhCNcV45lPTM68MfrQ4eJsncTQoJ2eyAHooCo5X/dxTVkXEJInnJv+woiG1TjEe3uxKxZdlhN4MiDodforydo24Tx+u1Z1t0yNT20Teponq1U0vj3I05Amg8Bxt6K+bqeYy43Wo51Bxb45A0lD6EOVsElgU8FlAMBklKvdLeTzOG0Knm51ctJRdolNlKE98oPC9ZT3iP4/fF+7YNAtJnbhUJaSjbtHHT6HFTjTvQqCw10ID5f9DUg84zbLTxwmS8ORXGRztuxKNJW3BNNHbr09L/MpffsLm/MjdjMoqb6Qc+OkwEODzEFKbuQJsRKmqe2s9RO2Hhxyuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xCaXWS706zdNp9Tv5nFclkf+RS2VOM87RH2ktKcIOjw=; b=XwxsxyZocWVxspkYhPQrFLqiF9i4qVT0lfYtgZBBTT10SZoOKgv5QOb8V5IyjjfDf0iZaY5JJOWtQcvTpGYc1nAT9vo4x9wwRPd9/sz+jNwf3i19gZc91FLtfExWqf9J7SuxXlET2j/+fkdeePQxbh2qnauCHsXEKnBIZxAzmD1GtlOvvbVIRNMPpS1ROMyqZouQ2G66LyD8yzFBfP+utJ7+o0ypN3yHIKJk7mHZwtjM5mZR7BEXNA/tI+ojNkCwZ3ZxWL/yUKcsh4eHZF5qE3T6pHZW0pHc6Q4VBwS5imKd/ZLMwjsNjlSpw/f2dM37niN1cY8lyrBjpeBf4iNoIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from MWHPR13MB1072.namprd13.prod.outlook.com (2603:10b6:300:13::19) by MWHPR1301MB2029.namprd13.prod.outlook.com (2603:10b6:301:36::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Tue, 7 Jul 2020 02:41:55 +0000 Received: from MWHPR13MB1072.namprd13.prod.outlook.com ([fe80::9080:78ca:a64b:304b]) by MWHPR13MB1072.namprd13.prod.outlook.com ([fe80::9080:78ca:a64b:304b%4]) with mapi id 15.20.3174.020; Tue, 7 Jul 2020 02:41:54 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:301:36::12] X-Barracuda-Apparent-Source-IP: 2603:10b6:301:36::12 From: "Hale, Britta (CIV)" To: Chris Brzuska , "mls@ietf.org" Thread-Topic: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) X-ASG-Orig-Subj: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) Thread-Index: AQHWPoPnV6XFdyfMMkWRCdiY8/bkhKjt41EA Date: Tue, 7 Jul 2020 02:41:54 +0000 Message-ID: References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> In-Reply-To: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.17.200615 authentication-results: aalto.fi; dkim=none (message not signed) header.d=none;aalto.fi; dmarc=none action=none header.from=nps.edu; x-originating-ip: [2601:647:cb00:2941:c9af:a9c8:ee9b:400e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f15ce72d-c033-4ac1-ee06-08d8221f4fb9 x-ms-traffictypediagnostic: MWHPR1301MB2029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m1rrxdzDxYEVwGRwdM/hbRlREJbL/vTuTag66r9rhr+AujmhPClhGWvIdhHts9IF/x5PJU37D7k44ToCNMdMwhodJmyP5UFMQzLuq173Jfl8ZI4w4sfGT+ueqexdcOH5RPsTvi1kUMnvAbTFQ8IUH52tjq6x8qB3qjQlLF21cjnw1ZCd3z2J5oqPTAlHbhYDD6GxlDyPwlwDv/0k+90azA7I41f+1pz+V5/VIfjOu31EAlA4tYSKIvtIt3MykSvNdKabuyjn5PxmjC38jT6yVF/GfcmrshAbbSNJxqGFYIgLN3pKKegc1glz72RDZyKVkbpr2lDfKpZFGf7fBMM41iglsqLcMVdkR8VawKcONiW/vBbhYhkSSLr11nP2eL6d5EODHZwhm1DBgOnLS5ViYA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR13MB1072.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(396003)(366004)(136003)(8676002)(8936002)(33656002)(966005)(478600001)(5660300002)(2906002)(91956017)(86362001)(75432002)(66446008)(64756008)(66556008)(66476007)(83380400001)(36756003)(6512007)(66946007)(76116006)(186003)(21615005)(83080400001)(110136005)(53546011)(71200400001)(2616005)(166002)(6486002)(316002)(786003)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Ah1sEcHGZmuGCb7Q97A6kAZcm1KBYJdkhVakAIcVkIe4KsNra6WMfTN5R90VEPXqfTFKOvmFUql7AsCOFoXF9nBsTnwxg0ryLcvfSDUCAjHsImtABDLPBCe+Td3B1GeU1HPq08uu5/bfGChq53su+vgkf8SmnQopnfctHT2XPV+DpCNE8ZTgGtdzv+PlbPBaC6Ng9tCngx8rHro1ZPOLLMKRPS26rXqFQh9dJsPiwvAxSAdnu1VkwT9cGvrKGAuPifHJiBGVcePkrLy48syKUERdCYm3dNXJ+gmC0GUjNE209aoFKhr2C58MDFduPQM9tpld94nL0fHqrDuViR4sCWu3y7EaJpeOdKPmslp6Vutr3vPI0hcjEoSmgDras2fyK9wT2pfgEsMHsfi8s3w6ODpx2t7smp0HyLYJh41m1dNzjaKyZ+JRFJMbJSclCMEf+CIJHVUErKKqCQPg5orkU/HVFRqA6ENJR5sPTdU7en6rjFJKRWq8/7fdjIT2xRALfeSCTlJd42fke6KOcywAdOy/26WE17MNnBuUmILJHSuRykqnX5JLErSQo1Mo42Lr x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_B0D017EB1A154C9684C81E202A5A51EFnpsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR13MB1072.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f15ce72d-c033-4ac1-ee06-08d8221f4fb9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2020 02:41:54.8291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WI013Q/xFxW/QG2Q+Rq4hIc/leg01264Oxz8vyTpAXKJpNnon/LVaHhEOODc7sYXV9f7pnEz3sPuAuHN+c6QUQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1301MB2029 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1594089718 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 12329 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83027 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 07 Jul 2020 02:42:04 -0000 --_000_B0D017EB1A154C9684C81E202A5A51EFnpsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhbiBpbnRlcmVzdGluZyBwcm9wb3NhbC4gSXQgaXMgY2xvc2VseSByZWxhdGVkIGF0 IGEgaGlnaCBsZXZlbCB0byBDYXJ0ZXItV2VnbWFuIE1BQ3MgKGkuZS4gZm9yIHJhbmRvbSBzZWVk IHIsIE1BQygoazEsIGsyKSwgbSkgPSAgUFJGKGsxLCByKSBYT1IgTUFDKGsyLCBtKSkuIFF1aXRl IGEgZmV3IE1BQ3MgZmFsbCBpbnRvIHRoaXMgY2F0ZWdvcnkgaW4gcHJhY3RpY2UuIENvbnNpZGVy aW5nIHRoZSB1c2Ugb2YgYSBNQUMtYmFzZWQgS0RGIGFuZCB0aGUgcHJvb2ZzIG9mIFszXSBvbiBE UFJGcywgdGhlcmUgaXMgYW4gb3ZlcmxhcCBiZXR3ZWVuIE5QUkZzIGFuZCBleHRyYXBvbGF0aW9u IG9mIHRoZSBhYm92ZSAoYmFzZWQgb24gaXRlcmF0aW9uIG9mIHRoZSBQUkYgZ3VhcmFudGVlcyku DQoNClRoaXMgaXMgd29ydGggbm90aW5nIGZyb20gYW4gYXNzdXJhbmNlIHN0YW5kcG9pbnQ6IHRo ZXJlIHdhcyBkaXNjdXNzaW9uIGF0IHRoZSB2aXJ0dWFsIGludGVyaW1zIHdpdGggcmVzcGVjdCB0 byB0aGUgY3VycmVudCBmb3JtdWxhdGlvbiBvZiBNTFMga2V5IGRlcml2YXRpb24sIHdoaWNoIGhh cyBhIOKAnFRMUyBwcmVjZWRlbmNl4oCdLCB5ZXQgdGhpcyBwcm9wb3NhbCBpcyBub3Qgd2l0aG91 dCBwcmVjZWRlbmNlIGl0c2VsZi4gRXJnbywgc3VjaCBhIGNoYW5nZSBzaG91bGQgbm90IG5lY2Vz c2FyaWx5IGJlIGNvbmNlcm5pbmcgYmFzZWQgb24gZGlmZmVyaW5nIGZyb20gY3VycmVudCBwcmFj dGljZS4NCg0KVGhpcyBzdHlsZSBvZiBjb21iaW5nIGhhc2ggb3V0cHV0cyBkb2VzIGFmZmVjdCBj b2xsaXNpb24gcmVzaXN0YW5jZSBbNF0sIGFuZCBzb21lIGRpc2N1c3Npb24gb24gcmVsYXRpb24g dG8gdGhhdCB3b3VsZCBiZSBuaWNlIHRvIHNlZS4NCg0KQnJpdHRhDQoNCg0KDQpbMV0gQ2FydGVy LCBXZWdtYW4uIFVuaXZlcnNhbCBjbGFzc2VzIG9mIGhhc2ggZnVuY3Rpb25zLg0KWzJdIENhcnRl ciwgV2VnbWFuLiBOZXcgaGFzaCBmdW5jdGlvbnMgYW5kIHRoZWlyIHVzZSBpbiBhdXRoZW50aWNh dGlvbiBhbmQgc2V0IGVxdWFsaXR5Lg0KWzNdIEJlbGxhcmUgYW5kIEx5c3lhbnNrYXlhLiBTeW1t ZXRyaWMgYW5kIER1YWwgUFJGcyBmcm9tIFN0YW5kYXJkIEFzc3VtcHRpb25zOiBBIEdlbmVyaWMg VmFsaWRhdGlvbiBvZiBhbiBITUFDIEFzc3VtcHRpb24uDQpbNF0gQmVybnN0ZWluLiBXaGF0IG91 dHB1dCBzaXplIHJlc2lzdHMgY29sbGlzaW9ucyBpbiBhIHhvciBvZiBpbmRlcGVuZGVudCBleHBh bnNpb25zPw0KDQoNCg0KRnJvbTogTUxTIDxtbHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm IG9mIENocmlzIEJyenVza2EgPGNocmlzLmJyenVza2FAYWFsdG8uZmk+DQpEYXRlOiBUdWVzZGF5 LCBKdW5lIDksIDIwMjAgYXQgMTA6MzIgQU0NClRvOiAibWxzQGlldGYub3JnIiA8bWxzQGlldGYu b3JnPg0KU3ViamVjdDogW01MU10gS2V5IFNjaGVkdWxlOiBSZXBsYWNlIERQUkYgd2l0aCBtdWx0 aS1pbnB1dCBQUkYgKE5QUkYpDQoNCg0KSGkgYWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gb3BlbiBh IGRpc2N1c3Npb24gb24gYSBzdWdnZXN0aW9uIGZvciBhIGNoYW5nZSBpbiB0aGUga2V5IHNjaGVk dWxlLiBJbiB0aGUgY3VycmVudCBkcmFmdCwgd2UgdXNlIHRoZSBFeHRyYWN0IGZ1bmN0aW9uIHR3 aWNlIGFzIGEgZHVhbCBwc2V1ZG9yYW5kb20gZnVuY3Rpb24gKERQUkYpIHdoZW4gY29tYmluaW5n IDMga2V5cyAoKikgYW5kIGludGVybGVhdmUgdGhlbSB3aXRoIGFuIEV4cGFuZCBjYWxsLg0KDQpU aGUgc3VnZ2VzdGlvbiBbMV0gaXMgdG8gcmVwbGFjZSB0aGVzZSAzIGNhbGxzIGJ5IGEgbXVsdGkt aW5wdXQgUFJGIChOUFJGKSB3aGljaCBpcyBlc3BlY2lhbGx5IGRlc2lnbmVkIHRvIHJldHVybiBh IHBzZXVkb3JhbmRvbSBrZXkgd2hlbiBhdCBsZWFzdCBvbmUgb2YgdGhlIGlucHV0IGtleXMgaXMg cHNldWRvcmFuZG9tLiBUaGUgbmV3IHN1Z2dlc3Rpb24gcmVsaWVzIG9uIHN0YW5kYXJkIFBSRiBz ZWN1cml0eSByYXRoZXIgdGhhbiBEUFJGLXNlY3VyaXR5IG9mIEV4dHJhY3QuDQoNCllvdSBjYW4g ZmluZCB0aGUgYWNjb21wYW55aW5nIHBhcGVyIHdpdGggcGljdHVyZXMsIGRpc2N1c3Npb24gYW5k IHNlY3VyaXR5IHJlZHVjdGlvbiBmb3IgdGhlIGRlc2lnbiBwcmluY2lwbGUgaGVyZSBbMl0uIEkg aW5jbHVkZSBhIHN1bW1hcnkgb2YgdGhlIG1haW4gcG9pbnRzIGluIHRoZSBlbmQgb2YgdGhpcyBl TWFpbC4NCg0KUGxlYXNlIGNvbW1lbnQvc2hhcmUgeW91ciBvcGluaW9uLiBUaGFua3MhDQoNCkNo cmlzDQoNCigqKSBjb21taXRfc2VjcmV0LCBQU0sgYW5kIGluaXRfc2VjcmV0DQoNClsxXSBQdWxs IFJlcXVlc3Q6IGh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvcHVsbC8zMzcN Cg0KWzJdIFBhcGVyOiBodHRwOi8vY2hyaXNicnp1c2thLmRlLzIwMjAtTlBSRi5odG1sDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNClN1bW1hcnkgb2YgbWFpbiBwb2ludHM6DQoNClRoZSBjdXJyZW50IGtleSBzY2hlZHVsZQ0K LSB1c2VzIEV4dHJhY3QgYXMgYSBkdWFsIHBzZXVkb3JhbmRvbSBmdW5jdGlvbiBhbmQgYXNzdW1l cyB0aGF0IEhNQUMgaXMgYSBkdWFsIHBzZXVkb3JhbmRvbSBmdW5jdGlvbg0KLSBhcHBsaWVzIEV4 dHJhY3QgYWZ0ZXIgRXhwYW5kLCBpLmUuLCBhZnRlciBhcHBseWluZyBhIGZ1bmN0aW9uIHdoaWNo IGdlbmVyYXRlcyBhIHBzZXVkb3JhbmRvbSB2YWx1ZQ0KLSBpdGVyYXRlcyBFeHRyYWN0LXRoZW4t RXhwYW5kIHNlcXVlbnRpYWxseSB0byBjb21iaW5lIG1vcmUgdGhhbiAyIGtleXMNCg0KVGhlIHB1 bGwgcmVxdWVzdCBzdWdnZXN0cyB0bw0KLSByZXBsYWNlIHRoZSBhZC1ob2MgYXNzdW1wdGlvbiB0 aGF0IEV4dHJhY3QgaXMgYSBkdWFsIHBzZXVkb3JhbmRvbSBmdW5jdGlvbg0KLSByZW1vdmUgRXh0 cmFjdCBzdGVwcyB3aGVuIGFwcGxpZWQgYWZ0ZXIgRXhwYW5kDQotIHVzZSBhIHByb3ZhYmx5IHNl Y3VyZSBOUFJGIGNvbnN0cnVjdGlvbiB3aGljaCBhbGxvd3MgdG8gY29tYmluZSBtb3JlIHRoYW4g MiBrZXlzIGFuZCBpcyBiYXNlZCBvbiBhIHN0YW5kYXJkIFBSRiBhc3N1bXB0aW9uIGFuZCBzdGF0 aXN0aWNhbCBwcm9wZXJ0aWVzIG9mIHhvci4NCg0KRWZmaWNpZW5jeToNCi0gVGhlIHN1Z2dlc3Rl ZCBjb25zdHJ1Y3Rpb24gaGFzIGhpZ2hlciBwYXJhbGxlbCBlZmZpY2llbmN5LiBJdCBpbmNyZWFz ZXMgdGhlIG92ZXJhbGwgbnVtYmVyIG9mIEhNQUMgZXZhbHVhdGlvbnMgYnkgMS4NCg0KQXNzdW1w dGlvbnM6DQotIEhNQUMgaXMgYSBzdGFuZGFyZCBQUkYuDQotIFJlbGllcyBvbiBhIHVuaXF1ZSB2 YWx1ZSwgdGhlIGdyb3VwX2NvbnRleHQgd2FzIHN1Z2dlc3RlZC4NCg0KQ29uc3RydWN0aW9uOg0K KDEpIFVzZSB1bmlxdWUgdmFsdWUgdG8gZXhwYW5kIGVhY2gga2V5IGFuZCB4b3IgdGhlIHJlc3Vs dA0KKDIpIGV4cGFuZCByZXN1bHRpbmcga2V5LCBpbmNsdWRpbmcgdW5pcXVlIHZhbHVlIGludG8g dGhlIGNvbnRleHQgYWdhaW4NCg0KU2VjdXJpdHkgYXJndW1lbnQ6DQotIFBzZXVkb3JhbmRvbW5l c3M6IHVuaXF1ZSB2YWx1ZSBlbnN1cmVzIHRoYXQgZWFjaCBvdXRjb21lIG9mIEV4cGFuZCBpbiAo MSkgaXMgdXNlZCBvbmx5IG9uY2UgaW4gYSB4b3IgY29tYmluYXRpb24sIHRodXMgYWxsb3dpbmcg b24gb25lLXRpbWUgcGFkIGFyZ3VtZW50IG9mIHhvci4NCi0gVW5pcXVlbmVzcyBvZiByZXN1bHRp bmcga2V5czogKDIpIGVuc3VyZXMgdGhhdCBpZiBITUFDIGlzIGNvbGxpc2lvbi1yZXNpc3RlbnQs IHRoZW4gdGhlIHJlc3VsdCBpcyBjb2xsaXNpb24tcmVzaXN0ZW50Lg0KDQpWYXJpYW50czoNCi0g SXQgaXMgcG9zc2libGUgdG8gdXNlIGFuIE5QUkYgdmFyaWFudCBjYWxsZWQgTmFtZU5QUkYgWzJd IHdoaWNoIGhhcyAzIEhNQUMgZXZhbHVhdGlvbnMgbW9yZSBhbmQgcmVsaWVzIGxlc3Mgb24gdGhl IHVuaXF1ZSB2YWx1ZS4gSS5lLiwgTmFtZU5QUkYgaXMgc2VjdXJlIGluIHRoZSBzYW1lIHNjZW5h cmlvcyBhcyBEUFJGOiBLZXlzIG9ubHkgcmVwZWF0IGlmIHRoZSBpbnB1dCBrZXlzIHJlcGVhdCAq YW5kKiB0aGUgZ3JvdXAgY29udGV4dCByZXBlYXRzLg0KDQpRdWVzdGlvbnMvQ29tbWVudHMgdGhh dCBjYW1lIHVwOg0KLSBCYXJuZXMsIE1hY01pbGxpb24gc3VnZ2VzdGVkIGdyb3VwX2NvbnRleHQg YXMgdW5pcXVlIHZhbHVlDQotIE1hY01pbGxpb24gd29uZGVyZWQgYWJvdXQgcmVtb3ZhbCBvZiBF eHRyYWN0OiBPbmUgY2FuIGFkZCBhbiBleHRyYWN0IG9wZXJhdGlvbiBmb3IgdGhlIHBzay4gRm9y IG90aGVyIGlucHV0IGtleXMsIGl0IGRvZXMgbm90IHNlZW0gbmVlZGVkLCBzaW5jZSB0aGV5IHdl cmUgcmV0dXJuZWQgZnJvbSBFeHBhbmQuDQotIFdvb2Q6IENhbiB3ZSByZXBsYWNlIEhNQUMgYnkg YXJiaXRyYXJ5IFBSRj8gWWVzLiBGb3IgdW5pcXVlbmVzcyBvZiBvdXRwdXQga2V5cywgdGhlIFBS RiBuZWVkcyB0byBiZSBjb2xsaXNpb24tcmVzaXN0YW50LCB0b28uDQo= --_000_B0D017EB1A154C9684C81E202A5A51EFnpsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <1F08FC5602F0424DBA549B5BE95EB299@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYW4gaW50ZXJlc3Rpbmcg cHJvcG9zYWwuIEl0IGlzIGNsb3NlbHkgcmVsYXRlZCBhdCBhIGhpZ2ggbGV2ZWwgdG8gQ2FydGVy LVdlZ21hbiBNQUNzIChpLmUuIGZvciByYW5kb20gc2VlZCByLCBNQUMoKGsxLCBrMiksIG0pID0m bmJzcDsgUFJGKGsxLCByKSBYT1IgTUFDKGsyLCBtKSkuIFF1aXRlIGEgZmV3IE1BQ3MgZmFsbCBp bnRvIHRoaXMgY2F0ZWdvcnkgaW4gcHJhY3RpY2UuIENvbnNpZGVyaW5nIHRoZQ0KIHVzZSBvZiBh IE1BQy1iYXNlZCBLREYgYW5kIHRoZSBwcm9vZnMgb2YgWzNdIG9uIERQUkZzLCB0aGVyZSBpcyBh biBvdmVybGFwIGJldHdlZW4gTlBSRnMgYW5kIGV4dHJhcG9sYXRpb24gb2YgdGhlIGFib3ZlIChi YXNlZCBvbiBpdGVyYXRpb24gb2YgdGhlIFBSRiBndWFyYW50ZWVzKS4NCjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyBpcyB3b3J0aCBub3RpbmcgZnJvbSBhbiBhc3N1cmFuY2Ugc3RhbmRwb2ludDogdGhlcmUg d2FzIGRpc2N1c3Npb24gYXQgdGhlIHZpcnR1YWwgaW50ZXJpbXMgd2l0aCByZXNwZWN0IHRvIHRo ZSBjdXJyZW50IGZvcm11bGF0aW9uIG9mIE1MUyBrZXkgZGVyaXZhdGlvbiwgd2hpY2ggaGFzIGEg 4oCcVExTIHByZWNlZGVuY2XigJ0sIHlldCB0aGlzIHByb3Bvc2FsIGlzIG5vdCB3aXRob3V0IHBy ZWNlZGVuY2UgaXRzZWxmLg0KIEVyZ28sIHN1Y2ggYSBjaGFuZ2Ugc2hvdWxkIG5vdCBuZWNlc3Nh cmlseSBiZSBjb25jZXJuaW5nIGJhc2VkIG9uIGRpZmZlcmluZyBmcm9tIGN1cnJlbnQgcHJhY3Rp Y2UuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIHN0eWxlIG9mIGNvbWJpbmcgaGFzaCBvdXRwdXRzIGRvZXMg YWZmZWN0IGNvbGxpc2lvbiByZXNpc3RhbmNlIFs0XSwgYW5kIHNvbWUgZGlzY3Vzc2lvbiBvbiBy ZWxhdGlvbiB0byB0aGF0IHdvdWxkIGJlIG5pY2UgdG8gc2VlLjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpdHRh PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdIENhcnRlciwg V2VnbWFuLiBVbml2ZXJzYWwgY2xhc3NlcyBvZiBoYXNoIGZ1bmN0aW9ucy48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5bMl0gQ2FydGVyLCBXZWdtYW4uIE5ldyBoYXNoIGZ1bmN0aW9ucyBhbmQg dGhlaXIgdXNlIGluIGF1dGhlbnRpY2F0aW9uIGFuZCBzZXQgZXF1YWxpdHkuPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTk8tQk9LIj5bM10gQmVsbGFyZSBhbmQgTHlzeWFu c2theWEuIDwvc3Bhbj5TeW1tZXRyaWMgYW5kIER1YWwgUFJGcyBmcm9tIFN0YW5kYXJkIEFzc3Vt cHRpb25zOiBBIEdlbmVyaWMgVmFsaWRhdGlvbiBvZiBhbiBITUFDIEFzc3VtcHRpb24uPC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTk8tQk9LIj5bNF0gQmVybnN0ZWluLiA8 L3NwYW4+V2hhdCBvdXRwdXQgc2l6ZSByZXNpc3RzIGNvbGxpc2lvbnMgaW4gYSB4b3Igb2YgaW5k ZXBlbmRlbnQgZXhwYW5zaW9ucz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5NTFMgJmx0O21scy1ib3VuY2Vz QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXMgQnJ6dXNrYSAmbHQ7Y2hyaXMuYnJ6dXNr YUBhYWx0by5maSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSnVuZSA5LCAyMDIwIGF0 IDEwOjMyIEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDttbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21s c0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W01MU10gS2V5IFNjaGVkdWxlOiBS ZXBsYWNlIERQUkYgd2l0aCBtdWx0aS1pbnB1dCBQUkYgKE5QUkYpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwPkhpIGFsbCw8L3A+DQo8cD5JIHdvdWxkIGxpa2UgdG8gb3BlbiBh IGRpc2N1c3Npb24gb24gYSBzdWdnZXN0aW9uIGZvciBhIGNoYW5nZSBpbiB0aGUga2V5IHNjaGVk dWxlLiBJbiB0aGUgY3VycmVudCBkcmFmdCwgd2UgdXNlIHRoZSBFeHRyYWN0IGZ1bmN0aW9uIHR3 aWNlIGFzIGEgZHVhbCBwc2V1ZG9yYW5kb20gZnVuY3Rpb24gKERQUkYpIHdoZW4gY29tYmluaW5n IDMga2V5cyAoKikgYW5kIGludGVybGVhdmUgdGhlbSB3aXRoIGFuIEV4cGFuZCBjYWxsLjwvcD4N CjxwPlRoZSBzdWdnZXN0aW9uIFsxXSBpcyB0byByZXBsYWNlIHRoZXNlIDMgY2FsbHMgYnkgYSBt dWx0aS1pbnB1dCBQUkYgKE5QUkYpIHdoaWNoIGlzIGVzcGVjaWFsbHkgZGVzaWduZWQgdG8gcmV0 dXJuIGEgcHNldWRvcmFuZG9tIGtleSB3aGVuIGF0IGxlYXN0IG9uZSBvZiB0aGUgaW5wdXQga2V5 cyBpcyBwc2V1ZG9yYW5kb20uIFRoZSBuZXcgc3VnZ2VzdGlvbiByZWxpZXMgb24gc3RhbmRhcmQg UFJGIHNlY3VyaXR5IHJhdGhlciB0aGFuIERQUkYtc2VjdXJpdHkNCiBvZiBFeHRyYWN0LjwvcD4N CjxwPllvdSBjYW4gZmluZCB0aGUgYWNjb21wYW55aW5nIHBhcGVyIHdpdGggcGljdHVyZXMsIGRp c2N1c3Npb24gYW5kIHNlY3VyaXR5IHJlZHVjdGlvbiBmb3IgdGhlIGRlc2lnbiBwcmluY2lwbGUg aGVyZSBbMl0uIEkgaW5jbHVkZSBhIHN1bW1hcnkgb2YgdGhlIG1haW4gcG9pbnRzIGluIHRoZSBl bmQgb2YgdGhpcyBlTWFpbC48L3A+DQo8cD5QbGVhc2UgY29tbWVudC9zaGFyZSB5b3VyIG9waW5p b24uIFRoYW5rcyE8YnI+DQo8YnI+DQpDaHJpczwvcD4NCjxwPigqKSBjb21taXRfc2VjcmV0LCBQ U0sgYW5kIGluaXRfc2VjcmV0PC9wPg0KPHA+WzFdIFB1bGwgUmVxdWVzdDo8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMzM3Ij4gaHR0cHM6Ly9naXRo dWIuY29tL21sc3dnL21scy1wcm90b2NvbC9wdWxsLzMzNzwvYT48L3A+DQo8cD5bMl0gUGFwZXI6 IDxhIGhyZWY9Imh0dHA6Ly9jaHJpc2JyenVza2EuZGUvMjAyMC1OUFJGLmh0bWwiPmh0dHA6Ly9j aHJpc2JyenVza2EuZGUvMjAyMC1OUFJGLmh0bWw8L2E+PC9wPg0KPHA+PGI+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2I+PC9wPg0K PHA+PGI+U3VtbWFyeSBvZiBtYWluIHBvaW50czo8L2I+PC9wPg0KPHA+VGhlIGN1cnJlbnQga2V5 IHNjaGVkdWxlPGJyPg0KLSB1c2VzIEV4dHJhY3QgYXMgYSBkdWFsIHBzZXVkb3JhbmRvbSBmdW5j dGlvbiBhbmQgYXNzdW1lcyB0aGF0IEhNQUMgaXMgYSBkdWFsIHBzZXVkb3JhbmRvbSBmdW5jdGlv bjxicj4NCi0gYXBwbGllcyBFeHRyYWN0IGFmdGVyIEV4cGFuZCwgaS5lLiwgYWZ0ZXIgYXBwbHlp bmcgYSBmdW5jdGlvbiB3aGljaCBnZW5lcmF0ZXMgYSBwc2V1ZG9yYW5kb20gdmFsdWU8YnI+DQot IGl0ZXJhdGVzIEV4dHJhY3QtdGhlbi1FeHBhbmQgc2VxdWVudGlhbGx5IHRvIGNvbWJpbmUgbW9y ZSB0aGFuIDIga2V5czxicj4NCjxicj4NClRoZSBwdWxsIHJlcXVlc3Qgc3VnZ2VzdHMgdG88YnI+ DQotIHJlcGxhY2UgdGhlIGFkLWhvYyBhc3N1bXB0aW9uIHRoYXQgRXh0cmFjdCBpcyBhIGR1YWwg cHNldWRvcmFuZG9tIGZ1bmN0aW9uPGJyPg0KLSByZW1vdmUgRXh0cmFjdCBzdGVwcyB3aGVuIGFw cGxpZWQgYWZ0ZXIgRXhwYW5kPGJyPg0KLSB1c2UgYSBwcm92YWJseSBzZWN1cmUgTlBSRiBjb25z dHJ1Y3Rpb24gd2hpY2ggYWxsb3dzIHRvIGNvbWJpbmUgbW9yZSB0aGFuIDIga2V5cyBhbmQgaXMg YmFzZWQgb24gYSBzdGFuZGFyZCBQUkYgYXNzdW1wdGlvbiBhbmQgc3RhdGlzdGljYWwgcHJvcGVy dGllcyBvZiB4b3IuPGJyPg0KPGJyPg0KRWZmaWNpZW5jeTo8YnI+DQotIFRoZSBzdWdnZXN0ZWQg Y29uc3RydWN0aW9uIGhhcyBoaWdoZXIgcGFyYWxsZWwgZWZmaWNpZW5jeS4gSXQgaW5jcmVhc2Vz IHRoZSBvdmVyYWxsIG51bWJlciBvZiBITUFDIGV2YWx1YXRpb25zIGJ5IDEuPGJyPg0KPGJyPg0K QXNzdW1wdGlvbnM6PGJyPg0KLSBITUFDIGlzIGEgc3RhbmRhcmQgUFJGLjxicj4NCi0gUmVsaWVz IG9uIGEgdW5pcXVlIHZhbHVlLCB0aGUgZ3JvdXBfY29udGV4dCB3YXMgc3VnZ2VzdGVkLjxicj4N Cjxicj4NCkNvbnN0cnVjdGlvbjo8YnI+DQooMSkgVXNlIHVuaXF1ZSB2YWx1ZSB0byBleHBhbmQg ZWFjaCBrZXkgYW5kIHhvciB0aGUgcmVzdWx0PGJyPg0KKDIpIGV4cGFuZCByZXN1bHRpbmcga2V5 LCBpbmNsdWRpbmcgdW5pcXVlIHZhbHVlIGludG8gdGhlIGNvbnRleHQgYWdhaW48YnI+DQo8YnI+ DQpTZWN1cml0eSBhcmd1bWVudDo8YnI+DQotIFBzZXVkb3JhbmRvbW5lc3M6IHVuaXF1ZSB2YWx1 ZSBlbnN1cmVzIHRoYXQgZWFjaCBvdXRjb21lIG9mIEV4cGFuZCBpbiAoMSkgaXMgdXNlZCBvbmx5 IG9uY2UgaW4gYSB4b3IgY29tYmluYXRpb24sIHRodXMgYWxsb3dpbmcgb24gb25lLXRpbWUgcGFk IGFyZ3VtZW50IG9mIHhvci48YnI+DQotIFVuaXF1ZW5lc3Mgb2YgcmVzdWx0aW5nIGtleXM6ICgy KSBlbnN1cmVzIHRoYXQgaWYgSE1BQyBpcyBjb2xsaXNpb24tcmVzaXN0ZW50LCB0aGVuIHRoZSBy ZXN1bHQgaXMgY29sbGlzaW9uLXJlc2lzdGVudC48YnI+DQo8YnI+DQpWYXJpYW50czo8YnI+DQot IEl0IGlzIHBvc3NpYmxlIHRvIHVzZSBhbiBOUFJGIHZhcmlhbnQgY2FsbGVkIE5hbWVOUFJGIFsy XSB3aGljaCBoYXMgMyBITUFDIGV2YWx1YXRpb25zIG1vcmUgYW5kIHJlbGllcyBsZXNzIG9uIHRo ZSB1bmlxdWUgdmFsdWUuIEkuZS4sIE5hbWVOUFJGIGlzIHNlY3VyZSBpbiB0aGUgc2FtZSBzY2Vu YXJpb3MgYXMgRFBSRjogS2V5cyBvbmx5IHJlcGVhdCBpZiB0aGUgaW5wdXQga2V5cyByZXBlYXQg KmFuZCogdGhlIGdyb3VwIGNvbnRleHQgcmVwZWF0cy48YnI+DQo8YnI+DQpRdWVzdGlvbnMvQ29t bWVudHMgdGhhdCBjYW1lIHVwOjxicj4NCi0gQmFybmVzLCBNYWNNaWxsaW9uIHN1Z2dlc3RlZCBn cm91cF9jb250ZXh0IGFzIHVuaXF1ZSB2YWx1ZTxicj4NCi0gTWFjTWlsbGlvbiB3b25kZXJlZCBh Ym91dCByZW1vdmFsIG9mIEV4dHJhY3Q6IE9uZSBjYW4gYWRkIGFuIGV4dHJhY3Qgb3BlcmF0aW9u IGZvciB0aGUgcHNrLiBGb3Igb3RoZXIgaW5wdXQga2V5cywgaXQgZG9lcyBub3Qgc2VlbSBuZWVk ZWQsIHNpbmNlIHRoZXkgd2VyZSByZXR1cm5lZCBmcm9tIEV4cGFuZC48YnI+DQotIFdvb2Q6IENh biB3ZSByZXBsYWNlIEhNQUMgYnkgYXJiaXRyYXJ5IFBSRj8gWWVzLiBGb3IgdW5pcXVlbmVzcyBv ZiBvdXRwdXQga2V5cywgdGhlIFBSRiBuZWVkcyB0byBiZSBjb2xsaXNpb24tcmVzaXN0YW50LCB0 b28uDQo8L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B0D017EB1A154C9684C81E202A5A51EFnpsedu_-- From nobody Tue Jul 7 02:29: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 A7DFE3A0895 for ; Tue, 7 Jul 2020 02:29:49 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=aalto.fi 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 eU5CCT0OyOkx for ; Tue, 7 Jul 2020 02:29:47 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 E29C93A0898 for ; Tue, 7 Jul 2020 02:29:45 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3E423271578_F044085B for ; Tue, 7 Jul 2020 09:29:41 +0000 (GMT) Received: from exng2.org.aalto.fi (exng2.org.aalto.fi [130.233.223.21]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id B1CAC271574_F044084F for ; Tue, 7 Jul 2020 09:29:40 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng2.org.aalto.fi (130.233.223.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 7 Jul 2020 12:29:40 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 7 Jul 2020 12:29:40 +0300 To: References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> From: Chris Brzuska Message-ID: <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> Date: Tue, 7 Jul 2020 12:29:36 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> Content-Type: multipart/alternative; boundary="------------63DD37DE72328A6E35F687FD" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng2.org.aalto.fi (130.233.223.21) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=Sz7EwD0W8ySwrJuqIYI0GgxC/kxo7MmA2IB2VuAII1k=; b=OOlNWh8ASh1fpD+twNtqamKayqkSWGxjEC0ShQtPBgtZvp3uN6kZMrc3sXOzF2q0Fh7GFcQOEM4scPM7cIvIhsTBJ7mxvAMzLNPEEhkAp3OFx4GQO7Dxrx2E5Ma3lRasNeKvhm3F1y/sOSFvU9so3Nxy6X3bWE+uVWbK8I/LWoLN8k8ayTMed2fL4fETSwMkZ6JmOV8leSBKobv4Fwlo7uT2/Rw4ZZIi396/3w9h7i6FF1sCPY16ycPh4NkTNg/SeLwJLV+LTFcjp+FltMtvIMvNk9nNtEo3fMCFzPaNScnhsxNy9Ss9CnrAasZNhAnBVXswpOM0eP/H39waOxwO4w== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 07 Jul 2020 09:29:50 -0000 --------------63DD37DE72328A6E35F687FD Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Thank you for the pointer to Carter-Wegman MACs. >>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see. That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor. Chris On 07/07/2020 05:41, Hale, Britta (CIV) wrote: > > This is an interesting proposal. It is closely related at a high level > to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  > PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category > in practice. Considering the use of a MAC-based KDF and the proofs of > [3] on DPRFs, there is an overlap between NPRFs and extrapolation of > the above (based on iteration of the PRF guarantees). > > This is worth noting from an assurance standpoint: there was > discussion at the virtual interims with respect to the current > formulation of MLS key derivation, which has a “TLS precedence”, yet > this proposal is not without precedence itself. Ergo, such a change > should not necessarily be concerning based on differing from current > practice. > > This style of combing hash outputs does affect collision resistance > [4], and some discussion on relation to that would be nice to see. > > Britta > > [1] Carter, Wegman. Universal classes of hash functions. > > [2] Carter, Wegman. New hash functions and their use in authentication > and set equality. > > [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard > Assumptions: A Generic Validation of an HMAC Assumption. > > [4] Bernstein. What output size resists collisions in a xor of > independent expansions? > > *From: *MLS on behalf of Chris Brzuska > > *Date: *Tuesday, June 9, 2020 at 10:32 AM > *To: *"mls@ietf.org" > *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) > > Hi all, > > I would like to open a discussion on a suggestion for a change in the > key schedule. In the current draft, we use the Extract function twice > as a dual pseudorandom function (DPRF) when combining 3 keys (*) and > interleave them with an Expand call. > > The suggestion [1] is to replace these 3 calls by a multi-input PRF > (NPRF) which is especially designed to return a pseudorandom key when > at least one of the input keys is pseudorandom. The new suggestion > relies on standard PRF security rather than DPRF-security of Extract. > > You can find the accompanying paper with pictures, discussion and > security reduction for the design principle here [2]. I include a > summary of the main points in the end of this eMail. > > Please comment/share your opinion. Thanks! > > Chris > > (*) commit_secret, PSK and init_secret > > [1] Pull Request:https://github.com/mlswg/mls-protocol/pull/337 > > > [2] Paper: http://chrisbrzuska.de/2020-NPRF.html > > *--------------------------------------------------------------------------------------------------------------------* > > *Summary of main points:* > > The current key schedule > - uses Extract as a dual pseudorandom function and assumes that HMAC > is a dual pseudorandom function > - applies Extract after Expand, i.e., after applying a function which > generates a pseudorandom value > - iterates Extract-then-Expand sequentially to combine more than 2 keys > > The pull request suggests to > - replace the ad-hoc assumption that Extract is a dual pseudorandom > function > - remove Extract steps when applied after Expand > - use a provably secure NPRF construction which allows to combine more > than 2 keys and is based on a standard PRF assumption and statistical > properties of xor. > > Efficiency: > - The suggested construction has higher parallel efficiency. It > increases the overall number of HMAC evaluations by 1. > > Assumptions: > - HMAC is a standard PRF. > - Relies on a unique value, the group_context was suggested. > > Construction: > (1) Use unique value to expand each key and xor the result > (2) expand resulting key, including unique value into the context again > > Security argument: > - Pseudorandomness: unique value ensures that each outcome of Expand > in (1) is used only once in a xor combination, thus allowing on > one-time pad argument of xor. > - Uniqueness of resulting keys: (2) ensures that if HMAC is > collision-resistent, then the result is collision-resistent. > > Variants: > - It is possible to use an NPRF variant called NameNPRF [2] which has > 3 HMAC evaluations more and relies less on the unique value. I.e., > NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if > the input keys repeat *and* the group context repeats. > > Questions/Comments that came up: > - Barnes, MacMillion suggested group_context as unique value > - MacMillion wondered about removal of Extract: One can add an extract > operation for the psk. For other input keys, it does not seem needed, > since they were returned from Expand. > - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of > output keys, the PRF needs to be collision-resistant, too. > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --------------63DD37DE72328A6E35F687FD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--------------63DD37DE72328A6E35F687FD-- From nobody Tue Jul 7 07:42: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 60E663A0D5C for ; Tue, 7 Jul 2020 07:42:00 -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 2HoHcEpOTAUy for ; Tue, 7 Jul 2020 07:41:59 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 ECF3D3A0D5A for ; Tue, 7 Jul 2020 07:41:58 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id k18so38308690qke.4 for ; Tue, 07 Jul 2020 07:41:58 -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=SjegMjuRKuSPk0UVS6uQdOgW6yUgbBPA//Av/0y/wc0=; b=MC0m8XGX698VTNM6cCOsLPWteobHTPWtYkQJrGEhWXPjpD+lzhuPzi5ioIzJ2RiE3W Qyxaw9KrbjWJtqbE0E/P2GEmosqgG8+F3g1qUI5jH/mip/oCngbMaF3mC8utIFMoek+g 1lCVmC2dhdjAEZkSmoy1Fr4VM3LlzOEJVTglo= 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=SjegMjuRKuSPk0UVS6uQdOgW6yUgbBPA//Av/0y/wc0=; b=pCT1juTUt8ruU0etpiXrMTH5wV+9cW4cYOj5FBB1SF5X/xQW77fcNtjODsGqrJ6L0N WQpd1D9TlOxmWAjHaObj0vCRipr2fNTyCaYzFRx3M2NGdQg7I16wctGxRV3Qs0JzOGL9 85KmsP/GEMj3FZ2owUBQYoPx4J4Op7LX31+zYnA2HwejXtWjZJch5/dK8j39OF4mk/jX ap4hMg5KB7Gkk9TWXjK/MNVrbb2ZUF7LFVj1dz8jmd/lqOiaYGKzYPsrqQxOXAhdYpfi FPMq5+89aGY7t1zfn3w5wA/ctrf3jFgSIo6Dt3xYIgvTPef+Wm+clrn6uvqDKNozpGEX XauQ== X-Gm-Message-State: AOAM531JWZIpkawxHSrHa6ZetJvCFsYbWBGiMeAqN0N95ifPJTu0u6nr tirv9hxBqLsdfNIIbCeRoELyCshwOc4= X-Google-Smtp-Source: ABdhPJw6KGLDkyHbvhNgsR87txX6iBXBeWR3hlrws+zohsouHdC9uMdfP8AhbKX5fHUqQszHGm4eqw== X-Received: by 2002:a37:b4f:: with SMTP id 76mr48579145qkl.283.1594132917609; Tue, 07 Jul 2020 07:41:57 -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 i26sm23256314qkh.14.2020.07.07.07.41.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2020 07:41:56 -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.80.23.2.2\)) Message-Id: Date: Tue, 7 Jul 2020 10:41:52 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [MLS] 7/7 Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 14:42:00 -0000 Just a reminder that there is a virtual interim planned for today at = 16:00 UTC. Attendance link is here: https://ietf.webex.com/ietf/j.php?MTID=3Dm7f300037f89a213366d395bd400579a8= =20= From nobody Tue Jul 7 08:21: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 79D223A0E70 for ; Tue, 7 Jul 2020 08:21:48 -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 12CkosFetNuA for ; Tue, 7 Jul 2020 08:21:46 -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 0BED63A0E5C for ; Tue, 7 Jul 2020 08:21:45 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id b185so27865997qkg.1 for ; Tue, 07 Jul 2020 08:21:45 -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=MSKL96ZN6ZyWq9nyvWVLbKbFMT6ELcFPty//VhYMDf4=; b=a8erGem39UqH1GpV1ToZBTqQXFn9NGRkEfpTjIGvdXK6NVLJZ7Dav/AFpNVeM59OAx iv8Ky+oaepf4+/U0sF1vLkzpoYSY5H3d1XgtP//1/1MKJtXiH9thjzLEK3mhnDWiOV53 xxjesAMcF1byvyahcim5y89PmHoLX5slCEkwk0EPa5Itznmn8YitjOY780ydEeHUmzMr RuBWhPA+4uTZsZOdaGGDqP1e4rlP/X25jj+mE5C+STsmJDcK9UTT2PnBobFTVC0/KEln ZAgO8nDEuBYfoYKSMAU4vtVbCBkvEb9SD9//J717J6+7E2fMpHijG2NQyronBJ9G6rhw VWag== 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=MSKL96ZN6ZyWq9nyvWVLbKbFMT6ELcFPty//VhYMDf4=; b=JZS5XMB5ifVHWQILZIe0gUkCO5tCZZPHvDeZilzbDF5IzCXcpUYUuTEED1n2QLK4Aq 78mC6sss7zsgDfERmMz3VPXjwmCy2bRgB0AcHjck16joPRag5NGBeK9Y4hiosZF10kjB zBGkGzEGZGxDWmTj3DWjaNzm1gMU9sEFwf9W7NC7LitsI0dRC633DRHcRipQPVkl0885 rMUijh8lyphNi7RFjONbsAn8HanJFFIvB7LiCDoCRIAZKSdmmV8MhyLaXzpEpGH/pjEI VOo2awxJ5+t8rm8HjzhHCpJmTw9IzLKZATFxjePclh18hAxTukXp25oKU0YTgyt7VOlH qpYQ== X-Gm-Message-State: AOAM530eHAA6OFTamcQcJIz+G24Z14QAR1qir8fIj5JwnR3MaOqAx5R5 BFeoz+gL/O06yb8xp6j04B7+cJBKIib9mQ/+UY5dKfsY X-Google-Smtp-Source: ABdhPJyHoSOCOs4GYlP/LTXihj4yip3fwKTFKg8Mm8qov9GN8MOajm4ru2LymIs0ph7i++6ZR4Rkap/U3YN9aKzjYOA= X-Received: by 2002:a37:cd4:: with SMTP id 203mr53781093qkm.490.1594135304119; Tue, 07 Jul 2020 08:21:44 -0700 (PDT) MIME-Version: 1.0 References: <2d1b-5f035980-1-53713100@74279099> <51A5B187-EAAB-4126-BE29-C18ADAFFB179@wire.com> <4BB46738-4B7D-472C-B8DA-A51A93B33DD9@wire.com> In-Reply-To: <4BB46738-4B7D-472C-B8DA-A51A93B33DD9@wire.com> From: Richard Barnes Date: Tue, 7 Jul 2020 11:21:26 -0400 Message-ID: To: Raphael Robert Cc: Hubert Chathi , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000086c0c405a9db8c36" Archived-At: Subject: Re: [MLS] Circular dependency in node hash calculation? 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, 07 Jul 2020 15:21:55 -0000 --00000000000086c0c405a9db8c36 Content-Type: text/plain; charset="UTF-8" Yeah, just to restate / reaffirm what Raphael says: * You get parent_hash values when you get the tree initially (in Welcome) or when you process a DirectPath * You compute node hashes based on those hashes, plus the other contents of the nodes Totally agree that this is tricky to get right, though :) If you have suggestions for how we can make this clearer, they would be welcome. --Richard On Mon, Jul 6, 2020 at 4:43 PM Raphael Robert wrote: > (forgot to include the list) > > > On 6 Jul 2020, at 22:05, Raphael Robert wrote: > > > > Hi Hubert, > > > > I admit this looks a bit confusing. The parent_hash field of a > ParentNode is not to be calculated at that point in time. Instead, it > should already be there. It gets populated by processing a Commit message, > where a LeafNode gets updated and its entire direct path is also updated. > In other words, calculating the tree hash is strictly a top down operation. > > > > Regarding the serialisation: MLS uses the TLS presentation language > specified in RFC8446. > > > > Raphael > > > >> On 6 Jul 2020, at 19:04, Hubert Chathi wrote: > >> > >> I may be missing something, but it seems to me like there is a circular > dependency in the definition of the hash of a parent node. In the "Tree > Hashes" section, it says that when computing the hash of a parent node, you > use the ParentNodeHashInput struct, which includes an item that is a > ParentNode (which I assume is the data concerning the node that you are > hashing), as well as the hashes of the two children. However, ParentNode > contains an item called parent_hash, which I assume is the hash of the > node's parent. Thus to calculate the hash of a node, you need to > calculate the hash of its parent, but that requires calculating the hash of > both its children, meaning that you need to calculate the hash of node that > you were trying to calculate in the first place. > >> > >> Am I reading it wrong (and if so, can there be more clarification > added), or is there a bug in the definitions? > >> > >> Also, when calculating the hash of a struct, is there a prescribed > serialization format to use, or is it up to the application to define the > serialization format? > >> > >> Thanks > >> > >> Hubert > >> > >> _______________________________________________ > >> 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 > --00000000000086c0c405a9db8c36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, just to restate / reaffirm what Raphael says:

* You get parent_hash values when you get the tree = initially (in Welcome) or when you process a DirectPath
* You com= pute node hashes based on those hashes, plus the other contents of the node= s

Totally agree that this is tricky to get right, = though :)=C2=A0 If you have suggestions for how we can make this clearer, t= hey would be welcome.

--Richard


On Mon, Jul 6, 2020 at 4:43 PM Raphael Robert <raphael=3D40wire.com@dmarc.ietf.org> wrote:
(forgot to include= the list)

> On 6 Jul 2020, at 22:05, Raphael Robert <raphael@wire.com> wrote:
>
> Hi Hubert,
>
> I admit this looks a bit confusing. The parent_hash field of a ParentN= ode is not to be calculated at that point in time. Instead, it should alrea= dy be there. It gets populated by processing a Commit message, where a Leaf= Node gets updated and its entire direct path is also updated. In other word= s, calculating the tree hash is strictly a top down operation.
>
> Regarding the serialisation: MLS uses the TLS presentation language sp= ecified in RFC8446.
>
> Raphael
>
>> On 6 Jul 2020, at 19:04, Hubert Chathi <hubertc@matrix.org> wrote:
>>
>> I may be missing something, but it seems to me like there is a cir= cular dependency in the definition of the hash of a parent node.=C2=A0 In t= he "Tree Hashes" section, it says that when computing the hash of= a parent node, you use the ParentNodeHashInput struct, which includes an i= tem that is a ParentNode (which I assume is the data concerning the node th= at you are hashing), as well as the hashes of the two children.=C2=A0 Howev= er, ParentNode contains an item called parent_hash, which I assume is the h= ash of the node's parent.=C2=A0 Thus to calculate the hash of a node,= =C2=A0 you need to calculate the hash of its parent, but that requires calc= ulating the hash of both its children, meaning that you need to calculate t= he hash of node that you were trying to calculate in the first place.
>>
>> Am I reading it wrong (and if so, can there be more clarification = added), or is there a bug in the definitions?
>>
>> Also, when calculating the hash of a struct, is there a prescribed= serialization format to use, or is it up to the application to define the = serialization format?
>>
>> Thanks
>>
>> Hubert
>>
>> _______________________________________________
>> 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
--00000000000086c0c405a9db8c36-- From nobody Tue Jul 7 08:24:43 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 69DBA3A0E2F; Tue, 7 Jul 2020 08:24:42 -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 (4096-bit key) header.d=matrix.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A7P-xEFG63L; Tue, 7 Jul 2020 08:24:41 -0700 (PDT) Received: from polemos.matrix.org (polemos.matrix.org [94.237.46.156]) (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 48E3F3A0E1D; Tue, 7 Jul 2020 08:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matrix.org; s=polemos; h=Content-Transfer-Encoding:Subject:Message-ID:MIME-Version:To:Cc :Date:From:In-Reply-To:Content-Type:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=70m2dXrDBe7/sxhwP2IsnjDPaB33HF4fonOrZUCiC88=; b=Qaugl8g8ZUsB1LV5mnEeTaIsCh 7IUvlJ6bQozIgZVrnzHOAOUBoTVRlxlVDHfqXQJ/tnWHwM0o/jDBoyHju7IJM4e1TS1i3YL0L0Hza DuKeThPZBKqxF48lpGWl8WhPVTDAKVfz8KBEEx6t5G6EWHnN2yJxgsx1Ubn1+4BCb9DQuos5n9und zQ15mEO7aQKck7HGX0bHavjcr9aQCfD5uFw448PHygkuHF9TPfYsyn0/G14/1qniT03Rbph+TxKSX xLCMIxVnmLnuxAoaSogsJQm7GpU0pXWhem127s1xnw6h0FD0ScTyOYLc84s/a42odAgPSXbqMv5Wi YIcBFm9obIh18uguqTZARklEy/yaKsplpin9k2Jk4RxuzRYiJQE2/EoiPDAQmIffU8667cj2gFAt+ MHANL7Urt37slua3D+0yQBXnAcBjROwi7M5hkyQ/nSeowNS9+JP84FS4kU972Hsexdoeiw9BjogBt 57Bypp71r97rPZ+XLQ4tm7sAZeF5J68fE5LsSGuFuSenq79J9RItTCNYldC2S3TA1qbayJ6+e4vhv vo7iU1UvZghjreNS5Zt4icwhPEJq1oHzgX6RMulJKHREfn3YW8cqaaNPfiQtIL+4Ei3lJzFfxATok 8YGWPcrCQ/MxARtlMGSzCfRuFyDL8Hvj8Ws87nN10=; Received: from [127.0.0.1] (helo=localhost) by polemos.matrix.org with esmtp (Exim 4.89) (envelope-from ) id 1jspSY-0004md-Bm; Tue, 07 Jul 2020 15:24:38 +0000 Content-Type: text/plain; charset="utf-8" In-Reply-To: From: "Hubert Chathi" X-Forward: 192.252.163.163 Date: Tue, 07 Jul 2020 16:24:38 +0100 Cc: "Raphael Robert" , "Messaging Layer Security WG" To: "Richard Barnes" MIME-Version: 1.0 Message-ID: <47d2-5f049380-1-53b35d00@74914386> User-Agent: SOGoMail 3.2.6 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__Circular_dependency_in?= =?utf-8?q?_node_hash_calculation=3F?= 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, 07 Jul 2020 15:24:43 -0000 Thanks to both of you for the clarifications. I'll see if I can come u= p with a way to make it clearer. On Tuesday, July 07, 2020 11:21 EDT, Richard Barnes wrote:= > Yeah, just to restate / reaffirm what Raphael says: > > * You get parent=5Fhash values when you get the tree initially (in We= lcome) > or when you process a DirectPath > * You compute node hashes based on those hashes, plus the other conte= nts of > the nodes > > Totally agree that this is tricky to get right, though :) If you hav= e > suggestions for how we can make this clearer, they would be welcome. > > --Richard > > > On Mon, Jul 6, 2020 at 4:43 PM Raphael Robert 40wire.com@dmarc.ietf.org> wrote: > > > (forgot to include the list) > > > > > On 6 Jul 2020, at 22:05, Raphael Robert wrote:= > > > > > > Hi Hubert, > > > > > > I admit this looks a bit confusing. The parent=5Fhash field of a > > ParentNode is not to be calculated at that point in time. Instead, = it > > should already be there. It gets populated by processing a Commit m= essage, > > where a LeafNode gets updated and its entire direct path is also up= dated. > > In other words, calculating the tree hash is strictly a top down op= eration. > > > > > > Regarding the serialisation: MLS uses the TLS presentation langua= ge > > specified in RFC8446. > > > > > > Raphael > > > > > >> On 6 Jul 2020, at 19:04, Hubert Chathi wrot= e: > > >> > > >> I may be missing something, but it seems to me like there is a c= ircular > > dependency in the definition of the hash of a parent node. In the = "Tree > > Hashes" section, it says that when computing the hash of a parent n= ode, you > > use the ParentNodeHashInput struct, which includes an item that is = a > > ParentNode (which I assume is the data concerning the node that you= are > > hashing), as well as the hashes of the two children. However, Pare= ntNode > > contains an item called parent=5Fhash, which I assume is the hash o= f the > > node's parent. Thus to calculate the hash of a node, you need to > > calculate the hash of its parent, but that requires calculating the= hash of > > both its children, meaning that you need to calculate the hash of n= ode that > > you were trying to calculate in the first place. > > >> > > >> Am I reading it wrong (and if so, can there be more clarificatio= n > > added), or is there a bug in the definitions? > > >> > > >> Also, when calculating the hash of a struct, is there a prescrib= ed > > serialization format to use, or is it up to the application to defi= ne the > > serialization format? > > >> > > >> Thanks > > >> > > >> Hubert > > >> > > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > >> MLS mailing list > > >> MLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/mls > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > MLS mailing list > > MLS@ietf.org > > https://www.ietf.org/mailman/listinfo/mls > > From nobody Tue Jul 7 10:05: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 D404D3A1181 for ; Tue, 7 Jul 2020 10:05:49 -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 yWleXlV3aAbC for ; Tue, 7 Jul 2020 10:05:47 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 C64543A1189 for ; Tue, 7 Jul 2020 10:05:39 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id u8so19138514qvj.12 for ; Tue, 07 Jul 2020 10:05:39 -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=mnuroqyBvelswuTvuPKpvxXZoWDpJEOWFpptTGjzTo0=; b=QbfgO7gxQ3PNZO+5A+Vx2buzlEBiyNNtHVYzvKh82HWlC35kS5a3FlU/laETEt/d6J Vx4EK4kc8EhQE6KDxKqfveW+i1mjVXCL514zXJh1l8UJLnisRl/D6kqBYy+8SznYdyzI 2bwfB6+GwOvg4Tjx33VUFpTcHN/CfWDLAIxbZLVdsv+GH+VIfb8PddIlwqDLuqjrLS4z gSNo2LyhsZUTNXszpgceYS1ktsztGtI70qSgDwIGmhebFEG7PvgOsT3LCJd6qnVVwnf6 gdgP5svAkfHXrYRyTmUpgpphAFYLCy1N26M3qde38tbtrf2d7I58hec5a63xyAgKFgKS Tytg== 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=mnuroqyBvelswuTvuPKpvxXZoWDpJEOWFpptTGjzTo0=; b=VGksu6beDDmSPRedqyrQo3cLw4s6UQNdNrN5K6iFh48HODGHsurZGPm0O2ktHtgydI B2vXjW2VvQ/nZsgEBCwjoUzIHDYSSc0UPjiEi410sGEnuKk5cgCs+OTRIAwcGqtr/FBJ 4hhbikOd9I6k7EzB7gYROrGTfPZQ8yARK+g+Q/bXzk6QZhpiGTXKEJWyOEAak3qY9UwH IiqngcrcA9S7/rbnHUp1buV5VCcz85JXt70hze5+dzaipOUbJyYpCD16n4qD7RxYZ0f2 CqX5PC+VYQdBwo5ihX0sRjQq1iLxZ0d0cOphZrFTRVjrLt7Vrkt39FFEa5XlgiIgWPzi WOgA== X-Gm-Message-State: AOAM533uDrBWCK2muaTOXSLC/BqZezFXKYbhPoHJrQDb77C1PdIhNYhE B0R5akKqo67UWlislv20tdaX8zQAu3yZiWSlfR6N4g== X-Google-Smtp-Source: ABdhPJxiKXY5MHiWbKb0kjuBwykIoWhAf2Fx8DYNRzxCpovcF9KWrEnpTIKtDYb6t/ahtMP8SUByHnjv96VUx8VrXIY= X-Received: by 2002:a05:6214:925:: with SMTP id dk5mr40949189qvb.183.1594141538450; Tue, 07 Jul 2020 10:05:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 7 Jul 2020 13:05:20 -0400 Message-ID: To: Sean Turner Cc: MLS List Content-Type: multipart/alternative; boundary="0000000000001f0fb205a9dd0096" Archived-At: Subject: Re: [MLS] 7/7 Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 17:05:50 -0000 --0000000000001f0fb205a9dd0096 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Notes from today's call: MLS Interim 2020-07-07 * #354 - To merge after Hubert fixes the minimum * #352 - Good to merge * #353 * Maybe there should be a noop proposal? * Britta: Clarify in first note exactly what an empty commit is for * Raphael: Three types of commits * Generic: Update leaf of committer + some number of proposals * Add-only: No path * No-proposals: as here * Raphael: Note that you get PCS for updaters, committer when there is a path * #349 * Concerns about whether this stuff will just need to get added back by applications, maybe spamming * =E2=80=A6 and whether there might be desync issues * Re-adding in AAD could be a good compromise, maybe describe in the arch doc * TODO(RLB): Send to mailing list to see if other folks share these concerns * #350 * TODO(SPT): Find better reference for SECG * TODO(RLB): Clarify that the signature scheme is implied by the cipher suite in the KeyPackage * TODO(RLB): Remove ratchet_tree extension * TODO(RLB): Reserve private use space in the registries On Tue, Jul 7, 2020 at 10:42 AM Sean Turner wrote: > Just a reminder that there is a virtual interim planned for today at 16:0= 0 > UTC. > Attendance link is here: > https://ietf.webex.com/ietf/j.php?MTID=3Dm7f300037f89a213366d395bd400579a= 8 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000001f0fb205a9dd0096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Notes from today's call:

MLS Interim 2020-07-07

* #354 - To merge after Hubert fixes the min= imum
* #352 - Good to merge
* #353
=C2=A0 =C2=A0 * Maybe there sh= ould be a noop proposal?
=C2=A0 =C2=A0 * Britta: Clarify in first note e= xactly what an empty commit is for
=C2=A0 =C2=A0 * Raphael: Three types = of commits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Generic: Update leaf of committ= er + some number of proposals
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * Add-only: No= path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * No-proposals: as here
=C2=A0 =C2= =A0 * Raphael: Note that you get PCS for updaters, committer when there is = a path
* #349
=C2=A0 =C2=A0 * Concerns about whether this stuff will = just need to get added back by applications, maybe spamming
=C2=A0 =C2= =A0 * =E2=80=A6 and whether there might be desync issues
=C2=A0 =C2=A0 *= Re-adding in AAD could be a good compromise, maybe describe in the arch do= c
=C2=A0 =C2=A0 * TODO(RLB): Send to mailing list to see if other folks = share these concerns
* #350
=C2=A0 =C2=A0 * TODO(SPT): Find better re= ference for SECG
=C2=A0 =C2=A0 * TODO(RLB): Clarify that the signature s= cheme is implied by the cipher suite in the KeyPackage
=C2=A0 =C2=A0 * T= ODO(RLB): Remove ratchet_tree extension
=C2=A0 =C2=A0 * TODO(RLB): Reser= ve private use space in the registries

On Tue, Jul 7, 2020 at 10:4= 2 AM Sean Turner <sean@sn3rd.com&g= t; wrote:
Just a= reminder that there is a virtual interim planned for today at 16:00 UTC. Attendance link is here:
https://ietf.webex.com/iet= f/j.php?MTID=3Dm7f300037f89a213366d395bd400579a8
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000001f0fb205a9dd0096-- From nobody Sun Jul 12 00:41: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 5E5423A0EB8 for ; Sun, 12 Jul 2020 00:41:11 -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=mlbapYgx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nhwN4OTS 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 HTqDToZlktc5 for ; Sun, 12 Jul 2020 00:41:09 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE22B3A0EB6 for ; Sun, 12 Jul 2020 00:41:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8A9CD5C00F3 for ; Sun, 12 Jul 2020 03:32:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 12 Jul 2020 03:32:17 -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=YifX9lZthadbs8y2ZPpuuJ+LfBg2Dw6vpGlmM3AlzCI=; b=mlbapYgx M5jg5VRwo+sTge+gvpS/mGzzm4ukQq/5Ojz/A20OneuS3BftrLLUV/MabB0tUo8j Mpvz7Kgp0B9QSOjiGvWOFMKuvGVR5L9VujVLUN6ImW05qpT3IfTeZzpCCXdIyc9C 04QN93Y+lQYIIiLsXr5nQ+Z9HFbqAqsw+sGVSHLshPbWq6pm5v2yomoKoFSVsRhm z4SM+A/XpYSZ19qAFiipXy0HJV2/BUk8N6VOoPFYfUxnSH+0/K1l7kOHn3NoNm1C mpK66LY81DkZqKce84lUx7fN54lAskdVV1nkcnDoUdNpXJwyV6Oma3p4EpUQDtHT LcPFp317Cp2tcw== 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=fm3; bh=YifX9lZthadbs8y2ZPpuuJ+LfBg2D w6vpGlmM3AlzCI=; b=nhwN4OTSSzcTsUo6TBRmU/wFfAQ+a6id2bykQJFTmB0YU jYFc56+sluGz3TlL+DQBq7XX0iIJ4GT+Yj5a8VLcdiZQ7oUm9A2gQJ5mAhRlbKSV lCOP5SKuPpC42aKpNZjFPplbIwy+lXBRpoN9vFD+UK9isQItJRcLmZAYV/czmR/y jONiiBUxPzgXKZltqBwJuVjzwqPFERuA8VXcRi5Go0xzgBYAFwHvfJfnv61Xi03M Imd/M16zS3gK7axPGnl3FqQeE09Ghv37mAWgisAvKW8G0v0wc0CiTFqESWCbxJdo KSj/MazusH2eu8A3k8zFR3DoEbYKyApRDlumDxjSQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdehgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrkeekrddufeegrdegke enucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az86.internal.cloudapp.net (unknown [40.88.134.48]) by mail.messagingengine.com (Postfix) with ESMTPA id 54C2630600A3 for ; Sun, 12 Jul 2020 03:32:17 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8703676083320676368==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200712073217.54C2630600A3@mailuser.nyi.internal> Date: Sun, 12 Jul 2020 03:32:17 -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, 12 Jul 2020 07:41:11 -0000 --===============8703676083320676368== 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: - Use the same index for hashing parent and leaf nodes https://github.com= /mlswg/mls-protocol/issues/328 [enhancement]=20 Pull requests ------------- * mlswg/mls-architecture (+2/-0/=F0=9F=92=AC0) 2 pull requests submitted: - Expand privacy section (by d1vyank) https://github.com/mlswg/mls-architecture/pull/67=20 - Clarify guarantees on TLS compromise (by d1vyank) https://github.com/mlswg/mls-architecture/pull/66=20 * mlswg/mls-protocol (+4/-5/=F0=9F=92=AC6) 4 pull requests submitted: - Fix build by switching to GitHub actions (by Bren2010) https://github.com/mlswg/mls-protocol/pull/358=20 - Fix all compiler warnings. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/357=20 - Minor editorial changes (by d1vyank) https://github.com/mlswg/mls-protocol/pull/356=20 - Validate external proposals from preconfigured senders (by d1vyank) https://github.com/mlswg/mls-protocol/pull/355=20 5 pull requests received 6 new comments: - #358 Fix build by switching to GitHub actions (2 by Bren2010, katrielal= ex) https://github.com/mlswg/mls-protocol/pull/358=20 - #357 Fix all compiler warnings. (1 by Bren2010) https://github.com/mlswg/mls-protocol/pull/357=20 - #355 Validate external proposals from preconfigured senders (1 by d1vya= nk) https://github.com/mlswg/mls-protocol/pull/355=20 - #349 Use opaque epoch IDs and encrypt content type (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/349=20 - #348 Make the tree in the Welcome optional (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/348=20 5 pull requests merged: - Validate external proposals from preconfigured senders https://github.com/mlswg/mls-protocol/pull/355=20 - Fix build by switching to GitHub actions https://github.com/mlswg/mls-protocol/pull/358=20 - Minor editorial changes https://github.com/mlswg/mls-protocol/pull/356=20 - misc little fixes https://github.com/mlswg/mls-protocol/pull/354=20 - Use node_index for both hashes https://github.com/mlswg/mls-protocol/pull/352=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============8703676083320676368== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday July 12, 2020

Issues

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

1 issues closed:

Pull requests

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

2 pull requests submitted:

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

4 pull requests submitted:

5 pull requests received 6 new comments:

5 pull requests merged:

Repositories tracked by this digest:

--===============8703676083320676368==-- From nobody Sun Jul 12 18:21:44 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 C82763A0645 for ; Sun, 12 Jul 2020 18:21:42 -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 wwBtW39Z32NX for ; Sun, 12 Jul 2020 18:21:41 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 91B1F3A060A for ; Sun, 12 Jul 2020 18:21:41 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id e12so8829665qtr.9 for ; Sun, 12 Jul 2020 18:21:41 -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=Sk3z5wNoopo5WhFbZz8wc10BKl6yxAR6EJAhZzVGh90=; b=MATaIwiHOIF1rAfpPI2yB4N9mC0fHHnMT49U+WhgbggcCaJXYA4Sk2hcuBuJxACPQ7 nVwgw/RYMX4oCEaCIwy1v58MpVx6I2fQCdgqqRlXuWZAZBLlTZ5FUFEJzVGATIQhTOn3 K9APj0atJKsyvPLneS+QdXfybK5Z1QTWcAlZ4= 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=Sk3z5wNoopo5WhFbZz8wc10BKl6yxAR6EJAhZzVGh90=; b=HFxLGLqPY22DzCfKDbJEpopVJN/ljZo3dewknXA76b2OCcmSHJo9pcQTccgKU+0k6O E9pt1dFBpgG1KV/QtkNfhnwWbZ27lDNVJJxKAjC57CyAWUxiplrFsL6RGaZky5KRq+MJ sUqdhCHub2sveYXY5IUlAqEo6jv1dv6p+8bQ3fWS6yEmiDZ1/r8tNOHGsUsKSOajRN1h 7eXWOmbgZfIMw20C0+kycPL1HyRgzI9IkGVX3Y5HSoATwHE4uzk54Qngg1Kd1p3tDtdI Jbs7kXtkhp0FA9dM750TY6UwGAJEyrZMdAk1RhSYvUhQ6w6Hrso8O20FphtbYHLNwxBN QL6w== X-Gm-Message-State: AOAM530lROr70seHvx3V5DDK5c36T/yHvrYKx0nXNmiwSb3UFi/68gV2 RK2/0+lkX6EvhO5RiR8Gw44edcA3b3E= X-Google-Smtp-Source: ABdhPJwkHRZBeblhbqLawA7DeUwj5VRfEqNkhHxDQtLIuS/sLXUh2/0V1w9NsUIn1naJ1Hn8Cmw2UA== X-Received: by 2002:aed:3904:: with SMTP id l4mr77490768qte.370.1594603300172; Sun, 12 Jul 2020 18:21:40 -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 l5sm9107958qtd.37.2020.07.12.18.21.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2020 18:21:39 -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.80.23.2.2\)) Message-Id: Date: Sun, 12 Jul 2020 21:21:38 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [MLS] 7/14 Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 01:21:43 -0000 Just a reminder that there is a virtual interim planned for Tuesday July = 14 at 16:00 UTC. Attendance link is here: https://ietf.webex.com/ietf/j.php?MTID=3Dm7f300037f89a213366d395bd400579a8= spt= From nobody Mon Jul 13 06:56: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 5FFF23A11FB for ; Mon, 13 Jul 2020 06:56: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 kyXdEFWdgqYB for ; Mon, 13 Jul 2020 06:56:17 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA043A11F1 for ; Mon, 13 Jul 2020 06:56:17 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id k18so9925450qtm.10 for ; Mon, 13 Jul 2020 06:56:17 -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=XLkHcEKwfZSwK0FO7kcLPwlzLqUEA6DIfBY/bZeEy2I=; b=hD+Vz3ukatN+Yq1MCNs+YQIEeVTA6zPvP+j/rezUD7YZpxTA4SoficpVEgF2M5TAsC ctVaQCezV+lildSgwBfrvadDmzcoOOK0XLu/8is4q360DbwFfi0jz4vFKgyvSzl6tXX7 x7iWZNcAY9CO9HqErD6mmDhN0N7VXJ1OviOYs2S6ng+AqY12LgZyEMqQG3CLfsDME8sA QWnxnklnzFWtraj9V8p+xctH88xKTAzmZxcC/kcB1xZ4KIKsOdJHqpxTqsyBBTNH6GH0 LsWDEAhARX8IiDDl2+hHzMQ/XqIwFdtjmNnFxxE4BNYAPizz+TOJxNcdQhmy4g00v2we Ycxw== 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=XLkHcEKwfZSwK0FO7kcLPwlzLqUEA6DIfBY/bZeEy2I=; b=MZkMoDZuwCQ4zEBsISCzeu2V5JiUnPdzKYAzxNhw0AcC1kSCZlMcvD0XZsPRxPdrfQ r154Zjf+qRMh6+f3xb2dYVNQGppwKPH05ceMft9oWBQkh3OFxRP3m4e4LGFxIoeqim6D fbtbVioDDdWVhgGS8NAEOotHA7wxDZLuNmwRWWqxz505l/Ns6PpLyE6D6MZIcm/Bhp0L czLYj00kinUFB52M6V5DklR2fqOIU5/q0Qzn8EFvVwFNOd0IF02VbnVULByamET4hA3x gorjnqDm1WTHqUQqMfbwYwuhYPQ3qSpz7EXk7/DR+Bxe7CFKpfo8s3+hjJCSKJik6yAK yw8A== X-Gm-Message-State: AOAM530gB7J7+D6CfXYntdtPpCf/y2pi+rnJL672OkAzxoUi0eNJurm7 eOplpItat/lPedd58vtWnLKARNg8iFLlWYib35MIBtB0JWM= X-Google-Smtp-Source: ABdhPJw4eFmjUYYf9SLme6wCTJldkwoBH8vYYxX3suGzZW9sXDXGIsPf5pJrqLnwUsBVpxUNQVWsU31YIB7VsO0wUWk= X-Received: by 2002:ac8:4649:: with SMTP id f9mr35077764qto.313.1594648576162; Mon, 13 Jul 2020 06:56:16 -0700 (PDT) MIME-Version: 1.0 From: Richard Barnes Date: Mon, 13 Jul 2020 09:55:55 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000ec99d205aa530d0b" Archived-At: Subject: [MLS] Hiding content type 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, 13 Jul 2020 13:56:19 -0000 --000000000000ec99d205aa530d0b Content-Type: text/plain; charset="UTF-8" Hi all, Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) encrypt the content type of the message (application / proposal / commit) [1]. There was some discussion on the call last week that encrypting the content type might not be that useful, since an application that relies on a server to assure ordering of commits will need to at least be able to tell commits from other things. Of course, even if the content type is encrypted by default, the application can add it back in authenticated data, or in some unauthenticated wrapper. Net of those considerations, I'm personally still inclined to merge the PR, to have a conservative baseline. But those on the call thought it would be useful to pose this to the group, so please speak up if you have concerns. --Richard [1] https://github.com/mlswg/mls-protocol/pull/349 --000000000000ec99d205aa530d0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Recall that PR#349 d= oes two things (1) use an opaque epoch ID, and (2) encrypt the content type= of the message (application / proposal / commit) [1].

=
There was some discussion on the call last week that encrypting the co= ntent type might not be that useful, since an application that relies on a = server to assure ordering of commits will need to at least be able to tell = commits from other things.=C2=A0 Of course, even if the content type is enc= rypted by default, the application can add it back in authenticated data, o= r in some unauthenticated wrapper.

Net of thos= e considerations, I'm personally still inclined to merge the PR, to hav= e a conservative baseline.=C2=A0 But those on the call thought it would be = useful to pose this to the group, so please speak up if you have concerns.<= /div>

--Richard

--000000000000ec99d205aa530d0b-- From nobody Mon Jul 13 07:57: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 853683A09BE for ; Mon, 13 Jul 2020 07:57:43 -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=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 IPR1La5dT6bq for ; Mon, 13 Jul 2020 07:57:42 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DDA3A09E8 for ; Mon, 13 Jul 2020 07:57:41 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id a32so10150103qtb.5 for ; Mon, 13 Jul 2020 07:57:41 -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=LF6lrrU4ITBx/LDF52PGrxzhdb6RpjebhcO+/g/HhMA=; b=hGyuoPQwFc6PIrzB9fM427y32VUCMxY0squdZOiyjb0Im2rHCxCeaE+EjudIElmfCc 0V0U2JQA2FV1Eb96y5V8PJ/8FU57XHdjdo+8sW6FALuLw2SwXeJfZcXR5czIZTkWClRA 2dATR1r0ZgPtfbU3jtHaR5rFvkLCMqIq3MDjU= 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=LF6lrrU4ITBx/LDF52PGrxzhdb6RpjebhcO+/g/HhMA=; b=Kij4NSyHLGL2sNPXqm93uVtKa8j/Zu09Ou6UYmXNRt4Y9yHxiE3pYRQSR/KqEAmwe5 GUqJ1zCgJXi+a2x8CKMWsgzjHgOkglvr14DFMmzDWw9CEZbfpX9u5naE3wRxrw5cRTfP gdt2dRlIubmCH6pfUavdZJ6zrTISQcdnkQ3tiCUj8NdyeC7/ZBZaE0ua08VS5fH1PhSG yBTgjvkHu75CgAf5qGmLSn8S4DK8sZaIR07yzeGAjL0XAc1PMbB85s9LgdRNJhrTIv0C K22K4HPbNkW5mZSrg2XZT7ix5vT5v1IF7Ki+InyjZDce09M2izLT8ZtmIg/uIyRHSNl1 5dbw== X-Gm-Message-State: AOAM530wmOx0/pZVsyWIOD53nlyrp1ekUJqd3Z2pKhO4/PqhLDoOasDD qyngb3odzeAlsY5QXPF2g2Uud2FFZK7X4aNyE6caZ5MjnA4= X-Google-Smtp-Source: ABdhPJz/SvMQkxHNGOvZEXMdfouutVegcwdFnAQ+sltrzzoaTYfhXLxEH/mOoE85qyqgQh/ii4h8dzNgni8U8VdB7yo= X-Received: by 2002:ac8:d86:: with SMTP id s6mr56225547qti.343.1594652259191; Mon, 13 Jul 2020 07:57:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brendan McMillion Date: Mon, 13 Jul 2020 09:57:28 -0500 Message-ID: To: Richard Barnes Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000073487f05aa53e9f8" Archived-At: Subject: Re: [MLS] Hiding content type 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, 13 Jul 2020 14:57:43 -0000 --00000000000073487f05aa53e9f8 Content-Type: text/plain; charset="UTF-8" With respect to using an opaque epoch id, I believe this was proposed in #245 and consensus was against it because it makes it more difficult to implement the DS. It's also not clear to me what security properties you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect this to be a source of confusion and bugs. With respect to encrypting the content type, it also seems to me that this would cause issues because different content types have different delivery guarantees. Specifically: messages are allowed to be unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and not lossy. In the deployment scenarios we've talked about, the DS essentially always needs to know the content type to provide this. Conversely, you don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id change and infer which message was a commit, or see a dropped message getting re-sent and infer it was a proposal. On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: > Hi all, > > Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) > encrypt the content type of the message (application / proposal / commit) > [1]. > > There was some discussion on the call last week that encrypting the > content type might not be that useful, since an application that relies on > a server to assure ordering of commits will need to at least be able to > tell commits from other things. Of course, even if the content type is > encrypted by default, the application can add it back in authenticated > data, or in some unauthenticated wrapper. > > Net of those considerations, I'm personally still inclined to merge the > PR, to have a conservative baseline. But those on the call thought it > would be useful to pose this to the group, so please speak up if you have > concerns. > > --Richard > > [1] https://github.com/mlswg/mls-protocol/pull/349 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000073487f05aa53e9f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With respect to using an opaque epoch id, I believe t= his was proposed in #245 and consensus was against it because it makes it more difficul= t to implement the DS. It's also not clear to me what security properti= es you want from an opaque epoch id, because the current PR doesn't pro= vide collision resistance and I'd expect this to be a source of confusi= on and bugs.

With respect to encrypting the conten= t type, it also seems to me that this would cause issues because different = content types have different delivery guarantees. Specifically: messages ar= e allowed to be unordered and lossy, proposals are allowed to be unordered = but not lossy, and commits are both ordered and not lossy. In the deploymen= t scenarios we've talked about, the DS essentially always needs to know= the content type to provide this. Conversely, you don't get much addit= ional privacy from encrypting the content type because an eavesdropper can = see the epoch id change and infer which message was a commit, or see a drop= ped message getting re-sent and infer it was a proposal.
On Mon, J= ul 13, 2020 at 8:56 AM Richard Barnes <rlb@ipv.sx> wrote:
Hi al= l,

Recall that PR#349 does two things (1) use an o= paque epoch ID, and (2) encrypt the content type of the message (applicatio= n / proposal / commit) [1].

There was some discuss= ion on the call last week that encrypting the content type might not be tha= t useful, since an application that relies on a server to assure ordering o= f commits will need to at least be able to tell commits from other things.= =C2=A0 Of course, even if the content type is encrypted by default, the app= lication can add it back in authenticated data, or in some unauthenticated = wrapper.

Net of those considerations, I'm = personally still inclined to merge the PR, to have a conservative baseline.= =C2=A0 But those on the call thought it would be useful to pose this to the= group, so please speak up if you have concerns.

-= -Richard

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000073487f05aa53e9f8-- From nobody Mon Jul 13 08:57:10 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 DF60B3A1518 for ; Mon, 13 Jul 2020 08:57:03 -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 IbYKKbro9pBG for ; Mon, 13 Jul 2020 08:57:01 -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 0D3693A1489 for ; Mon, 13 Jul 2020 08:56:56 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id z63so12631986qkb.8 for ; Mon, 13 Jul 2020 08:56:56 -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=oSSFSkl31s4xC8gYy5d/0zsCV/0h35AkfZeX1Qmi6f8=; b=YIeM/oN3O12GzItPh4csnedv7re0Lr4LqPrYNaZhNpQpwJiKokq88KOdpLQ9lBTals FmuQMSROutD8PtiAJWF5XIjWxKU6Y4DIiBNs6lpWNpcmYD2UKNstzLKmlfGXi4ioVzu1 AcuxPiIE+GCJ2MmJmnL48KYajpjO42lCPVDzS/46wVAhKP0aK+WtyNqhoP5GbLLXXPsB qEk+5kHVepyXcFBpj7sS5HGNALm2Dn+McKFozl0Iw95+Vm5B6DNdnAcl1aWohNeNcYlb 5AUKqs0tgDc/mqejvc3hutYHKKlqXGg/JNWpNAjYQz8pdqKiiFcix8W6EIE7wJ8cSyL5 E4MQ== 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=oSSFSkl31s4xC8gYy5d/0zsCV/0h35AkfZeX1Qmi6f8=; b=puGL4NFN67HOan63mMWH/fr0pgL1fb6zNR92zYeXSHtDcNl7X/dKfPGd/MK+aocLVm K9TPxh9royUA1TkZ4OXiN/+tOQJUYtAr+8g2LTeLYbUNas+KCo93JjuFzpGlFrltYPa5 jRkTQVmYQIyoiMceCzc1xoiGuIJb68c9gYHWMxTbTJHOiyzZ4S7M5PALLXl5uwGlU+JZ 8npNQ7PME0Hvs5O/M6RzbxGKS+zLJFX7m/TPibfAdTg45jrrOzySWo0IFThemPoxKrFY XTNWmDUQOmuWZP5bfA0lL7+UaPpO/y2mlodotRkOWEzbllhR5GZif2RCJ+OmTU0RhbSQ 0Wcg== X-Gm-Message-State: AOAM5316I48ob7gZBoTtB3C1od0kkSFq7NPl5b8OGXF7uxclxFkVSk0W D/Zvi/TGXwkqKU+p9Mt+qqXZGYGBVKEwW2G+92IFj9YM X-Google-Smtp-Source: ABdhPJxiwFBKoeRykHUzHMf27OEzoqXsD3BhM8QOsG1SQeNTodkoLsQB9K/oxBxMybl2uQsMj+oJ7UL5woGywBs+3u8= X-Received: by 2002:ae9:e517:: with SMTP id w23mr227344qkf.159.1594655815881; Mon, 13 Jul 2020 08:56:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 13 Jul 2020 11:56:35 -0400 Message-ID: To: Brendan McMillion Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000071e8d805aa54bdf2" Archived-At: Subject: Re: [MLS] Hiding content type 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, 13 Jul 2020 15:57:09 -0000 --00000000000071e8d805aa54bdf2 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion wrote: > With respect to using an opaque epoch id, I believe this was proposed in > #245 and consensus was > against it because it makes it more difficult to implement the DS. It's > also not clear to me what security properties you want from an opaque epoch > id, because the current PR doesn't provide collision resistance and I'd > expect this to be a source of confusion and bugs. > I think the discussion on #245 got derailed a bit by the focus on non-linear epochs. The point here is that even in a case where you have linear history, I think there's intrinsic value in the epoch ID being opaque because it gives intermediaries less opportunity for ossification. As far as collision resistance, I'm not too worried about collisions among 64-bit random values, especially as the scope for collision is fairly small, arguably just one epoch. > With respect to encrypting the content type, it also seems to me that this > would cause issues because different content types have different delivery > guarantees. Specifically: messages are allowed to be unordered and lossy, > proposals are allowed to be unordered but not lossy, and commits are both > ordered and not lossy. In the deployment scenarios we've talked about, the > DS essentially always needs to know the content type to provide this. > Conversely, you don't get much additional privacy from encrypting the > content type because an eavesdropper can see the epoch id change and infer > which message was a commit, or see a dropped message getting re-sent and > infer it was a proposal. > I don't disagree that there are different guarantees you need, but like I said, I think the idea here is to be conservative by default. There are systems in which you can hide the metadata you're talking about with things like mixnets and dropboxes. Keeping the ciphertext as opaque as possible keeps the door open to running MLS over those systems without MLS's own metadata undermining their privacy properties. FWIW, in the systems I'm looking at building, this PR does not make any difference, because clients use separate channels for Proposals/Commits vs. application data and the server doesn't check. --Richard > > On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: > >> Hi all, >> >> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) >> encrypt the content type of the message (application / proposal / commit) >> [1]. >> >> There was some discussion on the call last week that encrypting the >> content type might not be that useful, since an application that relies on >> a server to assure ordering of commits will need to at least be able to >> tell commits from other things. Of course, even if the content type is >> encrypted by default, the application can add it back in authenticated >> data, or in some unauthenticated wrapper. >> >> Net of those considerations, I'm personally still inclined to merge the >> PR, to have a conservative baseline. But those on the call thought it >> would be useful to pose this to the group, so please speak up if you have >> concerns. >> >> --Richard >> >> [1] https://github.com/mlswg/mls-protocol/pull/349 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --00000000000071e8d805aa54bdf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 13, 2020 at 10:57 AM Brendan = McMillion <brendan@cloudflare.= com> wrote:
With respect to using a= n opaque epoch id, I believe this was proposed in #245 and consensus = was against it because it makes it more difficult to implement the DS. It&#= 39;s also not clear to me what security properties you want from an opaque = epoch id, because the current PR doesn't provide collision resistance a= nd I'd expect this to be a source of confusion and bugs.

I think the discussion on #245 got derailed a= bit by the focus on non-linear epochs.=C2=A0 The point here is that even i= n a case where you have linear history, I think there's intrinsic value= in the epoch ID being opaque because it gives intermediaries less opportun= ity for ossification.

As far as collision resi= stance, I'm not too worried about collisions among 64-bit random values= , especially as the scope for collision is fairly small, arguably just one = epoch.

=C2=A0
With respect to encrypting the con= tent type, it also seems to me that this would cause issues because differe= nt content types have different delivery guarantees. Specifically: messages= are allowed to be unordered and lossy, proposals are allowed to be unorder= ed but not lossy, and commits are both ordered and not lossy. In the deploy= ment scenarios we've talked about, the DS essentially always needs to k= now the content type to provide this. Conversely, you don't get much ad= ditional privacy from encrypting the content type because an eavesdropper c= an see the epoch id change and infer which message was a commit, or see a d= ropped message getting re-sent and infer it was a proposal.
=

I don't disagree that there are differ= ent guarantees you need, but like I said, I think the idea here is to be co= nservative by default.=C2=A0 There are systems in which you can hide the me= tadata you're talking about with things like mixnets and dropboxes.=C2= =A0 Keeping the ciphertext as opaque as possible keeps the door open to run= ning MLS over those systems without MLS's own metadata undermining thei= r privacy properties.

FWIW, in the systems I&#= 39;m looking at building, this PR does not make any difference, because cli= ents use separate channels for Proposals/Commits vs. application data and t= he server doesn't check.

--Richard

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Ba= rnes <rlb@ipv.sx> wrote:
Hi all,

Recal= l that PR#349 does two things (1) use an opaque epoch ID, and (2) encrypt t= he content type of the message (application / proposal / commit) [1].
=

There was some discussion on the call last week that en= crypting the content type might not be that useful, since an application th= at relies on a server to assure ordering of commits will need to at least b= e able to tell commits from other things.=C2=A0 Of course, even if the cont= ent type is encrypted by default, the application can add it back in authen= ticated data, or in some unauthenticated wrapper.

<= div>Net of those considerations, I'm personally still inclined to merge= the PR, to have a conservative baseline.=C2=A0 But those on the call thoug= ht it would be useful to pose this to the group, so please speak up if you = have concerns.

--Richard

<= div>[1] https://github.com/mlswg/mls-protocol/pull/349
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000071e8d805aa54bdf2-- From nobody Mon Jul 13 09:32: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 8C8CF3A156D for ; Mon, 13 Jul 2020 09:32:44 -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 GIZehmlgovfA for ; Mon, 13 Jul 2020 09:32:42 -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 13B9E3A1523 for ; Mon, 13 Jul 2020 09:32:36 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id s10so17180114wrw.12 for ; Mon, 13 Jul 2020 09:32:35 -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=4fd+4KL2fAmoLtu69dfSr8B9uqtnvb1eDdgOkd9wXPI=; b=UB9TZ105PU06Aege51zv6Kyp5jmZPZC1S+Rx107zG/zbkZ0g18hjfHKS1jhtuf8huh hTuLgC5fx1hy9NwGr9O6EhoJBn84iIrp5g+m5xDCKjFdwmUpLmSWe1YY7mDRsKePmWju Qq/XcV3y3xqy4a/0O3QHGmfl1nJooSlsDuWrdR+eXy008U82T7r5SV9bSpTeT1re60sG mzQrx1SZdflwIQ8XvXhhYsS/hdUcCAzmz+RDSjzeisAkV/dXFBw9G7kM6NHzdcB+qJ+s 6bfmlPhi0o0XpMCO5zDikDz/CG5oI+vgzIfGk8OIi/4UDLKOaTC4AkDoXMEoHr9VwCZ+ Vs6A== 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=4fd+4KL2fAmoLtu69dfSr8B9uqtnvb1eDdgOkd9wXPI=; b=Ap2KDxmqpIL9XHGhQx08f93vmN2MRCiEsADBgxV6Y40AcY1EXwojyu0LXDWb//xkh6 k/oFj0KrXPbo/uS09O85zb3zUplEUoHfls12dRZpres0OQMB6wEWoGn1raM2vUD16o/5 /Ofv5uT9iEpHkLT7sYMB8dn1tn//csMQjWeUFOiAFdwh6DdYMY9b6oJuT0nmyfZL6LRG 91HaIRtGNnrs21GpcqsFMthBTc2bzDIQv+H0JFqZ3zIZEhFhER60XSviZ8Zc9CIqzMC0 t1kUSZrzrHWxZqia402bOwnqVydhpUAFSvOqJ41qur78PIjSDprfOpxhAgZ8SlfV11Ef k1Cw== X-Gm-Message-State: AOAM5325/F2vFn/+3eAABKaXhtteiOQrioW9dP2WsTQ0eKzIhocaPP0A rvx++ClDinV0LnKtC4dFJS/ICw== X-Google-Smtp-Source: ABdhPJxqYRnEgXSZ5YCYSWxBisyBRle8jrbGHAkLDlkN9KRTNvvtD5JDIamJsDUxfhYepEMksbVazA== X-Received: by 2002:a5d:5187:: with SMTP id k7mr183240wrv.39.1594657954339; Mon, 13 Jul 2020 09:32:34 -0700 (PDT) Received: from [192.168.178.21] ([134.3.30.253]) by smtp.gmail.com with ESMTPSA id o9sm24035423wrs.1.2020.07.13.09.32.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 09:32:33 -0700 (PDT) From: Raphael Robert Message-Id: <4A6AF95E-F3DA-40CF-A814-349D329BFE4D@wire.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AF49DD84-0876-406D-B8D2-E60C17805F82" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 13 Jul 2020 18:32:02 +0200 In-Reply-To: Cc: Brendan McMillion , Messaging Layer Security WG To: Richard Barnes References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Hiding content type 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, 13 Jul 2020 16:32:45 -0000 --Apple-Mail=_AF49DD84-0876-406D-B8D2-E60C17805F82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As mentioned on the call, I think that =E2=80=9Cprivacy by design=E2=80=9D= is the right approach (unless proven otherwise in specific cases) and = we should go forward with this. Raphael > On 13 Jul 2020, at 17:56, Richard Barnes wrote: >=20 > On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion = > wrote: > With respect to using an opaque epoch id, I believe this was proposed = in #245 and consensus = was against it because it makes it more difficult to implement the DS. = It's also not clear to me what security properties you want from an = opaque epoch id, because the current PR doesn't provide collision = resistance and I'd expect this to be a source of confusion and bugs. >=20 > I think the discussion on #245 got derailed a bit by the focus on = non-linear epochs. The point here is that even in a case where you have = linear history, I think there's intrinsic value in the epoch ID being = opaque because it gives intermediaries less opportunity for = ossification. >=20 > As far as collision resistance, I'm not too worried about collisions = among 64-bit random values, especially as the scope for collision is = fairly small, arguably just one epoch. >=20 > =20 > With respect to encrypting the content type, it also seems to me that = this would cause issues because different content types have different = delivery guarantees. Specifically: messages are allowed to be unordered = and lossy, proposals are allowed to be unordered but not lossy, and = commits are both ordered and not lossy. In the deployment scenarios = we've talked about, the DS essentially always needs to know the content = type to provide this. Conversely, you don't get much additional privacy = from encrypting the content type because an eavesdropper can see the = epoch id change and infer which message was a commit, or see a dropped = message getting re-sent and infer it was a proposal. >=20 > I don't disagree that there are different guarantees you need, but = like I said, I think the idea here is to be conservative by default. = There are systems in which you can hide the metadata you're talking = about with things like mixnets and dropboxes. Keeping the ciphertext as = opaque as possible keeps the door open to running MLS over those systems = without MLS's own metadata undermining their privacy properties. >=20 > FWIW, in the systems I'm looking at building, this PR does not make = any difference, because clients use separate channels for = Proposals/Commits vs. application data and the server doesn't check. >=20 > --Richard >=20 > =20 >=20 > On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: > Hi all, >=20 > Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) = encrypt the content type of the message (application / proposal / = commit) [1]. >=20 > There was some discussion on the call last week that encrypting the = content type might not be that useful, since an application that relies = on a server to assure ordering of commits will need to at least be able = to tell commits from other things. Of course, even if the content type = is encrypted by default, the application can add it back in = authenticated data, or in some unauthenticated wrapper. >=20 > Net of those considerations, I'm personally still inclined to merge = the PR, to have a conservative baseline. But those on the call thought = it would be useful to pose this to the group, so please speak up if you = have concerns. >=20 > --Richard >=20 > [1] https://github.com/mlswg/mls-protocol/pull/349 = __________________________= _____________________ > 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=_AF49DD84-0876-406D-B8D2-E60C17805F82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = mentioned on the call, I think that =E2=80=9Cprivacy by design=E2=80=9D = is the right approach (unless proven otherwise in specific cases) and we = should go forward with this.

Raphael

On 13 Jul 2020, at 17:56, = Richard Barnes <rlb@ipv.sx> wrote:

On Mon, Jul 13, 2020 at 10:57 AM = Brendan McMillion <brendan@cloudflare.com> wrote:
With respect to using an opaque epoch id, I believe this was = proposed in #245 and consensus was against it = because it makes it more difficult to implement the DS. It's also not = clear to me what security properties you want from an opaque epoch id, = because the current PR doesn't provide collision resistance and I'd = expect this to be a source of confusion and = bugs.

I think the discussion on #245 got derailed a bit by the = focus on non-linear epochs.  The point here is that even in a case = where you have linear history, I think there's intrinsic value in the = epoch ID being opaque because it gives intermediaries less opportunity = for ossification.

As far as collision resistance, I'm not = too worried about collisions among 64-bit random values, especially as = the scope for collision is fairly small, arguably just one = epoch.

 
With respect to encrypting the content type, it also seems to = me that this would cause issues because different content types have = different delivery guarantees. Specifically: messages are allowed to be = unordered and lossy, proposals are allowed to be unordered but not = lossy, and commits are both ordered and not lossy. In the deployment = scenarios we've talked about, the DS essentially always needs to know = the content type to provide this. Conversely, you don't get much = additional privacy from encrypting the content type because an = eavesdropper can see the epoch id change and infer which message was a = commit, or see a dropped message getting re-sent and infer it was a = proposal.

I don't disagree that there are = different guarantees you need, but like I said, I think the idea here is = to be conservative by default.  There are systems in which you can = hide the metadata you're talking about with things like mixnets and = dropboxes.  Keeping the ciphertext as opaque as possible keeps the = door open to running MLS over those systems without MLS's own metadata = undermining their privacy properties.

FWIW, in the systems I'm = looking at building, this PR does not make any difference, because = clients use separate channels for Proposals/Commits vs. application data = and the server doesn't check.

--Richard

 

On Mon, Jul 13, 2020 at 8:56 AM Richard = Barnes <rlb@ipv.sx> = wrote:
Hi all,

Recall that PR#349 does two things (1) use an opaque epoch = ID, and (2) encrypt the content type of the message (application / = proposal / commit) [1].

There was some discussion on the call last week that = encrypting the content type might not be that useful, since an = application that relies on a server to assure ordering of commits will = need to at least be able to tell commits from other things.  Of = course, even if the content type is encrypted by default, the = application can add it back in authenticated data, or in some = unauthenticated wrapper.

Net of those considerations, I'm = personally still inclined to merge the PR, to have a conservative = baseline.  But those on the call thought it would be useful to pose = this to the group, so please speak up if you have concerns.

--Richard

[1] = https://github.com/mlswg/mls-protocol/pull/349
_______________________________________________
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=_AF49DD84-0876-406D-B8D2-E60C17805F82-- From nobody Mon Jul 13 09:37:43 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 BED833A157B for ; Mon, 13 Jul 2020 09:37:42 -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=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 cvyWcbI3oman for ; Mon, 13 Jul 2020 09:37:40 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 AFE9E3A1578 for ; Mon, 13 Jul 2020 09:37:40 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id b4so12785490qkn.11 for ; Mon, 13 Jul 2020 09:37:40 -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=49ydJxFPbJ4iRNcKSxAHwYXIQP2eLP4eX8N1OxaIXw4=; b=HoxTE1q93SZ3LsBkfBJnXX/1oMGhn3xdNaGolCi3fdHaBAEZE/GGyMTOJRoRlxIjcJ 21s3N3UAtnhE6TqzlPnVGHQEHeRaK/KsVU73mMU0Ymc3o3q/8qvGPsBO7PwC0UeSPKUD 5IDrcLLBTQhkHhrqAl7u+Ea/nPH9Gg921579U= 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=49ydJxFPbJ4iRNcKSxAHwYXIQP2eLP4eX8N1OxaIXw4=; b=SzVu9e/19HJUGYKeakCTYocu0dNYH5EIX+6KSC4CddvgXiZNhENNp3gz0KDYOeaECr YteZAheqQxcmjiLEL2e4OkwsrChBe7xViyKWZYVzZNanwtAH+Zo7JLBG8FsY/yD9z5Uj QCM0dByyg3NJD/Rhvy7ElbGRFbHiwmsTsppo8BK0d71UfvQWGpaXFI+73JrjMSGTvekh I4675vtQKZUM3VIhAbjGjKwy/ZdSSdEkXxjnBq1GBSbAl8FcQ0VLlGi+FeJkaflHSJ8t mlds7CmywfHlubAtRLuTPeMtDc7qiAd8EUFHVvix/zg903T/LU1uzmLkXsUF7a52rOW9 JOTA== X-Gm-Message-State: AOAM530g64fepir2J5GBqigAWvBEkXypyajTC8nljMnKpOsJdOpgumN/ 0WHmp2WfTOG0Gcs2R0jjer5OI/G1tIct6rfQBPby+m0RRzXdxA== X-Google-Smtp-Source: ABdhPJyjI2FunbR4ZIVseRdOWFGK+saOWIWtj2FvnVkH/xGwU5C4zShGUSVNIigUVpFRm59PzeR8H2lU/h/eAswBZew= X-Received: by 2002:a05:620a:1007:: with SMTP id z7mr403609qkj.443.1594658259482; Mon, 13 Jul 2020 09:37:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brendan McMillion Date: Mon, 13 Jul 2020 11:37:28 -0500 Message-ID: To: Richard Barnes Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000185a8b05aa554f23" Archived-At: Subject: Re: [MLS] Hiding content type 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, 13 Jul 2020 16:37:43 -0000 --000000000000185a8b05aa554f23 Content-Type: text/plain; charset="UTF-8" > > As far as collision resistance, I'm not too worried about collisions among > 64-bit random values, especially as the scope for collision is fairly > small, arguably just one epoch. > The issue isn't with accidental collisions, it's with malicious ones. An attacker can purposefully (and quickly) generate commits that create duplicate epoch ids, and send them to a client to corrupt their group state. I think the idea here is to be conservative by default. There are systems > in which you can hide the metadata you're talking about with things like > mixnets and dropboxes. > It's not just being more conservative, you're making changes specifically for very niche use-cases where I don't think the security of the whole system has been thought through. Maybe you have an example in mind, but I can't think of a system where this change provides any additional privacy. On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: > On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion > wrote: > >> With respect to using an opaque epoch id, I believe this was proposed in >> #245 and consensus was >> against it because it makes it more difficult to implement the DS. It's >> also not clear to me what security properties you want from an opaque epoch >> id, because the current PR doesn't provide collision resistance and I'd >> expect this to be a source of confusion and bugs. >> > > I think the discussion on #245 got derailed a bit by the focus on > non-linear epochs. The point here is that even in a case where you have > linear history, I think there's intrinsic value in the epoch ID being > opaque because it gives intermediaries less opportunity for ossification. > > As far as collision resistance, I'm not too worried about collisions among > 64-bit random values, especially as the scope for collision is fairly > small, arguably just one epoch. > > > >> With respect to encrypting the content type, it also seems to me that >> this would cause issues because different content types have different >> delivery guarantees. Specifically: messages are allowed to be unordered and >> lossy, proposals are allowed to be unordered but not lossy, and commits are >> both ordered and not lossy. In the deployment scenarios we've talked about, >> the DS essentially always needs to know the content type to provide this. >> Conversely, you don't get much additional privacy from encrypting the >> content type because an eavesdropper can see the epoch id change and infer >> which message was a commit, or see a dropped message getting re-sent and >> infer it was a proposal. >> > > I don't disagree that there are different guarantees you need, but like I > said, I think the idea here is to be conservative by default. There are > systems in which you can hide the metadata you're talking about with things > like mixnets and dropboxes. Keeping the ciphertext as opaque as possible > keeps the door open to running MLS over those systems without MLS's own > metadata undermining their privacy properties. > > FWIW, in the systems I'm looking at building, this PR does not make any > difference, because clients use separate channels for Proposals/Commits vs. > application data and the server doesn't check. > > --Richard > > > >> >> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >> >>> Hi all, >>> >>> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) >>> encrypt the content type of the message (application / proposal / commit) >>> [1]. >>> >>> There was some discussion on the call last week that encrypting the >>> content type might not be that useful, since an application that relies on >>> a server to assure ordering of commits will need to at least be able to >>> tell commits from other things. Of course, even if the content type is >>> encrypted by default, the application can add it back in authenticated >>> data, or in some unauthenticated wrapper. >>> >>> Net of those considerations, I'm personally still inclined to merge the >>> PR, to have a conservative baseline. But those on the call thought it >>> would be useful to pose this to the group, so please speak up if you have >>> concerns. >>> >>> --Richard >>> >>> [1] https://github.com/mlswg/mls-protocol/pull/349 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> --000000000000185a8b05aa554f23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As = far as collision resistance, I'm not too worried about=20 collisions among 64-bit random values, especially as the scope for=20 collision is fairly small, arguably just one epoch.
=
The issue isn't with accidental collisions, it's wit= h malicious ones. An attacker can purposefully (and quickly) generate commi= ts that create duplicate epoch ids, and send them to a client to corrupt th= eir group state.

I think the idea here is to be conservative by default.=C2= =A0 There are=20 systems in which you can hide the metadata you're talking about with=20 things like mixnets and dropboxes.

It= 's not just being more conservative, you're making changes specific= ally for very niche use-cases where I don't think the security of the w= hole system has been thought through. Maybe you have an example in mind, bu= t I can't think of a system where this change provides any additional p= rivacy.

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <rlb@ip= v.sx> wrote:
=








On Mon, Jul 13, 2020 at 8= :56 AM Richard Barnes <rlb@ipv.sx> wrote:
Hi all,
Recall that PR#349 does two things (1) use an opaque epoch ID,= and (2) encrypt the content type of the message (application / proposal / = commit) [1].

There was some discussion on the call= last week that encrypting the content type might not be that useful, since= an application that relies on a server to assure ordering of commits will = need to at least be able to tell commits from other things.=C2=A0 Of course= , even if the content type is encrypted by default, the application can add= it back in authenticated data, or in some unauthenticated wrapper.

Net of those considerations, I'm personally still= inclined to merge the PR, to have a conservative baseline.=C2=A0 But those= on the call thought it would be useful to pose this to the group, so pleas= e speak up if you have concerns.

 _______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000185a8b05aa554f23-- From nobody Mon Jul 13 17:11: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 8CD8E3A095F for ; Mon, 13 Jul 2020 17:11:03 -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 cZQoyXfjtKh7 for ; Mon, 13 Jul 2020 17:11:01 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 C9AB13A095A for ; Mon, 13 Jul 2020 17:11:01 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id k18so14084776qke.4 for ; Mon, 13 Jul 2020 17:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=aAyFROhebacU62qoZS14qXfFjDtJX5eVxzEcUduHeuI=; b=MtPiYt8svJaLUbP2jLnfZoFmXG0PZOXamYVcmFLIwjnTVwiC2S0VdnZGIjVVgqNz2T WWx5KNdftlA2GACskzLe1F4OLdDyfdNLsMQpmutp176xncGbd4yBlHxtz+tNEdHRgO7T GG6WDkNkGbtctUGroHUXNIpLtV5p1N1s3RxY8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=aAyFROhebacU62qoZS14qXfFjDtJX5eVxzEcUduHeuI=; b=dywmSs48twe0rVzXSUQRmEmRuIjLq506CIQ5ldEvO5u32brsqeQuuEoVYfZBe8nPbu KtbreZxfq8d211RmmrzQkdEkXxsHh1z63fkgbDHHtUAmYBDlFTW18a7QhmtHe9RyzW3f M0iM7x1CZV6P/dr8oa3pothfjJCChueYfJu8uWwoDHtcKaDHoI9c90fxvRWCIKNZtPmt eqBiWdE4f/cB4b/dHsEb1tYMbbRezJNciudnuLh+EdgebMDlGv0ZTIu7vrheXRYF8zwN W25nNVvMjgMl4hhiOMitwaP272vhOzWSPurj4yO7ccqkaK4BG7gWf0flLYpTxHxI3QrZ evgg== X-Gm-Message-State: AOAM531Oups96DyLp3CSiV+fYwVO2gwDzhZZbs0ZipgKmtAQGfnBSHFd 6AK2eRznT5KvwOodKoZ83R1dwA5TKl8= X-Google-Smtp-Source: ABdhPJxO78749i6+06yye40hq9Ie3XsyITY0hdN8X3PEIeZIar4hxCzdWkkvm89HkdbJcBfvyAPUPA== X-Received: by 2002:ae9:e519:: with SMTP id w25mr2128222qkf.327.1594685460397; Mon, 13 Jul 2020 17:11:00 -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 w11sm20966547qtk.35.2020.07.13.17.10.59 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 17:10:59 -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.80.23.2.2\)) Date: Mon, 13 Jul 2020 20:10:58 -0400 References: To: MLS List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] 7/14 Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 00:11:04 -0000 Reminder that there is an interim tomorrow. > On Jul 12, 2020, at 21:21, Sean Turner wrote: >=20 > Just a reminder that there is a virtual interim planned for Tuesday = July 14 at 16:00 UTC. > Attendance link is here: > = https://ietf.webex.com/ietf/j.php?MTID=3Dm7f300037f89a213366d395bd400579a8= >=20 > spt From nobody Mon Jul 13 23:36:14 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 39EDD3A114C for ; Mon, 13 Jul 2020 23:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cis-india.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5PjVipiDsRI for ; Mon, 13 Jul 2020 23:36:11 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 D3E883A114A for ; Mon, 13 Jul 2020 23:36:10 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jvEXt-0005H3-CJ for mls@ietf.org; Tue, 14 Jul 2020 08:36:08 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org E0DAD581C006C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1594708564; bh=YkKM/XkDgH6+8MA9XZ+sc2qguGmJ1xeaYOB0YKKig50=; h=From:Mime-Version:Message-Id:Date:To; b=YkURxGU1+PNXontCeGqZvNXIKL+yBN+v0TgE4bjzBdMgdDYpG+40P9ov2iZg/8l0d 07+Pio4EAALtTA/TdA6XCd2XUVY2BYYzWmpbSbK3iC0fRMRQlgewWIweJy5raxUdee y4Eu9HtGZMCOtqLb6N21yqHwE9GKTtxhvwVWBDLYZUByUsNkzR7rvwLeal4yI7wy9Y /L4nZMFscl8db3dGmcQVXZefMEzjGj2Ej1YRqTgtVl4/rRu9teImF3p1XOeE/VZJ1d M1mi9C0WYV7568efBKqdweqiUcaFynHWvTqsPLw8n8lCqv3jpw/PV4JDipAzAu6M63 m8zwzVIfvkMSg== From: Divyank Katira Content-Type: multipart/alternative; boundary="Apple-Mail=_AD89881B-4E6F-4162-928D-3F9306AE7231" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Message-Id: Date: Tue, 14 Jul 2020 12:05:54 +0530 To: mls@ietf.org X-Mailer: Apple Mail (2.3601.0.10) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 9484ae446d4f83cee8bf28db5146d16c Archived-At: Subject: [MLS] External Proposals Guardrails 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, 14 Jul 2020 06:36:13 -0000 --Apple-Mail=_AD89881B-4E6F-4162-928D-3F9306AE7231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, A poorly designed implementation of external proposals could break the = end-to-end encryption provided by MLS. A compromised server could = arbitrarily add and remove group participants. While such tampering = would be visible in the chat transcript, the utility of manual = verification is diminished in large groups like the ones MLS enables. I suggest two changes to nudge application developers towards a more = secure design: - On the server side, given that the user/identity recovery cases that = external proposals aim to address fall under the authentication = service's purview, the initiation of such proposals can be constrained = to the authentication service and not any preconfigured entity. This = reduces trust on the delivery service provider in cases where a custom = identity provider/SSO is used. This also fits better in the security = considerations in the architecture document where authentication service = compromise and delivery service compromise are treated differently, with = the former leading to break of confidentiality, and the latter leading = to denial of service. - On the client side, the protocol should signal to application = developers that external proposals should be handled differently from = other proposals. For example, an update proposal is a routine operation = that can be committed automatically whereas an external proposal should = require consent/manual consideration before commit. I am happy to make concrete suggestions to the text if this sounds like = a good idea. Thanks, Divyank= --Apple-Mail=_AD89881B-4E6F-4162-928D-3F9306AE7231 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello,

A poorly designed implementation of external = proposals could break the end-to-end encryption provided by MLS. A compromised server = could arbitrarily add and remove group participants. While such = tampering would be visible in the chat transcript, the utility of manual = verification is diminished in large groups like the ones MLS = enables.

I suggest two changes to nudge application developers = towards a more secure design:

 - On the server side, = given that the user/identity recovery cases that external proposals aim = to address fall under the authentication service's purview, the = initiation of such proposals can be constrained to the authentication = service and not any preconfigured entity. This reduces trust on the = delivery service provider in cases where a custom identity provider/SSO = is used. This also fits better in the security considerations in the = architecture document where authentication service compromise and = delivery service compromise are treated differently, with the former = leading to break of confidentiality, and the latter leading to denial of = service.

 - On the client side, the protocol should = signal to application developers that external proposals should be = handled differently from other proposals. For example, an update = proposal is a routine operation that can be committed automatically = whereas an external proposal should require consent/manual consideration = before commit.

I am happy to make concrete = suggestions to the text if this sounds like a good idea.
Thanks,
Divyank
= --Apple-Mail=_AD89881B-4E6F-4162-928D-3F9306AE7231-- From nobody Tue Jul 14 07:39:00 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 0EE4E3A08A3 for ; Tue, 14 Jul 2020 07:38:59 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9yeZv3TAn48 for ; Tue, 14 Jul 2020 07:38:57 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 11E323A0896 for ; Tue, 14 Jul 2020 07:38:56 -0700 (PDT) X-ASG-Debug-ID: 1594737536-0e39451ec704070001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id vbwSxql3vPySq3iN; Tue, 14 Jul 2020 07:38:56 -0700 (PDT) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from synergos.ern.nps.edu (172.20.4.116) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Tue, 14 Jul 2020 07:38:55 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) by synergos.ern.nps.edu (172.20.4.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Tue, 14 Jul 2020 07:38:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kcT4rftgw4aG63FnHvmwcfnQuabzbze71Cwm/j6mMUTl6D7656uu70LBtGNP71+p/1xl11zZOYybUywBHihhWADsea/ZMl4dUAV+TeOrzSwWtOMtweVMILAx5Z5Tb9Q0n3lGfVvU1gZiMhdgUTqTVYBpZ6u44nHi7zM9FsbwRNedVkg7RmXeCfeApY11bc/KrHYgPmFCdegcGNM5zuqKJnw+bDWdHq8pbU2lR/wtxe5es1gvRCcjO4YYRtpo9Z4iZmZuIxHrUX8lKdbGMjWdKiX3k3mCY1hclpxH7vK3/TBhn9a6FnLvaMfPbHdQf1ny6O4esFQyeZRgIbdm0KSRsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qpj0OJAZcFVZTub43HBlcV5KKSD+sJfe3VWs5Q6qqAA=; b=NdiWf5sHYzcf52P7NoRAkwPjbK13sDdpKh+2IV02vzKtEsWHb98/tTftGVCnS+Oewjk9oMX1aXFEhhkv8It3hLbJMI7zttYi7OfSi7/ocKOmd8D+ZqGpX+atAlIV8839ryvCM+AzmGudn45KTl4T4MXPvFNLynf72ejbuv0ZnX0Fd6zUCp8uSRPOxx0oIfMGuFEVBQm+423cP9A02wy6BQgkPRo4cAtGJGrzbQLlWusKcxeLNZOgwpJanm3UrsTYin0kBM6pzvcnz/iBB0rEgsFpAQaR6VbH2/33x3yx5EdO54qhkQ8tizlKu2if/07+YDSKlaYBFq/OTODtk3WPjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from DM5PR13MB1066.namprd13.prod.outlook.com (2603:10b6:3:78::16) by DM6PR13MB3692.namprd13.prod.outlook.com (2603:10b6:5:229::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.10; Tue, 14 Jul 2020 14:38:53 +0000 Received: from DM5PR13MB1066.namprd13.prod.outlook.com ([fe80::c5c2:1037:89ad:ad00]) by DM5PR13MB1066.namprd13.prod.outlook.com ([fe80::c5c2:1037:89ad:ad00%4]) with mapi id 15.20.3195.017; Tue, 14 Jul 2020 14:38:52 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:5:229::7] X-Barracuda-Apparent-Source-IP: 2603:10b6:5:229::7 From: "Hale, Britta (CIV)" To: Brendan McMillion , "Richard Barnes" CC: Messaging Layer Security WG Thread-Topic: [MLS] Hiding content type X-ASG-Orig-Subj: Re: [MLS] Hiding content type Thread-Index: AQHWWR1miPCJW/kzdkaeKDSwZdPxN6kFmZ8AgAAQhICAAAtsAIAA+9iA Date: Tue, 14 Jul 2020 14:38:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.17.200615 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nps.edu; x-originating-ip: [2601:647:cb00:2941:5de6:2854:de7d:b513] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4feed8c0-6a70-4f6e-6ea1-08d82803a151 x-ms-traffictypediagnostic: DM6PR13MB3692: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ipPy8LISYadsGz7+Ts4MMMN9qDYVeOSRl+YBu/0ZajJ/Gbw92MgbvJ5uVGpsBAxHHP/HN77e9D33q9jyYImYwdkBIuxni0Dih726hqK1gcLACeyzE01IJZs1BUWnoVgVLRTN3PDOsBMLetKxqjqeJ/XO/kfVOpoHYTPkrZx5NzIel6nLZjSLs+e6ni575d5t7v8ivNODsTXthFadux8MbSOMduxRriocmof/SrosgrnWBb24iG5V/Mc/GrAYMWosonTk7gvcLf8iXzkfuxW8CmbR6JtE2oNxto3m2WY5/wAZF/hHE5dN9UTcqJbg2hkDBwRIlnGffTTjdNEdby9TUD1RLlTMaLv7xbMHAGs5xxNyw1z7WqGTK8l1q0P4AwoXiScxwcHibajThdmjj3isYg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR13MB1066.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(110136005)(8936002)(75432002)(2906002)(33656002)(86362001)(36756003)(4326008)(966005)(6512007)(2616005)(5660300002)(83380400001)(498600001)(6486002)(186003)(166002)(71200400001)(8676002)(91956017)(76116006)(64756008)(6506007)(66446008)(53546011)(66476007)(66556008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 7lDc7WeZZUlqBaKdiUNEQL99mdJWCXyVAnpIdOFKFmD6Gu0TsaMxbukqXVJngfJrdGlPvPfBxtwhCYLn9nNLWAuPvn1KTJDXNc6jqa5mIpQA4hvdvc93EFMYzFAGKQLC1p6iUXexKScxM3WjW/ZRIkLZekcBkGjHfgAGC+2kxJHVIm4B/GEHXOsSM7ilCLN7MPMsJSyD8I3SBqFQtsVskQFcfcfTI6DxTFykKWZKEKPS6CnTomqjN7CsZvvM73PthoR/1rmZibqSvQ3UC4y5Cbwg6H92EjTEaMVD/PmDsrkrNVlNgeXHGCzV1lhVyxADI6F5xAjFa+pqHV3kNaQsgSOO6Q9aDtLsQCf7tgwYWhT5YCSR7Lg6ve7rRyUrpEyAikrPG+NyXGZ0TsKj99zMyGPDsBsu7TuW+6z6nKdaUxv5aA+/kB+Ec4nZ5HIOm2tfhqGFylg82F0dOo8zw4xTLPg1lbnrM8+trmMTFaOkYXFMRZgLfhYcFuP65rHVgtECN69ZFlMEnq8PDpV1IxsqCBNKQQvmZmymRr90vKtG4MHvODpwopdvZvbubfqpNnjI x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FCAAD638E0F84A9190F11A2F1233D88Fnpsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR13MB1066.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4feed8c0-6a70-4f6e-6ea1-08d82803a151 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 14:38:52.7937 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tO5nfXpEBFTCS9Ss+5jfyUMdk+uHeOTGN5IsUHVppGHNrnZTcjPetX2l8Sz/s3iaHb+i9FKL08FGNjsFuZ/b5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3692 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1594737536 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 17536 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83193 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] Hiding content type 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, 14 Jul 2020 14:38:59 -0000 --_000_FCAAD638E0F84A9190F11A2F1233D88Fnpsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RW5zdXJpbmcgdGhlIG1vc3QgY29uc2VydmF0aXZlIGRlc2lnbiBieSBkZWZhdWx0IHNlZW1zIGFk dmlzYWJsZTsgaG93ZXZlciBpdCBpcyBub3QgY2xlYXIgdGhhdCB0aGlzIHByb3Bvc2FsIGZvciBo aWRpbmcgY29udGVudCB0eXBlIGlzIGFjdHVhbGx5IGRvaW5nIHRoYXQuIEluZGVlZCwgaWYgYW4g YXBwbGljYXRpb24gaXMgY29uY2VybmVkIGFib3V0IGhpZGluZyB0aGUgY29udGVudCB0eXBlLCB3 b3VsZCBub3QgdGhhdCBzYW1lIHR5cGUgb2YgYXBwbGljYXRpb24gYWxzbyBiZSBjb25jZXJuZWQg YWJvdXQgY29sbGlzaW9ucz8NCg0KQXMgQnJlbmRhbiBub3Rlcywgd2UgYXJlIG5vdCB0YWxraW5n IGFib3V0IGFjY2lkZW50YWwgY29sbGlzaW9ucyBoZXJlLiBQcmUtY29tcHV0YXRpb24gaXMgZW50 aXJlbHkgcG9zc2libGUsIHN1Y2ggYXMgYnkgYSBtYWxpY2lvdXMgZ3JvdXAgbWVtYmVyLCBzbyB0 aGUgd2luZG93IG9mIGF0dGFjayBpcyBub3QgbGltaXRlZCB0byBvbmUgZXBvY2guDQoNCklmIHRo aXMgaXMgdGhpcyBQUiBwYXJ0aWN1bGFyIGlzIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3QgdG8gc29t ZSwgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvIHNlZSBhIGNsYXJpZnlpbmcgZXhwbGFuYXRpb24g YXMgdG8gdGhlIHNlY3VyaXR5IGl0IGFjaGlldmVzIChpLmUuIHdoeSB0aGlzIGlzIOKAnHNlY3Vy aXR5IGJ5IGRlc2lnbuKAnSBkZXNwaXRlIGludHJvZHVjaW5nIHN1Y2ggY29sbGlzaW9uIHBvc3Np YmlsaXRpZXMpLCBvciBhIGNvbmNyZXRlIHVzZS1jYXNlLiBBbHRlcm5hdGl2ZWx5LCBhcmUgd2Ug cmVhbGx5IGxpbWl0ZWQgdG8gYSA2NC1iaXQgZmllbGQsIG9yIGNhbiB0aGF0IGxlbmd0aCBiZSBh ZGp1c3RlZCB0byBtaXRpZ2F0ZSB0aGUgaW50cm9kdWNlZCBwcm9ibGVtcz8NCg0KDQoNCkEgY2xh cmlmeWluZyBwb2ludCBmb3IgdGhvc2UgZm9sbG93aW5nIHRoaXMgdGhyZWFkOiBzb21lIHJlZmVy ZW5jZXMgaW4gdGhlIGVtYWlsIGNoYWluIHN0YXRlIHRoYXQgdGhpcyBpcyBlbmNyeXB0aW9uIG9m IHRoZSBlcG9jaCBJRC4gVGhhdCBpcyBub3QgdGhlIGNhc2UuIFRoZSBwcm9wb3NhbCBiZWluZyBk aXNjdXNzZWQgaXMgYWJvdXQgYSBoYXNoIHRoZXJlb2YgKGhlbmNlIGRpc2N1c3Npb24gb24gY29s bGlzaW9ucykuDQoNCkJyaXR0YQ0KDQoNCkZyb206IE1MUyA8bWxzLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBCcmVuZGFuIE1jTWlsbGlvbiA8YnJlbmRhbj00MGNsb3VkZmxhcmUuY29t QGRtYXJjLmlldGYub3JnPg0KRGF0ZTogTW9uZGF5LCBKdWx5IDEzLCAyMDIwIGF0IDk6MzcgQU0N ClRvOiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4NCkNjOiBNZXNzYWdpbmcgTGF5ZXIgU2Vj dXJpdHkgV0cgPG1sc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTUxTXSBIaWRpbmcgY29udGVu dCB0eXBlDQoNCkFzIGZhciBhcyBjb2xsaXNpb24gcmVzaXN0YW5jZSwgSSdtIG5vdCB0b28gd29y cmllZCBhYm91dCBjb2xsaXNpb25zIGFtb25nIDY0LWJpdCByYW5kb20gdmFsdWVzLCBlc3BlY2lh bGx5IGFzIHRoZSBzY29wZSBmb3IgY29sbGlzaW9uIGlzIGZhaXJseSBzbWFsbCwgYXJndWFibHkg anVzdCBvbmUgZXBvY2guDQoNClRoZSBpc3N1ZSBpc24ndCB3aXRoIGFjY2lkZW50YWwgY29sbGlz aW9ucywgaXQncyB3aXRoIG1hbGljaW91cyBvbmVzLiBBbiBhdHRhY2tlciBjYW4gcHVycG9zZWZ1 bGx5IChhbmQgcXVpY2tseSkgZ2VuZXJhdGUgY29tbWl0cyB0aGF0IGNyZWF0ZSBkdXBsaWNhdGUg ZXBvY2ggaWRzLCBhbmQgc2VuZCB0aGVtIHRvIGEgY2xpZW50IHRvIGNvcnJ1cHQgdGhlaXIgZ3Jv dXAgc3RhdGUuDQoNCkkgdGhpbmsgdGhlIGlkZWEgaGVyZSBpcyB0byBiZSBjb25zZXJ2YXRpdmUg YnkgZGVmYXVsdC4gIFRoZXJlIGFyZSBzeXN0ZW1zIGluIHdoaWNoIHlvdSBjYW4gaGlkZSB0aGUg bWV0YWRhdGEgeW91J3JlIHRhbGtpbmcgYWJvdXQgd2l0aCB0aGluZ3MgbGlrZSBtaXhuZXRzIGFu ZCBkcm9wYm94ZXMuDQoNCkl0J3Mgbm90IGp1c3QgYmVpbmcgbW9yZSBjb25zZXJ2YXRpdmUsIHlv dSdyZSBtYWtpbmcgY2hhbmdlcyBzcGVjaWZpY2FsbHkgZm9yIHZlcnkgbmljaGUgdXNlLWNhc2Vz IHdoZXJlIEkgZG9uJ3QgdGhpbmsgdGhlIHNlY3VyaXR5IG9mIHRoZSB3aG9sZSBzeXN0ZW0gaGFz IGJlZW4gdGhvdWdodCB0aHJvdWdoLiBNYXliZSB5b3UgaGF2ZSBhbiBleGFtcGxlIGluIG1pbmQs IGJ1dCBJIGNhbid0IHRoaW5rIG9mIGEgc3lzdGVtIHdoZXJlIHRoaXMgY2hhbmdlIHByb3ZpZGVz IGFueSBhZGRpdGlvbmFsIHByaXZhY3kuDQoNCk9uIE1vbiwgSnVsIDEzLCAyMDIwIGF0IDEwOjU2 IEFNIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PiB3cm90ZToNCk9uIE1vbiwgSnVsIDEzLCAy MDIwIGF0IDEwOjU3IEFNIEJyZW5kYW4gTWNNaWxsaW9uIDxicmVuZGFuQGNsb3VkZmxhcmUuY29t PG1haWx0bzpicmVuZGFuQGNsb3VkZmxhcmUuY29tPj4gd3JvdGU6DQpXaXRoIHJlc3BlY3QgdG8g dXNpbmcgYW4gb3BhcXVlIGVwb2NoIGlkLCBJIGJlbGlldmUgdGhpcyB3YXMgcHJvcG9zZWQgaW4g IzI0NTxodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMjQ1PiBhbmQg Y29uc2Vuc3VzIHdhcyBhZ2FpbnN0IGl0IGJlY2F1c2UgaXQgbWFrZXMgaXQgbW9yZSBkaWZmaWN1 bHQgdG8gaW1wbGVtZW50IHRoZSBEUy4gSXQncyBhbHNvIG5vdCBjbGVhciB0byBtZSB3aGF0IHNl Y3VyaXR5IHByb3BlcnRpZXMgeW91IHdhbnQgZnJvbSBhbiBvcGFxdWUgZXBvY2ggaWQsIGJlY2F1 c2UgdGhlIGN1cnJlbnQgUFIgZG9lc24ndCBwcm92aWRlIGNvbGxpc2lvbiByZXNpc3RhbmNlIGFu ZCBJJ2QgZXhwZWN0IHRoaXMgdG8gYmUgYSBzb3VyY2Ugb2YgY29uZnVzaW9uIGFuZCBidWdzLg0K DQpJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIG9uICMyNDUgZ290IGRlcmFpbGVkIGEgYml0IGJ5IHRo ZSBmb2N1cyBvbiBub24tbGluZWFyIGVwb2Nocy4gIFRoZSBwb2ludCBoZXJlIGlzIHRoYXQgZXZl biBpbiBhIGNhc2Ugd2hlcmUgeW91IGhhdmUgbGluZWFyIGhpc3RvcnksIEkgdGhpbmsgdGhlcmUn cyBpbnRyaW5zaWMgdmFsdWUgaW4gdGhlIGVwb2NoIElEIGJlaW5nIG9wYXF1ZSBiZWNhdXNlIGl0 IGdpdmVzIGludGVybWVkaWFyaWVzIGxlc3Mgb3Bwb3J0dW5pdHkgZm9yIG9zc2lmaWNhdGlvbi4N Cg0KQXMgZmFyIGFzIGNvbGxpc2lvbiByZXNpc3RhbmNlLCBJJ20gbm90IHRvbyB3b3JyaWVkIGFi b3V0IGNvbGxpc2lvbnMgYW1vbmcgNjQtYml0IHJhbmRvbSB2YWx1ZXMsIGVzcGVjaWFsbHkgYXMg dGhlIHNjb3BlIGZvciBjb2xsaXNpb24gaXMgZmFpcmx5IHNtYWxsLCBhcmd1YWJseSBqdXN0IG9u ZSBlcG9jaC4NCg0KDQpXaXRoIHJlc3BlY3QgdG8gZW5jcnlwdGluZyB0aGUgY29udGVudCB0eXBl LCBpdCBhbHNvIHNlZW1zIHRvIG1lIHRoYXQgdGhpcyB3b3VsZCBjYXVzZSBpc3N1ZXMgYmVjYXVz ZSBkaWZmZXJlbnQgY29udGVudCB0eXBlcyBoYXZlIGRpZmZlcmVudCBkZWxpdmVyeSBndWFyYW50 ZWVzLiBTcGVjaWZpY2FsbHk6IG1lc3NhZ2VzIGFyZSBhbGxvd2VkIHRvIGJlIHVub3JkZXJlZCBh bmQgbG9zc3ksIHByb3Bvc2FscyBhcmUgYWxsb3dlZCB0byBiZSB1bm9yZGVyZWQgYnV0IG5vdCBs b3NzeSwgYW5kIGNvbW1pdHMgYXJlIGJvdGggb3JkZXJlZCBhbmQgbm90IGxvc3N5LiBJbiB0aGUg ZGVwbG95bWVudCBzY2VuYXJpb3Mgd2UndmUgdGFsa2VkIGFib3V0LCB0aGUgRFMgZXNzZW50aWFs bHkgYWx3YXlzIG5lZWRzIHRvIGtub3cgdGhlIGNvbnRlbnQgdHlwZSB0byBwcm92aWRlIHRoaXMu IENvbnZlcnNlbHksIHlvdSBkb24ndCBnZXQgbXVjaCBhZGRpdGlvbmFsIHByaXZhY3kgZnJvbSBl bmNyeXB0aW5nIHRoZSBjb250ZW50IHR5cGUgYmVjYXVzZSBhbiBlYXZlc2Ryb3BwZXIgY2FuIHNl ZSB0aGUgZXBvY2ggaWQgY2hhbmdlIGFuZCBpbmZlciB3aGljaCBtZXNzYWdlIHdhcyBhIGNvbW1p dCwgb3Igc2VlIGEgZHJvcHBlZCBtZXNzYWdlIGdldHRpbmcgcmUtc2VudCBhbmQgaW5mZXIgaXQg d2FzIGEgcHJvcG9zYWwuDQoNCkkgZG9uJ3QgZGlzYWdyZWUgdGhhdCB0aGVyZSBhcmUgZGlmZmVy ZW50IGd1YXJhbnRlZXMgeW91IG5lZWQsIGJ1dCBsaWtlIEkgc2FpZCwgSSB0aGluayB0aGUgaWRl YSBoZXJlIGlzIHRvIGJlIGNvbnNlcnZhdGl2ZSBieSBkZWZhdWx0LiAgVGhlcmUgYXJlIHN5c3Rl bXMgaW4gd2hpY2ggeW91IGNhbiBoaWRlIHRoZSBtZXRhZGF0YSB5b3UncmUgdGFsa2luZyBhYm91 dCB3aXRoIHRoaW5ncyBsaWtlIG1peG5ldHMgYW5kIGRyb3Bib3hlcy4gIEtlZXBpbmcgdGhlIGNp cGhlcnRleHQgYXMgb3BhcXVlIGFzIHBvc3NpYmxlIGtlZXBzIHRoZSBkb29yIG9wZW4gdG8gcnVu bmluZyBNTFMgb3ZlciB0aG9zZSBzeXN0ZW1zIHdpdGhvdXQgTUxTJ3Mgb3duIG1ldGFkYXRhIHVu ZGVybWluaW5nIHRoZWlyIHByaXZhY3kgcHJvcGVydGllcy4NCg0KRldJVywgaW4gdGhlIHN5c3Rl bXMgSSdtIGxvb2tpbmcgYXQgYnVpbGRpbmcsIHRoaXMgUFIgZG9lcyBub3QgbWFrZSBhbnkgZGlm ZmVyZW5jZSwgYmVjYXVzZSBjbGllbnRzIHVzZSBzZXBhcmF0ZSBjaGFubmVscyBmb3IgUHJvcG9z YWxzL0NvbW1pdHMgdnMuIGFwcGxpY2F0aW9uIGRhdGEgYW5kIHRoZSBzZXJ2ZXIgZG9lc24ndCBj aGVjay4NCg0KLS1SaWNoYXJkDQoNCg0KDQpPbiBNb24sIEp1bCAxMywgMjAyMCBhdCA4OjU2IEFN IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PiB3cm90ZToNCkhpIGFsbCwNCg0KUmVjYWxsIHRo YXQgUFIjMzQ5IGRvZXMgdHdvIHRoaW5ncyAoMSkgdXNlIGFuIG9wYXF1ZSBlcG9jaCBJRCwgYW5k ICgyKSBlbmNyeXB0IHRoZSBjb250ZW50IHR5cGUgb2YgdGhlIG1lc3NhZ2UgKGFwcGxpY2F0aW9u IC8gcHJvcG9zYWwgLyBjb21taXQpIFsxXS4NCg0KVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBv biB0aGUgY2FsbCBsYXN0IHdlZWsgdGhhdCBlbmNyeXB0aW5nIHRoZSBjb250ZW50IHR5cGUgbWln aHQgbm90IGJlIHRoYXQgdXNlZnVsLCBzaW5jZSBhbiBhcHBsaWNhdGlvbiB0aGF0IHJlbGllcyBv biBhIHNlcnZlciB0byBhc3N1cmUgb3JkZXJpbmcgb2YgY29tbWl0cyB3aWxsIG5lZWQgdG8gYXQg bGVhc3QgYmUgYWJsZSB0byB0ZWxsIGNvbW1pdHMgZnJvbSBvdGhlciB0aGluZ3MuICBPZiBjb3Vy c2UsIGV2ZW4gaWYgdGhlIGNvbnRlbnQgdHlwZSBpcyBlbmNyeXB0ZWQgYnkgZGVmYXVsdCwgdGhl IGFwcGxpY2F0aW9uIGNhbiBhZGQgaXQgYmFjayBpbiBhdXRoZW50aWNhdGVkIGRhdGEsIG9yIGlu IHNvbWUgdW5hdXRoZW50aWNhdGVkIHdyYXBwZXIuDQoNCk5ldCBvZiB0aG9zZSBjb25zaWRlcmF0 aW9ucywgSSdtIHBlcnNvbmFsbHkgc3RpbGwgaW5jbGluZWQgdG8gbWVyZ2UgdGhlIFBSLCB0byBo YXZlIGEgY29uc2VydmF0aXZlIGJhc2VsaW5lLiAgQnV0IHRob3NlIG9uIHRoZSBjYWxsIHRob3Vn aHQgaXQgd291bGQgYmUgdXNlZnVsIHRvIHBvc2UgdGhpcyB0byB0aGUgZ3JvdXAsIHNvIHBsZWFz ZSBzcGVhayB1cCBpZiB5b3UgaGF2ZSBjb25jZXJucy4NCg0KLS1SaWNoYXJkDQoNClsxXSBodHRw czovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwvMzQ5DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxT QGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21scw0K --_000_FCAAD638E0F84A9190F11A2F1233D88Fnpsedu_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkVuc3VyaW5nIHRoZSBtb3N0IGNvbnNlcnZhdGl2ZSBkZXNpZ24gYnkgZGVmYXVs dCBzZWVtcyBhZHZpc2FibGU7IGhvd2V2ZXIgaXQgaXMgbm90IGNsZWFyIHRoYXQgdGhpcyBwcm9w b3NhbCBmb3IgaGlkaW5nIGNvbnRlbnQgdHlwZSBpcyBhY3R1YWxseSBkb2luZyB0aGF0LiBJbmRl ZWQsIGlmIGFuIGFwcGxpY2F0aW9uIGlzIGNvbmNlcm5lZCBhYm91dCBoaWRpbmcgdGhlIGNvbnRl bnQgdHlwZSwgd291bGQgbm90DQogdGhhdCBzYW1lIHR5cGUgb2YgYXBwbGljYXRpb24gYWxzbyBi ZSBjb25jZXJuZWQgYWJvdXQgY29sbGlzaW9ucz8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IEJyZW5kYW4gbm90ZXMsIHdlIGFyZSBub3QgdGFsa2luZyBhYm91dCBhY2NpZGVudGFsIGNvbGxp c2lvbnMgaGVyZS4gUHJlLWNvbXB1dGF0aW9uIGlzIGVudGlyZWx5IHBvc3NpYmxlLCBzdWNoIGFz IGJ5IGEgbWFsaWNpb3VzIGdyb3VwIG1lbWJlciwgc28gdGhlIHdpbmRvdyBvZiBhdHRhY2sgaXMg bm90IGxpbWl0ZWQgdG8gb25lIGVwb2NoLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRo aXMgaXMgdGhpcyBQUiBwYXJ0aWN1bGFyIGlzIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3QgdG8gc29t ZSwgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvIHNlZSBhIGNsYXJpZnlpbmcgZXhwbGFuYXRpb24g YXMgdG8gdGhlIHNlY3VyaXR5IGl0IGFjaGlldmVzIChpLmUuIHdoeSB0aGlzIGlzIOKAnHNlY3Vy aXR5IGJ5IGRlc2lnbuKAnSBkZXNwaXRlIGludHJvZHVjaW5nIHN1Y2ggY29sbGlzaW9uIHBvc3Np YmlsaXRpZXMpLA0KIG9yIGEgY29uY3JldGUgdXNlLWNhc2UuIEFsdGVybmF0aXZlbHksIGFyZSB3 ZSByZWFsbHkgbGltaXRlZCB0byBhIDY0LWJpdCBmaWVsZCwgb3IgY2FuIHRoYXQgbGVuZ3RoIGJl IGFkanVzdGVkIHRvIG1pdGlnYXRlIHRoZSBpbnRyb2R1Y2VkIHByb2JsZW1zPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjbGFyaWZ5aW5n IHBvaW50IGZvciB0aG9zZSBmb2xsb3dpbmcgdGhpcyB0aHJlYWQ6IHNvbWUgcmVmZXJlbmNlcyBp biB0aGUgZW1haWwgY2hhaW4gc3RhdGUgdGhhdCB0aGlzIGlzIGVuY3J5cHRpb24gb2YgdGhlIGVw b2NoIElELiBUaGF0IGlzIG5vdCB0aGUgY2FzZS4gVGhlIHByb3Bvc2FsIGJlaW5nIGRpc2N1c3Nl ZCBpcyBhYm91dCBhIGhhc2ggdGhlcmVvZiAoaGVuY2UgZGlzY3Vzc2lvbiBvbiBjb2xsaXNpb25z KS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccml0dGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+TUxTICZsdDttbHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEJy ZW5kYW4gTWNNaWxsaW9uICZsdDticmVuZGFuPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgSnVseSAxMywgMjAyMCBhdCA5OjM3IEFN PGJyPg0KPGI+VG86IDwvYj5SaWNoYXJkIEJhcm5lcyAmbHQ7cmxiQGlwdi5zeCZndDs8YnI+DQo8 Yj5DYzogPC9iPk1lc3NhZ2luZyBMYXllciBTZWN1cml0eSBXRyAmbHQ7bWxzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW01MU10gSGlkaW5nIGNvbnRlbnQgdHlwZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgZmFyIGFzIGNvbGxpc2lvbiByZXNpc3RhbmNl LCBJJ20gbm90IHRvbyB3b3JyaWVkIGFib3V0IGNvbGxpc2lvbnMgYW1vbmcgNjQtYml0IHJhbmRv bSB2YWx1ZXMsIGVzcGVjaWFsbHkgYXMgdGhlIHNjb3BlIGZvciBjb2xsaXNpb24gaXMgZmFpcmx5 IHNtYWxsLCBhcmd1YWJseSBqdXN0IG9uZSBlcG9jaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlzc3VlIGlz bid0IHdpdGggYWNjaWRlbnRhbCBjb2xsaXNpb25zLCBpdCdzIHdpdGggbWFsaWNpb3VzIG9uZXMu IEFuIGF0dGFja2VyIGNhbiBwdXJwb3NlZnVsbHkgKGFuZCBxdWlja2x5KSBnZW5lcmF0ZSBjb21t aXRzIHRoYXQgY3JlYXRlIGR1cGxpY2F0ZSBlcG9jaCBpZHMsIGFuZCBzZW5kIHRoZW0gdG8gYSBj bGllbnQgdG8gY29ycnVwdCB0aGVpciBncm91cCBzdGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhl IGlkZWEgaGVyZSBpcyB0byBiZSBjb25zZXJ2YXRpdmUgYnkgZGVmYXVsdC4mbmJzcDsgVGhlcmUg YXJlIHN5c3RlbXMgaW4gd2hpY2ggeW91IGNhbiBoaWRlIHRoZSBtZXRhZGF0YSB5b3UncmUgdGFs a2luZyBhYm91dCB3aXRoIHRoaW5ncyBsaWtlIG1peG5ldHMgYW5kIGRyb3Bib3hlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQncyBub3QganVzdCBiZWluZyBtb3JlIGNvbnNlcnZhdGl2ZSwgeW91J3JlIG1ha2lu ZyBjaGFuZ2VzIHNwZWNpZmljYWxseSBmb3IgdmVyeSBuaWNoZSB1c2UtY2FzZXMgd2hlcmUgSSBk b24ndCB0aGluayB0aGUgc2VjdXJpdHkgb2YgdGhlIHdob2xlIHN5c3RlbSBoYXMgYmVlbiB0aG91 Z2h0IHRocm91Z2guIE1heWJlIHlvdSBoYXZlIGFuIGV4YW1wbGUgaW4gbWluZCwgYnV0IEkgY2Fu J3QgdGhpbmsgb2YgYQ0KIHN5c3RlbSB3aGVyZSB0aGlzIGNoYW5nZSBwcm92aWRlcyBhbnkgYWRk aXRpb25hbCBwcml2YWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAxMywgMjAyMCBhdCAxMDo1NiBBTSBSaWNoYXJkIEJh cm5lcyAmbHQ7cmxiQGlwdi5zeCZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVs IDEzLCAyMDIwIGF0IDEwOjU3IEFNIEJyZW5kYW4gTWNNaWxsaW9uICZsdDs8YSBocmVmPSJtYWls dG86YnJlbmRhbkBjbG91ZGZsYXJlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyZW5kYW5AY2xvdWRm bGFyZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggcmVzcGVj dCB0byB1c2luZyBhbiBvcGFxdWUgZXBvY2ggaWQsIEkgYmVsaWV2ZSB0aGlzIHdhcyBwcm9wb3Nl ZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1wcm90b2NvbC9wdWxs LzI0NSIgdGFyZ2V0PSJfYmxhbmsiPiMyNDU8L2E+IGFuZCBjb25zZW5zdXMgd2FzIGFnYWluc3Qg aXQgYmVjYXVzZSBpdCBtYWtlcyBpdCBtb3JlIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgdGhlIERT LiBJdCdzIGFsc28gbm90IGNsZWFyIHRvIG1lIHdoYXQgc2VjdXJpdHkgcHJvcGVydGllcyB5b3Ug d2FudCBmcm9tIGFuIG9wYXF1ZSBlcG9jaCBpZCwgYmVjYXVzZQ0KIHRoZSBjdXJyZW50IFBSIGRv ZXNuJ3QgcHJvdmlkZSBjb2xsaXNpb24gcmVzaXN0YW5jZSBhbmQgSSdkIGV4cGVjdCB0aGlzIHRv IGJlIGEgc291cmNlIG9mIGNvbmZ1c2lvbiBhbmQgYnVncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRoaW5rIHRoZSBkaXNjdXNzaW9uIG9uICMyNDUgZ290IGRlcmFpbGVkIGEgYml0IGJ5IHRoZSBm b2N1cyBvbiBub24tbGluZWFyIGVwb2Nocy4mbmJzcDsgVGhlIHBvaW50IGhlcmUgaXMgdGhhdCBl dmVuIGluIGEgY2FzZSB3aGVyZSB5b3UgaGF2ZSBsaW5lYXIgaGlzdG9yeSwgSSB0aGluayB0aGVy ZSdzIGludHJpbnNpYyB2YWx1ZSBpbiB0aGUgZXBvY2ggSUQgYmVpbmcgb3BhcXVlIGJlY2F1c2Ug aXQgZ2l2ZXMgaW50ZXJtZWRpYXJpZXMNCiBsZXNzIG9wcG9ydHVuaXR5IGZvciBvc3NpZmljYXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIGZhciBhcyBjb2xsaXNpb24gcmVzaXN0YW5jZSwgSSdtIG5vdCB0b28gd29ycmllZCBhYm91 dCBjb2xsaXNpb25zIGFtb25nIDY0LWJpdCByYW5kb20gdmFsdWVzLCBlc3BlY2lhbGx5IGFzIHRo ZSBzY29wZSBmb3IgY29sbGlzaW9uIGlzIGZhaXJseSBzbWFsbCwgYXJndWFibHkganVzdCBvbmUg ZXBvY2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHJlc3BlY3QgdG8gZW5jcnlwdGluZyB0aGUg Y29udGVudCB0eXBlLCBpdCBhbHNvIHNlZW1zIHRvIG1lIHRoYXQgdGhpcyB3b3VsZCBjYXVzZSBp c3N1ZXMgYmVjYXVzZSBkaWZmZXJlbnQgY29udGVudCB0eXBlcyBoYXZlIGRpZmZlcmVudCBkZWxp dmVyeSBndWFyYW50ZWVzLiBTcGVjaWZpY2FsbHk6IG1lc3NhZ2VzIGFyZSBhbGxvd2VkIHRvIGJl IHVub3JkZXJlZCBhbmQgbG9zc3ksIHByb3Bvc2FscyBhcmUNCiBhbGxvd2VkIHRvIGJlIHVub3Jk ZXJlZCBidXQgbm90IGxvc3N5LCBhbmQgY29tbWl0cyBhcmUgYm90aCBvcmRlcmVkIGFuZCBub3Qg bG9zc3kuIEluIHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvcyB3ZSd2ZSB0YWxrZWQgYWJvdXQsIHRo ZSBEUyBlc3NlbnRpYWxseSBhbHdheXMgbmVlZHMgdG8ga25vdyB0aGUgY29udGVudCB0eXBlIHRv IHByb3ZpZGUgdGhpcy4gQ29udmVyc2VseSwgeW91IGRvbid0IGdldCBtdWNoIGFkZGl0aW9uYWwg cHJpdmFjeSBmcm9tDQogZW5jcnlwdGluZyB0aGUgY29udGVudCB0eXBlIGJlY2F1c2UgYW4gZWF2 ZXNkcm9wcGVyIGNhbiBzZWUgdGhlIGVwb2NoIGlkIGNoYW5nZSBhbmQgaW5mZXIgd2hpY2ggbWVz c2FnZSB3YXMgYSBjb21taXQsIG9yIHNlZSBhIGRyb3BwZWQgbWVzc2FnZSBnZXR0aW5nIHJlLXNl bnQgYW5kIGluZmVyIGl0IHdhcyBhIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u J3QgZGlzYWdyZWUgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW50IGd1YXJhbnRlZXMgeW91IG5lZWQs IGJ1dCBsaWtlIEkgc2FpZCwgSSB0aGluayB0aGUgaWRlYSBoZXJlIGlzIHRvIGJlIGNvbnNlcnZh dGl2ZSBieSBkZWZhdWx0LiZuYnNwOyBUaGVyZSBhcmUgc3lzdGVtcyBpbiB3aGljaCB5b3UgY2Fu IGhpZGUgdGhlIG1ldGFkYXRhIHlvdSdyZSB0YWxraW5nIGFib3V0IHdpdGggdGhpbmdzIGxpa2Ug bWl4bmV0cw0KIGFuZCBkcm9wYm94ZXMuJm5ic3A7IEtlZXBpbmcgdGhlIGNpcGhlcnRleHQgYXMg b3BhcXVlIGFzIHBvc3NpYmxlIGtlZXBzIHRoZSBkb29yIG9wZW4gdG8gcnVubmluZyBNTFMgb3Zl ciB0aG9zZSBzeXN0ZW1zIHdpdGhvdXQgTUxTJ3Mgb3duIG1ldGFkYXRhIHVuZGVybWluaW5nIHRo ZWlyIHByaXZhY3kgcHJvcGVydGllcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RldJVywgaW4gdGhlIHN5c3RlbXMgSSdtIGxvb2tpbmcgYXQg YnVpbGRpbmcsIHRoaXMgUFIgZG9lcyBub3QgbWFrZSBhbnkgZGlmZmVyZW5jZSwgYmVjYXVzZSBj bGllbnRzIHVzZSBzZXBhcmF0ZSBjaGFubmVscyBmb3IgUHJvcG9zYWxzL0NvbW1pdHMgdnMuIGFw cGxpY2F0aW9uIGRhdGEgYW5kIHRoZSBzZXJ2ZXIgZG9lc24ndCBjaGVjay48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1SaWNoYXJkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgSnVsIDEzLCAyMDIwIGF0IDg6NTYgQU0gUmljaGFyZCBCYXJuZXMgJmx0O3JsYkBp cHYuc3gmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlY2FsbCB0aGF0IFBSIzM0OSBk b2VzIHR3byB0aGluZ3MgKDEpIHVzZSBhbiBvcGFxdWUgZXBvY2ggSUQsIGFuZCAoMikgZW5jcnlw dCB0aGUgY29udGVudCB0eXBlIG9mIHRoZSBtZXNzYWdlIChhcHBsaWNhdGlvbiAvIHByb3Bvc2Fs IC8gY29tbWl0KSBbMV0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gdGhlIGNhbGwgbGFzdCB3 ZWVrIHRoYXQgZW5jcnlwdGluZyB0aGUgY29udGVudCB0eXBlIG1pZ2h0IG5vdCBiZSB0aGF0IHVz ZWZ1bCwgc2luY2UgYW4gYXBwbGljYXRpb24gdGhhdCByZWxpZXMgb24gYSBzZXJ2ZXIgdG8gYXNz dXJlIG9yZGVyaW5nIG9mIGNvbW1pdHMgd2lsbCBuZWVkIHRvIGF0IGxlYXN0IGJlIGFibGUgdG8g dGVsbCBjb21taXRzIGZyb20gb3RoZXINCiB0aGluZ3MuJm5ic3A7IE9mIGNvdXJzZSwgZXZlbiBp ZiB0aGUgY29udGVudCB0eXBlIGlzIGVuY3J5cHRlZCBieSBkZWZhdWx0LCB0aGUgYXBwbGljYXRp b24gY2FuIGFkZCBpdCBiYWNrIGluIGF1dGhlbnRpY2F0ZWQgZGF0YSwgb3IgaW4gc29tZSB1bmF1 dGhlbnRpY2F0ZWQgd3JhcHBlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TmV0IG9mIHRob3NlIGNvbnNpZGVyYXRpb25zLCBJJ20gcGVyc29u YWxseSBzdGlsbCBpbmNsaW5lZCB0byBtZXJnZSB0aGUgUFIsIHRvIGhhdmUgYSBjb25zZXJ2YXRp dmUgYmFzZWxpbmUuJm5ic3A7IEJ1dCB0aG9zZSBvbiB0aGUgY2FsbCB0aG91Z2h0IGl0IHdvdWxk IGJlIHVzZWZ1bCB0byBwb3NlIHRoaXMgdG8gdGhlIGdyb3VwLCBzbyBwbGVhc2Ugc3BlYWsgdXAg aWYgeW91IGhhdmUgY29uY2VybnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tUmljaGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L21sc3dnL21scy1wcm90b2NvbC9wdWxsLzM0OSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9n aXRodWIuY29tL21sc3dnL21scy1wcm90b2NvbC9wdWxsLzM0OTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk1MUyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TUxTQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FCAAD638E0F84A9190F11A2F1233D88Fnpsedu_-- From nobody Tue Jul 14 09:36: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 657C83A0ACE for ; Tue, 14 Jul 2020 09:36: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, RCVD_IN_DNSWL_BLOCKED=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 lSuUFJQ_SMq3 for ; Tue, 14 Jul 2020 09:36:36 -0700 (PDT) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4B03A0C85 for ; Tue, 14 Jul 2020 09:36:28 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4B5mP66YcjzQlLm for ; Tue, 14 Jul 2020 18:36:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172]) (amavisd-new, port 10030) with ESMTP id OH7fnXlV3vVj for ; Tue, 14 Jul 2020 18:36:20 +0200 (CEST) To: mls@ietf.org References: <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> From: Konrad Kohbrok Message-ID: Date: Tue, 14 Jul 2020 18:36:20 +0200 MIME-Version: 1.0 In-Reply-To: <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-MBO-SPAM-Probability: 0 X-Rspamd-Score: -4.01 / 15.00 / 15.00 X-Rspamd-Queue-Id: 6E7E41738 X-Rspamd-UID: c78468 Archived-At: Subject: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) 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, 14 Jul 2020 16:36:44 -0000 We just briefly touched upon this PR in the virtual interim on July 14th and I think we agreed that the discussion should be continued on the mailinglist and then tied up at the IETF 108 meeting. I think continuing the discussion on the mailinglist is a good idea, however, neither Britta nor myself are going to be present at the IETF 108 meeting. Maybe we can push the discussion to the next virtual interim meeting instead? Cheers, Konrad On 18.06.20 16:29, Konrad Kohbrok wrote: > Hi, > > Just a small addition to Britta's response: > > For #3: We already mandate that the parent group must not be used anymore if a > Re-Init proposal is included in a commit in lines 2341-2342 of the PR (although > "to send messages" might as well be removed). We could also get rid of the > proposal and simply have the intent to re-initialize be implicit in sending a > Welcome message with a corresponding PSK Id. The idea behind the Proposal was to > make that intent explicit such that the intent, as well as the target > ciphersuite and MLS version are all entered into the transcript and thus agreed > upon. Even though the group is terminated after the proposal is received, this > agreement can be verified by using the authentication key technique that Britta > proposed, i.e. each party can check that their authentication key corresponds to > the one the committer uploaded. > > I'm also ok with splitting it into multiple individual PRs if that makes it > easier to review and discuss. > > Cheers, > Konrad > > > On 18.06.20 04:07, Hale, Britta (CIV) wrote: >> Hi Richard, >> >>   >> >> Thank you for the comments and careful read of the PR. >> >>   >> >> For #1/#2: I am amicable to the idea of adding an extension field to the commit >> message. As a general comment, we may want to consider if there are other types >> of commit extensions worth adding or, alternatively, how the field may be abused >> (e.g. treated as AD by an application). >> >> It terms of objection to the current form though, your argument is not clear. >> PSKIds should uniquely identify PSKs, and a joiner (or anyone) should be able to >> identify the correct PSK given the PSKId, if they are in possession of it. PSKs >> must only be used in an Add if the joiner is a past group member (line 2055) and >> therefore has the correct PSKId/group_id/psk_epoch, although this is nullified >> if we make the change discussed in #4. In that case, the issue for Adds goes away. >> >> The PR already allows for a PSK in the Welcome message. >> >>   >> >> For #3: Currently, in the PR, there is a recovery_secret derived per-epoch. When >> a member wants to re-initialize, they issue a Re-Init proposal. They may then >> re-initialize the group by sending a Welcome message (see lines 1923, 1948, and >> 2349) with the PSKId for the parent group/epoch and a psktype that indicates >> that they are re-initializing the group with the stated PSKId. So this seems to >> already be what you describe below as “have the initiator of the child send a >> Welcome that has a pointer back to the parent”. However, you are right that more >> detail can be added; in particular a requirement should be added to terminate >> the parent group and that the terminating member/re-init proposer must also >> create the new group. >> >>   >> >> For #4: There was a discussion at the first virtual interim in late April >> (Interim #11-2020) wherein some expressed a desire for this feature. Namely, >> instead of re-syncing the entire group, there were use cases for re-syncing the >> odd member when necessary. Its inclusion in the PR arises from that later >> request. I am favorable to removing it since, from security standpoint, it is >> not ideal. However, the motivation for this was pushed from the implementation >> standpoint. Consequently, now is a good time for anyone to speak up who wants to >> push for this. >> >>   >> >>   >> >> One item: you made point of specifically requesting – a few times – at the >> virtual interims #11 and #12 in April/May that this PSK PR and as many other key >> schedule-related PRs be combined into a single one. Raphael made a similar >> request under git issue #325. In fact, the authors of this PR had pushed back on >> that insistence to limit the current PR down to the items it currently covers, >> instead of merging in other key schedule changes as well. Are you saying that >> you have changed your mind? >> >> We can, of course, accommodate a revised preference if needed. >> >>   >> >>   >> >> Britta >> >>   >> >>   >> >>   >> >> *From: *MLS on behalf of Richard Barnes >> *Date: *Wednesday, June 17, 2020 at 3:54 PM >> *To: *Messaging Layer Security WG >> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) >> >>   >> >> Hey all, >> >> Sorry for the late review on this PR, I have finally gotten a chance to really >> dig into it, and ... I have some concerns.  My current thinking is consistent >> with my earlier comments that the general thrust of this PR is OK.  But I think >> the actual approach needs to change a fair bit. >> >> As its title implies, this PR is trying to do several things at once, which seem >> to me to be fairly separable: >> >> 0. Update the key schedule so that PSKs are injected at the right point and >> multiple PSKs are supported >> 1. Signal that a PSK should get injected into a given epoch >> 2. Request injection of PSK at join / in Welcome >> 3. Re-initialize the group with different parameters >> 4. Re-sync group members that have lost state >> >> For the most part, I think these are worthwhile goals, but they should be >> accomplished in different ways than the PR proposes.  Detailed thoughts by >> objective: >> >> >> # 0. Update the key schedule so that PSKs are injected at the right point and >> multiple PSKs are supported >> >> This part of the PR is fine, but I think is ultimately done a bit more elegantly >> with the n-PRF stuff in #337. >> >> >> # 1. Signal that a PSK should get injected into a given epoch >> # 2. Request injection of PSK at join / in Welcome >> >> (These go together) >> >> The PR proposes (heh) an EPSK proposal or an Add proposal, but then requires >> that only one EPSK be used.  I actually don't the proposal for including PSKs in >> Adds actually works.  The joiner would have to know all of them plus the EPSK, >> and there's not even any syntax in the PR to tell the joiner which ones to include. >> >> I would propose that instead we add an extensions field to the Commit message, >> then add a Commit extension that specifies the PSK ID for the PSK to be added.  >> That extension can then also go in the Welcome message corresponding to the >> commit, so that joiners know to add the PSK. >> >> This change actually doesn't make a difference in terms of what ends up in the >> transcript -- either way, only the PSK ID selected by the committer goes in the >> transcript.  It seems better not to deliberately have proposals floating around >> that never get included in the transcript. >> >> >> # 3. Re-initialize the group with different parameters >> >> The PR proposes another proposal type for reinitialization, but it's really >> under-specified what you do to re-init.  For example, what goes in the ratchet >> tree?  Clearly you need a brand new tree, since the one you have might be tied >> to the wrong ciphersuite.  What you really need is something like a Welcome message. >> >> And that's how I think we should actually arrange things.  Instead of having the >> parent group do something to spawn, have the initiator of the child send a >> Welcome that has a pointer back to the parent.  So we have another Welcome >> extension (`parent_group`, say) that has a pointer to the parent group by group >> ID and epoch, and instructs the joiner to take a secret from that group/epoch's >> key schedule and add it into the new group's key schedule. >> >> >> >> # 4. Re-sync group members that have lost state >> >> We should not do these.  At the January interim, we decided not to drop the >> resync issue (#93) given that there were some subtleties depending on exactly >> what state had been lost, and that it could be cleanly done in a separate spec. >> >> >> # Conclusions >> >> Given the above, I would propose we break this into separate issues to be closed >> with individual, smaller PRs.  Assuming that (0) will get addressed by the n-PRF >> PR, that leaves us with: >> >> #XXX Add Extensions to the Commit message >> #XXX Signal use of external PSKs in Commit/Welcome (=> extension to >> Commit/Welcome messages) >> #XXX Allow Welcome to signal the inclusion of information from a prior group (=> >> Welcome extension) >> >> Happy to write those up, and contribute to PRs.  Sorry again for the slow >> progress here. >> >> --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 > From nobody Tue Jul 14 10:00:38 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 546483A0AD5 for ; Tue, 14 Jul 2020 10:00:36 -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 AkoPIW5Hbysq for ; Tue, 14 Jul 2020 10:00:34 -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 AA8E43A0AA7 for ; Tue, 14 Jul 2020 10:00:34 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id k18so13333925qtm.10 for ; Tue, 14 Jul 2020 10:00:34 -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=Vt1BzX+0r/qvUbylwTjj7hmRGyj+SaJHVubadc90nL4=; b=cQb64ZxJjzYhZ2wuYvvt7mSs5GSk+KIaULAy/A3fLzmSIH4xj+xNyWdHtvTWQt0bxG 7epbW5kUzMtkOVvxMimLE+T3k/VLpId8b8QzO/Fte2huRUwMlsiPRrA1WGYiFjPlV5BN z+OmJI4mZCHl20szHF6NnOQw/gdkdXigysCUIzjMm1h4HUkNRV9c2zwtSVtYmJDTRqpX kOAeNecYWBLY71/lSTEs6itvA+j08apavpeFySMpvV775J0tGy8CzjHGgx3Xf9d9aGIY aXSF8Edl60KBTidA1ZdWOSq/wsWCplml/mX/1GUjU24YFq+40T6qmsiVKG4cMz8yAmEu DNGQ== 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=Vt1BzX+0r/qvUbylwTjj7hmRGyj+SaJHVubadc90nL4=; b=GZvHTINjjBaDG46tF/rJP+o6eMh3X2UIZz66RINHKsnZqcLTQithoPGxnGEHLEdzyH I61ca+UtimbwOODUklMedXrbBXvSc7RpVUvOLnAOPzTGMDJBs0w0AQD3OOUvNYA/l7N/ aQfPQ3+34HTtUIFzS0KgV1hQDYmBv8NWkg+zdBQk1UlQXPiXu7+K/kK4RLmKJEYSYOeY 4xLU+stiBpdt52KWQeH+125CrCPqTO7huAcSASlu7Z4CcY/GSi71sz/eT8SIBEDrH4/T bZiT5+O0+p7C0L8senxg1rEY7wCvqqEi5uSo1ZO2LI10Cd1SF8uzfu2EWE9fXN7zD20j 56Iw== X-Gm-Message-State: AOAM532ZI+XOVITLKxfnoJ52lttFZTjxqvbYtwZi9YSOluLO5Yqxb7dG 79nSh8Kvo8QX308MKawY8zTazgMw+amDeXjs0AVx0Q== X-Google-Smtp-Source: ABdhPJxp0GiFML0f9sRQxa+S/c9F33SslZ1q3lOj+zK0oYjxhFUhpiGiah0z/SjmwdSrF0KXbvj/psNd/Ef/qDTrBCY= X-Received: by 2002:ac8:4649:: with SMTP id f9mr5462928qto.313.1594746033367; Tue, 14 Jul 2020 10:00:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 14 Jul 2020 13:00:11 -0400 Message-ID: To: Sean Turner Cc: MLS List Content-Type: multipart/alternative; boundary="000000000000d381b005aa69be47" Archived-At: Subject: Re: [MLS] 7/14 Interim X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 17:00:36 -0000 --000000000000d381b005aa69be47 Content-Type: text/plain; charset="UTF-8" Here are my notes from the call: * #350 * TODO(RLB): Make sure it bases CI, then merge * #348 * RLB concerned about ordering concerns here, since the signature public key to verify is from the tree * TODO(RLB): Add explanatory text to clarify that you MUST download the whole tree in order to process the Welcome, and how you verify a Welcome based on a tree * Once RR signs off on edits, will merge * #219 * RLB proposes that it might be better to punt this to the application level * TODO(SPT): Try to spur some more mailing list discussion * #336 * TODO(RLB): Pick mailing list thread back up, make progress on it * TODO(SPT): Make sure that this happens * #337 * Hoyland, Hale still working with the proofs, will follow up off-line * SPT: Two tracks - get the PR ready, get more crypto feedback * TODO(Brzuska): Follow up with Holland, Hale * TODO(Brzuska): Solicit feedback on CFRG (SPT to help) * #349 * Hale is concerned that a malicious insider could induce collisions in epoch ID, leading to authentication issues * RLB points out that epoch IDs are *already* collision prone * RR observes that DS is supposed to enforce ordering, so an attack here would require subverting that property * Discussion to continue on the list On Mon, Jul 13, 2020 at 8:11 PM Sean Turner wrote: > Reminder that there is an interim tomorrow. > > > On Jul 12, 2020, at 21:21, Sean Turner wrote: > > > > Just a reminder that there is a virtual interim planned for Tuesday July > 14 at 16:00 UTC. > > Attendance link is here: > > https://ietf.webex.com/ietf/j.php?MTID=m7f300037f89a213366d395bd400579a8 > > > > spt > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d381b005aa69be47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are my notes from the call:

=
* #350
=C2=A0 =C2=A0 * TODO(RLB): Make sure it bases CI, then merge=
* #348
=C2=A0 =C2=A0 * RLB concerned about ordering concerns here, s= ince the signature public key to verify is from the tree
=C2=A0 =C2=A0 *= TODO(RLB): Add explanatory text to clarify that you MUST download the whol= e tree in order to process the Welcome, and how you verify a Welcome based = on a tree
=C2=A0 =C2=A0 * Once RR signs off on edits, will merge
* #2= 19
=C2=A0 =C2=A0 * RLB proposes that it might be better to punt this to = the application level
=C2=A0 =C2=A0 * TODO(SPT): Try to spur some more m= ailing list discussion
* #336
=C2=A0 =C2=A0 * TODO(RLB): Pick mailing= list thread back up, make progress on it
=C2=A0 =C2=A0 * TODO(SPT): Mak= e sure that this happens
* #337
=C2=A0 =C2=A0 * Hoyland, Hale still w= orking with the proofs, will follow up off-line
=C2=A0 =C2=A0 * SPT: Two= tracks - get the PR ready, get more crypto feedback
=C2=A0 =C2=A0 * TOD= O(Brzuska): Follow up with Holland, Hale
=C2=A0 =C2=A0 * TODO(Brzuska): = Solicit feedback on CFRG (SPT to help)
* #349
=C2=A0 =C2=A0 * Hale is= concerned that a malicious insider could induce collisions in epoch ID, le= ading to authentication issues
=C2=A0 =C2=A0 * RLB points out that epoch= IDs are *already* collision prone
=C2=A0 =C2=A0 * RR observes that DS i= s supposed to enforce ordering, so an attack here would require subverting = that property
=C2=A0 =C2=A0 * Discussion to continue on the list

On= Mon, Jul 13, 2020 at 8:11 PM Sean Turner <sean@sn3rd.com> wrote:
Reminder that there is an interim tomorrow.

> On Jul 12, 2020, at 21:21, Sean Turner <sean@sn3rd.com> wrote:
>
> Just a reminder that there is a virtual interim planned for Tuesday Ju= ly 14 at 16:00 UTC.
> Attendance link is here:
> https://ietf.webex.co= m/ietf/j.php?MTID=3Dm7f300037f89a213366d395bd400579a8
>
> spt

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d381b005aa69be47-- From nobody Thu Jul 16 09:31: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 7E9783A0BDE for ; Thu, 16 Jul 2020 09:30:59 -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=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 cPYeD2ADZ0D8 for ; Thu, 16 Jul 2020 09:30:58 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF5E3A0BD9 for ; Thu, 16 Jul 2020 09:30:57 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id w34so5376008qte.1 for ; Thu, 16 Jul 2020 09:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=srHpAmjPIJ7wRfuBBmFohNfQCyI2iYgPwAAsuqZB2i4=; b=NNmnJX1r0SnBceidoSLxt8pv4ZQ+L3UcsIN+2FKSTrxaZ+cYJuUVyfX6NUuvPhYNz/ WgEDPGbN2qPcufN6YEltq0FlUAEPGP0m20B8Uv9RWv6iMRW5p6RM8COkr5cGeXsiq0Rs rBBTu5War8RV/pYMwEJDMpkmUJg+wFcOROEWQ= 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=srHpAmjPIJ7wRfuBBmFohNfQCyI2iYgPwAAsuqZB2i4=; b=piQzW7QpoN4bhp6WoIDtUFei2Yjt5iQKCZguiBmQAIbu1gLgBqMxy3kGmsW2rRfsG6 WwYVUvXdSK3MsoV04xuA0e6BLmIDpxRCRSjGlqTAk46hBMvQA5w7cYeZ+4liMR2ebmAg /HdahI7LvqiznCS3XZfPOIsnIYr/Rb9nTJAQ8aWw7MUvfv2XuG1VBMcKGDwq6cGToWsO /hOAwWaYeH8x8UzMj0MAKZ1QR0LzIq0HzGss49bD9l+JvQnDTqUey5Ol86j3xBXoAkC8 UZ1lwIVXN5FvpGWpotY8A9xohRXe0AU9WfR03CUbrhgPRox4DF1n3dVp+pEkY59+Dv8N /Qog== X-Gm-Message-State: AOAM5331MOJvGqeXeazarZNTDCeTPuxlNQ6Gz1QtYCpgntSuo12vKdy/ wdlUzptATg+nJ2RCQQb+afFHvJVqYYQtuz5MA1l98Adrk7y54w== X-Google-Smtp-Source: ABdhPJweuKj/1OdCgSMGDCwXbZIdTqtO+7v6onkT5AKX4zzSJCNkyXrhHgyz3PZRJD7gqt1iFA4hDrIA75/g23f+k8Y= X-Received: by 2002:ac8:444c:: with SMTP id m12mr6158503qtn.281.1594917056168; Thu, 16 Jul 2020 09:30:56 -0700 (PDT) MIME-Version: 1.0 From: Brendan McMillion Date: Thu, 16 Jul 2020 09:30:45 -0700 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000947df405aa9190ff" Archived-At: Subject: [MLS] Masking sender data 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, 16 Jul 2020 16:31:00 -0000 --000000000000947df405aa9190ff Content-Type: text/plain; charset="UTF-8" Hello mls@ There's been an open ticket [1] on MLS for a while now to explore masking sender data instead of encrypting it with an AEAD. I opened a PR [2] with an initial attempt to achieve this, which I wanted to now introduce to the list. The first major change is to encrypt the first block of `ciphertext` under a derived key with AES-ECB, and XOR the encoded SenderData with that value. The masked sender data replaces the `encrypted_sender_data` and obsoletes `sender_data_nonce`. The PR also specifies that the auth tag should be truncated from the `ciphertext` because the full MLSCiphertext is now authenticated with a MAC under a shared key, and this MAC is stored on its own in an `auth_tag` field on MLSCiphertext. The process of masking the sender data is designed to match the construction HN1 in [3]. The reason for messing around with the MAC structure, is that it allows us to validate the integrity of the sender data before we use it to generate sender-specific keys, while still only have one MAC total. One of the downsides to this proposal is that it requires two passes over the ciphertext, since we'd now encrypt and authenticate in separate passes. While I'd like to get rid of this, I don't think it will be a big performance issue for implementations. Feedback welcomed! 1. https://github.com/mlswg/mls-protocol/issues/302 2. https://github.com/mlswg/mls-protocol/pull/360 3. https://eprint.iacr.org/2019/624.pdf --000000000000947df405aa9190ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello mls@

There's been = an open ticket [1] on MLS for a while now to explore masking sender data in= stead of encrypting it with an AEAD. I opened a PR [2] with an initial atte= mpt to achieve this, which I wanted to now introduce to the list.

The first major change is to encrypt the first block of `ci= phertext` under a derived key with AES-ECB, and XOR the encoded SenderData = with that value. The masked sender data replaces the `encrypted_sender_data= ` and obsoletes `sender_data_nonce`. The PR also specifies that the auth ta= g should be truncated from the `ciphertext` because the full MLSCiphertext = is now authenticated with a MAC under a shared key, and this MAC is stored = on its own in an `auth_tag` field on MLSCiphertext.

The process of masking the sender data is designed to match the construct= ion HN1 in [3]. The reason for messing around with the MAC structure, is th= at it allows us to validate the integrity of the sender data before we use = it to generate sender-specific keys, while still only have one MAC total.

One of the downsides to this proposal is that it re= quires two passes over the ciphertext, since we'd now encrypt and authe= nticate in separate passes. While I'd like to get rid of this, I don= 9;t think it will be a big performance issue for implementations.
=

Feedback welcomed!

--000000000000947df405aa9190ff-- From nobody Fri Jul 17 16:42: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 115CD3A0B97 for ; Fri, 17 Jul 2020 16:42:08 -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 zeAnpbKB1diH for ; Fri, 17 Jul 2020 16:42:06 -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 909613A0B91 for ; Fri, 17 Jul 2020 16:42:06 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id 80so10329833qko.7 for ; Fri, 17 Jul 2020 16:42:06 -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=/N27usIW42JZmItYUIuvR6/qPBi1VKomMLNkoHySh1Q=; b=dlcz9lKJOk5ECn46nFbev2OVFM1l8B6MatHIRJMMDfq24YFDlyp5K/SuahfQTAh5Vy KJsssJoEtEMLBaopLRXdqXmZmvdmaReevXRwUi1Bmqr7SaUDb9pOxrqTUrA2Lb9Ro2tL 86NV2N03dgAU2ZDhwHT9y54Zg/Xwzd202c/u8= 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=/N27usIW42JZmItYUIuvR6/qPBi1VKomMLNkoHySh1Q=; b=F+eupHtz8fF3kUQfyN5YoKEA1SKc2kb0prNFTnbMdBZeNiTtb7QJdLBm/OyvdS9zwL tyEo5Qw1DRB33LwonuO1bVFnx4/jHIfgJDilst2lfsdRbsF+kiavpPgk/ubnKAp+o74M 673vi0YpAbm4hDvvb6gaRFJM++ov0Wgqp6gOx+b0gl6p5JKPeC32VjiaEw5BEgr4gQvy zAvj0M3bkPe1T1XnONUqRJo9sYNxyDNklUvUq/INi6n1AU3XMZptR/SFqu0IavbgnPLO QknIZi3GUhTICKL72YcyaIiMnkaGHWWNSzmlXuIukENIwM2nCU05IQkZe7U2bux69cf6 8cKA== X-Gm-Message-State: AOAM5303687aqbJOaReHMllskfVbTKptNVxWloChQVZGIJi7EPL6xnAk KVemh2Ach00OTfL2pRKaOudFFmkWnV0= X-Google-Smtp-Source: ABdhPJxp7CQDKznNRxOBPO5lUXtmymkiLKszYPTtHPbYvtDgPxPwVKHiy0FYWwkOrRQW2B2fIk3/CQ== X-Received: by 2002:a05:620a:7e7:: with SMTP id k7mr115972qkk.420.1595029325103; Fri, 17 Jul 2020 16:42:05 -0700 (PDT) Received: from [5.5.33.203] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id o12sm11996648qtl.48.2020.07.17.16.42.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2020 16:42:03 -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.1\)) Message-Id: Date: Fri, 17 Jul 2020 19:42:03 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [MLS] MLS@IETF108: Agenda Topics / Mea Culpa 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, 17 Jul 2020 23:42:08 -0000 Apologies for sending this request at this late. It is entirely my fault = for dropping this ball. The MLS WG will be meeting virtual for IETF 108 on Tuesday 2020-07-28 @ = 13:00 UTC for 50 minutes. The chair=E2=80=99s plan was to continue what = we have been doing with the other virtual meetings and just roll through = the GitHub issues and pull requests. But, if you have specific agenda = topics that you like to discuss please send in your agenda requests to = mailto:tls-chairs@ietf.org. Along with your request please provide an = estimate for how much time you will need. Nick and Sean= From nobody Fri Jul 17 16:55:00 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 9A0943A0C2D for ; Fri, 17 Jul 2020 16:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 8cqFIWYmwSHR for ; Fri, 17 Jul 2020 16:54:50 -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 AA0483A0C04 for ; Fri, 17 Jul 2020 16:54:50 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id c139so10324123qkg.12 for ; Fri, 17 Jul 2020 16:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=nCAJlBSH29Tcge5WRCWKn1WZGdYlxQcC3mGNsti0V0g=; b=BhU7gCMFzDcQ82sXpVqh88B8YBMdtREqbs9uxuqE01obhwve4ZNfHQ0uJddEKtCfXG 19prBGMf9ZMUEudiJz0xFCtRFRSASTOoQ6H8MWXjoU34c1aQlgtxhqBd1Y/Dz1/OTg5z AQ0rpKBIyl1jAxrhFbcZZLQsY7zEeKTcNhCEw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=nCAJlBSH29Tcge5WRCWKn1WZGdYlxQcC3mGNsti0V0g=; b=mCBsANtKZtkQjZOgQ6M6m7Ou//yo1dTRdtuXG7uQYyBrAH0bNcj6bF2wKBI2UkiQ+b HXifPNtMN66nBsx1mLRaHx3QGuQpxl5JraNcIjMLQhAdnes4E3/rNeDhMQ2b98IlTszI eAaJiFAAo0X+jRBb97j4GZMs1BCr6SN8gJcook5J2PEB9qupRBca6PIjxBkwk69Jlp6g Q4kH/azx+2YIv1fbB2ToMlonGIgMvGic4hQFxTDD6jTioDfQUqOniv2uiAMp9nyZmSfC lxhAE6xfFSb8jtXTNRYZcM2S2sUsE6fXM6LcQOiGts88ff0e4184+/SJaBnxFsbAuPNu fSfg== X-Gm-Message-State: AOAM530FgsZoUAnyLmp73jpuOitgy2r/9H6R0py3jAR+CedF+NvcIg7v uQy+gDRGXNJe3cLrURtF2cxOPavqLe8= X-Google-Smtp-Source: ABdhPJwgojd2HGEsnCUQzQmcUN91oeud9G215kqjxN2BMYSLuy3twxg3Y+oofr0+ooI9Ye0Bh0dSug== X-Received: by 2002:a37:d02:: with SMTP id 2mr10876197qkn.382.1595030089271; Fri, 17 Jul 2020 16:54:49 -0700 (PDT) Received: from [5.5.33.203] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id f18sm13374265qtc.28.2020.07.17.16.54.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2020 16:54:48 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_60775103-ED4C-4396-A8EC-3DEDFF89236A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <7CFE9B09-FA65-4BBB-BE8E-4150A1D00A6A@sn3rd.com> References: <437DEDB1-5C00-4ECC-994D-1111021458A8@ietf.org> To: MLS List Date: Fri, 17 Jul 2020 19:54:48 -0400 X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [MLS] Fwd: [108all] Reminder about IETF 108 Online test sessions 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, 17 Jul 2020 23:54:58 -0000 --Apple-Mail=_60775103-ED4C-4396-A8EC-3DEDFF89236A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI - some useful info for IETF108. > Begin forwarded message: >=20 > From: Greg Wood > Subject: [108all] Reminder about IETF 108 Online test sessions > Date: July 14, 2020 at 19:11:09 EDT > To: 108all@ietf.org >=20 > Hello, >=20 > Meetecho will be the main conferencing platform for the IETF 108 = Online meeting. >=20 > Test sessions for meeting participants have been scheduled for: >=20 > =E2=80=A2 16 July 2020, 1200 UTC > =E2=80=A2 17 July 2020, 0000 UTC > =E2=80=A2 17 July 2020, 1500 UTC >=20 > Each session is scheduled to last about an hour. Sessions will = include: >=20 > =E2=80=A2 a tour of Meetecho features and controls; > =E2=80=A2 demos of capabilities such as queue management, hums, = and presentation sharing; and > =E2=80=A2 plenty of time for discussion and questions. >=20 > Test sessions will be recorded and shared in advance of IETF 108. >=20 > You are encouraged to review the IETF 108 participant guide, which has = links to the sessions and further details: >=20 > https://www.ietf.org/how/meetings/108/session-participant-guide/ >=20 > Also, Gather.town will be available as a = platform for social interaction during the IETF 108 meeting week. = Details are being finalized and will be shared ahead of the meeting. In = the meantime, a test session has been set up at: >=20 > https://gather.town/iCbv26xgBvGPhlyR/ietftest > with the password: Test108!=20 >=20 > This won=E2=80=99t be covered in the Meetecho sessions, but you are = encouraged to try it out as well. >=20 > Sincerely, >=20 > -Greg >=20 >=20 > -- >=20 > Greg Wood > ghwood@ietf.org > +1-703-625-3917 >=20 > --=20 > 108all mailing list > 108all@ietf.org > https://www.ietf.org/mailman/listinfo/108all --Apple-Mail=_60775103-ED4C-4396-A8EC-3DEDFF89236A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI = - some useful info for IETF108.

Begin = forwarded message:

From: = Greg Wood <ghwood@ietf.org>
Subject: = [108all] Reminder = about IETF 108 Online test sessions
Date: = July 14, 2020 at 19:11:09 = EDT
To: = 108all@ietf.org

Hello,

Meetecho will be the main = conferencing platform for the IETF 108 Online meeting.

Test sessions for meeting participants have been scheduled = for:

=E2=80=A2 16 July 2020, 1200 = UTC
=E2=80=A2 17 July 2020, 0000 = UTC
=E2=80=A2 17 July 2020, 1500 = UTC

Each session is scheduled to last about = an hour. Sessions will include:

=E2=80=A2 = a tour of Meetecho features and controls;
=E2=80=A2 = demos of capabilities such as queue management, hums, and presentation = sharing; and
=E2=80=A2 plenty of time for = discussion and questions.

Test sessions = will be recorded and shared in advance of IETF 108.

You are encouraged to review the IETF 108 participant guide, = which has links to the sessions and further details:

https://www.ietf.org/how/meetings/108/session-participant-guide= /

Also, Gather.town = <https://gather.town> will be available as a platform for social = interaction during the IETF 108 meeting week. Details are being = finalized and will be shared ahead of the meeting. In the meantime, a = test session has been set up at:

https://gather.town/iCbv26xgBvGPhlyR/ietftest
with the password: Test108!

This = won=E2=80=99t be covered in the Meetecho sessions, but you are = encouraged to try it out as well.

Sincerely,

-Greg

--

Greg Wood
ghwood@ietf.org
+1-703-625-3917
--
108all mailing list
108all@ietf.org
https://www.ietf.org/mailman/listinfo/108all

= --Apple-Mail=_60775103-ED4C-4396-A8EC-3DEDFF89236A-- From nobody Sun Jul 19 00:41: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 599513A0AFF for ; Sun, 19 Jul 2020 00:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=qh7f0xBy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KP+TAL2x 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 gI1jDCEVFOCa for ; Sun, 19 Jul 2020 00:41:32 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3A93A0AFE for ; Sun, 19 Jul 2020 00:41:32 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 43819D4C for ; Sun, 19 Jul 2020 03:32:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 19 Jul 2020 03:32:28 -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=o/Jgpc/8NKyUIR3M5CwzvT94J70DlhD5bfzEdMI+JIs=; b=qh7f0xBy ygES6XD7fVWipx8He4HErIL8Cf5a7U1FN30YrMe089HSRRnsS3f9H2KseqqlhRXF A6ESH9UNRrWcWJ7fc1vNqSdlHTH15Y2XC4fteIhgMTbWBTZIhiuQavc4uSfz2TT+ XC601/6eBp0mdRDRdI3NaceomkeZ8abQumJuIVl0tErrwxPbjBhaPwfsNGTO3G4I RIxSETwz8/8eJZYaTmrbJ08RCeBFgSlxZEH5+Sj7uqoC7hJr2jvnQ/ddRl7taTWk V/R6WO6AZrag/E5ew5puIRiNjb5nBcZSraBOQjVP9JbxJ+wPCgAqDRSwwzUCumi6 EWL+InpvqXjCbw== 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=fm3; bh=o/Jgpc/8NKyUIR3M5CwzvT94J70Dl hD5bfzEdMI+JIs=; b=KP+TAL2xwYti8rDn2cOZdWdY28s1KA50FHYNAlQ2ZtNnx dS1DpLpHgHKLKss8Ks/uELVyYohWFhTQYoVKK/f5IMksIYttFiT+KoooQeALdync jF6+6P4NAPAkd22bZtvRMYWxsHXezXSl5QqGtnGHPNAHGqPg4t6ahyj6N3hSqUSM GNpn47s7odmUbzcduUpfhEk/XSD50MHEgdrdG1t/fTvl832Hb6/IEshGB88w5/6H //KZ7qJWH77SllZfatHL0oq/PICvxkxMB9G67jVVhXFCewFlzPVs1gN73p/G3+v4 JmBi/SUoyJETORfgrZfnH2cwbf2fUKrjLm8AmTjxA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgedtgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddugeelrdefledrud eikeenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az131.internal.cloudapp.net (unknown [52.149.39.168]) by mail.messagingengine.com (Postfix) with ESMTPA id 89BB73280059 for ; Sun, 19 Jul 2020 03:32:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2116412826876932612==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200719073227.89BB73280059@mailuser.nyi.internal> Date: Sun, 19 Jul 2020 03:32:27 -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, 19 Jul 2020 07:41:34 -0000 --===============2116412826876932612== 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: - Handling user permissions in MLS versus implementations (by chelseakoml= o) https://github.com/mlswg/mls-architecture/issues/68=20 * mlswg/mls-protocol (+0/-1/=F0=9F=92=AC0) 1 issues closed: - Add IANA considerations for Extensions https://github.com/mlswg/mls-pr= otocol/issues/312 [bug]=20 Pull requests ------------- * mlswg/mls-architecture (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #67 Expand privacy section (1 by chelseakomlo) https://github.com/mlswg/mls-architecture/pull/67=20 * mlswg/mls-protocol (+2/-3/=F0=9F=92=AC5) 2 pull requests submitted: - #302: Reduce encryption overhead to just auth tag (by Bren2010) https://github.com/mlswg/mls-protocol/pull/360=20 - Fix bugs in tree math and cleanup docs. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/359=20 3 pull requests received 5 new comments: - #349 Use opaque epoch IDs and encrypt content type (1 by uhoreg) https://github.com/mlswg/mls-protocol/pull/349=20 - #337 Replace DKDF by n-PRF in key schedule; minor fix (3 by chrisbrzusk= a, seanturner) https://github.com/mlswg/mls-protocol/pull/337 [discussion] [key schedu= le] [security] [work in progress]=20 - #308 Remove nonce from SenderData AAD. (1 by beurdouche) https://github.com/mlswg/mls-protocol/pull/308 [discussion] [performanc= e]=20 3 pull requests merged: - Fix bugs in tree math and cleanup docs. https://github.com/mlswg/mls-protocol/pull/359=20 - IANA updates and their consequences https://github.com/mlswg/mls-protocol/pull/350=20 - Remove nonce from SenderData AAD. https://github.com/mlswg/mls-protocol/pull/308 [discussion] [performanc= e]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============2116412826876932612== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday July 19, 2020

Issues

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

1 issues created:

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

1 issues closed:

Pull requests

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

1 pull requests received 1 new comments:

mlswg/mls-protocol (+2/-3/=F0=9F=92=AC5)

2 pull requests submitted:

3 pull requests received 5 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============2116412826876932612==-- From nobody Mon Jul 20 13:02: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 2626A3A0E7B for ; Mon, 20 Jul 2020 13:02:48 -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 HxaSR3jtWEIw for ; Mon, 20 Jul 2020 13:02:45 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 878AF3A0E75 for ; Mon, 20 Jul 2020 13:02:45 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id u64so3618723qka.12 for ; Mon, 20 Jul 2020 13:02:45 -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=xUSk9zl9lOEb4bDS+hLU8bMfgKQlUTekGyVl0MR9sZ8=; b=IOKcPqTCTUwe/7seuj76luL7zN8dDUquKTXCaqBD6hChZDTTbmhd6Ij/oEChDjbIM3 elEEwVZtSydLof8TQ5hsPI8tlXLaMkbx2OnVoMQTamTBK9Hy2p//b0Dvxi/KmvpNdMK6 LHx/seIJh7mfYd8y6P+f8N51P01s/NQ+wbYX+bRiT+5cFCr38io4gFhJ8pP28uezF5mJ OOhZiw5qIAJXtNhBxA6RNsBydxT8c4KsA+pyNl+SYe13VfG2/1O21Loe4BxJclWbjrId 49ah8U/PIbCwISk8btHvbiQq5jV/i+0DiEaFDuh7agBCqvjbiOx7PG5+F2GmNwiFh+V7 VYJQ== 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=xUSk9zl9lOEb4bDS+hLU8bMfgKQlUTekGyVl0MR9sZ8=; b=nDNwVdeZqKJEzu0ml8pd08bPu048V53hC0v82qQmiD12mv5J5eyZ4s38f2bzdj5HBL CFYUHL86jxwKglfi2W106xA18BYUVxmeUfxKB/dCj2HTRXUApwbvPZ5BoUK3ww9fmhAS xX1m29NXC9DNVeH12tilP+8d37BWNyE4qnOVGBIAwOWfnzGG3WifVi9ZSd3XaiHoYFCM drh5wAn+1y7iE9//3w12iqbfmyss0EpNx4WjuTFaFkgPmN+r6d64T4VtGgBuZ2dTWrJi D5A1RVGJN5WvwflSRjrEQnKAjCw1l/D32+xzrbdAW4JHRWMhKg+gtaDM6L9kclqqJSJJ NszA== X-Gm-Message-State: AOAM5326ksm0mrSwZQvMMxygq55/4ssTO7cOYO5QJNNvdR8a0x56ZhXq Bg1+Ut1CTrZLvXpxs6GCU6xDwAQis3zBJGh4dsRKdg== X-Google-Smtp-Source: ABdhPJw9Gopcgv39r6hS2ctweG3HzZuBL6m1V1hGyUVJ4012za8mwJ4SkOfKOd/Q7tzZOsy1rtrZlMgSz6+9I1oGqHU= X-Received: by 2002:a05:620a:1478:: with SMTP id j24mr6620760qkl.347.1595275364083; Mon, 20 Jul 2020 13:02:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Mon, 20 Jul 2020 16:02:18 -0400 Message-ID: To: Brendan McMillion Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000654db705aae4fd06" Archived-At: Subject: Re: [MLS] Masking sender data 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, 20 Jul 2020 20:02:48 -0000 --000000000000654db705aae4fd06 Content-Type: text/plain; charset="UTF-8" Hi Brendan, Thanks a lot for writing this up! I agree that this addresses the authenticity concerns that had been raised on earlier iterations of this problem. I've suggested a few corrections and simplifications in the PR. https://github.com/mlswg/mls-protocol/pull/360#discussion_r457656760 Either way (what you suggested or with my edits), it's clear that there's some non-trivial complexity involved here. Both in terms of getting the operations in the right order (content encryption, then sender data encryption, and reverse for decryption), and in terms of constructing all the different AAD values. So I wonder how people feel about that taking that compexity cost in the interest of removing an explicit nonce. Personally, I'm probably still inclined to do it, since explicit nonces make me nervous, but I would like to hear what other folks think. --Richard On Thu, Jul 16, 2020 at 12:31 PM Brendan McMillion wrote: > Hello mls@ > > There's been an open ticket [1] on MLS for a while now to explore masking > sender data instead of encrypting it with an AEAD. I opened a PR [2] with > an initial attempt to achieve this, which I wanted to now introduce to the > list. > > The first major change is to encrypt the first block of `ciphertext` under > a derived key with AES-ECB, and XOR the encoded SenderData with that value. > The masked sender data replaces the `encrypted_sender_data` and obsoletes > `sender_data_nonce`. The PR also specifies that the auth tag should be > truncated from the `ciphertext` because the full MLSCiphertext is now > authenticated with a MAC under a shared key, and this MAC is stored on its > own in an `auth_tag` field on MLSCiphertext. > > The process of masking the sender data is designed to match the > construction HN1 in [3]. The reason for messing around with the MAC > structure, is that it allows us to validate the integrity of the sender > data before we use it to generate sender-specific keys, while still only > have one MAC total. > > One of the downsides to this proposal is that it requires two passes over > the ciphertext, since we'd now encrypt and authenticate in separate passes. > While I'd like to get rid of this, I don't think it will be a big > performance issue for implementations. > > Feedback welcomed! > > 1. https://github.com/mlswg/mls-protocol/issues/302 > 2. https://github.com/mlswg/mls-protocol/pull/360 > 3. https://eprint.iacr.org/2019/624.pdf > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000654db705aae4fd06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brendan,

Thanks a lot for= writing this up!=C2=A0 I agree that this addresses the authenticity concer= ns that had been raised on earlier iterations of this problem.=C2=A0 I'= ve suggested a few corrections and simplifications in the PR.

Either way (what you suggested or = with my edits), it's clear that there's some non-trivial complexity= involved here.=C2=A0 Both in terms of getting the operations in the right = order (content encryption, then sender data encryption, and reverse for dec= ryption), and in terms of constructing all the different AAD values.=C2=A0 = So I wonder how people feel about that taking that compexity cost in the in= terest of removing an explicit nonce. Personally, I'm probably still in= clined to do it, since explicit nonces make me nervous, but I would like to= hear what other folks think.

--Richard

On Thu, Jul 16, 2020 at 12:31 PM Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org= > wrote:
=
Hello mls@

There's been = an open ticket [1] on MLS for a while now to explore masking sender data in= stead of encrypting it with an AEAD. I opened a PR [2] with an initial atte= mpt to achieve this, which I wanted to now introduce to the list.

The first major change is to encrypt the first block of `ci= phertext` under a derived key with AES-ECB, and XOR the encoded SenderData = with that value. The masked sender data replaces the `encrypted_sender_data= ` and obsoletes `sender_data_nonce`. The PR also specifies that the auth ta= g should be truncated from the `ciphertext` because the full MLSCiphertext = is now authenticated with a MAC under a shared key, and this MAC is stored = on its own in an `auth_tag` field on MLSCiphertext.

The process of masking the sender data is designed to match the construct= ion HN1 in [3]. The reason for messing around with the MAC structure, is th= at it allows us to validate the integrity of the sender data before we use = it to generate sender-specific keys, while still only have one MAC total.

One of the downsides to this proposal is that it re= quires two passes over the ciphertext, since we'd now encrypt and authe= nticate in separate passes. While I'd like to get rid of this, I don= 9;t think it will be a big performance issue for implementations.
=

Feedback welcomed!

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000654db705aae4fd06-- From nobody Thu Jul 23 10:19: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 0BF193A0C36 for ; Thu, 23 Jul 2020 10:19:01 -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 njIPo_mopzPY for ; Thu, 23 Jul 2020 10:19:00 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F643A0C38 for ; Thu, 23 Jul 2020 10:18:59 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id w9so4950613qts.6 for ; Thu, 23 Jul 2020 10:18:59 -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=9Y6NdNaFzG0tyN1deRIHo6MqhL85q6aSDjRfuW2HxkI=; b=Eb4HKIIZmFYMjaAL7b4XN6iXXLbp18yXPMwWTs9/NW2H22DQwltjGTLO5XvLrIxBSE NP/Gzi72tpWcpLi6LtnGLlJRbKyz/vb9XqA0EaEfmRXOhGmmmvNZQKtXwpqOmIWtlbR0 Tjo+2CP3F+HwDFPlmFl0FFZ0eJNr1nbk1opUM= 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=9Y6NdNaFzG0tyN1deRIHo6MqhL85q6aSDjRfuW2HxkI=; b=a4on0MSxzyoT7xGQNcSjgkQV7kr1LFCyoFv4jcDgK+uwE8KhkCvcDJT5WUnv7/Sno3 Wqav7yXoaPor2hzFIo4yjwi20Kwv4CmjypeCkdpaFnJqTfppgPCp3Ccpl/7eflDyJ4nz 0ehDv/HBBxbz8K6ehRk22xEIC2tlBDid1iY7Lwex+pt1z4SrC1aMXRABG8tCIweJ9rQR k4upVuwzgaRQXeafuORuF4vrNcTp3nmKhJJ2Z4tvU2OrOxtGvruQrDhOzU0AJlEA5mTe 9tb+IbfvRcl5vejt8m7L+oAHTdq/VaU0JVp4/xdLcEyLzSTuWhKel1Hk1XLBWNczSbBD wsOw== X-Gm-Message-State: AOAM530zgTFGH25F0NAnK/sxqaxGR0s4+DOCNRo+qJfzDctCiMc4U7t8 6hmtC9/f/NSRzJ+iHhYYMESPukifATM= X-Google-Smtp-Source: ABdhPJzM1Xzs6tham6lWRUSl8/S4VatrJy1RVs09Lyj4Kvp+qKpQzGhqkezQnyGpLlTd8ljaxFqNOA== X-Received: by 2002:aed:2125:: with SMTP id 34mr5117803qtc.203.1595524738244; Thu, 23 Jul 2020 10:18:58 -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 f41sm3145853qtk.55.2020.07.23.10.18.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2020 10:18:57 -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.1\)) Message-Id: Date: Thu, 23 Jul 2020 13:18:55 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [MLS] MLS@IETF108: Agenda Uploaded 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, 23 Jul 2020 17:19:01 -0000 I have uploaded an agenda with the meeting logistics in case you need = them. The agenda itself is pretty bare bones, i.e., we are planning on = running through the outstanding issues pull requests. A couple of points: - I suspect that the only slides might have are from the chairs. - There really aren=E2=80=99t that many protocol-related issues/prs so = hopefully you can come up to speed quickly. spt= From nobody Fri Jul 24 10:54: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 176D23A10D2 for ; Fri, 24 Jul 2020 10:54:15 -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 X-9Ea6z1S5vB for ; Fri, 24 Jul 2020 10:54:11 -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 647743A10D1 for ; Fri, 24 Jul 2020 10:54:06 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id h7so9396537qkk.7 for ; Fri, 24 Jul 2020 10:54:06 -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=I1NRqwBt0CoGsTZyMIqOUccgfz2ne+XYCc/gOz7OBCE=; b=WmAZ80ydhM+BOCxvaGwFsuNaNt6aWtF1kiKEMDSR99MG+cjfmg+zp92yPaYcI9OGeT xK+F79CrifduAXuUbxBpqFKO9e3dxdQdEHU4ucBetZEZEEfYYNcNqs8ZyFApbZfTMjhh ttf7R/pVF+y0FDtcmw1Rg9Mh1NojculThDAgdBbrt8ElD3Pj2CBUG/Mhgx6UOkjUlU6Z J8ZnQOsAhgLC0FMAAC2p1z0f8zwtoFmkZjDURUtZYPHqHgZ6Vsqo0bFLOESz7AWlYVMw JYQPvydMqQ8msTUGt/pQCDauA34WTswW50WGv5Xb8V5IPMxrZCN1Irn+Thy4e0W2wmKU Topw== 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=I1NRqwBt0CoGsTZyMIqOUccgfz2ne+XYCc/gOz7OBCE=; b=ofCwl6Cx67ouZ1dK82tdQjLS6f+RrGfVK4gv/NWEYS6ixHAcJklDJJJRm3hcwM8OrF k+jnyRgCZDKVEXSojTu00D/KqxkvgbDJNp3g7OslYrAciI1DaU+TmdE3MkqjlsW0T4Ot /jDgnbLWdWQ3gKWEeP2PrGEqYenMRCP5Qhfs1PC2RWBoVrRyMoRzhEHqfWvzooycJl9i ciQi431MYGMMvQYh9yTkVU/Uy2NRE4dItAwMSMbxa0oWiwfK0hITQ7s7bgS+BaG93X1Y 6uL9U7AnFFVORqGtS3KoYVKjyJr2ajOyXnPIm/x4/yDhi3nJWu8kE1tdXDPmNyeADqqO uiTg== X-Gm-Message-State: AOAM530gfODmNnU56rz2L/iqOz7uw4lOTExETek3F8KkzOrkRsTbARRv U1Rh8aA6NxUELzkVQl5yQ9QY28ZRWJnuCghEV111/A== X-Google-Smtp-Source: ABdhPJyust8tRUFJtl+sLczZbl5tHshxsPgyRtb8jAkBG+hYSU80cGZ7n5cV3dccJZWgQh1YIncsBhiTxa1SNJzl+8I= X-Received: by 2002:ae9:ee06:: with SMTP id i6mr11424090qkg.132.1595613244909; Fri, 24 Jul 2020 10:54:04 -0700 (PDT) MIME-Version: 1.0 References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> In-Reply-To: <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> From: Richard Barnes Date: Fri, 24 Jul 2020 13:53:38 -0400 Message-ID: To: Chris Brzuska Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000a97d6605ab33a8ca" Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 24 Jul 2020 17:54:16 -0000 --000000000000a97d6605ab33a8ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Chris, I was looking again at the key schedule as I was drafting #362 [1]. A couple of things occurred to me: 1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret. 2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362. Given those observations, I wonder how much an nPRF is really buying us. It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call. Maybe there's some benefit if there are multiple PSKs? But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple. At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336. --Richard [1] https://github.com/mlswg/mls-protocol/pull/362 On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska wrote= : > Thank you for the pointer to Carter-Wegman MACs. > > >>> This style of combing hash outputs does affect collision resistance > [4], and some discussion on relation to that would be nice to see. > > That's an excellent point. In addition to pseudorandomness, we prove the > collision-resistance of our construction. I.e., assuming that no unique > value is used twice and assuming that HMAC is collision-resistance, then > the final Expand operation guarantees unique outputs. I.e., by including > the unique value into the final Expand operation after the xor, the > construction recovers from any collisions incurred by the xor. > > Chris > On 07/07/2020 05:41, Hale, Britta (CIV) wrote: > > This is an interesting proposal. It is closely related at a high level to > Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D PRF(k1,= r) > XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. > Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, > there is an overlap between NPRFs and extrapolation of the above (based o= n > iteration of the PRF guarantees). > > > > This is worth noting from an assurance standpoint: there was discussion a= t > the virtual interims with respect to the current formulation of MLS key > derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet this propos= al is not without > precedence itself. Ergo, such a change should not necessarily be concerni= ng > based on differing from current practice. > > > > This style of combing hash outputs does affect collision resistance [4], > and some discussion on relation to that would be nice to see. > > > > Britta > > > > > > > > [1] Carter, Wegman. Universal classes of hash functions. > > [2] Carter, Wegman. New hash functions and their use in authentication an= d > set equality. > > [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard > Assumptions: A Generic Validation of an HMAC Assumption. > > [4] Bernstein. What output size resists collisions in a xor of > independent expansions? > > > > > > > > *From: *MLS on behalf of > Chris Brzuska > *Date: *Tuesday, June 9, 2020 at 10:32 AM > *To: *"mls@ietf.org" > *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) > > > > Hi all, > > I would like to open a discussion on a suggestion for a change in the key > schedule. In the current draft, we use the Extract function twice as a du= al > pseudorandom function (DPRF) when combining 3 keys (*) and interleave the= m > with an Expand call. > > The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF= ) > which is especially designed to return a pseudorandom key when at least o= ne > of the input keys is pseudorandom. The new suggestion relies on standard > PRF security rather than DPRF-security of Extract. > > You can find the accompanying paper with pictures, discussion and securit= y > reduction for the design principle here [2]. I include a summary of the > main points in the end of this eMail. > > Please comment/share your opinion. Thanks! > > Chris > > (*) commit_secret, PSK and init_secret > > [1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337 > > [2] Paper: http://chrisbrzuska.de/2020-NPRF.html > > > *------------------------------------------------------------------------= --------------------------------------------* > > *Summary of main points:* > > The current key schedule > - uses Extract as a dual pseudorandom function and assumes that HMAC is a > dual pseudorandom function > - applies Extract after Expand, i.e., after applying a function which > generates a pseudorandom value > - iterates Extract-then-Expand sequentially to combine more than 2 keys > > The pull request suggests to > - replace the ad-hoc assumption that Extract is a dual pseudorandom > function > - remove Extract steps when applied after Expand > - use a provably secure NPRF construction which allows to combine more > than 2 keys and is based on a standard PRF assumption and statistical > properties of xor. > > Efficiency: > - The suggested construction has higher parallel efficiency. It increases > the overall number of HMAC evaluations by 1. > > Assumptions: > - HMAC is a standard PRF. > - Relies on a unique value, the group_context was suggested. > > Construction: > (1) Use unique value to expand each key and xor the result > (2) expand resulting key, including unique value into the context again > > Security argument: > - Pseudorandomness: unique value ensures that each outcome of Expand in > (1) is used only once in a xor combination, thus allowing on one-time pad > argument of xor. > - Uniqueness of resulting keys: (2) ensures that if HMAC is > collision-resistent, then the result is collision-resistent. > > Variants: > - It is possible to use an NPRF variant called NameNPRF [2] which has 3 > HMAC evaluations more and relies less on the unique value. I.e., NameNPRF > is secure in the same scenarios as DPRF: Keys only repeat if the input ke= ys > repeat *and* the group context repeats. > > Questions/Comments that came up: > - Barnes, MacMillion suggested group_context as unique value > - MacMillion wondered about removal of Extract: One can add an extract > operation for the psk. For other input keys, it does not seem needed, sin= ce > they were returned from Expand. > - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of > output keys, the PRF needs to be collision-resistant, too. > > _______________________________________________ > MLS mailing listMLS@ietf.orghttps://www.ietf.org/mailman/listinfo/mls > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000a97d6605ab33a8ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Chris,

I was looking aga= in at the key schedule as I was drafting #362 [1].=C2=A0 A couple of things= occurred to me:

1. You can't add the commit s= ecret and PSKs in the same operation, because you want new joiners to put i= n the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same n= umber of HMAC invocations as the chained-HKDF-Extract stuff that's in t= he current draft / 362.

Given those observations, = I wonder how much an nPRF is really buying us.=C2=A0 It's not saving us= any HMAC calls, and relative to #362, it would only coalesce two DPRF call= s into one nPRF call.

Maybe there's some b= enefit if there are multiple PSKs?=C2=A0 But even then, it seems like you c= ould add a layer, computing a synthetic PSK from the multiple ones, and kee= ping the main key schedule simple.

At this poi= nt, given the above and the novelty of the nPRF construction, I'm incli= ned to just stick with HKDF and merge #362 instead of #336.

On Tue, Jul 7, 2020 at 5:30 AM Chris Brzus= ka <chris.brzuska@aalto.fi= > wrote:
=20 =20 =20

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:
=20 =20 =20

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D=C2=A0 PRF(k1, r) XOR MAC(= k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

=C2=A0

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet this proposal i= s not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

=C2=A0

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

=C2=A0

Britta

=C2=A0

=C2=A0

=C2=A0

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. = What output size resists collisions in a xor of independent expansions?

=C2=A0

=C2=A0

=C2=A0

From: MLS <= ;mls-bounces@ietf.org> on behalf of Chris Brzuska &= lt;chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: = "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

=C2=A0

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

-------------------------------------------------------------= -------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
MLS mailing list
MLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000a97d6605ab33a8ca-- From nobody Fri Jul 24 11:05:14 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 084F63A1105 for ; Fri, 24 Jul 2020 11:05: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 GgjoEtLJzCnN for ; Fri, 24 Jul 2020 11:05:10 -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 9BF943A1102 for ; Fri, 24 Jul 2020 11:05:10 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 11so9477096qkn.2 for ; Fri, 24 Jul 2020 11:05:10 -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=iZg/iW+if3g6yjIOBhx9BmaO0pBVFB/ljcXDrezQAGc=; b=QQrYWSd6t3mez2OlBgbG9HbcmY2FZUOyYXko4Uanm7O6ygwiCr9XeycQlzGTIC5fVX VFQm1K1Yip/bVJYDovcWJIuHqJSoPyaTEHXIsIh60oziqCZBuuGo4Psue5hbxQ5CH6tB +JaP5/4Ck8J2b6fPIIyTzY80UHxmhATjQzEOz5WMrmyqYqn8G8tz3MbVcHswiaAXyb0q Hedb6M20dn6Z95soV5dXgKM11ohHL8DK6VtQDgbuwlZbxt5HMvJON6lFTVYcGCt+3H3i TMHkyaqKZqWoZtRv5yxzM8DTL8wGRCSU0x3Qpk9vmk35a3rNy3DtBmDZj2XEHzvHoctv CaFQ== 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=iZg/iW+if3g6yjIOBhx9BmaO0pBVFB/ljcXDrezQAGc=; b=ZA11r3MysG1UkCitN1Q4ITBn8ajnDpWF1NajWIvPTrO2NYh9t1KRk/NFw4///AL9iS Dwets+TKx0K1f94XnzSIRPWqkOqRoQZxi/awg8tlPGIIvQqLeqdnLa7ifAI6zyyv1A7m wxEipbOtj8+W38//ceon33PT1UG3UOAoV2yPcnIjQHAtcAlyhK2+QZ1Z4rxl05JBOue8 hAD+ogibdRkY0ch+ubMjYtreVcIiXfTf4P/z6LsusxRRLJ5X4Wm72dVge8PzF2FEX9n1 qqnjYhMRKrxiIpCNyOB4VJ3McYovfO/LNAxsDDjcaf5X1UB3zfHXWKvuYOUx8pZEi6Wi 8GrQ== X-Gm-Message-State: AOAM5317XP7nQ4dvdy8fsLNEOVaeTKF4Ed6lYAo3brXQzLuhSlJU9qD4 OhNyCoaQGg95d4GdUJEjNknVfgQXB6UiXx1uAvc7/kFvGlo= X-Google-Smtp-Source: ABdhPJzSX9bKqXiQnX1IJjpUvrsASZGSfVsnP+HvICJYIGypLxyZNQz+eqiD63wKO09BTF7/qeNxnMZYZRLgu3vTYew= X-Received: by 2002:a05:620a:125b:: with SMTP id a27mr12095393qkl.371.1595613909574; Fri, 24 Jul 2020 11:05:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 24 Jul 2020 14:04:42 -0400 Message-ID: To: "Hale, Britta (CIV)" Cc: Brendan McMillion , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000047773305ab33d00a" Archived-At: Subject: Re: [MLS] Hiding content type 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, 24 Jul 2020 18:05:13 -0000 --00000000000047773305ab33d00a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm honestly really confused by the worry about collisions here. The current epoch ID collides trivially -- it's just a counter! And the group ID is assumed to be public anyway. So if your authentication scheme is broken when you have a (group ID, epoch ID) collision, then your scheme is already broken. If we're going to block this change on this basis, then we need to see clearly articulated an authentication scheme that is secure in the current model, but broken in the case where epoch IDs are derived off of the key schedule. --Richard On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) wrote: > Ensuring the most conservative design by default seems advisable; however > it is not clear that this proposal for hiding content type is actually > doing that. Indeed, if an application is concerned about hiding the conte= nt > type, would not that same type of application also be concerned about > collisions? > > > > As Brendan notes, we are not talking about accidental collisions here. > Pre-computation is entirely possible, such as by a malicious group member= , > so the window of attack is not limited to one epoch. > > > > If this is this PR particular is of particular interest to some, then it > would be good to see a clarifying explanation as to the security it > achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite i= ntroducing such > collision possibilities), or a concrete use-case. Alternatively, are we > really limited to a 64-bit field, or can that length be adjusted to > mitigate the introduced problems? > > > > > > > > A clarifying point for those following this thread: some references in th= e > email chain state that this is encryption of the epoch ID. That is not th= e > case. The proposal being discussed is about a hash thereof (hence > discussion on collisions). > > > > Britta > > > > > > *From: *MLS on behalf of Brendan McMillion > > *Date: *Monday, July 13, 2020 at 9:37 AM > *To: *Richard Barnes > *Cc: *Messaging Layer Security WG > *Subject: *Re: [MLS] Hiding content type > > > > As far as collision resistance, I'm not too worried about collisions amon= g > 64-bit random values, especially as the scope for collision is fairly > small, arguably just one epoch. > > > > The issue isn't with accidental collisions, it's with malicious ones. An > attacker can purposefully (and quickly) generate commits that create > duplicate epoch ids, and send them to a client to corrupt their group sta= te. > > > > I think the idea here is to be conservative by default. There are system= s > in which you can hide the metadata you're talking about with things like > mixnets and dropboxes. > > > > It's not just being more conservative, you're making changes specifically > for very niche use-cases where I don't think the security of the whole > system has been thought through. Maybe you have an example in mind, but I > can't think of a system where this change provides any additional privacy= . > > > > On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: > > On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion > wrote: > > With respect to using an opaque epoch id, I believe this was proposed in > #245 and consensus was > against it because it makes it more difficult to implement the DS. It's > also not clear to me what security properties you want from an opaque epo= ch > id, because the current PR doesn't provide collision resistance and I'd > expect this to be a source of confusion and bugs. > > > > I think the discussion on #245 got derailed a bit by the focus on > non-linear epochs. The point here is that even in a case where you have > linear history, I think there's intrinsic value in the epoch ID being > opaque because it gives intermediaries less opportunity for ossification. > > > > As far as collision resistance, I'm not too worried about collisions amon= g > 64-bit random values, especially as the scope for collision is fairly > small, arguably just one epoch. > > > > > > With respect to encrypting the content type, it also seems to me that thi= s > would cause issues because different content types have different deliver= y > guarantees. Specifically: messages are allowed to be unordered and lossy, > proposals are allowed to be unordered but not lossy, and commits are both > ordered and not lossy. In the deployment scenarios we've talked about, th= e > DS essentially always needs to know the content type to provide this. > Conversely, you don't get much additional privacy from encrypting the > content type because an eavesdropper can see the epoch id change and infe= r > which message was a commit, or see a dropped message getting re-sent and > infer it was a proposal. > > > > I don't disagree that there are different guarantees you need, but like I > said, I think the idea here is to be conservative by default. There are > systems in which you can hide the metadata you're talking about with thin= gs > like mixnets and dropboxes. Keeping the ciphertext as opaque as possible > keeps the door open to running MLS over those systems without MLS's own > metadata undermining their privacy properties. > > > > FWIW, in the systems I'm looking at building, this PR does not make any > difference, because clients use separate channels for Proposals/Commits v= s. > application data and the server doesn't check. > > > > --Richard > > > > > > > > On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: > > Hi all, > > > > Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) > encrypt the content type of the message (application / proposal / commit) > [1]. > > > > There was some discussion on the call last week that encrypting the > content type might not be that useful, since an application that relies o= n > a server to assure ordering of commits will need to at least be able to > tell commits from other things. Of course, even if the content type is > encrypted by default, the application can add it back in authenticated > data, or in some unauthenticated wrapper. > > > > Net of those considerations, I'm personally still inclined to merge the > PR, to have a conservative baseline. But those on the call thought it > would be useful to pose this to the group, so please speak up if you have > concerns. > > > > --Richard > > > > [1] https://github.com/mlswg/mls-protocol/pull/349 > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --00000000000047773305ab33d00a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm honestly really confused by the worry about c= ollisions here.=C2=A0 The current epoch ID collides trivially -- it's j= ust a counter!=C2=A0 And the group ID is assumed to be public anyway.=C2=A0= So if your authentication scheme is broken when you have a (group ID, epoc= h ID) collision, then your scheme is already broken.

If we're going to block this change on this basis, then we need to s= ee clearly articulated an authentication scheme that is secure in the curre= nt model, but broken in the case where epoch IDs are derived off of the key= schedule.

--Richard

On Tue, Jul 14, 2020 at 10:= 38 AM Hale, Britta (CIV) <britta.= hale@nps.edu> wrote:

Ensuring the most conservative design by default see= ms advisable; however it is not clear that this proposal for hiding content= type is actually doing that. Indeed, if an application is concerned about = hiding the content type, would not that same type of application also be concerned about collisions? <= u>

=C2=A0

As Brendan notes, we are not talking about accidenta= l collisions here. Pre-computation is entirely possible, such as by a malic= ious group member, so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular inter= est to some, then it would be good to see a clarifying explanation as to th= e security it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80= =9D despite introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit f= ield, or can that length be adjusted to mitigate the introduced problems?

=C2=A0

=C2=A0

=C2=A0

A clarifying point for those following this thread: = some references in the email chain state that this is encryption of the epo= ch ID. That is not the case. The proposal being discussed is about a hash t= hereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0

=C2=A0

From: = MLS <mls-bounces@ietf.org> o= n behalf of Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org&g= t;
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions, it&#= 39;s with malicious ones. An attacker can purposefully (and quickly) genera= te commits that create duplicate epoch ids, and send them to a client to co= rrupt their group state.

=C2=A0

I think the idea here is to be conservative by defau= lt.=C2=A0 There are systems in which you can hide the metadata you're t= alking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you'r= e making changes specifically for very niche use-cases where I don't th= ink the security of the whole system has been thought through. Maybe you ha= ve an example in mind, but I can't think of a system where this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <= rlb@ipv.sx> wrote:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion &= lt;brendan@clou= dflare.com> wrote:

With respect to using an opaque epoch id, I believe = this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a bit by= the focus on non-linear epochs.=C2=A0 The point here is that even in a cas= e where you have linear history, I think there's intrinsic value in the= epoch ID being opaque because it gives intermediaries less opportunity for ossification.

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it also= seems to me that this would cause issues because different content types h= ave different delivery guarantees. Specifically: messages are allowed to be= unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and no= t lossy. In the deployment scenarios we've talked about, the DS essenti= ally always needs to know the content type to provide this. Conversely, you= don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id c= hange and infer which message was a commit, or see a dropped message gettin= g re-sent and infer it was a proposal.

=C2=A0

I don't disagree that there are different guaran= tees you need, but like I said, I think the idea here is to be conservative= by default.=C2=A0 There are systems in which you can hide the metadata you= 're talking about with things like mixnets and dropboxes.=C2=A0 Keeping the ciphertext as opaque as possible keeps th= e door open to running MLS over those systems without MLS's own metadat= a undermining their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at building, th= is PR does not make any difference, because clients use separate channels f= or Proposals/Commits vs. application data and the server doesn't check.=

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <r= lb@ipv.sx> wrote:

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an opaque= epoch ID, and (2) encrypt the content type of the message (application / p= roposal / commit) [1].

=C2=A0

There was some discussion on the call last week that= encrypting the content type might not be that useful, since an application= that relies on a server to assure ordering of commits will need to at leas= t be able to tell commits from other things.=C2=A0 Of course, even if the content type is encrypted by default,= the application can add it back in authenticated data, or in some unauthen= ticated wrapper.

=C2=A0

Net of those considerations, I'm personally stil= l inclined to merge the PR, to have a conservative baseline.=C2=A0 But thos= e on the call thought it would be useful to pose this to the group, so plea= se speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

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

--00000000000047773305ab33d00a-- From nobody Fri Jul 24 11:32: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 1B6F93A11C9 for ; Fri, 24 Jul 2020 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=aalto.fi 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 AYo7CoZONx7c for ; Fri, 24 Jul 2020 11:32:08 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 553833A11F0 for ; Fri, 24 Jul 2020 11:32:06 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B480A2715FD_F1B2921B; Fri, 24 Jul 2020 18:32:01 +0000 (GMT) Received: from exng3.org.aalto.fi (exng3.org.aalto.fi [130.233.223.22]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng3.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id 3D9302715D6_F1B2921F; Fri, 24 Jul 2020 18:32:01 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng3.org.aalto.fi (130.233.223.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 24 Jul 2020 21:32:01 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 24 Jul 2020 21:32:00 +0300 To: Richard Barnes CC: Messaging Layer Security WG References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> From: Chris Brzuska Message-ID: <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> Date: Fri, 24 Jul 2020 21:31:53 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9B915FFFFC4A08C1FEF0451F" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng2.org.aalto.fi (130.233.223.21) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:cc:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=N9Z3TnvitWY/Pq068KjsdFuj19bPm2R9eMogIDydgy0=; b=MoN4f5GfgOTaiKNTNju11jDdcZFhFyzz2NLoJPpyx1sCJZk50lLGtRSswxLNiNL44bkDbg3/3LHwK3o9wY4t0FaR1rYTCiAFJF7PEydemcbeAJDvXd+iywxXHMiMxnaBLlYuD9CFMMb/rY/jJjg4PaKqmcAmv+7JLb7HfDYa43YJ/3KYh8FX6wUhz0ur/kvMFGqKupEe4gcNlxd6LsbOL6m+4fNwX0lHjnpcbcKcQ1zctPG5NKIa9Ma+fR1gLOlV+g6vSjpU+MjNJNNNch5SkTrDGu9quJeAgzpbgBFcGi5zlmhTrCXcLqwIaX7TJuqdyTeBGB87IvbU1nWYMqszOg== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 24 Jul 2020 18:32:16 -0000 --------------9B915FFFFC4A08C1FEF0451F Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hey Richard, thank you for looking into this. I think, I need more explanation to understand the following point: >>>  You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret. The current draft sais the following about the PSK: "Groups which already have an out-of-band mechanism to generate *shared* group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries." As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong? Thanks! Chris init_secret_[n-1] (or 0) | V PSK (or 0) -> HKDF-Extract = early_secret | Derive-Secret(., "derived", "") | V commit_secret -> HKDF-Extract = epoch_secret On 24/07/2020 20:53, Richard Barnes wrote: > Hey Chris, > > I was looking again at the key schedule as I was drafting #362 [1].  A > couple of things occurred to me: > > 1. You can't add the commit secret and PSKs in the same operation, > because you want new joiners to put in the PSK, but you don't want > them to have to know the commit secret. > > 2. The nPRF construction you propose has the same number of HMAC > invocations as the chained-HKDF-Extract stuff that's in the current > draft / 362. > > Given those observations, I wonder how much an nPRF is really buying > us.  It's not saving us any HMAC calls, and relative to #362, it would > only coalesce two DPRF calls into one nPRF call. > > Maybe there's some benefit if there are multiple PSKs?  But even then, > it seems like you could add a layer, computing a synthetic PSK from > the multiple ones, and keeping the main key schedule simple. > > At this point, given the above and the novelty of the nPRF > construction, I'm inclined to just stick with HKDF and merge #362 > instead of #336. > > --Richard > > > [1] https://github.com/mlswg/mls-protocol/pull/362 > > On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska > wrote: > > Thank you for the pointer to Carter-Wegman MACs. > > >>> This style of combing hash outputs does affect collision > resistance [4], and some discussion on relation to that would be > nice to see. > > That's an excellent point. In addition to pseudorandomness, we > prove the collision-resistance of our construction. I.e., assuming > that no unique value is used twice and assuming that HMAC is > collision-resistance, then the final Expand operation guarantees > unique outputs. I.e., by including the unique value into the final > Expand operation after the xor, the construction recovers from any > collisions incurred by the xor. > > Chris > > On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >> >> This is an interesting proposal. It is closely related at a high >> level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, >> k2), m) = PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into >> this category in practice. Considering the use of a MAC-based KDF >> and the proofs of [3] on DPRFs, there is an overlap between NPRFs >> and extrapolation of the above (based on iteration of the PRF >> guarantees). >> >> This is worth noting from an assurance standpoint: there was >> discussion at the virtual interims with respect to the current >> formulation of MLS key derivation, which has a “TLS precedence”, >> yet this proposal is not without precedence itself. Ergo, such a >> change should not necessarily be concerning based on differing >> from current practice. >> >> This style of combing hash outputs does affect collision >> resistance [4], and some discussion on relation to that would be >> nice to see. >> >> Britta >> >> [1] Carter, Wegman. Universal classes of hash functions. >> >> [2] Carter, Wegman. New hash functions and their use in >> authentication and set equality. >> >> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from >> Standard Assumptions: A Generic Validation of an HMAC Assumption. >> >> [4] Bernstein. What output size resists collisions in a xor of >> independent expansions? >> >> *From: *MLS >> on behalf of Chris Brzuska >> >> *Date: *Tuesday, June 9, 2020 at 10:32 AM >> *To: *"mls@ietf.org" >> >> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF >> (NPRF) >> >> Hi all, >> >> I would like to open a discussion on a suggestion for a change in >> the key schedule. In the current draft, we use the Extract >> function twice as a dual pseudorandom function (DPRF) when >> combining 3 keys (*) and interleave them with an Expand call. >> >> The suggestion [1] is to replace these 3 calls by a multi-input >> PRF (NPRF) which is especially designed to return a pseudorandom >> key when at least one of the input keys is pseudorandom. The new >> suggestion relies on standard PRF security rather than >> DPRF-security of Extract. >> >> You can find the accompanying paper with pictures, discussion and >> security reduction for the design principle here [2]. I include a >> summary of the main points in the end of this eMail. >> >> Please comment/share your opinion. Thanks! >> >> Chris >> >> (*) commit_secret, PSK and init_secret >> >> [1] Pull Request:https://github.com/mlswg/mls-protocol/pull/337 >> >> >> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >> >> *--------------------------------------------------------------------------------------------------------------------* >> >> *Summary of main points:* >> >> The current key schedule >> - uses Extract as a dual pseudorandom function and assumes that >> HMAC is a dual pseudorandom function >> - applies Extract after Expand, i.e., after applying a function >> which generates a pseudorandom value >> - iterates Extract-then-Expand sequentially to combine more than >> 2 keys >> >> The pull request suggests to >> - replace the ad-hoc assumption that Extract is a dual >> pseudorandom function >> - remove Extract steps when applied after Expand >> - use a provably secure NPRF construction which allows to combine >> more than 2 keys and is based on a standard PRF assumption and >> statistical properties of xor. >> >> Efficiency: >> - The suggested construction has higher parallel efficiency. It >> increases the overall number of HMAC evaluations by 1. >> >> Assumptions: >> - HMAC is a standard PRF. >> - Relies on a unique value, the group_context was suggested. >> >> Construction: >> (1) Use unique value to expand each key and xor the result >> (2) expand resulting key, including unique value into the context >> again >> >> Security argument: >> - Pseudorandomness: unique value ensures that each outcome of >> Expand in (1) is used only once in a xor combination, thus >> allowing on one-time pad argument of xor. >> - Uniqueness of resulting keys: (2) ensures that if HMAC is >> collision-resistent, then the result is collision-resistent. >> >> Variants: >> - It is possible to use an NPRF variant called NameNPRF [2] which >> has 3 HMAC evaluations more and relies less on the unique value. >> I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only >> repeat if the input keys repeat *and* the group context repeats. >> >> Questions/Comments that came up: >> - Barnes, MacMillion suggested group_context as unique value >> - MacMillion wondered about removal of Extract: One can add an >> extract operation for the psk. For other input keys, it does not >> seem needed, since they were returned from Expand. >> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness >> of output keys, the PRF needs to be collision-resistant, too. >> >> >> _______________________________________________ >> 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 > --------------9B915FFFFC4A08C1FEF0451F Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>  You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris


               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract = early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract = epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].  A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.  It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?  But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
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
--------------9B915FFFFC4A08C1FEF0451F-- From nobody Fri Jul 24 11:48:21 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 3F48C3A045B for ; Fri, 24 Jul 2020 11:48:18 -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 2XkKCIE8hvdp for ; Fri, 24 Jul 2020 11:48:15 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 7F5323A043E for ; Fri, 24 Jul 2020 11:48:14 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id e3so4544354qvo.10 for ; Fri, 24 Jul 2020 11:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ijnr6yEf6Fe2t61Spns3j2iHxF6QED3Lb5eAFY7gfDM=; b=XGwT+i7hPJ86SUlDQu7hxvtV5nTviaroQPcBuUhNltndH749sxJFhIzM9eTwFibGJ0 gXmQTZCtSmwwoPv9LmetsesrPo6St+YjiixdOKPDCPmeFrQKSafHOrNcXw27q37aEpd5 EmWgZHxAoSu2KsHw6BGwd+YFNfk+Y4ooXvkfXU4DBTsi4YCX9gYP396aK9mbbUAArqXs o8gRcWq7lGFXMNg9tjDr6zqveD0fG6FFBqt0XN4YD7uoBq49DH/DCEsg7p6w7cZueEpK qhw5rT1YvPyYMmIj728L6cTfJWlUVE15sU1HVmWz2fNW5sGxFPZuTzHyfKmOiadRsT8c aoyw== 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=Ijnr6yEf6Fe2t61Spns3j2iHxF6QED3Lb5eAFY7gfDM=; b=pGIIE1XKBIE/SYjSIZ3tCHKwXHLCmIMnHQtBVf2M1dH84wsdFICpJdvPKyR2SUfRaR OkbRFPm8xm6k2YVHwiNzgKpO2fzGe/74H9j4KqvqxX8GH0MSEXcBKpmECEwVzlubeFjP +yZiOCLjDBxJlGYmIzB9ZoUFcJSPq01H5EuXcodTs7vsfNWgsg+putu/vUpX7Q50w3Rn gfD9z03uAVHbphQ8vbSeZFz9nNrxsHtvRckciXpO9guO6RTZjPDi+XmNEtI1akP11s84 5ctMjiN7hMHxwqB1tWi+SrTjOpD+c3+7vBbHN6BWsuItor210sn5r9p4jIw+TngdIU96 BFVQ== X-Gm-Message-State: AOAM533z+PMzaQqz6mJJSiRq09FZHmw30UAFt4deNXfesHYwmuKrvEEx 5i1T0xdm8iBF78UJlfrv6/kGu8PrbK443AJaQ8ocDQU3PvDovQ== X-Google-Smtp-Source: ABdhPJxN7dTS2v6E5dlygM2D/kt7j5ffcHEbmAO+glZI8+QGAO6CRGf73LwGpj0HwST6qvtWlEUYrPXuH/8UPumN2J0= X-Received: by 2002:a0c:8643:: with SMTP id p61mr11426380qva.43.1595616493030; Fri, 24 Jul 2020 11:48:13 -0700 (PDT) MIME-Version: 1.0 References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> In-Reply-To: <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> From: Richard Barnes Date: Fri, 24 Jul 2020 14:47:46 -0400 Message-ID: To: Chris Brzuska Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000043e81f05ab346a76" Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 24 Jul 2020 18:48:19 -0000 --00000000000043e81f05ab346a76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your confusion is understandable -- the document is wrong right now! You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature. The epoch secret should verify that *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch. That's why #362 rearranges the key schedule as follows: init_secret_[n-1] (or 0) | V commit_secret -> HKDF-Extract =3D joiner_secret | +--> Derive-Secret(., "welcome") | =3D welcome_secret | V PSK (or 0) -> HKDF-Extract =3D member_secret | V GroupContext_[n] -> HKDF-Extract =3D epoch_secret (I also promoted the GroupContext to the main key schedule.) That's the context for my earlier comments. With that picture, the only thing you're coalescing with nPRF would be the latter two HKDF-Extract calls. Hope that helps, --Richard On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska wrote: > Hey Richard, > > thank you for looking into this. I think, I need more explanation to > understand the following point: > >>> You can't add the commit secret and PSKs in the same operation, > because you want new joiners to put in the PSK, but you don't want them t= o > have to know the commit secret. > > The current draft sais the following about the PSK: > "Groups which already have an out-of-band mechanism to generate *shared* > group secrets can inject those in the MLS key schedule to seed the MLS > group secrets computations by this external entropy. At any epoch, > including the initial state, an application can decide to synchronize the > injection of a PSK into the MLS key schedule. This mechanism can be used = to > improve security in the cases where having a full run of updates across > members is too expensive or in the case where the external group key > establishment mechanism provides stronger security against classical or > quantum adversaries." > > As I understand this paragraph, the PSK is known by all group members and > not related to new joiners. Maybe, the requirements and/or design changed > in the meanwhile, and I am not aware of it. I interpreted the paragraph > this way, since the current construction (posted below for convenience) > also requires to know the commit_secret to derive the epoch_secret (from > which the welcome_secret is derived). Where did I go wrong? > > Thanks! > > Chris > > init_secret_[n-1] (or 0) > | > V > PSK (or 0) -> HKDF-Extract =3D early_secret > | > Derive-Secret(., "derived", "") > | > V > commit_secret -> HKDF-Extract =3D epoch_secret > > > On 24/07/2020 20:53, Richard Barnes wrote: > > Hey Chris, > > I was looking again at the key schedule as I was drafting #362 [1]. A > couple of things occurred to me: > > 1. You can't add the commit secret and PSKs in the same operation, becaus= e > you want new joiners to put in the PSK, but you don't want them to have t= o > know the commit secret. > > 2. The nPRF construction you propose has the same number of HMAC > invocations as the chained-HKDF-Extract stuff that's in the current draft= / > 362. > > Given those observations, I wonder how much an nPRF is really buying us. > It's not saving us any HMAC calls, and relative to #362, it would only > coalesce two DPRF calls into one nPRF call. > > Maybe there's some benefit if there are multiple PSKs? But even then, it > seems like you could add a layer, computing a synthetic PSK from the > multiple ones, and keeping the main key schedule simple. > > At this point, given the above and the novelty of the nPRF construction, > I'm inclined to just stick with HKDF and merge #362 instead of #336. > > --Richard > > > [1] https://github.com/mlswg/mls-protocol/pull/362 > > On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska > wrote: > >> Thank you for the pointer to Carter-Wegman MACs. >> >> >>> This style of combing hash outputs does affect collision resistance >> [4], and some discussion on relation to that would be nice to see. >> >> That's an excellent point. In addition to pseudorandomness, we prove the >> collision-resistance of our construction. I.e., assuming that no unique >> value is used twice and assuming that HMAC is collision-resistance, then >> the final Expand operation guarantees unique outputs. I.e., by including >> the unique value into the final Expand operation after the xor, the >> construction recovers from any collisions incurred by the xor. >> >> Chris >> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >> >> This is an interesting proposal. It is closely related at a high level t= o >> Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D PRF(k1= , r) >> XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. >> Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, >> there is an overlap between NPRFs and extrapolation of the above (based = on >> iteration of the PRF guarantees). >> >> >> >> This is worth noting from an assurance standpoint: there was discussion >> at the virtual interims with respect to the current formulation of MLS k= ey >> derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet this propo= sal is not without >> precedence itself. Ergo, such a change should not necessarily be concern= ing >> based on differing from current practice. >> >> >> >> This style of combing hash outputs does affect collision resistance [4], >> and some discussion on relation to that would be nice to see. >> >> >> >> Britta >> >> >> >> >> >> >> >> [1] Carter, Wegman. Universal classes of hash functions. >> >> [2] Carter, Wegman. New hash functions and their use in authentication >> and set equality. >> >> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard >> Assumptions: A Generic Validation of an HMAC Assumption. >> >> [4] Bernstein. What output size resists collisions in a xor of >> independent expansions? >> >> >> >> >> >> >> >> *From: *MLS on behalf of >> Chris Brzuska >> *Date: *Tuesday, June 9, 2020 at 10:32 AM >> *To: *"mls@ietf.org" >> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) >> >> >> >> Hi all, >> >> I would like to open a discussion on a suggestion for a change in the ke= y >> schedule. In the current draft, we use the Extract function twice as a d= ual >> pseudorandom function (DPRF) when combining 3 keys (*) and interleave th= em >> with an Expand call. >> >> The suggestion [1] is to replace these 3 calls by a multi-input PRF >> (NPRF) which is especially designed to return a pseudorandom key when at >> least one of the input keys is pseudorandom. The new suggestion relies o= n >> standard PRF security rather than DPRF-security of Extract. >> >> You can find the accompanying paper with pictures, discussion and >> security reduction for the design principle here [2]. I include a summar= y >> of the main points in the end of this eMail. >> >> Please comment/share your opinion. Thanks! >> >> Chris >> >> (*) commit_secret, PSK and init_secret >> >> [1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337 >> >> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >> >> >> *-----------------------------------------------------------------------= ---------------------------------------------* >> >> *Summary of main points:* >> >> The current key schedule >> - uses Extract as a dual pseudorandom function and assumes that HMAC is = a >> dual pseudorandom function >> - applies Extract after Expand, i.e., after applying a function which >> generates a pseudorandom value >> - iterates Extract-then-Expand sequentially to combine more than 2 keys >> >> The pull request suggests to >> - replace the ad-hoc assumption that Extract is a dual pseudorandom >> function >> - remove Extract steps when applied after Expand >> - use a provably secure NPRF construction which allows to combine more >> than 2 keys and is based on a standard PRF assumption and statistical >> properties of xor. >> >> Efficiency: >> - The suggested construction has higher parallel efficiency. It increase= s >> the overall number of HMAC evaluations by 1. >> >> Assumptions: >> - HMAC is a standard PRF. >> - Relies on a unique value, the group_context was suggested. >> >> Construction: >> (1) Use unique value to expand each key and xor the result >> (2) expand resulting key, including unique value into the context again >> >> Security argument: >> - Pseudorandomness: unique value ensures that each outcome of Expand in >> (1) is used only once in a xor combination, thus allowing on one-time pa= d >> argument of xor. >> - Uniqueness of resulting keys: (2) ensures that if HMAC is >> collision-resistent, then the result is collision-resistent. >> >> Variants: >> - It is possible to use an NPRF variant called NameNPRF [2] which has 3 >> HMAC evaluations more and relies less on the unique value. I.e., NameNPR= F >> is secure in the same scenarios as DPRF: Keys only repeat if the input k= eys >> repeat *and* the group context repeats. >> >> Questions/Comments that came up: >> - Barnes, MacMillion suggested group_context as unique value >> - MacMillion wondered about removal of Extract: One can add an extract >> operation for the psk. For other input keys, it does not seem needed, si= nce >> they were returned from Expand. >> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of >> output keys, the PRF needs to be collision-resistant, too. >> >> _______________________________________________ >> MLS mailing listMLS@ietf.orghttps://www.ietf.org/mailman/listinfo/mls >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --00000000000043e81f05ab346a76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your confusion is understandable -- the document is w= rong right now!=C2=A0 You are correct that the current design prohibits new= joiners from participating in the PSK proof, but that's a bug, not a f= eature.=C2=A0 The epoch secret should verify that *all members of the curre= nt epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as f= ollows:

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 init_secret_[n-= 1] (or 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0commit_secret -> H= KDF-Extract =3D joiner_secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--> Derive-Secr= et(., "welcome")
=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=3D welcome_secret=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0 =C2=A0 PSK (or 0) -> HKDF-Ex= tract =3D member_secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V
GroupContext_[n] -&g= t; HKDF-Extract =3D epoch_secret

(I also pr= omoted the GroupContext to the main key schedule.)=C2=A0 That's the con= text for my earlier comments.=C2=A0 With that picture, the only thing you&#= 39;re coalescing with nPRF would be the latter two HKDF-Extract calls.
<= /div>

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:<= br>
=20 =20 =20

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>=C2=A0 You can't add the commit secret and PSKs in the = same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to genera= te shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

=
               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract =3D early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract =3D epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
=20
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].=C2=A0 A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.=C2=A0 It's not saving us any HMAC calls, an= d relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?=C2= =A0 But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 A= M Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D=C2=A0 PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

=C2=A0

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a =E2=80=9CT= LS precedence=E2=80=9D, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

=C2=A0

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

=C2=A0

Britta

=C2=A0

=C2=A0

=C2=A0

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare an= d Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

=C2=A0

=C2=A0

=C2=A0

From: MLS= <mls-bounces@= ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <= ;mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

=C2=A0

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

-----------------------------------------------------= ---------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
MLS mailing list
MLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000043e81f05ab346a76-- From nobody Fri Jul 24 12:18:17 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 9FE363A091C for ; Fri, 24 Jul 2020 12:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=aalto.fi 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 TPufQD9KceEC for ; Fri, 24 Jul 2020 12:18:11 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 6E0BF3A091B for ; Fri, 24 Jul 2020 12:18:10 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id EA30611566E_F1B33EDB; Fri, 24 Jul 2020 19:18:05 +0000 (GMT) Received: from exng4.org.aalto.fi (exng4.org.aalto.fi [130.233.223.23]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng4.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 67F7611553A_F1B33EDF; Fri, 24 Jul 2020 19:18:05 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng4.org.aalto.fi (130.233.223.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 24 Jul 2020 22:18:05 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 24 Jul 2020 22:18:04 +0300 To: Richard Barnes CC: Messaging Layer Security WG References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> From: Chris Brzuska Message-ID: <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> Date: Fri, 24 Jul 2020 22:18:03 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------21387090B51100973E85BCF1" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng3.org.aalto.fi (130.233.223.22) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:cc:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=O+O/xDHsbA59rSOtjcEvEr6T6pczIDhpuqO81EILk08=; b=PHKxanpQp/xi9TEASRyvS9KM9zy9b/OheX56O4zG2vZtaMDeC9mUV04WjbzzvK+sqs6fNICTUjQoQq0rJ/nf2vjuCM/SEdLiR+yIfVTps8Uldxi1ZAEt7gU4NSdmBtzOk0ZvQISR6L+mogsagusnhnHd0KgeWIbeUOhgI3D4Q+vG4RVisFfVVtpxhF8+iDtqHanbRbQ8ONl8ZpgRWMjxHiXXfBVY6zDWI4YlJEbq/lvRCymY2AQO2xjwhDZbTxsKJ6PJyN9Wfe/zfAaCzz0hWr49xYHXNNrqZj0AmEmllf6fMAFw28dmf18ThzJHGLw/Fr0jGtq3pQ0r4vk/IvuV4g== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 24 Jul 2020 19:18:15 -0000 --------------21387090B51100973E85BCF1 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first. Will think about it, thanks for clarifying the requirements! Chris On 24/07/2020 21:47, Richard Barnes wrote: > Your confusion is understandable -- the document is wrong right now!  > You are correct that the current design prohibits new joiners from > participating in the PSK proof, but that's a bug, not a feature.  The > epoch secret should verify that *all members of the current epoch* > know the PSK, not just the ones inherited from the last epoch. > > That's why #362 rearranges the key schedule as follows: > > init_secret_[n-1] (or 0) >                         | >                         V >    commit_secret -> HKDF-Extract = joiner_secret >                         | >                         +--> Derive-Secret(., "welcome") >                         |    = welcome_secret >                         | >                         V >       PSK (or 0) -> HKDF-Extract = member_secret >                         | >                         V > GroupContext_[n] -> HKDF-Extract = epoch_secret > > (I also promoted the GroupContext to the main key schedule.)  That's > the context for my earlier comments.  With that picture, the only > thing you're coalescing with nPRF would be the latter two HKDF-Extract > calls. > > Hope that helps, > --Richard > > > > On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska > wrote: > > Hey Richard, > > thank you for looking into this. I think, I need more explanation > to understand the following point: > > >>>  You can't add the commit secret and PSKs in the same > operation, because you want new joiners to put in the PSK, but you > don't want them to have to know the commit secret. > > The current draft sais the following about the PSK: > "Groups which already have an out-of-band mechanism to generate > *shared* group secrets can inject those in the MLS key schedule to > seed the MLS group secrets computations by this external entropy. > At any epoch, including the initial state, an application can > decide to synchronize the injection of a PSK into the MLS key > schedule. This mechanism can be used to improve security in the > cases where having a full run of updates across members is too > expensive or in the case where the external group key > establishment mechanism provides stronger security against > classical or quantum adversaries." > > As I understand this paragraph, the PSK is known by all group > members and not related to new joiners. Maybe, the requirements > and/or design changed in the meanwhile, and I am not aware of it. > I interpreted the paragraph this way, since the current > construction (posted below for convenience) also requires to know > the commit_secret to derive the epoch_secret (from which the > welcome_secret is derived). Where did I go wrong? > > Thanks! > > Chris > > init_secret_[n-1] (or 0) > | > V > PSK (or 0) -> HKDF-Extract = early_secret > | > Derive-Secret(., "derived", "") > | > V > commit_secret -> HKDF-Extract = epoch_secret > > > On 24/07/2020 20:53, Richard Barnes wrote: >> Hey Chris, >> >> I was looking again at the key schedule as I was drafting #362 >> [1].  A couple of things occurred to me: >> >> 1. You can't add the commit secret and PSKs in the same >> operation, because you want new joiners to put in the PSK, but >> you don't want them to have to know the commit secret. >> >> 2. The nPRF construction you propose has the same number of HMAC >> invocations as the chained-HKDF-Extract stuff that's in the >> current draft / 362. >> >> Given those observations, I wonder how much an nPRF is really >> buying us.  It's not saving us any HMAC calls, and relative to >> #362, it would only coalesce two DPRF calls into one nPRF call. >> >> Maybe there's some benefit if there are multiple PSKs?  But even >> then, it seems like you could add a layer, computing a synthetic >> PSK from the multiple ones, and keeping the main key schedule simple. >> >> At this point, given the above and the novelty of the nPRF >> construction, I'm inclined to just stick with HKDF and merge #362 >> instead of #336. >> >> --Richard >> >> >> [1] https://github.com/mlswg/mls-protocol/pull/362 >> >> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >> > wrote: >> >> Thank you for the pointer to Carter-Wegman MACs. >> >> >>> This style of combing hash outputs does affect collision >> resistance [4], and some discussion on relation to that would >> be nice to see. >> >> That's an excellent point. In addition to pseudorandomness, >> we prove the collision-resistance of our construction. I.e., >> assuming that no unique value is used twice and assuming that >> HMAC is collision-resistance, then the final Expand operation >> guarantees unique outputs. I.e., by including the unique >> value into the final Expand operation after the xor, the >> construction recovers from any collisions incurred by the xor. >> >> Chris >> >> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>> >>> This is an interesting proposal. It is closely related at a >>> high level to Carter-Wegman MACs (i.e. for random seed r, >>> MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few >>> MACs fall into this category in practice. Considering the >>> use of a MAC-based KDF and the proofs of [3] on DPRFs, there >>> is an overlap between NPRFs and extrapolation of the above >>> (based on iteration of the PRF guarantees). >>> >>> This is worth noting from an assurance standpoint: there was >>> discussion at the virtual interims with respect to the >>> current formulation of MLS key derivation, which has a “TLS >>> precedence”, yet this proposal is not without precedence >>> itself. Ergo, such a change should not necessarily be >>> concerning based on differing from current practice. >>> >>> This style of combing hash outputs does affect collision >>> resistance [4], and some discussion on relation to that >>> would be nice to see. >>> >>> Britta >>> >>> [1] Carter, Wegman. Universal classes of hash functions. >>> >>> [2] Carter, Wegman. New hash functions and their use in >>> authentication and set equality. >>> >>> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from >>> Standard Assumptions: A Generic Validation of an HMAC >>> Assumption. >>> >>> [4] Bernstein. What output size resists collisions in a xor >>> of independent expansions? >>> >>> *From: *MLS >>> on behalf of Chris Brzuska >>> >>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>> *To: *"mls@ietf.org" >>> >>> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input >>> PRF (NPRF) >>> >>> Hi all, >>> >>> I would like to open a discussion on a suggestion for a >>> change in the key schedule. In the current draft, we use the >>> Extract function twice as a dual pseudorandom function >>> (DPRF) when combining 3 keys (*) and interleave them with an >>> Expand call. >>> >>> The suggestion [1] is to replace these 3 calls by a >>> multi-input PRF (NPRF) which is especially designed to >>> return a pseudorandom key when at least one of the input >>> keys is pseudorandom. The new suggestion relies on standard >>> PRF security rather than DPRF-security of Extract. >>> >>> You can find the accompanying paper with pictures, >>> discussion and security reduction for the design principle >>> here [2]. I include a summary of the main points in the end >>> of this eMail. >>> >>> Please comment/share your opinion. Thanks! >>> >>> Chris >>> >>> (*) commit_secret, PSK and init_secret >>> >>> [1] Pull >>> Request:https://github.com/mlswg/mls-protocol/pull/337 >>> >>> >>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>> >>> *--------------------------------------------------------------------------------------------------------------------* >>> >>> *Summary of main points:* >>> >>> The current key schedule >>> - uses Extract as a dual pseudorandom function and assumes >>> that HMAC is a dual pseudorandom function >>> - applies Extract after Expand, i.e., after applying a >>> function which generates a pseudorandom value >>> - iterates Extract-then-Expand sequentially to combine more >>> than 2 keys >>> >>> The pull request suggests to >>> - replace the ad-hoc assumption that Extract is a dual >>> pseudorandom function >>> - remove Extract steps when applied after Expand >>> - use a provably secure NPRF construction which allows to >>> combine more than 2 keys and is based on a standard PRF >>> assumption and statistical properties of xor. >>> >>> Efficiency: >>> - The suggested construction has higher parallel efficiency. >>> It increases the overall number of HMAC evaluations by 1. >>> >>> Assumptions: >>> - HMAC is a standard PRF. >>> - Relies on a unique value, the group_context was suggested. >>> >>> Construction: >>> (1) Use unique value to expand each key and xor the result >>> (2) expand resulting key, including unique value into the >>> context again >>> >>> Security argument: >>> - Pseudorandomness: unique value ensures that each outcome >>> of Expand in (1) is used only once in a xor combination, >>> thus allowing on one-time pad argument of xor. >>> - Uniqueness of resulting keys: (2) ensures that if HMAC is >>> collision-resistent, then the result is collision-resistent. >>> >>> Variants: >>> - It is possible to use an NPRF variant called NameNPRF [2] >>> which has 3 HMAC evaluations more and relies less on the >>> unique value. I.e., NameNPRF is secure in the same scenarios >>> as DPRF: Keys only repeat if the input keys repeat *and* the >>> group context repeats. >>> >>> Questions/Comments that came up: >>> - Barnes, MacMillion suggested group_context as unique value >>> - MacMillion wondered about removal of Extract: One can add >>> an extract operation for the psk. For other input keys, it >>> does not seem needed, since they were returned from Expand. >>> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For >>> uniqueness of output keys, the PRF needs to be >>> collision-resistant, too. >>> >>> >>> _______________________________________________ >>> 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 >> --------------21387090B51100973E85BCF1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first.

Will think about it, thanks for clarifying the requirements!

Chris

On 24/07/2020 21:47, Richard Barnes wrote:
Your confusion is understandable -- the document is wrong right now!  You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature.  The epoch secret should verify that *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as follows:

                  init_secret_[n-1] (or 0)
                        |
                        V
   commit_secret -> HKDF-Extract = joiner_secret
                        |
                        +--> Derive-Secret(., "welcome")
                        |    = welcome_secret
                        |
                        V
      PSK (or 0) -> HKDF-Extract = member_secret
                        |
                        V
GroupContext_[n] -> HKDF-Extract = epoch_secret

(I also promoted the GroupContext to the main key schedule.)  That's the context for my earlier comments.  With that picture, the only thing you're coalescing with nPRF would be the latter two HKDF-Extract calls.

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>  You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract = early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract = epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].  A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.  It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?  But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
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
--------------21387090B51100973E85BCF1-- From nobody Fri Jul 24 15:39: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 0BE243A09F7 for ; Fri, 24 Jul 2020 15:39:54 -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 e1BeTN7TkaX5 for ; Fri, 24 Jul 2020 15:39:51 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC37C3A09F1 for ; Fri, 24 Jul 2020 15:39:50 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id s23so8035721qtq.12 for ; Fri, 24 Jul 2020 15:39:50 -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=AjU5XPHY9kGTaMknZ/a6mYVCCwC7CSRVbOqqgsr19M4=; b=e4ObzVvqmK9DYDmKCVDobvJStTpCdcdMkc+9tRAG/OdJrxDyLb3/RJHnZnqE+j6SKC f9u1Ia4GXfmE+YoQ8dco7gf3OhpvSa52YHwRUac44WiyGRGSO2+0naNQZuJuPQIsw9Ro UH86RKIrXtHZ48lPU4wnRuHSaBDuERXPp+s+90BafiI2kaNltZe03ycptLu/aEksVOYl qKvTDKJLqvJWX1Ep8FnxC5UoDouZf71kPI8D0JrpuwunGfepENSjtxPlaZw6PnltCiRZ AzDfbZ2bv+dMJXVS2q1ta4SQFPUS+qv4kTvu6HBzgFGZ3BbtRUh0t1EMsFHhIgflgFQr n/tA== 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=AjU5XPHY9kGTaMknZ/a6mYVCCwC7CSRVbOqqgsr19M4=; b=G39fDTMz+wqcXpd802h6Ey57k2MMJRJ5HuRi4tXYbASfIjVsNYCFhXeXwUq9RAIjsq W4j6jI049o66eCY9TqQrttVZ8XGr1U5eCX1IzuB602bvc5dX2y69u+Y3v1OMV/9IjBPI UBU/kqm4N3ziNzRGf62P0qa1AcQ1jmyVLJkgZcWr7Fw2rM5dxq0IKfzbZLXIiXSPK/Tx c4sq+8G5OE7kTIYr3WCdoLrgmBGp/0NvB4+NhLZHxAqi7eEcSRhbBhPys1XKHcPQol2Y XQ28m19ODSBjVstM+wZU2Q8z6Fr2E8Ob9xJRb10Md80qVPdmv3cmPR3GZ5VacFwZbEMI cfNg== X-Gm-Message-State: AOAM531sNVFj1yKXDM6VC1MW7Ax+9alPX3nvgyNFoBbEiBJ+mcaX4yfT scVc36D1t6uHnGQe9B2EiiW6Y2n0NT3A9ASiRp3YhIAf/QtF1w== X-Google-Smtp-Source: ABdhPJx+zQBY7G03c/tuj/6BLuK4VGXI1APMIUPEJT/1KQtMCuKYfNMIPMkTputNz3Dw6GAoLvBUkzjvfk8CgBxOBhg= X-Received: by 2002:ac8:387b:: with SMTP id r56mr11776802qtb.353.1595630389498; Fri, 24 Jul 2020 15:39:49 -0700 (PDT) MIME-Version: 1.0 References: <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> In-Reply-To: From: Richard Barnes Date: Fri, 24 Jul 2020 18:39:22 -0400 Message-ID: To: Konrad Kohbrok Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000008f2b9c05ab37a643" Archived-At: Subject: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) 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, 24 Jul 2020 22:39:54 -0000 --0000000000008f2b9c05ab37a643 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Picking this thread back up: I tried to encapsulate my approach to the issues here in a few GitHub issues and one PR: Reorder key schedule inputs https://github.com/mlswg/mls-protocol/issues/362 Add extensions to the Commit message https://github.com/mlswg/mls-protocol/issues/366 Negotiate PSKs https://github.com/mlswg/mls-protocol/issues/367 Proof of prior membership in the group / Resumption https://github.com/mlswg/mls-protocol/issues/368 Konrad / Britta - I think those combine to cover the cases you were trying to address in #366, but tease the issues apart a bit more clearly. Does that make sense to you? What have I missed here? If this general plan looks good, I think we can get the details arranged and agreed fairly quickly, as these are each pretty self-contained pieces of work. Thanks, --Richard On Tue, Jul 14, 2020 at 12:37 PM Konrad Kohbrok < konrad.kohbrok@datashrine.de> wrote: > We just briefly touched upon this PR in the virtual interim on July 14th > and I > think we agreed that the discussion should be continued on the mailinglis= t > and > then tied up at the IETF 108 meeting. > > I think continuing the discussion on the mailinglist is a good idea, > however, > neither Britta nor myself are going to be present at the IETF 108 meeting= . > Maybe > we can push the discussion to the next virtual interim meeting instead? > > Cheers, > Konrad > > > On 18.06.20 16:29, Konrad Kohbrok wrote: > > Hi, > > > > Just a small addition to Britta's response: > > > > For #3: We already mandate that the parent group must not be used > anymore if a > > Re-Init proposal is included in a commit in lines 2341-2342 of the PR > (although > > "to send messages" might as well be removed). We could also get rid of > the > > proposal and simply have the intent to re-initialize be implicit in > sending a > > Welcome message with a corresponding PSK Id. The idea behind the > Proposal was to > > make that intent explicit such that the intent, as well as the target > > ciphersuite and MLS version are all entered into the transcript and thu= s > agreed > > upon. Even though the group is terminated after the proposal is > received, this > > agreement can be verified by using the authentication key technique tha= t > Britta > > proposed, i.e. each party can check that their authentication key > corresponds to > > the one the committer uploaded. > > > > I'm also ok with splitting it into multiple individual PRs if that make= s > it > > easier to review and discuss. > > > > Cheers, > > Konrad > > > > > > On 18.06.20 04:07, Hale, Britta (CIV) wrote: > >> Hi Richard, > >> > >> > >> > >> Thank you for the comments and careful read of the PR. > >> > >> > >> > >> For #1/#2: I am amicable to the idea of adding an extension field to > the commit > >> message. As a general comment, we may want to consider if there are > other types > >> of commit extensions worth adding or, alternatively, how the field may > be abused > >> (e.g. treated as AD by an application). > >> > >> It terms of objection to the current form though, your argument is not > clear. > >> PSKIds should uniquely identify PSKs, and a joiner (or anyone) should > be able to > >> identify the correct PSK given the PSKId, if they are in possession of > it. PSKs > >> must only be used in an Add if the joiner is a past group member (line > 2055) and > >> therefore has the correct PSKId/group_id/psk_epoch, although this is > nullified > >> if we make the change discussed in #4. In that case, the issue for Add= s > goes away. > >> > >> The PR already allows for a PSK in the Welcome message. > >> > >> > >> > >> For #3: Currently, in the PR, there is a recovery_secret derived > per-epoch. When > >> a member wants to re-initialize, they issue a Re-Init proposal. They > may then > >> re-initialize the group by sending a Welcome message (see lines 1923, > 1948, and > >> 2349) with the PSKId for the parent group/epoch and a psktype that > indicates > >> that they are re-initializing the group with the stated PSKId. So this > seems to > >> already be what you describe below as =E2=80=9Chave the initiator of t= he child > send a > >> Welcome that has a pointer back to the parent=E2=80=9D. However, you a= re right > that more > >> detail can be added; in particular a requirement should be added to > terminate > >> the parent group and that the terminating member/re-init proposer must > also > >> create the new group. > >> > >> > >> > >> For #4: There was a discussion at the first virtual interim in late > April > >> (Interim #11-2020) wherein some expressed a desire for this feature. > Namely, > >> instead of re-syncing the entire group, there were use cases for > re-syncing the > >> odd member when necessary. Its inclusion in the PR arises from that > later > >> request. I am favorable to removing it since, from security standpoint= , > it is > >> not ideal. However, the motivation for this was pushed from the > implementation > >> standpoint. Consequently, now is a good time for anyone to speak up wh= o > wants to > >> push for this. > >> > >> > >> > >> > >> > >> One item: you made point of specifically requesting =E2=80=93 a few ti= mes =E2=80=93 at > the > >> virtual interims #11 and #12 in April/May that this PSK PR and as many > other key > >> schedule-related PRs be combined into a single one. Raphael made a > similar > >> request under git issue #325. In fact, the authors of this PR had > pushed back on > >> that insistence to limit the current PR down to the items it currently > covers, > >> instead of merging in other key schedule changes as well. Are you > saying that > >> you have changed your mind? > >> > >> We can, of course, accommodate a revised preference if needed. > >> > >> > >> > >> > >> > >> Britta > >> > >> > >> > >> > >> > >> > >> > >> *From: *MLS on behalf of Richard Barnes > > >> *Date: *Wednesday, June 17, 2020 at 3:54 PM > >> *To: *Messaging Layer Security WG > >> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group > Branching (#336) > >> > >> > >> > >> Hey all, > >> > >> Sorry for the late review on this PR, I have finally gotten a chance t= o > really > >> dig into it, and ... I have some concerns. My current thinking is > consistent > >> with my earlier comments that the general thrust of this PR is OK. Bu= t > I think > >> the actual approach needs to change a fair bit. > >> > >> As its title implies, this PR is trying to do several things at once, > which seem > >> to me to be fairly separable: > >> > >> 0. Update the key schedule so that PSKs are injected at the right poin= t > and > >> multiple PSKs are supported > >> 1. Signal that a PSK should get injected into a given epoch > >> 2. Request injection of PSK at join / in Welcome > >> 3. Re-initialize the group with different parameters > >> 4. Re-sync group members that have lost state > >> > >> For the most part, I think these are worthwhile goals, but they should > be > >> accomplished in different ways than the PR proposes. Detailed thought= s > by > >> objective: > >> > >> > >> # 0. Update the key schedule so that PSKs are injected at the right > point and > >> multiple PSKs are supported > >> > >> This part of the PR is fine, but I think is ultimately done a bit more > elegantly > >> with the n-PRF stuff in #337. > >> > >> > >> # 1. Signal that a PSK should get injected into a given epoch > >> # 2. Request injection of PSK at join / in Welcome > >> > >> (These go together) > >> > >> The PR proposes (heh) an EPSK proposal or an Add proposal, but then > requires > >> that only one EPSK be used. I actually don't the proposal for > including PSKs in > >> Adds actually works. The joiner would have to know all of them plus > the EPSK, > >> and there's not even any syntax in the PR to tell the joiner which one= s > to include. > >> > >> I would propose that instead we add an extensions field to the Commit > message, > >> then add a Commit extension that specifies the PSK ID for the PSK to b= e > added. > >> That extension can then also go in the Welcome message corresponding t= o > the > >> commit, so that joiners know to add the PSK. > >> > >> This change actually doesn't make a difference in terms of what ends u= p > in the > >> transcript -- either way, only the PSK ID selected by the committer > goes in the > >> transcript. It seems better not to deliberately have proposals > floating around > >> that never get included in the transcript. > >> > >> > >> # 3. Re-initialize the group with different parameters > >> > >> The PR proposes another proposal type for reinitialization, but it's > really > >> under-specified what you do to re-init. For example, what goes in the > ratchet > >> tree? Clearly you need a brand new tree, since the one you have might > be tied > >> to the wrong ciphersuite. What you really need is something like a > Welcome message. > >> > >> And that's how I think we should actually arrange things. Instead of > having the > >> parent group do something to spawn, have the initiator of the child > send a > >> Welcome that has a pointer back to the parent. So we have another > Welcome > >> extension (`parent_group`, say) that has a pointer to the parent group > by group > >> ID and epoch, and instructs the joiner to take a secret from that > group/epoch's > >> key schedule and add it into the new group's key schedule. > >> > >> > >> > >> # 4. Re-sync group members that have lost state > >> > >> We should not do these. At the January interim, we decided not to dro= p > the > >> resync issue (#93) given that there were some subtleties depending on > exactly > >> what state had been lost, and that it could be cleanly done in a > separate spec. > >> > >> > >> # Conclusions > >> > >> Given the above, I would propose we break this into separate issues to > be closed > >> with individual, smaller PRs. Assuming that (0) will get addressed by > the n-PRF > >> PR, that leaves us with: > >> > >> #XXX Add Extensions to the Commit message > >> #XXX Signal use of external PSKs in Commit/Welcome (=3D> extension to > >> Commit/Welcome messages) > >> #XXX Allow Welcome to signal the inclusion of information from a prior > group (=3D> > >> Welcome extension) > >> > >> Happy to write those up, and contribute to PRs. Sorry again for the > slow > >> progress here. > >> > >> --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 > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000008f2b9c05ab37a643 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Picking this thread back up:

I tried to encapsulate my approach to the issues here in a few GitHub issu= es and one PR:

Reorder key schedule inputs
https://git= hub.com/mlswg/mls-protocol/issues/362

Add exte= nsions to the Commit message


Proof of prior membership in = the group / Resumption
https://github.com/mlswg/mls-protocol/issues/368

Konrad / Britta - I think those combine to cover the = cases you were trying to address in #366, but tease the issues apart a bit = more clearly.=C2=A0 Does that make sense to you?=C2=A0 What have I missed h= ere?=C2=A0 If this general plan looks good, I think we can get the details = arranged and agreed fairly quickly, as these are each pretty self-contained= pieces of work.

Thanks,
--Richard

On Tue, Jul 14, 2020 at 12:37 PM Konrad Kohbrok <konrad.kohbrok@datashrine.de> wrote:
We just briefly to= uched upon this PR in the virtual interim on July 14th and I
think we agreed that the discussion should be continued on the mailinglist = and
then tied up at the IETF 108 meeting.

I think continuing the discussion on the mailinglist is a good idea, howeve= r,
neither Britta nor myself are going to be present at the IETF 108 meeting. = Maybe
we can push the discussion to the next virtual interim meeting instead?

Cheers,
Konrad


On 18.06.20 16:29, Konrad Kohbrok wrote:
> Hi,
>
> Just a small addition to Britta's response:
>
> For #3: We already mandate that the parent group must not be used anym= ore if a
> Re-Init proposal is included in a commit in lines 2341-2342 of the PR = (although
> "to send messages" might as well be removed). We could also = get rid of the
> proposal and simply have the intent to re-initialize be implicit in se= nding a
> Welcome message with a corresponding PSK Id. The idea behind the Propo= sal was to
> make that intent explicit such that the intent, as well as the target<= br> > ciphersuite and MLS version are all entered into the transcript and th= us agreed
> upon. Even though the group is terminated after the proposal is receiv= ed, this
> agreement can be verified by using the authentication key technique th= at Britta
> proposed, i.e. each party can check that their authentication key corr= esponds to
> the one the committer uploaded.
>
> I'm also ok with splitting it into multiple individual PRs if that= makes it
> easier to review and discuss.
>
> Cheers,
> Konrad
>
>
> On 18.06.20 04:07, Hale, Britta (CIV) wrote:
>> Hi Richard,
>>
>> =C2=A0
>>
>> Thank you for the comments and careful read of the PR.
>>
>> =C2=A0
>>
>> For #1/#2: I am amicable to the idea of adding an extension field = to the commit
>> message. As a general comment, we may want to consider if there ar= e other types
>> of commit extensions worth adding or, alternatively, how the field= may be abused
>> (e.g. treated as AD by an application).
>>
>> It terms of objection to the current form though, your argument is= not clear.
>> PSKIds should uniquely identify PSKs, and a joiner (or anyone) sho= uld be able to
>> identify the correct PSK given the PSKId, if they are in possessio= n of it. PSKs
>> must only be used in an Add if the joiner is a past group member (= line 2055) and
>> therefore has the correct PSKId/group_id/psk_epoch, although this = is nullified
>> if we make the change discussed in #4. In that case, the issue for= Adds goes away.
>>
>> The PR already allows for a PSK in the Welcome message.
>>
>> =C2=A0
>>
>> For #3: Currently, in the PR, there is a recovery_secret derived p= er-epoch. When
>> a member wants to re-initialize, they issue a Re-Init proposal. Th= ey may then
>> re-initialize the group by sending a Welcome message (see lines 19= 23, 1948, and
>> 2349) with the PSKId for the parent group/epoch and a psktype that= indicates
>> that they are re-initializing the group with the stated PSKId. So = this seems to
>> already be what you describe below as =E2=80=9Chave the initiator = of the child send a
>> Welcome that has a pointer back to the parent=E2=80=9D. However, y= ou are right that more
>> detail can be added; in particular a requirement should be added t= o terminate
>> the parent group and that the terminating member/re-init proposer = must also
>> create the new group.
>>
>> =C2=A0
>>
>> For #4: There was a discussion at the first virtual interim in lat= e April
>> (Interim #11-2020) wherein some expressed a desire for this featur= e. Namely,
>> instead of re-syncing the entire group, there were use cases for r= e-syncing the
>> odd member when necessary. Its inclusion in the PR arises from tha= t later
>> request. I am favorable to removing it since, from security standp= oint, it is
>> not ideal. However, the motivation for this was pushed from the im= plementation
>> standpoint. Consequently, now is a good time for anyone to speak u= p who wants to
>> push for this.
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> One item: you made point of specifically requesting =E2=80=93 a fe= w times =E2=80=93 at the
>> virtual interims #11 and #12 in April/May that this PSK PR and as = many other key
>> schedule-related PRs be combined into a single one. Raphael made a= similar
>> request under git issue #325. In fact, the authors of this PR had = pushed back on
>> that insistence to limit the current PR down to the items it curre= ntly covers,
>> instead of merging in other key schedule changes as well. Are you = saying that
>> you have changed your mind?
>>
>> We can, of course, accommodate a revised preference if needed.
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> Britta
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> *From: *MLS <mls-bounces@ietf.org> on behalf of Richard Barnes <rlb@ip= v.sx>
>> *Date: *Wednesday, June 17, 2020 at 3:54 PM
>> *To: *Messaging Layer Security WG <mls@ietf.org>
>> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group= Branching (#336)
>>
>> =C2=A0
>>
>> Hey all,
>>
>> Sorry for the late review on this PR, I have finally gotten a chan= ce to really
>> dig into it, and ... I have some concerns.=C2=A0 My current thinki= ng is consistent
>> with my earlier comments that the general thrust of this PR is OK.= =C2=A0 But I think
>> the actual approach needs to change a fair bit.
>>
>> As its title implies, this PR is trying to do several things at on= ce, which seem
>> to me to be fairly separable:
>>
>> 0. Update the key schedule so that PSKs are injected at the right = point and
>> multiple PSKs are supported
>> 1. Signal that a PSK should get injected into a given epoch
>> 2. Request injection of PSK at join / in Welcome
>> 3. Re-initialize the group with different parameters
>> 4. Re-sync group members that have lost state
>>
>> For the most part, I think these are worthwhile goals, but they sh= ould be
>> accomplished in different ways than the PR proposes.=C2=A0 Detaile= d thoughts by
>> objective:
>>
>>
>> # 0. Update the key schedule so that PSKs are injected at the righ= t point and
>> multiple PSKs are supported
>>
>> This part of the PR is fine, but I think is ultimately done a bit = more elegantly
>> with the n-PRF stuff in #337.
>>
>>
>> # 1. Signal that a PSK should get injected into a given epoch
>> # 2. Request injection of PSK at join / in Welcome
>>
>> (These go together)
>>
>> The PR proposes (heh) an EPSK proposal or an Add proposal, but the= n requires
>> that only one EPSK be used.=C2=A0 I actually don't the proposa= l for including PSKs in
>> Adds actually works.=C2=A0 The joiner would have to know all of th= em plus the EPSK,
>> and there's not even any syntax in the PR to tell the joiner w= hich ones to include.
>>
>> I would propose that instead we add an extensions field to the Com= mit message,
>> then add a Commit extension that specifies the PSK ID for the PSK = to be added.=C2=A0
>> That extension can then also go in the Welcome message correspondi= ng to the
>> commit, so that joiners know to add the PSK.
>>
>> This change actually doesn't make a difference in terms of wha= t ends up in the
>> transcript -- either way, only the PSK ID selected by the committe= r goes in the
>> transcript.=C2=A0 It seems better not to deliberately have proposa= ls floating around
>> that never get included in the transcript.
>>
>>
>> # 3. Re-initialize the group with different parameters
>>
>> The PR proposes another proposal type for reinitialization, but it= 's really
>> under-specified what you do to re-init.=C2=A0 For example, what go= es in the ratchet
>> tree?=C2=A0 Clearly you need a brand new tree, since the one you h= ave might be tied
>> to the wrong ciphersuite.=C2=A0 What you really need is something = like a Welcome message.
>>
>> And that's how I think we should actually arrange things.=C2= =A0 Instead of having the
>> parent group do something to spawn, have the initiator of the chil= d send a
>> Welcome that has a pointer back to the parent.=C2=A0 So we have an= other Welcome
>> extension (`parent_group`, say) that has a pointer to the parent g= roup by group
>> ID and epoch, and instructs the joiner to take a secret from that = group/epoch's
>> key schedule and add it into the new group's key schedule.
>>
>>
>>
>> # 4. Re-sync group members that have lost state
>>
>> We should not do these.=C2=A0 At the January interim, we decided n= ot to drop the
>> resync issue (#93) given that there were some subtleties depending= on exactly
>> what state had been lost, and that it could be cleanly done in a s= eparate spec.
>>
>>
>> # Conclusions
>>
>> Given the above, I would propose we break this into separate issue= s to be closed
>> with individual, smaller PRs.=C2=A0 Assuming that (0) will get add= ressed by the n-PRF
>> PR, that leaves us with:
>>
>> #XXX Add Extensions to the Commit message
>> #XXX Signal use of external PSKs in Commit/Welcome (=3D> extens= ion to
>> Commit/Welcome messages)
>> #XXX Allow Welcome to signal the inclusion of information from a p= rior group (=3D>
>> Welcome extension)
>>
>> Happy to write those up, and contribute to PRs.=C2=A0 Sorry again = for the slow
>> progress here.
>>
>> --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
>

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--0000000000008f2b9c05ab37a643-- From nobody Sat Jul 25 10:50: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 1E79E3A0D65 for ; Sat, 25 Jul 2020 10:50:46 -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=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 93zf8qumkZIz for ; Sat, 25 Jul 2020 10:50:44 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 EF75C3A0D63 for ; Sat, 25 Jul 2020 10:50:43 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id l23so11760021qkk.0 for ; Sat, 25 Jul 2020 10:50:43 -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=AxAZ5dutSQfbVvD+FZk85Yw0q8GZugvxeUrA2ic7MTI=; b=P+uqZz1TOYPgBrleYBTBA1Qk+71y60N254EUblyy14NTSNj+DM1Pvn2oOJWqDrRMAA cE2j0YBE2wsjJaF5Z381i1scBExYMiTL5d4me5it2NfzUSO39gKfoVHXl7t3YzJpTI/m a5l5Q8i0iq8eZQczRH0gFrMTyfO3fTiQ1jFx0= 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=AxAZ5dutSQfbVvD+FZk85Yw0q8GZugvxeUrA2ic7MTI=; b=b1/Rh2meMYMAEPi3fHLIyS2DHKAOh3N/s24c8VHqNdS8sO48Hh1cqmhu+1c8hQkpXE bGzvdfTjd6krhLgoWwgSKy5Z5hfA2pcV5H6tFKawxlE3bwDhMAhzJ3R224g5w/KOLByI RYPAhI/6HmtqZsia/djFgUIewBDEcznfbUXsbq5kctJX8WacVpscoTxXhs4pOAwgnCjg XgDeI0YP1sCI3jhdDyyJvB2xrub5t90RaZTpuWrAi5gzJ/EfPvcQx3fSz1b6AsOXXArv enLRFuPK9fTVnNTwINAfM0mQ9QZFvMTxJ/dPmwBvaeah7Gv/ku3NzVR7LlzvEeNOUsKs f1EA== X-Gm-Message-State: AOAM531ZUM2nFETR3OY3dTgtEkC48pv2Q+fkdirpA2J3LlXR5NeviVd0 cGfEhwskEdNb947A5X4Z6x71efe56f9TZXQlQZJ2RminrdQ= X-Google-Smtp-Source: ABdhPJzfBS2n/FLrl5RA/s8w7AsNUL5XMtqVJc6VTgV3dweQ8M/AlHLlEjtREPTCWtFCLZteKflp83jltZ8sS9pmUcI= X-Received: by 2002:a37:7ec5:: with SMTP id z188mr15236724qkc.461.1595699442759; Sat, 25 Jul 2020 10:50:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brendan McMillion Date: Sat, 25 Jul 2020 10:50:31 -0700 Message-ID: To: Richard Barnes Cc: "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000747d8e05ab47ba4f" Archived-At: Subject: Re: [MLS] Hiding content type 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, 25 Jul 2020 17:50:46 -0000 --000000000000747d8e05ab47ba4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Take for example, a broadcast channel that's ordered but lossy. A Commit gets sent where the new epoch id collides with the previous epoch id, but not all members get the Commit. So now the group is fractured and there's no way for members in the previous epoch to know that they missed a message. What the application developer needs to do to detect lost messages, is immediately re-implement the counter epoch id that you've just removed. That's an example of a system where this change is pointless / harmful. If you could provide an example of a system where the change is *helpful*, that would be more interesting. On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: > I'm honestly really confused by the worry about collisions here. The > current epoch ID collides trivially -- it's just a counter! And the grou= p > ID is assumed to be public anyway. So if your authentication scheme is > broken when you have a (group ID, epoch ID) collision, then your scheme i= s > already broken. > > If we're going to block this change on this basis, then we need to see > clearly articulated an authentication scheme that is secure in the curren= t > model, but broken in the case where epoch IDs are derived off of the key > schedule. > > --Richard > > On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) > wrote: > >> Ensuring the most conservative design by default seems advisable; howeve= r >> it is not clear that this proposal for hiding content type is actually >> doing that. Indeed, if an application is concerned about hiding the cont= ent >> type, would not that same type of application also be concerned about >> collisions? >> >> >> >> As Brendan notes, we are not talking about accidental collisions here. >> Pre-computation is entirely possible, such as by a malicious group membe= r, >> so the window of attack is not limited to one epoch. >> >> >> >> If this is this PR particular is of particular interest to some, then it >> would be good to see a clarifying explanation as to the security it >> achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite = introducing such >> collision possibilities), or a concrete use-case. Alternatively, are we >> really limited to a 64-bit field, or can that length be adjusted to >> mitigate the introduced problems? >> >> >> >> >> >> >> >> A clarifying point for those following this thread: some references in >> the email chain state that this is encryption of the epoch ID. That is n= ot >> the case. The proposal being discussed is about a hash thereof (hence >> discussion on collisions). >> >> >> >> Britta >> >> >> >> >> >> *From: *MLS on behalf of Brendan McMillion >> >> *Date: *Monday, July 13, 2020 at 9:37 AM >> *To: *Richard Barnes >> *Cc: *Messaging Layer Security WG >> *Subject: *Re: [MLS] Hiding content type >> >> >> >> As far as collision resistance, I'm not too worried about collisions >> among 64-bit random values, especially as the scope for collision is fai= rly >> small, arguably just one epoch. >> >> >> >> The issue isn't with accidental collisions, it's with malicious ones. An >> attacker can purposefully (and quickly) generate commits that create >> duplicate epoch ids, and send them to a client to corrupt their group st= ate. >> >> >> >> I think the idea here is to be conservative by default. There are >> systems in which you can hide the metadata you're talking about with thi= ngs >> like mixnets and dropboxes. >> >> >> >> It's not just being more conservative, you're making changes specificall= y >> for very niche use-cases where I don't think the security of the whole >> system has been thought through. Maybe you have an example in mind, but = I >> can't think of a system where this change provides any additional privac= y. >> >> >> >> On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: >> >> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion < >> brendan@cloudflare.com> wrote: >> >> With respect to using an opaque epoch id, I believe this was proposed in >> #245 and consensus was >> against it because it makes it more difficult to implement the DS. It's >> also not clear to me what security properties you want from an opaque ep= och >> id, because the current PR doesn't provide collision resistance and I'd >> expect this to be a source of confusion and bugs. >> >> >> >> I think the discussion on #245 got derailed a bit by the focus on >> non-linear epochs. The point here is that even in a case where you have >> linear history, I think there's intrinsic value in the epoch ID being >> opaque because it gives intermediaries less opportunity for ossification= . >> >> >> >> As far as collision resistance, I'm not too worried about collisions >> among 64-bit random values, especially as the scope for collision is fai= rly >> small, arguably just one epoch. >> >> >> >> >> >> With respect to encrypting the content type, it also seems to me that >> this would cause issues because different content types have different >> delivery guarantees. Specifically: messages are allowed to be unordered = and >> lossy, proposals are allowed to be unordered but not lossy, and commits = are >> both ordered and not lossy. In the deployment scenarios we've talked abo= ut, >> the DS essentially always needs to know the content type to provide this= . >> Conversely, you don't get much additional privacy from encrypting the >> content type because an eavesdropper can see the epoch id change and inf= er >> which message was a commit, or see a dropped message getting re-sent and >> infer it was a proposal. >> >> >> >> I don't disagree that there are different guarantees you need, but like = I >> said, I think the idea here is to be conservative by default. There are >> systems in which you can hide the metadata you're talking about with thi= ngs >> like mixnets and dropboxes. Keeping the ciphertext as opaque as possibl= e >> keeps the door open to running MLS over those systems without MLS's own >> metadata undermining their privacy properties. >> >> >> >> FWIW, in the systems I'm looking at building, this PR does not make any >> difference, because clients use separate channels for Proposals/Commits = vs. >> application data and the server doesn't check. >> >> >> >> --Richard >> >> >> >> >> >> >> >> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >> >> Hi all, >> >> >> >> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) >> encrypt the content type of the message (application / proposal / commit= ) >> [1]. >> >> >> >> There was some discussion on the call last week that encrypting the >> content type might not be that useful, since an application that relies = on >> a server to assure ordering of commits will need to at least be able to >> tell commits from other things. Of course, even if the content type is >> encrypted by default, the application can add it back in authenticated >> data, or in some unauthenticated wrapper. >> >> >> >> Net of those considerations, I'm personally still inclined to merge the >> PR, to have a conservative baseline. But those on the call thought it >> would be useful to pose this to the group, so please speak up if you hav= e >> concerns. >> >> >> >> --Richard >> >> >> >> [1] https://github.com/mlswg/mls-protocol/pull/349 >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> --000000000000747d8e05ab47ba4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Take for example, a broadcast channel that's orde= red but lossy. A Commit gets sent where the new epoch id collides with the = previous epoch id, but not all members get the Commit. So now the group is = fractured and there's no way for members in the previous epoch to know = that they missed a message. What the application developer needs to do to d= etect lost messages, is immediately re-implement the counter epoch id that = you've just removed.

That's an example of = a system where this change is pointless / harmful. If you could provide an = example of a system where the change is *helpful*, that would be more inter= esting.

On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <rlb@ip= v.sx> wrote:
=
I'm honestly really confused by the worry about c= ollisions here.=C2=A0 The current epoch ID collides trivially -- it's j= ust a counter!=C2=A0 And the group ID is assumed to be public anyway.=C2=A0= So if your authentication scheme is broken when you have a (group ID, epoc= h ID) collision, then your scheme is already broken.

If we're going to block this change on this basis, then we need to s= ee clearly articulated an authentication scheme that is secure in the curre= nt model, but broken in the case where epoch IDs are derived off of the key= schedule.

--Richard

On Tue, Jul 14, 2020 at 10:= 38 AM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:

Ensuring the most conservative design by default see= ms advisable; however it is not clear that this proposal for hiding content= type is actually doing that. Indeed, if an application is concerned about = hiding the content type, would not that same type of application also be concerned about collisions? <= u>

=C2=A0

As Brendan notes, we are not talking about accidenta= l collisions here. Pre-computation is entirely possible, such as by a malic= ious group member, so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular inter= est to some, then it would be good to see a clarifying explanation as to th= e security it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80= =9D despite introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit f= ield, or can that length be adjusted to mitigate the introduced problems?

=C2=A0

=C2=A0

=C2=A0

A clarifying point for those following this thread: = some references in the email chain state that this is encryption of the epo= ch ID. That is not the case. The proposal being discussed is about a hash t= hereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0

=C2=A0

From: = MLS <mls-bounces@ietf.org> o= n behalf of Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org&g= t;
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions, it&#= 39;s with malicious ones. An attacker can purposefully (and quickly) genera= te commits that create duplicate epoch ids, and send them to a client to co= rrupt their group state.

=C2=A0

I think the idea here is to be conservative by defau= lt.=C2=A0 There are systems in which you can hide the metadata you're t= alking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you'r= e making changes specifically for very niche use-cases where I don't th= ink the security of the whole system has been thought through. Maybe you ha= ve an example in mind, but I can't think of a system where this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <= rlb@ipv.sx> wrote:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion &= lt;brendan@clou= dflare.com> wrote:

With respect to using an opaque epoch id, I believe = this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a bit by= the focus on non-linear epochs.=C2=A0 The point here is that even in a cas= e where you have linear history, I think there's intrinsic value in the= epoch ID being opaque because it gives intermediaries less opportunity for ossification.

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it also= seems to me that this would cause issues because different content types h= ave different delivery guarantees. Specifically: messages are allowed to be= unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and no= t lossy. In the deployment scenarios we've talked about, the DS essenti= ally always needs to know the content type to provide this. Conversely, you= don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id c= hange and infer which message was a commit, or see a dropped message gettin= g re-sent and infer it was a proposal.

=C2=A0

I don't disagree that there are different guaran= tees you need, but like I said, I think the idea here is to be conservative= by default.=C2=A0 There are systems in which you can hide the metadata you= 're talking about with things like mixnets and dropboxes.=C2=A0 Keeping the ciphertext as opaque as possible keeps th= e door open to running MLS over those systems without MLS's own metadat= a undermining their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at building, th= is PR does not make any difference, because clients use separate channels f= or Proposals/Commits vs. application data and the server doesn't check.=

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <r= lb@ipv.sx> wrote:

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an opaque= epoch ID, and (2) encrypt the content type of the message (application / p= roposal / commit) [1].

=C2=A0

There was some discussion on the call last week that= encrypting the content type might not be that useful, since an application= that relies on a server to assure ordering of commits will need to at leas= t be able to tell commits from other things.=C2=A0 Of course, even if the content type is encrypted by default,= the application can add it back in authenticated data, or in some unauthen= ticated wrapper.

=C2=A0

Net of those considerations, I'm personally stil= l inclined to merge the PR, to have a conservative baseline.=C2=A0 But thos= e on the call thought it would be useful to pose this to the group, so plea= se speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

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

--000000000000747d8e05ab47ba4f-- From nobody Sat Jul 25 12:39:08 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 4A6E33A09FC for ; Sat, 25 Jul 2020 12:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 Q1IYv3smXwzw for ; Sat, 25 Jul 2020 12:39:03 -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 5F7043A09FB for ; Sat, 25 Jul 2020 12:39:02 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 11so11910521qkn.2 for ; Sat, 25 Jul 2020 12:39:02 -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=VYAY0wgwy/sMHoCKFbwaMuQN6DIAeLmE4smQGz/ZHMM=; b=eK+lKO6QhJ2ql11rbOEM3RRLBS2Qrg/BHsK7k36lZfBnzANgiSoLaEpG4spdvU8Qda 7pO06+A0TbHrnYdg/rTQk2vSHbQtFxyRyoJ+guy++LIc3GsAZ38yEVHBRkDv0ECQupIU ciNVe/Rc7+QN/07efEawdl3MK7/KOvFrtQWIdo8r3BeWjTMmYdOOljOePnhC57BRnrxa bjoLXqTTnkMYO7hPIC5KRllQKQmeWpOsOS6Hm5V1iwzGtRBZdrgNgPR2mO9mwmUxZ8kx 89w/gi0C4KkRW+bsER0l/b/YoyZkGiTcozx5jvX4aUTI0xz6RnR1QN/ljz8NIKJbzPiC SVrQ== 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=VYAY0wgwy/sMHoCKFbwaMuQN6DIAeLmE4smQGz/ZHMM=; b=ndDKNtfMHDG5nlhFMOCHdwfn4T5b60XKzshsmUFFbNm5n9UDlODbu/pDTkSy1zVxQr v2yVTyFCljDyfedDSTlZsDfKf5/5LVRWiLAA7Cs+hJasEPj0QD6RXCTwRtVzNlixOvZl 7WROwlWklycICbLlyijV0kEyWC1lM5L1rbqCUsIzZxGRKjLjRf8l+KsqUPdXV3hfp0r1 YIY+EsWwXnW7pNlCHIFYE/2Rvl5QeLFh1LxcFs6KAD+DHUsdD43Mv/SXN4oiGAUVvb2T Eg9HaDHipEuEsqdIEY/u3sfkJklhdu5TBYegmNv+0VZZqC9wYQXgk3RtbyHxQhEtIPbW 8u2g== X-Gm-Message-State: AOAM5339eq/2P1E85XG7vkZFxxm75Gd6mIMXZg9G2sda0jb9IugAErRd HTZkUOnDNOSNhrzQ6RQBIA5cBsQwd+WGOlPATu/Avw== X-Google-Smtp-Source: ABdhPJzw/htNFYIyhDeNJ4GHDdgqweuvSkiFcrsSW+TR77Kj8Dl4rygJXI+ZorK0LgQA7ir2ozdNo/9j0nFiKoaTn0w= X-Received: by 2002:a37:8fc6:: with SMTP id r189mr15869850qkd.159.1595705941917; Sat, 25 Jul 2020 12:39:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Sat, 25 Jul 2020 15:38:33 -0400 Message-ID: To: Brendan McMillion Cc: "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d5957a05ab493d9a" Archived-At: Subject: Re: [MLS] Hiding content type 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, 25 Jul 2020 19:39:06 -0000 --000000000000d5957a05ab493d9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just so we're clear, in your example, are you concerned about accidental or adversarial collisions? I hope we agree that we can fix the accidental case just by making a longer epoch ID. In the adversarial case, this seems like a partial DoS at worst, since the members who incorrectly think they are in the previous epoch will no longer be decrypting with the right keys. As far as a positive example: Imagine a Generic Commit Sequencing Service that provides a reliable broadcast/ledger over anonymous channels (e.g., as an onion service), but will only broadcast/record one message for each groupID/epoch. If the groupID/epoch is opaque, then such a service can be provided without learning anything about the groups it serves or their evolution. On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion wrote: > Take for example, a broadcast channel that's ordered but lossy. A Commit > gets sent where the new epoch id collides with the previous epoch id, but > not all members get the Commit. So now the group is fractured and there's > no way for members in the previous epoch to know that they missed a > message. What the application developer needs to do to detect lost > messages, is immediately re-implement the counter epoch id that you've ju= st > removed. > > That's an example of a system where this change is pointless / harmful. I= f > you could provide an example of a system where the change is *helpful*, > that would be more interesting. > > On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: > >> I'm honestly really confused by the worry about collisions here. The >> current epoch ID collides trivially -- it's just a counter! And the gro= up >> ID is assumed to be public anyway. So if your authentication scheme is >> broken when you have a (group ID, epoch ID) collision, then your scheme = is >> already broken. >> >> If we're going to block this change on this basis, then we need to see >> clearly articulated an authentication scheme that is secure in the curre= nt >> model, but broken in the case where epoch IDs are derived off of the key >> schedule. >> >> --Richard >> >> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) >> wrote: >> >>> Ensuring the most conservative design by default seems advisable; >>> however it is not clear that this proposal for hiding content type is >>> actually doing that. Indeed, if an application is concerned about hidin= g >>> the content type, would not that same type of application also be conce= rned >>> about collisions? >>> >>> >>> >>> As Brendan notes, we are not talking about accidental collisions here. >>> Pre-computation is entirely possible, such as by a malicious group memb= er, >>> so the window of attack is not limited to one epoch. >>> >>> >>> >>> If this is this PR particular is of particular interest to some, then i= t >>> would be good to see a clarifying explanation as to the security it >>> achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite= introducing such >>> collision possibilities), or a concrete use-case. Alternatively, are we >>> really limited to a 64-bit field, or can that length be adjusted to >>> mitigate the introduced problems? >>> >>> >>> >>> >>> >>> >>> >>> A clarifying point for those following this thread: some references in >>> the email chain state that this is encryption of the epoch ID. That is = not >>> the case. The proposal being discussed is about a hash thereof (hence >>> discussion on collisions). >>> >>> >>> >>> Britta >>> >>> >>> >>> >>> >>> *From: *MLS on behalf of Brendan McMillion >>> >>> *Date: *Monday, July 13, 2020 at 9:37 AM >>> *To: *Richard Barnes >>> *Cc: *Messaging Layer Security WG >>> *Subject: *Re: [MLS] Hiding content type >>> >>> >>> >>> As far as collision resistance, I'm not too worried about collisions >>> among 64-bit random values, especially as the scope for collision is fa= irly >>> small, arguably just one epoch. >>> >>> >>> >>> The issue isn't with accidental collisions, it's with malicious ones. A= n >>> attacker can purposefully (and quickly) generate commits that create >>> duplicate epoch ids, and send them to a client to corrupt their group s= tate. >>> >>> >>> >>> I think the idea here is to be conservative by default. There are >>> systems in which you can hide the metadata you're talking about with th= ings >>> like mixnets and dropboxes. >>> >>> >>> >>> It's not just being more conservative, you're making changes >>> specifically for very niche use-cases where I don't think the security = of >>> the whole system has been thought through. Maybe you have an example in >>> mind, but I can't think of a system where this change provides any >>> additional privacy. >>> >>> >>> >>> On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: >>> >>> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion < >>> brendan@cloudflare.com> wrote: >>> >>> With respect to using an opaque epoch id, I believe this was proposed i= n >>> #245 and consensus was >>> against it because it makes it more difficult to implement the DS. It's >>> also not clear to me what security properties you want from an opaque e= poch >>> id, because the current PR doesn't provide collision resistance and I'd >>> expect this to be a source of confusion and bugs. >>> >>> >>> >>> I think the discussion on #245 got derailed a bit by the focus on >>> non-linear epochs. The point here is that even in a case where you hav= e >>> linear history, I think there's intrinsic value in the epoch ID being >>> opaque because it gives intermediaries less opportunity for ossificatio= n. >>> >>> >>> >>> As far as collision resistance, I'm not too worried about collisions >>> among 64-bit random values, especially as the scope for collision is fa= irly >>> small, arguably just one epoch. >>> >>> >>> >>> >>> >>> With respect to encrypting the content type, it also seems to me that >>> this would cause issues because different content types have different >>> delivery guarantees. Specifically: messages are allowed to be unordered= and >>> lossy, proposals are allowed to be unordered but not lossy, and commits= are >>> both ordered and not lossy. In the deployment scenarios we've talked ab= out, >>> the DS essentially always needs to know the content type to provide thi= s. >>> Conversely, you don't get much additional privacy from encrypting the >>> content type because an eavesdropper can see the epoch id change and in= fer >>> which message was a commit, or see a dropped message getting re-sent an= d >>> infer it was a proposal. >>> >>> >>> >>> I don't disagree that there are different guarantees you need, but like >>> I said, I think the idea here is to be conservative by default. There = are >>> systems in which you can hide the metadata you're talking about with th= ings >>> like mixnets and dropboxes. Keeping the ciphertext as opaque as possib= le >>> keeps the door open to running MLS over those systems without MLS's own >>> metadata undermining their privacy properties. >>> >>> >>> >>> FWIW, in the systems I'm looking at building, this PR does not make any >>> difference, because clients use separate channels for Proposals/Commits= vs. >>> application data and the server doesn't check. >>> >>> >>> >>> --Richard >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >>> >>> Hi all, >>> >>> >>> >>> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) >>> encrypt the content type of the message (application / proposal / commi= t) >>> [1]. >>> >>> >>> >>> There was some discussion on the call last week that encrypting the >>> content type might not be that useful, since an application that relies= on >>> a server to assure ordering of commits will need to at least be able to >>> tell commits from other things. Of course, even if the content type is >>> encrypted by default, the application can add it back in authenticated >>> data, or in some unauthenticated wrapper. >>> >>> >>> >>> Net of those considerations, I'm personally still inclined to merge the >>> PR, to have a conservative baseline. But those on the call thought it >>> would be useful to pose this to the group, so please speak up if you ha= ve >>> concerns. >>> >>> >>> >>> --Richard >>> >>> >>> >>> [1] https://github.com/mlswg/mls-protocol/pull/349 >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >>> --000000000000d5957a05ab493d9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just so we're clear, in your example, are you con= cerned about accidental or adversarial collisions?=C2=A0 I hope we agree th= at we can fix the accidental case just by making a longer epoch ID.=C2=A0 I= n the adversarial case, this seems like a partial DoS at worst, since the m= embers who incorrectly think they are in the previous epoch will no longer = be decrypting with the right keys.

As far as a= positive example: Imagine a Generic Commit Sequencing Service that provide= s a reliable broadcast/ledger over anonymous channels (e.g., as an onion se= rvice), but will only broadcast/record one message for each groupID/epoch.= =C2=A0 If the groupID/epoch is opaque, then such a service can be provided = without learning anything about the groups it serves or their evolution.


On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion &l= t;brendan@cloudflare.com> = wrote:
Take for example, a broadcast channel that's ordered but = lossy. A Commit gets sent where the new epoch id collides with the previous= epoch id, but not all members get the Commit. So now the group is fracture= d and there's no way for members in the previous epoch to know that the= y missed a message. What the application developer needs to do to detect lo= st messages, is immediately re-implement the counter epoch id that you'= ve just removed.

That's an example of a system= where this change is pointless / harmful. If you could provide an example = of a system where the change is *helpful*, that would be more interesting.<= br>

On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <rlb@ipv.sx>= wrote:
I'm honestly really confused by the worry about collision= s here.=C2=A0 The current epoch ID collides trivially -- it's just a co= unter!=C2=A0 And the group ID is assumed to be public anyway.=C2=A0 So if y= our authentication scheme is broken when you have a (group ID, epoch ID) co= llision, then your scheme is already broken.

If we= 're going to block this change on this basis, then we need to see clear= ly articulated an authentication scheme that is secure in the current model= , but broken in the case where epoch IDs are derived off of the key schedul= e.

--Richard

On Tue, Jul 14, 2020 at 10:38 AM Ha= le, Britta (CIV) <britta.hale@nps.edu> wrote:

Ensuring the most conservative design by default see= ms advisable; however it is not clear that this proposal for hiding content= type is actually doing that. Indeed, if an application is concerned about = hiding the content type, would not that same type of application also be concerned about collisions? <= u>

=C2=A0

As Brendan notes, we are not talking about accidenta= l collisions here. Pre-computation is entirely possible, such as by a malic= ious group member, so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular inter= est to some, then it would be good to see a clarifying explanation as to th= e security it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80= =9D despite introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit f= ield, or can that length be adjusted to mitigate the introduced problems?

=C2=A0

=C2=A0

=C2=A0

A clarifying point for those following this thread: = some references in the email chain state that this is encryption of the epo= ch ID. That is not the case. The proposal being discussed is about a hash t= hereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0

=C2=A0

From: = MLS <mls-bounces@ietf.org> o= n behalf of Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org&g= t;
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions, it&#= 39;s with malicious ones. An attacker can purposefully (and quickly) genera= te commits that create duplicate epoch ids, and send them to a client to co= rrupt their group state.

=C2=A0

I think the idea here is to be conservative by defau= lt.=C2=A0 There are systems in which you can hide the metadata you're t= alking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you'r= e making changes specifically for very niche use-cases where I don't th= ink the security of the whole system has been thought through. Maybe you ha= ve an example in mind, but I can't think of a system where this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <= rlb@ipv.sx> wrote:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion &= lt;brendan@clou= dflare.com> wrote:

With respect to using an opaque epoch id, I believe = this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a bit by= the focus on non-linear epochs.=C2=A0 The point here is that even in a cas= e where you have linear history, I think there's intrinsic value in the= epoch ID being opaque because it gives intermediaries less opportunity for ossification.

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it also= seems to me that this would cause issues because different content types h= ave different delivery guarantees. Specifically: messages are allowed to be= unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and no= t lossy. In the deployment scenarios we've talked about, the DS essenti= ally always needs to know the content type to provide this. Conversely, you= don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id c= hange and infer which message was a commit, or see a dropped message gettin= g re-sent and infer it was a proposal.

=C2=A0

I don't disagree that there are different guaran= tees you need, but like I said, I think the idea here is to be conservative= by default.=C2=A0 There are systems in which you can hide the metadata you= 're talking about with things like mixnets and dropboxes.=C2=A0 Keeping the ciphertext as opaque as possible keeps th= e door open to running MLS over those systems without MLS's own metadat= a undermining their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at building, th= is PR does not make any difference, because clients use separate channels f= or Proposals/Commits vs. application data and the server doesn't check.=

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <r= lb@ipv.sx> wrote:

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an opaque= epoch ID, and (2) encrypt the content type of the message (application / p= roposal / commit) [1].

=C2=A0

There was some discussion on the call last week that= encrypting the content type might not be that useful, since an application= that relies on a server to assure ordering of commits will need to at leas= t be able to tell commits from other things.=C2=A0 Of course, even if the content type is encrypted by default,= the application can add it back in authenticated data, or in some unauthen= ticated wrapper.

=C2=A0

Net of those considerations, I'm personally stil= l inclined to merge the PR, to have a conservative baseline.=C2=A0 But thos= e on the call thought it would be useful to pose this to the group, so plea= se speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

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

--000000000000d5957a05ab493d9a-- From nobody Sat Jul 25 13:09: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 DBEDD3A0A8E for ; Sat, 25 Jul 2020 13:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=aalto.fi 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 kUz8ztzLNd7c for ; Sat, 25 Jul 2020 13:09:29 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 2CDCC3A0A87 for ; Sat, 25 Jul 2020 13:09:27 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 279DC27145C_F1C9173B; Sat, 25 Jul 2020 20:09:23 +0000 (GMT) Received: from exng2.org.aalto.fi (exng2.org.aalto.fi [130.233.223.21]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id A10912713F0_F1C9172F; Sat, 25 Jul 2020 20:09:22 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng2.org.aalto.fi (130.233.223.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sat, 25 Jul 2020 23:09:22 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sat, 25 Jul 2020 23:09:21 +0300 From: Chris Brzuska To: Richard Barnes CC: Messaging Layer Security WG References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> Message-ID: <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> Date: Sat, 25 Jul 2020 23:09:19 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> Content-Type: multipart/alternative; boundary="------------8591F5DB9CD872A453A1BEE0" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng5.org.aalto.fi (130.233.223.24) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:from:to:cc:references:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=iSHiFKnZY1ri+7tD3m5GdXg94trVYpfYuNreow/QRt8=; b=ytbvvEjqMXgVeZgatWH/y+bA1KVQCmFoF+/4a/rnksML9QgHJf/heesP+ZPjf6NtG/mG5dQm2nwzt0WBcxUC86kOMAxqWXePCtXnQC+dcYRIu4pWyV3PwBiVMEIwGtUuxGpzkKwv4oAhNCLWDeM0IVUSuiFIkZWqcSWnZnHJc48Y9qP0mw69IdKeG9PiCMI69SCPFDLvw1enoVC0+BHD4fl2iRYoEnR0YfZei/dRlpFZMFxLaXt2hHiLm+yjJ0BNd4CmuumlznZlxcf9XZZDnAI+4Liy23TdfImesNSxwWgT+t1gyBcCM/7c38TBOI7xSJD2ZB+V76u4gN3/9DQd4Q== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 25 Jul 2020 20:09:33 -0000 --------------8591F5DB9CD872A453A1BEE0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Richard, I have a quick question: An additional change in your key schedule is that the welcome_secret is now derived *before* including the PSK. What is the motivation behind this? Thanks! Chris On 24/07/2020 22:18, Chris Brzuska wrote: > I see, thanks for clarifying. Obviously, with these requirements, pull > request #336 does not work as is. I think that the conceptual issue of > how to best combine two, three keys and more keys, remains, now with > an additional requirement to combine two keys separately first. > > Will think about it, thanks for clarifying the requirements! > > Chris > > On 24/07/2020 21:47, Richard Barnes wrote: >> Your confusion is understandable -- the document is wrong right now!  >> You are correct that the current design prohibits new joiners from >> participating in the PSK proof, but that's a bug, not a feature.  The >> epoch secret should verify that *all members of the current epoch* >> know the PSK, not just the ones inherited from the last epoch. >> >> That's why #362 rearranges the key schedule as follows: >> >> init_secret_[n-1] (or 0) >>                         | >>                         V >>    commit_secret -> HKDF-Extract = joiner_secret >>                         | >>                         +--> Derive-Secret(., "welcome") >>                         |    = welcome_secret >>                         | >>                         V >>       PSK (or 0) -> HKDF-Extract = member_secret >>                         | >>                         V >> GroupContext_[n] -> HKDF-Extract = epoch_secret >> >> (I also promoted the GroupContext to the main key schedule.)  That's >> the context for my earlier comments. With that picture, the only >> thing you're coalescing with nPRF would be the latter two >> HKDF-Extract calls. >> >> Hope that helps, >> --Richard >> >> >> >> On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska > > wrote: >> >> Hey Richard, >> >> thank you for looking into this. I think, I need more explanation >> to understand the following point: >> >> >>>  You can't add the commit secret and PSKs in the same >> operation, because you want new joiners to put in the PSK, but >> you don't want them to have to know the commit secret. >> >> The current draft sais the following about the PSK: >> "Groups which already have an out-of-band mechanism to generate >> *shared* group secrets can inject those in the MLS key schedule >> to seed the MLS group secrets computations by this external >> entropy. At any epoch, including the initial state, an >> application can decide to synchronize the injection of a PSK into >> the MLS key schedule. This mechanism can be used to improve >> security in the cases where having a full run of updates across >> members is too expensive or in the case where the external group >> key establishment mechanism provides stronger security against >> classical or quantum adversaries." >> >> As I understand this paragraph, the PSK is known by all group >> members and not related to new joiners. Maybe, the requirements >> and/or design changed in the meanwhile, and I am not aware of it. >> I interpreted the paragraph this way, since the current >> construction (posted below for convenience) also requires to know >> the commit_secret to derive the epoch_secret (from which the >> welcome_secret is derived). Where did I go wrong? >> >> Thanks! >> >> Chris >> >> init_secret_[n-1] (or 0) >> | >> V >> PSK (or 0) -> HKDF-Extract = early_secret >> | >> Derive-Secret(., "derived", "") >> | >> V >> commit_secret -> HKDF-Extract = epoch_secret >> >> >> On 24/07/2020 20:53, Richard Barnes wrote: >>> Hey Chris, >>> >>> I was looking again at the key schedule as I was drafting #362 >>> [1].  A couple of things occurred to me: >>> >>> 1. You can't add the commit secret and PSKs in the same >>> operation, because you want new joiners to put in the PSK, but >>> you don't want them to have to know the commit secret. >>> >>> 2. The nPRF construction you propose has the same number of HMAC >>> invocations as the chained-HKDF-Extract stuff that's in the >>> current draft / 362. >>> >>> Given those observations, I wonder how much an nPRF is really >>> buying us.  It's not saving us any HMAC calls, and relative to >>> #362, it would only coalesce two DPRF calls into one nPRF call. >>> >>> Maybe there's some benefit if there are multiple PSKs?  But even >>> then, it seems like you could add a layer, computing a synthetic >>> PSK from the multiple ones, and keeping the main key schedule >>> simple. >>> >>> At this point, given the above and the novelty of the nPRF >>> construction, I'm inclined to just stick with HKDF and merge >>> #362 instead of #336. >>> >>> --Richard >>> >>> >>> [1] https://github.com/mlswg/mls-protocol/pull/362 >>> >>> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >>> > wrote: >>> >>> Thank you for the pointer to Carter-Wegman MACs. >>> >>> >>> This style of combing hash outputs does affect collision >>> resistance [4], and some discussion on relation to that >>> would be nice to see. >>> >>> That's an excellent point. In addition to pseudorandomness, >>> we prove the collision-resistance of our construction. I.e., >>> assuming that no unique value is used twice and assuming >>> that HMAC is collision-resistance, then the final Expand >>> operation guarantees unique outputs. I.e., by including the >>> unique value into the final Expand operation after the xor, >>> the construction recovers from any collisions incurred by >>> the xor. >>> >>> Chris >>> >>> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>>> >>>> This is an interesting proposal. It is closely related at a >>>> high level to Carter-Wegman MACs (i.e. for random seed r, >>>> MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few >>>> MACs fall into this category in practice. Considering the >>>> use of a MAC-based KDF and the proofs of [3] on DPRFs, >>>> there is an overlap between NPRFs and extrapolation of the >>>> above (based on iteration of the PRF guarantees). >>>> >>>> This is worth noting from an assurance standpoint: there >>>> was discussion at the virtual interims with respect to the >>>> current formulation of MLS key derivation, which has a “TLS >>>> precedence”, yet this proposal is not without precedence >>>> itself. Ergo, such a change should not necessarily be >>>> concerning based on differing from current practice. >>>> >>>> This style of combing hash outputs does affect collision >>>> resistance [4], and some discussion on relation to that >>>> would be nice to see. >>>> >>>> Britta >>>> >>>> [1] Carter, Wegman. Universal classes of hash functions. >>>> >>>> [2] Carter, Wegman. New hash functions and their use in >>>> authentication and set equality. >>>> >>>> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from >>>> Standard Assumptions: A Generic Validation of an HMAC >>>> Assumption. >>>> >>>> [4] Bernstein. What output size resists collisions in a xor >>>> of independent expansions? >>>> >>>> *From: *MLS >>>> on behalf of Chris Brzuska >>>> >>>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>>> *To: *"mls@ietf.org" >>>> >>>> *Subject: *[MLS] Key Schedule: Replace DPRF with >>>> multi-input PRF (NPRF) >>>> >>>> Hi all, >>>> >>>> I would like to open a discussion on a suggestion for a >>>> change in the key schedule. In the current draft, we use >>>> the Extract function twice as a dual pseudorandom function >>>> (DPRF) when combining 3 keys (*) and interleave them with >>>> an Expand call. >>>> >>>> The suggestion [1] is to replace these 3 calls by a >>>> multi-input PRF (NPRF) which is especially designed to >>>> return a pseudorandom key when at least one of the input >>>> keys is pseudorandom. The new suggestion relies on standard >>>> PRF security rather than DPRF-security of Extract. >>>> >>>> You can find the accompanying paper with pictures, >>>> discussion and security reduction for the design principle >>>> here [2]. I include a summary of the main points in the end >>>> of this eMail. >>>> >>>> Please comment/share your opinion. Thanks! >>>> >>>> Chris >>>> >>>> (*) commit_secret, PSK and init_secret >>>> >>>> [1] Pull Request:https://github.com/mlswg/mls-protocol/pull/337 >>>> >>>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>>> >>>> *--------------------------------------------------------------------------------------------------------------------* >>>> >>>> *Summary of main points:* >>>> >>>> The current key schedule >>>> - uses Extract as a dual pseudorandom function and assumes >>>> that HMAC is a dual pseudorandom function >>>> - applies Extract after Expand, i.e., after applying a >>>> function which generates a pseudorandom value >>>> - iterates Extract-then-Expand sequentially to combine more >>>> than 2 keys >>>> >>>> The pull request suggests to >>>> - replace the ad-hoc assumption that Extract is a dual >>>> pseudorandom function >>>> - remove Extract steps when applied after Expand >>>> - use a provably secure NPRF construction which allows to >>>> combine more than 2 keys and is based on a standard PRF >>>> assumption and statistical properties of xor. >>>> >>>> Efficiency: >>>> - The suggested construction has higher parallel >>>> efficiency. It increases the overall number of HMAC >>>> evaluations by 1. >>>> >>>> Assumptions: >>>> - HMAC is a standard PRF. >>>> - Relies on a unique value, the group_context was suggested. >>>> >>>> Construction: >>>> (1) Use unique value to expand each key and xor the result >>>> (2) expand resulting key, including unique value into the >>>> context again >>>> >>>> Security argument: >>>> - Pseudorandomness: unique value ensures that each outcome >>>> of Expand in (1) is used only once in a xor combination, >>>> thus allowing on one-time pad argument of xor. >>>> - Uniqueness of resulting keys: (2) ensures that if HMAC is >>>> collision-resistent, then the result is collision-resistent. >>>> >>>> Variants: >>>> - It is possible to use an NPRF variant called NameNPRF [2] >>>> which has 3 HMAC evaluations more and relies less on the >>>> unique value. I.e., NameNPRF is secure in the same >>>> scenarios as DPRF: Keys only repeat if the input keys >>>> repeat *and* the group context repeats. >>>> >>>> Questions/Comments that came up: >>>> - Barnes, MacMillion suggested group_context as unique value >>>> - MacMillion wondered about removal of Extract: One can add >>>> an extract operation for the psk. For other input keys, it >>>> does not seem needed, since they were returned from Expand. >>>> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For >>>> uniqueness of output keys, the PRF needs to be >>>> collision-resistant, too. >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> --------------8591F5DB9CD872A453A1BEE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Richard,

I have a quick question: An additional change in your key schedule is that the welcome_secret is now derived before including the PSK. What is the motivation behind this?

Thanks!

Chris

On 24/07/2020 22:18, Chris Brzuska wrote:

I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first.

Will think about it, thanks for clarifying the requirements!

Chris

On 24/07/2020 21:47, Richard Barnes wrote:
Your confusion is understandable -- the document is wrong right now!  You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature.  The epoch secret should verify that *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as follows:

                  init_secret_[n-1] (or 0)
                        |
                        V
   commit_secret -> HKDF-Extract = joiner_secret
                        |
                        +--> Derive-Secret(., "welcome")
                        |    = welcome_secret
                        |
                        V
      PSK (or 0) -> HKDF-Extract = member_secret
                        |
                        V
GroupContext_[n] -> HKDF-Extract = epoch_secret

(I also promoted the GroupContext to the main key schedule.)  That's the context for my earlier comments.  With that picture, the only thing you're coalescing with nPRF would be the latter two HKDF-Extract calls.

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>  You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract = early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract = epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].  A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.  It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?  But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
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
--------------8591F5DB9CD872A453A1BEE0-- From nobody Sat Jul 25 14:14: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 83CC83A0AF4 for ; Sat, 25 Jul 2020 14:14:53 -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 7WEjQzYPOEGU for ; Sat, 25 Jul 2020 14:14:50 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 1002A3A0ABD for ; Sat, 25 Jul 2020 14:14:49 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id e3so5737383qvo.10 for ; Sat, 25 Jul 2020 14:14:49 -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=1mDwMjGVqOnihe/mv23FjLGEi4Go4E00IZAhWHVfofQ=; b=EZ6CLw8bChIUILb/rNpsf0zBCFIZJ7IwfZ77frZ6yIIL+7Tjq/QtB+R9vUiI/4sN3u GHtlNOtPG+5iUUa2NBvYUVzvd0eCykrHUM1ZIxqbamRwjkn7RwQmYVJnRamuBs4TxIBU 0VprH6WWo1HrSeHPH4YQ/wwaUbmqwsynERMrcbiuXwbXUROZug+vACswvAFOVdUbZ+aA 8+bDlo6uXIteQv9Ta9dxNf07GzgfLyCwce5E8P2EKKZoXp4lW3oxEfCRxeYYLC0jIadr 1KHh/k0+oGDVPa+G3AZLKWXZzB2Ntzm+y+/KhWjAeYQRNdbOEB4zKQe3jBrsNhe471cp 0fNg== 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=1mDwMjGVqOnihe/mv23FjLGEi4Go4E00IZAhWHVfofQ=; b=iHpmOm7LNd858ruXOCEheNzmi2Jx6v0ekLSxK39SK81xeO06Ig8LY7MDYl/S1DfZO6 WCEMrDBujEKTX9bKI/ZDGLQPdk7cdQ2V9D9dfX1A4LQOPSTCNNRFAzELQiDQEA6Cr9Wa 2kXYm8MywEmDzy5IQq2kK0bSv+H2CHpfJY130q2UvFjr2lTHA7WoDB0+LuMoteLTyNcO OIx0o1CtlXeoS0CH5D7ke79rYDxEhEo35Hz3b69MxXoVfgFm9UbBIVvhTi6iifuelDTg YMnafRfkzPalM+8AepcjLi9wTMizHuuqOIgCsyW8dgwSTn429lFBFxiNg3C0ncc6NecJ ZoQw== X-Gm-Message-State: AOAM53030ULrTCNrU6BrREWsHG36noXVoxbnZ8kcyXVl0lmiawT0RwUb 1mgrCZgW7bX4HkhM32uxd/Yu9VD0wnnXQn7B9huXilQJi1jzJw== X-Google-Smtp-Source: ABdhPJzfKAtFVAhkRaZzXyP5pWq24FZ5qjIexjqDrq+N5/UAUKBTHGOHUcUmIbw4AMmsv7VMYn7bgm0w5mxxjt9MFVI= X-Received: by 2002:a05:6214:1584:: with SMTP id m4mr15286004qvw.60.1595711688783; Sat, 25 Jul 2020 14:14:48 -0700 (PDT) MIME-Version: 1.0 References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> In-Reply-To: <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> From: Richard Barnes Date: Sat, 25 Jul 2020 17:14:20 -0400 Message-ID: To: Chris Brzuska Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000005fd71505ab4a9473" Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 25 Jul 2020 21:14:54 -0000 --0000000000005fd71505ab4a9473 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Think about the order of operations a new joiner goes through: 1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) using the relevant HPKE private key 2. Compute the welcome_secret, welcome_key, and welcome_nonce 3. Decrypt the GroupInfo using the welcome_key and welcome_nonce My presumption is that the joiner will only know that it needs the PSK after step 3, when it can read the GroupInfo extensions. (See https://github.com/mlswg/mls-protocol/issues/367) That means that the welcome_secret can't depend on the PSK. On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska wrote: > Hi Richard, > > I have a quick question: An additional change in your key schedule is tha= t > the welcome_secret is now derived *before* including the PSK. What is the > motivation behind this? > > Thanks! > > Chris > > On 24/07/2020 22:18, Chris Brzuska wrote: > > I see, thanks for clarifying. Obviously, with these requirements, pull > request #336 does not work as is. I think that the conceptual issue of ho= w > to best combine two, three keys and more keys, remains, now with an > additional requirement to combine two keys separately first. > > Will think about it, thanks for clarifying the requirements! > Chris > > On 24/07/2020 21:47, Richard Barnes wrote: > > Your confusion is understandable -- the document is wrong right now! You > are correct that the current design prohibits new joiners from > participating in the PSK proof, but that's a bug, not a feature. The epo= ch > secret should verify that *all members of the current epoch* know the PSK= , > not just the ones inherited from the last epoch. > > That's why #362 rearranges the key schedule as follows: > > init_secret_[n-1] (or 0) > | > V > commit_secret -> HKDF-Extract =3D joiner_secret > | > +--> Derive-Secret(., "welcome") > | =3D welcome_secret > | > V > PSK (or 0) -> HKDF-Extract =3D member_secret > | > V > GroupContext_[n] -> HKDF-Extract =3D epoch_secret > > (I also promoted the GroupContext to the main key schedule.) That's the > context for my earlier comments. With that picture, the only thing you'r= e > coalescing with nPRF would be the latter two HKDF-Extract calls. > > Hope that helps, > --Richard > > > > On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska > wrote: > >> Hey Richard, >> >> thank you for looking into this. I think, I need more explanation to >> understand the following point: >> >>> You can't add the commit secret and PSKs in the same operation, >> because you want new joiners to put in the PSK, but you don't want them = to >> have to know the commit secret. >> >> The current draft sais the following about the PSK: >> "Groups which already have an out-of-band mechanism to generate *shared* >> group secrets can inject those in the MLS key schedule to seed the MLS >> group secrets computations by this external entropy. At any epoch, >> including the initial state, an application can decide to synchronize th= e >> injection of a PSK into the MLS key schedule. This mechanism can be used= to >> improve security in the cases where having a full run of updates across >> members is too expensive or in the case where the external group key >> establishment mechanism provides stronger security against classical or >> quantum adversaries." >> >> As I understand this paragraph, the PSK is known by all group members an= d >> not related to new joiners. Maybe, the requirements and/or design change= d >> in the meanwhile, and I am not aware of it. I interpreted the paragraph >> this way, since the current construction (posted below for convenience) >> also requires to know the commit_secret to derive the epoch_secret (from >> which the welcome_secret is derived). Where did I go wrong? >> >> Thanks! >> >> Chris >> >> init_secret_[n-1] (or 0) >> | >> V >> PSK (or 0) -> HKDF-Extract =3D early_secret >> | >> Derive-Secret(., "derived", "") >> | >> V >> commit_secret -> HKDF-Extract =3D epoch_secret >> >> >> On 24/07/2020 20:53, Richard Barnes wrote: >> >> Hey Chris, >> >> I was looking again at the key schedule as I was drafting #362 [1]. A >> couple of things occurred to me: >> >> 1. You can't add the commit secret and PSKs in the same operation, >> because you want new joiners to put in the PSK, but you don't want them = to >> have to know the commit secret. >> >> 2. The nPRF construction you propose has the same number of HMAC >> invocations as the chained-HKDF-Extract stuff that's in the current draf= t / >> 362. >> >> Given those observations, I wonder how much an nPRF is really buying us. >> It's not saving us any HMAC calls, and relative to #362, it would only >> coalesce two DPRF calls into one nPRF call. >> >> Maybe there's some benefit if there are multiple PSKs? But even then, i= t >> seems like you could add a layer, computing a synthetic PSK from the >> multiple ones, and keeping the main key schedule simple. >> >> At this point, given the above and the novelty of the nPRF construction, >> I'm inclined to just stick with HKDF and merge #362 instead of #336. >> >> --Richard >> >> >> [1] https://github.com/mlswg/mls-protocol/pull/362 >> >> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >> wrote: >> >>> Thank you for the pointer to Carter-Wegman MACs. >>> >>> >>> This style of combing hash outputs does affect collision resistance >>> [4], and some discussion on relation to that would be nice to see. >>> >>> That's an excellent point. In addition to pseudorandomness, we prove th= e >>> collision-resistance of our construction. I.e., assuming that no unique >>> value is used twice and assuming that HMAC is collision-resistance, the= n >>> the final Expand operation guarantees unique outputs. I.e., by includin= g >>> the unique value into the final Expand operation after the xor, the >>> construction recovers from any collisions incurred by the xor. >>> >>> Chris >>> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>> >>> This is an interesting proposal. It is closely related at a high level >>> to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D PR= F(k1, >>> r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practic= e. >>> Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, >>> there is an overlap between NPRFs and extrapolation of the above (based= on >>> iteration of the PRF guarantees). >>> >>> >>> >>> This is worth noting from an assurance standpoint: there was discussion >>> at the virtual interims with respect to the current formulation of MLS = key >>> derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet this prop= osal is not without >>> precedence itself. Ergo, such a change should not necessarily be concer= ning >>> based on differing from current practice. >>> >>> >>> >>> This style of combing hash outputs does affect collision resistance [4]= , >>> and some discussion on relation to that would be nice to see. >>> >>> >>> >>> Britta >>> >>> >>> >>> >>> >>> >>> >>> [1] Carter, Wegman. Universal classes of hash functions. >>> >>> [2] Carter, Wegman. New hash functions and their use in authentication >>> and set equality. >>> >>> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard >>> Assumptions: A Generic Validation of an HMAC Assumption. >>> >>> [4] Bernstein. What output size resists collisions in a xor of >>> independent expansions? >>> >>> >>> >>> >>> >>> >>> >>> *From: *MLS on behalf of >>> Chris Brzuska >>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>> *To: *"mls@ietf.org" >>> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) >>> >>> >>> >>> Hi all, >>> >>> I would like to open a discussion on a suggestion for a change in the >>> key schedule. In the current draft, we use the Extract function twice a= s a >>> dual pseudorandom function (DPRF) when combining 3 keys (*) and interle= ave >>> them with an Expand call. >>> >>> The suggestion [1] is to replace these 3 calls by a multi-input PRF >>> (NPRF) which is especially designed to return a pseudorandom key when a= t >>> least one of the input keys is pseudorandom. The new suggestion relies = on >>> standard PRF security rather than DPRF-security of Extract. >>> >>> You can find the accompanying paper with pictures, discussion and >>> security reduction for the design principle here [2]. I include a summa= ry >>> of the main points in the end of this eMail. >>> >>> Please comment/share your opinion. Thanks! >>> >>> Chris >>> >>> (*) commit_secret, PSK and init_secret >>> >>> [1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337 >>> >>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>> >>> >>> *----------------------------------------------------------------------= ----------------------------------------------* >>> >>> *Summary of main points:* >>> >>> The current key schedule >>> - uses Extract as a dual pseudorandom function and assumes that HMAC is >>> a dual pseudorandom function >>> - applies Extract after Expand, i.e., after applying a function which >>> generates a pseudorandom value >>> - iterates Extract-then-Expand sequentially to combine more than 2 keys >>> >>> The pull request suggests to >>> - replace the ad-hoc assumption that Extract is a dual pseudorandom >>> function >>> - remove Extract steps when applied after Expand >>> - use a provably secure NPRF construction which allows to combine more >>> than 2 keys and is based on a standard PRF assumption and statistical >>> properties of xor. >>> >>> Efficiency: >>> - The suggested construction has higher parallel efficiency. It >>> increases the overall number of HMAC evaluations by 1. >>> >>> Assumptions: >>> - HMAC is a standard PRF. >>> - Relies on a unique value, the group_context was suggested. >>> >>> Construction: >>> (1) Use unique value to expand each key and xor the result >>> (2) expand resulting key, including unique value into the context again >>> >>> Security argument: >>> - Pseudorandomness: unique value ensures that each outcome of Expand in >>> (1) is used only once in a xor combination, thus allowing on one-time p= ad >>> argument of xor. >>> - Uniqueness of resulting keys: (2) ensures that if HMAC is >>> collision-resistent, then the result is collision-resistent. >>> >>> Variants: >>> - It is possible to use an NPRF variant called NameNPRF [2] which has 3 >>> HMAC evaluations more and relies less on the unique value. I.e., NameNP= RF >>> is secure in the same scenarios as DPRF: Keys only repeat if the input = keys >>> repeat *and* the group context repeats. >>> >>> Questions/Comments that came up: >>> - Barnes, MacMillion suggested group_context as unique value >>> - MacMillion wondered about removal of Extract: One can add an extract >>> operation for the psk. For other input keys, it does not seem needed, s= ince >>> they were returned from Expand. >>> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of >>> output keys, the PRF needs to be collision-resistant, too. >>> >>> _______________________________________________ >>> MLS mailing listMLS@ietf.orghttps://www.ietf.org/mailman/listinfo/mls >>> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> --0000000000005fd71505ab4a9473 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Think about the order of operations a new joiner goes= through:

1. Decrypt the EncryptedGroupSecrets (in= cluding the joiner_secret) using the relevant HPKE private key
2. Compute the welcome_secret, welcome_key, and welcome_nonce
3= . Decrypt the GroupInfo using the welcome_key and welcome_nonce
<= div>
My presumption is that the joiner will only know that it needs the PSK=20 after step 3, when it can read the GroupInfo extensions.=C2=A0 (See htt= ps://github.com/mlswg/mls-protocol/issues/367)=C2=A0 That means that th= e welcome_secret can't depend on the PSK.

On Sat, Jul 25, 2020 at = 4:09 PM Chris Brzuska <chris.b= rzuska@aalto.fi> wrote:
=20 =20 =20

Hi Richard,

I have a quick question: An additional change in your key schedule is that the welcome_secret is now derived before including the PSK. What is the motivation behind this?

Thanks!

Chris

On 24/07/2020 22:18, Chris Brzuska wrote:

=20

I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first.

Will think about it, thanks for clarifying the requirements!

Chris

On 24/07/2020 21:47, Richard Barnes wrote:
=20
Your confusion is understandable -- the document is wrong right now!=C2=A0 You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature.=C2=A0 The epoch secret sho= uld verify that *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as follows:<= /div>

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 init_secret_[n-1] (or 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0commit_secret -> HKDF-Extract =3D joiner_secr= et
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--> Derive-Secret(., "welcome")
=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=3D welcome_secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0 =C2=A0 PSK (or 0) -> HKDF-Extract =3D member= _secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 V
GroupContext_[n] -> HKDF-Extract =3D epoch_secret

(I also promoted the GroupContext to the main key schedule.)=C2=A0 That's the context for my earlier comments= .=C2=A0 With that picture, the only thing you're coalescing with nPRF would be the latter two HKDF-Extract calls.

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>=C2=A0 You can't add the commit secret and = PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechani= sm to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract =3D early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract =3D epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].=C2=A0 A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to hav= e to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.=C2=A0 It's not saving u= s any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?=C2=A0 But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D=C2=A0 PRF= (k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

=C2=A0

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

=C2=A0

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

=C2=A0

Britta

=C2=A0

=C2=A0

=C2=A0

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3= ] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4= ] Bernstein. What output size resists collisions in a xor of independent expansions?

=C2=A0

=C2=A0

=C2=A0

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>= ;
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

=C2=A0

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

-----------------------------------------= ---------------------------------------------------------------------------=

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


____________________________________________=
___
MLS mailing list
MLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS= @ietf.org
https://www.ietf.org/mailman/listinfo= /mls
--0000000000005fd71505ab4a9473-- From nobody Sat Jul 25 14:36: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 B41A03A087F for ; Sat, 25 Jul 2020 14:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=aalto.fi 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 GAvwMbuy2RJz for ; Sat, 25 Jul 2020 14:36:50 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 4181F3A087D for ; Sat, 25 Jul 2020 14:36:48 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 317422713F0_F1CA5EEB; Sat, 25 Jul 2020 21:36:46 +0000 (GMT) Received: from exng4.org.aalto.fi (exng4.org.aalto.fi [130.233.223.23]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng4.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id AB53427138F_F1CA5EDF; Sat, 25 Jul 2020 21:36:45 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng4.org.aalto.fi (130.233.223.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 26 Jul 2020 00:36:45 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 26 Jul 2020 00:36:45 +0300 To: Richard Barnes CC: Messaging Layer Security WG References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> From: Chris Brzuska Message-ID: <7c3c0f7f-58d2-acfb-d5d6-e8e5e80299da@aalto.fi> Date: Sun, 26 Jul 2020 00:36:44 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4EC37C874B10A6B6185A4D37" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng5.org.aalto.fi (130.233.223.24) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:cc:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=J+YoIJ+hF2PoXkvo0kmKw8RTBRSngHBGI65Pqp+ROYY=; b=raq6WdNN9Qzn7cF3rA3IFiqEF5fFIys61siHah7xxUDX618ffnl2t0BSCAiJslc2cw/84LvomVDrcNIoTAIiK81VYtMr6SGaGTefn6F3AbkSn/G2L8oveHehpg7JG6YolVl3fc3/gfYaoCWtk0kRwecfy8UnrGswP4KxbKUdBmafXw1brisQvz37ZvLImfD/oTabSQCKzhQv4d94rfPDphBKkj7aLnQeABR8nO615+FpYx5jKzi7l43+VwCWOLk5sHW8x4LP+bHMjgTjwzTgojkW3yOyuokNlLJIY5RFKsKabHivsZE6wDLbkxDh2c7UZ4HDbKJSmXsfVy9tM7zrTg== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 25 Jul 2020 21:36:54 -0000 --------------4EC37C874B10A6B6185A4D37 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Thanks! Another clarification question: I am confused about why GroupInfo and GroupSecrets are not encrypted using the same key? Since the welcome_secret can be derived from the GroupSecrets, the use of the welcome_secret does not seem to add security. Is this an efficiency optimization? Chris On 26/07/2020 00:14, Richard Barnes wrote: > Think about the order of operations a new joiner goes through: > > 1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) > using the relevant HPKE private key > 2. Compute the welcome_secret, welcome_key, and welcome_nonce > 3. Decrypt the GroupInfo using the welcome_key and welcome_nonce > > My presumption is that the joiner will only know that it needs the PSK > after step 3, when it can read the GroupInfo extensions.  (See > https://github.com/mlswg/mls-protocol/issues/367) That means that the > welcome_secret can't depend on the PSK. > > On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska > wrote: > > Hi Richard, > > I have a quick question: An additional change in your key schedule > is that the welcome_secret is now derived *before* including the > PSK. What is the motivation behind this? > > Thanks! > > Chris > > On 24/07/2020 22:18, Chris Brzuska wrote: > >> I see, thanks for clarifying. Obviously, with these requirements, >> pull request #336 does not work as is. I think that the >> conceptual issue of how to best combine two, three keys and more >> keys, remains, now with an additional requirement to combine two >> keys separately first. >> >> Will think about it, thanks for clarifying the requirements! >> >> Chris >> >> On 24/07/2020 21:47, Richard Barnes wrote: >>> Your confusion is understandable -- the document is wrong right >>> now!  You are correct that the current design prohibits new >>> joiners from participating in the PSK proof, but that's a bug, >>> not a feature.  The epoch secret should verify that *all members >>> of the current epoch* know the PSK, not just the ones inherited >>> from the last epoch. >>> >>> That's why #362 rearranges the key schedule as follows: >>> >>>     init_secret_[n-1] (or 0) >>>                         | >>>                         V >>>    commit_secret -> HKDF-Extract = joiner_secret >>>                         | >>>                         +--> Derive-Secret(., "welcome") >>>                         |    = welcome_secret >>>                         | >>>                         V >>>       PSK (or 0) -> HKDF-Extract = member_secret >>>                         | >>>                         V >>> GroupContext_[n] -> HKDF-Extract = epoch_secret >>> >>> (I also promoted the GroupContext to the main key schedule.)  >>> That's the context for my earlier comments.  With that picture, >>> the only thing you're coalescing with nPRF would be the latter >>> two HKDF-Extract calls. >>> >>> Hope that helps, >>> --Richard >>> >>> >>> >>> On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska >>> > wrote: >>> >>> Hey Richard, >>> >>> thank you for looking into this. I think, I need more >>> explanation to understand the following point: >>> >>> >>>  You can't add the commit secret and PSKs in the same >>> operation, because you want new joiners to put in the PSK, >>> but you don't want them to have to know the commit secret. >>> >>> The current draft sais the following about the PSK: >>> "Groups which already have an out-of-band mechanism to >>> generate *shared* group secrets can inject those in the MLS >>> key schedule to seed the MLS group secrets computations by >>> this external entropy. At any epoch, including the initial >>> state, an application can decide to synchronize the >>> injection of a PSK into the MLS key schedule. This mechanism >>> can be used to improve security in the cases where having a >>> full run of updates across members is too expensive or in >>> the case where the external group key establishment >>> mechanism provides stronger security against classical or >>> quantum adversaries." >>> >>> As I understand this paragraph, the PSK is known by all >>> group members and not related to new joiners. Maybe, the >>> requirements and/or design changed in the meanwhile, and I >>> am not aware of it. I interpreted the paragraph this way, >>> since the current construction (posted below for >>> convenience) also requires to know the commit_secret to >>> derive the epoch_secret (from which the welcome_secret is >>> derived). Where did I go wrong? >>> >>> Thanks! >>> >>> Chris >>> >>> init_secret_[n-1] (or 0) >>> | >>> V >>> PSK (or 0) -> HKDF-Extract = early_secret >>> | >>> Derive-Secret(., "derived", "") >>> | >>> V >>> commit_secret -> HKDF-Extract = epoch_secret >>> >>> >>> On 24/07/2020 20:53, Richard Barnes wrote: >>>> Hey Chris, >>>> >>>> I was looking again at the key schedule as I was drafting >>>> #362 [1].  A couple of things occurred to me: >>>> >>>> 1. You can't add the commit secret and PSKs in the same >>>> operation, because you want new joiners to put in the PSK, >>>> but you don't want them to have to know the commit secret. >>>> >>>> 2. The nPRF construction you propose has the same number of >>>> HMAC invocations as the chained-HKDF-Extract stuff that's >>>> in the current draft / 362. >>>> >>>> Given those observations, I wonder how much an nPRF is >>>> really buying us.  It's not saving us any HMAC calls, and >>>> relative to #362, it would only coalesce two DPRF calls >>>> into one nPRF call. >>>> >>>> Maybe there's some benefit if there are multiple PSKs?  But >>>> even then, it seems like you could add a layer, computing a >>>> synthetic PSK from the multiple ones, and keeping the main >>>> key schedule simple. >>>> >>>> At this point, given the above and the novelty of the nPRF >>>> construction, I'm inclined to just stick with HKDF and >>>> merge #362 instead of #336. >>>> >>>> --Richard >>>> >>>> >>>> [1] https://github.com/mlswg/mls-protocol/pull/362 >>>> >>>> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >>>> > wrote: >>>> >>>> Thank you for the pointer to Carter-Wegman MACs. >>>> >>>> >>> This style of combing hash outputs does affect >>>> collision resistance [4], and some discussion on >>>> relation to that would be nice to see. >>>> >>>> That's an excellent point. In addition to >>>> pseudorandomness, we prove the collision-resistance of >>>> our construction. I.e., assuming that no unique value >>>> is used twice and assuming that HMAC is >>>> collision-resistance, then the final Expand operation >>>> guarantees unique outputs. I.e., by including the >>>> unique value into the final Expand operation after the >>>> xor, the construction recovers from any collisions >>>> incurred by the xor. >>>> >>>> Chris >>>> >>>> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>>>> >>>>> This is an interesting proposal. It is closely related >>>>> at a high level to Carter-Wegman MACs (i.e. for random >>>>> seed r, MAC((k1, k2), m) = PRF(k1, r) XOR MAC(k2, m)). >>>>> Quite a few MACs fall into this category in practice. >>>>> Considering the use of a MAC-based KDF and the proofs >>>>> of [3] on DPRFs, there is an overlap between NPRFs and >>>>> extrapolation of the above (based on iteration of the >>>>> PRF guarantees). >>>>> >>>>> This is worth noting from an assurance standpoint: >>>>> there was discussion at the virtual interims with >>>>> respect to the current formulation of MLS key >>>>> derivation, which has a “TLS precedence”, yet this >>>>> proposal is not without precedence itself. Ergo, such >>>>> a change should not necessarily be concerning based on >>>>> differing from current practice. >>>>> >>>>> This style of combing hash outputs does affect >>>>> collision resistance [4], and some discussion on >>>>> relation to that would be nice to see. >>>>> >>>>> Britta >>>>> >>>>> [1] Carter, Wegman. Universal classes of hash functions. >>>>> >>>>> [2] Carter, Wegman. New hash functions and their use >>>>> in authentication and set equality. >>>>> >>>>> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs >>>>> from Standard Assumptions: A Generic Validation of an >>>>> HMAC Assumption. >>>>> >>>>> [4] Bernstein. What output size resists collisions in >>>>> a xor of independent expansions? >>>>> >>>>> *From: *MLS >>>>> on behalf of Chris >>>>> Brzuska >>>>> >>>>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>>>> *To: *"mls@ietf.org" >>>>> >>>>> *Subject: *[MLS] Key Schedule: Replace DPRF with >>>>> multi-input PRF (NPRF) >>>>> >>>>> Hi all, >>>>> >>>>> I would like to open a discussion on a suggestion for >>>>> a change in the key schedule. In the current draft, we >>>>> use the Extract function twice as a dual pseudorandom >>>>> function (DPRF) when combining 3 keys (*) and >>>>> interleave them with an Expand call. >>>>> >>>>> The suggestion [1] is to replace these 3 calls by a >>>>> multi-input PRF (NPRF) which is especially designed to >>>>> return a pseudorandom key when at least one of the >>>>> input keys is pseudorandom. The new suggestion relies >>>>> on standard PRF security rather than DPRF-security of >>>>> Extract. >>>>> >>>>> You can find the accompanying paper with pictures, >>>>> discussion and security reduction for the design >>>>> principle here [2]. I include a summary of the main >>>>> points in the end of this eMail. >>>>> >>>>> Please comment/share your opinion. Thanks! >>>>> >>>>> Chris >>>>> >>>>> (*) commit_secret, PSK and init_secret >>>>> >>>>> [1] Pull >>>>> Request:https://github.com/mlswg/mls-protocol/pull/337 >>>>> >>>>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>>>> >>>>> *--------------------------------------------------------------------------------------------------------------------* >>>>> >>>>> *Summary of main points:* >>>>> >>>>> The current key schedule >>>>> - uses Extract as a dual pseudorandom function and >>>>> assumes that HMAC is a dual pseudorandom function >>>>> - applies Extract after Expand, i.e., after applying a >>>>> function which generates a pseudorandom value >>>>> - iterates Extract-then-Expand sequentially to combine >>>>> more than 2 keys >>>>> >>>>> The pull request suggests to >>>>> - replace the ad-hoc assumption that Extract is a dual >>>>> pseudorandom function >>>>> - remove Extract steps when applied after Expand >>>>> - use a provably secure NPRF construction which allows >>>>> to combine more than 2 keys and is based on a standard >>>>> PRF assumption and statistical properties of xor. >>>>> >>>>> Efficiency: >>>>> - The suggested construction has higher parallel >>>>> efficiency. It increases the overall number of HMAC >>>>> evaluations by 1. >>>>> >>>>> Assumptions: >>>>> - HMAC is a standard PRF. >>>>> - Relies on a unique value, the group_context was >>>>> suggested. >>>>> >>>>> Construction: >>>>> (1) Use unique value to expand each key and xor the result >>>>> (2) expand resulting key, including unique value into >>>>> the context again >>>>> >>>>> Security argument: >>>>> - Pseudorandomness: unique value ensures that each >>>>> outcome of Expand in (1) is used only once in a xor >>>>> combination, thus allowing on one-time pad argument of >>>>> xor. >>>>> - Uniqueness of resulting keys: (2) ensures that if >>>>> HMAC is collision-resistent, then the result is >>>>> collision-resistent. >>>>> >>>>> Variants: >>>>> - It is possible to use an NPRF variant called >>>>> NameNPRF [2] which has 3 HMAC evaluations more and >>>>> relies less on the unique value. I.e., NameNPRF is >>>>> secure in the same scenarios as DPRF: Keys only repeat >>>>> if the input keys repeat *and* the group context repeats. >>>>> >>>>> Questions/Comments that came up: >>>>> - Barnes, MacMillion suggested group_context as unique >>>>> value >>>>> - MacMillion wondered about removal of Extract: One >>>>> can add an extract operation for the psk. For other >>>>> input keys, it does not seem needed, since they were >>>>> returned from Expand. >>>>> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For >>>>> uniqueness of output keys, the PRF needs to be >>>>> collision-resistant, too. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> --------------4EC37C874B10A6B6185A4D37 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thanks!

Another clarification question: I am confused about why GroupInfo and GroupSecrets are not encrypted using the same key? Since the welcome_secret can be derived from the GroupSecrets, the use of the welcome_secret does not seem to add security. Is this an efficiency optimization?

Chris

On 26/07/2020 00:14, Richard Barnes wrote:
Think about the order of operations a new joiner goes through:

1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) using the relevant HPKE private key
2. Compute the welcome_secret, welcome_key, and welcome_nonce
3. Decrypt the GroupInfo using the welcome_key and welcome_nonce

My presumption is that the joiner will only know that it needs the PSK after step 3, when it can read the GroupInfo extensions.  (See https://github.com/mlswg/mls-protocol/issues/367)  That means that the welcome_secret can't depend on the PSK.

On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hi Richard,

I have a quick question: An additional change in your key schedule is that the welcome_secret is now derived before including the PSK. What is the motivation behind this?

Thanks!

Chris

On 24/07/2020 22:18, Chris Brzuska wrote:

I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first.

Will think about it, thanks for clarifying the requirements!

Chris

On 24/07/2020 21:47, Richard Barnes wrote:
Your confusion is understandable -- the document is wrong right now!  You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature.  The epoch secret should verify that *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as follows:

                  init_secret_[n-1] (or 0)
                        |
                        V
   commit_secret -> HKDF-Extract = joiner_secret
                        |
                        +--> Derive-Secret(., "welcome")
                        |    = welcome_secret
                        |
                        V
      PSK (or 0) -> HKDF-Extract = member_secret
                        |
                        V
GroupContext_[n] -> HKDF-Extract = epoch_secret

(I also promoted the GroupContext to the main key schedule.)  That's the context for my earlier comments.  With that picture, the only thing you're coalescing with nPRF would be the latter two HKDF-Extract calls.

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>  You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract = early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract = epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].  A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.  It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?  But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
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
--------------4EC37C874B10A6B6185A4D37-- From nobody Sat Jul 25 15:01:24 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 69AEE3A0B3D for ; Sat, 25 Jul 2020 15:01: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=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 11Jcgh-tOWCI for ; Sat, 25 Jul 2020 15:01:19 -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 1EF953A0B3C for ; Sat, 25 Jul 2020 15:01:18 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id s23so9549414qtq.12 for ; Sat, 25 Jul 2020 15:01: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=/zaIqwPTZDNiPLSrIbbdguY5n5oNDFzAlIe4C8IvZYg=; b=uFy302HteHcSzpgR6vx1AqOjh3UYkwhG/sLBMzR+mfnUESwedF7zD5J2/DipT/bokm ApDnblxE4oJj5nlfrlll14DceE7RR4nT5fLd42eZverTSBhNGjAaEnZZE6/blrXiOrVS G8F0EKXI/zzMARSPgOdO9GbuKLyTmYVsdWCJoSwAeJrBhBp325fWSqkmP+puHHSZ7b89 sQ9P9MkPguu2Zu+P3bJ7otHghUSzMGswy+XbYUEZE+oQyBLQV/6hfkRDgBUJbD8ptdlb qNZMjECYg8r6Q93Xy6/OBJgUWapjYCxhMSO8BwiZaX5V8BmuiDJxQTeV1N/oxSQ/I2g1 kjfg== 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=/zaIqwPTZDNiPLSrIbbdguY5n5oNDFzAlIe4C8IvZYg=; b=ne+86YhqBxmDkcUsFhv5rYpuMRudGf69QTkqjQ757syaLlwRu13x/LYn0VoEKqgK+c WslXz3xHKxnP13hiAWH6+04DMSaymVKie/pNdk6GdeKnclcam3FWcCYGN/wJ5WHzJ3h6 2J+hvcgwHB3oh/239AgbkXirREjY1Z2Gn2ZunF40GzIwRklvCKmJk8h2Mwy07YYX+V/Y YFVLgdi4qz/YACnI7jlwptzOObq2Teey0EehPai6aMisJmtUl57yToxAVZmGkavlIgcB R+KwucP/nj68AipLlfHxriQ/9u1eVEibiBFShWzUy+WEm/MzxPsXWzIV1rTZcniZ/Yrp pIwQ== X-Gm-Message-State: AOAM531L1qIxoZqvtxmSm7YU4AYmppz5W2MDR5SmBe4wuV2KXnd5UBUf gEbGtH1f1Vf78nkDqmqAUDeBbt4wpr69VGwOzKXOKgi89tY= X-Google-Smtp-Source: ABdhPJw7dRRszfYjQF1tFbUVZhYC/oFOjnk1RWyZcdMfYhb+xe9v0M+TIiMFr2EOxrGT0vx+9PYRK0SOIRKWhXtAbQM= X-Received: by 2002:ac8:5207:: with SMTP id r7mr15561455qtn.191.1595714477562; Sat, 25 Jul 2020 15:01:17 -0700 (PDT) MIME-Version: 1.0 References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> <7c3c0f7f-58d2-acfb-d5d6-e8e5e80299da@aalto.fi> In-Reply-To: <7c3c0f7f-58d2-acfb-d5d6-e8e5e80299da@aalto.fi> From: Richard Barnes Date: Sat, 25 Jul 2020 18:01:06 -0400 Message-ID: To: Chris Brzuska Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000009931b905ab4b3a05" Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 25 Jul 2020 22:01:23 -0000 --0000000000009931b905ab4b3a05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct, it=E2=80=99s for efficiency. It lets you encrypt one copy of the GroupInfo and send it to many new joiners. If the group is large and the Welcome carries the tree, this is a significant savings, especially if you=E2=80=99re adding multiple new members in the epoch. On Sat, Jul 25, 2020 at 17:36 Chris Brzuska wrote: > Thanks! > > Another clarification question: I am confused about why GroupInfo and > GroupSecrets are not encrypted using the same key? Since the welcome_secr= et > can be derived from the GroupSecrets, the use of the welcome_secret does > not seem to add security. Is this an efficiency optimization? > > > Chris > > On 26/07/2020 00:14, Richard Barnes wrote: > > Think about the order of operations a new joiner goes through: > > 1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) using > the relevant HPKE private key > 2. Compute the welcome_secret, welcome_key, and welcome_nonce > 3. Decrypt the GroupInfo using the welcome_key and welcome_nonce > > My presumption is that the joiner will only know that it needs the PSK > after step 3, when it can read the GroupInfo extensions. (See > https://github.com/mlswg/mls-protocol/issues/367) That means that the > welcome_secret can't depend on the PSK. > > On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska > wrote: > >> Hi Richard, >> >> I have a quick question: An additional change in your key schedule is >> that the welcome_secret is now derived *before* including the PSK. What >> is the motivation behind this? >> >> Thanks! >> >> Chris >> >> On 24/07/2020 22:18, Chris Brzuska wrote: >> >> I see, thanks for clarifying. Obviously, with these requirements, pull >> request #336 does not work as is. I think that the conceptual issue of h= ow >> to best combine two, three keys and more keys, remains, now with an >> additional requirement to combine two keys separately first. >> >> Will think about it, thanks for clarifying the requirements! >> Chris >> >> On 24/07/2020 21:47, Richard Barnes wrote: >> >> Your confusion is understandable -- the document is wrong right now! Yo= u >> are correct that the current design prohibits new joiners from >> participating in the PSK proof, but that's a bug, not a feature. The ep= och >> secret should verify that *all members of the current epoch* know the PS= K, >> not just the ones inherited from the last epoch. >> >> That's why #362 rearranges the key schedule as follows: >> >> init_secret_[n-1] (or 0) >> | >> V >> commit_secret -> HKDF-Extract =3D joiner_secret >> | >> +--> Derive-Secret(., "welcome") >> | =3D welcome_secret >> | >> V >> PSK (or 0) -> HKDF-Extract =3D member_secret >> | >> V >> GroupContext_[n] -> HKDF-Extract =3D epoch_secret >> >> (I also promoted the GroupContext to the main key schedule.) That's the >> context for my earlier comments. With that picture, the only thing you'= re >> coalescing with nPRF would be the latter two HKDF-Extract calls. >> >> Hope that helps, >> --Richard >> >> >> >> On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska >> wrote: >> >>> Hey Richard, >>> >>> thank you for looking into this. I think, I need more explanation to >>> understand the following point: >>> >>> You can't add the commit secret and PSKs in the same operation, >>> because you want new joiners to put in the PSK, but you don't want them= to >>> have to know the commit secret. >>> >>> The current draft sais the following about the PSK: >>> "Groups which already have an out-of-band mechanism to generate *shared= * >>> group secrets can inject those in the MLS key schedule to seed the MLS >>> group secrets computations by this external entropy. At any epoch, >>> including the initial state, an application can decide to synchronize t= he >>> injection of a PSK into the MLS key schedule. This mechanism can be use= d to >>> improve security in the cases where having a full run of updates across >>> members is too expensive or in the case where the external group key >>> establishment mechanism provides stronger security against classical or >>> quantum adversaries." >>> >>> As I understand this paragraph, the PSK is known by all group members >>> and not related to new joiners. Maybe, the requirements and/or design >>> changed in the meanwhile, and I am not aware of it. I interpreted the >>> paragraph this way, since the current construction (posted below for >>> convenience) also requires to know the commit_secret to derive the >>> epoch_secret (from which the welcome_secret is derived). Where did I go >>> wrong? >>> >>> Thanks! >>> >>> Chris >>> >>> init_secret_[n-1] (or 0) >>> | >>> V >>> PSK (or 0) -> HKDF-Extract =3D early_secret >>> | >>> Derive-Secret(., "derived", "") >>> | >>> V >>> commit_secret -> HKDF-Extract =3D epoch_secret >>> >>> >>> On 24/07/2020 20:53, Richard Barnes wrote: >>> >>> Hey Chris, >>> >>> I was looking again at the key schedule as I was drafting #362 [1]. A >>> couple of things occurred to me: >>> >>> 1. You can't add the commit secret and PSKs in the same operation, >>> because you want new joiners to put in the PSK, but you don't want them= to >>> have to know the commit secret. >>> >>> 2. The nPRF construction you propose has the same number of HMAC >>> invocations as the chained-HKDF-Extract stuff that's in the current dra= ft / >>> 362. >>> >>> Given those observations, I wonder how much an nPRF is really buying >>> us. It's not saving us any HMAC calls, and relative to #362, it would = only >>> coalesce two DPRF calls into one nPRF call. >>> >>> Maybe there's some benefit if there are multiple PSKs? But even then, >>> it seems like you could add a layer, computing a synthetic PSK from the >>> multiple ones, and keeping the main key schedule simple. >>> >>> At this point, given the above and the novelty of the nPRF construction= , >>> I'm inclined to just stick with HKDF and merge #362 instead of #336. >>> >>> --Richard >>> >>> >>> [1] https://github.com/mlswg/mls-protocol/pull/362 >>> >>> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >>> wrote: >>> >>>> Thank you for the pointer to Carter-Wegman MACs. >>>> >>>> >>> This style of combing hash outputs does affect collision resistanc= e >>>> [4], and some discussion on relation to that would be nice to see. >>>> >>>> That's an excellent point. In addition to pseudorandomness, we prove >>>> the collision-resistance of our construction. I.e., assuming that no u= nique >>>> value is used twice and assuming that HMAC is collision-resistance, th= en >>>> the final Expand operation guarantees unique outputs. I.e., by includi= ng >>>> the unique value into the final Expand operation after the xor, the >>>> construction recovers from any collisions incurred by the xor. >>>> >>>> Chris >>>> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>>> >>>> This is an interesting proposal. It is closely related at a high level >>>> to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D P= RF(k1, >>>> r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practi= ce. >>>> Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, >>>> there is an overlap between NPRFs and extrapolation of the above (base= d on >>>> iteration of the PRF guarantees). >>>> >>>> >>>> >>>> This is worth noting from an assurance standpoint: there was discussio= n >>>> at the virtual interims with respect to the current formulation of MLS= key >>>> derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet this pro= posal is not without >>>> precedence itself. Ergo, such a change should not necessarily be conce= rning >>>> based on differing from current practice. >>>> >>>> >>>> >>>> This style of combing hash outputs does affect collision resistance >>>> [4], and some discussion on relation to that would be nice to see. >>>> >>>> >>>> >>>> Britta >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] Carter, Wegman. Universal classes of hash functions. >>>> >>>> [2] Carter, Wegman. New hash functions and their use in authentication >>>> and set equality. >>>> >>>> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard >>>> Assumptions: A Generic Validation of an HMAC Assumption. >>>> >>>> [4] Bernstein. What output size resists collisions in a xor of >>>> independent expansions? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *From: *MLS on behalf of >>>> Chris Brzuska >>>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>>> *To: *"mls@ietf.org" >>>> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF= ) >>>> >>>> >>>> >>>> Hi all, >>>> >>>> I would like to open a discussion on a suggestion for a change in the >>>> key schedule. In the current draft, we use the Extract function twice = as a >>>> dual pseudorandom function (DPRF) when combining 3 keys (*) and interl= eave >>>> them with an Expand call. >>>> >>>> The suggestion [1] is to replace these 3 calls by a multi-input PRF >>>> (NPRF) which is especially designed to return a pseudorandom key when = at >>>> least one of the input keys is pseudorandom. The new suggestion relies= on >>>> standard PRF security rather than DPRF-security of Extract. >>>> >>>> You can find the accompanying paper with pictures, discussion and >>>> security reduction for the design principle here [2]. I include a summ= ary >>>> of the main points in the end of this eMail. >>>> >>>> Please comment/share your opinion. Thanks! >>>> >>>> Chris >>>> >>>> (*) commit_secret, PSK and init_secret >>>> >>>> [1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337 >>>> >>>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>>> >>>> >>>> *---------------------------------------------------------------------= -----------------------------------------------* >>>> >>>> *Summary of main points:* >>>> >>>> The current key schedule >>>> - uses Extract as a dual pseudorandom function and assumes that HMAC i= s >>>> a dual pseudorandom function >>>> - applies Extract after Expand, i.e., after applying a function which >>>> generates a pseudorandom value >>>> - iterates Extract-then-Expand sequentially to combine more than 2 key= s >>>> >>>> The pull request suggests to >>>> - replace the ad-hoc assumption that Extract is a dual pseudorandom >>>> function >>>> - remove Extract steps when applied after Expand >>>> - use a provably secure NPRF construction which allows to combine more >>>> than 2 keys and is based on a standard PRF assumption and statistical >>>> properties of xor. >>>> >>>> Efficiency: >>>> - The suggested construction has higher parallel efficiency. It >>>> increases the overall number of HMAC evaluations by 1. >>>> >>>> Assumptions: >>>> - HMAC is a standard PRF. >>>> - Relies on a unique value, the group_context was suggested. >>>> >>>> Construction: >>>> (1) Use unique value to expand each key and xor the result >>>> (2) expand resulting key, including unique value into the context agai= n >>>> >>>> Security argument: >>>> - Pseudorandomness: unique value ensures that each outcome of Expand i= n >>>> (1) is used only once in a xor combination, thus allowing on one-time = pad >>>> argument of xor. >>>> - Uniqueness of resulting keys: (2) ensures that if HMAC is >>>> collision-resistent, then the result is collision-resistent. >>>> >>>> Variants: >>>> - It is possible to use an NPRF variant called NameNPRF [2] which has = 3 >>>> HMAC evaluations more and relies less on the unique value. I.e., NameN= PRF >>>> is secure in the same scenarios as DPRF: Keys only repeat if the input= keys >>>> repeat *and* the group context repeats. >>>> >>>> Questions/Comments that came up: >>>> - Barnes, MacMillion suggested group_context as unique value >>>> - MacMillion wondered about removal of Extract: One can add an extract >>>> operation for the psk. For other input keys, it does not seem needed, = since >>>> they were returned from Expand. >>>> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of >>>> output keys, the PRF needs to be collision-resistant, too. >>>> >>>> _______________________________________________ >>>> MLS mailing listMLS@ietf.orghttps://www.ietf.org/mailman/listinfo/mls >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>> --0000000000009931b905ab4b3a05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct, it=E2=80=99s for efficiency.=C2=A0 It lets = you encrypt one copy of the GroupInfo and send it to many new joiners.=C2= =A0 If the group is large and the Welcome carries the tree, this is a signi= ficant savings, especially if you=E2=80=99re adding multiple new members in= the epoch.=C2=A0


On Sat, Jul 25, 202= 0 at 17:36 Chris Brzuska <chri= s.brzuska@aalto.fi> wrote:
=20 =20 =20

Thanks!

Another clarification question: I am confused about why GroupInfo and GroupSecrets are not encrypted using the same key? Since the welcome_secret can be derived from the GroupSecrets, the use of the welcome_secret does not seem to add security. Is this an efficiency optimization?


Chris

On 26/07/2020 00:14, Richard Barnes wrote:
=20
Think about the order of operations a new joiner goes through:

1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) using the relevant HPKE private key
2. Compute the welcome_secret, welcome_key, and welcome_nonce
3. Decrypt the GroupInfo using the welcome_key and welcome_nonce

My presumption is that the joiner will only know that it needs the PSK after step 3, when it can read the GroupInfo extensions.=C2=A0 (See https://github.com/mlswg/mls-protocol/= issues/367)=C2=A0 That means that the welcome_secret can't depend on the PSK.

On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hi Richard,

I have a quick question: An additional change in your key schedule is that the welcome_secret is now derived before<= /b> including the PSK. What is the motivation behind this?

Thanks!

Chris

On 24/07/2020 22:18, Chris Brzuska wrote:

I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first.

Will think about it, thanks for clarifying the requirements!

Chris

On 24/07/2020 21:47, Richard Barnes wrote:
Your confusion is understandable -- the document is wrong right now!=C2=A0 You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature.=C2=A0 The epoch secret should verify tha= t *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as follows:

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 init_secret_[n-1] (or 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0commit_secret -> HKDF-Extract =3D joiner_secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--> Derive-Secret(., "welcome")
=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=3D welcome_secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V
=C2=A0 =C2=A0 =C2=A0 PSK (or 0) -> HKDF-Extract = =3D member_secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V
GroupContext_[n] -> HKDF-Extract =3D epoch_secret<= /span>

(I also promoted the GroupContext to the main key schedule.)=C2=A0 That's the context for my earlier comments.=C2=A0 With that picture, the only thing you&#= 39;re coalescing with nPRF would be the latter two HKDF-Extract calls.

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>=C2=A0 You can't add the commit sec= ret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

               ini=
t_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract =3D early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract =3D epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].=C2=A0 A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.=C2=A0 It= 9;s not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there ar= e multiple PSKs?=C2=A0 But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto= .fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =3D= =C2=A0 PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

=C2=A0

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a =E2=80=9CTLS precedence=E2=80=9D, yet= this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

=C2=A0

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

=C2=A0

Britta

=C2=A0

=C2=A0

=C2=A0

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

=C2=A0

=C2=A0

=C2=A0

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aal= to.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

=C2=A0

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF= .html

---------------------------------= ---------------------------------------------------------------------------= --------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.
Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


____=
___________________________________________
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
--0000000000009931b905ab4b3a05-- From nobody Sat Jul 25 15:10: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 E845D3A0B40 for ; Sat, 25 Jul 2020 15:10:20 -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=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 I9O4RH6tRqHb for ; Sat, 25 Jul 2020 15:10:17 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E983A0B3C for ; Sat, 25 Jul 2020 15:10:17 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id x9so6269502plr.2 for ; Sat, 25 Jul 2020 15:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dE/U5MmDb0xktmElU9yyulsieetLy177gAFdG0uHyes=; b=XjB+z2Vc8sCxmz8DmhEdPQWBYhlpnUXP50Ycb99KMyQOGOSWOUaTCRC3uDjHdFpiVe VLBeokLMRMNopasDzhz9DFzpD0dGJzmGMbSlmV8ZUwUbYUgtwy94zVMSMP/EK1gkkADF LoiBnPZ3Va4/9r9oZP7EhVUvZPc/sOzSs8lJU= 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=dE/U5MmDb0xktmElU9yyulsieetLy177gAFdG0uHyes=; b=i6r2iq+WNMoBZeaD3l3566cblioP7dQKVj+sjcTdhjYJWgccOWGDQeLbBLWWY3fIPR B8dXodaZr3bwHgtdPidQ1M0xqp8HSCn/oKaCsF+YtA7eUEC+RAbqi0O3F/PhsBG+DM7/ vqpoPzKn2zklpUrXx4XJheo95/UhsP8Irmaig/BLCz2d9F9RKYabsBCB1mc/KGNAUfpm dRM0+jNXs9GqPR+a6qZ9FHtZQt+9ms5RbI80pKQwQOlxhp9/bOkTw20QrA8+k+mCNc6d c5dHiU0adBFAuA3FYkXqo2PSPDTifgEa3sPN3pvSSHZhQItvVTynlgE2urrWwdd6WGEX 8GDQ== X-Gm-Message-State: AOAM530cBDJrLY5wY8kgdkW8m1APwxY337rDxS1bqAH0JBqTbpdUgaaT wlTFWXDH3FwANQUESh/eBkTFNofPRZd2dQ== X-Google-Smtp-Source: ABdhPJwZCFMlkWxC/FhTqsQ2Eg1iahjfFTJxltagZiXzvtFr3o1b9bR+QQlIsAoRfpjRYGUo5UpWzA== X-Received: by 2002:a17:902:9890:: with SMTP id s16mr13511873plp.112.1595715016920; Sat, 25 Jul 2020 15:10:16 -0700 (PDT) Received: from [192.168.7.29] (c-73-15-208-167.hsd1.ca.comcast.net. [73.15.208.167]) by smtp.gmail.com with ESMTPSA id u73sm10515608pfc.113.2020.07.25.15.10.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jul 2020 15:10:16 -0700 (PDT) From: Brendan McMillion Message-Id: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_47D19D76-67FA-44CE-AD5D-631E27D82CC7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 25 Jul 2020 15:10:15 -0700 In-Reply-To: Cc: "Hale, Britta (CIV)" , Messaging Layer Security WG To: Richard Barnes References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [MLS] Hiding content type 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, 25 Jul 2020 22:10:21 -0000 --Apple-Mail=_47D19D76-67FA-44CE-AD5D-631E27D82CC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m concerned about adversarial collisions, that'd cause a = partial DoS like you say. There are other ways to cause partial DoS in = an MLS group, but I think it=E2=80=99s good to minimize the avenues for = attack. In your example, it sounds like you=E2=80=99re trying to achieve = unlinkability between messages, with a Generic Commit Sequencing Service = which is basically a KV store that only accepts one write per key. So in = this scenario, I think you would be much better off by simply truncating = the group ID and epoch from MLSCiphertext (making them implicit), and = choosing the key that each message is stored under with some function = of: 1.) a group secret, and 2.) a message counter. Would that work? > On Jul 25, 2020, at 12:38 PM, Richard Barnes wrote: >=20 > Just so we're clear, in your example, are you concerned about = accidental or adversarial collisions? I hope we agree that we can fix = the accidental case just by making a longer epoch ID. In the = adversarial case, this seems like a partial DoS at worst, since the = members who incorrectly think they are in the previous epoch will no = longer be decrypting with the right keys. >=20 > As far as a positive example: Imagine a Generic Commit Sequencing = Service that provides a reliable broadcast/ledger over anonymous = channels (e.g., as an onion service), but will only broadcast/record one = message for each groupID/epoch. If the groupID/epoch is opaque, then = such a service can be provided without learning anything about the = groups it serves or their evolution. >=20 >=20 > On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion = > wrote: > Take for example, a broadcast channel that's ordered but lossy. A = Commit gets sent where the new epoch id collides with the previous epoch = id, but not all members get the Commit. So now the group is fractured = and there's no way for members in the previous epoch to know that they = missed a message. What the application developer needs to do to detect = lost messages, is immediately re-implement the counter epoch id that = you've just removed. >=20 > That's an example of a system where this change is pointless / = harmful. If you could provide an example of a system where the change is = *helpful*, that would be more interesting. >=20 > On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: > I'm honestly really confused by the worry about collisions here. The = current epoch ID collides trivially -- it's just a counter! And the = group ID is assumed to be public anyway. So if your authentication = scheme is broken when you have a (group ID, epoch ID) collision, then = your scheme is already broken. >=20 > If we're going to block this change on this basis, then we need to see = clearly articulated an authentication scheme that is secure in the = current model, but broken in the case where epoch IDs are derived off of = the key schedule. >=20 > --Richard >=20 > On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) = > wrote: > Ensuring the most conservative design by default seems advisable; = however it is not clear that this proposal for hiding content type is = actually doing that. Indeed, if an application is concerned about hiding = the content type, would not that same type of application also be = concerned about collisions? >=20 > =20 >=20 > As Brendan notes, we are not talking about accidental collisions here. = Pre-computation is entirely possible, such as by a malicious group = member, so the window of attack is not limited to one epoch. >=20 > =20 >=20 > If this is this PR particular is of particular interest to some, then = it would be good to see a clarifying explanation as to the security it = achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite = introducing such collision possibilities), or a concrete use-case. = Alternatively, are we really limited to a 64-bit field, or can that = length be adjusted to mitigate the introduced problems? >=20 > =20 >=20 > =20 >=20 > =20 >=20 > A clarifying point for those following this thread: some references in = the email chain state that this is encryption of the epoch ID. That is = not the case. The proposal being discussed is about a hash thereof = (hence discussion on collisions). >=20 > =20 >=20 > Britta >=20 > =20 >=20 > =20 >=20 > From: MLS > on = behalf of Brendan McMillion > > Date: Monday, July 13, 2020 at 9:37 AM > To: Richard Barnes > Cc: Messaging Layer Security WG > > Subject: Re: [MLS] Hiding content type >=20 > =20 >=20 > As far as collision resistance, I'm not too worried about collisions = among 64-bit random values, especially as the scope for collision is = fairly small, arguably just one epoch. >=20 > =20 >=20 > The issue isn't with accidental collisions, it's with malicious ones. = An attacker can purposefully (and quickly) generate commits that create = duplicate epoch ids, and send them to a client to corrupt their group = state. >=20 > =20 >=20 > I think the idea here is to be conservative by default. There are = systems in which you can hide the metadata you're talking about with = things like mixnets and dropboxes. >=20 > =20 >=20 > It's not just being more conservative, you're making changes = specifically for very niche use-cases where I don't think the security = of the whole system has been thought through. Maybe you have an example = in mind, but I can't think of a system where this change provides any = additional privacy. >=20 > =20 >=20 > On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: >=20 > On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion = > wrote: >=20 > With respect to using an opaque epoch id, I believe this was proposed = in #245 and consensus = was against it because it makes it more difficult to implement the DS. = It's also not clear to me what security properties you want from an = opaque epoch id, because the current PR doesn't provide collision = resistance and I'd expect this to be a source of confusion and bugs. >=20 > =20 >=20 > I think the discussion on #245 got derailed a bit by the focus on = non-linear epochs. The point here is that even in a case where you have = linear history, I think there's intrinsic value in the epoch ID being = opaque because it gives intermediaries less opportunity for = ossification. >=20 > =20 >=20 > As far as collision resistance, I'm not too worried about collisions = among 64-bit random values, especially as the scope for collision is = fairly small, arguably just one epoch. >=20 > =20 >=20 > =20 >=20 > With respect to encrypting the content type, it also seems to me that = this would cause issues because different content types have different = delivery guarantees. Specifically: messages are allowed to be unordered = and lossy, proposals are allowed to be unordered but not lossy, and = commits are both ordered and not lossy. In the deployment scenarios = we've talked about, the DS essentially always needs to know the content = type to provide this. Conversely, you don't get much additional privacy = from encrypting the content type because an eavesdropper can see the = epoch id change and infer which message was a commit, or see a dropped = message getting re-sent and infer it was a proposal. >=20 > =20 >=20 > I don't disagree that there are different guarantees you need, but = like I said, I think the idea here is to be conservative by default. = There are systems in which you can hide the metadata you're talking = about with things like mixnets and dropboxes. Keeping the ciphertext as = opaque as possible keeps the door open to running MLS over those systems = without MLS's own metadata undermining their privacy properties. >=20 > =20 >=20 > FWIW, in the systems I'm looking at building, this PR does not make = any difference, because clients use separate channels for = Proposals/Commits vs. application data and the server doesn't check. >=20 > =20 >=20 > --Richard >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >=20 > Hi all, >=20 > =20 >=20 > Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) = encrypt the content type of the message (application / proposal / = commit) [1]. >=20 > =20 >=20 > There was some discussion on the call last week that encrypting the = content type might not be that useful, since an application that relies = on a server to assure ordering of commits will need to at least be able = to tell commits from other things. Of course, even if the content type = is encrypted by default, the application can add it back in = authenticated data, or in some unauthenticated wrapper. >=20 > =20 >=20 > Net of those considerations, I'm personally still inclined to merge = the PR, to have a conservative baseline. But those on the call thought = it would be useful to pose this to the group, so please speak up if you = have concerns. >=20 > =20 >=20 > --Richard >=20 > =20 >=20 > [1] https://github.com/mlswg/mls-protocol/pull/349 = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_47D19D76-67FA-44CE-AD5D-631E27D82CC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m concerned about adversarial collisions, that'd cause a partial DoS = like you say. There are other ways to cause partial DoS in an MLS group, = but I think it=E2=80=99s good to minimize the avenues for attack.

In your example, it = sounds like you=E2=80=99re trying to achieve unlinkability between = messages, with a Generic Commit Sequencing Service which is basically a = KV store that only accepts one write per key. So in this scenario, I = think you would be much better off by simply truncating the group ID and = epoch from MLSCiphertext (making them implicit), and choosing the key = that each message is stored under with some function of: 1.) a group = secret, and 2.) a message counter.

Would that work?

On Jul = 25, 2020, at 12:38 PM, Richard Barnes <rlb@ipv.sx> wrote:

Just so we're clear, in your example, are you = concerned about accidental or adversarial collisions?  I hope we = agree that we can fix the accidental case just by making a longer epoch = ID.  In the adversarial case, this seems like a partial DoS at = worst, since the members who incorrectly think they are in the previous = epoch will no longer be decrypting with the right keys.

As = far as a positive example: Imagine a Generic Commit Sequencing Service = that provides a reliable broadcast/ledger over anonymous channels (e.g., = as an onion service), but will only broadcast/record one message for = each groupID/epoch.  If the groupID/epoch is opaque, then such a = service can be provided without learning anything about the groups it = serves or their evolution.


On Sat, Jul 25, 2020 at 1:50 PM Brendan = McMillion <brendan@cloudflare.com> wrote:
Take for example, a broadcast channel that's ordered but = lossy. A Commit gets sent where the new epoch id collides with the = previous epoch id, but not all members get the Commit. So now the group = is fractured and there's no way for members in the previous epoch to = know that they missed a message. What the application developer needs to = do to detect lost messages, is immediately re-implement the counter = epoch id that you've just removed.

That's an example of a system where = this change is pointless / harmful. If you could provide an example of a = system where the change is *helpful*, that would be more interesting.

On Fri, Jul 24, 2020 at 11:05 AM = Richard Barnes <rlb@ipv.sx> wrote:
I'm honestly really confused by the worry about collisions = here.  The current epoch ID collides trivially -- it's just a = counter!  And the group ID is assumed to be public anyway.  So = if your authentication scheme is broken when you have a (group ID, epoch = ID) collision, then your scheme is already broken.

If we're going to block = this change on this basis, then we need to see clearly articulated an = authentication scheme that is secure in the current model, but broken in = the case where epoch IDs are derived off of the key schedule.

--Richard

On Tue, Jul 14, 2020 at 10:38 AM Hale, = Britta (CIV) <britta.hale@nps.edu> wrote:

Ensuring the most conservative = design by default seems advisable; however it is not clear that this = proposal for hiding content type is actually doing that. Indeed, if an = application is concerned about hiding the content type, would not that same type of application also be concerned about collisions?

 

As = Brendan notes, we are not talking about accidental collisions here. = Pre-computation is entirely possible, such as by a malicious group = member, so the window of attack is not limited to one epoch.

 

If = this is this PR particular is of particular interest to some, then it = would be good to see a clarifying explanation as to the security it = achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite = introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a = 64-bit field, or can that length be adjusted to mitigate the introduced = problems?

 

 

 

A = clarifying point for those following this thread: some references in the = email chain state that this is encryption of the epoch ID. That is not = the case. The proposal being discussed is about a hash thereof (hence = discussion on collisions).

 

Britta

 

 

From: = MLS <mls-bounces@ietf.org> on behalf of Brendan McMillion = <brendan=3D40cloudflare.com@dmarc.ietf.org>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

 

As far as collision resistance, = I'm not too worried about collisions among 64-bit random values, = especially as the scope for collision is fairly small, arguably just one = epoch.

 

The issue isn't with accidental = collisions, it's with malicious ones. An attacker can purposefully (and = quickly) generate commits that create duplicate epoch ids, and send them = to a client to corrupt their group state.

 

I think the idea here is to be = conservative by default.  There are systems in which you can hide = the metadata you're talking about with things like mixnets and = dropboxes.

 

It's not just being more = conservative, you're making changes specifically for very niche = use-cases where I don't think the security of the whole system has been = thought through. Maybe you have an example in mind, but I can't think of = a system where this change provides any additional privacy.

 

On Mon, Jul 13, 2020 at 10:56 AM = Richard Barnes <rlb@ipv.sx> wrote:

On Mon, Jul 13, 2020 at 10:57 AM = Brendan McMillion <brendan@cloudflare.com> wrote:

With respect to using an opaque = epoch id, I believe this was proposed in #245 and consensus was against it = because it makes it more difficult to implement the DS. It's also not = clear to me what security properties you want from an opaque epoch id, = because the current PR doesn't provide collision resistance and I'd expect this = to be a source of confusion and bugs.

 

I think the discussion on #245 = got derailed a bit by the focus on non-linear epochs.  The point = here is that even in a case where you have linear history, I think = there's intrinsic value in the epoch ID being opaque because it gives = intermediaries less opportunity for ossification.

 

As far as collision resistance, = I'm not too worried about collisions among 64-bit random values, = especially as the scope for collision is fairly small, arguably just one = epoch.

 

 

With respect to encrypting the = content type, it also seems to me that this would cause issues because = different content types have different delivery guarantees. = Specifically: messages are allowed to be unordered and lossy, proposals = are allowed to be unordered but not lossy, and commits are both ordered and = not lossy. In the deployment scenarios we've talked about, the DS = essentially always needs to know the content type to provide this. = Conversely, you don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch = id change and infer which message was a commit, or see a dropped message = getting re-sent and infer it was a proposal.

 

I don't disagree that there are = different guarantees you need, but like I said, I think the idea here is = to be conservative by default.  There are systems in which you can = hide the metadata you're talking about with things like mixnets and dropboxes.  Keeping the ciphertext as opaque as possible keeps = the door open to running MLS over those systems without MLS's own = metadata undermining their privacy properties.

 

FWIW, in the systems I'm looking = at building, this PR does not make any difference, because clients use = separate channels for Proposals/Commits vs. application data and the = server doesn't check.

 

--Richard

 

 

 

On Mon, Jul 13, 2020 at 8:56 AM = Richard Barnes <rlb@ipv.sx> wrote:

Hi all,

 

Recall that PR#349 does two = things (1) use an opaque epoch ID, and (2) encrypt the content type of = the message (application / proposal / commit) [1].

 

There was some discussion on the = call last week that encrypting the content type might not be that = useful, since an application that relies on a server to assure ordering = of commits will need to at least be able to tell commits from other things.  Of course, even if the content type is encrypted by = default, the application can add it back in authenticated data, or in = some unauthenticated wrapper.

 

Net of those considerations, I'm = personally still inclined to merge the PR, to have a conservative = baseline.  But those on the call thought it would be useful to pose = this to the group, so please speak up if you have concerns.

 

--Richard

 

[1] https://github.com/mlswg/mls-protocol/pull/349

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


= --Apple-Mail=_47D19D76-67FA-44CE-AD5D-631E27D82CC7-- From nobody Sat Jul 25 16:01:21 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 549A43A0B85 for ; Sat, 25 Jul 2020 16:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=aalto.fi 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 seZznPFNl5Gq for ; Sat, 25 Jul 2020 16:01:09 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 92EF33A0B9E for ; Sat, 25 Jul 2020 16:01:07 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5EDFB271579_F1CB9AFB; Sat, 25 Jul 2020 23:01:03 +0000 (GMT) Received: from exng3.org.aalto.fi (exng3.org.aalto.fi [130.233.223.22]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng3.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id D66E727156E_F1CB9AEF; Sat, 25 Jul 2020 23:01:02 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng3.org.aalto.fi (130.233.223.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 26 Jul 2020 02:01:02 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 26 Jul 2020 02:01:02 +0300 To: Richard Barnes CC: Messaging Layer Security WG References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> <7c3c0f7f-58d2-acfb-d5d6-e8e5e80299da@aalto.fi> From: Chris Brzuska Message-ID: Date: Sun, 26 Jul 2020 02:01:01 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------063327395B6BD17B4FD9A920" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng5.org.aalto.fi (130.233.223.24) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:cc:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=7BlEh7yxzRVugc17QuWfsQEQzRCVKdVv3h0tRONczS4=; b=JcPvbum92aF8Z+OYGFthsKBwHF6RfsP9Iy55LAmSf9PJhgw4zura7NiUX8rnytbtH/kmcMHQaoOBUJFaqstMz/UulbwJFRYBpaJl15IEcetBwkZiBqMJ1WZSTDJpZm3rNMseTqNKmYkj6+45o1R2ZOZnaL5or/TY0xAW96kcvN3YTjSKBEfatFcaGfOZgW2thjwynSxvYWWfJG3cdyy2RgGVKkaQ/cVDH0ybeOOy4LUoBZPAGz8BYv4MdNiV4MpM+4vorlLm9mN+jLD3yQA1ehBlA0IBCAzuFmJj+TtkVhoWCmWfjk/j/gpO7zV0igH9UcsUnIs3dnURgq9Ulwdbmw== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 25 Jul 2020 23:01:20 -0000 --------------063327395B6BD17B4FD9A920 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Right - so, I guess, I have another misunderstanding/confusion. I thought that the GroupSecrets, too, are only encrypted once under a single symmetric key, and then, this symmetric key is encrypted to all new members using HPKE. But I guess I misunderstood and this is not the case (why not?), because else, we could just use this same symmetric key to encrypt the GroupInfo, too. Chris On 26/07/2020 01:01, Richard Barnes wrote: > Correct, it’s for efficiency.  It lets you encrypt one copy of the > GroupInfo and send it to many new joiners.  If the group is large and > the Welcome carries the tree, this is a significant savings, > especially if you’re adding multiple new members in the epoch. > > > On Sat, Jul 25, 2020 at 17:36 Chris Brzuska > wrote: > > Thanks! > > Another clarification question: I am confused about why GroupInfo > and GroupSecrets are not encrypted using the same key? Since the > welcome_secret can be derived from the GroupSecrets, the use of > the welcome_secret does not seem to add security. Is this an > efficiency optimization? > > > Chris > > On 26/07/2020 00:14, Richard Barnes wrote: >> Think about the order of operations a new joiner goes through: >> >> 1. Decrypt the EncryptedGroupSecrets (including the >> joiner_secret) using the relevant HPKE private key >> 2. Compute the welcome_secret, welcome_key, and welcome_nonce >> 3. Decrypt the GroupInfo using the welcome_key and welcome_nonce >> >> My presumption is that the joiner will only know that it needs >> the PSK after step 3, when it can read the GroupInfo extensions.  >> (See https://github.com/mlswg/mls-protocol/issues/367) That means >> that the welcome_secret can't depend on the PSK. >> >> On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska >> > wrote: >> >> Hi Richard, >> >> I have a quick question: An additional change in your key >> schedule is that the welcome_secret is now derived *before* >> including the PSK. What is the motivation behind this? >> >> Thanks! >> >> Chris >> >> On 24/07/2020 22:18, Chris Brzuska wrote: >> >>> I see, thanks for clarifying. Obviously, with these >>> requirements, pull request #336 does not work as is. I think >>> that the conceptual issue of how to best combine two, three >>> keys and more keys, remains, now with an additional >>> requirement to combine two keys separately first. >>> >>> Will think about it, thanks for clarifying the requirements! >>> >>> Chris >>> >>> On 24/07/2020 21:47, Richard Barnes wrote: >>>> Your confusion is understandable -- the document is wrong >>>> right now!  You are correct that the current design >>>> prohibits new joiners from participating in the PSK proof, >>>> but that's a bug, not a feature. The epoch secret should >>>> verify that *all members of the current epoch* know the >>>> PSK, not just the ones inherited from the last epoch. >>>> >>>> That's why #362 rearranges the key schedule as follows: >>>> >>>>               init_secret_[n-1] (or 0) >>>>                         | >>>>                         V >>>>    commit_secret -> HKDF-Extract = joiner_secret >>>>                         | >>>>                         +--> Derive-Secret(., "welcome") >>>>                         |    = welcome_secret >>>>                         | >>>>                         V >>>>       PSK (or 0) -> HKDF-Extract = member_secret >>>>                         | >>>>                         V >>>> GroupContext_[n] -> HKDF-Extract = epoch_secret >>>> >>>> (I also promoted the GroupContext to the main key >>>> schedule.)  That's the context for my earlier comments.  >>>> With that picture, the only thing you're coalescing with >>>> nPRF would be the latter two HKDF-Extract calls. >>>> >>>> Hope that helps, >>>> --Richard >>>> >>>> >>>> >>>> On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska >>>> > wrote: >>>> >>>> Hey Richard, >>>> >>>> thank you for looking into this. I think, I need more >>>> explanation to understand the following point: >>>> >>>> >>>  You can't add the commit secret and PSKs in the >>>> same operation, because you want new joiners to put in >>>> the PSK, but you don't want them to have to know the >>>> commit secret. >>>> >>>> The current draft sais the following about the PSK: >>>> "Groups which already have an out-of-band mechanism to >>>> generate *shared* group secrets can inject those in the >>>> MLS key schedule to seed the MLS group secrets >>>> computations by this external entropy. At any epoch, >>>> including the initial state, an application can decide >>>> to synchronize the injection of a PSK into the MLS key >>>> schedule. This mechanism can be used to improve >>>> security in the cases where having a full run of >>>> updates across members is too expensive or in the case >>>> where the external group key establishment mechanism >>>> provides stronger security against classical or quantum >>>> adversaries." >>>> >>>> As I understand this paragraph, the PSK is known by all >>>> group members and not related to new joiners. Maybe, >>>> the requirements and/or design changed in the >>>> meanwhile, and I am not aware of it. I interpreted the >>>> paragraph this way, since the current construction >>>> (posted below for convenience) also requires to know >>>> the commit_secret to derive the epoch_secret (from >>>> which the welcome_secret is derived). Where did I go wrong? >>>> >>>> Thanks! >>>> >>>> Chris >>>> >>>> init_secret_[n-1] (or 0) >>>> | >>>> V >>>> PSK (or 0) -> HKDF-Extract = early_secret >>>> | >>>> Derive-Secret(., "derived", "") >>>> | >>>> V >>>> commit_secret -> HKDF-Extract = epoch_secret >>>> >>>> >>>> On 24/07/2020 20:53, Richard Barnes wrote: >>>>> Hey Chris, >>>>> >>>>> I was looking again at the key schedule as I was >>>>> drafting #362 [1].  A couple of things occurred to me: >>>>> >>>>> 1. You can't add the commit secret and PSKs in the >>>>> same operation, because you want new joiners to put in >>>>> the PSK, but you don't want them to have to know the >>>>> commit secret. >>>>> >>>>> 2. The nPRF construction you propose has the same >>>>> number of HMAC invocations as the chained-HKDF-Extract >>>>> stuff that's in the current draft / 362. >>>>> >>>>> Given those observations, I wonder how much an nPRF is >>>>> really buying us.  It's not saving us any HMAC calls, >>>>> and relative to #362, it would only coalesce two DPRF >>>>> calls into one nPRF call. >>>>> >>>>> Maybe there's some benefit if there are multiple >>>>> PSKs?  But even then, it seems like you could add a >>>>> layer, computing a synthetic PSK from the multiple >>>>> ones, and keeping the main key schedule simple. >>>>> >>>>> At this point, given the above and the novelty of the >>>>> nPRF construction, I'm inclined to just stick with >>>>> HKDF and merge #362 instead of #336. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> [1] https://github.com/mlswg/mls-protocol/pull/362 >>>>> >>>>> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >>>>> >>>> > wrote: >>>>> >>>>> Thank you for the pointer to Carter-Wegman MACs. >>>>> >>>>> >>> This style of combing hash outputs does affect >>>>> collision resistance [4], and some discussion on >>>>> relation to that would be nice to see. >>>>> >>>>> That's an excellent point. In addition to >>>>> pseudorandomness, we prove the >>>>> collision-resistance of our construction. I.e., >>>>> assuming that no unique value is used twice and >>>>> assuming that HMAC is collision-resistance, then >>>>> the final Expand operation guarantees unique >>>>> outputs. I.e., by including the unique value into >>>>> the final Expand operation after the xor, the >>>>> construction recovers from any collisions incurred >>>>> by the xor. >>>>> >>>>> Chris >>>>> >>>>> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>>>>> >>>>>> This is an interesting proposal. It is closely >>>>>> related at a high level to Carter-Wegman MACs >>>>>> (i.e. for random seed r, MAC((k1, k2), m) = >>>>>> PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall >>>>>> into this category in practice. Considering the >>>>>> use of a MAC-based KDF and the proofs of [3] on >>>>>> DPRFs, there is an overlap between NPRFs and >>>>>> extrapolation of the above (based on iteration of >>>>>> the PRF guarantees). >>>>>> >>>>>> This is worth noting from an assurance >>>>>> standpoint: there was discussion at the virtual >>>>>> interims with respect to the current formulation >>>>>> of MLS key derivation, which has a “TLS >>>>>> precedence”, yet this proposal is not without >>>>>> precedence itself. Ergo, such a change should not >>>>>> necessarily be concerning based on differing from >>>>>> current practice. >>>>>> >>>>>> This style of combing hash outputs does affect >>>>>> collision resistance [4], and some discussion on >>>>>> relation to that would be nice to see. >>>>>> >>>>>> Britta >>>>>> >>>>>> [1] Carter, Wegman. Universal classes of hash >>>>>> functions. >>>>>> >>>>>> [2] Carter, Wegman. New hash functions and their >>>>>> use in authentication and set equality. >>>>>> >>>>>> [3] Bellare and Lysyanskaya. Symmetric and Dual >>>>>> PRFs from Standard Assumptions: A Generic >>>>>> Validation of an HMAC Assumption. >>>>>> >>>>>> [4] Bernstein. What output size resists >>>>>> collisions in a xor of independent expansions? >>>>>> >>>>>> *From: *MLS >>>>>> on behalf of Chris >>>>>> Brzuska >>>>>> >>>>>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>>>>> *To: *"mls@ietf.org" >>>>>> >>>>>> *Subject: *[MLS] Key Schedule: Replace DPRF with >>>>>> multi-input PRF (NPRF) >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I would like to open a discussion on a suggestion >>>>>> for a change in the key schedule. In the current >>>>>> draft, we use the Extract function twice as a >>>>>> dual pseudorandom function (DPRF) when combining >>>>>> 3 keys (*) and interleave them with an Expand call. >>>>>> >>>>>> The suggestion [1] is to replace these 3 calls by >>>>>> a multi-input PRF (NPRF) which is especially >>>>>> designed to return a pseudorandom key when at >>>>>> least one of the input keys is pseudorandom. The >>>>>> new suggestion relies on standard PRF security >>>>>> rather than DPRF-security of Extract. >>>>>> >>>>>> You can find the accompanying paper with >>>>>> pictures, discussion and security reduction for >>>>>> the design principle here [2]. I include a >>>>>> summary of the main points in the end of this eMail. >>>>>> >>>>>> Please comment/share your opinion. Thanks! >>>>>> >>>>>> Chris >>>>>> >>>>>> (*) commit_secret, PSK and init_secret >>>>>> >>>>>> [1] Pull >>>>>> Request:https://github.com/mlswg/mls-protocol/pull/337 >>>>>> >>>>>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>>>>> >>>>>> *--------------------------------------------------------------------------------------------------------------------* >>>>>> >>>>>> *Summary of main points:* >>>>>> >>>>>> The current key schedule >>>>>> - uses Extract as a dual pseudorandom function >>>>>> and assumes that HMAC is a dual pseudorandom function >>>>>> - applies Extract after Expand, i.e., after >>>>>> applying a function which generates a >>>>>> pseudorandom value >>>>>> - iterates Extract-then-Expand sequentially to >>>>>> combine more than 2 keys >>>>>> >>>>>> The pull request suggests to >>>>>> - replace the ad-hoc assumption that Extract is a >>>>>> dual pseudorandom function >>>>>> - remove Extract steps when applied after Expand >>>>>> - use a provably secure NPRF construction which >>>>>> allows to combine more than 2 keys and is based >>>>>> on a standard PRF assumption and statistical >>>>>> properties of xor. >>>>>> >>>>>> Efficiency: >>>>>> - The suggested construction has higher parallel >>>>>> efficiency. It increases the overall number of >>>>>> HMAC evaluations by 1. >>>>>> >>>>>> Assumptions: >>>>>> - HMAC is a standard PRF. >>>>>> - Relies on a unique value, the group_context was >>>>>> suggested. >>>>>> >>>>>> Construction: >>>>>> (1) Use unique value to expand each key and xor >>>>>> the result >>>>>> (2) expand resulting key, including unique value >>>>>> into the context again >>>>>> >>>>>> Security argument: >>>>>> - Pseudorandomness: unique value ensures that >>>>>> each outcome of Expand in (1) is used only once >>>>>> in a xor combination, thus allowing on one-time >>>>>> pad argument of xor. >>>>>> - Uniqueness of resulting keys: (2) ensures that >>>>>> if HMAC is collision-resistent, then the result >>>>>> is collision-resistent. >>>>>> >>>>>> Variants: >>>>>> - It is possible to use an NPRF variant called >>>>>> NameNPRF [2] which has 3 HMAC evaluations more >>>>>> and relies less on the unique value. I.e., >>>>>> NameNPRF is secure in the same scenarios as DPRF: >>>>>> Keys only repeat if the input keys repeat *and* >>>>>> the group context repeats. >>>>>> >>>>>> Questions/Comments that came up: >>>>>> - Barnes, MacMillion suggested group_context as >>>>>> unique value >>>>>> - MacMillion wondered about removal of Extract: >>>>>> One can add an extract operation for the psk. For >>>>>> other input keys, it does not seem needed, since >>>>>> they were returned from Expand. >>>>>> - Wood: Can we replace HMAC by arbitrary PRF? >>>>>> Yes. For uniqueness of output keys, the PRF needs >>>>>> to be collision-resistant, too. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> --------------063327395B6BD17B4FD9A920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Right - so, I guess, I have another misunderstanding/confusion. I thought that the GroupSecrets, too, are only encrypted once under a single symmetric key, and then, this symmetric key is encrypted to all new members using HPKE. But I guess I misunderstood and this is not the case (why not?), because else, we could just use this same symmetric key to encrypt the GroupInfo, too.

Chris

On 26/07/2020 01:01, Richard Barnes wrote:

Correct, it’s for efficiency.  It lets you encrypt one copy of the GroupInfo and send it to many new joiners.  If the group is large and the Welcome carries the tree, this is a significant savings, especially if you’re adding multiple new members in the epoch. 


On Sat, Jul 25, 2020 at 17:36 Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thanks!

Another clarification question: I am confused about why GroupInfo and GroupSecrets are not encrypted using the same key? Since the welcome_secret can be derived from the GroupSecrets, the use of the welcome_secret does not seem to add security. Is this an efficiency optimization?


Chris

On 26/07/2020 00:14, Richard Barnes wrote:
Think about the order of operations a new joiner goes through:

1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) using the relevant HPKE private key
2. Compute the welcome_secret, welcome_key, and welcome_nonce
3. Decrypt the GroupInfo using the welcome_key and welcome_nonce

My presumption is that the joiner will only know that it needs the PSK after step 3, when it can read the GroupInfo extensions.  (See https://github.com/mlswg/mls-protocol/issues/367)  That means that the welcome_secret can't depend on the PSK.

On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hi Richard,

I have a quick question: An additional change in your key schedule is that the welcome_secret is now derived before including the PSK. What is the motivation behind this?

Thanks!

Chris

On 24/07/2020 22:18, Chris Brzuska wrote:

I see, thanks for clarifying. Obviously, with these requirements, pull request #336 does not work as is. I think that the conceptual issue of how to best combine two, three keys and more keys, remains, now with an additional requirement to combine two keys separately first.

Will think about it, thanks for clarifying the requirements!

Chris

On 24/07/2020 21:47, Richard Barnes wrote:
Your confusion is understandable -- the document is wrong right now!  You are correct that the current design prohibits new joiners from participating in the PSK proof, but that's a bug, not a feature.  The epoch secret should verify that *all members of the current epoch* know the PSK, not just the ones inherited from the last epoch.

That's why #362 rearranges the key schedule as follows:

                  init_secret_[n-1] (or 0)
                        |
                        V
   commit_secret -> HKDF-Extract = joiner_secret
                        |
                        +--> Derive-Secret(., "welcome")
                        |    = welcome_secret
                        |
                        V
      PSK (or 0) -> HKDF-Extract = member_secret
                        |
                        V
GroupContext_[n] -> HKDF-Extract = epoch_secret

(I also promoted the GroupContext to the main key schedule.)  That's the context for my earlier comments.  With that picture, the only thing you're coalescing with nPRF would be the latter two HKDF-Extract calls.

Hope that helps,
--Richard



On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Hey Richard,

thank you for looking into this. I think, I need more explanation to understand the following point:

>>>  You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

The current draft sais the following about the PSK:
"Groups which already have an out-of-band mechanism to generate shared group secrets can inject those in the MLS key schedule to seed the MLS group secrets computations by this external entropy. At any epoch, including the initial state, an application can decide to synchronize the injection of a PSK into the MLS key schedule. This mechanism can be used to improve security in the cases where having a full run of updates across members is too expensive or in the case where the external group key establishment mechanism provides stronger security against classical or quantum adversaries."

As I understand this paragraph, the PSK is known by all group members and not related to new joiners. Maybe, the requirements and/or design changed in the meanwhile, and I am not aware of it. I interpreted the paragraph this way, since the current construction (posted below for convenience) also requires to know the commit_secret to derive the epoch_secret (from which the welcome_secret is derived). Where did I go wrong?

Thanks!

Chris

               init_secret_[n-1] (or 0)
                     |
                     V
    PSK (or 0) -> HKDF-Extract = early_secret
                     |
               Derive-Secret(., "derived", "")
                     |
                     V
commit_secret -> HKDF-Extract = epoch_secret

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].  A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.  It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?  But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
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
--------------063327395B6BD17B4FD9A920-- From nobody Sun Jul 26 00:41:40 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 35AC23A0BFF; Sun, 26 Jul 2020 00:41: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.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <159574929716.22694.16064628062387140906@ietfa.amsl.com> Date: Sun, 26 Jul 2020 00:41:37 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-architecture-05.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: Sun, 26 Jul 2020 07:41:38 -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) Architecture Authors : Emad Omara Benjamin Beurdouche Eric Rescorla Srinivas Inguva Albert Kwon Alan Duric Filename : draft-ietf-mls-architecture-05.txt Pages : 19 Date : 2020-07-26 Abstract: This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol. MLS provides a security layer for group messaging applications, where the number of clients ranges from two to many. It is meant to protect against eavesdropping, tampering, and message forgery. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mlswg/mls-architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-architecture-05 https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 26 00:41:54 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 4A3323A0C35 for ; Sun, 26 Jul 2020 00:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=qZZXtRAe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ckABBwaZ 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 iM1CsxLP9hfK for ; Sun, 26 Jul 2020 00:41:40 -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 D309C3A0C0B for ; Sun, 26 Jul 2020 00:41:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DB24CC35 for ; Sun, 26 Jul 2020 03:32:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 26 Jul 2020 03:32:31 -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=NLvXEpTlXiyxW2TeviGJJhOzOVVvzsdvLUisQ+kA8nk=; b=qZZXtRAe TJe+2F1ijAVCMPMnGxDS455KJkNS8DIlYXQ4WqpvMjpRIBub+wvPLNrcwxpWYmbu GHlHkBdnTwX7rqUg1/L+VVsJqRl/o4oPp42i7l15qlNbM3MfjKNorKboChM5JWYl DEhrGBN3R50b55gRrvWArwBU+R22J/6VapNVX2Qx+NyMxvoMZJNkGjFMJD+oqCSp qGkIV/aXZXWmWxQkleqcq5MkbFX21LzJ4T55HHr5tbt8T9dKDa5KGoYxYDefxJF/ pJUcYZx/z5ZP3xcHpZOdOqWt/UT2sr0OzYNs6YDjU8A7wl2F1xlZZ2vWMVlmVd2A b6cEwbkm/BYLeA== 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=fm3; bh=NLvXEpTlXiyxW2TeviGJJhOzOVVvz sdvLUisQ+kA8nk=; b=ckABBwaZ34g9EBT+yRjV6aOsPjw6PoNSO8mR7l5ZQ8+es zqdPdKF8tnDzue9yVctm4n4cvKTpi/2nSaO2wWBXBgH2ilydeNpYymWpGI6sBtW3 U/naDlNCTvniZHP/sCXyW1Ac38G92uCQaiKSP/bQ1BFIsnRbyo6zgwUvPXH1RRoQ UfHR3OPe6i+u6KAu5Sm9BwyvGEVjDHgwmaQtpQ9U8hyKcpw3V30QWN1JJXxQYmVa GDheE7/usAOwy27FzTinSKbxb6t9jzoZ9ZUXZum+NoP4b2Rj7s09VxOpMxbjimgL GJvmY1RFMWJVKJdavNQmm4jLBpsP7z9YxKy/2Q7KA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrheeigdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddujeehrddvudeird dvudeknecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az134.internal.cloudapp.net (unknown [52.175.216.218]) by mail.messagingengine.com (Postfix) with ESMTPA id 3F4C7306005F for ; Sun, 26 Jul 2020 03:32:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6428522908501095126==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200726073231.3F4C7306005F@mailuser.nyi.internal> Date: Sun, 26 Jul 2020 03:32:31 -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, 26 Jul 2020 07:41:50 -0000 --===============6428522908501095126== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+2/-2/=F0=9F=92=AC11) 2 issues created: - Definition of a group member can be strengthened (by chelseakomlo) https://github.com/mlswg/mls-architecture/issues/71=20 - Editor's copy points to a 404. (by beurdouche) https://github.com/mlswg/mls-architecture/issues/70 [website]=20 3 issues received 11 new comments: - #70 Editor's copy points to a 404. (6 by Bren2010, beurdouche, katriela= lex) https://github.com/mlswg/mls-architecture/issues/70 [website]=20 - #68 Handling user permissions in MLS versus implementations (1 by beurd= ouche) https://github.com/mlswg/mls-architecture/issues/68=20 - #48 Description of the formal security guarantees that the protocol MUS= T provide (4 by beurdouche, claucece) https://github.com/mlswg/mls-architecture/issues/48=20 2 issues closed: - Editor's copy points to a 404. https://github.com/mlswg/mls-architectur= e/issues/70 [website]=20 - Handling user permissions in MLS versus implementations https://github.= com/mlswg/mls-architecture/issues/68=20 * mlswg/mls-protocol (+4/-4/=F0=9F=92=AC0) 4 issues created: - Proof of prior membership in the group / Resumption (by bifurcation) https://github.com/mlswg/mls-protocol/issues/368=20 - Negotiate PSKs (by bifurcation) https://github.com/mlswg/mls-protocol/issues/367=20 - Add extensions to the Commit message (by bifurcation) https://github.com/mlswg/mls-protocol/issues/366=20 - Update security considerations (by bifurcation) https://github.com/mlswg/mls-protocol/issues/365=20 4 issues closed: - Tree in GroupInfo not optional https://github.com/mlswg/mls-protocol/is= sues/344 [functionality] [performance]=20 - Clarify what it means to send a Commit with no Proposals https://github= .com/mlswg/mls-protocol/issues/340=20 - Use HPKE KDF for the MLS key schedule https://github.com/mlswg/mls-prot= ocol/issues/351=20 - Use consistent arguments to Derive-Secret https://github.com/mlswg/mls-= protocol/issues/324 [enhancement]=20 Pull requests ------------- * mlswg/mls-architecture (+1/-2/=F0=9F=92=AC5) 1 pull requests submitted: - Update build (by Bren2010) https://github.com/mlswg/mls-architecture/pull/69=20 1 pull requests received 5 new comments: - #69 Update build (5 by Bren2010, beurdouche) https://github.com/mlswg/mls-architecture/pull/69=20 2 pull requests merged: - Editorial changes https://github.com/mlswg/mls-architecture/pull/65=20 - Update build https://github.com/mlswg/mls-architecture/pull/69=20 * mlswg/mls-protocol (+6/-6/=F0=9F=92=AC3) 6 pull requests submitted: - Coalesce supported_* into Capabilities (by bifurcation) https://github.com/mlswg/mls-protocol/pull/370=20 - Add Commit extensions and clarify the extensibility story (by bifurcati= on) https://github.com/mlswg/mls-protocol/pull/369=20 - Use the KDF from HPKE (by bifurcation) https://github.com/mlswg/mls-protocol/pull/364=20 - Fix compile errors again. (by Bren2010) https://github.com/mlswg/mls-protocol/pull/363=20 - Reorder key schedule inputs (by bifurcation) https://github.com/mlswg/mls-protocol/pull/362=20 - Use correct arguments to Derive-Secret (by bifurcation) https://github.com/mlswg/mls-protocol/pull/361=20 3 pull requests received 3 new comments: - #353 Explain the meaning of a Commit with no proposals (1 by bifurcatio= n) https://github.com/mlswg/mls-protocol/pull/353=20 - #348 Make the tree in the Welcome optional (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/348=20 - #219 Fix application message truncation attack (1 by bifurcation) https://github.com/mlswg/mls-protocol/pull/219 [functionality] [securit= y] [work in progress]=20 6 pull requests merged: - Make the tree in the Welcome optional https://github.com/mlswg/mls-protocol/pull/348=20 - Explain the meaning of a Commit with no proposals https://github.com/mlswg/mls-protocol/pull/353=20 - Use the KDF from HPKE https://github.com/mlswg/mls-protocol/pull/364=20 - Fix compile errors again. https://github.com/mlswg/mls-protocol/pull/363=20 - Fix all compiler warnings. https://github.com/mlswg/mls-protocol/pull/357=20 - Use correct arguments to Derive-Secret https://github.com/mlswg/mls-protocol/pull/361=20 * mlswg/mls-federation (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Update build (by Bren2010) https://github.com/mlswg/mls-federation/pull/5=20 1 pull requests received 1 new comments: - #5 Update build (1 by Bren2010) https://github.com/mlswg/mls-federation/pull/5=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6428522908501095126== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday July 26, 2020

Issues

mlswg/mls-architecture (+2/-2/=F0=9F=92=AC11)

2 issues created:

3 issues received 11 new comments:

2 issues closed:

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

4 issues created:

4 issues closed:

Pull requests

mlswg/mls-architecture (+1/-2/=F0=9F=92=AC5)

1 pull requests submitted:

1 pull requests received 5 new comments:

2 pull requests merged:

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

6 pull requests submitted:

3 pull requests received 3 new comments:

6 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============6428522908501095126==-- From nobody Sun Jul 26 00:51:04 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 579073A0C1A for ; Sun, 26 Jul 2020 00:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62V_RxZ1mrYD for ; Sun, 26 Jul 2020 00:51:00 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DEA3A0C1B for ; Sun, 26 Jul 2020 00:50:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.75,397,1589234400"; d="scan'208";a="461328486" Received: from unknown (HELO [172.20.10.3]) ([37.165.127.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2020 09:50:57 +0200 From: Benjamin Beurdouche Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 26 Jul 2020 09:50:56 +0200 References: <159574929716.22694.16064628062387140906@ietfa.amsl.com> To: ML Messaging Layer Security In-Reply-To: <159574929716.22694.16064628062387140906@ietfa.amsl.com> Message-Id: <0D3E86E8-94C7-4C97-B0C3-9F2B5A924A48@inria.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] I-D Action: draft-ietf-mls-architecture-05.txt 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, 26 Jul 2020 07:51:03 -0000 Dear all, I just posted a new draft of the Architecture document which contains = only minor editorial differences and to avoid expiration of the draft. The current plan is to do a = significant update, especially for the threat model and security tradeoffs part of the document this September (after we = have stabilised the protocol document). At that time, I=E2=80=99ll get back to the list and open a large = discussion with interested parties=E2=80=A6 Feel free to open issues in the meantime=E2=80=A6 : ) Stay safe and take care! Benjamin > On 26 Jul 2020, at 09:41, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : The Messaging Layer Security (MLS) = Architecture > Authors : Emad Omara > Benjamin Beurdouche > Eric Rescorla > Srinivas Inguva > Albert Kwon > Alan Duric > Filename : draft-ietf-mls-architecture-05.txt > Pages : 19 > Date : 2020-07-26 >=20 > Abstract: > This document describes the reference architecture, functional and > security requirements for the Messaging Layer Security (MLS) > protocol. MLS provides a security layer for group messaging > applications, where the number of clients ranges from two to many. > It is meant to protect against eavesdropping, tampering, and message > forgery. >=20 > Discussion Venues >=20 > This note is to be removed before publishing as an RFC. >=20 > Source for this draft and an issue tracker can be found at > https://github.com/mlswg/mls-architecture. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mls-architecture-05 > https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mls-architecture-05 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Sun Jul 26 13:02: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 077A63A140C for ; Sun, 26 Jul 2020 13:02:00 -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 (2048-bit key) header.d=aalto.fi 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 OYg9dUvGsd1n for ; Sun, 26 Jul 2020 13:01:58 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 2A8953A140A for ; Sun, 26 Jul 2020 13:01:56 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 4FCA11157AE_F1DE130B for ; Sun, 26 Jul 2020 20:01:52 +0000 (GMT) Received: from exng2.org.aalto.fi (exng2.org.aalto.fi [130.233.223.21]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 2807011579E_F1DE130F for ; Sun, 26 Jul 2020 20:01:52 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng2.org.aalto.fi (130.233.223.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 26 Jul 2020 23:01:51 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Sun, 26 Jul 2020 23:01:51 +0300 From: Chris Brzuska To: Messaging Layer Security WG Message-ID: <5f7e09a6-98d8-0584-249f-f9f268683484@aalto.fi> Date: Sun, 26 Jul 2020 23:01:52 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng6.org.aalto.fi (130.233.223.25) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=from:subject:to:message-id:date:mime-version:content-type:content-transfer-encoding; s=its18; bh=LU0VYyNl1ogmNR013JvMs8OtjXRvz8VwaAlbRUoZ2C8=; b=SrKIOTQDSWSrKuLvDg0DuHXBSY7ISWQy0sNmcm4bTDRcm/i6KJ7hc39t+orUrUm+suPLQ8Jt2hDKWiCUA/LrsxzLe3TsWLrdB3GaN4aqiK0uQmT1akvAsh9KtByY3gMngb5Ku8wYcN3xfIoAswVDRIuE6Ci2DaKVMYPmT09b8NG+oUkoSpAB40Y29pLazoMmhArGCXjz1V4nQ+ix82wNzCYjri+AnAKhQduYUBc0lYa8Myb0r1TQubGQKEiO5syItI9Erahjgm2Ol4qskzy6HOrMddT3BzCNAds0wU55BvgypawfMfiZGM8wR/NknxQsipIoCuPUMMNGOWrUxc/ZhQ== Archived-At: Subject: [MLS] Key Schedule: New Document 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, 26 Jul 2020 20:02:00 -0000 Hi all, I still need to process and understand the key schedule interface requirements which Richard discussed yesterday. In the meanwhile, I would like to make available an update on the original proposal (w.r.t. the original interface) and a discussion, available here in a (short) document (high-level discussion, no proofs): http://www.chrisbrzuska.de/2020-07-26-MLS.pdf Main points of the document: - In the cfrg meeting, it was suggested to call HKDF.Extract on all three keys. Page 1 explains why relying on this "direct extract" construction implies the assumption that HKDF.Extract is an Triple-PRF (or n-PRF if there are more keys). - Hugo Krawczyk brought the issue of low-entropy key material to my attention which I find an interesting topic for MLS: Sessions last very long and, after many updates, one would hope that entropy accumulates such that the keys become pseudorandom even if individual keys might have low entropy. For this purpose, it would be better to replace xor by HKDF.Extract which additively combines the entropy of its inputs (which xor does not necessarily do, see linked document above). This is the main reason why I favor to replace xor by HKDF.Extract. For a more nuanced discussion of pros and cons, see above document. Chris From nobody Sun Jul 26 19:02:49 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 802333A15E9 for ; Sun, 26 Jul 2020 19:02:47 -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 jy7pIkZKcCDV for ; Sun, 26 Jul 2020 19:02:46 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 1967F3A15E7 for ; Sun, 26 Jul 2020 19:02:45 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id u8so6755074qvj.12 for ; Sun, 26 Jul 2020 19:02:45 -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=ak4zvJXDt01daA+iQz09GtqSvoB32v/wOYFXdq8yC2Q=; b=B/3bN2D58GZU0k7wZI5C42FXHlNnelRyAhcNZzQxKji4ko8B0/leNlKLoA3JKJYDo8 EI7q6zAkYp+SVDL/ETc7J4OowK0J99yJwqTJD/znUR2kQpO02DXYcUutFTAKWhx/yZHw T9GHp8rm1UxSs501XCJES1oai6W1z+97grPGg= 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=ak4zvJXDt01daA+iQz09GtqSvoB32v/wOYFXdq8yC2Q=; b=SlMZa00/FYcaEuAR6ezyub8pqYOY7amfnHK3g+eVb94my3YxBwwIir/480qbsAnd7l 9Ls4WZtyU6/NaBoripaJESgycIMdFnALIDHDO+DRRbfXUob5CNsdls20/3IoSdpLlzUU uTVxmX8KBy1rJfh3MO1HZC1kpdRNs86OR0Kev25rGUOq0qW3cUw1IT8KZiRee6ZT5B9S 150/82rQ27lLswRYI4+IuApcxgFBvvxRaa1c04Oxb2mWF/voTmmGZWVozjydiiVw16b3 DY6XmWcUv/1Yr+Ud1R3s1QT/p+9AtPiDlrlsfSO49hzIKpVzCdN9L48ZS/4ED8DF3dlR Tfag== X-Gm-Message-State: AOAM5322LSmkaSzCURlq95cZL3f3hBV1VvsWzZ2BwIyjvTzjipCpkp+O 7gT/m9wBrVmO8+Wq3D2CEujnIQI5ylY= X-Google-Smtp-Source: ABdhPJxQiun9ZuPfHmlbnOhl/ccZSj+E1Y6P+2/RTxspnDO5rIdx0ke4oBR873iJFyYMAjt1RI4z8g== X-Received: by 2002:a0c:ee4a:: with SMTP id m10mr19515449qvs.41.1595815364505; Sun, 26 Jul 2020 19:02:44 -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 w1sm12396155qte.25.2020.07.26.19.02.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 19:02:43 -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.1\)) Message-Id: Date: Sun, 26 Jul 2020 22:02:42 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [MLS] MLS@IETF108: Requests 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, 27 Jul 2020 02:02:48 -0000 Hi! If you=E2=80=99re interested in volunteering to take minutes or be = jabber scribe please let the chairs know (chairs-mls@ietf.org). spt= From nobody Sun Jul 26 19:09: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 871A93A087B for ; Sun, 26 Jul 2020 19:09:44 -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 At0PUKhVZeAc for ; Sun, 26 Jul 2020 19:09: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 709103A07E2 for ; Sun, 26 Jul 2020 19:09:40 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id w9so11152604qts.6 for ; Sun, 26 Jul 2020 19:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=nJ0kfgb9luFGlIm4Qzn+nzHOynS/4FCwLripqT3jmCI=; b=aossJ1xysue1+k7S0EPHZYKn/tMIVRY5bjk3bg4NhzLxpaHptwSnmHtr9mRX0LHLcJ 3FjOHMZfpf6dOlfyRTS7/BOjR80CUFCab7e+EOE9PVNKpQc4WNHeYluUQbO9BNvOXBnO qCwHOtfZoRZrsB+gstxYBE3TkYrX73hnRXc1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=nJ0kfgb9luFGlIm4Qzn+nzHOynS/4FCwLripqT3jmCI=; b=BRuqGz2eO/U0gup31nSu2pKoILWSP8PjU0QolkC4ANQAg7vtK43DlDSl/ymS8AgwEh Rc70LYuafrU+gbqyxcQhL0B/+hOPmpaQPV1zO4M6V3JgGBOB55PNvBLsSK1ruCXmevtH buwFNZRYcDuXpC9BLNtBHA68tXsf6ituyCNKJD7jJz4RND9a2L5qiLK53RAbZmxGVHho 6itvkPS66MUkCl1/NFwggoPNWc0kpJcXX9FvOPVIFAtodjryEPNXxTcMtsNXQsYssBJq 2hnxBz6iCLfRp/f8HqtGlQVgBL0ccdQD8a8q2Tln2HKVjnf++YcDNAuM3ezZ9ygv6/bA /yGQ== X-Gm-Message-State: AOAM532ME0Ma0zJPcL98GyMvAkkmFTFqJ+hM1M4kjidaBnTADumf9Y/M JWR2S/729dCyW57vh10upPOyDN7gG+Q= X-Google-Smtp-Source: ABdhPJyXT4XoOFZmfOU3fomBeCqqPQmjQOHWKDrUjzHVRGmWZ/umkbym0y0ozAdrSIw45W7pR46THA== X-Received: by 2002:ac8:6bc2:: with SMTP id b2mr20471653qtt.115.1595815779105; Sun, 26 Jul 2020 19:09:39 -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 w7sm13362882qtw.47.2020.07.26.19.09.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 19:09:38 -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.1\)) Date: Sun, 26 Jul 2020 22:09:37 -0400 References: To: MLS List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [MLS] MLS@IETF108: Requests 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, 27 Jul 2020 02:09:45 -0000 And that=E2=80=99s mls-chairs@ietf.org > On Jul 26, 2020, at 22:02, Sean Turner wrote: >=20 > Hi! >=20 > If you=E2=80=99re interested in volunteering to take minutes or be = jabber scribe please let the chairs know (chairs-mls@ietf.org). >=20 > spt From nobody Sun Jul 26 20: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 E85953A1664 for ; Sun, 26 Jul 2020 20:35:25 -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 PVFCrpCu4Cdl for ; Sun, 26 Jul 2020 20:35:24 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 80C4D3A1663 for ; Sun, 26 Jul 2020 20:35:24 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id l64so7311781qkb.8 for ; Sun, 26 Jul 2020 20:35:24 -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=BE/td51crrsAD5apqFsnUH+elUUcIlRR7l7g019X75o=; b=fANZJ8seuyu26tRzzVzqZXq8nag0fC1IZhyqRvVMKKfinDGRYcTezqcHh+Dak/0WvJ A3QwB1NyLbHd5NJJPiXZYvC+YbexJTNiKoE685RjWkKmH5WDlLf/RUmNZ4iO+Tu+yQJ2 p9z25ZMt037ArgSt62rwiZWfpqXzpd6HvJcFk= 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=BE/td51crrsAD5apqFsnUH+elUUcIlRR7l7g019X75o=; b=PLGjJbZD9QMrg/DwuYBQ+K6pwN+/jhNgAfBelucy7iqHC910m/18nLHrFFMco2tyof tgHLnaSFFMG1BJKVBWWYaiivr322heNve5bKfy2LYsb+LNzsjmrxApPBU9RxF5pmvYoj dRIJehw7HD/Q5gBSeucmnRc0aULM2RkaIR7neFYyDAeOgyQXlLIpuxWxE35xmqeQ5J04 SsoYy6HUiIRAvZkStQArhYjgM6me3c2fSAJHeF2Mt7dAgm6la6qe8Ph/wm/fYxNv2HPf tGPfB2iwjifICEqvf8CWvgYRtcWtebOcGS9XECsGXwDPs4xVvvnCE0qFPONKqyVA3fQj Fr7w== X-Gm-Message-State: AOAM532pS8JEWggE0m9/4RxL0NFHU481qSeBHiS9n+Po+y0UdB10sgJs PXJhLos1Mv3X0YfXivZaH/yeNfa+FKs= X-Google-Smtp-Source: ABdhPJxMNyduiljhc5Vxf/tG1GiWG+OXxGf1x9+THZ78We7wadgGJ6Jxp7HhbdFlx17JmXM99Cb5fA== X-Received: by 2002:a37:a982:: with SMTP id s124mr20871345qke.171.1595820922995; Sun, 26 Jul 2020 20:35:22 -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 84sm17976602qkf.136.2020.07.26.20.35.21 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 20:35:22 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Sun, 26 Jul 2020 23:35:21 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [MLS] MLS@IETF108: Meeting Logistics 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, 27 Jul 2020 03:35:26 -0000 The following information can also be found in the agenda: https://www.ietf.org/proceedings/108/agenda/agenda-108-mls-02 # MLS@IETF018 ## Logistics ### Time Tuesday 2020-07-28 13:00 UTC ### Meeting Information Meetecho (a/v and chat): https://meetings.conf.meetecho.com/ietf108/?group=mls&short=&item=1 Audio (only): http://mp3.conf.meetecho.com/ietf/ietf1087.m3u Etherpad (virtual blue sheets and notes): https://codimd.ietf.org/notes-ietf-108-mls# ## Agenda ### Administrivia - Virtual Meeting Tips - Note Well - Virtual Bluesheet - Note Taker - Jabber Scribe - Status ### Protocol Issues and Pull Requests https://github.com/mlswg/mls-protocol/issues https://github.com/mlswg/mls-protocol/pulls Requests: Brendan https://github.com/mlswg/mls-protocol/pull/360 From nobody Mon Jul 27 21:01: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 B6AE33A0BCC for ; Mon, 27 Jul 2020 21:01:50 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDM_Ml1YkJSl for ; Mon, 27 Jul 2020 21:01:48 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 8FE433A0BCF for ; Mon, 27 Jul 2020 21:01:44 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id a5so6860217wrm.6 for ; Mon, 27 Jul 2020 21:01:44 -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=blIRRXXSUUHvaldG+OGSfrHCy2QrZwyDxoZ2JzzjfHA=; b=g9QBEvxQ6ixjIGc6e4VUKfoPS841kIgIW3YekCJbOJDDAzzHaYjEY8dbgshTVuqolN WYz5NayifkXWwuGREkKuLSCOge3bUQ3XO+Yo1loa09+Qlzp6I1vFO2R3rXxFVzLqL/+e qpNoODfQJqKZ3ts887tqmFif2el3GllFmi5HgVglNongLr7PbKyJKkm3OdN5QFVzMv73 o8NOa4cr9LJpkF4AuRPocsSvvNoGfj0NZyYdfrBDJDAjTnodp8iC+n5iNNZ7BVobGPmx QoWqSxYzRpb6jux73q+qi+yJ8T2pCh/D8oehYbpWVNXvgNcv3ZHvdhwkiWasTgIh2/vt hgLw== 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=blIRRXXSUUHvaldG+OGSfrHCy2QrZwyDxoZ2JzzjfHA=; b=QK8IQrNu8gt8fyPQJoQcoJxprRf2MxghnR0amLIHrA/9drw5/5DExoB97De3bg6ivu tSXKBJyMIivl6Bh0P7m6ZXW1eT1D5TkD3APCGuoSzTb3ZJ6uBd1d0QXLCuJU5WxlFT10 Rm0Z4SNMl6rg3cMxavfOlEVbhASZePIkZI6Aj1ElxcRJxopqbb8T3KBgqGr9eyCWQ2lR 58wyomRQEwNxQZZAYRWlX0F9oXhtBYyLvqImjJNVOBjke1mAFE1RTCT65NxgXxv5F0Yc Ub4BULRbxtqOtvpmxNumo75wRRLJ+7Z14lDHkMtBti4IWB+B1ivPKNkreIG6AyB0Y9hz lP8A== X-Gm-Message-State: AOAM532ZSenkXlDHm2THTp+ommMNl/eVKlGyuEbhwGEMfwwdpfwygbJi bTusY8zVQ3I5lMlPKdf2OHmEwEQ3a3D6OCQ6uKonLrLR X-Google-Smtp-Source: ABdhPJyGxrHhIIzw7p2mVwFsf6nHzWkAd71mwNKjbDEVLzaJ3M4VOCamo23Bskth9NJXf0qBCNVf/vWEBBcT7xjgpW0= X-Received: by 2002:a5d:5086:: with SMTP id a6mr22827143wrt.304.1595908902244; Mon, 27 Jul 2020 21:01:42 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> From: Chelsea Komlo Date: Mon, 27 Jul 2020 22:01:29 -0600 Message-ID: To: mls@ietf.org Cc: britta.hale@nps.edu, rlb@ipv.sx, brendan=40cloudflare.com@dmarc.ietf.org Content-Type: multipart/alternative; boundary="0000000000003657d205ab787fa2" Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 04:01:51 -0000 --0000000000003657d205ab787fa2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like to affirm the positive use case Richard described, and say that minimizing metadata where possible is valuable and leaves open the possibility of using MLS in less-trusted settings. There are messaging applications currently being developed in practice [1] that provide metadata resistance (and hopefully more will follow this trend in the future). It would be good to keep the door open to the use of MLS in these settings. As I am just now reading over the latest draft, I don't have much to add at this moment as to how to derive these fields implicitly, but I am happy to take a closer look and provide recommendations if the group doesn't come to consensus in the meeting this week. [1] https://openprivacy.ca/work/cwtch/ On Sat, Jul 25, 2020 at 4:10 PM Brendan McMillion wrote: > I=E2=80=99m concerned about adversarial collisions, that'd cause a partia= l DoS > like you say. There are other ways to cause partial DoS in an MLS group, > but I think it=E2=80=99s good to minimize the avenues for attack. > > In your example, it sounds like you=E2=80=99re trying to achieve unlinkab= ility > between messages, with a Generic Commit Sequencing Service which is > basically a KV store that only accepts one write per key. So in this > scenario, I think you would be much better off by simply truncating the > group ID and epoch from MLSCiphertext (making them implicit), and choosin= g > the key that each message is stored under with some function of: 1.) a > group secret, and 2.) a message counter. > > Would that work? > > On Jul 25, 2020, at 12:38 PM, Richard Barnes wrote: > > Just so we're clear, in your example, are you concerned about accidental > or adversarial collisions? I hope we agree that we can fix the accidenta= l > case just by making a longer epoch ID. In the adversarial case, this see= ms > like a partial DoS at worst, since the members who incorrectly think they > are in the previous epoch will no longer be decrypting with the right key= s. > > As far as a positive example: Imagine a Generic Commit Sequencing Service > that provides a reliable broadcast/ledger over anonymous channels (e.g., = as > an onion service), but will only broadcast/record one message for each > groupID/epoch. If the groupID/epoch is opaque, then such a service can b= e > provided without learning anything about the groups it serves or their > evolution. > > > On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion > wrote: > >> Take for example, a broadcast channel that's ordered but lossy. A Commit >> gets sent where the new epoch id collides with the previous epoch id, bu= t >> not all members get the Commit. So now the group is fractured and there'= s >> no way for members in the previous epoch to know that they missed a >> message. What the application developer needs to do to detect lost >> messages, is immediately re-implement the counter epoch id that you've j= ust >> removed. >> >> That's an example of a system where this change is pointless / harmful. >> If you could provide an example of a system where the change is *helpful= *, >> that would be more interesting. >> >> On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: >> >>> I'm honestly really confused by the worry about collisions here. The >>> current epoch ID collides trivially -- it's just a counter! And the gr= oup >>> ID is assumed to be public anyway. So if your authentication scheme is >>> broken when you have a (group ID, epoch ID) collision, then your scheme= is >>> already broken. >>> >>> If we're going to block this change on this basis, then we need to see >>> clearly articulated an authentication scheme that is secure in the curr= ent >>> model, but broken in the case where epoch IDs are derived off of the ke= y >>> schedule. >>> >>> --Richard >>> >>> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) >>> wrote: >>> >>>> Ensuring the most conservative design by default seems advisable; >>>> however it is not clear that this proposal for hiding content type is >>>> actually doing that. Indeed, if an application is concerned about hidi= ng >>>> the content type, would not that same type of application also be conc= erned >>>> about collisions? >>>> >>>> >>>> >>>> As Brendan notes, we are not talking about accidental collisions here. >>>> Pre-computation is entirely possible, such as by a malicious group mem= ber, >>>> so the window of attack is not limited to one epoch. >>>> >>>> >>>> >>>> If this is this PR particular is of particular interest to some, then >>>> it would be good to see a clarifying explanation as to the security it >>>> achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despit= e introducing such >>>> collision possibilities), or a concrete use-case. Alternatively, are w= e >>>> really limited to a 64-bit field, or can that length be adjusted to >>>> mitigate the introduced problems? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> A clarifying point for those following this thread: some references in >>>> the email chain state that this is encryption of the epoch ID. That is= not >>>> the case. The proposal being discussed is about a hash thereof (hence >>>> discussion on collisions). >>>> >>>> >>>> >>>> Britta >>>> >>>> >>>> >>>> >>>> >>>> *From: *MLS on behalf of Brendan McMillion >>>> >>>> *Date: *Monday, July 13, 2020 at 9:37 AM >>>> *To: *Richard Barnes >>>> *Cc: *Messaging Layer Security WG >>>> *Subject: *Re: [MLS] Hiding content type >>>> >>>> >>>> >>>> As far as collision resistance, I'm not too worried about collisions >>>> among 64-bit random values, especially as the scope for collision is f= airly >>>> small, arguably just one epoch. >>>> >>>> >>>> >>>> The issue isn't with accidental collisions, it's with malicious ones. >>>> An attacker can purposefully (and quickly) generate commits that creat= e >>>> duplicate epoch ids, and send them to a client to corrupt their group = state. >>>> >>>> >>>> >>>> I think the idea here is to be conservative by default. There are >>>> systems in which you can hide the metadata you're talking about with t= hings >>>> like mixnets and dropboxes. >>>> >>>> >>>> >>>> It's not just being more conservative, you're making changes >>>> specifically for very niche use-cases where I don't think the security= of >>>> the whole system has been thought through. Maybe you have an example i= n >>>> mind, but I can't think of a system where this change provides any >>>> additional privacy. >>>> >>>> >>>> >>>> On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: >>>> >>>> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion < >>>> brendan@cloudflare.com> wrote: >>>> >>>> With respect to using an opaque epoch id, I believe this was proposed >>>> in #245 and consensus >>>> was against it because it makes it more difficult to implement the DS.= It's >>>> also not clear to me what security properties you want from an opaque = epoch >>>> id, because the current PR doesn't provide collision resistance and I'= d >>>> expect this to be a source of confusion and bugs. >>>> >>>> >>>> >>>> I think the discussion on #245 got derailed a bit by the focus on >>>> non-linear epochs. The point here is that even in a case where you ha= ve >>>> linear history, I think there's intrinsic value in the epoch ID being >>>> opaque because it gives intermediaries less opportunity for ossificati= on. >>>> >>>> >>>> >>>> As far as collision resistance, I'm not too worried about collisions >>>> among 64-bit random values, especially as the scope for collision is f= airly >>>> small, arguably just one epoch. >>>> >>>> >>>> >>>> >>>> >>>> With respect to encrypting the content type, it also seems to me that >>>> this would cause issues because different content types have different >>>> delivery guarantees. Specifically: messages are allowed to be unordere= d and >>>> lossy, proposals are allowed to be unordered but not lossy, and commit= s are >>>> both ordered and not lossy. In the deployment scenarios we've talked a= bout, >>>> the DS essentially always needs to know the content type to provide th= is. >>>> Conversely, you don't get much additional privacy from encrypting the >>>> content type because an eavesdropper can see the epoch id change and i= nfer >>>> which message was a commit, or see a dropped message getting re-sent a= nd >>>> infer it was a proposal. >>>> >>>> >>>> >>>> I don't disagree that there are different guarantees you need, but lik= e >>>> I said, I think the idea here is to be conservative by default. There= are >>>> systems in which you can hide the metadata you're talking about with t= hings >>>> like mixnets and dropboxes. Keeping the ciphertext as opaque as possi= ble >>>> keeps the door open to running MLS over those systems without MLS's ow= n >>>> metadata undermining their privacy properties. >>>> >>>> >>>> >>>> FWIW, in the systems I'm looking at building, this PR does not make an= y >>>> difference, because clients use separate channels for Proposals/Commit= s vs. >>>> application data and the server doesn't check. >>>> >>>> >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) >>>> encrypt the content type of the message (application / proposal / comm= it) >>>> [1]. >>>> >>>> >>>> >>>> There was some discussion on the call last week that encrypting the >>>> content type might not be that useful, since an application that relie= s on >>>> a server to assure ordering of commits will need to at least be able t= o >>>> tell commits from other things. Of course, even if the content type i= s >>>> encrypted by default, the application can add it back in authenticated >>>> data, or in some unauthenticated wrapper. >>>> >>>> >>>> >>>> Net of those considerations, I'm personally still inclined to merge th= e >>>> PR, to have a conservative baseline. But those on the call thought it >>>> would be useful to pose this to the group, so please speak up if you h= ave >>>> concerns. >>>> >>>> >>>> >>>> --Richard >>>> >>>> >>>> >>>> [1] https://github.com/mlswg/mls-protocol/pull/349 >>>> >>>> _______________________________________________ >>>> 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 > --0000000000003657d205ab787fa2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to affirm the positive use c= ase Richard described, and say that minimizing metadata where possible is v= aluable and leaves open the possibility of using MLS in less-trusted settin= gs. There are messaging applications currently being developed in practice = [1] that provide metadata resistance=C2=A0(and hopefully more will follow t= his trend in the future).=C2=A0It would be good to keep the door open to th= e use of MLS in these settings.

As I am just now reading over = the latest draft, I don't have much to add at this moment as to how to = derive these fields implicitly, but I am happy to take a closer=C2=A0look a= nd provide recommendations if the group doesn't come to=C2=A0consensus = in the meeting this=C2=A0week.=C2=A0


On Sat, Jul 25, 2020 at 4:10 PM Brendan McMillion <br= endan=3D40cloudflare.com@dmarc.ietf.org> wrote:
I=E2=80=99m concerned about adversari= al collisions, that'd cause a partial DoS like you say. There are other= ways to cause partial DoS in an MLS group, but I think it=E2=80=99s good t= o minimize the avenues for attack.

In your example, it s= ounds like you=E2=80=99re trying to achieve unlinkability between messages,= with a Generic Commit Sequencing Service which is basically a KV store tha= t only accepts one write per key. So in this scenario, I think you would be= much better off by simply truncating the group ID and epoch from MLSCipher= text (making them implicit), and choosing the key that each message is stor= ed under with some function of: 1.) a group secret, and 2.) a message count= er.

Would that work?
<= br>
On Jul 25, 2020, at 12:38 PM, Richard Bar= nes <rlb@ipv.sx> = wrote:

Just so we're clear, in your= example, are you concerned about accidental or adversarial collisions?=C2= =A0 I hope we agree that we can fix the accidental case just by making a lo= nger epoch ID.=C2=A0 In the adversarial case, this seems like a partial DoS= at worst, since the members who incorrectly think they are in the previous= epoch will no longer be decrypting with the right keys.

=
As far as a positive example: Imagine a Generic Commit Sequencin= g Service that provides a reliable broadcast/ledger over anonymous channels= (e.g., as an onion service), but will only broadcast/record one message fo= r each groupID/epoch.=C2=A0 If the groupID/epoch is opaque, then such a ser= vice can be provided without learning anything about the groups it serves o= r their evolution.


On Sat, Jul 25, 2020 at 1:50 PM= Brendan McMillion <brendan@cloudflare.com> wrote:
Take for example, a bro= adcast channel that's ordered but lossy. A Commit gets sent where the n= ew epoch id collides with the previous epoch id, but not all members get th= e Commit. So now the group is fractured and there's no way for members = in the previous epoch to know that they missed a message. What the applicat= ion developer needs to do to detect lost messages, is immediately re-implem= ent the counter epoch id that you've just removed.

=
That's an example of a system where this change is pointless / har= mful. If you could provide an example of a system where the change is *help= ful*, that would be more interesting.

On Fri, Jul 24, 2020 at 11:0= 5 AM Richard Barnes <rlb= @ipv.sx> wrote:
I'm honestly really confused by the worry = about collisions here.=C2=A0 The current epoch ID collides trivially -- it&= #39;s just a counter!=C2=A0 And the group ID is assumed to be public anyway= .=C2=A0 So if your authentication scheme is broken when you have a (group I= D, epoch ID) collision, then your scheme is already broken.

<= /div>
If we're going to block this change on this basis, then we ne= ed to see clearly articulated an authentication scheme that is secure in th= e current model, but broken in the case where epoch IDs are derived off of = the key schedule.

--Richard

On Tue, Jul 14, 2020= at 10:38 AM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:

Ensuring the most conservative design by defaul= t seems advisable; however it is not clear that this proposal for hiding co= ntent type is actually doing that. Indeed, if an application is concerned a= bout hiding the content type, would not that same type of application also be concerned about collisions? <= u>

=C2=A0

As Brendan notes, we are not talking about accidental collisions here.= Pre-computation is entirely possible, such as by a malicious group member,= so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular interest to s= ome, then it would be good to see a clarifying explanation as to the securi= ty it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despi= te introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit f= ield, or can that length be adjusted to mitigate the introduced problems?

=C2=A0

=C2=A0

=C2=A0<= /u>

A clarifying point for those following this t= hread: some references in the email chain state that this is encryption of = the epoch ID. That is not the case. The proposal being discussed is about a= hash thereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0=

=C2=A0

From: = MLS <mls-bounces@ietf.org> on behalf of Brendan McM= illion <brendan=3D40cloudflare.com@dmarc.ietf.org>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too= worried about collisions among 64-bit random values, especially as the sco= pe for collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions,= it's with malicious ones. An attacker can purposefully (and quickly) g= enerate commits that create duplicate epoch ids, and send them to a client = to corrupt their group state.

=C2=A0

I think the idea here is to be conservative by = default.=C2=A0 There are systems in which you can hide the metadata you'= ;re talking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you&= #39;re making changes specifically for very niche use-cases where I don'= ;t think the security of the whole system has been thought through. Maybe y= ou have an example in mind, but I can't think of a system where this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes= <rlb@ipv.sx> wro= te:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMill= ion <brendan= @cloudflare.com> wrote:

With respect to using an opaque epoch id, I bel= ieve this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a b= it by the focus on non-linear epochs.=C2=A0 The point here is that even in = a case where you have linear history, I think there's intrinsic value i= n the epoch ID being opaque because it gives intermediaries less opportunity for ossification.

=C2=A0

As far as collision resistance, I'm not too= worried about collisions among 64-bit random values, especially as the sco= pe for collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it= also seems to me that this would cause issues because different content ty= pes have different delivery guarantees. Specifically: messages are allowed = to be unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and no= t lossy. In the deployment scenarios we've talked about, the DS essenti= ally always needs to know the content type to provide this. Conversely, you= don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id c= hange and infer which message was a commit, or see a dropped message gettin= g re-sent and infer it was a proposal.

=C2=A0

I don't disagree that there are different g= uarantees you need, but like I said, I think the idea here is to be conserv= ative by default.=C2=A0 There are systems in which you can hide the metadat= a you're talking about with things like mixnets and dropboxes.=C2=A0 Keeping the ciphertext as opaque as possible keeps th= e door open to running MLS over those systems without MLS's own metadat= a undermining their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at buildin= g, this PR does not make any difference, because clients use separate chann= els for Proposals/Commits vs. application data and the server doesn't c= heck.

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes = <rlb@ipv.sx> wrot= e:

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an o= paque epoch ID, and (2) encrypt the content type of the message (applicatio= n / proposal / commit) [1].

=C2=A0

There was some discussion on the call last week= that encrypting the content type might not be that useful, since an applic= ation that relies on a server to assure ordering of commits will need to at= least be able to tell commits from other things.=C2=A0 Of course, even if the content type is encrypted by default,= the application can add it back in authenticated data, or in some unauthen= ticated wrapper.

=C2=A0

Net of those considerations, I'm personally= still inclined to merge the PR, to have a conservative baseline.=C2=A0 But= those on the call thought it would be useful to pose this to the group, so= please speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

______________________________________________= _
MLS mailing list
MLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mls


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



--0000000000003657d205ab787fa2-- From nobody Mon Jul 27 21:09: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 C5A793A0BDF for ; Mon, 27 Jul 2020 21:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCRXkwZu5Ev6 for ; Mon, 27 Jul 2020 21:09:12 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 C339C3A0BDE for ; Mon, 27 Jul 2020 21:09:12 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4BG38S1sZhzDsf0 for ; Mon, 27 Jul 2020 21:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1595909352; bh=YypRHAnjH/AwHbCfoJnxtBkkJC+b0n+GdjgI31UHmoM=; h=To:From:Subject:Date:From; b=JfADqmzbvQ6gpBJiPyfAQdELaKjpcDYnDRn901ZxZ5K9bg5sYGu0AVhOs8Tlkbeif EHAt+O8R9uUtxuN1wZf0KCbT/n59zf52yRqR3hwLC/Q1IQJKLqKWOD/A2c7zxsz5Hu IYZbeX40PZvxoi8A15bm8N+qIYsZND358Yk5gig8= X-Riseup-User-ID: 2BE4E444CEED8FD6C4286212850B30AA8E91C25E083BA772231F969616D9C4BD Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 4BG38R3hZwz8sgc for ; Mon, 27 Jul 2020 21:09:11 -0700 (PDT) To: mls@ietf.org From: =?UTF-8?Q?Sof=c3=ada_Celi?= Autocrypt: addr=cherenkov@riseup.net; keydata= mQINBF2PpxoBEADAIhbOpA23OBsXzg/aQakv88vaLv8Dxt2oR92Rz9cfxca736HKDeO19IFC F1Anu6ylQsJfoT4UUgbGIjJpHtQB3OVIcgvsMagfZ0lEHd1eG8H8K9wqSjwSphUJl9ra+tMW MEbSDVmeV6qvHeO63vrazXrgUKBf0jDae0HcK++AYiSeSpbTmN+zTsY3ZXy9H1sdNhMUlkGt jcpROrna2NaSL3YG8YNJHsN+zGPoaBbPo9gQALUvuxtg0yS/ecly2xomWIeH6qJ4yJonO/Ys WqAAC96n423BeC1cAyYjij8ydygnR3csTibUI/iPkoH8xstnTyrv3djyiunVuw1BQUNqmtLV v7meRZfIFbfnNatuuPYp7S5NnL58vUwY/BwlMb5OhyzdCckRcITAXiz8sp4LANx1lxIdbaQA 9NsYv32vem9Pd0wtdN5JTW3dajgJtPAC1yfR86rw9u/+BSW9KhRqNF0/a+hX/+Njdni9fkl9 EheZiFHNO+nXeGLy0kikhUXr5iLg8626fG9I8QYuNj05WIEntegvAW65YjGTYSCdVgLx2bvv oGwC/4/jWxNm8MTzv38f/9YAZ5u5DSG3dFKYAjwOhf1IgEMTEWj+bKDFvgpv5fdTFumLxNey M/v3viwuNjS1hscRbi6IO36v4sFce4K1C5GU93YIgao2j01M8QARAQABtB1yaXNldXAgPGNo ZXJlbmtvdkByaXNldXAubmV0PokCVAQTAQgAPhYhBPq5Ptx83RGY3P1FWJG7a0VvRC0CBQJd j6caAhsDBQkHhh+ABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJG7a0VvRC0CEV0P/2UN rjx8LYmz/ydk2XO/uNWyobCtj/y9XBhZG9dpB8R43VC8OS5gv4Nw2ZLDrrpLQmaQ2dXjAeLL +9eCM++QT//VP2j2QS3YKbIcRreXSnl7DI6bMpD+Pu3JwiYHSyBs1zZT+VGm4nTS6QH588XJ VrslKyDYJFfzaHgkIGtxAWgqaHWAZHtjqh6PNEWMe2t571YYcVlk29cWsJ5ITsSPb+0Y0xJn u5HKQOc4TOdraedpLSFb5CZRlusNgWvhqmL4VyIcfjSEY0B8JVOgVpUeNTy0sZcDflYJ6uSN 9B1m79kb8STnVOtFS9gjnWbVwjAunqkkb/joRZhYfjeANVyYC4skh0uqJLFtqJw4r8s9+MrE p4lBy30lQ7mYYyqvRcwyEgoRRLHUvzV6cIHau/HV1pw0lwcbiXk3jP+TMf6OKOzg6lGJ/zX0 ZD+s0OAvHh8GM+5TDlgEM4Dwp6Q+9Jr1m9sp1QDQVbU7xrXXndXDd8RLEkiMDLovyyDtN6Jn HsW9PVMtu6sXvmbn0AHeHzHU/+bwB1LF4sx8O82tWKCgZlm270p+Bk6mjYmrlO4eQ11/AOF6 3ZlVoeXSaM4X0yoKa3ltdWaRoy9L0a4p7JuQYhBYIzjARbVjp9CmxctuQqW2qNSCJfagsUl8 mpcrs7xdhzfhzZHf8kQYWQcPYPPWLWqIuQINBF2PpxoBEACow9T4wPaQvKNG2LBnXeuLkDxf VGrZ/fDk0yfhG0174SjWXvDMIAgdNmfn2F4CM4F2FfPI32NZT34Td89fyWEWvP5/2I9HywyI QI/ubQvbqvm0l+DyzsdZNj4MBmNLy34Rg3K8uScgG7YbakzUplalbQKuzHrSW5OL5aBeKOG2 NGKJK7VZ4MzbdxhCLnXYvQwgnSkJ6B3AoBGv0LsLYzGUixzlMbNmYEhlQcK2scqprmFoX9rQ ymStV8b4Z37gkVmYeWGG2D9zl8gLj0u5Xw/KlF45JNxtMFBSL+Px7E1c+GJTWJxIENBhxRAu fxvbvduyJdXTObI51bqgV57510RjoLdzvVVqUpevmIdaMnavyUnDZOb8sBg3JG6NozZVzlXf S3FAvvK82zRShpd06ZNUbxPtNkruH/dT+6QV8gW3jX15gKGp2CtvhxLbi8ysV6zwtqxPkba2 03J0RAq2lVzxE/CSAP2qGPttElzHOPqhdmL6XjdmTw/WpF+qT8acB6Te8HZF+DriR/xG6EA1 MSdIK0vX4r5+U5bd0r7sh1ysSaYk/RI8hqxZZ4VGdPbVhFCOdT8AVcEXRoLsv+oN4x5WYJ9g 8G8Xw9+DvCNjFLxaGcL0ATHc8u8TyeegGRF3ZQNsRCqfVOLEYclYX+DqIly4ebCawAoIeWg2 GvN9cJAnFwARAQABiQI8BBgBCAAmFiEE+rk+3HzdEZjc/UVYkbtrRW9ELQIFAl2PpxoCGwwF CQeGH4AACgkQkbtrRW9ELQJX3g/8DAxtZTUJAlbKkluY30zITfcUwH4h9Rppxx/RvibZ1R4k 960OlvwyoRZ5rv2XiQA5VxOaVlh1tJErZnAyqgYwHr5CGQBjPEgkmRWBzme4W62uvCXOahxJ 4lNpr0TrVGRNOu223zYQcaN5S4Q5H2U9XNUFx8UF5leZIL6/Z6/bSGEW27vSuCxY6v8MkhQC 6l8T5RJqDsJmhwcVg9KDm8eGLkiu+kXS8iKl/Bw4o9257BI8hswBVRhN8kpHsecP2MGzKwn9 ccXWnOfM75qiq566UI26MY5priaGz5i+eCo26Rc0edm0IXxNs6rUZKVQUoxfMb/A/buJknYZ lUYXAgG2eDHEjlXvqNxQWHgfhIGqKFXDWuMt0sKP7Ta/lvGVPx9IHCTvkRZn9mtIN2/F9Lt5 sK3kezAlFw3BK6AIbD2v+g8TZnvKWSBidJHyhh7OEmKg3gXA3DxBpb7TU6iVUfG5e10RJUvQ qQNTSxv6mxJOgE3mEXizzj+tC6aEG/BzBwDsQpKquzUIKGCF2EGX9C7CZBhlsng/zmL3TFH6 EnY1tqV/lEg2/+gCLy/OE2dlE+EDZEtAiV183lzZNBs5Bg9NIz0Gq6a4ZkA8zDOFuxL2BFH2 EqrT33ladX2AIyKPMF50IwY4TMxGRlKhAjb4++pb55vBwVBLaTC09mvA+CuupPU= Message-ID: Date: Mon, 27 Jul 2020 23:09:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] draft-ietf-mls-architecture and draft-ietf-mls-mls-protocol review 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, 28 Jul 2020 04:09:16 -0000 Dear, list, Thank you so much for all your efforts into developing MLS. After re-reading the architecture and protocol drafts, I have some comments. Please, excuse me if I got anything wrong. Apologies as well if this have been already discussed. - While it is clear on the architecture draft that 'Client' refers to a device that a user has, it is unclear on the protocol draft and might generate confusion, specifically, by the definition: """ Client: : An agent that uses this protocol to establish shared cryptographic state with other clients. A client is defined by the cryptographic keys it holds. """ Might be good to clarify here the relationship with devices and users, as this is something often enforced by messaging protocols, such as XMPP. - It is unclear if any member can 'Add' another one. In the case of 'Remove', it is clear, as: """ Members are removed from the group in a similar way. Any member of the group can send a _Remove_ proposal followed by a _Commit_ message, which adds new entropy to the group state that's known to all except for the removed member. Note that this does not necessarily imply that any member is actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism. """ It might be good to add the same note to the 'Add' mechanism, as some protocols might enforce only some members to be able to add others (an admin, for example). I think this is clearer on the architecture draft. - While there is a deletion schedule section, it should perhaps be enforced on several sections where deletion is critical: reuse of KeyPackages, key/nonce pair reuse, etc. It will be good to specially refer where these values should be safely deleted, even in regars that, on some occasions, key/nonce pairs, for example, should be kept in memory for delayed messages. - It will be good to enforce a time, as part of an structure to which retention occurs: """ For usability, MLS clients might be required to keep the AEAD key and nonce for a certain amount of time to retain the ability to decrypt delayed or out of order messages, possibly still in transit while a decryption is being done. """ This time, I think should be enforced by the application but could be part of an struct and periodically be checked. After the times passes, the values should be deleted. - I'm not really sure of this section: """ Decryption is done by decrypting the metadata, then the message, and then verifying the content signature. """ Wouldn't it be better to first verify the signature and then decrypt the message? I can imagine that, as it is written, an application can show the messages to the end users without verifying the identity (and I assume integrity, as well). - What happens if a proposal or message is invalid? On these sections: """ An invited member receiving a _Welcome_ message can recognize group creation if the number of entries in the `members` array is equal to the number of leaves in the tree minus one. A client receiving a _Welcome_ message SHOULD verify whether it is a newly created group, and if so, SHOULD verify that the above process was followed by reconstructing the _Add_ and _Commit_ messages, and verifying that the resulting transcript hashes and epoch secret match those found in the Welcome message. and The sender of a _Commit_ MUST include all valid proposals that it has received during the current epoch. Invalid proposals include, for example, proposals with an invalid signature or proposals that are semantically invalid, such as an _Add_ when the sender does not have the application-level permission to add new users. """ What will be the correct behaviour when failure? Should the messages be ignored or ask to be resent? I assumed ignored; but might be worth noting. - Will it be better to use a MAC key? On the section: """ To prevent counter manipulation by the server, the counter's integrity can be ensured by including the counter in a signed message envelope. """ Might be better to somehow derive a MAC key and attach it to the counter... - Security level: On the section: """ requirements, clients can choose between two security levels (roughly 128-bit and 256-bit). Within the security levels clients can choose between faster """ As I see that ed448 is used, it is worth noting that is security level is of 224-bit, as stated over: https://tools.ietf.org/html/rfc8032#section-1 I'll keep on reviewing some other parts in the future in more detail. I submitted two pull request with some grammar fixes as well and can put these thoughts on issues on the repository. Thanks! -- Sofía Celi @claucece http://claucece.github.io/ Cryptographic research and implementation at many places, but mainly Cloudflare FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02 From nobody Mon Jul 27 22:16: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 866843A0C73 for ; Mon, 27 Jul 2020 22:16:47 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2aKBrkoVfMV4 for ; Mon, 27 Jul 2020 22:16:42 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A53A0C70 for ; Mon, 27 Jul 2020 22:16:41 -0700 (PDT) X-ASG-Debug-ID: 1595913400-0e39451ec895170001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id CtVXzb3eP8tMBkKD; Mon, 27 Jul 2020 22:16:40 -0700 (PDT) X-Barracuda-Envelope-From: britta.hale@nps.edu Received: from skywalker.ern.nps.edu (172.20.4.117) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Mon, 27 Jul 2020 22:16:39 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.173) by skywalker.ern.nps.edu (172.20.4.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3 via Frontend Transport; Mon, 27 Jul 2020 22:16:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Aevz2ybbYrvJVQbuKBRgFVxZz1mRCggNaX/nxRnY2xE1HCj4TYUifI45p0mjeQTDawKDslbyXs6UHoRvXXM+iNfrDNpJMiuQlPwnSrdJOU0bOto0EpCLUlGLuRCzwb7vr86k4iE4hXYvBbRwc5QN8iKiYxYK9YVgt4OA/ffGfX8O0VV+epEAo4Mc3l4kmJoT5i4fNOMDIA+5nY42Soi3TUn/vZ023oA0cwvEpf6eONo7leVXzbW2TfJL7jq59KhWRUYz7VKcnUQagzbt/zryLR1Nv9h74x2AqwiBQ65NjXVWndjQZNPvkWAoJiUly32GiWQOlVb4BElSNGkDuSrYgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8TmX77M6kqHUqpAx8kuaw7loPrQAlXodXykCvFiAYdE=; b=m3ytlNZNEu9AKU4CMfqNVz7uADwg1kWI4jqcOZn5f70RQq0v3w9rj+YJaSazI2CGxTW0oDQ0yRwKOrq5S+y0q9OuaTx/t0d+fS0hWKClWHAfFVQDWOL9aAzvI8HyLhACJxQ5UfeHHd/pnLF4v+95sqXEwr+FweTrvkiTvNnG2RgmvikWgZ+l16cQasHpNPtFpglgBYY1ppkXo5yrjocZB6VNOqXvJlAb4gzCN9Sk6ZkdQ7B6CcEcPDQUbmKI2583sqlD/TSYJyQwNcyZS2NENeVTSGcba2WzvfiW8aLRbQ9jwjLqFBp3fjM/1tsdG/QKd1hNLqfuMvzsy3klJmVo4A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nps.edu; dmarc=pass action=none header.from=nps.edu; dkim=pass header.d=nps.edu; arc=none Received: from BY5PR13MB3348.namprd13.prod.outlook.com (2603:10b6:a03:1aa::23) by BY5PR13MB3288.namprd13.prod.outlook.com (2603:10b6:a03:186::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 05:16:38 +0000 Received: from BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::cd68:c4a7:9a8e:7f33]) by BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::cd68:c4a7:9a8e:7f33%7]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 05:16:38 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:186::28] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:186::28 From: "Hale, Britta (CIV)" To: Chelsea Komlo , "mls@ietf.org" CC: "rlb@ipv.sx" , "brendan=40cloudflare.com@dmarc.ietf.org" Thread-Topic: [MLS] Hiding content type X-ASG-Orig-Subj: Re: [MLS] Hiding content type Thread-Index: AQHWWR1miPCJW/kzdkaeKDSwZdPxN6kFmZ8AgAAQhICAAAtsAIAA+9iAgBBmLQCAAY5egIAAHi+AgAAqY4CAA4bMgP//n6WA Date: Tue, 28 Jul 2020 05:16:37 +0000 Message-ID: References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.17.200615 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nps.edu; x-originating-ip: [2601:647:cb00:2941:86c:e96:626e:6ae8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf2ddecd-e775-4326-e644-08d832b5679a x-ms-traffictypediagnostic: BY5PR13MB3288: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ucFrzwa0GW8QwWpRuDTQn4fWLcyIosydqjuus9//CmzlKaCEZ5xnJN8QG15VTSzw4IaLailIaDQcpKTil88w3FsNGVj8Z2yEo8mjmg8Hz8fYnH5OCvIu1uPh1XpJh61HT9tOFe3pB5+cEMCyp6W1sWOwfGiXJLDQ1orQCfNgJOsVPSUgA6S9TG7uPabDkYCy4whf8bVtWXyLtn9QVSu7vp3MLQPaVJpDhJ6bHIT1zoD7cMYyeD1K/6260OU+Bn8Yagoob3pLWVzQu05vvzNlKcyD0qQzxC39DSYH0VZRW1oCY9YoZy+JAJ84LqU/U52HelJHV+fWS9bj9w/5PgSbaLaxnAIqKuriXhup50wMHKwcWCLK1oUSYoU7prqJZPxgXEUxxIL489rNRD6zqXj4gA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3348.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(39850400004)(396003)(136003)(346002)(53546011)(6506007)(966005)(76116006)(66446008)(64756008)(66556008)(786003)(316002)(36756003)(30864003)(4326008)(478600001)(6486002)(6512007)(8936002)(83380400001)(86362001)(110136005)(33656002)(2906002)(75432002)(66476007)(8676002)(71200400001)(2616005)(54906003)(5660300002)(66946007)(166002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ss4vEvXH7WPoUYH47XghlaKe6SEouzVoVjo5DjSSz6KtcnS4SJsZTSb3LmLcTTA8v7LjVWKn5CXFFh8B2ENGHh9/lNbZoJm4tCUgl6Eo/wx+fSpY/JjpDtAezjAeyrYJMdz+VEQAMiJkipejcQdwsc6GE/Au3V+xX4EsEXSThBJesj+ukXLGcrAVIRuaWn5W2/fWC8JkWc3hL4VERia6ffuTMwo/m5YxIKIsmOVTTgsFvnDAQe6D5qJKT+k4SzlN8pJthSLGWQg8bEqwF+DSw1E+VuaU/CNgS5xELFI6oNwvxcXpFcr4AEKtY2vmApKvNduvSV/dEsfoNZ/vyBGM0Kv0zBcQk32zvKVQUVsTM/vfIHPXuHEezYjmH3hMb0u/hCZN4oYPcICd41p64am8ePe9BQlsbcbu4obaKTM6phDmMl+C/+xLs1Fwh3Ub5xJ50AyES6iMOY0JFViiEYfb7ynIW+FDC1wZdhCCNdawWiQMIfGZRwt2dzu9v1yn5FPqaAET0b5wls/tK6UXzz0MPRruUYChHrErODTHFVJUeemJ29JkSiDDsy5DFg2zswb7jT3nl2mck43pjjYmZ4QMK9c0wUG2CPXHULAcLfLdz7PrEdelWTKBwPJGTC1USHcSumuYxzw6nIsIIMKBu/+ae6VjojyB3eBY7Sbds0RcDdhOeS+LuXVhztseqWoJ0amWC6GtRC1ej3OQ0TwFO803xA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_B72B8E66D973460A952027D8AC30E4FAnpsedu_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf2ddecd-e775-4326-e644-08d832b5679a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 05:16:38.0350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6d936231-a517-40ea-9199-f7578963378e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3eQWENBVLTDO0WdbMXfDUI381JhxgDK8K0WNAUMOrKJBI2RI7CCzWHZydSg6RPGS9k8ck4zlJ9Po7S/0IP0tHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3288 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1595913400 X-Barracuda-URL: https://205.155.65.106:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Scan-Msg-Size: 40369 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83514 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 05:16:48 -0000 --_000_B72B8E66D973460A952027D8AC30E4FAnpsedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJpdmFjeS1ieS1kZWZhdWx0IGlzIGEgZ29hbCB0aGF0IEkgdGhpbmsgbW9zdCBvbiB0aGUgbWFp bGluZ2xpc3QgY2FuIGFncmVlIHdpdGggKGF0IGxlYXN0IHRoZXJlIGhhdmUgbm90IGJlZW4gb2Jq ZWN0aW9ucyBhYm91dCB0aGF0IHNvIGZhcikuIEl0IGlzICpob3cqIGl0IGlzIGFjaGlldmVkIHRo YXQgaXMgdGhlIGlzc3VlLg0KDQpBIHRoZSBtb21lbnQsIG9uZSBtZXRob2QgaGFzIGJlZW4gcHJl c2VudGVkIGFuZCBzdHJvbmdseSBhcmd1ZWQgZm9yLCBidXQgdGhlcmUgZG9lcyBub3Qgc2VlbSB0 byBiZSBhIGdvb2QgYmFja2luZyBjYXNlIGZvciB0aGF0IGFwcHJvYWNoLiBBbHRlcm5hdGl2ZWx5 LCB0aGVyZSBjb3VsZCBiZSBvdGhlciB3YXlzIG9mIGFjaGlldmluZyBwcml2YWN5IGFuZCBjb250 ZW50IGhpZGluZyBhbmQgYWxsZXZpYXRpbmcgc29tZSBvZiB0aGUgdmFyaW91cyB0eXBlcyBvZiBj b25jZXJucyB0aGF0IGhhdmUgYmVlbiByYWlzZWQgZnJvbSBkaWZmZXJlbnQgY29ybmVycy4NCg0K LSAgRm9yIGV4YW1wbGUsIGl0IHdhcyBwcm9wb3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0IG9uIDE0 IEp1bHkgdGhhdCB3ZSBjb3VsZCBjb25zaWRlciBhIGxvbmdlciBmaWVsZCB0byBhdm9pZCBjb2xs aXNpb25zLg0KLSAgQWxzbywgdGhlcmUgZG9lcyBub3Qgc2VlbSB0byBiZSBhIGZpcm0gcmVhc29u IGZvciBkZXJpdmluZyB0aGUgZXBvY2ggSUQgYXMgcHJvcG9zZWQuIElmIHRoZSBoYXNoIHdhcyBp bnN0ZWFkIG92ZXIgb25seSB0aGUgKGN1cnJlbnQgdmVyc2lvbikgZ3JvdXAvZXBvY2ggSUQsIHRo ZW4gdGhlcmUgd291bGQgYmUgbm8gdmFyaWFibGUgaW5wdXQgYW5kIHRoZSBlcG9jaCBJRCB3b3Vs ZCBiZSBwcmVkaWN0YWJsZSBieSBhbGwgbWVtYmVycyBvZiB0aGUgZ3JvdXAgKGJ1dCBub3QgdGhv c2Ugb3V0c2lkZSkuIFRoYXQgd291bGQgYWxsYXkgc29tZSBvZiB0aGUgZm9ya2luZyBjb25jZXJu cy4gQSBjb21wcm9taXNlIG1pZ2h0IGJlIGZvdW5kIG9uIHdoYXQgaW5wdXRzIHRvIHVzZSwgc28g dGhhdCB0aGUgZXBvY2ggSUQgcmVtYWlucyBwcmVkaWN0YWJsZSBvbmx5IHRvIGdyb3VwIG1lbWJl cnMgZm9sbG93aW5nIGFuIGFkZC9yZW1vdmFsLg0KLSAgRmluYWxseSwgKGlmIHdlIHJlYWxseSB3 YW50IHRvIGV4cGFuZCBvbiBwb3NzaWJpbGl0aWVzKSBpZiB0aGUgZXBvY2ggSUQgd2FzIHRha2Vu IGFzIGFuIGVuY3J5cHRpb24gb2YgdGhlIGN1cnJlbnQgZ3JvdXAvZXBvY2ggSUQgaW5zdGVhZCBv ZiBhIGhhc2gsIHRoZW4gaXQgY291bGQgYmUgdW5pcXVlbHkgcmVjb25jaWxhYmxlIHdoZW4gcmVx dWlyZWQuIFRoZSBncm91cC9lcG9jaCBJRCBsZW5ndGggaXMgYWxyZWFkeSBhY2NvdW50ZWQgZm9y IGluIHRoZSBjdXJyZW50IHNwZWMsIHNvIGNvbXByZXNzaW9uIHdpdGggYSBoYXNoIGlzIG5vdCBy ZWFsbHkgYSBib251cyBmYWN0b3IuDQoNCkp1c3QgdG8gYmUgY2xlYXIsIEkgZG8gbm90IHRoaW5r IHRoYXQgdGhlIHRoaXJkIHBvaW50IGFib3ZlIGlzIHJlYWxseSBhIGdvb2Qgb3B0aW9uLiBIb3dl dmVyLCBpdCBkb2VzIGhpZ2hsaWdodCB0aGF0IHRoZXJlIGFyZSBvdGhlciBvcHRpb25zIHRvIG1l ZXQgdGhlIGVuZCBnb2FsIG9mIGNvbnRlbnQgaGlkaW5nLiBUaGUgb3RoZXIgdHdvIHBvaW50cyBv dWdodCB0byBiZSBjb25zaWRlcmVkLg0KDQpUaGUg4oCccG9zaXRpdmUgdXNlIGNhc2XigJ0gZGVz Y3JpYmVkIHRodXMgZmFyIGlzIGFuIGFyZ3VtZW50IGZvciB0aGUgZW5kIGdvYWwgb2YgY29udGVu dCBoaWRpbmcsIGJ1dCBpcyBub3QgYW4gYXJndW1lbnQgZm9yIGNvbnRlbnQgaGlkaW5nIGluIHRo ZSBwYXJ0aWN1bGFyIHdheSB0aGF0IGhhcyBiZWVuIHByb3Bvc2VkLiBIYXZpbmcgYSBwb3NpdGl2 ZSB1c2UgY2FzZSB0byBzdXBwb3J0IHRoZSBwcmVjaXNlIHByb3Bvc2VkIGNoYW5nZSB3b3VsZCBi ZSBoZWxwZnVsLg0KDQpVbHRpbWF0ZWx5LCBJIHdvdWxkIGxpa2UgdG8gc2VlIGFyZ3VtZW50cyBm b3IvYWdhaW5zdCB0aGUgdmFyaW91cyBvdGhlciB3YXlzIG9mIGFjaGlldmluZyBjb250ZW50IGhp ZGluZywgc3VjaCBhcyB0aG9zZSBsaXN0ZWQgYWJvdmUgKG9yIG90aGVycykuIFRoaXMgYXBwbGll cyB0byBib3RoIHRoZSBjb25jZXJucyBhYm91dCByZXNpc3RhbmNlIHRvIGNvbGxpc2lvbnMgYXMg d2VsbCBhcyB0aGUgZ2VuZXJhbCBhaW0gb2YgcHJpdmFjeS4gSXQgaXMgYnkgbm8gbWVhbnMgYW4g YWJzb2x1dGUgZmFjdCB0aGF0IHdlIGNhbiBzdXBwb3J0IG9ubHkgb25lIG9yIHRoZSBvdGhlciwg c28gdGhlcmUgbWF5IGJlIGEgc29sdXRpb24gdGhhdCBhZGRyZXNzZXMgYWxsIGNvbmNlcm5zIGRp c2N1c3NlZCBzbyBmYXIuIEl0IGlzIGRlZmluaXRlbHkgd29ydGh3aGlsZSB0byB0cnkgZm9yIHRo YXQuDQoNCg0KQnJpdHRhDQoNCg0KRnJvbTogQ2hlbHNlYSBLb21sbyA8Y2hlbHNlYS5rb21sb0Bn bWFpbC5jb20+DQpEYXRlOiBNb25kYXksIEp1bHkgMjcsIDIwMjAgYXQgOTowMSBQTQ0KVG86ICJt bHNAaWV0Zi5vcmciIDxtbHNAaWV0Zi5vcmc+DQpDYzogIkhhbGUsIEJyaXR0YSAoQ0lWKSIgPGJy aXR0YS5oYWxlQG5wcy5lZHU+LCAicmxiQGlwdi5zeCIgPHJsYkBpcHYuc3g+LCAiYnJlbmRhbj00 MGNsb3VkZmxhcmUuY29tQGRtYXJjLmlldGYub3JnIiA8YnJlbmRhbj00MGNsb3VkZmxhcmUuY29t QGRtYXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTFNdIEhpZGluZyBjb250ZW50IHR5cGUN Cg0KSSB3b3VsZCBsaWtlIHRvIGFmZmlybSB0aGUgcG9zaXRpdmUgdXNlIGNhc2UgUmljaGFyZCBk ZXNjcmliZWQsIGFuZCBzYXkgdGhhdCBtaW5pbWl6aW5nIG1ldGFkYXRhIHdoZXJlIHBvc3NpYmxl IGlzIHZhbHVhYmxlIGFuZCBsZWF2ZXMgb3BlbiB0aGUgcG9zc2liaWxpdHkgb2YgdXNpbmcgTUxT IGluIGxlc3MtdHJ1c3RlZCBzZXR0aW5ncy4gVGhlcmUgYXJlIG1lc3NhZ2luZyBhcHBsaWNhdGlv bnMgY3VycmVudGx5IGJlaW5nIGRldmVsb3BlZCBpbiBwcmFjdGljZSBbMV0gdGhhdCBwcm92aWRl IG1ldGFkYXRhIHJlc2lzdGFuY2UgKGFuZCBob3BlZnVsbHkgbW9yZSB3aWxsIGZvbGxvdyB0aGlz IHRyZW5kIGluIHRoZSBmdXR1cmUpLiBJdCB3b3VsZCBiZSBnb29kIHRvIGtlZXAgdGhlIGRvb3Ig b3BlbiB0byB0aGUgdXNlIG9mIE1MUyBpbiB0aGVzZSBzZXR0aW5ncy4NCg0KQXMgSSBhbSBqdXN0 IG5vdyByZWFkaW5nIG92ZXIgdGhlIGxhdGVzdCBkcmFmdCwgSSBkb24ndCBoYXZlIG11Y2ggdG8g YWRkIGF0IHRoaXMgbW9tZW50IGFzIHRvIGhvdyB0byBkZXJpdmUgdGhlc2UgZmllbGRzIGltcGxp Y2l0bHksIGJ1dCBJIGFtIGhhcHB5IHRvIHRha2UgYSBjbG9zZXIgbG9vayBhbmQgcHJvdmlkZSBy ZWNvbW1lbmRhdGlvbnMgaWYgdGhlIGdyb3VwIGRvZXNuJ3QgY29tZSB0byBjb25zZW5zdXMgaW4g dGhlIG1lZXRpbmcgdGhpcyB3ZWVrLg0KDQpbMV0gaHR0cHM6Ly9vcGVucHJpdmFjeS5jYS93b3Jr L2N3dGNoLw0KDQpPbiBTYXQsIEp1bCAyNSwgMjAyMCBhdCA0OjEwIFBNIEJyZW5kYW4gTWNNaWxs aW9uIDxicmVuZGFuPTQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2xv dWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCknigJltIGNvbmNlcm5lZCBhYm91 dCBhZHZlcnNhcmlhbCBjb2xsaXNpb25zLCB0aGF0J2QgY2F1c2UgYSBwYXJ0aWFsIERvUyBsaWtl IHlvdSBzYXkuIFRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIGNhdXNlIHBhcnRpYWwgRG9TIGluIGFu IE1MUyBncm91cCwgYnV0IEkgdGhpbmsgaXTigJlzIGdvb2QgdG8gbWluaW1pemUgdGhlIGF2ZW51 ZXMgZm9yIGF0dGFjay4NCg0KSW4geW91ciBleGFtcGxlLCBpdCBzb3VuZHMgbGlrZSB5b3XigJly ZSB0cnlpbmcgdG8gYWNoaWV2ZSB1bmxpbmthYmlsaXR5IGJldHdlZW4gbWVzc2FnZXMsIHdpdGgg YSBHZW5lcmljIENvbW1pdCBTZXF1ZW5jaW5nIFNlcnZpY2Ugd2hpY2ggaXMgYmFzaWNhbGx5IGEg S1Ygc3RvcmUgdGhhdCBvbmx5IGFjY2VwdHMgb25lIHdyaXRlIHBlciBrZXkuIFNvIGluIHRoaXMg c2NlbmFyaW8sIEkgdGhpbmsgeW91IHdvdWxkIGJlIG11Y2ggYmV0dGVyIG9mZiBieSBzaW1wbHkg dHJ1bmNhdGluZyB0aGUgZ3JvdXAgSUQgYW5kIGVwb2NoIGZyb20gTUxTQ2lwaGVydGV4dCAobWFr aW5nIHRoZW0gaW1wbGljaXQpLCBhbmQgY2hvb3NpbmcgdGhlIGtleSB0aGF0IGVhY2ggbWVzc2Fn ZSBpcyBzdG9yZWQgdW5kZXIgd2l0aCBzb21lIGZ1bmN0aW9uIG9mOiAxLikgYSBncm91cCBzZWNy ZXQsIGFuZCAyLikgYSBtZXNzYWdlIGNvdW50ZXIuDQoNCldvdWxkIHRoYXQgd29yaz8NCg0KDQpP biBKdWwgMjUsIDIwMjAsIGF0IDEyOjM4IFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxt YWlsdG86cmxiQGlwdi5zeD4+IHdyb3RlOg0KDQpKdXN0IHNvIHdlJ3JlIGNsZWFyLCBpbiB5b3Vy IGV4YW1wbGUsIGFyZSB5b3UgY29uY2VybmVkIGFib3V0IGFjY2lkZW50YWwgb3IgYWR2ZXJzYXJp YWwgY29sbGlzaW9ucz8gIEkgaG9wZSB3ZSBhZ3JlZSB0aGF0IHdlIGNhbiBmaXggdGhlIGFjY2lk ZW50YWwgY2FzZSBqdXN0IGJ5IG1ha2luZyBhIGxvbmdlciBlcG9jaCBJRC4gIEluIHRoZSBhZHZl cnNhcmlhbCBjYXNlLCB0aGlzIHNlZW1zIGxpa2UgYSBwYXJ0aWFsIERvUyBhdCB3b3JzdCwgc2lu Y2UgdGhlIG1lbWJlcnMgd2hvIGluY29ycmVjdGx5IHRoaW5rIHRoZXkgYXJlIGluIHRoZSBwcmV2 aW91cyBlcG9jaCB3aWxsIG5vIGxvbmdlciBiZSBkZWNyeXB0aW5nIHdpdGggdGhlIHJpZ2h0IGtl eXMuDQoNCkFzIGZhciBhcyBhIHBvc2l0aXZlIGV4YW1wbGU6IEltYWdpbmUgYSBHZW5lcmljIENv bW1pdCBTZXF1ZW5jaW5nIFNlcnZpY2UgdGhhdCBwcm92aWRlcyBhIHJlbGlhYmxlIGJyb2FkY2Fz dC9sZWRnZXIgb3ZlciBhbm9ueW1vdXMgY2hhbm5lbHMgKGUuZy4sIGFzIGFuIG9uaW9uIHNlcnZp Y2UpLCBidXQgd2lsbCBvbmx5IGJyb2FkY2FzdC9yZWNvcmQgb25lIG1lc3NhZ2UgZm9yIGVhY2gg Z3JvdXBJRC9lcG9jaC4gIElmIHRoZSBncm91cElEL2Vwb2NoIGlzIG9wYXF1ZSwgdGhlbiBzdWNo IGEgc2VydmljZSBjYW4gYmUgcHJvdmlkZWQgd2l0aG91dCBsZWFybmluZyBhbnl0aGluZyBhYm91 dCB0aGUgZ3JvdXBzIGl0IHNlcnZlcyBvciB0aGVpciBldm9sdXRpb24uDQoNCg0KT24gU2F0LCBK dWwgMjUsIDIwMjAgYXQgMTo1MCBQTSBCcmVuZGFuIE1jTWlsbGlvbiA8YnJlbmRhbkBjbG91ZGZs YXJlLmNvbTxtYWlsdG86YnJlbmRhbkBjbG91ZGZsYXJlLmNvbT4+IHdyb3RlOg0KVGFrZSBmb3Ig ZXhhbXBsZSwgYSBicm9hZGNhc3QgY2hhbm5lbCB0aGF0J3Mgb3JkZXJlZCBidXQgbG9zc3kuIEEg Q29tbWl0IGdldHMgc2VudCB3aGVyZSB0aGUgbmV3IGVwb2NoIGlkIGNvbGxpZGVzIHdpdGggdGhl IHByZXZpb3VzIGVwb2NoIGlkLCBidXQgbm90IGFsbCBtZW1iZXJzIGdldCB0aGUgQ29tbWl0LiBT byBub3cgdGhlIGdyb3VwIGlzIGZyYWN0dXJlZCBhbmQgdGhlcmUncyBubyB3YXkgZm9yIG1lbWJl cnMgaW4gdGhlIHByZXZpb3VzIGVwb2NoIHRvIGtub3cgdGhhdCB0aGV5IG1pc3NlZCBhIG1lc3Nh Z2UuIFdoYXQgdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciBuZWVkcyB0byBkbyB0byBkZXRlY3Qg bG9zdCBtZXNzYWdlcywgaXMgaW1tZWRpYXRlbHkgcmUtaW1wbGVtZW50IHRoZSBjb3VudGVyIGVw b2NoIGlkIHRoYXQgeW91J3ZlIGp1c3QgcmVtb3ZlZC4NCg0KVGhhdCdzIGFuIGV4YW1wbGUgb2Yg YSBzeXN0ZW0gd2hlcmUgdGhpcyBjaGFuZ2UgaXMgcG9pbnRsZXNzIC8gaGFybWZ1bC4gSWYgeW91 IGNvdWxkIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBhIHN5c3RlbSB3aGVyZSB0aGUgY2hhbmdlIGlz ICpoZWxwZnVsKiwgdGhhdCB3b3VsZCBiZSBtb3JlIGludGVyZXN0aW5nLg0KDQpPbiBGcmksIEp1 bCAyNCwgMjAyMCBhdCAxMTowNSBBTSBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86 cmxiQGlwdi5zeD4+IHdyb3RlOg0KSSdtIGhvbmVzdGx5IHJlYWxseSBjb25mdXNlZCBieSB0aGUg d29ycnkgYWJvdXQgY29sbGlzaW9ucyBoZXJlLiAgVGhlIGN1cnJlbnQgZXBvY2ggSUQgY29sbGlk ZXMgdHJpdmlhbGx5IC0tIGl0J3MganVzdCBhIGNvdW50ZXIhICBBbmQgdGhlIGdyb3VwIElEIGlz IGFzc3VtZWQgdG8gYmUgcHVibGljIGFueXdheS4gIFNvIGlmIHlvdXIgYXV0aGVudGljYXRpb24g c2NoZW1lIGlzIGJyb2tlbiB3aGVuIHlvdSBoYXZlIGEgKGdyb3VwIElELCBlcG9jaCBJRCkgY29s bGlzaW9uLCB0aGVuIHlvdXIgc2NoZW1lIGlzIGFscmVhZHkgYnJva2VuLg0KDQpJZiB3ZSdyZSBn b2luZyB0byBibG9jayB0aGlzIGNoYW5nZSBvbiB0aGlzIGJhc2lzLCB0aGVuIHdlIG5lZWQgdG8g c2VlIGNsZWFybHkgYXJ0aWN1bGF0ZWQgYW4gYXV0aGVudGljYXRpb24gc2NoZW1lIHRoYXQgaXMg c2VjdXJlIGluIHRoZSBjdXJyZW50IG1vZGVsLCBidXQgYnJva2VuIGluIHRoZSBjYXNlIHdoZXJl IGVwb2NoIElEcyBhcmUgZGVyaXZlZCBvZmYgb2YgdGhlIGtleSBzY2hlZHVsZS4NCi0tUmljaGFy ZA0KDQpPbiBUdWUsIEp1bCAxNCwgMjAyMCBhdCAxMDozOCBBTSBIYWxlLCBCcml0dGEgKENJVikg PGJyaXR0YS5oYWxlQG5wcy5lZHU8bWFpbHRvOmJyaXR0YS5oYWxlQG5wcy5lZHU+PiB3cm90ZToN CkVuc3VyaW5nIHRoZSBtb3N0IGNvbnNlcnZhdGl2ZSBkZXNpZ24gYnkgZGVmYXVsdCBzZWVtcyBh ZHZpc2FibGU7IGhvd2V2ZXIgaXQgaXMgbm90IGNsZWFyIHRoYXQgdGhpcyBwcm9wb3NhbCBmb3Ig aGlkaW5nIGNvbnRlbnQgdHlwZSBpcyBhY3R1YWxseSBkb2luZyB0aGF0LiBJbmRlZWQsIGlmIGFu IGFwcGxpY2F0aW9uIGlzIGNvbmNlcm5lZCBhYm91dCBoaWRpbmcgdGhlIGNvbnRlbnQgdHlwZSwg d291bGQgbm90IHRoYXQgc2FtZSB0eXBlIG9mIGFwcGxpY2F0aW9uIGFsc28gYmUgY29uY2VybmVk IGFib3V0IGNvbGxpc2lvbnM/DQoNCkFzIEJyZW5kYW4gbm90ZXMsIHdlIGFyZSBub3QgdGFsa2lu ZyBhYm91dCBhY2NpZGVudGFsIGNvbGxpc2lvbnMgaGVyZS4gUHJlLWNvbXB1dGF0aW9uIGlzIGVu dGlyZWx5IHBvc3NpYmxlLCBzdWNoIGFzIGJ5IGEgbWFsaWNpb3VzIGdyb3VwIG1lbWJlciwgc28g dGhlIHdpbmRvdyBvZiBhdHRhY2sgaXMgbm90IGxpbWl0ZWQgdG8gb25lIGVwb2NoLg0KDQpJZiB0 aGlzIGlzIHRoaXMgUFIgcGFydGljdWxhciBpcyBvZiBwYXJ0aWN1bGFyIGludGVyZXN0IHRvIHNv bWUsIHRoZW4gaXQgd291bGQgYmUgZ29vZCB0byBzZWUgYSBjbGFyaWZ5aW5nIGV4cGxhbmF0aW9u IGFzIHRvIHRoZSBzZWN1cml0eSBpdCBhY2hpZXZlcyAoaS5lLiB3aHkgdGhpcyBpcyDigJxzZWN1 cml0eSBieSBkZXNpZ27igJ0gZGVzcGl0ZSBpbnRyb2R1Y2luZyBzdWNoIGNvbGxpc2lvbiBwb3Nz aWJpbGl0aWVzKSwgb3IgYSBjb25jcmV0ZSB1c2UtY2FzZS4gQWx0ZXJuYXRpdmVseSwgYXJlIHdl IHJlYWxseSBsaW1pdGVkIHRvIGEgNjQtYml0IGZpZWxkLCBvciBjYW4gdGhhdCBsZW5ndGggYmUg YWRqdXN0ZWQgdG8gbWl0aWdhdGUgdGhlIGludHJvZHVjZWQgcHJvYmxlbXM/DQoNCg0KDQpBIGNs YXJpZnlpbmcgcG9pbnQgZm9yIHRob3NlIGZvbGxvd2luZyB0aGlzIHRocmVhZDogc29tZSByZWZl cmVuY2VzIGluIHRoZSBlbWFpbCBjaGFpbiBzdGF0ZSB0aGF0IHRoaXMgaXMgZW5jcnlwdGlvbiBv ZiB0aGUgZXBvY2ggSUQuIFRoYXQgaXMgbm90IHRoZSBjYXNlLiBUaGUgcHJvcG9zYWwgYmVpbmcg ZGlzY3Vzc2VkIGlzIGFib3V0IGEgaGFzaCB0aGVyZW9mIChoZW5jZSBkaXNjdXNzaW9uIG9uIGNv bGxpc2lvbnMpLg0KDQpCcml0dGENCg0KDQpGcm9tOiBNTFMgPG1scy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBCcmVuZGFuIE1jTWls bGlvbiA8YnJlbmRhbj00MGNsb3VkZmxhcmUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNs b3VkZmxhcmUuY29tQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IE1vbmRheSwgSnVseSAxMywgMjAy MCBhdCA5OjM3IEFNDQpUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBp cHYuc3g+Pg0KQ2M6IE1lc3NhZ2luZyBMYXllciBTZWN1cml0eSBXRyA8bWxzQGlldGYub3JnPG1h aWx0bzptbHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtNTFNdIEhpZGluZyBjb250ZW50IHR5 cGUNCg0KQXMgZmFyIGFzIGNvbGxpc2lvbiByZXNpc3RhbmNlLCBJJ20gbm90IHRvbyB3b3JyaWVk IGFib3V0IGNvbGxpc2lvbnMgYW1vbmcgNjQtYml0IHJhbmRvbSB2YWx1ZXMsIGVzcGVjaWFsbHkg YXMgdGhlIHNjb3BlIGZvciBjb2xsaXNpb24gaXMgZmFpcmx5IHNtYWxsLCBhcmd1YWJseSBqdXN0 IG9uZSBlcG9jaC4NCg0KVGhlIGlzc3VlIGlzbid0IHdpdGggYWNjaWRlbnRhbCBjb2xsaXNpb25z LCBpdCdzIHdpdGggbWFsaWNpb3VzIG9uZXMuIEFuIGF0dGFja2VyIGNhbiBwdXJwb3NlZnVsbHkg KGFuZCBxdWlja2x5KSBnZW5lcmF0ZSBjb21taXRzIHRoYXQgY3JlYXRlIGR1cGxpY2F0ZSBlcG9j aCBpZHMsIGFuZCBzZW5kIHRoZW0gdG8gYSBjbGllbnQgdG8gY29ycnVwdCB0aGVpciBncm91cCBz dGF0ZS4NCg0KSSB0aGluayB0aGUgaWRlYSBoZXJlIGlzIHRvIGJlIGNvbnNlcnZhdGl2ZSBieSBk ZWZhdWx0LiAgVGhlcmUgYXJlIHN5c3RlbXMgaW4gd2hpY2ggeW91IGNhbiBoaWRlIHRoZSBtZXRh ZGF0YSB5b3UncmUgdGFsa2luZyBhYm91dCB3aXRoIHRoaW5ncyBsaWtlIG1peG5ldHMgYW5kIGRy b3Bib3hlcy4NCg0KSXQncyBub3QganVzdCBiZWluZyBtb3JlIGNvbnNlcnZhdGl2ZSwgeW91J3Jl IG1ha2luZyBjaGFuZ2VzIHNwZWNpZmljYWxseSBmb3IgdmVyeSBuaWNoZSB1c2UtY2FzZXMgd2hl cmUgSSBkb24ndCB0aGluayB0aGUgc2VjdXJpdHkgb2YgdGhlIHdob2xlIHN5c3RlbSBoYXMgYmVl biB0aG91Z2h0IHRocm91Z2guIE1heWJlIHlvdSBoYXZlIGFuIGV4YW1wbGUgaW4gbWluZCwgYnV0 IEkgY2FuJ3QgdGhpbmsgb2YgYSBzeXN0ZW0gd2hlcmUgdGhpcyBjaGFuZ2UgcHJvdmlkZXMgYW55 IGFkZGl0aW9uYWwgcHJpdmFjeS4NCg0KT24gTW9uLCBKdWwgMTMsIDIwMjAgYXQgMTA6NTYgQU0g UmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCk9u IE1vbiwgSnVsIDEzLCAyMDIwIGF0IDEwOjU3IEFNIEJyZW5kYW4gTWNNaWxsaW9uIDxicmVuZGFu QGNsb3VkZmxhcmUuY29tPG1haWx0bzpicmVuZGFuQGNsb3VkZmxhcmUuY29tPj4gd3JvdGU6DQpX aXRoIHJlc3BlY3QgdG8gdXNpbmcgYW4gb3BhcXVlIGVwb2NoIGlkLCBJIGJlbGlldmUgdGhpcyB3 YXMgcHJvcG9zZWQgaW4gIzI0NTxodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29s L3B1bGwvMjQ1PiBhbmQgY29uc2Vuc3VzIHdhcyBhZ2FpbnN0IGl0IGJlY2F1c2UgaXQgbWFrZXMg aXQgbW9yZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50IHRoZSBEUy4gSXQncyBhbHNvIG5vdCBjbGVh ciB0byBtZSB3aGF0IHNlY3VyaXR5IHByb3BlcnRpZXMgeW91IHdhbnQgZnJvbSBhbiBvcGFxdWUg ZXBvY2ggaWQsIGJlY2F1c2UgdGhlIGN1cnJlbnQgUFIgZG9lc24ndCBwcm92aWRlIGNvbGxpc2lv biByZXNpc3RhbmNlIGFuZCBJJ2QgZXhwZWN0IHRoaXMgdG8gYmUgYSBzb3VyY2Ugb2YgY29uZnVz aW9uIGFuZCBidWdzLg0KDQpJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIG9uICMyNDUgZ290IGRlcmFp bGVkIGEgYml0IGJ5IHRoZSBmb2N1cyBvbiBub24tbGluZWFyIGVwb2Nocy4gIFRoZSBwb2ludCBo ZXJlIGlzIHRoYXQgZXZlbiBpbiBhIGNhc2Ugd2hlcmUgeW91IGhhdmUgbGluZWFyIGhpc3Rvcnks IEkgdGhpbmsgdGhlcmUncyBpbnRyaW5zaWMgdmFsdWUgaW4gdGhlIGVwb2NoIElEIGJlaW5nIG9w YXF1ZSBiZWNhdXNlIGl0IGdpdmVzIGludGVybWVkaWFyaWVzIGxlc3Mgb3Bwb3J0dW5pdHkgZm9y IG9zc2lmaWNhdGlvbi4NCg0KQXMgZmFyIGFzIGNvbGxpc2lvbiByZXNpc3RhbmNlLCBJJ20gbm90 IHRvbyB3b3JyaWVkIGFib3V0IGNvbGxpc2lvbnMgYW1vbmcgNjQtYml0IHJhbmRvbSB2YWx1ZXMs IGVzcGVjaWFsbHkgYXMgdGhlIHNjb3BlIGZvciBjb2xsaXNpb24gaXMgZmFpcmx5IHNtYWxsLCBh cmd1YWJseSBqdXN0IG9uZSBlcG9jaC4NCg0KDQpXaXRoIHJlc3BlY3QgdG8gZW5jcnlwdGluZyB0 aGUgY29udGVudCB0eXBlLCBpdCBhbHNvIHNlZW1zIHRvIG1lIHRoYXQgdGhpcyB3b3VsZCBjYXVz ZSBpc3N1ZXMgYmVjYXVzZSBkaWZmZXJlbnQgY29udGVudCB0eXBlcyBoYXZlIGRpZmZlcmVudCBk ZWxpdmVyeSBndWFyYW50ZWVzLiBTcGVjaWZpY2FsbHk6IG1lc3NhZ2VzIGFyZSBhbGxvd2VkIHRv IGJlIHVub3JkZXJlZCBhbmQgbG9zc3ksIHByb3Bvc2FscyBhcmUgYWxsb3dlZCB0byBiZSB1bm9y ZGVyZWQgYnV0IG5vdCBsb3NzeSwgYW5kIGNvbW1pdHMgYXJlIGJvdGggb3JkZXJlZCBhbmQgbm90 IGxvc3N5LiBJbiB0aGUgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2UndmUgdGFsa2VkIGFib3V0LCB0 aGUgRFMgZXNzZW50aWFsbHkgYWx3YXlzIG5lZWRzIHRvIGtub3cgdGhlIGNvbnRlbnQgdHlwZSB0 byBwcm92aWRlIHRoaXMuIENvbnZlcnNlbHksIHlvdSBkb24ndCBnZXQgbXVjaCBhZGRpdGlvbmFs IHByaXZhY3kgZnJvbSBlbmNyeXB0aW5nIHRoZSBjb250ZW50IHR5cGUgYmVjYXVzZSBhbiBlYXZl c2Ryb3BwZXIgY2FuIHNlZSB0aGUgZXBvY2ggaWQgY2hhbmdlIGFuZCBpbmZlciB3aGljaCBtZXNz YWdlIHdhcyBhIGNvbW1pdCwgb3Igc2VlIGEgZHJvcHBlZCBtZXNzYWdlIGdldHRpbmcgcmUtc2Vu dCBhbmQgaW5mZXIgaXQgd2FzIGEgcHJvcG9zYWwuDQoNCkkgZG9uJ3QgZGlzYWdyZWUgdGhhdCB0 aGVyZSBhcmUgZGlmZmVyZW50IGd1YXJhbnRlZXMgeW91IG5lZWQsIGJ1dCBsaWtlIEkgc2FpZCwg SSB0aGluayB0aGUgaWRlYSBoZXJlIGlzIHRvIGJlIGNvbnNlcnZhdGl2ZSBieSBkZWZhdWx0LiAg VGhlcmUgYXJlIHN5c3RlbXMgaW4gd2hpY2ggeW91IGNhbiBoaWRlIHRoZSBtZXRhZGF0YSB5b3Un cmUgdGFsa2luZyBhYm91dCB3aXRoIHRoaW5ncyBsaWtlIG1peG5ldHMgYW5kIGRyb3Bib3hlcy4g IEtlZXBpbmcgdGhlIGNpcGhlcnRleHQgYXMgb3BhcXVlIGFzIHBvc3NpYmxlIGtlZXBzIHRoZSBk b29yIG9wZW4gdG8gcnVubmluZyBNTFMgb3ZlciB0aG9zZSBzeXN0ZW1zIHdpdGhvdXQgTUxTJ3Mg b3duIG1ldGFkYXRhIHVuZGVybWluaW5nIHRoZWlyIHByaXZhY3kgcHJvcGVydGllcy4NCg0KRldJ VywgaW4gdGhlIHN5c3RlbXMgSSdtIGxvb2tpbmcgYXQgYnVpbGRpbmcsIHRoaXMgUFIgZG9lcyBu b3QgbWFrZSBhbnkgZGlmZmVyZW5jZSwgYmVjYXVzZSBjbGllbnRzIHVzZSBzZXBhcmF0ZSBjaGFu bmVscyBmb3IgUHJvcG9zYWxzL0NvbW1pdHMgdnMuIGFwcGxpY2F0aW9uIGRhdGEgYW5kIHRoZSBz ZXJ2ZXIgZG9lc24ndCBjaGVjay4NCg0KLS1SaWNoYXJkDQoNCg0KDQpPbiBNb24sIEp1bCAxMywg MjAyMCBhdCA4OjU2IEFNIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2 LnN4Pj4gd3JvdGU6DQpIaSBhbGwsDQoNClJlY2FsbCB0aGF0IFBSIzM0OSBkb2VzIHR3byB0aGlu Z3MgKDEpIHVzZSBhbiBvcGFxdWUgZXBvY2ggSUQsIGFuZCAoMikgZW5jcnlwdCB0aGUgY29udGVu dCB0eXBlIG9mIHRoZSBtZXNzYWdlIChhcHBsaWNhdGlvbiAvIHByb3Bvc2FsIC8gY29tbWl0KSBb MV0uDQoNClRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gdGhlIGNhbGwgbGFzdCB3ZWVrIHRo YXQgZW5jcnlwdGluZyB0aGUgY29udGVudCB0eXBlIG1pZ2h0IG5vdCBiZSB0aGF0IHVzZWZ1bCwg c2luY2UgYW4gYXBwbGljYXRpb24gdGhhdCByZWxpZXMgb24gYSBzZXJ2ZXIgdG8gYXNzdXJlIG9y ZGVyaW5nIG9mIGNvbW1pdHMgd2lsbCBuZWVkIHRvIGF0IGxlYXN0IGJlIGFibGUgdG8gdGVsbCBj b21taXRzIGZyb20gb3RoZXIgdGhpbmdzLiAgT2YgY291cnNlLCBldmVuIGlmIHRoZSBjb250ZW50 IHR5cGUgaXMgZW5jcnlwdGVkIGJ5IGRlZmF1bHQsIHRoZSBhcHBsaWNhdGlvbiBjYW4gYWRkIGl0 IGJhY2sgaW4gYXV0aGVudGljYXRlZCBkYXRhLCBvciBpbiBzb21lIHVuYXV0aGVudGljYXRlZCB3 cmFwcGVyLg0KDQpOZXQgb2YgdGhvc2UgY29uc2lkZXJhdGlvbnMsIEknbSBwZXJzb25hbGx5IHN0 aWxsIGluY2xpbmVkIHRvIG1lcmdlIHRoZSBQUiwgdG8gaGF2ZSBhIGNvbnNlcnZhdGl2ZSBiYXNl bGluZS4gIEJ1dCB0aG9zZSBvbiB0aGUgY2FsbCB0aG91Z2h0IGl0IHdvdWxkIGJlIHVzZWZ1bCB0 byBwb3NlIHRoaXMgdG8gdGhlIGdyb3VwLCBzbyBwbGVhc2Ugc3BlYWsgdXAgaWYgeW91IGhhdmUg Y29uY2VybnMuDQoNCi0tUmljaGFyZA0KDQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21s cy1wcm90b2NvbC9wdWxsLzM0OQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5n IGxpc3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMNCg0KDQoNCg== --_000_B72B8E66D973460A952027D8AC30E4FAnpsedu_ Content-Type: text/html; charset="utf-8" Content-ID: <2404641ACF0CEA42A3B9376536144A91@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcml2YWN5LWJ5LWRlZmF1bHQgaXMgYSBn b2FsIHRoYXQgSSB0aGluayBtb3N0IG9uIHRoZSBtYWlsaW5nbGlzdCBjYW4gYWdyZWUgd2l0aCAo YXQgbGVhc3QgdGhlcmUgaGF2ZSBub3QgYmVlbiBvYmplY3Rpb25zIGFib3V0IHRoYXQgc28gZmFy KS4gSXQgaXMgKjxiPmhvdzwvYj4qIGl0IGlzIGFjaGlldmVkIHRoYXQgaXMgdGhlIGlzc3VlLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgdGhlIG1vbWVudCwgb25lIG1ldGhvZCBoYXMgYmVl biBwcmVzZW50ZWQgYW5kIHN0cm9uZ2x5IGFyZ3VlZCBmb3IsIGJ1dCB0aGVyZSBkb2VzIG5vdCBz ZWVtIHRvIGJlIGEgZ29vZCBiYWNraW5nIGNhc2UgZm9yIHRoYXQgYXBwcm9hY2guIEFsdGVybmF0 aXZlbHksIHRoZXJlIGNvdWxkIGJlIG90aGVyIHdheXMgb2YgYWNoaWV2aW5nIHByaXZhY3kgYW5k IGNvbnRlbnQgaGlkaW5nIGFuZCBhbGxldmlhdGluZyBzb21lDQogb2YgdGhlIHZhcmlvdXMgdHlw ZXMgb2YgY29uY2VybnMgdGhhdCBoYXZlIGJlZW4gcmFpc2VkIGZyb20gZGlmZmVyZW50IGNvcm5l cnMuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mbmJzcDsgRm9yIGV4YW1wbGUsIGl0IHdh cyBwcm9wb3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0IG9uIDE0IEp1bHkgdGhhdCB3ZSBjb3VsZCBj b25zaWRlciBhIGxvbmdlciBmaWVsZCB0byBhdm9pZCBjb2xsaXNpb25zLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJm5ic3A7IEFsc28sIHRoZXJlIGRvZXMgbm90IHNl ZW0gdG8gYmUgYSBmaXJtIHJlYXNvbiBmb3IgZGVyaXZpbmcgdGhlIGVwb2NoIElEIGFzIHByb3Bv c2VkLiBJZiB0aGUgaGFzaCB3YXMgaW5zdGVhZCBvdmVyIG9ubHkgdGhlIChjdXJyZW50IHZlcnNp b24pIGdyb3VwL2Vwb2NoIElELCB0aGVuIHRoZXJlIHdvdWxkIGJlIG5vIHZhcmlhYmxlIGlucHV0 IGFuZCB0aGUgZXBvY2ggSUQgd291bGQgYmUgcHJlZGljdGFibGUNCiBieSBhbGwgbWVtYmVycyBv ZiB0aGUgZ3JvdXAgKGJ1dCBub3QgdGhvc2Ugb3V0c2lkZSkuIFRoYXQgd291bGQgYWxsYXkgc29t ZSBvZiB0aGUgZm9ya2luZyBjb25jZXJucy4gQSBjb21wcm9taXNlIG1pZ2h0IGJlIGZvdW5kIG9u IHdoYXQgaW5wdXRzIHRvIHVzZSwgc28gdGhhdCB0aGUgZXBvY2ggSUQgcmVtYWlucyBwcmVkaWN0 YWJsZSBvbmx5IHRvIGdyb3VwIG1lbWJlcnMgZm9sbG93aW5nIGFuIGFkZC9yZW1vdmFsLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSAmbmJzcDtGaW5hbGx5LCAoaWYgd2Ug cmVhbGx5IHdhbnQgdG8gZXhwYW5kIG9uIHBvc3NpYmlsaXRpZXMpIGlmIHRoZSBlcG9jaCBJRCB3 YXMgdGFrZW4gYXMgYW4gZW5jcnlwdGlvbiBvZiB0aGUgY3VycmVudCBncm91cC9lcG9jaCBJRCBp bnN0ZWFkIG9mIGEgaGFzaCwgdGhlbiBpdCBjb3VsZCBiZSB1bmlxdWVseSByZWNvbmNpbGFibGUg d2hlbiByZXF1aXJlZC4gVGhlIGdyb3VwL2Vwb2NoIElEIGxlbmd0aCBpcyBhbHJlYWR5DQogYWNj b3VudGVkIGZvciBpbiB0aGUgY3VycmVudCBzcGVjLCBzbyBjb21wcmVzc2lvbiB3aXRoIGEgaGFz aCBpcyBub3QgcmVhbGx5IGEgYm9udXMgZmFjdG9yLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkp1c3QgdG8gYmUgY2xlYXIsIEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIHRoaXJkIHBvaW50IGFi b3ZlIGlzIHJlYWxseSBhIGdvb2Qgb3B0aW9uLiBIb3dldmVyLCBpdCBkb2VzIGhpZ2hsaWdodCB0 aGF0IHRoZXJlIGFyZSBvdGhlciBvcHRpb25zIHRvIG1lZXQgdGhlIGVuZCBnb2FsIG9mIGNvbnRl bnQgaGlkaW5nLiBUaGUgb3RoZXIgdHdvIHBvaW50cyBvdWdodCB0byBiZSBjb25zaWRlcmVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCccG9zaXRpdmUgdXNlIGNhc2XigJ0gZGVzY3Jp YmVkIHRodXMgZmFyIGlzIGFuIGFyZ3VtZW50IGZvciB0aGUgZW5kIGdvYWwgb2YgY29udGVudCBo aWRpbmcsIGJ1dCBpcyBub3QgYW4gYXJndW1lbnQgZm9yIGNvbnRlbnQgaGlkaW5nIGluIHRoZSBw YXJ0aWN1bGFyIHdheSB0aGF0IGhhcyBiZWVuIHByb3Bvc2VkLiBIYXZpbmcgYSBwb3NpdGl2ZSB1 c2UgY2FzZSB0byBzdXBwb3J0IHRoZSBwcmVjaXNlIHByb3Bvc2VkDQogY2hhbmdlIHdvdWxkIGJl IGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVsdGltYXRlbHksIEkgd291bGQgbGlr ZSB0byBzZWUgYXJndW1lbnRzIGZvci9hZ2FpbnN0IHRoZSB2YXJpb3VzIG90aGVyIHdheXMgb2Yg YWNoaWV2aW5nIGNvbnRlbnQgaGlkaW5nLCBzdWNoIGFzIHRob3NlIGxpc3RlZCBhYm92ZSAob3Ig b3RoZXJzKS4gVGhpcyBhcHBsaWVzIHRvIGJvdGggdGhlIGNvbmNlcm5zIGFib3V0IHJlc2lzdGFu Y2UgdG8gY29sbGlzaW9ucyBhcyB3ZWxsIGFzIHRoZSBnZW5lcmFsIGFpbQ0KIG9mIHByaXZhY3ku IEl0IGlzIGJ5IG5vIG1lYW5zIGFuIGFic29sdXRlIGZhY3QgdGhhdCB3ZSBjYW4gc3VwcG9ydCBv bmx5IG9uZSBvciB0aGUgb3RoZXIsIHNvIHRoZXJlIG1heSBiZSBhIHNvbHV0aW9uIHRoYXQgYWRk cmVzc2VzIGFsbCBjb25jZXJucyBkaXNjdXNzZWQgc28gZmFyLiBJdCBpcyBkZWZpbml0ZWx5IHdv cnRod2hpbGUgdG8gdHJ5IGZvciB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaXR0YTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5DaGVsc2VhIEtvbWxvICZsdDtjaGVsc2VhLmtvbWxvQGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdWx5IDI3LCAyMDIwIGF0IDk6MDEgUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O21sc0BpZXRmLm9yZyZxdW90OyAmbHQ7bWxzQGlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7SGFsZSwgQnJpdHRhIChDSVYpJnF1b3Q7ICZsdDti cml0dGEuaGFsZUBucHMuZWR1Jmd0OywgJnF1b3Q7cmxiQGlwdi5zeCZxdW90OyAmbHQ7cmxiQGlw di5zeCZndDssICZxdW90O2JyZW5kYW49NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRmLm9yZyZx dW90OyAmbHQ7YnJlbmRhbj00MGNsb3VkZmxhcmUuY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW01MU10gSGlkaW5nIGNvbnRlbnQgdHlwZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxk IGxpa2UgdG8gYWZmaXJtIHRoZSBwb3NpdGl2ZSB1c2UgY2FzZSBSaWNoYXJkIGRlc2NyaWJlZCwg YW5kIHNheSB0aGF0IG1pbmltaXppbmcgbWV0YWRhdGEgd2hlcmUgcG9zc2libGUgaXMgdmFsdWFi bGUgYW5kIGxlYXZlcyBvcGVuIHRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBNTFMgaW4gbGVzcy10 cnVzdGVkIHNldHRpbmdzLiBUaGVyZSBhcmUgbWVzc2FnaW5nIGFwcGxpY2F0aW9ucyBjdXJyZW50 bHkNCiBiZWluZyBkZXZlbG9wZWQgaW4gcHJhY3RpY2UgWzFdIHRoYXQgcHJvdmlkZSBtZXRhZGF0 YSByZXNpc3RhbmNlJm5ic3A7KGFuZCBob3BlZnVsbHkgbW9yZSB3aWxsIGZvbGxvdyB0aGlzIHRy ZW5kIGluIHRoZSBmdXR1cmUpLiZuYnNwO0l0IHdvdWxkIGJlIGdvb2QgdG8ga2VlcCB0aGUgZG9v ciBvcGVuIHRvIHRoZSB1c2Ugb2YgTUxTIGluIHRoZXNlIHNldHRpbmdzLg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSSBhbSBqdXN0IG5vdyByZWFkaW5nIG92ZXIg dGhlIGxhdGVzdCBkcmFmdCwgSSBkb24ndCBoYXZlIG11Y2ggdG8gYWRkIGF0IHRoaXMgbW9tZW50 IGFzIHRvIGhvdyB0byBkZXJpdmUgdGhlc2UgZmllbGRzIGltcGxpY2l0bHksIGJ1dCBJIGFtIGhh cHB5IHRvIHRha2UgYSBjbG9zZXImbmJzcDtsb29rIGFuZCBwcm92aWRlIHJlY29tbWVuZGF0aW9u cyBpZiB0aGUgZ3JvdXAgZG9lc24ndCBjb21lIHRvJm5ic3A7Y29uc2Vuc3VzDQogaW4gdGhlIG1l ZXRpbmcgdGhpcyZuYnNwO3dlZWsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly9vcGVucHJpdmFjeS5jYS93b3JrL2N3dGNoLyI+aHR0cHM6Ly9vcGVucHJpdmFjeS5jYS93b3Jr L2N3dGNoLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gU2F0LCBKdWwgMjUsIDIwMjAgYXQgNDoxMCBQTSBCcmVuZGFuIE1jTWlsbGlv biAmbHQ7YnJlbmRhbj08YSBocmVmPSJtYWlsdG86NDBjbG91ZGZsYXJlLmNvbUBkbWFyYy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwY2xvdWRmbGFyZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBjb25jZXJuZWQgYWJvdXQgYWR2ZXJzYXJpYWwgY29s bGlzaW9ucywgdGhhdCdkIGNhdXNlIGEgcGFydGlhbCBEb1MgbGlrZSB5b3Ugc2F5LiBUaGVyZSBh cmUgb3RoZXIgd2F5cyB0byBjYXVzZSBwYXJ0aWFsIERvUyBpbiBhbiBNTFMgZ3JvdXAsIGJ1dCBJ IHRoaW5rIGl04oCZcyBnb29kIHRvIG1pbmltaXplIHRoZSBhdmVudWVzIGZvciBhdHRhY2suDQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHlvdXIgZXhh bXBsZSwgaXQgc291bmRzIGxpa2UgeW914oCZcmUgdHJ5aW5nIHRvIGFjaGlldmUgdW5saW5rYWJp bGl0eSBiZXR3ZWVuIG1lc3NhZ2VzLCB3aXRoIGEgR2VuZXJpYyBDb21taXQgU2VxdWVuY2luZyBT ZXJ2aWNlIHdoaWNoIGlzIGJhc2ljYWxseSBhIEtWIHN0b3JlIHRoYXQgb25seSBhY2NlcHRzIG9u ZSB3cml0ZSBwZXIga2V5LiBTbyBpbiB0aGlzIHNjZW5hcmlvLCBJIHRoaW5rIHlvdSB3b3VsZA0K IGJlIG11Y2ggYmV0dGVyIG9mZiBieSBzaW1wbHkgdHJ1bmNhdGluZyB0aGUgZ3JvdXAgSUQgYW5k IGVwb2NoIGZyb20gTUxTQ2lwaGVydGV4dCAobWFraW5nIHRoZW0gaW1wbGljaXQpLCBhbmQgY2hv b3NpbmcgdGhlIGtleSB0aGF0IGVhY2ggbWVzc2FnZSBpcyBzdG9yZWQgdW5kZXIgd2l0aCBzb21l IGZ1bmN0aW9uIG9mOiAxLikgYSBncm91cCBzZWNyZXQsIGFuZCAyLikgYSBtZXNzYWdlIGNvdW50 ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldvdWxkIHRoYXQgd29yaz88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKdWwgMjUsIDIwMjAsIGF0IDEy OjM4IFBNLCBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRh cmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBzbyB3ZSdyZSBjbGVhciwg aW4geW91ciBleGFtcGxlLCBhcmUgeW91IGNvbmNlcm5lZCBhYm91dCBhY2NpZGVudGFsIG9yIGFk dmVyc2FyaWFsIGNvbGxpc2lvbnM/Jm5ic3A7IEkgaG9wZSB3ZSBhZ3JlZSB0aGF0IHdlIGNhbiBm aXggdGhlIGFjY2lkZW50YWwgY2FzZSBqdXN0IGJ5IG1ha2luZyBhIGxvbmdlciBlcG9jaCBJRC4m bmJzcDsgSW4gdGhlIGFkdmVyc2FyaWFsIGNhc2UsIHRoaXMgc2VlbXMgbGlrZSBhIHBhcnRpYWwN CiBEb1MgYXQgd29yc3QsIHNpbmNlIHRoZSBtZW1iZXJzIHdobyBpbmNvcnJlY3RseSB0aGluayB0 aGV5IGFyZSBpbiB0aGUgcHJldmlvdXMgZXBvY2ggd2lsbCBubyBsb25nZXIgYmUgZGVjcnlwdGlu ZyB3aXRoIHRoZSByaWdodCBrZXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmYXIgYXMgYSBwb3NpdGl2ZSBleGFtcGxlOiBJbWFnaW5l IGEgR2VuZXJpYyBDb21taXQgU2VxdWVuY2luZyBTZXJ2aWNlIHRoYXQgcHJvdmlkZXMgYSByZWxp YWJsZSBicm9hZGNhc3QvbGVkZ2VyIG92ZXIgYW5vbnltb3VzIGNoYW5uZWxzIChlLmcuLCBhcyBh biBvbmlvbiBzZXJ2aWNlKSwgYnV0IHdpbGwgb25seSBicm9hZGNhc3QvcmVjb3JkIG9uZSBtZXNz YWdlIGZvciBlYWNoIGdyb3VwSUQvZXBvY2guJm5ic3A7DQogSWYgdGhlIGdyb3VwSUQvZXBvY2gg aXMgb3BhcXVlLCB0aGVuIHN1Y2ggYSBzZXJ2aWNlIGNhbiBiZSBwcm92aWRlZCB3aXRob3V0IGxl YXJuaW5nIGFueXRoaW5nIGFib3V0IHRoZSBncm91cHMgaXQgc2VydmVzIG9yIHRoZWlyIGV2b2x1 dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gU2F0LCBKdWwgMjUsIDIwMjAgYXQgMTo1MCBQTSBCcmVuZGFuIE1jTWls bGlvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyZW5kYW5AY2xvdWRmbGFyZS5jb20iIHRhcmdldD0i X2JsYW5rIj5icmVuZGFuQGNsb3VkZmxhcmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRha2UgZm9yIGV4YW1wbGUsIGEgYnJvYWRjYXN0IGNoYW5uZWwgdGhhdCdzIG9yZGVyZWQg YnV0IGxvc3N5LiBBIENvbW1pdCBnZXRzIHNlbnQgd2hlcmUgdGhlIG5ldyBlcG9jaCBpZCBjb2xs aWRlcyB3aXRoIHRoZSBwcmV2aW91cyBlcG9jaCBpZCwgYnV0IG5vdCBhbGwgbWVtYmVycyBnZXQg dGhlIENvbW1pdC4gU28gbm93IHRoZSBncm91cCBpcyBmcmFjdHVyZWQgYW5kIHRoZXJlJ3Mgbm8g d2F5IGZvciBtZW1iZXJzDQogaW4gdGhlIHByZXZpb3VzIGVwb2NoIHRvIGtub3cgdGhhdCB0aGV5 IG1pc3NlZCBhIG1lc3NhZ2UuIFdoYXQgdGhlIGFwcGxpY2F0aW9uIGRldmVsb3BlciBuZWVkcyB0 byBkbyB0byBkZXRlY3QgbG9zdCBtZXNzYWdlcywgaXMgaW1tZWRpYXRlbHkgcmUtaW1wbGVtZW50 IHRoZSBjb3VudGVyIGVwb2NoIGlkIHRoYXQgeW91J3ZlIGp1c3QgcmVtb3ZlZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIGFuIGV4 YW1wbGUgb2YgYSBzeXN0ZW0gd2hlcmUgdGhpcyBjaGFuZ2UgaXMgcG9pbnRsZXNzIC8gaGFybWZ1 bC4gSWYgeW91IGNvdWxkIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBhIHN5c3RlbSB3aGVyZSB0aGUg Y2hhbmdlIGlzICpoZWxwZnVsKiwgdGhhdCB3b3VsZCBiZSBtb3JlIGludGVyZXN0aW5nLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IEp1bCAyNCwgMjAyMCBhdCAxMTowNSBBTSBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkknbSBob25lc3RseSByZWFsbHkgY29uZnVzZWQgYnkgdGhlIHdvcnJ5 IGFib3V0IGNvbGxpc2lvbnMgaGVyZS4mbmJzcDsgVGhlIGN1cnJlbnQgZXBvY2ggSUQgY29sbGlk ZXMgdHJpdmlhbGx5IC0tIGl0J3MganVzdCBhIGNvdW50ZXIhJm5ic3A7IEFuZCB0aGUgZ3JvdXAg SUQgaXMgYXNzdW1lZCB0byBiZSBwdWJsaWMgYW55d2F5LiZuYnNwOyBTbyBpZiB5b3VyIGF1dGhl bnRpY2F0aW9uIHNjaGVtZSBpcyBicm9rZW4gd2hlbiB5b3UgaGF2ZQ0KIGEgKGdyb3VwIElELCBl cG9jaCBJRCkgY29sbGlzaW9uLCB0aGVuIHlvdXIgc2NoZW1lIGlzIGFscmVhZHkgYnJva2VuLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHdlJ3JlIGdvaW5nIHRvIGJsb2NrIHRoaXMgY2hh bmdlIG9uIHRoaXMgYmFzaXMsIHRoZW4gd2UgbmVlZCB0byBzZWUgY2xlYXJseSBhcnRpY3VsYXRl ZCBhbiBhdXRoZW50aWNhdGlvbiBzY2hlbWUgdGhhdCBpcyBzZWN1cmUgaW4gdGhlIGN1cnJlbnQg bW9kZWwsIGJ1dCBicm9rZW4gaW4gdGhlIGNhc2Ugd2hlcmUgZXBvY2ggSURzIGFyZSBkZXJpdmVk IG9mZg0KIG9mIHRoZSBrZXkgc2NoZWR1bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgMTQsIDIwMjAgYXQgMTA6 MzggQU0gSGFsZSwgQnJpdHRhIChDSVYpICZsdDs8YSBocmVmPSJtYWlsdG86YnJpdHRhLmhhbGVA bnBzLmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmJyaXR0YS5oYWxlQG5wcy5lZHU8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5FbnN1cmluZyB0aGUgbW9zdCBjb25zZXJ2YXRpdmUgZGVzaWdu IGJ5IGRlZmF1bHQgc2VlbXMgYWR2aXNhYmxlOyBob3dldmVyIGl0IGlzIG5vdCBjbGVhciB0aGF0 IHRoaXMgcHJvcG9zYWwgZm9yIGhpZGluZyBjb250ZW50IHR5cGUgaXMgYWN0dWFsbHkgZG9pbmcg dGhhdC4gSW5kZWVkLCBpZiBhbiBhcHBsaWNhdGlvbg0KIGlzIGNvbmNlcm5lZCBhYm91dCBoaWRp bmcgdGhlIGNvbnRlbnQgdHlwZSwgd291bGQgbm90IHRoYXQgc2FtZSB0eXBlIG9mIGFwcGxpY2F0 aW9uIGFsc28gYmUgY29uY2VybmVkIGFib3V0IGNvbGxpc2lvbnM/DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFzIEJyZW5kYW4gbm90ZXMsIHdlIGFyZSBub3QgdGFsa2luZyBhYm91dCBh Y2NpZGVudGFsIGNvbGxpc2lvbnMgaGVyZS4gUHJlLWNvbXB1dGF0aW9uIGlzIGVudGlyZWx5IHBv c3NpYmxlLCBzdWNoIGFzIGJ5IGEgbWFsaWNpb3VzIGdyb3VwIG1lbWJlciwgc28gdGhlIHdpbmRv dyBvZiBhdHRhY2sgaXMgbm90DQogbGltaXRlZCB0byBvbmUgZXBvY2guIDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SWYgdGhpcyBpcyB0aGlzIFBSIHBhcnRpY3VsYXIgaXMgb2YgcGFydGlj dWxhciBpbnRlcmVzdCB0byBzb21lLCB0aGVuIGl0IHdvdWxkIGJlIGdvb2QgdG8gc2VlIGEgY2xh cmlmeWluZyBleHBsYW5hdGlvbiBhcyB0byB0aGUgc2VjdXJpdHkgaXQgYWNoaWV2ZXMgKGkuZS4g d2h5IHRoaXMgaXMg4oCcc2VjdXJpdHkNCiBieSBkZXNpZ27igJ0gZGVzcGl0ZSBpbnRyb2R1Y2lu ZyBzdWNoIGNvbGxpc2lvbiBwb3NzaWJpbGl0aWVzKSwgb3IgYSBjb25jcmV0ZSB1c2UtY2FzZS4g QWx0ZXJuYXRpdmVseSwgYXJlIHdlIHJlYWxseSBsaW1pdGVkIHRvIGEgNjQtYml0IGZpZWxkLCBv ciBjYW4gdGhhdCBsZW5ndGggYmUgYWRqdXN0ZWQgdG8gbWl0aWdhdGUgdGhlIGludHJvZHVjZWQg cHJvYmxlbXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkEgY2xhcmlmeWluZyBwb2ludCBmb3IgdGhvc2UgZm9sbG93aW5nIHRo aXMgdGhyZWFkOiBzb21lIHJlZmVyZW5jZXMgaW4gdGhlIGVtYWlsIGNoYWluIHN0YXRlIHRoYXQg dGhpcyBpcyBlbmNyeXB0aW9uIG9mIHRoZSBlcG9jaCBJRC4gVGhhdCBpcyBub3QgdGhlIGNhc2Uu IFRoZSBwcm9wb3NhbCBiZWluZyBkaXNjdXNzZWQNCiBpcyBhYm91dCBhIGhhc2ggdGhlcmVvZiAo aGVuY2UgZGlzY3Vzc2lvbiBvbiBjb2xsaXNpb25zKS4gPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Ccml0dGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPk1MUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1scy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg QnJlbmRhbiBNY01pbGxpb24gJmx0O2JyZW5kYW49PGEgaHJlZj0ibWFpbHRvOjQwY2xvdWRmbGFy ZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGNsb3VkZmxhcmUuY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdWx5IDEzLCAy MDIwIGF0IDk6MzcgQU08YnI+DQo8Yj5UbzogPC9iPlJpY2hhcmQgQmFybmVzICZsdDs8YSBocmVm PSJtYWlsdG86cmxiQGlwdi5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+Jmd0Ozxi cj4NCjxiPkNjOiA8L2I+TWVzc2FnaW5nIExheWVyIFNlY3VyaXR5IFdHICZsdDs8YSBocmVmPSJt YWlsdG86bWxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWxzQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtNTFNdIEhpZGluZyBjb250ZW50IHR5cGU8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRj b2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJnYigyMDQsMjA0LDIwNCkiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgZmFyIGFzIGNvbGxpc2lvbiByZXNpc3RhbmNlLCBJ J20gbm90IHRvbyB3b3JyaWVkIGFib3V0IGNvbGxpc2lvbnMgYW1vbmcgNjQtYml0IHJhbmRvbSB2 YWx1ZXMsIGVzcGVjaWFsbHkgYXMgdGhlIHNjb3BlIGZvciBjb2xsaXNpb24gaXMgZmFpcmx5IHNt YWxsLCBhcmd1YWJseSBqdXN0IG9uZSBlcG9jaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBpc3N1ZSBp c24ndCB3aXRoIGFjY2lkZW50YWwgY29sbGlzaW9ucywgaXQncyB3aXRoIG1hbGljaW91cyBvbmVz LiBBbiBhdHRhY2tlciBjYW4gcHVycG9zZWZ1bGx5IChhbmQgcXVpY2tseSkgZ2VuZXJhdGUgY29t bWl0cyB0aGF0IGNyZWF0ZSBkdXBsaWNhdGUgZXBvY2ggaWRzLCBhbmQgc2VuZCB0aGVtDQogdG8g YSBjbGllbnQgdG8gY29ycnVwdCB0aGVpciBncm91cCBzdGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIHJn YigyMDQsMjA0LDIwNCkiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0 aGUgaWRlYSBoZXJlIGlzIHRvIGJlIGNvbnNlcnZhdGl2ZSBieSBkZWZhdWx0LiZuYnNwOyBUaGVy ZSBhcmUgc3lzdGVtcyBpbiB3aGljaCB5b3UgY2FuIGhpZGUgdGhlIG1ldGFkYXRhIHlvdSdyZSB0 YWxraW5nIGFib3V0IHdpdGggdGhpbmdzIGxpa2UgbWl4bmV0cyBhbmQgZHJvcGJveGVzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SXQncyBub3QganVzdCBiZWluZyBtb3JlIGNvbnNlcnZhdGl2ZSwgeW91J3Jl IG1ha2luZyBjaGFuZ2VzIHNwZWNpZmljYWxseSBmb3IgdmVyeSBuaWNoZSB1c2UtY2FzZXMgd2hl cmUgSSBkb24ndCB0aGluayB0aGUgc2VjdXJpdHkgb2YgdGhlIHdob2xlIHN5c3RlbSBoYXMgYmVl biB0aG91Z2h0IHRocm91Z2guDQogTWF5YmUgeW91IGhhdmUgYW4gZXhhbXBsZSBpbiBtaW5kLCBi dXQgSSBjYW4ndCB0aGluayBvZiBhIHN5c3RlbSB3aGVyZSB0aGlzIGNoYW5nZSBwcm92aWRlcyBh bnkgYWRkaXRpb25hbCBwcml2YWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBKdWwgMTMsIDIwMjAgYXQgMTA6NTYgQU0g UmljaGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0YXJnZXQ9Il9i bGFuayI+cmxiQGlwdi5zeDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1j b2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwy MDQpIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEp1bCAx MywgMjAyMCBhdCAxMDo1NyBBTSBCcmVuZGFuIE1jTWlsbGlvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJyZW5kYW5AY2xvdWRmbGFyZS5jb20iIHRhcmdldD0iX2JsYW5rIj5icmVuZGFuQGNsb3VkZmxh cmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xv cjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQp Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaXRoIHJlc3BlY3QgdG8g dXNpbmcgYW4gb3BhcXVlIGVwb2NoIGlkLCBJIGJlbGlldmUgdGhpcyB3YXMgcHJvcG9zZWQgaW4N CjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tbHN3Zy9tbHMtcHJvdG9jb2wvcHVsbC8yNDUi IHRhcmdldD0iX2JsYW5rIj4jMjQ1PC9hPiBhbmQgY29uc2Vuc3VzIHdhcyBhZ2FpbnN0IGl0IGJl Y2F1c2UgaXQgbWFrZXMgaXQgbW9yZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50IHRoZSBEUy4gSXQn cyBhbHNvIG5vdCBjbGVhciB0byBtZSB3aGF0IHNlY3VyaXR5IHByb3BlcnRpZXMgeW91IHdhbnQg ZnJvbSBhbiBvcGFxdWUgZXBvY2ggaWQsIGJlY2F1c2UNCiB0aGUgY3VycmVudCBQUiBkb2Vzbid0 IHByb3ZpZGUgY29sbGlzaW9uIHJlc2lzdGFuY2UgYW5kIEknZCBleHBlY3QgdGhpcyB0byBiZSBh IHNvdXJjZSBvZiBjb25mdXNpb24gYW5kIGJ1Z3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg dGhpbmsgdGhlIGRpc2N1c3Npb24gb24gIzI0NSBnb3QgZGVyYWlsZWQgYSBiaXQgYnkgdGhlIGZv Y3VzIG9uIG5vbi1saW5lYXIgZXBvY2hzLiZuYnNwOyBUaGUgcG9pbnQgaGVyZSBpcyB0aGF0IGV2 ZW4gaW4gYSBjYXNlIHdoZXJlIHlvdSBoYXZlIGxpbmVhciBoaXN0b3J5LCBJIHRoaW5rIHRoZXJl J3MgaW50cmluc2ljDQogdmFsdWUgaW4gdGhlIGVwb2NoIElEIGJlaW5nIG9wYXF1ZSBiZWNhdXNl IGl0IGdpdmVzIGludGVybWVkaWFyaWVzIGxlc3Mgb3Bwb3J0dW5pdHkgZm9yIG9zc2lmaWNhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFzIGZhciBhcyBjb2xsaXNpb24gcmVzaXN0YW5jZSwgSSdtIG5vdCB0b28gd29ycmllZCBh Ym91dCBjb2xsaXNpb25zIGFtb25nIDY0LWJpdCByYW5kb20gdmFsdWVzLCBlc3BlY2lhbGx5IGFz IHRoZSBzY29wZSBmb3IgY29sbGlzaW9uIGlzIGZhaXJseSBzbWFsbCwgYXJndWFibHkganVzdCBv bmUgZXBvY2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNv bG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aCByZXNwZWN0IHRvIGVuY3J5cHRpbmcg dGhlIGNvbnRlbnQgdHlwZSwgaXQgYWxzbyBzZWVtcyB0byBtZSB0aGF0IHRoaXMgd291bGQgY2F1 c2UgaXNzdWVzIGJlY2F1c2UgZGlmZmVyZW50IGNvbnRlbnQgdHlwZXMgaGF2ZSBkaWZmZXJlbnQg ZGVsaXZlcnkgZ3VhcmFudGVlcy4gU3BlY2lmaWNhbGx5OiBtZXNzYWdlcw0KIGFyZSBhbGxvd2Vk IHRvIGJlIHVub3JkZXJlZCBhbmQgbG9zc3ksIHByb3Bvc2FscyBhcmUgYWxsb3dlZCB0byBiZSB1 bm9yZGVyZWQgYnV0IG5vdCBsb3NzeSwgYW5kIGNvbW1pdHMgYXJlIGJvdGggb3JkZXJlZCBhbmQg bm90IGxvc3N5LiBJbiB0aGUgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2UndmUgdGFsa2VkIGFib3V0 LCB0aGUgRFMgZXNzZW50aWFsbHkgYWx3YXlzIG5lZWRzIHRvIGtub3cgdGhlIGNvbnRlbnQgdHlw ZSB0byBwcm92aWRlIHRoaXMuDQogQ29udmVyc2VseSwgeW91IGRvbid0IGdldCBtdWNoIGFkZGl0 aW9uYWwgcHJpdmFjeSBmcm9tIGVuY3J5cHRpbmcgdGhlIGNvbnRlbnQgdHlwZSBiZWNhdXNlIGFu IGVhdmVzZHJvcHBlciBjYW4gc2VlIHRoZSBlcG9jaCBpZCBjaGFuZ2UgYW5kIGluZmVyIHdoaWNo IG1lc3NhZ2Ugd2FzIGEgY29tbWl0LCBvciBzZWUgYSBkcm9wcGVkIG1lc3NhZ2UgZ2V0dGluZyBy ZS1zZW50IGFuZCBpbmZlciBpdCB3YXMgYSBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBkb24ndCBkaXNhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkaWZmZXJlbnQgZ3VhcmFudGVlcyB5 b3UgbmVlZCwgYnV0IGxpa2UgSSBzYWlkLCBJIHRoaW5rIHRoZSBpZGVhIGhlcmUgaXMgdG8gYmUg Y29uc2VydmF0aXZlIGJ5IGRlZmF1bHQuJm5ic3A7IFRoZXJlIGFyZSBzeXN0ZW1zIGluIHdoaWNo IHlvdSBjYW4gaGlkZQ0KIHRoZSBtZXRhZGF0YSB5b3UncmUgdGFsa2luZyBhYm91dCB3aXRoIHRo aW5ncyBsaWtlIG1peG5ldHMgYW5kIGRyb3Bib3hlcy4mbmJzcDsgS2VlcGluZyB0aGUgY2lwaGVy dGV4dCBhcyBvcGFxdWUgYXMgcG9zc2libGUga2VlcHMgdGhlIGRvb3Igb3BlbiB0byBydW5uaW5n IE1MUyBvdmVyIHRob3NlIHN5c3RlbXMgd2l0aG91dCBNTFMncyBvd24gbWV0YWRhdGEgdW5kZXJt aW5pbmcgdGhlaXIgcHJpdmFjeSBwcm9wZXJ0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RldJVywgaW4gdGhlIHN5c3RlbXMgSSdt IGxvb2tpbmcgYXQgYnVpbGRpbmcsIHRoaXMgUFIgZG9lcyBub3QgbWFrZSBhbnkgZGlmZmVyZW5j ZSwgYmVjYXVzZSBjbGllbnRzIHVzZSBzZXBhcmF0ZSBjaGFubmVscyBmb3IgUHJvcG9zYWxzL0Nv bW1pdHMgdnMuIGFwcGxpY2F0aW9uIGRhdGEgYW5kIHRoZSBzZXJ2ZXINCiBkb2Vzbid0IGNoZWNr LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LS1SaWNoYXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6Y3VycmVu dGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgcmdiKDIwNCwyMDQsMjA0KSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgSnVsIDEzLCAyMDIwIGF0IDg6NTYgQU0gUmlj aGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0YXJnZXQ9Il9ibGFu ayI+cmxiQGlwdi5zeDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xv cjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciByZ2IoMjA0LDIwNCwyMDQp Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBhbGwsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWNhbGwg dGhhdCBQUiMzNDkgZG9lcyB0d28gdGhpbmdzICgxKSB1c2UgYW4gb3BhcXVlIGVwb2NoIElELCBh bmQgKDIpIGVuY3J5cHQgdGhlIGNvbnRlbnQgdHlwZSBvZiB0aGUgbWVzc2FnZSAoYXBwbGljYXRp b24gLyBwcm9wb3NhbCAvIGNvbW1pdCkgWzFdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBv biB0aGUgY2FsbCBsYXN0IHdlZWsgdGhhdCBlbmNyeXB0aW5nIHRoZSBjb250ZW50IHR5cGUgbWln aHQgbm90IGJlIHRoYXQgdXNlZnVsLCBzaW5jZSBhbiBhcHBsaWNhdGlvbiB0aGF0IHJlbGllcyBv biBhIHNlcnZlciB0byBhc3N1cmUgb3JkZXJpbmcgb2YgY29tbWl0cw0KIHdpbGwgbmVlZCB0byBh dCBsZWFzdCBiZSBhYmxlIHRvIHRlbGwgY29tbWl0cyBmcm9tIG90aGVyIHRoaW5ncy4mbmJzcDsg T2YgY291cnNlLCBldmVuIGlmIHRoZSBjb250ZW50IHR5cGUgaXMgZW5jcnlwdGVkIGJ5IGRlZmF1 bHQsIHRoZSBhcHBsaWNhdGlvbiBjYW4gYWRkIGl0IGJhY2sgaW4gYXV0aGVudGljYXRlZCBkYXRh LCBvciBpbiBzb21lIHVuYXV0aGVudGljYXRlZCB3cmFwcGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmV0IG9mIHRob3NlIGNvbnNp ZGVyYXRpb25zLCBJJ20gcGVyc29uYWxseSBzdGlsbCBpbmNsaW5lZCB0byBtZXJnZSB0aGUgUFIs IHRvIGhhdmUgYSBjb25zZXJ2YXRpdmUgYmFzZWxpbmUuJm5ic3A7IEJ1dCB0aG9zZSBvbiB0aGUg Y2FsbCB0aG91Z2h0IGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwb3NlIHRoaXMgdG8gdGhlDQogZ3Jv dXAsIHNvIHBsZWFzZSBzcGVhayB1cCBpZiB5b3UgaGF2ZSBjb25jZXJucy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tUmljaGFyZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ WzFdDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbWxzd2cvbWxzLXByb3RvY29sL3B1bGwv MzQ5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL21sc3dnL21scy1wcm90b2Nv bC9wdWxsLzM0OTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KTUxTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpNTFNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5NTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHMiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk1MUyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+TUxTQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B72B8E66D973460A952027D8AC30E4FAnpsedu_-- From nobody Tue Jul 28 04:49:54 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 F19DB3A0B83 for ; Tue, 28 Jul 2020 04:49:51 -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 tLJrSx5ZzvPj for ; Tue, 28 Jul 2020 04:49:48 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 2296C3A0B76 for ; Tue, 28 Jul 2020 04:49:47 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id u64so18234900qka.12 for ; Tue, 28 Jul 2020 04:49:47 -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=VpHkGr6GnwLvklisVYhywGYp6nM4ZyzRJSHfgx1wRPc=; b=LzF0W7YZiXPjxf3YuZlRwEDa1ta6jjb64QwQ1/HoxomzOcjbv2c3LB8Q12AY2wwLk1 pIVHUKmMhhAaS1MQEc+gVkq/cWBGmb3Jrvl2lDO8VrIkxlaylDBF6fDM7ZO5JGgDG3HJ +DIUYUazpc7Uf3u2lKyj45YS64O6UPfi3Li9hyM9PuBZ+Unhh6LtvUC+Y7/KYqmtJPxD EWIP3yGlSvGJNwVngHJuIUd0FEMlaUUZYh17L7iPKshe9ypgaXKiQbus/VnL81qf+tyg vcgnC0R+e8IIGC/wbSZt6/Fi+z6w3jqjAgBYps/qsXUwLTLAMry3TywjJiVwOJmuLItO 5b9w== 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=VpHkGr6GnwLvklisVYhywGYp6nM4ZyzRJSHfgx1wRPc=; b=MVXShdxq3FLR3cUwKLzp+AskPbW+RwwJLJ5ZRsTI+1Du/Vi6FOnBHvTqphirfcRFPf HT2wcmlEacD7fW9b0pg/lvPZs4f8vkc+vg6FJldAL9SCySprJQO3VesjiVeajfaTgefP uMkCVXHb4q/nuYdtLZGnWK7wcP6/gM8OqiHcEMJIhMHO/eFP3x/NuisunN1k2NqeK7mF U32Q4xgbHzk3lvMc90/AJW14iq9RYceUWA6EPhN7DXuRCb3g/g+wxmj/HWNOkMJK0efN lYDywGD69mWLxLBgQbq0lKm+SVRAYmO1q7k2ezuMm6SeyPlzIF3I3CGhPwiWtBHXKzvk Eu1A== X-Gm-Message-State: AOAM531BlsBw3tb54+JqoQ6eMZNuNdGg7EDYFpGemMjSivw6LUnBl2Y6 EFlWlK5iOnZuGuFP3rC7PM5qeXrndV0gzvo3cIdl4w== X-Google-Smtp-Source: ABdhPJwKgCMiOiL0a2r/uY92i+onV8tCp9r7kfbYHgdw/HDZT4xU/1oj/m8HyMeiMxScvVEyCRQAL3NhJ6hNVxKlpkg= X-Received: by 2002:a05:620a:125b:: with SMTP id a27mr28133281qkl.371.1595936986670; Tue, 28 Jul 2020 04:49:46 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: From: Richard Barnes Date: Tue, 28 Jul 2020 07:49:17 -0400 Message-ID: To: "Hale, Britta (CIV)" Cc: Chelsea Komlo , "mls@ietf.org" , "brendan=40cloudflare.com@dmarc.ietf.org" Content-Type: multipart/alternative; boundary="0000000000002cc08005ab7f09c7" Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 11:49:52 -0000 --0000000000002cc08005ab7f09c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inline... On Tue, Jul 28, 2020 at 1:16 AM Hale, Britta (CIV) wrote: > Privacy-by-default is a goal that I think most on the mailinglist can > agree with (at least there have not been objections about that so far). I= t > is **how** it is achieved that is the issue. > > > > A the moment, one method has been presented and strongly argued for, but > there does not seem to be a good backing case for that approach. > Alternatively, there could be other ways of achieving privacy and content > hiding and alleviating some of the various types of concerns that have be= en > raised from different corners. > > > > - For example, it was proposed on the mailing list on 14 July that we > could consider a longer field to avoid collisions. > To be clear, I am fine with this. What is your preferred size? Would something like 16 bytes work? > - Also, there does not seem to be a firm reason for deriving the epoch I= D > as proposed. If the hash was instead over only the (current version) > group/epoch ID, then there would be no variable input and the epoch ID > would be predictable by all members of the group (but not those outside). > That would allay some of the forking concerns. A compromise might be foun= d > on what inputs to use, so that the epoch ID remains predictable only to > group members following an add/removal. > This seems worse to me. Basically, you're saying that the group members can brute-force the epoch IDs when necessary -- but that also means that the DS can brute force them. You seem to be presuming that there's a need for clients to be able to recognize which epoch IDs belong to which groups -- even for epochs where they are not a member. That seems of limited utility, since the client can't do anything with the message other than recognize its existence. Can you elaborate why this property seems desirable? The proposal in the PR provides the more limited property that clients can recognize epoch IDs for epochs they are members of, which is pretty clearly required for the protocol to work. > - Finally, (if we really want to expand on possibilities) if the epoch I= D > was taken as an encryption of the current group/epoch ID instead of a has= h, > then it could be uniquely reconcilable when required. The group/epoch ID > length is already accounted for in the current spec, so compression with = a > hash is not really a bonus factor. > I agree that this is not a great option, not least because it's not clear what key you would use. It is also premised on the idea of epoch IDs being intelligible by non-members, which seems problematic as above. --Richard > > > Just to be clear, I do not think that the third point above is really a > good option. However, it does highlight that there are other options to > meet the end goal of content hiding. The other two points ought to be > considered. > > > > The =E2=80=9Cpositive use case=E2=80=9D described thus far is an argument= for the end goal > of content hiding, but is not an argument for content hiding in the > particular way that has been proposed. Having a positive use case to > support the precise proposed change would be helpful. > > > > Ultimately, I would like to see arguments for/against the various other > ways of achieving content hiding, such as those listed above (or others). > This applies to both the concerns about resistance to collisions as well = as > the general aim of privacy. It is by no means an absolute fact that we ca= n > support only one or the other, so there may be a solution that addresses > all concerns discussed so far. It is definitely worthwhile to try for tha= t. > > > > > > Britta > > > > > > *From: *Chelsea Komlo > *Date: *Monday, July 27, 2020 at 9:01 PM > *To: *"mls@ietf.org" > *Cc: *"Hale, Britta (CIV)" , "rlb@ipv.sx" , > "brendan=3D40cloudflare.com@dmarc.ietf.org" 40cloudflare.com@dmarc.ietf.org> > *Subject: *Re: [MLS] Hiding content type > > > > I would like to affirm the positive use case Richard described, and say > that minimizing metadata where possible is valuable and leaves open the > possibility of using MLS in less-trusted settings. There are messaging > applications currently being developed in practice [1] that provide > metadata resistance (and hopefully more will follow this trend in the > future). It would be good to keep the door open to the use of MLS in thes= e > settings. > > > > As I am just now reading over the latest draft, I don't have much to add > at this moment as to how to derive these fields implicitly, but I am happ= y > to take a closer look and provide recommendations if the group doesn't co= me > to consensus in the meeting this week. > > > > [1] https://openprivacy.ca/work/cwtch/ > > > > On Sat, Jul 25, 2020 at 4:10 PM Brendan McMillion 40cloudflare.com@dmarc.ietf.org> wrote: > > I=E2=80=99m concerned about adversarial collisions, that'd cause a partia= l DoS > like you say. There are other ways to cause partial DoS in an MLS group, > but I think it=E2=80=99s good to minimize the avenues for attack. > > > > In your example, it sounds like you=E2=80=99re trying to achieve unlinkab= ility > between messages, with a Generic Commit Sequencing Service which is > basically a KV store that only accepts one write per key. So in this > scenario, I think you would be much better off by simply truncating the > group ID and epoch from MLSCiphertext (making them implicit), and choosin= g > the key that each message is stored under with some function of: 1.) a > group secret, and 2.) a message counter. > > > > Would that work? > > > > On Jul 25, 2020, at 12:38 PM, Richard Barnes wrote: > > > > Just so we're clear, in your example, are you concerned about accidental > or adversarial collisions? I hope we agree that we can fix the accidenta= l > case just by making a longer epoch ID. In the adversarial case, this see= ms > like a partial DoS at worst, since the members who incorrectly think they > are in the previous epoch will no longer be decrypting with the right key= s. > > > > As far as a positive example: Imagine a Generic Commit Sequencing Service > that provides a reliable broadcast/ledger over anonymous channels (e.g., = as > an onion service), but will only broadcast/record one message for each > groupID/epoch. If the groupID/epoch is opaque, then such a service can b= e > provided without learning anything about the groups it serves or their > evolution. > > > > > > On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion > wrote: > > Take for example, a broadcast channel that's ordered but lossy. A Commit > gets sent where the new epoch id collides with the previous epoch id, but > not all members get the Commit. So now the group is fractured and there's > no way for members in the previous epoch to know that they missed a > message. What the application developer needs to do to detect lost > messages, is immediately re-implement the counter epoch id that you've ju= st > removed. > > > > That's an example of a system where this change is pointless / harmful. I= f > you could provide an example of a system where the change is *helpful*, > that would be more interesting. > > > > On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: > > I'm honestly really confused by the worry about collisions here. The > current epoch ID collides trivially -- it's just a counter! And the grou= p > ID is assumed to be public anyway. So if your authentication scheme is > broken when you have a (group ID, epoch ID) collision, then your scheme i= s > already broken. > > > > If we're going to block this change on this basis, then we need to see > clearly articulated an authentication scheme that is secure in the curren= t > model, but broken in the case where epoch IDs are derived off of the key > schedule. > > --Richard > > > > On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) > wrote: > > Ensuring the most conservative design by default seems advisable; however > it is not clear that this proposal for hiding content type is actually > doing that. Indeed, if an application is concerned about hiding the conte= nt > type, would not that same type of application also be concerned about > collisions? > > > > As Brendan notes, we are not talking about accidental collisions here. > Pre-computation is entirely possible, such as by a malicious group member= , > so the window of attack is not limited to one epoch. > > > > If this is this PR particular is of particular interest to some, then it > would be good to see a clarifying explanation as to the security it > achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite i= ntroducing such > collision possibilities), or a concrete use-case. Alternatively, are we > really limited to a 64-bit field, or can that length be adjusted to > mitigate the introduced problems? > > > > > > > > A clarifying point for those following this thread: some references in th= e > email chain state that this is encryption of the epoch ID. That is not th= e > case. The proposal being discussed is about a hash thereof (hence > discussion on collisions). > > > > Britta > > > > > > *From: *MLS on behalf of Brendan McMillion > > *Date: *Monday, July 13, 2020 at 9:37 AM > *To: *Richard Barnes > *Cc: *Messaging Layer Security WG > *Subject: *Re: [MLS] Hiding content type > > > > As far as collision resistance, I'm not too worried about collisions amon= g > 64-bit random values, especially as the scope for collision is fairly > small, arguably just one epoch. > > > > The issue isn't with accidental collisions, it's with malicious ones. An > attacker can purposefully (and quickly) generate commits that create > duplicate epoch ids, and send them to a client to corrupt their group sta= te. > > > > I think the idea here is to be conservative by default. There are system= s > in which you can hide the metadata you're talking about with things like > mixnets and dropboxes. > > > > It's not just being more conservative, you're making changes specifically > for very niche use-cases where I don't think the security of the whole > system has been thought through. Maybe you have an example in mind, but I > can't think of a system where this change provides any additional privacy= . > > > > On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: > > On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion > wrote: > > With respect to using an opaque epoch id, I believe this was proposed in > #245 and consensus was > against it because it makes it more difficult to implement the DS. It's > also not clear to me what security properties you want from an opaque epo= ch > id, because the current PR doesn't provide collision resistance and I'd > expect this to be a source of confusion and bugs. > > > > I think the discussion on #245 got derailed a bit by the focus on > non-linear epochs. The point here is that even in a case where you have > linear history, I think there's intrinsic value in the epoch ID being > opaque because it gives intermediaries less opportunity for ossification. > > > > As far as collision resistance, I'm not too worried about collisions amon= g > 64-bit random values, especially as the scope for collision is fairly > small, arguably just one epoch. > > > > > > With respect to encrypting the content type, it also seems to me that thi= s > would cause issues because different content types have different deliver= y > guarantees. Specifically: messages are allowed to be unordered and lossy, > proposals are allowed to be unordered but not lossy, and commits are both > ordered and not lossy. In the deployment scenarios we've talked about, th= e > DS essentially always needs to know the content type to provide this. > Conversely, you don't get much additional privacy from encrypting the > content type because an eavesdropper can see the epoch id change and infe= r > which message was a commit, or see a dropped message getting re-sent and > infer it was a proposal. > > > > I don't disagree that there are different guarantees you need, but like I > said, I think the idea here is to be conservative by default. There are > systems in which you can hide the metadata you're talking about with thin= gs > like mixnets and dropboxes. Keeping the ciphertext as opaque as possible > keeps the door open to running MLS over those systems without MLS's own > metadata undermining their privacy properties. > > > > FWIW, in the systems I'm looking at building, this PR does not make any > difference, because clients use separate channels for Proposals/Commits v= s. > application data and the server doesn't check. > > > > --Richard > > > > > > > > On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: > > Hi all, > > > > Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) > encrypt the content type of the message (application / proposal / commit) > [1]. > > > > There was some discussion on the call last week that encrypting the > content type might not be that useful, since an application that relies o= n > a server to assure ordering of commits will need to at least be able to > tell commits from other things. Of course, even if the content type is > encrypted by default, the application can add it back in authenticated > data, or in some unauthenticated wrapper. > > > > Net of those considerations, I'm personally still inclined to merge the > PR, to have a conservative baseline. But those on the call thought it > would be useful to pose this to the group, so please speak up if you have > concerns. > > > > --Richard > > > > [1] https://github.com/mlswg/mls-protocol/pull/349 > > _______________________________________________ > 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 > > > > > > --0000000000002cc08005ab7f09c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline...

On Tue, Jul 28, 2020 at 1:16 AM Hale, Br= itta (CIV) <britta.hale@nps.edu> wrote:

Privacy-by-default is a goal that I think most on th= e mailinglist can agree with (at least there have not been objections about= that so far). It is *how* it is achieved that is the issue.

=C2=A0

A the moment, one method has been presented and stro= ngly argued for, but there does not seem to be a good backing case for that= approach. Alternatively, there could be other ways of achieving privacy an= d content hiding and alleviating some of the various types of concerns that have been raised from different corn= ers.

=C2=A0

-=C2=A0 For example, it was proposed on the mailing = list on 14 July that we could consider a longer field to avoid collisions.







=C2=A0

Just to be clear, I do not think that the third poin= t above is really a good option. However, it does highlight that there are = other options to meet the end goal of content hiding. The other two points = ought to be considered.

=C2=A0

The =E2=80=9Cpositive use case=E2=80=9D described th= us far is an argument for the end goal of content hiding, but is not an arg= ument for content hiding in the particular way that has been proposed. Havi= ng a positive use case to support the precise proposed change would be helpful.

=C2=A0

Ultimately, I would like to see arguments for/agains= t the various other ways of achieving content hiding, such as those listed = above (or others). This applies to both the concerns about resistance to co= llisions as well as the general aim of privacy. It is by no means an absolute fact that we can support only on= e or the other, so there may be a solution that addresses all concerns disc= ussed so far. It is definitely worthwhile to try for that.

=C2=A0

=C2=A0

Britta

=C2=A0

=C2=A0

From: = Chelsea Komlo <chelsea.komlo@gma= il.com>
Date: Monday, July 27, 2020 at 9:01 PM
To: "mls@ietf= .org" <mls@ie= tf.org>
Cc: "Hale, Britta (CIV)" <britta.hale@nps.edu>, "rlb@ipv.sx&q= uot; <rlb@ipv.sx>, "brendan=3D40cloudflare.com@dmarc.ietf.org"= ; <brendan=3D40cloudflare.com@dmarc.ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

I would like to affirm the positive use case Richard= described, and say that minimizing metadata where possible is valuable and= leaves open the possibility of using MLS in less-trusted settings. There a= re messaging applications currently being developed in practice [1] that provide metadata resistance=C2=A0(and= hopefully more will follow this trend in the future).=C2=A0It would be goo= d to keep the door open to the use of MLS in these settings.

=C2=A0

As I am just now reading over the latest draft, I do= n't have much to add at this moment as to how to derive these fields im= plicitly, but I am happy to take a closer=C2=A0look and provide recommendat= ions if the group doesn't come to=C2=A0consensus in the meeting this=C2=A0week.=C2=A0

=C2=A0

=C2=A0

On Sat, Jul 25, 2020 at 4:10 PM Brendan McMillion &l= t;brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:

I=E2=80=99m concerned about adversarial collisions, = that'd cause a partial DoS like you say. There are other ways to cause = partial DoS in an MLS group, but I think it=E2=80=99s good to minimize the = avenues for attack.

=C2=A0

In your example, it sounds like you=E2=80=99re tryin= g to achieve unlinkability between messages, with a Generic Commit Sequenci= ng Service which is basically a KV store that only accepts one write per ke= y. So in this scenario, I think you would be much better off by simply truncating the group ID and epoch from MLSCip= hertext (making them implicit), and choosing the key that each message is s= tored under with some function of: 1.) a group secret, and 2.) a message co= unter.

=C2=A0

Would that work?



On Jul 25, 2020, at 12:38 PM, Richard Barnes <rlb@ipv.sx> wrote:

=C2=A0

Just so we're clear, in your example, are you co= ncerned about accidental or adversarial collisions?=C2=A0 I hope we agree t= hat we can fix the accidental case just by making a longer epoch ID.=C2=A0 = In the adversarial case, this seems like a partial DoS at worst, since the members who incorrectly think they are in the prev= ious epoch will no longer be decrypting with the right keys.<= /p>

=C2=A0

As far as a positive example: Imagine a Generic Comm= it Sequencing Service that provides a reliable broadcast/ledger over anonym= ous channels (e.g., as an onion service), but will only broadcast/record on= e message for each groupID/epoch.=C2=A0 If the groupID/epoch is opaque, then such a service can be provided withou= t learning anything about the groups it serves or their evolution.

=C2=A0

=C2=A0

On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion &l= t;brendan@cloud= flare.com> wrote:

Take for example, a broadcast channel that's ord= ered but lossy. A Commit gets sent where the new epoch id collides with the= previous epoch id, but not all members get the Commit. So now the group is= fractured and there's no way for members in the previous epoch to know that they missed a message. What the applica= tion developer needs to do to detect lost messages, is immediately re-imple= ment the counter epoch id that you've just removed.

=C2=A0

That's an example of a system where this change = is pointless / harmful. If you could provide an example of a system where t= he change is *helpful*, that would be more interesting.

=C2=A0

On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <= rlb@ipv.sx> wrote:

I'm honestly really confused by the worry about = collisions here.=C2=A0 The current epoch ID collides trivially -- it's = just a counter!=C2=A0 And the group ID is assumed to be public anyway.=C2= =A0 So if your authentication scheme is broken when you have a (group ID, epoch ID) collision, then your scheme is already broken.

=C2=A0

If we're going to b= lock this change on this basis, then we need to see clearly articulated an = authentication scheme that is secure in the current model, but broken in th= e case where epoch IDs are derived off of the key schedule.

--Richard

=C2=A0

On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) = <britta.hale@np= s.edu> wrote:

Ensuring the most conservative design by default see= ms advisable; however it is not clear that this proposal for hiding content= type is actually doing that. Indeed, if an application is concerned about hiding the content type, would not that same type of ap= plication also be concerned about collisions?

=C2=A0

As Brendan notes, we are not talking about accidenta= l collisions here. Pre-computation is entirely possible, such as by a malic= ious group member, so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular inter= est to some, then it would be good to see a clarifying explanation as to th= e security it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despite introducing such collision possibilities), or a= concrete use-case. Alternatively, are we really limited to a 64-bit field,= or can that length be adjusted to mitigate the introduced problems?=

=C2=A0

=C2=A0

=C2=A0

A clarifying point for those following this thread: = some references in the email chain state that this is encryption of the epo= ch ID. That is not the case. The proposal being discussed is about a hash thereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0

=C2=A0

From: MLS <mls-bounces@ietf.org> on behalf of = Brendan McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions, it&#= 39;s with malicious ones. An attacker can purposefully (and quickly) genera= te commits that create duplicate epoch ids, and send them to a client to corrupt their group state.

=C2=A0

I think the idea here is to be conservative by defau= lt.=C2=A0 There are systems in which you can hide the metadata you're t= alking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you'r= e making changes specifically for very niche use-cases where I don't th= ink the security of the whole system has been thought through. Maybe you have an example in mind, but I can't think of a system where= this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <= rlb@ipv.sx> wrote:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion &= lt;brendan@clou= dflare.com> wrote:

With respect to using an opaque epoch id, I believe = this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a bit by= the focus on non-linear epochs.=C2=A0 The point here is that even in a cas= e where you have linear history, I think there's intrinsic value in the epoch ID being opaque because it gives intermediaries less op= portunity for ossification.

=C2=A0

As far as collision resistance, I'm not too worr= ied about collisions among 64-bit random values, especially as the scope fo= r collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it also= seems to me that this would cause issues because different content types h= ave different delivery guarantees. Specifically: messages are allowed to be unordered and lossy, proposals are allowed to be unorder= ed but not lossy, and commits are both ordered and not lossy. In the deploy= ment scenarios we've talked about, the DS essentially always needs to k= now the content type to provide this. Conversely, you don't get much additional privacy from encrypting the = content type because an eavesdropper can see the epoch id change and infer = which message was a commit, or see a dropped message getting re-sent and in= fer it was a proposal.

=C2=A0

I don't disagree that there are different guaran= tees you need, but like I said, I think the idea here is to be conservative= by default.=C2=A0 There are systems in which you can hide the metadata you're talking about with things like mixnets and dropbox= es.=C2=A0 Keeping the ciphertext as opaque as possible keeps the door open = to running MLS over those systems without MLS's own metadata underminin= g their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at building, th= is PR does not make any difference, because clients use separate channels f= or Proposals/Commits vs. application data and the server doesn't check.

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wrote:=

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an opaque= epoch ID, and (2) encrypt the content type of the message (application / p= roposal / commit) [1].

=C2=A0

There was some discussion on the call last week that= encrypting the content type might not be that useful, since an application= that relies on a server to assure ordering of commits will need to at least be able to tell commits from other things.=C2=A0 Of = course, even if the content type is encrypted by default, the application c= an add it back in authenticated data, or in some unauthenticated wrapper.

=C2=A0

Net of those considerations, I'm personally stil= l inclined to merge the PR, to have a conservative baseline.=C2=A0 But thos= e on the call thought it would be useful to pose this to the group, so please speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

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

=C2=A0

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


=C2=A0

=C2=A0

--0000000000002cc08005ab7f09c7-- From nobody Tue Jul 28 05:35:49 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 9204A3A0BE6 for ; Tue, 28 Jul 2020 05:35:46 -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 Sqez482mEF2w for ; Tue, 28 Jul 2020 05:35:43 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 F0ED93A0BB9 for ; Tue, 28 Jul 2020 05:35:42 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id o2so8988539qvk.6 for ; Tue, 28 Jul 2020 05:35:42 -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=nL78vY8WcaVlEjFK8kdh3YuRaQjc+zGyGNeYisb40YE=; b=UFjZ1HUyKk9wfMk2IjMARgxDMSQrTOH9tIzxO7JJ4BL5iqXLOeCMEJ/2PPeLdx95cP KWKvJzeM7YGDUwYRQqfNqidYg8DOqamGf4nsii3cZBiEEQRbvA7xkg2DdxjirlhP7Oyc 4ek0LZ+SCHxlvomcL7sKXTPwaXXPHjhFhwsxsDXMKHqRpH+oRuJ65b9tlQA3PdiFyqkk z26XGn1bjR72r60YHPhpIB2KY1E9eAATmxuqpcyO9CtVjbPFRJzAboxnya5ztGcG5dZ9 UXl20IgzmBq3OQQ5BmfwwHFRBUSfPaqoXK12Wq10/AfrJGuGonDCjC0bkN/wRa6Jz/La utKw== 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=nL78vY8WcaVlEjFK8kdh3YuRaQjc+zGyGNeYisb40YE=; b=WVY5vcdTHm3nlLjWfJZWKNw1+zfME+WU7HBW9XQa/8bWE27I2pcBMP3bEbgw8eR3f8 dUfABdm/C+zU1VYoFDosQOTc1HnA+VIn550Q5PN3cZ0oVIi5u/yYKEIJie0JTOOOTJMb eyFMJ28Zk9QrYQwn5jfh9nWw3xUAA0ymnd7M4GOALBFn4LZuZRL2JyqnYgqvjJRoY8FS p+kySZgD46WQUYo73NSSZuN7zZ5V0aJMDPQO45zXWZ9VLiv4/IavQS0LscLJmErytzha +yXsxi1PajXdzc5CY6dqHD9CpO7eKnH6UgHf6z8U6pEO8tEELG3QTIFy8JiGrudrSUQN WKQw== X-Gm-Message-State: AOAM531n852RkTBFLCIt+nps3gqrrk6lVJRGllgHLt4Ei7Rxg0zYkd9h lfloNV/nNNIM6DlEU20gB1mW04Xze03kpz9wUviiKw== X-Google-Smtp-Source: ABdhPJyGqIpAnJ6yGXFNXdJIiLTk9rioBzGkA2XYWckAueLHY5I3uGkVEH2F/vrt4oZUjq7ha9F/EScFmBemjqW6ygc= X-Received: by 2002:ad4:44f2:: with SMTP id p18mr5427191qvt.137.1595939741732; Tue, 28 Jul 2020 05:35:41 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> From: Richard Barnes Date: Tue, 28 Jul 2020 08:35:12 -0400 Message-ID: To: Brendan McMillion Cc: "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000063a98c05ab7fad29" Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 12:35:47 -0000 --00000000000063a98c05ab7fad29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 25, 2020 at 6:10 PM Brendan McMillion wrote: > I=E2=80=99m concerned about adversarial collisions, that'd cause a partia= l DoS > like you say. There are other ways to cause partial DoS in an MLS group, > but I think it=E2=80=99s good to minimize the avenues for attack. > I wonder if this could in part be addressed just by using a longer identifier to make finding adversarial collisions impractical. > In your example, it sounds like you=E2=80=99re trying to achieve unlinkab= ility > between messages, with a Generic Commit Sequencing Service which is > basically a KV store that only accepts one write per key. So in this > scenario, I think you would be much better off by simply truncating the > group ID and epoch from MLSCiphertext (making them implicit), and choosin= g > the key that each message is stored under with some function of: 1.) a > group secret, and 2.) a message counter. > > Would that work? > Interesting, but I don't think so. I'm concerned about forcing applications to invent too much here. It seems like from what we know now, some applications are going to need to identify the group ID / epoch in the message, and in some applications, the group ID / epoch is going to be clear from context. That latter class of application would probably be OK with an implicit GroupID / Epoch. But in the former class, you would be forcing the application to invent its own scheme for signaling this stuff, which risks them making decisions that are suboptimal for metadata privacy. So my preference would still be to provide an identifier that offers the minimal properties required to make the protocol work. But I would be happy to acknowledge that applications can leak more metadata if they need to, and that metadata can be ultimately authenticated by the protocol. In fact, we could make this explicit by making the AAD for the ciphertext encryption include the GroupID and Epoch counter in addition to the opaque epoch. What would folks think about the following proposal: 1. MLSCiphertext includes an opaque EpochID 2. ... with a length that makes finding collisions infeasible (16 bytes? 32 bytes? KDF.Nh bytes?) 3. We add some explicit text noting that additional metadata can be added by the application 4. ... and update the AAD for the sender data and content encryptions to use all three values (group ID, epoch counter, epoch ID) --Richard > On Jul 25, 2020, at 12:38 PM, Richard Barnes wrote: > > Just so we're clear, in your example, are you concerned about accidental > or adversarial collisions? I hope we agree that we can fix the accidenta= l > case just by making a longer epoch ID. In the adversarial case, this see= ms > like a partial DoS at worst, since the members who incorrectly think they > are in the previous epoch will no longer be decrypting with the right key= s. > > As far as a positive example: Imagine a Generic Commit Sequencing Service > that provides a reliable broadcast/ledger over anonymous channels (e.g., = as > an onion service), but will only broadcast/record one message for each > groupID/epoch. If the groupID/epoch is opaque, then such a service can b= e > provided without learning anything about the groups it serves or their > evolution. > > > On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion > wrote: > >> Take for example, a broadcast channel that's ordered but lossy. A Commit >> gets sent where the new epoch id collides with the previous epoch id, bu= t >> not all members get the Commit. So now the group is fractured and there'= s >> no way for members in the previous epoch to know that they missed a >> message. What the application developer needs to do to detect lost >> messages, is immediately re-implement the counter epoch id that you've j= ust >> removed. >> >> That's an example of a system where this change is pointless / harmful. >> If you could provide an example of a system where the change is *helpful= *, >> that would be more interesting. >> >> On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: >> >>> I'm honestly really confused by the worry about collisions here. The >>> current epoch ID collides trivially -- it's just a counter! And the gr= oup >>> ID is assumed to be public anyway. So if your authentication scheme is >>> broken when you have a (group ID, epoch ID) collision, then your scheme= is >>> already broken. >>> >>> If we're going to block this change on this basis, then we need to see >>> clearly articulated an authentication scheme that is secure in the curr= ent >>> model, but broken in the case where epoch IDs are derived off of the ke= y >>> schedule. >>> >>> --Richard >>> >>> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) >>> wrote: >>> >>>> Ensuring the most conservative design by default seems advisable; >>>> however it is not clear that this proposal for hiding content type is >>>> actually doing that. Indeed, if an application is concerned about hidi= ng >>>> the content type, would not that same type of application also be conc= erned >>>> about collisions? >>>> >>>> >>>> >>>> As Brendan notes, we are not talking about accidental collisions here. >>>> Pre-computation is entirely possible, such as by a malicious group mem= ber, >>>> so the window of attack is not limited to one epoch. >>>> >>>> >>>> >>>> If this is this PR particular is of particular interest to some, then >>>> it would be good to see a clarifying explanation as to the security it >>>> achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despit= e introducing such >>>> collision possibilities), or a concrete use-case. Alternatively, are w= e >>>> really limited to a 64-bit field, or can that length be adjusted to >>>> mitigate the introduced problems? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> A clarifying point for those following this thread: some references in >>>> the email chain state that this is encryption of the epoch ID. That is= not >>>> the case. The proposal being discussed is about a hash thereof (hence >>>> discussion on collisions). >>>> >>>> >>>> >>>> Britta >>>> >>>> >>>> >>>> >>>> >>>> *From: *MLS on behalf of Brendan McMillion >>>> >>>> *Date: *Monday, July 13, 2020 at 9:37 AM >>>> *To: *Richard Barnes >>>> *Cc: *Messaging Layer Security WG >>>> *Subject: *Re: [MLS] Hiding content type >>>> >>>> >>>> >>>> As far as collision resistance, I'm not too worried about collisions >>>> among 64-bit random values, especially as the scope for collision is f= airly >>>> small, arguably just one epoch. >>>> >>>> >>>> >>>> The issue isn't with accidental collisions, it's with malicious ones. >>>> An attacker can purposefully (and quickly) generate commits that creat= e >>>> duplicate epoch ids, and send them to a client to corrupt their group = state. >>>> >>>> >>>> >>>> I think the idea here is to be conservative by default. There are >>>> systems in which you can hide the metadata you're talking about with t= hings >>>> like mixnets and dropboxes. >>>> >>>> >>>> >>>> It's not just being more conservative, you're making changes >>>> specifically for very niche use-cases where I don't think the security= of >>>> the whole system has been thought through. Maybe you have an example i= n >>>> mind, but I can't think of a system where this change provides any >>>> additional privacy. >>>> >>>> >>>> >>>> On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: >>>> >>>> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion < >>>> brendan@cloudflare.com> wrote: >>>> >>>> With respect to using an opaque epoch id, I believe this was proposed >>>> in #245 and consensus >>>> was against it because it makes it more difficult to implement the DS.= It's >>>> also not clear to me what security properties you want from an opaque = epoch >>>> id, because the current PR doesn't provide collision resistance and I'= d >>>> expect this to be a source of confusion and bugs. >>>> >>>> >>>> >>>> I think the discussion on #245 got derailed a bit by the focus on >>>> non-linear epochs. The point here is that even in a case where you ha= ve >>>> linear history, I think there's intrinsic value in the epoch ID being >>>> opaque because it gives intermediaries less opportunity for ossificati= on. >>>> >>>> >>>> >>>> As far as collision resistance, I'm not too worried about collisions >>>> among 64-bit random values, especially as the scope for collision is f= airly >>>> small, arguably just one epoch. >>>> >>>> >>>> >>>> >>>> >>>> With respect to encrypting the content type, it also seems to me that >>>> this would cause issues because different content types have different >>>> delivery guarantees. Specifically: messages are allowed to be unordere= d and >>>> lossy, proposals are allowed to be unordered but not lossy, and commit= s are >>>> both ordered and not lossy. In the deployment scenarios we've talked a= bout, >>>> the DS essentially always needs to know the content type to provide th= is. >>>> Conversely, you don't get much additional privacy from encrypting the >>>> content type because an eavesdropper can see the epoch id change and i= nfer >>>> which message was a commit, or see a dropped message getting re-sent a= nd >>>> infer it was a proposal. >>>> >>>> >>>> >>>> I don't disagree that there are different guarantees you need, but lik= e >>>> I said, I think the idea here is to be conservative by default. There= are >>>> systems in which you can hide the metadata you're talking about with t= hings >>>> like mixnets and dropboxes. Keeping the ciphertext as opaque as possi= ble >>>> keeps the door open to running MLS over those systems without MLS's ow= n >>>> metadata undermining their privacy properties. >>>> >>>> >>>> >>>> FWIW, in the systems I'm looking at building, this PR does not make an= y >>>> difference, because clients use separate channels for Proposals/Commit= s vs. >>>> application data and the server doesn't check. >>>> >>>> >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >>>> >>>> Hi all, >>>> >>>> >>>> >>>> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) >>>> encrypt the content type of the message (application / proposal / comm= it) >>>> [1]. >>>> >>>> >>>> >>>> There was some discussion on the call last week that encrypting the >>>> content type might not be that useful, since an application that relie= s on >>>> a server to assure ordering of commits will need to at least be able t= o >>>> tell commits from other things. Of course, even if the content type i= s >>>> encrypted by default, the application can add it back in authenticated >>>> data, or in some unauthenticated wrapper. >>>> >>>> >>>> >>>> Net of those considerations, I'm personally still inclined to merge th= e >>>> PR, to have a conservative baseline. But those on the call thought it >>>> would be useful to pose this to the group, so please speak up if you h= ave >>>> concerns. >>>> >>>> >>>> >>>> --Richard >>>> >>>> >>>> >>>> [1] https://github.com/mlswg/mls-protocol/pull/349 >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>>> > --00000000000063a98c05ab7fad29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 25, 2020 at 6:10 PM Brendan M= cMillion <brendan@cloudflare.c= om> wrote:
I=E2= =80=99m concerned about adversarial collisions, that'd cause a partial = DoS like you say. There are other ways to cause partial DoS in an MLS group= , but I think it=E2=80=99s good to minimize the avenues for attack.

I wonder if this could in part be addressed = just by using a longer identifier to make finding adversarial collisions im= practical.
=C2=A0
In your example,= it sounds like you=E2=80=99re trying to achieve unlinkability between mess= ages, with a Generic Commit Sequencing Service which is basically a KV stor= e that only accepts one write per key. So in this scenario, I think you wou= ld be much better off by simply truncating the group ID and epoch from MLSC= iphertext (making them implicit), and choosing the key that each message is= stored under with some function of: 1.) a group secret, and 2.) a message = counter.

Would that work?

Interesting, but I don't think so.=C2=A0 I'= m concerned about forcing applications to invent too much here.=C2=A0 It se= ems like from what we know now, some applications are going to need to iden= tify the group ID / epoch in the message, and in some applications, the gro= up ID / epoch is going to be clear from context.=C2=A0 That latter class of= application would probably be OK with an implicit GroupID / Epoch.=C2=A0 B= ut in the former class, you would be forcing the application to invent its = own scheme for signaling this stuff, which risks them making decisions that= are suboptimal for metadata privacy.

So my pr= eference would still be to provide an identifier that offers the minimal pr= operties required to make the protocol work.=C2=A0 But I would be happy to = acknowledge that applications can leak more metadata if they need to, and t= hat metadata can be ultimately authenticated by the protocol.=C2=A0 In fact= , we could make this explicit by making the AAD for the ciphertext encrypti= on include the GroupID and Epoch counter in addition to the opaque epoch.

What would folks think about the following prop= osal:

1. MLSCiphertext includes an opaque EpochID =
2. ... with a length that makes finding collisions infeasibl= e (16 bytes?=C2=A0 32 bytes?=C2=A0 KDF.Nh bytes?)
3. We add s= ome explicit text noting that additional metadata can be added by the appli= cation
4. ... and update the AAD for the sender data and content = encryptions to use all three values (group ID, epoch counter, epoch ID)
=

--Richard

On Jul 2= 5, 2020, at 12:38 PM, Richard Barnes <rlb@ipv.sx> wrote:

Just so we're clear, in your example, are you concerned about accident= al or adversarial collisions?=C2=A0 I hope we agree that we can fix the acc= idental case just by making a longer epoch ID.=C2=A0 In the adversarial cas= e, this seems like a partial DoS at worst, since the members who incorrectl= y think they are in the previous epoch will no longer be decrypting with th= e right keys.

As far as a positive example: Im= agine a Generic Commit Sequencing Service that provides a reliable broadcas= t/ledger over anonymous channels (e.g., as an onion service), but will only= broadcast/record one message for each groupID/epoch.=C2=A0 If the groupID/= epoch is opaque, then such a service can be provided without learning anyth= ing about the groups it serves or their evolution.


On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion <brendan@cloudflare.com> wrot= e:
Take for example, a broadcast channel that's ordered but lossy= . A Commit gets sent where the new epoch id collides with the previous epoc= h id, but not all members get the Commit. So now the group is fractured and= there's no way for members in the previous epoch to know that they mis= sed a message. What the application developer needs to do to detect lost me= ssages, is immediately re-implement the counter epoch id that you've ju= st removed.

That's an example of a system wher= e this change is pointless / harmful. If you could provide an example of a = system where the change is *helpful*, that would be more interesting.

On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <rlb@ipv.sx> wrote:
I'm honest= ly really confused by the worry about collisions here.=C2=A0 The current ep= och ID collides trivially -- it's just a counter!=C2=A0 And the group I= D is assumed to be public anyway.=C2=A0 So if your authentication scheme is= broken when you have a (group ID, epoch ID) collision, then your scheme is= already broken.

If we're going to block this = change on this basis, then we need to see clearly articulated an authentica= tion scheme that is secure in the current model, but broken in the case whe= re epoch IDs are derived off of the key schedule.

--Richa= rd

On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <britta.hale@nps.edu&g= t; wrote:

Ensuring the most conservative design by defaul= t seems advisable; however it is not clear that this proposal for hiding co= ntent type is actually doing that. Indeed, if an application is concerned a= bout hiding the content type, would not that same type of application also be concerned about collisions? <= u>

=C2=A0

As Brendan notes, we are not talking about accidental collisions here.= Pre-computation is entirely possible, such as by a malicious group member,= so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular interest to s= ome, then it would be good to see a clarifying explanation as to the securi= ty it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despi= te introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit f= ield, or can that length be adjusted to mitigate the introduced problems?

=C2=A0

=C2=A0

=C2=A0<= /u>

A clarifying point for those following this t= hread: some references in the email chain state that this is encryption of = the epoch ID. That is not the case. The proposal being discussed is about a= hash thereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0=

=C2=A0

From: = MLS <mls-bounces@ietf.org> on behalf of Brendan McM= illion <brendan=3D40cloudflare.com@dmarc.ietf.org>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too= worried about collisions among 64-bit random values, especially as the sco= pe for collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions,= it's with malicious ones. An attacker can purposefully (and quickly) g= enerate commits that create duplicate epoch ids, and send them to a client = to corrupt their group state.

=C2=A0

I think the idea here is to be conservative by = default.=C2=A0 There are systems in which you can hide the metadata you'= ;re talking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you&= #39;re making changes specifically for very niche use-cases where I don'= ;t think the security of the whole system has been thought through. Maybe y= ou have an example in mind, but I can't think of a system where this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes= <rlb@ipv.sx> wro= te:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMill= ion <brendan= @cloudflare.com> wrote:

With respect to using an opaque epoch id, I bel= ieve this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a b= it by the focus on non-linear epochs.=C2=A0 The point here is that even in = a case where you have linear history, I think there's intrinsic value i= n the epoch ID being opaque because it gives intermediaries less opportunity for ossification.

=C2=A0

As far as collision resistance, I'm not too= worried about collisions among 64-bit random values, especially as the sco= pe for collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it= also seems to me that this would cause issues because different content ty= pes have different delivery guarantees. Specifically: messages are allowed = to be unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and no= t lossy. In the deployment scenarios we've talked about, the DS essenti= ally always needs to know the content type to provide this. Conversely, you= don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id c= hange and infer which message was a commit, or see a dropped message gettin= g re-sent and infer it was a proposal.

=C2=A0

I don't disagree that there are different g= uarantees you need, but like I said, I think the idea here is to be conserv= ative by default.=C2=A0 There are systems in which you can hide the metadat= a you're talking about with things like mixnets and dropboxes.=C2=A0 Keeping the ciphertext as opaque as possible keeps th= e door open to running MLS over those systems without MLS's own metadat= a undermining their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at buildin= g, this PR does not make any difference, because clients use separate chann= els for Proposals/Commits vs. application data and the server doesn't c= heck.

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes = <rlb@ipv.sx> wrot= e:

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an o= paque epoch ID, and (2) encrypt the content type of the message (applicatio= n / proposal / commit) [1].

=C2=A0

There was some discussion on the call last week= that encrypting the content type might not be that useful, since an applic= ation that relies on a server to assure ordering of commits will need to at= least be able to tell commits from other things.=C2=A0 Of course, even if the content type is encrypted by default,= the application can add it back in authenticated data, or in some unauthen= ticated wrapper.

=C2=A0

Net of those considerations, I'm personally= still inclined to merge the PR, to have a conservative baseline.=C2=A0 But= those on the call thought it would be useful to pose this to the group, so= please speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

______________________________________________= _
MLS mailing list
MLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mls


--00000000000063a98c05ab7fad29-- From nobody Tue Jul 28 07:11: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 2607C3A0CB2 for ; Tue, 28 Jul 2020 07:11:06 -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=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 gG1pXnc4SLup for ; Tue, 28 Jul 2020 07:11:01 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 86EF13A0CB1 for ; Tue, 28 Jul 2020 07:11:01 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id k18so14867598qtm.10 for ; Tue, 28 Jul 2020 07:11:01 -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=unq92KTyHqA6aFh4PzFHxGYCIlWHdrYmFWUklCVYZwE=; b=J76wNtyK3+G88FAnlWHyC9r1JCzzikksbbbofoj6f9sWUCPlQvThtp73XqXPZuPZNY Kw2Iftwhw4Y+8wwMZWjkUlZhOyXvj7o7e6xEJMzBoFionLar97pzqyjPSrKvRvc+I9M+ 2HsQE9XvCWkHEzvyc+yR3g5jBonnqXePHLKsQ= 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=unq92KTyHqA6aFh4PzFHxGYCIlWHdrYmFWUklCVYZwE=; b=mj0UGlhuKhA0xbGPY1nsMP2kq49UBc6zoab18LnC3uk9oWkY+ZRBywZaAkeL7sX83u GOStgi/KX2otsgTQ8J69uBhaljzHY5vykOsThjg475xpCve8LHBFwdkXbIQ3kqGMFkAi OnP3oSBs0ekaanZIP7RhML/OY79naa1czOTdubdfjkovyqTX6jTOMvEhZv/ovBLYjznz 8ORHR7HFqajIl3izm90+OWUtNpXKPgbfsP9tXVL6LPUOq3oWnxYpwLCK6LMkfizsVl/I Gfk8xsijS1ob3ZHwudTTncxcJxmeY3S71nzPJfnWNqcFx+qLt+33Vn5vi1XWSEa0JPDZ TKPg== X-Gm-Message-State: AOAM532HXLrz5vRUyI/NrhpKC9lk4PZzEfV/lKzkO6YpsQx2OKzqJ1x+ I5pgkY+HnjV3q/DFd8D/eXHUvSQdl9LFHv/B98LRlDyWXdOUyA== X-Google-Smtp-Source: ABdhPJzIk/bfynqAC3ZaZxB8wDO5JUN4kYg7LiAgBD771ScfOGsregM7M05AC/ZNYbjmsJeXLPlKjKmwSVt4rN2DwL0= X-Received: by 2002:ac8:6d2f:: with SMTP id r15mr27321832qtu.281.1595945460278; Tue, 28 Jul 2020 07:11:00 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: From: Brendan McMillion Date: Tue, 28 Jul 2020 07:10:48 -0700 Message-ID: To: Richard Barnes Cc: "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="0000000000003dd4e905ab8102d1" Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 14:11:06 -0000 --0000000000003dd4e905ab8102d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > But in the former class, you would be forcing the application to invent > its own scheme for signaling this stuff, which risks them making decision= s > that are suboptimal for metadata privacy. Making a metadata-resistant deployment of MLS would already be incredibly difficult because you'd have to design your application to use the network in a way that prevents useful traffic analysis. Someone who's capable of this should definitely be capable of choosing how messages are identified in their system. The flip side, is that your construction is already suboptimal for metadata privacy because the epoch id only changes once per epoch. In the construction that I described, the opaque identifier changes with each message. You could also imagine a system where the identifier would change with time instead of with protocol messages (for example, where messages are distributed over Tor circuits). On Tue, Jul 28, 2020 at 5:35 AM Richard Barnes wrote: > On Sat, Jul 25, 2020 at 6:10 PM Brendan McMillion > wrote: > >> I=E2=80=99m concerned about adversarial collisions, that'd cause a parti= al DoS >> like you say. There are other ways to cause partial DoS in an MLS group, >> but I think it=E2=80=99s good to minimize the avenues for attack. >> > > I wonder if this could in part be addressed just by using a longer > identifier to make finding adversarial collisions impractical. > > >> In your example, it sounds like you=E2=80=99re trying to achieve unlinka= bility >> between messages, with a Generic Commit Sequencing Service which is >> basically a KV store that only accepts one write per key. So in this >> scenario, I think you would be much better off by simply truncating the >> group ID and epoch from MLSCiphertext (making them implicit), and choosi= ng >> the key that each message is stored under with some function of: 1.) a >> group secret, and 2.) a message counter. >> >> Would that work? >> > > Interesting, but I don't think so. I'm concerned about forcing > applications to invent too much here. It seems like from what we know no= w, > some applications are going to need to identify the group ID / epoch in t= he > message, and in some applications, the group ID / epoch is going to be > clear from context. That latter class of application would probably be O= K > with an implicit GroupID / Epoch. But in the former class, you would be > forcing the application to invent its own scheme for signaling this stuff= , > which risks them making decisions that are suboptimal for metadata privac= y. > > So my preference would still be to provide an identifier that offers the > minimal properties required to make the protocol work. But I would be > happy to acknowledge that applications can leak more metadata if they nee= d > to, and that metadata can be ultimately authenticated by the protocol. I= n > fact, we could make this explicit by making the AAD for the ciphertext > encryption include the GroupID and Epoch counter in addition to the opaqu= e > epoch. > > What would folks think about the following proposal: > > 1. MLSCiphertext includes an opaque EpochID > 2. ... with a length that makes finding collisions infeasible (16 bytes? > 32 bytes? KDF.Nh bytes?) > 3. We add some explicit text noting that additional metadata can be added > by the application > 4. ... and update the AAD for the sender data and content encryptions to > use all three values (group ID, epoch counter, epoch ID) > > --Richard > > >> On Jul 25, 2020, at 12:38 PM, Richard Barnes wrote: >> >> Just so we're clear, in your example, are you concerned about accidental >> or adversarial collisions? I hope we agree that we can fix the accident= al >> case just by making a longer epoch ID. In the adversarial case, this se= ems >> like a partial DoS at worst, since the members who incorrectly think the= y >> are in the previous epoch will no longer be decrypting with the right ke= ys. >> >> As far as a positive example: Imagine a Generic Commit Sequencing Servic= e >> that provides a reliable broadcast/ledger over anonymous channels (e.g.,= as >> an onion service), but will only broadcast/record one message for each >> groupID/epoch. If the groupID/epoch is opaque, then such a service can = be >> provided without learning anything about the groups it serves or their >> evolution. >> >> >> On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion >> wrote: >> >>> Take for example, a broadcast channel that's ordered but lossy. A Commi= t >>> gets sent where the new epoch id collides with the previous epoch id, b= ut >>> not all members get the Commit. So now the group is fractured and there= 's >>> no way for members in the previous epoch to know that they missed a >>> message. What the application developer needs to do to detect lost >>> messages, is immediately re-implement the counter epoch id that you've = just >>> removed. >>> >>> That's an example of a system where this change is pointless / harmful. >>> If you could provide an example of a system where the change is *helpfu= l*, >>> that would be more interesting. >>> >>> On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes wrote: >>> >>>> I'm honestly really confused by the worry about collisions here. The >>>> current epoch ID collides trivially -- it's just a counter! And the g= roup >>>> ID is assumed to be public anyway. So if your authentication scheme i= s >>>> broken when you have a (group ID, epoch ID) collision, then your schem= e is >>>> already broken. >>>> >>>> If we're going to block this change on this basis, then we need to see >>>> clearly articulated an authentication scheme that is secure in the cur= rent >>>> model, but broken in the case where epoch IDs are derived off of the k= ey >>>> schedule. >>>> >>>> --Richard >>>> >>>> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) < >>>> britta.hale@nps.edu> wrote: >>>> >>>>> Ensuring the most conservative design by default seems advisable; >>>>> however it is not clear that this proposal for hiding content type is >>>>> actually doing that. Indeed, if an application is concerned about hid= ing >>>>> the content type, would not that same type of application also be con= cerned >>>>> about collisions? >>>>> >>>>> >>>>> >>>>> As Brendan notes, we are not talking about accidental collisions here= . >>>>> Pre-computation is entirely possible, such as by a malicious group me= mber, >>>>> so the window of attack is not limited to one epoch. >>>>> >>>>> >>>>> >>>>> If this is this PR particular is of particular interest to some, then >>>>> it would be good to see a clarifying explanation as to the security i= t >>>>> achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despi= te introducing such >>>>> collision possibilities), or a concrete use-case. Alternatively, are = we >>>>> really limited to a 64-bit field, or can that length be adjusted to >>>>> mitigate the introduced problems? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> A clarifying point for those following this thread: some references i= n >>>>> the email chain state that this is encryption of the epoch ID. That i= s not >>>>> the case. The proposal being discussed is about a hash thereof (hence >>>>> discussion on collisions). >>>>> >>>>> >>>>> >>>>> Britta >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *MLS on behalf of Brendan McMillion >>>>> >>>>> *Date: *Monday, July 13, 2020 at 9:37 AM >>>>> *To: *Richard Barnes >>>>> *Cc: *Messaging Layer Security WG >>>>> *Subject: *Re: [MLS] Hiding content type >>>>> >>>>> >>>>> >>>>> As far as collision resistance, I'm not too worried about collisions >>>>> among 64-bit random values, especially as the scope for collision is = fairly >>>>> small, arguably just one epoch. >>>>> >>>>> >>>>> >>>>> The issue isn't with accidental collisions, it's with malicious ones. >>>>> An attacker can purposefully (and quickly) generate commits that crea= te >>>>> duplicate epoch ids, and send them to a client to corrupt their group= state. >>>>> >>>>> >>>>> >>>>> I think the idea here is to be conservative by default. There are >>>>> systems in which you can hide the metadata you're talking about with = things >>>>> like mixnets and dropboxes. >>>>> >>>>> >>>>> >>>>> It's not just being more conservative, you're making changes >>>>> specifically for very niche use-cases where I don't think the securit= y of >>>>> the whole system has been thought through. Maybe you have an example = in >>>>> mind, but I can't think of a system where this change provides any >>>>> additional privacy. >>>>> >>>>> >>>>> >>>>> On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes wrote: >>>>> >>>>> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion < >>>>> brendan@cloudflare.com> wrote: >>>>> >>>>> With respect to using an opaque epoch id, I believe this was proposed >>>>> in #245 and >>>>> consensus was against it because it makes it more difficult to implem= ent >>>>> the DS. It's also not clear to me what security properties you want f= rom an >>>>> opaque epoch id, because the current PR doesn't provide collision >>>>> resistance and I'd expect this to be a source of confusion and bugs. >>>>> >>>>> >>>>> >>>>> I think the discussion on #245 got derailed a bit by the focus on >>>>> non-linear epochs. The point here is that even in a case where you h= ave >>>>> linear history, I think there's intrinsic value in the epoch ID being >>>>> opaque because it gives intermediaries less opportunity for ossificat= ion. >>>>> >>>>> >>>>> >>>>> As far as collision resistance, I'm not too worried about collisions >>>>> among 64-bit random values, especially as the scope for collision is = fairly >>>>> small, arguably just one epoch. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> With respect to encrypting the content type, it also seems to me that >>>>> this would cause issues because different content types have differen= t >>>>> delivery guarantees. Specifically: messages are allowed to be unorder= ed and >>>>> lossy, proposals are allowed to be unordered but not lossy, and commi= ts are >>>>> both ordered and not lossy. In the deployment scenarios we've talked = about, >>>>> the DS essentially always needs to know the content type to provide t= his. >>>>> Conversely, you don't get much additional privacy from encrypting the >>>>> content type because an eavesdropper can see the epoch id change and = infer >>>>> which message was a commit, or see a dropped message getting re-sent = and >>>>> infer it was a proposal. >>>>> >>>>> >>>>> >>>>> I don't disagree that there are different guarantees you need, but >>>>> like I said, I think the idea here is to be conservative by default. = There >>>>> are systems in which you can hide the metadata you're talking about w= ith >>>>> things like mixnets and dropboxes. Keeping the ciphertext as opaque = as >>>>> possible keeps the door open to running MLS over those systems withou= t >>>>> MLS's own metadata undermining their privacy properties. >>>>> >>>>> >>>>> >>>>> FWIW, in the systems I'm looking at building, this PR does not make >>>>> any difference, because clients use separate channels for Proposals/C= ommits >>>>> vs. application data and the server doesn't check. >>>>> >>>>> >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes wrote: >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2= ) >>>>> encrypt the content type of the message (application / proposal / com= mit) >>>>> [1]. >>>>> >>>>> >>>>> >>>>> There was some discussion on the call last week that encrypting the >>>>> content type might not be that useful, since an application that reli= es on >>>>> a server to assure ordering of commits will need to at least be able = to >>>>> tell commits from other things. Of course, even if the content type = is >>>>> encrypted by default, the application can add it back in authenticate= d >>>>> data, or in some unauthenticated wrapper. >>>>> >>>>> >>>>> >>>>> Net of those considerations, I'm personally still inclined to merge >>>>> the PR, to have a conservative baseline. But those on the call thoug= ht it >>>>> would be useful to pose this to the group, so please speak up if you = have >>>>> concerns. >>>>> >>>>> >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> [1] https://github.com/mlswg/mls-protocol/pull/349 >>>>> >>>>> _______________________________________________ >>>>> MLS mailing list >>>>> MLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mls >>>>> >>>>> >> --0000000000003dd4e905ab8102d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But in t= he former class, you would be forcing the application to invent=20 its own scheme for signaling this stuff, which risks them making=20 decisions that are suboptimal for metadata privacy.

Making a metadata-resistant deployment of MLS would already be inc= redibly difficult because you'd have to design your application to use = the network in a way that prevents useful traffic analysis. Someone who'= ;s capable of this should definitely be capable of choosing how messages ar= e identified in their system.

The flip side, i= s that your construction is already suboptimal for metadata privacy because= the epoch id only changes once per epoch. In the construction that I descr= ibed, the opaque identifier changes with each message. You could also imagi= ne a system where the identifier would change with time instead of with pro= tocol messages (for example, where messages are distributed over Tor circui= ts).

On Tue, Jul 28, 2020 at 5:35 AM Richard Barnes <rlb@ipv.= sx> wrote:
On Sat, Jul 25, 2020 at 6:10 PM Brendan McM= illion <bren= dan@cloudflare.com> wrote:
I=E2=80=99m concerned abo= ut adversarial collisions, that'd cause a partial DoS like you say. The= re are other ways to cause partial DoS in an MLS group, but I think it=E2= =80=99s good to minimize the avenues for attack.
I wonder if this could in part be addressed just by using a lon= ger identifier to make finding adversarial collisions impractical.
=C2=A0
In your example, it sounds like you=E2=80=99re trying to achieve unlinka= bility between messages, with a Generic Commit Sequencing Service which is = basically a KV store that only accepts one write per key. So in this scenar= io, I think you would be much better off by simply truncating the group ID = and epoch from MLSCiphertext (making them implicit), and choosing the key t= hat each message is stored under with some function of: 1.) a group secret,= and 2.) a message counter.

Would that work?

Interesting, but I don't thi= nk so.=C2=A0 I'm concerned about forcing applications to invent too muc= h here.=C2=A0 It seems like from what we know now, some applications are go= ing to need to identify the group ID / epoch in the message, and in some ap= plications, the group ID / epoch is going to be clear from context.=C2=A0 T= hat latter class of application would probably be OK with an implicit Group= ID / Epoch.=C2=A0 But in the former class, you would be forcing the applica= tion to invent its own scheme for signaling this stuff, which risks them ma= king decisions that are suboptimal for metadata privacy.

=
So my preference would still be to provide an identifier that of= fers the minimal properties required to make the protocol work.=C2=A0 But I= would be happy to acknowledge that applications can leak more metadata if = they need to, and that metadata can be ultimately authenticated by the prot= ocol.=C2=A0 In fact, we could make this explicit by making the AAD for the = ciphertext encryption include the GroupID and Epoch counter in addition to = the opaque epoch.

What would folks think about= the following proposal:

1. MLSCiphertext includes= an opaque EpochID
2. ... with a length that makes finding c= ollisions infeasible (16 bytes?=C2=A0 32 bytes?=C2=A0 KDF.Nh bytes?)
3. We add some explicit text noting that additional metadata can be= added by the application
4. ... and update the AAD for the sende= r data and content encryptions to use all three values (group ID, epoch cou= nter, epoch ID)

--Richard

<= div>

On Jul 25, 2020, at 12:38 = PM, Richard Barnes <rlb@= ipv.sx> wrote:

Just so we're= clear, in your example, are you concerned about accidental or adversarial = collisions?=C2=A0 I hope we agree that we can fix the accidental case just = by making a longer epoch ID.=C2=A0 In the adversarial case, this seems like= a partial DoS at worst, since the members who incorrectly think they are i= n the previous epoch will no longer be decrypting with the right keys.
<= /div>

As far as a positive example: Imagine a Generic Co= mmit Sequencing Service that provides a reliable broadcast/ledger over anon= ymous channels (e.g., as an onion service), but will only broadcast/record = one message for each groupID/epoch.=C2=A0 If the groupID/epoch is opaque, t= hen such a service can be provided without learning anything about the grou= ps it serves or their evolution.


On Sat, Jul 25, 2= 020 at 1:50 PM Brendan McMillion <brendan@cloudflare.com> wrote:
Take for = example, a broadcast channel that's ordered but lossy. A Commit gets se= nt where the new epoch id collides with the previous epoch id, but not all = members get the Commit. So now the group is fractured and there's no wa= y for members in the previous epoch to know that they missed a message. Wha= t the application developer needs to do to detect lost messages, is immedia= tely re-implement the counter epoch id that you've just removed.
<= div>
That's an example of a system where this change is p= ointless / harmful. If you could provide an example of a system where the c= hange is *helpful*, that would be more interesting.

On Fri, Jul 24= , 2020 at 11:05 AM Richard Barnes <rlb@ipv.sx> wrote:
I'm honestly really confuse= d by the worry about collisions here.=C2=A0 The current epoch ID collides t= rivially -- it's just a counter!=C2=A0 And the group ID is assumed to b= e public anyway.=C2=A0 So if your authentication scheme is broken when you = have a (group ID, epoch ID) collision, then your scheme is already broken.<= /div>

If we're going to block this change on this ba= sis, then we need to see clearly articulated an authentication scheme that = is secure in the current model, but broken in the case where epoch IDs are = derived off of the key schedule.

--Richard

On Tu= e, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <britta.hale@nps.edu> wrote:

Ensuring the most conservative design by defaul= t seems advisable; however it is not clear that this proposal for hiding co= ntent type is actually doing that. Indeed, if an application is concerned a= bout hiding the content type, would not that same type of application also be concerned about collisions? <= u>

=C2=A0

As Brendan notes, we are not talking about accidental collisions here.= Pre-computation is entirely possible, such as by a malicious group member,= so the window of attack is not limited to one epoch.

=C2=A0

If this is this PR particular is of particular interest to s= ome, then it would be good to see a clarifying explanation as to the securi= ty it achieves (i.e. why this is =E2=80=9Csecurity by design=E2=80=9D despi= te introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit f= ield, or can that length be adjusted to mitigate the introduced problems?

=C2=A0

=C2=A0

=C2=A0<= /u>

A clarifying point for those following this t= hread: some references in the email chain state that this is encryption of = the epoch ID. That is not the case. The proposal being discussed is about a= hash thereof (hence discussion on collisions).

=C2=A0

Britta

=C2=A0=

=C2=A0

From: = MLS <mls-bounces@ietf.org> on behalf of Brendan McM= illion <brendan=3D40cloudflare.com@dmarc.ietf.org>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Hiding content type

=C2=A0

As far as collision resistance, I'm not too= worried about collisions among 64-bit random values, especially as the sco= pe for collision is fairly small, arguably just one epoch.

=C2=A0

The issue isn't with accidental collisions,= it's with malicious ones. An attacker can purposefully (and quickly) g= enerate commits that create duplicate epoch ids, and send them to a client = to corrupt their group state.

=C2=A0

I think the idea here is to be conservative by = default.=C2=A0 There are systems in which you can hide the metadata you'= ;re talking about with things like mixnets and dropboxes.

=C2=A0

It's not just being more conservative, you&= #39;re making changes specifically for very niche use-cases where I don'= ;t think the security of the whole system has been thought through. Maybe y= ou have an example in mind, but I can't think of a system where this change provides any additional privacy.

=C2=A0

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes= <rlb@ipv.sx> wro= te:

On Mon, Jul 13, 2020 at 10:57 AM Brendan McMill= ion <brendan= @cloudflare.com> wrote:

With respect to using an opaque epoch id, I bel= ieve this was proposed in #245 and consensus was against it because it makes it more difficult = to implement the DS. It's also not clear to me what security properties= you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect= this to be a source of confusion and bugs.

=C2=A0

I think the discussion on #245 got derailed a b= it by the focus on non-linear epochs.=C2=A0 The point here is that even in = a case where you have linear history, I think there's intrinsic value i= n the epoch ID being opaque because it gives intermediaries less opportunity for ossification.

=C2=A0

As far as collision resistance, I'm not too= worried about collisions among 64-bit random values, especially as the sco= pe for collision is fairly small, arguably just one epoch.

=C2=A0

=C2=A0

With respect to encrypting the content type, it= also seems to me that this would cause issues because different content ty= pes have different delivery guarantees. Specifically: messages are allowed = to be unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and no= t lossy. In the deployment scenarios we've talked about, the DS essenti= ally always needs to know the content type to provide this. Conversely, you= don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id c= hange and infer which message was a commit, or see a dropped message gettin= g re-sent and infer it was a proposal.

=C2=A0

I don't disagree that there are different g= uarantees you need, but like I said, I think the idea here is to be conserv= ative by default.=C2=A0 There are systems in which you can hide the metadat= a you're talking about with things like mixnets and dropboxes.=C2=A0 Keeping the ciphertext as opaque as possible keeps th= e door open to running MLS over those systems without MLS's own metadat= a undermining their privacy properties.

=C2=A0

FWIW, in the systems I'm looking at buildin= g, this PR does not make any difference, because clients use separate chann= els for Proposals/Commits vs. application data and the server doesn't c= heck.

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes = <rlb@ipv.sx> wrot= e:

Hi all,

=C2=A0

Recall that PR#349 does two things (1) use an o= paque epoch ID, and (2) encrypt the content type of the message (applicatio= n / proposal / commit) [1].

=C2=A0

There was some discussion on the call last week= that encrypting the content type might not be that useful, since an applic= ation that relies on a server to assure ordering of commits will need to at= least be able to tell commits from other things.=C2=A0 Of course, even if the content type is encrypted by default,= the application can add it back in authenticated data, or in some unauthen= ticated wrapper.

=C2=A0

Net of those considerations, I'm personally= still inclined to merge the PR, to have a conservative baseline.=C2=A0 But= those on the call thought it would be useful to pose this to the group, so= please speak up if you have concerns.

=C2=A0

--Richard

=C2=A0

______________________________________________= _
MLS mailing list
MLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mls


--0000000000003dd4e905ab8102d1-- From nobody Tue Jul 28 10:38:14 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 C1F6C3A0A4D for ; Tue, 28 Jul 2020 10:38:12 -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 Uj2lT2UcLEwe for ; Tue, 28 Jul 2020 10:38:08 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 5EC6A3A0A49 for ; Tue, 28 Jul 2020 10:38:08 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id u64so19423892qka.12 for ; Tue, 28 Jul 2020 10:38:08 -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=pqHrF+BHJKIZHApcANcz/+lZysj8KOyJFwbPCqDySJA=; b=tjNycLOBHv2K9BFQufM0uqdBKEzfEV/j+28MrspCWTEoC+eCpBj1zvSdZbWzWSM/38 6UrjeIzgwukggLOct+iw2vmlIpX8RRCtfckf53wDTZMR+1nKm682H7OwCO/XK1fN1vPo XpkiB2uNv+jP9UpdO2OIdtvbexK4jQuxZV7mX9T2mUnOU30qMKqfi8KEMH2eEnYE8QyM fm2ljZK9U9W/elvZapOmhMS0B5JgkO5quiJ6QA9wuYFf5ZOZYa4/OuJoU7XR4nP60ubQ y17N+SIwX3I8Eld9gjtxTrn7AFBuuNS73w1j+j295w1MGx3VMvsG43W3FmhCHkRzNAKF ZBpw== 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=pqHrF+BHJKIZHApcANcz/+lZysj8KOyJFwbPCqDySJA=; b=YVI4Mda4iXAdLCEzScZAyyDfekhhFDG+3Vrx/vTnDtoQ4lMUxALkXqDnH3ACHwrpPT CaN5H3B1Ii13PXNouLGOxjwyzf3Zrej3+Ag0uDn2KIo+IkykTfxzpXFR3rN+S6NMc9qQ ZHe41jh9MPz16jO6hMWcwe/aQfjgvS/fQ8+T10qPtu4nWoTbhYj5wp5wWwduwS4p41Dm 3SZCgHeGt9Bvqdb1y0HJ+u/JqzPi68HK4tasekfj705T6F5XswmrpAyrjFv9s+JWTpGT gUVzKS5DhhsuGLKoAM0zZzJmFwqDWLn/RLToYayRRwnFZVZb1jjp5iz33ZpIANBqA5/8 2rKg== X-Gm-Message-State: AOAM5335I2vz7T5w6cgFeVNnsysKTNABU2nbtRWhuJ35cXBfl32W7ImQ XMVMRo8jORGgUinsashvCkacDH3G7qnHtO2I+ubdnHqZw6zarQ== X-Google-Smtp-Source: ABdhPJxgfBBDpkClzcRyESUCT/0owdx/8Q8UOrBZ9Gygv0w5v244vETp2D1VDh5rDijGD/5ZUb9h8+F47WiBjmNJlsM= X-Received: by 2002:a37:5cc5:: with SMTP id q188mr14022717qkb.347.1595957887049; Tue, 28 Jul 2020 10:38:07 -0700 (PDT) MIME-Version: 1.0 References: <710ba832-c77c-58d2-a7b4-b8dc8eaf09e3@datashrine.de> In-Reply-To: From: Richard Barnes Date: Tue, 28 Jul 2020 13:37:37 -0400 Message-ID: To: Konrad Kohbrok Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000ef3da105ab83e6fb" Archived-At: Subject: Re: [MLS] PSK Injection, Group recovery, Re-Init, Sub-group Branching (#336) 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, 28 Jul 2020 17:38:13 -0000 --000000000000ef3da105ab83e6fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually, noticed one thing that isn't accounted for in that list: Derive an "authentication secret" https://github.com/mlswg/mls-protocol/issues/374 A fun question for the list is what we should call these things, since there are a bunch of terms in the prior art, for example: - Authentication secret [PR#336] - Short authentication string [ZRTP, TLS] - Safety numbers [Signal] - Security codes [Zoom security whitepaper] Personally, I'm inclined against things that include "authentication", since the thing we're defining here is a backstop to the primary Authentication Service. Among the above list, "Security Codes" might be my favorite. Otherwise, maybe something like "group state verifier"? On Fri, Jul 24, 2020 at 6:39 PM Richard Barnes wrote: > Picking this thread back up: > > I tried to encapsulate my approach to the issues here in a few GitHub > issues and one PR: > > Reorder key schedule inputs > https://github.com/mlswg/mls-protocol/issues/362 > > Add extensions to the Commit message > https://github.com/mlswg/mls-protocol/issues/366 > > Negotiate PSKs > https://github.com/mlswg/mls-protocol/issues/367 > > Proof of prior membership in the group / Resumption > https://github.com/mlswg/mls-protocol/issues/368 > > Konrad / Britta - I think those combine to cover the cases you were tryin= g > to address in #366, but tease the issues apart a bit more clearly. Does > that make sense to you? What have I missed here? If this general plan > looks good, I think we can get the details arranged and agreed fairly > quickly, as these are each pretty self-contained pieces of work. > > Thanks, > --Richard > > On Tue, Jul 14, 2020 at 12:37 PM Konrad Kohbrok < > konrad.kohbrok@datashrine.de> wrote: > >> We just briefly touched upon this PR in the virtual interim on July 14th >> and I >> think we agreed that the discussion should be continued on the >> mailinglist and >> then tied up at the IETF 108 meeting. >> >> I think continuing the discussion on the mailinglist is a good idea, >> however, >> neither Britta nor myself are going to be present at the IETF 108 >> meeting. Maybe >> we can push the discussion to the next virtual interim meeting instead? >> >> Cheers, >> Konrad >> >> >> On 18.06.20 16:29, Konrad Kohbrok wrote: >> > Hi, >> > >> > Just a small addition to Britta's response: >> > >> > For #3: We already mandate that the parent group must not be used >> anymore if a >> > Re-Init proposal is included in a commit in lines 2341-2342 of the PR >> (although >> > "to send messages" might as well be removed). We could also get rid of >> the >> > proposal and simply have the intent to re-initialize be implicit in >> sending a >> > Welcome message with a corresponding PSK Id. The idea behind the >> Proposal was to >> > make that intent explicit such that the intent, as well as the target >> > ciphersuite and MLS version are all entered into the transcript and >> thus agreed >> > upon. Even though the group is terminated after the proposal is >> received, this >> > agreement can be verified by using the authentication key technique >> that Britta >> > proposed, i.e. each party can check that their authentication key >> corresponds to >> > the one the committer uploaded. >> > >> > I'm also ok with splitting it into multiple individual PRs if that >> makes it >> > easier to review and discuss. >> > >> > Cheers, >> > Konrad >> > >> > >> > On 18.06.20 04:07, Hale, Britta (CIV) wrote: >> >> Hi Richard, >> >> >> >> >> >> >> >> Thank you for the comments and careful read of the PR. >> >> >> >> >> >> >> >> For #1/#2: I am amicable to the idea of adding an extension field to >> the commit >> >> message. As a general comment, we may want to consider if there are >> other types >> >> of commit extensions worth adding or, alternatively, how the field ma= y >> be abused >> >> (e.g. treated as AD by an application). >> >> >> >> It terms of objection to the current form though, your argument is no= t >> clear. >> >> PSKIds should uniquely identify PSKs, and a joiner (or anyone) should >> be able to >> >> identify the correct PSK given the PSKId, if they are in possession o= f >> it. PSKs >> >> must only be used in an Add if the joiner is a past group member (lin= e >> 2055) and >> >> therefore has the correct PSKId/group_id/psk_epoch, although this is >> nullified >> >> if we make the change discussed in #4. In that case, the issue for >> Adds goes away. >> >> >> >> The PR already allows for a PSK in the Welcome message. >> >> >> >> >> >> >> >> For #3: Currently, in the PR, there is a recovery_secret derived >> per-epoch. When >> >> a member wants to re-initialize, they issue a Re-Init proposal. They >> may then >> >> re-initialize the group by sending a Welcome message (see lines 1923, >> 1948, and >> >> 2349) with the PSKId for the parent group/epoch and a psktype that >> indicates >> >> that they are re-initializing the group with the stated PSKId. So thi= s >> seems to >> >> already be what you describe below as =E2=80=9Chave the initiator of = the child >> send a >> >> Welcome that has a pointer back to the parent=E2=80=9D. However, you = are right >> that more >> >> detail can be added; in particular a requirement should be added to >> terminate >> >> the parent group and that the terminating member/re-init proposer mus= t >> also >> >> create the new group. >> >> >> >> >> >> >> >> For #4: There was a discussion at the first virtual interim in late >> April >> >> (Interim #11-2020) wherein some expressed a desire for this feature. >> Namely, >> >> instead of re-syncing the entire group, there were use cases for >> re-syncing the >> >> odd member when necessary. Its inclusion in the PR arises from that >> later >> >> request. I am favorable to removing it since, from security >> standpoint, it is >> >> not ideal. However, the motivation for this was pushed from the >> implementation >> >> standpoint. Consequently, now is a good time for anyone to speak up >> who wants to >> >> push for this. >> >> >> >> >> >> >> >> >> >> >> >> One item: you made point of specifically requesting =E2=80=93 a few t= imes =E2=80=93 at >> the >> >> virtual interims #11 and #12 in April/May that this PSK PR and as man= y >> other key >> >> schedule-related PRs be combined into a single one. Raphael made a >> similar >> >> request under git issue #325. In fact, the authors of this PR had >> pushed back on >> >> that insistence to limit the current PR down to the items it currentl= y >> covers, >> >> instead of merging in other key schedule changes as well. Are you >> saying that >> >> you have changed your mind? >> >> >> >> We can, of course, accommodate a revised preference if needed. >> >> >> >> >> >> >> >> >> >> >> >> Britta >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From: *MLS on behalf of Richard Barnes >> >> >> *Date: *Wednesday, June 17, 2020 at 3:54 PM >> >> *To: *Messaging Layer Security WG >> >> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group >> Branching (#336) >> >> >> >> >> >> >> >> Hey all, >> >> >> >> Sorry for the late review on this PR, I have finally gotten a chance >> to really >> >> dig into it, and ... I have some concerns. My current thinking is >> consistent >> >> with my earlier comments that the general thrust of this PR is OK. >> But I think >> >> the actual approach needs to change a fair bit. >> >> >> >> As its title implies, this PR is trying to do several things at once, >> which seem >> >> to me to be fairly separable: >> >> >> >> 0. Update the key schedule so that PSKs are injected at the right >> point and >> >> multiple PSKs are supported >> >> 1. Signal that a PSK should get injected into a given epoch >> >> 2. Request injection of PSK at join / in Welcome >> >> 3. Re-initialize the group with different parameters >> >> 4. Re-sync group members that have lost state >> >> >> >> For the most part, I think these are worthwhile goals, but they shoul= d >> be >> >> accomplished in different ways than the PR proposes. Detailed >> thoughts by >> >> objective: >> >> >> >> >> >> # 0. Update the key schedule so that PSKs are injected at the right >> point and >> >> multiple PSKs are supported >> >> >> >> This part of the PR is fine, but I think is ultimately done a bit mor= e >> elegantly >> >> with the n-PRF stuff in #337. >> >> >> >> >> >> # 1. Signal that a PSK should get injected into a given epoch >> >> # 2. Request injection of PSK at join / in Welcome >> >> >> >> (These go together) >> >> >> >> The PR proposes (heh) an EPSK proposal or an Add proposal, but then >> requires >> >> that only one EPSK be used. I actually don't the proposal for >> including PSKs in >> >> Adds actually works. The joiner would have to know all of them plus >> the EPSK, >> >> and there's not even any syntax in the PR to tell the joiner which >> ones to include. >> >> >> >> I would propose that instead we add an extensions field to the Commit >> message, >> >> then add a Commit extension that specifies the PSK ID for the PSK to >> be added. >> >> That extension can then also go in the Welcome message corresponding >> to the >> >> commit, so that joiners know to add the PSK. >> >> >> >> This change actually doesn't make a difference in terms of what ends >> up in the >> >> transcript -- either way, only the PSK ID selected by the committer >> goes in the >> >> transcript. It seems better not to deliberately have proposals >> floating around >> >> that never get included in the transcript. >> >> >> >> >> >> # 3. Re-initialize the group with different parameters >> >> >> >> The PR proposes another proposal type for reinitialization, but it's >> really >> >> under-specified what you do to re-init. For example, what goes in th= e >> ratchet >> >> tree? Clearly you need a brand new tree, since the one you have migh= t >> be tied >> >> to the wrong ciphersuite. What you really need is something like a >> Welcome message. >> >> >> >> And that's how I think we should actually arrange things. Instead of >> having the >> >> parent group do something to spawn, have the initiator of the child >> send a >> >> Welcome that has a pointer back to the parent. So we have another >> Welcome >> >> extension (`parent_group`, say) that has a pointer to the parent grou= p >> by group >> >> ID and epoch, and instructs the joiner to take a secret from that >> group/epoch's >> >> key schedule and add it into the new group's key schedule. >> >> >> >> >> >> >> >> # 4. Re-sync group members that have lost state >> >> >> >> We should not do these. At the January interim, we decided not to >> drop the >> >> resync issue (#93) given that there were some subtleties depending on >> exactly >> >> what state had been lost, and that it could be cleanly done in a >> separate spec. >> >> >> >> >> >> # Conclusions >> >> >> >> Given the above, I would propose we break this into separate issues t= o >> be closed >> >> with individual, smaller PRs. Assuming that (0) will get addressed b= y >> the n-PRF >> >> PR, that leaves us with: >> >> >> >> #XXX Add Extensions to the Commit message >> >> #XXX Signal use of external PSKs in Commit/Welcome (=3D> extension to >> >> Commit/Welcome messages) >> >> #XXX Allow Welcome to signal the inclusion of information from a prio= r >> group (=3D> >> >> Welcome extension) >> >> >> >> Happy to write those up, and contribute to PRs. Sorry again for the >> slow >> >> progress here. >> >> >> >> --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 >> > >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --000000000000ef3da105ab83e6fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually, noticed one thing that isn't accounted = for in that list:

Derive an "authentication s= ecret"

=
A fun question for the list is what we should call these things,= since there are a bunch of terms in the prior art, for example:
=
- Authentication secret [PR#336]
- Short authentic= ation string [ZRTP, TLS]
- Safety numbers [Signal]
- Se= curity codes [Zoom security whitepaper]

Personally= , I'm inclined against things that include "authentication", = since the thing we're defining here is a backstop to the primary Authen= tication Service.=C2=A0 Among the above list, "Security Codes" mi= ght be my favorite.=C2=A0 Otherwise, maybe something like "group state= verifier"?


On Fri, Jul 24, 2020 at 6:39 PM Ri= chard Barnes <rlb@ipv.sx> wrote:
Picking this thread back up:

I tried to encapsulate my approach to the issues he= re in a few GitHub issues and one PR:

Reorder key = schedule inputs

Add extensions to the Commit message
=
Negotiate PSKs

Proof of prior membership i= n the group / Resumption

Konrad / Britta - I think those c= ombine to cover the cases you were trying to address in #366, but tease the= issues apart a bit more clearly.=C2=A0 Does that make sense to you?=C2=A0 = What have I missed here?=C2=A0 If this general plan looks good, I think we = can get the details arranged and agreed fairly quickly, as these are each p= retty self-contained pieces of work.

Thanks,
=
--Richard

On Tue, Jul 14, 2020 at 12:37 PM Konrad Kohbrok <= ;konrad.k= ohbrok@datashrine.de> wrote:
We just briefly touched upon this PR in the virtual int= erim on July 14th and I
think we agreed that the discussion should be continued on the mailinglist = and
then tied up at the IETF 108 meeting.

I think continuing the discussion on the mailinglist is a good idea, howeve= r,
neither Britta nor myself are going to be present at the IETF 108 meeting. = Maybe
we can push the discussion to the next virtual interim meeting instead?

Cheers,
Konrad


On 18.06.20 16:29, Konrad Kohbrok wrote:
> Hi,
>
> Just a small addition to Britta's response:
>
> For #3: We already mandate that the parent group must not be used anym= ore if a
> Re-Init proposal is included in a commit in lines 2341-2342 of the PR = (although
> "to send messages" might as well be removed). We could also = get rid of the
> proposal and simply have the intent to re-initialize be implicit in se= nding a
> Welcome message with a corresponding PSK Id. The idea behind the Propo= sal was to
> make that intent explicit such that the intent, as well as the target<= br> > ciphersuite and MLS version are all entered into the transcript and th= us agreed
> upon. Even though the group is terminated after the proposal is receiv= ed, this
> agreement can be verified by using the authentication key technique th= at Britta
> proposed, i.e. each party can check that their authentication key corr= esponds to
> the one the committer uploaded.
>
> I'm also ok with splitting it into multiple individual PRs if that= makes it
> easier to review and discuss.
>
> Cheers,
> Konrad
>
>
> On 18.06.20 04:07, Hale, Britta (CIV) wrote:
>> Hi Richard,
>>
>> =C2=A0
>>
>> Thank you for the comments and careful read of the PR.
>>
>> =C2=A0
>>
>> For #1/#2: I am amicable to the idea of adding an extension field = to the commit
>> message. As a general comment, we may want to consider if there ar= e other types
>> of commit extensions worth adding or, alternatively, how the field= may be abused
>> (e.g. treated as AD by an application).
>>
>> It terms of objection to the current form though, your argument is= not clear.
>> PSKIds should uniquely identify PSKs, and a joiner (or anyone) sho= uld be able to
>> identify the correct PSK given the PSKId, if they are in possessio= n of it. PSKs
>> must only be used in an Add if the joiner is a past group member (= line 2055) and
>> therefore has the correct PSKId/group_id/psk_epoch, although this = is nullified
>> if we make the change discussed in #4. In that case, the issue for= Adds goes away.
>>
>> The PR already allows for a PSK in the Welcome message.
>>
>> =C2=A0
>>
>> For #3: Currently, in the PR, there is a recovery_secret derived p= er-epoch. When
>> a member wants to re-initialize, they issue a Re-Init proposal. Th= ey may then
>> re-initialize the group by sending a Welcome message (see lines 19= 23, 1948, and
>> 2349) with the PSKId for the parent group/epoch and a psktype that= indicates
>> that they are re-initializing the group with the stated PSKId. So = this seems to
>> already be what you describe below as =E2=80=9Chave the initiator = of the child send a
>> Welcome that has a pointer back to the parent=E2=80=9D. However, y= ou are right that more
>> detail can be added; in particular a requirement should be added t= o terminate
>> the parent group and that the terminating member/re-init proposer = must also
>> create the new group.
>>
>> =C2=A0
>>
>> For #4: There was a discussion at the first virtual interim in lat= e April
>> (Interim #11-2020) wherein some expressed a desire for this featur= e. Namely,
>> instead of re-syncing the entire group, there were use cases for r= e-syncing the
>> odd member when necessary. Its inclusion in the PR arises from tha= t later
>> request. I am favorable to removing it since, from security standp= oint, it is
>> not ideal. However, the motivation for this was pushed from the im= plementation
>> standpoint. Consequently, now is a good time for anyone to speak u= p who wants to
>> push for this.
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> One item: you made point of specifically requesting =E2=80=93 a fe= w times =E2=80=93 at the
>> virtual interims #11 and #12 in April/May that this PSK PR and as = many other key
>> schedule-related PRs be combined into a single one. Raphael made a= similar
>> request under git issue #325. In fact, the authors of this PR had = pushed back on
>> that insistence to limit the current PR down to the items it curre= ntly covers,
>> instead of merging in other key schedule changes as well. Are you = saying that
>> you have changed your mind?
>>
>> We can, of course, accommodate a revised preference if needed.
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> Britta
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> =C2=A0
>>
>> *From: *MLS <mls-bounces@ietf.org> on behalf of Richard Barnes <rlb@ip= v.sx>
>> *Date: *Wednesday, June 17, 2020 at 3:54 PM
>> *To: *Messaging Layer Security WG <mls@ietf.org>
>> *Subject: *[MLS] PSK Injection, Group recovery, Re-Init, Sub-group= Branching (#336)
>>
>> =C2=A0
>>
>> Hey all,
>>
>> Sorry for the late review on this PR, I have finally gotten a chan= ce to really
>> dig into it, and ... I have some concerns.=C2=A0 My current thinki= ng is consistent
>> with my earlier comments that the general thrust of this PR is OK.= =C2=A0 But I think
>> the actual approach needs to change a fair bit.
>>
>> As its title implies, this PR is trying to do several things at on= ce, which seem
>> to me to be fairly separable:
>>
>> 0. Update the key schedule so that PSKs are injected at the right = point and
>> multiple PSKs are supported
>> 1. Signal that a PSK should get injected into a given epoch
>> 2. Request injection of PSK at join / in Welcome
>> 3. Re-initialize the group with different parameters
>> 4. Re-sync group members that have lost state
>>
>> For the most part, I think these are worthwhile goals, but they sh= ould be
>> accomplished in different ways than the PR proposes.=C2=A0 Detaile= d thoughts by
>> objective:
>>
>>
>> # 0. Update the key schedule so that PSKs are injected at the righ= t point and
>> multiple PSKs are supported
>>
>> This part of the PR is fine, but I think is ultimately done a bit = more elegantly
>> with the n-PRF stuff in #337.
>>
>>
>> # 1. Signal that a PSK should get injected into a given epoch
>> # 2. Request injection of PSK at join / in Welcome
>>
>> (These go together)
>>
>> The PR proposes (heh) an EPSK proposal or an Add proposal, but the= n requires
>> that only one EPSK be used.=C2=A0 I actually don't the proposa= l for including PSKs in
>> Adds actually works.=C2=A0 The joiner would have to know all of th= em plus the EPSK,
>> and there's not even any syntax in the PR to tell the joiner w= hich ones to include.
>>
>> I would propose that instead we add an extensions field to the Com= mit message,
>> then add a Commit extension that specifies the PSK ID for the PSK = to be added.=C2=A0
>> That extension can then also go in the Welcome message correspondi= ng to the
>> commit, so that joiners know to add the PSK.
>>
>> This change actually doesn't make a difference in terms of wha= t ends up in the
>> transcript -- either way, only the PSK ID selected by the committe= r goes in the
>> transcript.=C2=A0 It seems better not to deliberately have proposa= ls floating around
>> that never get included in the transcript.
>>
>>
>> # 3. Re-initialize the group with different parameters
>>
>> The PR proposes another proposal type for reinitialization, but it= 's really
>> under-specified what you do to re-init.=C2=A0 For example, what go= es in the ratchet
>> tree?=C2=A0 Clearly you need a brand new tree, since the one you h= ave might be tied
>> to the wrong ciphersuite.=C2=A0 What you really need is something = like a Welcome message.
>>
>> And that's how I think we should actually arrange things.=C2= =A0 Instead of having the
>> parent group do something to spawn, have the initiator of the chil= d send a
>> Welcome that has a pointer back to the parent.=C2=A0 So we have an= other Welcome
>> extension (`parent_group`, say) that has a pointer to the parent g= roup by group
>> ID and epoch, and instructs the joiner to take a secret from that = group/epoch's
>> key schedule and add it into the new group's key schedule.
>>
>>
>>
>> # 4. Re-sync group members that have lost state
>>
>> We should not do these.=C2=A0 At the January interim, we decided n= ot to drop the
>> resync issue (#93) given that there were some subtleties depending= on exactly
>> what state had been lost, and that it could be cleanly done in a s= eparate spec.
>>
>>
>> # Conclusions
>>
>> Given the above, I would propose we break this into separate issue= s to be closed
>> with individual, smaller PRs.=C2=A0 Assuming that (0) will get add= ressed by the n-PRF
>> PR, that leaves us with:
>>
>> #XXX Add Extensions to the Commit message
>> #XXX Signal use of external PSKs in Commit/Welcome (=3D> extens= ion to
>> Commit/Welcome messages)
>> #XXX Allow Welcome to signal the inclusion of information from a p= rior group (=3D>
>> Welcome extension)
>>
>> Happy to write those up, and contribute to PRs.=C2=A0 Sorry again = for the slow
>> progress here.
>>
>> --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
>

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000ef3da105ab83e6fb-- From nobody Tue Jul 28 11:24: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 1B13F3A0AE5 for ; Tue, 28 Jul 2020 11:24:15 -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=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 5oXsz2wH_GTx for ; Tue, 28 Jul 2020 11:24:13 -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 096B93A0B0A for ; Tue, 28 Jul 2020 11:24:12 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id g26so19657655qka.3 for ; Tue, 28 Jul 2020 11:24: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=ZI7OclXDrq/9a71xihMCKDhSnMSQSY+FlTMkTruwUBA=; b=vd5f66uBfcqOLPr3fBWXEVDXXKk7hSUrfQZgxueXBDMP93BXQiqsQGTEu7ZdZbTW2f ngOuO449xAq0xqo60DOA2CTfeNa30NAjdYTjAt4CB7kXDEoJOax72g6gnsQA8U3mCLUC clXIywDvpes3YdGQGEUJatxS14Fw7S25+4bck= 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=ZI7OclXDrq/9a71xihMCKDhSnMSQSY+FlTMkTruwUBA=; b=GxqpDwp+BcXt638hDR/iBgXok3JnsYc4Te1V0napb9gnGJkgKKo1/HbW3zYJUvyPMy 9ODlxqgDZK6b1Z150r0igt1LKGhyEpqjxaDU8QISyzOnlhuYNrklTfQwT453uzguRpvl bYqFWoSLzDtQMC/8ZMtfVCm4+yME/eaPm63EQaPI4yLi44vCBrvbguZ+Vpkzd4opJdRm QraYu0R0dmF5ZlfYQRkoXgDdiY9LogmG3FDZLTcYH8NV9WsscTH5YsCV+HDlyNkh5Q3D 8pxVn1L7ducuUzkRWJnFLrd9gBKsiTNSFWzgNk1PMYsh/sDXWr4JiDx8j0zet2NfJEvB 23UQ== X-Gm-Message-State: AOAM531XB0cqP9CArHrV9/EP+cuFL5fh+sEzvqMgktw+mpeLtT1yO+tv /97W44vz5ZqYBBmX8nE03046WSErPqvgB9YESdWP8/l4DfY= X-Google-Smtp-Source: ABdhPJwdw3l8ScawE0d7FpuwHSqtO2memEnosNe1cSGHeD26uCyerHRFWSGBKaALDqH64dfWsj/4oihtSJKcpMhZ/RY= X-Received: by 2002:a05:620a:cd6:: with SMTP id b22mr28189684qkj.443.1595960651863; Tue, 28 Jul 2020 11:24:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brendan McMillion Date: Tue, 28 Jul 2020 11:24:00 -0700 Message-ID: To: Richard Barnes Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000bb085505ab848bae" Archived-At: Subject: Re: [MLS] Masking sender data 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, 28 Jul 2020 18:24:15 -0000 --000000000000bb085505ab848bae Content-Type: text/plain; charset="UTF-8" This PR was discussed at IETF 108 this morning, and the one issue that came up is whether or not we should really truncate the auth tag from the ciphertext. Personally I see no problem with it, as everything in MLSCiphertext is still authenticated. And with the auth tag truncated, performance-sensitive applications can optimize away the "second pass" on the ciphertext by using AES-CTR (or the corresponding unauthenticated cipher mode for their AEAD). Implementations that don't mind the second pass also have good options, for example: the same operation used to encrypt (AEAD encrypt and truncate auth tag), when applied to the ciphertext, returns the plaintext. So the same code does encryption and decryption. I'm curious to hear how others feel On Mon, Jul 20, 2020 at 1:02 PM Richard Barnes wrote: > Hi Brendan, > > Thanks a lot for writing this up! I agree that this addresses the > authenticity concerns that had been raised on earlier iterations of this > problem. I've suggested a few corrections and simplifications in the PR. > > https://github.com/mlswg/mls-protocol/pull/360#discussion_r457656760 > > Either way (what you suggested or with my edits), it's clear that there's > some non-trivial complexity involved here. Both in terms of getting the > operations in the right order (content encryption, then sender data > encryption, and reverse for decryption), and in terms of constructing all > the different AAD values. So I wonder how people feel about that taking > that compexity cost in the interest of removing an explicit nonce. > Personally, I'm probably still inclined to do it, since explicit nonces > make me nervous, but I would like to hear what other folks think. > > --Richard > > On Thu, Jul 16, 2020 at 12:31 PM Brendan McMillion 40cloudflare.com@dmarc.ietf.org> wrote: > >> Hello mls@ >> >> There's been an open ticket [1] on MLS for a while now to explore masking >> sender data instead of encrypting it with an AEAD. I opened a PR [2] with >> an initial attempt to achieve this, which I wanted to now introduce to the >> list. >> >> The first major change is to encrypt the first block of `ciphertext` >> under a derived key with AES-ECB, and XOR the encoded SenderData with that >> value. The masked sender data replaces the `encrypted_sender_data` and >> obsoletes `sender_data_nonce`. The PR also specifies that the auth tag >> should be truncated from the `ciphertext` because the full MLSCiphertext is >> now authenticated with a MAC under a shared key, and this MAC is stored on >> its own in an `auth_tag` field on MLSCiphertext. >> >> The process of masking the sender data is designed to match the >> construction HN1 in [3]. The reason for messing around with the MAC >> structure, is that it allows us to validate the integrity of the sender >> data before we use it to generate sender-specific keys, while still only >> have one MAC total. >> >> One of the downsides to this proposal is that it requires two passes over >> the ciphertext, since we'd now encrypt and authenticate in separate passes. >> While I'd like to get rid of this, I don't think it will be a big >> performance issue for implementations. >> >> Feedback welcomed! >> >> 1. https://github.com/mlswg/mls-protocol/issues/302 >> 2. https://github.com/mlswg/mls-protocol/pull/360 >> 3. https://eprint.iacr.org/2019/624.pdf >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > --000000000000bb085505ab848bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This PR was discussed at IETF 108 this morning, and t= he one issue that came up is whether or not we should really truncate the a= uth tag from the ciphertext.

Personally I see no p= roblem with it, as everything in MLSCiphertext is still authenticated. And = with the auth tag truncated, performance-sensitive applications can optimiz= e away the "second pass" on the ciphertext by using AES-CTR (or t= he corresponding unauthenticated cipher mode for their AEAD). Implementatio= ns that don't mind the second pass also have good options, for example:= the same operation used to encrypt (AEAD encrypt and truncate auth tag), w= hen applied to the ciphertext, returns the plaintext. So the same code does= encryption and decryption.

I'm curious to hea= r how others feel

On Mon, Jul 20, 2020 at 1:02 PM Richard Barnes &= lt;rlb@ipv.sx> wrote:
Hi Brendan,

Thank= s a lot for writing this up!=C2=A0 I agree that this addresses the authenti= city concerns that had been raised on earlier iterations of this problem.= =C2=A0 I've suggested a few corrections and simplifications in the PR.<= /div>


Eit= her way (what you suggested or with my edits), it's clear that there= 9;s some non-trivial complexity involved here.=C2=A0 Both in terms of getti= ng the operations in the right order (content encryption, then sender data = encryption, and reverse for decryption), and in terms of constructing all t= he different AAD values.=C2=A0 So I wonder how people feel about that takin= g that compexity cost in the interest of removing an explicit nonce. Person= ally, I'm probably still inclined to do it, since explicit nonces make = me nervous, but I would like to hear what other folks think.
=
--Richard

On Thu, Jul 16, 2020 at 12:31 PM Brendan = McMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Hell= o mls@

There's been an open ticket [1] on MLS = for a while now to explore masking sender data instead of encrypting it wit= h an AEAD. I opened a PR [2] with an initial attempt to achieve this, which= I wanted to now introduce to the list.

The first = major change is to encrypt the first block of `ciphertext` under a derived = key with AES-ECB, and XOR the encoded SenderData with that value. The maske= d sender data replaces the `encrypted_sender_data` and obsoletes `sender_da= ta_nonce`. The PR also specifies that the auth tag should be truncated from= the `ciphertext` because the full MLSCiphertext is now authenticated with = a MAC under a shared key, and this MAC is stored on its own in an `auth_tag= ` field on MLSCiphertext.

The process of masking t= he sender data is designed to match the construction HN1 in [3]. The reason= for messing around with the MAC structure, is that it allows us to validat= e the integrity of the sender data before we use it to generate sender-spec= ific keys, while still only have one MAC total.

On= e of the downsides to this proposal is that it requires two passes over the= ciphertext, since we'd now encrypt and authenticate in separate passes= . While I'd like to get rid of this, I don't think it will be a big= performance issue for implementations.

Feedba= ck welcomed!

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000bb085505ab848bae-- From nobody Tue Jul 28 11:47:38 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 BF4653A0B0A for ; Tue, 28 Jul 2020 11:47:35 -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 ZS8sF1o3_J-u for ; Tue, 28 Jul 2020 11:47:33 -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 908873A0AFA for ; Tue, 28 Jul 2020 11:47:17 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id e5so1637237qth.5 for ; Tue, 28 Jul 2020 11:47:17 -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=zk0Th73kvmVxCYI2zCK41WvkD9HowbIspOjqeZH+zzQ=; b=fd0HyKeTUvQbdyvOcNm5GLUIb4RxQW2dY+00LAKLgPp7QHUEbnN+hXEL+4UqD4IvmQ 4pqYe/zCAo0C9M1hgEmoX9rUxbqc7zaw2qaD+jJJ2L5zp47KRe7gx9PYEQM89j4MSdot VE3Jp3Jih/JHQzFj88wPcQmdOJBk3t0YCDXJwECfFHy5SIIKlYgJ5JMdZFR6t3MQNckn QWytTZ207xPJeqtJF4q5ill4YfAexg3tzcaEPWjVDOxwFPw5JHVSeHUCeu9DUIcZLCcI ZKOst/GYAOUt4i8e4P6dUBHJFEQjnE+kRW/loOk27+/tou031kLa07u7naiQrJuqI/jW iL5Q== 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=zk0Th73kvmVxCYI2zCK41WvkD9HowbIspOjqeZH+zzQ=; b=AVKB0eX8pJxgPcXNMRc+NiPL2zSRgjhnGD/I1tNkPg8g2K9Nfqp/mpnDC25R3x/A06 wF7f9fGekS4m5AnBEgM2wFLoNut67gO19Va5eXQIqBqG6Jk7NSyCdZ+y9EUau+i/BmsZ K1al9bJ5SW5CpsKlu0fapz9IQJMvefLk6wJ+tvi1+3okcUivC1vNDvbNjbROnrXCVCxh zVHZL538V8zPdXUCBNARdv48cIlEhKBQwOivq9bE9PmHiHTM5FE2qP1OAlX3vICMYn+u pMaVL2lInZncnL9szRWAlbpBwbyqI0eBqcH7TA9QSDZV9st9xPHlXuIKy1uVdk956V0e W9ig== X-Gm-Message-State: AOAM531mIuH378bk4pvOx94JkPYzYqiuCOad/SG5RTbeFAcIJ6pJ/nV4 nKgaEUp8JMvyT3Bj9Ovos/jTEYSlRzfh1OvYoui0Lg== X-Google-Smtp-Source: ABdhPJzY2kUR8k2mg/rAC3+EOWZ7BfFbjXS5Rx1oh39CzQ1e5hCGrKcgm3ZbRNT+ZG4l5IqnDK3J2oUKFMG+3m62NOo= X-Received: by 2002:ac8:2a3d:: with SMTP id k58mr27636697qtk.265.1595962036461; Tue, 28 Jul 2020 11:47:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 28 Jul 2020 14:46:46 -0400 Message-ID: To: Brendan McMillion Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000423a3205ab84de5a" Archived-At: Subject: Re: [MLS] Masking sender data 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, 28 Jul 2020 18:47:36 -0000 --000000000000423a3205ab84de5a Content-Type: text/plain; charset="UTF-8" Just to recap the options as I understand them: a) Today: encrypted_sender_data = AEAD(sender_data_key, sender_data_nonce, (groupID, epoch), sender_data) encrypted_content = AEAD(app_key[i][j], app_key[i][j], (groupID, epoch, encrypted_sender_data), content) b) Sample sender data nonce from ciphertext (saves explicit nonce) encrypted_content = AEAD(app_key[i][j], app_nonce[i][j], (groupID, epoch), content) encrypted_sender_data = AEAD(sender_data_key, sample(encrypted_content), (groupID, epoch, encrypted_content), sender_data) c) Drop auth tag from content encryption (saves explicit nonce and content auth tag) encrypted_content = Enc(app_key[i][j], app_nonce[i][j], content) encrypted_sender_data = AEAD(sender_data_key, sample(encrypted_content), (groupID, epoch, encrypted_content), sender_data) Here (c) is meant to be the option Brendan prefers. For me, I think (c) is a step too far. It does result in more savings, but it complicates the story in some other ways: - The authenticity of the ciphertext is dependent on the sender_data_key, not the key from the key schedule. - I'm wary that the deaggregated Encrypt-then-MAC scheme, especially with unrelated keys, will complicate analysis even if it ultimately works. - We now need to define a non-AEAD encryption algorithm in addition to the AEAD. By contrast, the only question with (b) is whether using sample(encrypted_content) as the nonce will cause nonce reuse. That seems easier to reason about, since it should be effectively the same as using a random nonce. So I would propose that we go with (b). --Richard On Tue, Jul 28, 2020 at 2:24 PM Brendan McMillion wrote: > This PR was discussed at IETF 108 this morning, and the one issue that > came up is whether or not we should really truncate the auth tag from the > ciphertext. > > Personally I see no problem with it, as everything in MLSCiphertext is > still authenticated. And with the auth tag truncated, performance-sensitive > applications can optimize away the "second pass" on the ciphertext by using > AES-CTR (or the corresponding unauthenticated cipher mode for their AEAD). > Implementations that don't mind the second pass also have good options, for > example: the same operation used to encrypt (AEAD encrypt and truncate auth > tag), when applied to the ciphertext, returns the plaintext. So the same > code does encryption and decryption. > > I'm curious to hear how others feel > > On Mon, Jul 20, 2020 at 1:02 PM Richard Barnes wrote: > >> Hi Brendan, >> >> Thanks a lot for writing this up! I agree that this addresses the >> authenticity concerns that had been raised on earlier iterations of this >> problem. I've suggested a few corrections and simplifications in the PR. >> >> https://github.com/mlswg/mls-protocol/pull/360#discussion_r457656760 >> >> Either way (what you suggested or with my edits), it's clear that there's >> some non-trivial complexity involved here. Both in terms of getting the >> operations in the right order (content encryption, then sender data >> encryption, and reverse for decryption), and in terms of constructing all >> the different AAD values. So I wonder how people feel about that taking >> that compexity cost in the interest of removing an explicit nonce. >> Personally, I'm probably still inclined to do it, since explicit nonces >> make me nervous, but I would like to hear what other folks think. >> >> --Richard >> >> On Thu, Jul 16, 2020 at 12:31 PM Brendan McMillion > 40cloudflare.com@dmarc.ietf.org> wrote: >> >>> Hello mls@ >>> >>> There's been an open ticket [1] on MLS for a while now to explore >>> masking sender data instead of encrypting it with an AEAD. I opened a PR >>> [2] with an initial attempt to achieve this, which I wanted to now >>> introduce to the list. >>> >>> The first major change is to encrypt the first block of `ciphertext` >>> under a derived key with AES-ECB, and XOR the encoded SenderData with that >>> value. The masked sender data replaces the `encrypted_sender_data` and >>> obsoletes `sender_data_nonce`. The PR also specifies that the auth tag >>> should be truncated from the `ciphertext` because the full MLSCiphertext is >>> now authenticated with a MAC under a shared key, and this MAC is stored on >>> its own in an `auth_tag` field on MLSCiphertext. >>> >>> The process of masking the sender data is designed to match the >>> construction HN1 in [3]. The reason for messing around with the MAC >>> structure, is that it allows us to validate the integrity of the sender >>> data before we use it to generate sender-specific keys, while still only >>> have one MAC total. >>> >>> One of the downsides to this proposal is that it requires two passes >>> over the ciphertext, since we'd now encrypt and authenticate in separate >>> passes. While I'd like to get rid of this, I don't think it will be a big >>> performance issue for implementations. >>> >>> Feedback welcomed! >>> >>> 1. https://github.com/mlswg/mls-protocol/issues/302 >>> 2. https://github.com/mlswg/mls-protocol/pull/360 >>> 3. https://eprint.iacr.org/2019/624.pdf >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>> >> --000000000000423a3205ab84de5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to recap the options as I understand them:
=

a) Today:
=C2=A0 =C2=A0encrypted_sender_data =3D AEA= D(sender_data_key, sender_data_nonce, (groupID, epoch), sender_data)
=C2= =A0 =C2=A0encrypted_content =3D AEAD(app_key[i][j], app_key[i][j], (groupID= , epoch, encrypted_sender_data), content)

b) Sample sender data nonc= e from ciphertext (saves explicit nonce)
=C2=A0 =C2=A0encrypted_content = =3D AEAD(app_key[i][j], app_nonce[i][j], (groupID, epoch), content)
=C2= =A0 =C2=A0encrypted_sender_data =3D AEAD(sender_data_key, sample(encrypted_= content), (groupID, epoch, encrypted_content), sender_data)

c) Drop = auth tag from content encryption (saves explicit nonce and content auth tag= )
=C2=A0 =C2=A0encrypted_content =3D Enc(app_key[i][j], app_nonce[i][j],= content)
=C2=A0 =C2=A0encrypted_sender_data =3D AEAD(sender_data_key, s= ample(encrypted_content), (groupID, epoch, encrypted_content), sender_data)=

Here (c) is meant to be the option Brendan prefer= s.

For me, I think (c) is a step too far.=C2= =A0 It does result in more savings, but it complicates the story in some ot= her ways:
- The authenticity of the ciphertext is dependent on th= e sender_data_key, not the key from the key schedule.
- I'm w= ary that the deaggregated Encrypt-then-MAC scheme, especially with unrelate= d keys, will complicate analysis even if it ultimately works.
- We now need to define a non-AEAD encryption algorithm in addition to the= AEAD.

By contrast, the only question with (b)= is whether using sample(encrypted_content) as the nonce will cause nonce r= euse.=C2=A0 That seems easier to reason about, since it should be effective= ly the same as using a random nonce.

So I would pr= opose that we go with (b).

--Richard
=


On Tue, Jul 28, 2020 at 2:24 PM Brendan McMillion <brendan@cloudflare.com> wrote:<= br>
This PR was discussed at IETF 108 this morning, and the one issue tha= t came up is whether or not we should really truncate the auth tag from the= ciphertext.

Personally I see no problem with it, = as everything in MLSCiphertext is still authenticated. And with the auth ta= g truncated, performance-sensitive applications can optimize away the "= ;second pass" on the ciphertext by using AES-CTR (or the corresponding= unauthenticated cipher mode for their AEAD). Implementations that don'= t mind the second pass also have good options, for example: the same operat= ion used to encrypt (AEAD encrypt and truncate auth tag), when applied to t= he ciphertext, returns the plaintext. So the same code does encryption and = decryption.

I'm curious to hear how others fee= l

On Mon, Jul 20, 2020 at 1:02 PM Richard Barnes <rlb@ipv.sx>= ; wrote:
Hi Brendan,

Thanks a lot for writin= g this up!=C2=A0 I agree that this addresses the authenticity concerns that= had been raised on earlier iterations of this problem.=C2=A0 I've sugg= ested a few corrections and simplifications in the PR.

=

Either way (what you su= ggested or with my edits), it's clear that there's some non-trivial= complexity involved here.=C2=A0 Both in terms of getting the operations in= the right order (content encryption, then sender data encryption, and reve= rse for decryption), and in terms of constructing all the different AAD val= ues.=C2=A0 So I wonder how people feel about that taking that compexity cos= t in the interest of removing an explicit nonce. Personally, I'm probab= ly still inclined to do it, since explicit nonces make me nervous, but I wo= uld like to hear what other folks think.

--Ric= hard

On Thu, Jul 16, 2020 at 12:31 PM Brendan McMillion <bren= dan=3D= 40cloudflare.com@dmarc.ietf.org> wrote:
Hello mls@

There's been an open ticket [1] on MLS for a while now = to explore masking sender data instead of encrypting it with an AEAD. I ope= ned a PR [2] with an initial attempt to achieve this, which I wanted to now= introduce to the list.

The first major change is = to encrypt the first block of `ciphertext` under a derived key with AES-ECB= , and XOR the encoded SenderData with that value. The masked sender data re= places the `encrypted_sender_data` and obsoletes `sender_data_nonce`. The P= R also specifies that the auth tag should be truncated from the `ciphertext= ` because the full MLSCiphertext is now authenticated with a MAC under a sh= ared key, and this MAC is stored on its own in an `auth_tag` field on MLSCi= phertext.

The process of masking the sender data i= s designed to match the construction HN1 in [3]. The reason for messing aro= und with the MAC structure, is that it allows us to validate the integrity = of the sender data before we use it to generate sender-specific keys, while= still only have one MAC total.

One of the downsid= es to this proposal is that it requires two passes over the ciphertext, sin= ce we'd now encrypt and authenticate in separate passes. While I'd = like to get rid of this, I don't think it will be a big performance iss= ue for implementations.

--000000000000423a3205ab84de5a-- From nobody Tue Jul 28 14:37:49 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 CD8E13A08F8 for ; Tue, 28 Jul 2020 14:37:46 -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 AllLd7w_XrlN for ; Tue, 28 Jul 2020 14:37:45 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 EB2763A08E2 for ; Tue, 28 Jul 2020 14:37:44 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id g8so886827wmk.3 for ; Tue, 28 Jul 2020 14:37:44 -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=4D3Dz0HOCA392CvuK26OYpzj2bTaszEGu6jLOVWZpcA=; b=dZuVqZMsM312ZDhel8gLcMdZniT9zj0BzPJdn8Et2eJyaAgeOfKOX1RoC6QGtH4zw0 1ta53rx47wg4nH/PQr0nmf0j8L3xjcz9ec+34r/way47uOp6H8yAWxw93pBxYfJrt7UY 6GnvwetiNIRaaGXqn+MZJnNc/cnf/WUquLxaoFsAP8jXYRMTC4PzOKVGG0BbmmMwmr8W DViY3o1MBoaPknjZYo9p+M9/FIRLgszJb4sKYM+QAQYbZN/rSxe9aMOjkfw7YmOfxf/Q SFKLjmqQ3VKcTzWmqM8ksXXwcz3xI3phwA8O3khmVPlce7xRnlBlVahPnzqk/r/UfArX Vg7A== 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=4D3Dz0HOCA392CvuK26OYpzj2bTaszEGu6jLOVWZpcA=; b=PQ6gsTc+N4mx5tAu041PtOEK5WRzayEf7xeT7B2IcRMyotisxVMqBN93OQbAV1fRo3 04y95XYQeg1sgvVPoKLuxJ/88KBFg9FX86CVM7xGQlUVOSPUSOWT8eTa2/NJSPWb1lGt 4wlq1q4x1fnfjsPf92lbDU2fEhsMrBc450kQes92IrI/YbNE8lHED632r59v2+N9x1AR hoU84DhUiT9DOqHVfc6PE5mZ4GXe2Cu4GVq5ccd9fIDQefQLYhWMk89vznMueLPB2NBt 9j8cuAM23z9/WE0H0vWupYfYYjZrv5OfNYeR+SpoWlEj9iDbcH0+xurmDNFHnlpsWmMF vjNw== X-Gm-Message-State: AOAM530zpgHDUQr6eQQ2/UwzKecYnI88qvyWSs2h/nRWS4Qd+68hBg9V KBIM5LdO+Y7EJfMAJIw3fDSt5owc3kCKGYGZesY= X-Google-Smtp-Source: ABdhPJwPxYv3UY5NW6NW6pdE7JH80237cRU+4pkAcrAqTZ1OuLNRGOCbs5pF2QzATPk4/ih76XH27HoMEWGWluGZ338= X-Received: by 2002:a05:600c:21c2:: with SMTP id x2mr5962850wmj.142.1595972263175; Tue, 28 Jul 2020 14:37:43 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: From: Chelsea Komlo Date: Tue, 28 Jul 2020 15:37:29 -0600 Message-ID: To: Brendan McMillion Cc: Richard Barnes , "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d1694105ab873f3a" Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 21:37:48 -0000 --000000000000d1694105ab873f3a Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 8:11 AM Brendan McMillion wrote: > But in the former class, you would be forcing the application to invent >> its own scheme for signaling this stuff, which risks them making decisions >> that are suboptimal for metadata privacy. > > > Making a metadata-resistant deployment of MLS would already be incredibly > difficult because you'd have to design your application to use the network > in a way that prevents useful traffic analysis. Someone who's capable of > this should definitely be capable of choosing how messages are identified > in their system. > While the network layer would need to protect against network-level traffic analysis such as timing and frequency fingerprinting, this can be done in a generalized way that is agnostic to the application (such as if a mix network were used to route traffic between the client and the DS). Ideally, MLS as a higher-level application would not leak additional information when it is received by the DS after having been sent through such a network. > The flip side, is that your construction is already suboptimal for > metadata privacy because the epoch id only changes once per epoch. In the > construction that I described, the opaque identifier changes with each > message. You could also imagine a system where the identifier would change > with time instead of with protocol messages (for example, where messages > are distributed over Tor circuits). > It is true that message fields should be bitwise unlinkable to a network observer (see [1] for more information on how this property is instantiated in routing protocols). Time can be a dangerous dependency in distributed systems though, so I would be careful there. [1] https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf --000000000000d1694105ab873f3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2020 at 8:11 AM Brendan M= cMillion <brendan=3D4= 0cloudflare.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">But in the former class, y= ou would be forcing the application to invent=20 its own scheme for signaling this stuff, which risks them making=20 decisions that are suboptimal for metadata privacy.

Making a metadata-resistant deployment of MLS would already be inc= redibly difficult because you'd have to design your application to use = the network in a way that prevents useful traffic analysis. Someone who'= ;s capable of this should definitely be capable of choosing how messages ar= e identified in their system.

While the network layer would need to protect against network-level traf= fic analysis such as timing and frequency fingerprinting, this can be done = in a generalized way that is agnostic to the application (such as if a mix = network were used to route traffic between the client and the DS). Ideally,= MLS as a higher-level application would not leak additional information wh= en it is received by the DS after having been sent through such a network.= =C2=A0


The flip side, is that yo= ur construction is already suboptimal for metadata privacy because the epoc= h id only changes once per epoch. In the construction that I described, the= opaque identifier changes with each message. You could also imagine a syst= em where the identifier would change with time instead of with protocol mes= sages (for example, where messages are distributed over Tor circuits).
<= /div>

It is true that message fields = should be bitwise unlinkable to a network observer (see [1] for more inform= ation on how this property is instantiated in routing protocols). Time can = be a dangerous dependency in distributed systems though, so I would be care= ful there.=C2=A0


--000000000000d1694105ab873f3a-- From nobody Tue Jul 28 15:05: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 6E13F3A09FC for ; Tue, 28 Jul 2020 15:05:13 -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=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 vhCSotIgGx_O for ; Tue, 28 Jul 2020 15:05:11 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4103A08AE for ; Tue, 28 Jul 2020 15:05:11 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id b25so16148607qto.2 for ; Tue, 28 Jul 2020 15:05:11 -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=L2I0nABi1Sd0RPQbpYKIgdQOjzQPkPJJT1XTN00RcsI=; b=sKCrF6UUICHJcjhqZpFKibqn809lDj4nc73XS4PGEpqTrEqZCGLkd7ioFfRoKNz8eU IvQe+wxzwbUEboWWuOaRGlXj8q42LFyIuq1uG8mepDl/iJlf50gqxSV4+nZ3jSpFs2eL PO8HWZ18q/0sA7U8s6R13MCG7+GFd1L7qO7L0= 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=L2I0nABi1Sd0RPQbpYKIgdQOjzQPkPJJT1XTN00RcsI=; b=o4O/HY5eCAt/owP0n/hL9hHzGF4dbi+r6GKPvdhwAJZPrH+9ERaCYsCM3epOA4MqM3 As1PdvnXkggx3UVyJvWfn1dTZWZFE0B3J1Mr9K6DH48PycmX9iIZXWZ/nY8GrdxOUR1O MstO6UgiKYL6Env7OjwPIp2sesxI+diFG/pJo3TRAQqRbaykDW8JLVrFaJJ7DanuIAH5 pZva37/K745gH+wNXhesYBm1lK5QoHLmM+m+OrjnmqKkOYv5PZKjkc+7pnck4Dq3IjHr GGY/JtAb3jtmyKgyCVl1aGHl3LUxeb3VENAq0SzQ6941lnc0AWDC4xhdj6EBFl/K3IGm wGOg== X-Gm-Message-State: AOAM532upU3OfVoa6/8KQ4CW3dRjOpmS2RqTKBKrMRN4xjLFNKz8lNm7 ZDX7r4Pw0j2PeaVKIVvsqBgq26xciWQ9JsL6EkcFEg== X-Google-Smtp-Source: ABdhPJwax9V3IkDyvaUg5+ZsskpH8fs7oeF2KaAYPpg9S5ErGUtdufEBUQ5jGcf/QVTRj3NICLNdwYjGprD7wRg7qmU= X-Received: by 2002:aed:27d5:: with SMTP id m21mr29984878qtg.4.1595973910099; Tue, 28 Jul 2020 15:05:10 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: From: Brendan McMillion Date: Tue, 28 Jul 2020 15:04:59 -0700 Message-ID: To: Chelsea Komlo Cc: Richard Barnes , "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000fbaa2d05ab87a193" Archived-At: Subject: Re: [MLS] Hiding content type 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, 28 Jul 2020 22:05:16 -0000 --000000000000fbaa2d05ab87a193 Content-Type: text/plain; charset="UTF-8" > > While the network layer would need to protect against network-level > traffic analysis such as timing and frequency fingerprinting, this can be > done in a generalized way that is agnostic to the application (such as if a > mix network were used to route traffic between the client and the DS). In the specific case of a mix network, that's not true. The DS has at least these variables for traffic analysis: 1. Messages which are requested in quick succession (associating messages that are requested together with the same group) 2. How many times a message is requested (associating a message with the number of participants in the group it was sent to) 3. Messages requested over the same circuit (Tor and similar networks often reuse circuits for efficiency) and may have more depending on context. On Tue, Jul 28, 2020 at 2:37 PM Chelsea Komlo wrote: > On Tue, Jul 28, 2020 at 8:11 AM Brendan McMillion 40cloudflare.com@dmarc.ietf.org> wrote: > >> But in the former class, you would be forcing the application to invent >>> its own scheme for signaling this stuff, which risks them making decisions >>> that are suboptimal for metadata privacy. >> >> >> Making a metadata-resistant deployment of MLS would already be incredibly >> difficult because you'd have to design your application to use the network >> in a way that prevents useful traffic analysis. Someone who's capable of >> this should definitely be capable of choosing how messages are identified >> in their system. >> > > While the network layer would need to protect against network-level > traffic analysis such as timing and frequency fingerprinting, this can be > done in a generalized way that is agnostic to the application (such as if a > mix network were used to route traffic between the client and the DS). > Ideally, MLS as a higher-level application would not leak additional > information when it is received by the DS after having been sent through > such a network. > > >> The flip side, is that your construction is already suboptimal for >> metadata privacy because the epoch id only changes once per epoch. In the >> construction that I described, the opaque identifier changes with each >> message. You could also imagine a system where the identifier would change >> with time instead of with protocol messages (for example, where messages >> are distributed over Tor circuits). >> > > It is true that message fields should be bitwise unlinkable to a network > observer (see [1] for more information on how this property is instantiated > in routing protocols). Time can be a dangerous dependency in distributed > systems though, so I would be careful there. > > [1] https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf > > --000000000000fbaa2d05ab87a193 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While th= e network layer would need to protect against network-level=20 traffic analysis such as timing and frequency fingerprinting, this can=20 be done in a generalized way that is agnostic to the application (such=20 as if a mix network were used to route traffic between the client and=20 the DS).

In the specific case of a mix net= work, that's not true. The DS has at least these variables for traffic = analysis:

1. Messages which are requested in quick= succession (associating messages that are requested together with the same= group)
2. How many times a message is requested (associating a m= essage with the number of participants in the group it was sent to)
3. Messages requested over the same circuit (Tor and similar networks of= ten reuse circuits for efficiency)

and may have mo= re depending on context.

On Tue, Jul 28, 2020 at 2:37 PM Chelsea K= omlo <chelsea.komlo@gmail.com= > wrote:
=
On Tue, Jul 28, 2020 at 8:11 AM Brendan M= cMillion <brendan=3D40cloudflare.com@dmarc.ietf.org> wrote:
=
But in t= he former class, you would be forcing the application to invent=20 its own scheme for signaling this stuff, which risks them making=20 decisions that are suboptimal for metadata privacy.

Making a metadata-resistant deployment of MLS would already be inc= redibly difficult because you'd have to design your application to use = the network in a way that prevents useful traffic analysis. Someone who'= ;s capable of this should definitely be capable of choosing how messages ar= e identified in their system.

While the network layer would need to protect against network-level traf= fic analysis such as timing and frequency fingerprinting, this can be done = in a generalized way that is agnostic to the application (such as if a mix = network were used to route traffic between the client and the DS). Ideally,= MLS as a higher-level application would not leak additional information wh= en it is received by the DS after having been sent through such a network.= =C2=A0


The flip side, is that yo= ur construction is already suboptimal for metadata privacy because the epoc= h id only changes once per epoch. In the construction that I described, the= opaque identifier changes with each message. You could also imagine a syst= em where the identifier would change with time instead of with protocol mes= sages (for example, where messages are distributed over Tor circuits).
<= /div>

It is true that message fields = should be bitwise unlinkable to a network observer (see [1] for more inform= ation on how this property is instantiated in routing protocols). Time can = be a dangerous dependency in distributed systems though, so I would be care= ful there.=C2=A0


--000000000000fbaa2d05ab87a193-- From nobody Tue Jul 28 17:11: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 DA2A03A0C70 for ; Tue, 28 Jul 2020 17:11:42 -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 jSxjlK6o5yHt for ; Tue, 28 Jul 2020 17:11:41 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 AE8903A0C6F for ; Tue, 28 Jul 2020 17:11:40 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 9so1106241wmj.5 for ; Tue, 28 Jul 2020 17:11:40 -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=UKXISD45bDNsPtSCdLkZEvkMfiWsmzzi7/jrtSEMM/g=; b=Me6i8rxCCLMVD7WUQwFfQwyARFVbb/Jr0oYcXYUEsHmu4UIf4Mj0OQJKWuegdxlRql EVCxn/lRPaP+/FoIcXsMqJtcHl4Ph/V1Lw+OgFmUfh9P46sDr0cNY6LE9jLz0f3/6fGx dxFlIhrpBEP5HiBg+JuCNVz+Qb8RWR5uTtkTcA/hszs21SYwz4b1jiRZZXyi9cWM5xqj yFbswdAYZVuxzbv1CNCgXJpZfHB0SNMnE7JhLcfS55vSxmFv9lm9Uf6B5rZFehiZghe/ RWk5XnkPyzcrQsw0irPoR6FkfsRnkDiIQc78Yz0CUdb3BxgjKgJxwrMVUT2eKuI6YExN 8Svw== 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=UKXISD45bDNsPtSCdLkZEvkMfiWsmzzi7/jrtSEMM/g=; b=NxrfAzUqkcVvZhkQcWlDOb5ZJ2oPsPGZud34AIBZDjE3LhLDiOven2X6lHJzpsuxrC pQSNw4m2XPS7gerWXx6232ytiiRO1LzUBgarZnDfDVWiIbhIGCzT7WzcVqdL6FOHh911 KAlQS8+XBwCsxsv3F0AVAqK1mCZM7b7mo7xmhjkndyDA1GEWNPPf2bTpZO/OrWI4uby3 Xeryqye2mDBs7BSGAQK9y4yiOMMP/mUstfg563eS8iMgmhuEeBF7nyLZAcHmWgH96Q6a GQvQ6ILaDLQ5okBBXfRJi37w1LnOiT5gMzArrkvtc/7AdAdhBkT86gKfhCPT7Lg4HL3n t0jA== X-Gm-Message-State: AOAM5329JlkA+QhRjV6SadFmNkOARtW261dcMs1NR6hxTEFGBowh+75m icYex5CCfs3FMOmi8+G+W+T5pKr2WI112jOcSDs= X-Google-Smtp-Source: ABdhPJxy75z/jETBrpGC0Eog7+NV5HAOdlBktgg0JlzgL5AD3EppT71vt5B1ELOcd7lrlwPTcmFlkpNM8IDBn3dub8I= X-Received: by 2002:a05:600c:2157:: with SMTP id v23mr5832454wml.38.1595981498235; Tue, 28 Jul 2020 17:11:38 -0700 (PDT) MIME-Version: 1.0 References: <56633046-DB4C-4EE8-A83B-E88A4F430171@cloudflare.com> In-Reply-To: From: Chelsea Komlo Date: Tue, 28 Jul 2020 18:11:25 -0600 Message-ID: To: Brendan McMillion Cc: Richard Barnes , "Hale, Britta (CIV)" , Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000453e7c05ab8966ef" Archived-At: Subject: Re: [MLS] Hiding content type 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, 29 Jul 2020 00:11:43 -0000 --000000000000453e7c05ab8966ef Content-Type: text/plain; charset="UTF-8" I realize this is off topic to the discussion of hiding content type/epoch ids in MLS, but addressing the below for completeness. I'm happy to continue this discussion in a separate thread if there is further interest. On Tue, Jul 28, 2020 at 4:05 PM Brendan McMillion wrote: > While the network layer would need to protect against network-level >> traffic analysis such as timing and frequency fingerprinting, this can be >> done in a generalized way that is agnostic to the application (such as if a >> mix network were used to route traffic between the client and the DS). > > > In the specific case of a mix network, that's not true. The DS has at > least these variables for traffic analysis: > > 1. Messages which are requested in quick succession (associating messages > that are requested together with the same group) > The DS can observe access patterns, but the important point is whether it can then use that information to deanonymize users. In a mix network instantiated with protocols like Loopix [1], users generate and send dummy packets (i.e, cover traffic that is dropped at random points in the network) along with real packets, all which are delayed by some random time period at each hop in the path. So performing end-to-end correlation attacks in such systems is harder. However, even when Tor is used, the question is at what point the DS *can* learn enough to deanonymize users if it can only observe access patterns and any exposed metadata (assuming it cannot perform end-to-end correlation attacks). See next. > 2. How many times a message is requested (associating a message with the > number of participants in the group it was sent to) > Note this problem of access pattern observability is not unique to MLS and without the use of PIR, access patterns will be observable by any content provider even when traffic is routed through an anonymity network. > 3. Messages requested over the same circuit (Tor and similar networks > often reuse circuits for efficiency) > This is only an issue in circuit-switched networks like Tor (where users maintain a long-lived connections), whereas mix networks like Loopix are packet-switched, meaning every message is routed independently. Further, applications using Tor can rotate through circuits more quickly, if desired (Tor Browser does this). [1] https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/piotrowska --000000000000453e7c05ab8966ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I realize this is off topic to the discussion of hidi= ng content type/epoch ids in MLS, but addressing the below for completeness= . I'm happy to continue this discussion in a separate thread if there i= s further interest.

On Tue, Jul 28, 2020 at 4:05 PM Brendan McMillion <brendan@cloudflare.com> wrot= e:
While the network lay= er would need to protect against network-level=20 traffic analysis such as timing and frequency fingerprinting, this can=20 be done in a generalized way that is agnostic to the application (such=20 as if a mix network were used to route traffic between the client and=20 the DS).

In the specific case of a mix net= work, that's not true. The DS has at least these variables for traffic = analysis:

1. Messages which are requested in quick= succession (associating messages that are requested together with the same= group)

The DS can observe acce= ss patterns, but the important point is whether it can then use that inform= ation to deanonymize users.=C2=A0

In a mix network= instantiated with protocols like Loopix [1], users generate and send dummy= packets (i.e, cover traffic that is dropped at random points in the networ= k) along with real packets, all which are delayed by some random time perio= d at each hop in the path. So performing end-to-end correlation attacks in = such systems is harder.

However, even when Tor is = used, the question is at what point the=C2=A0DS *can* learn enough to deano= nymize users if it can only observe access patterns and any exposed metadat= a (assuming it cannot perform end-to-end correlation attacks). See next.
=C2=A0
2. How many times a message is requested (associating a me= ssage with the number of participants in the group it was sent to)

Note this problem of access pattern obs= ervability is not unique to MLS and without the use of PIR, access patterns= will be observable by any content provider even when traffic is routed thr= ough an anonymity=C2=A0network.
=C2=A0
3. Messages requested ov= er the same circuit (Tor and similar networks often reuse circuits for effi= ciency)

This is only an issue i= n circuit-switched networks like Tor (where users maintain a long-lived con= nections), whereas mix networks like Loopix are packet-switched, meaning ev= ery message is routed independently. Further, applications using Tor can ro= tate through circuits more quickly, if desired (Tor Browser does this).

--000000000000453e7c05ab8966ef-- From nobody Thu Jul 30 00:49:24 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 BE5AF3A0F66 for ; Thu, 30 Jul 2020 00:49:21 -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 mcl3RiTDsy8h for ; Thu, 30 Jul 2020 00:49:18 -0700 (PDT) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [IPv6:2001:67c:2050::465:201]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765FB3A0F62 for ; Thu, 30 Jul 2020 00:49:17 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4BHMxR3ZMhzQlWK for ; Thu, 30 Jul 2020 09:49:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id DwXGjDVjH2Y4 for ; Thu, 30 Jul 2020 09:49:10 +0200 (CEST) To: mls@ietf.org References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <5754afd7-f05f-2844-5656-4f4572b49fab@aalto.fi> <0c22bb51-6ef2-a55c-0c3a-14e0b590d7c7@aalto.fi> <064ad211-9f5f-7254-aa48-d7aea0ca2c7f@aalto.fi> From: Konrad Kohbrok Message-ID: <6d0b0e16-88a9-96c6-cb45-96262c61f337@datashrine.de> Date: Thu, 30 Jul 2020 09:49:09 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-MBO-SPAM-Probability: 0 X-Rspamd-Score: -6.43 / 15.00 / 15.00 X-Rspamd-Queue-Id: 24B2217AB X-Rspamd-UID: 55ec65 Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 30 Jul 2020 07:49:22 -0000 Hi Richard, Is there a particular reason why the PSK has to be announced inside of the GroupInfo object? This significantly weakens the authentication guarantees we get from the PSK. A member that does not know the PSK can now decrypt the GroupInfo object and learn, for example, about the group composition, group id, epoch, etc. Our original proposal in #336 was suggesting to put the PSKId into the GroupSecrets object and I don't see what we gain by having it in the GroupInfo object instead. From what I can see it only weakens security and makes the key schedule design more awkward. Regarding efficiency: As Chris remarked, the GroupSecrets object is encrypted under a single symmetric key for all members just as the GroupInfo object, isn't it? Cheers, Konrad On 25.07.20 23:14, Richard Barnes wrote: > Think about the order of operations a new joiner goes through: > > 1. Decrypt the EncryptedGroupSecrets (including the joiner_secret) using the > relevant HPKE private key > 2. Compute the welcome_secret, welcome_key, and welcome_nonce > 3.. Decrypt the GroupInfo using the welcome_key and welcome_nonce > > My presumption is that the joiner will only know that it needs the PSK after > step 3, when it can read the GroupInfo extensions.  (See > https://github.com/mlswg/mls-protocol/issues/367)  That means that the > welcome_secret can't depend on the PSK. > > On Sat, Jul 25, 2020 at 4:09 PM Chris Brzuska > wrote: > > Hi Richard, > > I have a quick question: An additional change in your key schedule is that > the welcome_secret is now derived *before* including the PSK. What is the > motivation behind this? > > Thanks! > > Chris > > On 24/07/2020 22:18, Chris Brzuska wrote: > >> I see, thanks for clarifying. Obviously, with these requirements, pull >> request #336 does not work as is. I think that the conceptual issue of how >> to best combine two, three keys and more keys, remains, now with an >> additional requirement to combine two keys separately first. >> >> Will think about it, thanks for clarifying the requirements! >> >> Chris >> >> On 24/07/2020 21:47, Richard Barnes wrote: >>> Your confusion is understandable -- the document is wrong right now!  You >>> are correct that the current design prohibits new joiners from >>> participating in the PSK proof, but that's a bug, not a feature.  The >>> epoch secret should verify that *all members of the current epoch* know >>> the PSK, not just the ones inherited from the last epoch. >>> >>> That's why #362 rearranges the key schedule as follows: >>> >>>                   init_secret_[n-1] (or 0) >>>                         | >>>                         V >>>    commit_secret -> HKDF-Extract = joiner_secret >>>                         | >>>                         +--> Derive-Secret(., "welcome") >>>                         |    = welcome_secret >>>                         | >>>                         V >>>       PSK (or 0) -> HKDF-Extract = member_secret >>>                         | >>>                         V >>> GroupContext_[n] -> HKDF-Extract = epoch_secret >>> >>> (I also promoted the GroupContext to the main key schedule.)  That's the >>> context for my earlier comments..  With that picture, the only thing >>> you're coalescing with nPRF would be the latter two HKDF-Extract calls. >>> >>> Hope that helps, >>> --Richard >>> >>> >>> >>> On Fri, Jul 24, 2020 at 2:32 PM Chris Brzuska >> > wrote: >>> >>> Hey Richard, >>> >>> thank you for looking into this. I think, I need more explanation to >>> understand the following point: >>> >>> >>>  You can't add the commit secret and PSKs in the same operation, >>> because you want new joiners to put in the PSK, but you don't want >>> them to have to know the commit secret. >>> >>> The current draft sais the following about the PSK: >>> "Groups which already have an out-of-band mechanism to generate >>> *shared* group secrets can inject those in the MLS key schedule to >>> seed the MLS group secrets computations by this external entropy. At >>> any epoch, including the initial state, an application can decide to >>> synchronize the injection of a PSK into the MLS key schedule. This >>> mechanism can be used to improve security in the cases where having a >>> full run of updates across members is too expensive or in the case >>> where the external group key establishment mechanism provides >>> stronger security against classical or quantum adversaries." >>> >>> As I understand this paragraph, the PSK is known by all group members >>> and not related to new joiners. Maybe, the requirements and/or design >>> changed in the meanwhile, and I am not aware of it. I interpreted the >>> paragraph this way, since the current construction (posted below for >>> convenience) also requires to know the commit_secret to derive the >>> epoch_secret (from which the welcome_secret is derived). Where did I >>> go wrong? >>> >>> Thanks! >>> >>> Chris >>> >>> init_secret_[n-1] (or 0) >>> | >>> V >>> PSK (or 0) -> HKDF-Extract = early_secret >>> | >>> Derive-Secret(., "derived", "") >>> | >>> V >>> commit_secret -> HKDF-Extract = epoch_secret >>> >>> >>> On 24/07/2020 20:53, Richard Barnes wrote: >>>> Hey Chris, >>>> >>>> I was looking again at the key schedule as I was drafting #362 [1].  >>>> A couple of things occurred to me: >>>> >>>> 1. You can't add the commit secret and PSKs in the same operation, >>>> because you want new joiners to put in the PSK, but you don't want >>>> them to have to know the commit secret. >>>> >>>> 2. The nPRF construction you propose has the same number of HMAC >>>> invocations as the chained-HKDF-Extract stuff that's in the current >>>> draft / 362. >>>> >>>> Given those observations, I wonder how much an nPRF is really buying >>>> us.  It's not saving us any HMAC calls, and relative to #362, it >>>> would only coalesce two DPRF calls into one nPRF call. >>>> >>>> Maybe there's some benefit if there are multiple PSKs?  But even >>>> then, it seems like you could add a layer, computing a synthetic PSK >>>> from the multiple ones, and keeping the main key schedule simple. >>>> >>>> At this point, given the above and the novelty of the nPRF >>>> construction, I'm inclined to just stick with HKDF and merge #362 >>>> instead of #336. >>>> >>>> --Richard >>>> >>>> >>>> [1] https://github.com/mlswg/mls-protocol/pull/362 >>>> >>>> On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska >>> > wrote: >>>> >>>> Thank you for the pointer to Carter-Wegman MACs. >>>> >>>> >>> This style of combing hash outputs does affect collision >>>> resistance [4], and some discussion on relation to that would be >>>> nice to see. >>>> >>>> That's an excellent point. In addition to pseudorandomness, we >>>> prove the collision-resistance of our construction. I.e., >>>> assuming that no unique value is used twice and assuming that >>>> HMAC is collision-resistance, then the final Expand operation >>>> guarantees unique outputs. I.e., by including the unique value >>>> into the final Expand operation after the xor, the construction >>>> recovers from any collisions incurred by the xor. >>>> >>>> Chris >>>> >>>> On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >>>>> >>>>> This is an interesting proposal. It is closely related at a >>>>> high level to Carter-Wegman MACs (i.e. for random seed r, >>>>> MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few >>>>> MACs fall into this category in practice. Considering the use >>>>> of a MAC-based KDF and the proofs of [3] on DPRFs, there is an >>>>> overlap between NPRFs and extrapolation of the above (based on >>>>> iteration of the PRF guarantees). >>>>> >>>>>   >>>>> >>>>> This is worth noting from an assurance standpoint: there was >>>>> discussion at the virtual interims with respect to the current >>>>> formulation of MLS key derivation, which has a “TLS >>>>> precedence”, yet this proposal is not without precedence >>>>> itself. Ergo, such a change should not necessarily be >>>>> concerning based on differing from current practice. >>>>> >>>>>   >>>>> >>>>> This style of combing hash outputs does affect collision >>>>> resistance [4], and some discussion on relation to that would >>>>> be nice to see. >>>>> >>>>>   >>>>> >>>>> Britta >>>>> >>>>>   >>>>> >>>>>   >>>>> >>>>>   >>>>> >>>>> [1] Carter, Wegman. Universal classes of hash functions. >>>>> >>>>> [2] Carter, Wegman. New hash functions and their use in >>>>> authentication and set equality. >>>>> >>>>> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from >>>>> Standard Assumptions: A Generic Validation of an HMAC Assumption. >>>>> >>>>> [4] Bernstein. What output size resists collisions in a xor of >>>>> independent expansions? >>>>> >>>>>   >>>>> >>>>>   >>>>> >>>>>   >>>>> >>>>> *From: *MLS >>>>> on behalf of Chris Brzuska >>>>> >>>>> *Date: *Tuesday, June 9, 2020 at 10:32 AM >>>>> *To: *"mls@ietf.org" >>>>> >>>>> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input >>>>> PRF (NPRF) >>>>> >>>>>   >>>>> >>>>> Hi all, >>>>> >>>>> I would like to open a discussion on a suggestion for a change >>>>> in the key schedule. In the current draft, we use the Extract >>>>> function twice as a dual pseudorandom function (DPRF) when >>>>> combining 3 keys (*) and interleave them with an Expand call. >>>>> >>>>> The suggestion [1] is to replace these 3 calls by a multi-input >>>>> PRF (NPRF) which is especially designed to return a >>>>> pseudorandom key when at least one of the input keys is >>>>> pseudorandom. The new suggestion relies on standard PRF >>>>> security rather than DPRF-security of Extract. >>>>> >>>>> You can find the accompanying paper with pictures, discussion >>>>> and security reduction for the design principle here [2]. I >>>>> include a summary of the main points in the end of this eMail. >>>>> >>>>> Please comment/share your opinion. Thanks! >>>>> >>>>> Chris >>>>> >>>>> (*) commit_secret, PSK and init_secret >>>>> >>>>> [1] Pull Request:https://github.com/mlswg/mls-protocol/pull/337 >>>>> >>>>> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >>>>> >>>>> *--------------------------------------------------------------------------------------------------------------------* >>>>> >>>>> *Summary of main points:* >>>>> >>>>> The current key schedule >>>>> - uses Extract as a dual pseudorandom function and assumes that >>>>> HMAC is a dual pseudorandom function >>>>> - applies Extract after Expand, i.e., after applying a function >>>>> which generates a pseudorandom value >>>>> - iterates Extract-then-Expand sequentially to combine more >>>>> than 2 keys >>>>> >>>>> The pull request suggests to >>>>> - replace the ad-hoc assumption that Extract is a dual >>>>> pseudorandom function >>>>> - remove Extract steps when applied after Expand >>>>> - use a provably secure NPRF construction which allows to >>>>> combine more than 2 keys and is based on a standard PRF >>>>> assumption and statistical properties of xor. >>>>> >>>>> Efficiency: >>>>> - The suggested construction has higher parallel efficiency. It >>>>> increases the overall number of HMAC evaluations by 1. >>>>> >>>>> Assumptions: >>>>> - HMAC is a standard PRF. >>>>> - Relies on a unique value, the group_context was suggested. >>>>> >>>>> Construction: >>>>> (1) Use unique value to expand each key and xor the result >>>>> (2) expand resulting key, including unique value into the >>>>> context again >>>>> >>>>> Security argument: >>>>> - Pseudorandomness: unique value ensures that each outcome of >>>>> Expand in (1) is used only once in a xor combination, thus >>>>> allowing on one-time pad argument of xor. >>>>> - Uniqueness of resulting keys: (2) ensures that if HMAC is >>>>> collision-resistent, then the result is collision-resistent. >>>>> >>>>> Variants: >>>>> - It is possible to use an NPRF variant called NameNPRF [2] >>>>> which has 3 HMAC evaluations more and relies less on the unique >>>>> value. I.e., NameNPRF is secure in the same scenarios as DPRF: >>>>> Keys only repeat if the input keys repeat *and* the group >>>>> context repeats. >>>>> >>>>> Questions/Comments that came up: >>>>> - Barnes, MacMillion suggested group_context as unique value >>>>> - MacMillion wondered about removal of Extract: One can add an >>>>> extract operation for the psk. For other input keys, it does >>>>> not seem needed, since they were returned from Expand. >>>>> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For >>>>> uniqueness of output keys, the PRF needs to be >>>>> collision-resistant, too. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Fri Jul 31 00:22: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 341D33A0EA7 for ; Fri, 31 Jul 2020 00:22:15 -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 (2048-bit key) header.d=aalto.fi 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 HG_uH3ePTeE9 for ; Fri, 31 Jul 2020 00:22:13 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (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 7F4AB3A0EF1 for ; Fri, 31 Jul 2020 00:22:12 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 32429115638_F23C69DB for ; Fri, 31 Jul 2020 07:22:05 +0000 (GMT) Received: from exng2.org.aalto.fi (exng2.org.aalto.fi [130.233.223.21]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id 0A8DF1155B6_F23C69DF for ; Fri, 31 Jul 2020 07:22:05 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng2.org.aalto.fi (130.233.223.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 10:22:04 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 10:22:04 +0300 From: Chris Brzuska To: Messaging Layer Security WG Message-ID: Date: Fri, 31 Jul 2020 10:22:05 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng1.org.aalto.fi (130.233.223.20) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=from:subject:to:message-id:date:mime-version:content-type:content-transfer-encoding; s=its18; bh=gnoQHfYLbAZljJ6iBiYstFlePaWmXRazVHd+abjAjXc=; b=C82kL1fnJL2VmkDOi4a4r1xeb4lbR9dmKeORbvHUTdvdbnyqnND7jqRs34GAyHChbXOwImnOPm1mni7jM5yCnQqgvbLBu6kuwwvEAGIVW4UU1r9JYcIE7Ahxukh3Q3iHHtwB4CMyB6daUyz8fmWXfJ2NgSGacjw2Vf0RLXG7BTMTfgSJRdaSrYqVlL8iJtOabc+d07kk2cF/zd5g81jGPe7zclg1mazOgy/2XIVynAM7fP+9SBleDQpkyQ0bcCfQGpFAPHUiLwdN5zZbVHKzye0872zTdU2DBdNHuK5LNdkAwSB78LlostlEEgXJWhbXG7HreyHmjHicdzqai61nDg== Archived-At: Subject: [MLS] welcome_secret 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, 31 Jul 2020 07:22:15 -0000 Hi all, I think that the current derivation of the welcome_secret (used to encrypt the Group_Info) performs additional operations which are not needed, and its use is not optimal from a security perspective (and not necessary from an efficiency perspective). In the current version, we encrypt the joiner_secret (without PSK) and then derive the welcome_secret from the joiner-secret. Case 1: If the welcome_secret is not derived from the PSK, then one can use the same symmetric-key for encrypting the Group_Info than for encrypting the Group_Secrets. There is no efficiency loss, since for all new members, the same symmetric key for encrypting the Group_Secrets is used. In the case that the welcome_secret does not depend on the PSK, it is not needed at all. Disadvantage of this: The PSK does not protect the GroupInfo, as mentioned by Konrad. Additional Disadvantage of current version: Performs additional unnecessary key derivations which do not add security/efficiency. Case 2: If we want to make the welcome_secret depend on the PSK, we do not need to make it depend on the group_secrets. Making the welcome_secret depend on the group_secrets does not add any security. Instead, we only need to derive it from the PSK and the symmetric-key which was sent to all group members. In this case, it makes sense that both, the Group_Secrets and the Group_Info will be encrypted with the same key rather than different keys. In this case, both the Group_Secrets and the Group_Info will be protected by the combination of PSK knowledge and knowing the secret-key for the PKE. Advantage of this: The PSK protects both the GroupInfo and the GroupSecrets. Chris From nobody Fri Jul 31 00:22: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 5CC093A1025 for ; Fri, 31 Jul 2020 00:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=aalto.fi 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 qIFtXpmIKzhn for ; Fri, 31 Jul 2020 00:22:17 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) (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 053013A0EA7 for ; Fri, 31 Jul 2020 00:22:16 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7E8A1271590_F23C6A2B for ; Fri, 31 Jul 2020 07:22:10 +0000 (GMT) Received: from exng1.org.aalto.fi (exng1.org.aalto.fi [130.233.223.20]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng1.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id 0680F27158E_F23C6A2F for ; Fri, 31 Jul 2020 07:22:10 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng1.org.aalto.fi (130.233.223.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 10:22:09 +0300 Received: from [192.168.1.116] (130.233.0.5) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 31 Jul 2020 10:22:09 +0300 To: References: <682de0fe-41c2-9b96-067b-6cb4b08e1e7c@aalto.fi> <7028_1594089739_5F03E109_7028_154_1_B0D017EB-1A15-4C96-84C8-1E202A5A51EF@nps.edu> <4ceb1790-ef66-0113-0f59-023ab1e713e7@aalto.fi> <21383_1595613267_5F1B2052_21383_1688_1_CAL02cgTLkZrUBAD3LLKtgwfg+eNZKWMn0qEJ7=H98pRM=gzYxQ@mail.gmail.com> From: Chris Brzuska Message-ID: <176aefff-5394-b496-d649-fb7d4e430847@aalto.fi> Date: Fri, 31 Jul 2020 10:22:10 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <21383_1595613267_5F1B2052_21383_1688_1_CAL02cgTLkZrUBAD3LLKtgwfg+eNZKWMn0qEJ7=H98pRM=gzYxQ@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------709A1B6E95C1F3E66A856F75" Content-Language: en-GB X-Originating-IP: [130.233.0.5] X-ClientProxiedBy: exng4.org.aalto.fi (130.233.223.23) To exng6.org.aalto.fi (130.233.223.25) X-SASI-RCODE: 200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aalto.fi; h=subject:to:references:from:message-id:date:mime-version:in-reply-to:content-type; s=its18; bh=LhOuEVVoK6G8bMPN59At6s2rDacvfwXIG6CL/pf2pp8=; b=twPLf1qM12eo0FJI3+y+/UhwvPDW4s5SJ6YgT/yCm1gLX95YaeXvtnYrf4VYldLap64bw64CbHLImEeD+v90p985RWoJiqQPM/woTsdbKAgbs3Gpscyeq1nr/Tn6rJzSLX3AdhMR8AXD/bN8DCWi/JAxOHjldiwNjzpT4CDnO2+AQrGnZwOB7XSpCYB3W1RZanvhE/0gmfyyVHvA6CF3pQmrTnSH18WlTsnQutGOgWVnMqvg8mHwxA9T96RGgFdBZyIy88TKtaa3qj+8OG2503k+RT1ZvxkLfpJaLZULrMZRVeoL7gT9xnnJ2sxYPo1U0t3FOMNrtg91EGrXCiX8jg== Archived-At: Subject: Re: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF) 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, 31 Jul 2020 07:22:28 -0000 --------------709A1B6E95C1F3E66A856F75 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Richard, I came to the conclusion that none of the concerns you brought up affects the nPRF suggestion at its core. The issue of the welcome secret is unnecessary (see separate eMail which I just sent since I think that the use/generation of the welcome_secret is of independent interest). The other interface mismatch which you identified is that the key needs to be partially shared before, but this is not a problem: You can share the xor of the two input keys or the concatenation of the two keys to be xored. An additional advantage of the updated nPRF construction (in addition to better assumptions and parallel computation) is that it combines entropy additively, i.e., if several secrets have low entropy, but together, they have enough entropy, then extracting from the concatenation of all of them will yield a good key although neither of the secret was good. This is useful regardless of the number of keys we combine. Chris On 24/07/2020 20:53, Richard Barnes wrote: > Hey Chris, > > I was looking again at the key schedule as I was drafting #362 [1].  A > couple of things occurred to me: > > 1. You can't add the commit secret and PSKs in the same operation, > because you want new joiners to put in the PSK, but you don't want > them to have to know the commit secret. > > 2. The nPRF construction you propose has the same number of HMAC > invocations as the chained-HKDF-Extract stuff that's in the current > draft / 362. > > Given those observations, I wonder how much an nPRF is really buying > us.  It's not saving us any HMAC calls, and relative to #362, it would > only coalesce two DPRF calls into one nPRF call. > > Maybe there's some benefit if there are multiple PSKs?  But even then, > it seems like you could add a layer, computing a synthetic PSK from > the multiple ones, and keeping the main key schedule simple. > > At this point, given the above and the novelty of the nPRF > construction, I'm inclined to just stick with HKDF and merge #362 > instead of #336. > > --Richard > > > [1] https://github.com/mlswg/mls-protocol/pull/362 > > On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska > wrote: > > Thank you for the pointer to Carter-Wegman MACs. > > >>> This style of combing hash outputs does affect collision > resistance [4], and some discussion on relation to that would be > nice to see. > > That's an excellent point. In addition to pseudorandomness, we > prove the collision-resistance of our construction. I.e., assuming > that no unique value is used twice and assuming that HMAC is > collision-resistance, then the final Expand operation guarantees > unique outputs. I.e., by including the unique value into the final > Expand operation after the xor, the construction recovers from any > collisions incurred by the xor. > > Chris > > On 07/07/2020 05:41, Hale, Britta (CIV) wrote: >> >> This is an interesting proposal. It is closely related at a high >> level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, >> k2), m) = PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into >> this category in practice. Considering the use of a MAC-based KDF >> and the proofs of [3] on DPRFs, there is an overlap between NPRFs >> and extrapolation of the above (based on iteration of the PRF >> guarantees). >> >> This is worth noting from an assurance standpoint: there was >> discussion at the virtual interims with respect to the current >> formulation of MLS key derivation, which has a “TLS precedence”, >> yet this proposal is not without precedence itself. Ergo, such a >> change should not necessarily be concerning based on differing >> from current practice. >> >> This style of combing hash outputs does affect collision >> resistance [4], and some discussion on relation to that would be >> nice to see. >> >> Britta >> >> [1] Carter, Wegman. Universal classes of hash functions. >> >> [2] Carter, Wegman. New hash functions and their use in >> authentication and set equality. >> >> [3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from >> Standard Assumptions: A Generic Validation of an HMAC Assumption. >> >> [4] Bernstein. What output size resists collisions in a xor of >> independent expansions? >> >> *From: *MLS >> on behalf of Chris Brzuska >> >> *Date: *Tuesday, June 9, 2020 at 10:32 AM >> *To: *"mls@ietf.org" >> >> *Subject: *[MLS] Key Schedule: Replace DPRF with multi-input PRF >> (NPRF) >> >> Hi all, >> >> I would like to open a discussion on a suggestion for a change in >> the key schedule. In the current draft, we use the Extract >> function twice as a dual pseudorandom function (DPRF) when >> combining 3 keys (*) and interleave them with an Expand call. >> >> The suggestion [1] is to replace these 3 calls by a multi-input >> PRF (NPRF) which is especially designed to return a pseudorandom >> key when at least one of the input keys is pseudorandom. The new >> suggestion relies on standard PRF security rather than >> DPRF-security of Extract. >> >> You can find the accompanying paper with pictures, discussion and >> security reduction for the design principle here [2]. I include a >> summary of the main points in the end of this eMail. >> >> Please comment/share your opinion. Thanks! >> >> Chris >> >> (*) commit_secret, PSK and init_secret >> >> [1] Pull Request:https://github.com/mlswg/mls-protocol/pull/337 >> >> >> [2] Paper: http://chrisbrzuska.de/2020-NPRF.html >> >> *--------------------------------------------------------------------------------------------------------------------* >> >> *Summary of main points:* >> >> The current key schedule >> - uses Extract as a dual pseudorandom function and assumes that >> HMAC is a dual pseudorandom function >> - applies Extract after Expand, i.e., after applying a function >> which generates a pseudorandom value >> - iterates Extract-then-Expand sequentially to combine more than >> 2 keys >> >> The pull request suggests to >> - replace the ad-hoc assumption that Extract is a dual >> pseudorandom function >> - remove Extract steps when applied after Expand >> - use a provably secure NPRF construction which allows to combine >> more than 2 keys and is based on a standard PRF assumption and >> statistical properties of xor. >> >> Efficiency: >> - The suggested construction has higher parallel efficiency. It >> increases the overall number of HMAC evaluations by 1. >> >> Assumptions: >> - HMAC is a standard PRF. >> - Relies on a unique value, the group_context was suggested. >> >> Construction: >> (1) Use unique value to expand each key and xor the result >> (2) expand resulting key, including unique value into the context >> again >> >> Security argument: >> - Pseudorandomness: unique value ensures that each outcome of >> Expand in (1) is used only once in a xor combination, thus >> allowing on one-time pad argument of xor. >> - Uniqueness of resulting keys: (2) ensures that if HMAC is >> collision-resistent, then the result is collision-resistent. >> >> Variants: >> - It is possible to use an NPRF variant called NameNPRF [2] which >> has 3 HMAC evaluations more and relies less on the unique value. >> I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only >> repeat if the input keys repeat *and* the group context repeats. >> >> Questions/Comments that came up: >> - Barnes, MacMillion suggested group_context as unique value >> - MacMillion wondered about removal of Extract: One can add an >> extract operation for the psk. For other input keys, it does not >> seem needed, since they were returned from Expand. >> - Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness >> of output keys, the PRF needs to be collision-resistant, too. >> >> >> _______________________________________________ >> 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 --------------709A1B6E95C1F3E66A856F75 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Richard,

I came to the conclusion that none of the concerns you brought up affects the nPRF suggestion at its core. The issue of the welcome secret is unnecessary (see separate eMail which I just sent since I think that the use/generation of the welcome_secret is of independent interest). The other interface mismatch which you identified is that the key needs to be partially shared before, but this is not a problem: You can share the xor of the two input keys or the concatenation of the two keys to be xored.

An additional advantage of the updated nPRF construction (in addition to better assumptions and parallel computation) is that it combines entropy additively, i.e., if several secrets have low entropy, but together, they have enough entropy, then extracting from the concatenation of all of them will yield a good key although neither of the secret was good. This is useful regardless of the number of keys we combine.

Chris

On 24/07/2020 20:53, Richard Barnes wrote:
Hey Chris,

I was looking again at the key schedule as I was drafting #362 [1].  A couple of things occurred to me:

1. You can't add the commit secret and PSKs in the same operation, because you want new joiners to put in the PSK, but you don't want them to have to know the commit secret.

2. The nPRF construction you propose has the same number of HMAC invocations as the chained-HKDF-Extract stuff that's in the current draft / 362.

Given those observations, I wonder how much an nPRF is really buying us.  It's not saving us any HMAC calls, and relative to #362, it would only coalesce two DPRF calls into one nPRF call.

Maybe there's some benefit if there are multiple PSKs?  But even then, it seems like you could add a layer, computing a synthetic PSK from the multiple ones, and keeping the main key schedule simple.

At this point, given the above and the novelty of the nPRF construction, I'm inclined to just stick with HKDF and merge #362 instead of #336.

--Richard



On Tue, Jul 7, 2020 at 5:30 AM Chris Brzuska <chris.brzuska@aalto.fi> wrote:

Thank you for the pointer to Carter-Wegman MACs.

>>> This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

That's an excellent point. In addition to pseudorandomness, we prove the collision-resistance of our construction. I.e., assuming that no unique value is used twice and assuming that HMAC is collision-resistance, then the final Expand operation guarantees unique outputs. I.e., by including the unique value into the final Expand operation after the xor, the construction recovers from any collisions incurred by the xor.

Chris

On 07/07/2020 05:41, Hale, Britta (CIV) wrote:

This is an interesting proposal. It is closely related at a high level to Carter-Wegman MACs (i.e. for random seed r, MAC((k1, k2), m) =  PRF(k1, r) XOR MAC(k2, m)). Quite a few MACs fall into this category in practice. Considering the use of a MAC-based KDF and the proofs of [3] on DPRFs, there is an overlap between NPRFs and extrapolation of the above (based on iteration of the PRF guarantees).

 

This is worth noting from an assurance standpoint: there was discussion at the virtual interims with respect to the current formulation of MLS key derivation, which has a “TLS precedence”, yet this proposal is not without precedence itself. Ergo, such a change should not necessarily be concerning based on differing from current practice.

 

This style of combing hash outputs does affect collision resistance [4], and some discussion on relation to that would be nice to see.

 

Britta

 

 

 

[1] Carter, Wegman. Universal classes of hash functions.

[2] Carter, Wegman. New hash functions and their use in authentication and set equality.

[3] Bellare and Lysyanskaya. Symmetric and Dual PRFs from Standard Assumptions: A Generic Validation of an HMAC Assumption.

[4] Bernstein. What output size resists collisions in a xor of independent expansions?

 

 

 

From: MLS <mls-bounces@ietf.org> on behalf of Chris Brzuska <chris.brzuska@aalto.fi>
Date: Tuesday, June 9, 2020 at 10:32 AM
To: "mls@ietf.org" <mls@ietf.org>
Subject: [MLS] Key Schedule: Replace DPRF with multi-input PRF (NPRF)

 

Hi all,

I would like to open a discussion on a suggestion for a change in the key schedule. In the current draft, we use the Extract function twice as a dual pseudorandom function (DPRF) when combining 3 keys (*) and interleave them with an Expand call.

The suggestion [1] is to replace these 3 calls by a multi-input PRF (NPRF) which is especially designed to return a pseudorandom key when at least one of the input keys is pseudorandom. The new suggestion relies on standard PRF security rather than DPRF-security of Extract.

You can find the accompanying paper with pictures, discussion and security reduction for the design principle here [2]. I include a summary of the main points in the end of this eMail.

Please comment/share your opinion. Thanks!

Chris

(*) commit_secret, PSK and init_secret

[1] Pull Request: https://github.com/mlswg/mls-protocol/pull/337

[2] Paper: http://chrisbrzuska.de/2020-NPRF.html

--------------------------------------------------------------------------------------------------------------------

Summary of main points:

The current key schedule
- uses Extract as a dual pseudorandom function and assumes that HMAC is a dual pseudorandom function
- applies Extract after Expand, i.e., after applying a function which generates a pseudorandom value
- iterates Extract-then-Expand sequentially to combine more than 2 keys

The pull request suggests to
- replace the ad-hoc assumption that Extract is a dual pseudorandom function
- remove Extract steps when applied after Expand
- use a provably secure NPRF construction which allows to combine more than 2 keys and is based on a standard PRF assumption and statistical properties of xor.

Efficiency:
- The suggested construction has higher parallel efficiency. It increases the overall number of HMAC evaluations by 1.

Assumptions:
- HMAC is a standard PRF.
- Relies on a unique value, the group_context was suggested.

Construction:
(1) Use unique value to expand each key and xor the result
(2) expand resulting key, including unique value into the context again

Security argument:
- Pseudorandomness: unique value ensures that each outcome of Expand in (1) is used only once in a xor combination, thus allowing on one-time pad argument of xor.
- Uniqueness of resulting keys: (2) ensures that if HMAC is collision-resistent, then the result is collision-resistent.

Variants:
- It is possible to use an NPRF variant called NameNPRF [2] which has 3 HMAC evaluations more and relies less on the unique value. I.e., NameNPRF is secure in the same scenarios as DPRF: Keys only repeat if the input keys repeat *and* the group context repeats.

Questions/Comments that came up:
- Barnes, MacMillion suggested group_context as unique value
- MacMillion wondered about removal of Extract: One can add an extract operation for the psk. For other input keys, it does not seem needed, since they were returned from Expand.
- Wood: Can we replace HMAC by arbitrary PRF? Yes. For uniqueness of output keys, the PRF needs to be collision-resistant, too. 


_______________________________________________
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
--------------709A1B6E95C1F3E66A856F75--