From nobody Thu Apr 2 11:42: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 02B9E3A077C for ; Thu, 2 Apr 2020 11:42:19 -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 5fECp9MCyz6k for ; Thu, 2 Apr 2020 11:42:17 -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 840FB3A0766 for ; Thu, 2 Apr 2020 11:42:17 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id z13so2272436qvw.3 for ; Thu, 02 Apr 2020 11:42:17 -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=7hX41YiZXa3j0k6MKfkHE6w1ZydKDlN4u1vRFupRjB8=; b=fQUVUv6kNkPwL4VeNz1nB2mpNnBdepE0UdsmdTDXPnvgxUzkqWWn/iqGaSJZjm0s+n umaGeP6XZ8eLUP/h57lpJAeQSW+wVGHztMrxeb9meq6KhCaK63LbB+hixc9QcBp/c7qe Om7YtohU6HaGejNZefXjBwDbpn/U8QyoaZgfo= 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=7hX41YiZXa3j0k6MKfkHE6w1ZydKDlN4u1vRFupRjB8=; b=IWl4THyjIi8wQ/9Ohhn4UrKJgNdVDO68xkJLbPCSEHc55jb1gEKa+dCYo3UAlca48d PZQxYHVRozSrfEZ/GoGfBMuWl0pl+/zNJd/AzJbGYO2FLFk8ypQs8ka3etbl+Y/vOvK8 ogfjXoyJeB+NsAw63PovFYgpcEZ2iuL8nMOMMK3q9smZ1tqpNLWTLSo6SqPq6w+wnFGi lwsvYKi6hvfKFhuq79/dlpuSI4Iz7Df7XZ0Axz//fFCkLpM738sldFwdr5LQdchjhS79 yydJMBGUpKYBahVqzoLUeiH/o1WftCH6KmVwIdx0fXFxjQBa9K29MrjbBtNFdmyF1icK RAfg== X-Gm-Message-State: AGi0PuYDwMsAQrh1twWW0Us1wTI4wkxb239xLK0/HjFIu9fwpjc6vab0 Bz1nB9zgAkeVxIrzz0Ay6IAKaW5H54w= X-Google-Smtp-Source: APiQypLTT21AbbfM+Qa8COFCPK71FJubLskQU7eT3+CqLRKUcP6qAQkpxDIDiwsyw92FpLNJcF4lHw== X-Received: by 2002:a0c:c2d0:: with SMTP id c16mr4775808qvi.118.1585852935939; Thu, 02 Apr 2020 11:42:15 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id a136sm4167301qkb.15.2020.04.02.11.42.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 11:42:15 -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.80.23.2.2\)) Date: Thu, 2 Apr 2020 14:42:14 -0400 References: To: MLS List In-Reply-To: Message-Id: <13217D97-7C22-4829-8910-0AEA6774AF51@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Planning: IETF 107 Virtual Meeting 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, 02 Apr 2020 18:42:19 -0000 hi MLS, There were enough people that could not make the 31st that we decided to = try for another day. We have looked at the scheduled virtual interims = (https://datatracker.ietf.org/meeting/upcoming) in the coming weeks and = have decided that either the 16th or the 21st could work both in terms = of getting the formal approvals (we need a week) as well as making sure = we do not have major clashes (we want to make sure participants can = attend). This virtual would be 1.5 hours long. We also want to determine how often we should meet after that. The two = choices that seem reasonable are weekly and bi-weekly. Finally, we need pick a time. There are four main clusters of = participants are in the following timezones EDT, PDT, CEST, and BST. = With the four time zones there really is no good time: = https://www.timeanddate.com/worldclock/meetingtime.html?month=3D4&day=3D16= &year=3D2020&p1=3D263&p2=3D37&p3=3D136&p4=3D224&iv=3D0 Since the other virtual interims were scheduled for 0600am PST, we ought = to give them a break and not have it so early. So, I=E2=80=99ve proposed = four times later in the day. Please fill out the doodle poll to let us know what works: https://forms.gle/oBAtkAxVNwrb31j2A spt > On Mar 19, 2020, at 14:34, Nick Sullivan = wrote: >=20 > Hello MLSWG members, >=20 > Since the IETF 107 is no longer happening in person, it may be useful = to have a virtual meeting for MLS instead. There are a number of PRs and = ideas to discuss. >=20 > Please fill out the following poll to help us determine interest: > = https://docs.google.com/forms/d/e/1FAIpQLSdGgMT16UcwL21KWbO_RFwqkozuDkBRV-= FJh-VmVF_C204H8g/viewform?usp=3Dsf_link >=20 > Nick & Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Sun Apr 5 00:38: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 743493A15EC for ; Sun, 5 Apr 2020 00:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=md9Lt1PP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EXHgSr+O 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 BSP2MUN5r9dp for ; Sun, 5 Apr 2020 00:38:13 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E143A15EA for ; Sun, 5 Apr 2020 00:38:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E92E05C01A4 for ; Sun, 5 Apr 2020 03:32:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 05 Apr 2020 03:32:22 -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= fm2; bh=lluX058qOyFviCiXXIU+SWMuRD/ChZ0yXUsnWbfITBQ=; b=md9Lt1PP qIDspphfhecZGGzJHAgtaZ+ggAQ3rFF4Tox0pHNzHa1V9fwyb8o/TlhG/KQ2A2Q+ S/f3wP+ducdYuOxHA8PRd4JeV83SBiXtCszcnVb4Eie5L8WzdlkNoiMW2q/vc4x/ b3jPpmA+FB2ralf3HuoGhJjHcxJuLzD2/1P7qu8J7m4StA9GGJGOkZR1L+e3Je+X kRpGvuVYaZG4iU8ar4hRd24/PhAL34hZGoimq+FzcX5hGE57CyYbHGPLnBAATp3E uyTNnuCInhSeulCrWoGKjIpva3gXaw4pCfo1uocSxX+ILbKQmhQu2KpduPQkDuHC 6m2oObPKR5AggQ== 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=fm2; bh=lluX058qOyFviCiXXIU+SWMuRD/Ch Z0yXUsnWbfITBQ=; b=EXHgSr+OhD253N4KOBBagXXqqYICcxxuuOp1ngi9Yx9iS 3KbTkPDomYh8+bSwFXVP4PS7LMRc0+0tNa8TAmaG1NUQPVMffG597i4IFyhbbJAH Xk6Sq0cCQOIHqHIE2XGJ3UgGxgks5tQQK7w8Si4UlLx/GiU5uKFDbEYMvX0GHy0P znjieKYuv2vnp48D0v1UpG3SR2Q7k9daQGwJ/Ob9hNiwJLnEB8qKvtf9dqhjnF47 vtyKF+aqQOohq4AJo5koD2AQKVtoitB7TL7L7oMFoFTlNmR1gHBl9dRxIrKbCZPO /JnWmH8Dtkwae1ST92Eq07q/2D90cuOhFpBDBBAyA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehvddrudejjedrhedrheenucevlhhushhtvghrufhi iigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.177.5.5]) by mail.messagingengine.com (Postfix) with ESMTPA id A4FFF306D1F6 for ; Sun, 5 Apr 2020 03:32:22 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8427608209938214445==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200405073222.A4FFF306D1F6@mailuser.nyi.internal> Date: Sun, 5 Apr 2020 03:32:22 -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, 05 Apr 2020 07:38:15 -0000 --===============8427608209938214445== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC6) 1 issues created: - Clarification wanted: Messaging Service (by GaPhil) https://github.com/mlswg/mls-architecture/issues/62=20 1 issues received 6 new comments: - #62 Clarification wanted: Messaging Service (6 by GaPhil, beurdouche) https://github.com/mlswg/mls-architecture/issues/62=20 1 issues closed: - Clarification wanted: Messaging Service https://github.com/mlswg/mls-ar= chitecture/issues/62=20 * mlswg/mls-protocol (+1/-0/=F0=9F=92=AC16) 1 issues created: - Use the same index for hashing parent and leaf nodes (by bifurcation) https://github.com/mlswg/mls-protocol/issues/328=20 5 issues received 16 new comments: - #328 Use the same index for hashing parent and leaf nodes (1 by Bren201= 0) https://github.com/mlswg/mls-protocol/issues/328=20 - #326 Authenticate that added members know the PSK (1 by br-hale) https://github.com/mlswg/mls-protocol/issues/326=20 - #325 Simplify epoch secret derivation? (10 by Bren2010, br-hale, kkohbr= ok) https://github.com/mlswg/mls-protocol/issues/325 [question]=20 - #324 Use consistent arguments to Derive-Secret (1 by GaPhil) https://github.com/mlswg/mls-protocol/issues/324=20 - #301 Targeted message (3 by br-hale, kkohbrok, raphaelrobert) https://github.com/mlswg/mls-protocol/issues/301 [discussion] [function= ality] [privacy]=20 Pull requests ------------- * mlswg/mls-architecture (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Rename messaging service to service provider (by GaPhil) https://github.com/mlswg/mls-architecture/pull/63=20 1 pull requests received 1 new comments: - #63 Rename messaging service to service provider (1 by beurdouche) https://github.com/mlswg/mls-architecture/pull/63=20 1 pull requests merged: - Rename messaging service to service provider https://github.com/mlswg/mls-architecture/pull/63=20 * mlswg/mls-protocol (+1/-1/=F0=9F=92=AC4) 1 pull requests submitted: - Rename messaging service to service provider (by GaPhil) https://github.com/mlswg/mls-protocol/pull/329=20 1 pull requests received 4 new comments: - #320 Use node type instead of leaf index in tree hashes. (4 by Bren2010= , beurdouche, bifurcation) https://github.com/mlswg/mls-protocol/pull/320=20 1 pull requests merged: - Rename messaging service to service provider https://github.com/mlswg/mls-protocol/pull/329=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============8427608209938214445== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday April 05, 2020

Issues

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

1 issues created:

1 issues received 6 new comments:

1 issues closed:

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

1 issues created:

5 issues received 16 new comments:

Pull requests

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

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 4 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============8427608209938214445==-- From nobody Sun Apr 5 18:16: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 6B3E53A0A8B for ; Sun, 5 Apr 2020 18:16: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 7gpJH0S-Rmbw for ; Sun, 5 Apr 2020 18:16:42 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3942E3A0A80 for ; Sun, 5 Apr 2020 18:16:42 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id bu9so6743649qvb.13 for ; Sun, 05 Apr 2020 18:16: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:date:references :to:in-reply-to:message-id; bh=UFF4MFxxSzrCot2hTdBqgkpGx6AKw5JiHrftpCWANS0=; b=ACRwxrFxNJjXS2sCCnrFTCGua0fP30hPjsLqByfCJgVfGlsuH4hkrYf2fO+/MJUslf qRUO7MGzHboQHBupeDgr8WCH5PppI8RxYJyrFUNWMp3Rtu3hWK0HfyW87HMVN49BzTpg zktt8NYx9CQa+j6m3BbXvRYlDsfGHNfeE7Woo= 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=UFF4MFxxSzrCot2hTdBqgkpGx6AKw5JiHrftpCWANS0=; b=IuAiJr+ewB5zZXwaqQNk9Zc0cNKPoW8qYTews1OTF98YaFkGo/FIe4jc9EYGjO9hBf YwAiid4U9aCq4U6XBvJHTt6bXhAgsBD2NN72CYWxiDqKIcnwNOx6QtXPc39CxM1bYdTz 1IHu6Ap7yDO56285ZiVntN8CngvkAWBodkuUVNwhUrtZvyzQEBkeUEtTFepB1VrT2hdk CJ5E3kasDnqSVC3tM/4Y+rieEPMW58VeNz7yfEJlempwgGMC/wyZhUd0wpKnmjHFhgNd f7xhbhlshXeEvr/axLvb8jTylch4x/X4LsQ+lTHefUr2XAzTgrb3lgaHGfna1LFgi1uE t+BQ== X-Gm-Message-State: AGi0PuYVrO/oCkFJ3Nk05em0ls/xEQj1zszAU9iPQAIWRMPgbagAJuTe 7SW+ParqvU6bJcmfaTZkQZnPeVtS0vk= X-Google-Smtp-Source: APiQypLac8JDvdiB7jcFykI88kg2kub92zzdIWLeaLDh3VAJ7H0Bpq3IbGBN1riAOwQCUoiUCexYsQ== X-Received: by 2002:a05:6214:56c:: with SMTP id cj12mr18757272qvb.29.1586135800794; Sun, 05 Apr 2020 18:16:40 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id o187sm3063438qkb.40.2020.04.05.18.16.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 18:16:40 -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: Sun, 5 Apr 2020 21:16:39 -0400 References: <158335851698.29475.5981759485587583523@ietfa.amsl.com> To: MLS List In-Reply-To: <158335851698.29475.5981759485587583523@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request 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 Apr 2020 01:16:45 -0000 hi MLS, It seems like the prudent thing here would be to cancel this face to = face meeting. We are working to schedule virtual interims to ensure we = can continue to progress our work. spt > On Mar 4, 2020, at 16:48, IETF Meeting Session Request Tool = wrote: >=20 >=20 > A new interim meeting request has just been submitted by Sean Turner. >=20 > This request requires approval by the Area Director of the Security = Area >=20 > The meeting can be approved here:=20 > = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-10 >=20 >=20 >=20 > --------------------------------------------------------- > Working Group Name: Messaging Layer Security > Area Name: Security Area > Session Requester: Sean Turner >=20 > City: Berlin > Country: DE >=20 >=20 > Session 1: >=20 > Date: 2020-05-07 > Start Time: 09:00 Europe/Berlin > Duration: 08:00 > Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm0b5981050dd8f6e923fde6b5fb5835c1= > Agenda Note:=20 > Session 2: >=20 > Date: 2020-05-08 > Start Time: 09:00 Europe/Berlin > Duration: 08:00 > Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm0b5981050dd8f6e923fde6b5fb5835c1= > Agenda Note:=20 >=20 > --------------------------------------------------------- >=20 >=20 From nobody Thu Apr 9 18:00: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 1191F3A183C for ; Thu, 9 Apr 2020 18:00:27 -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 jsV4NY_ztKMb for ; Thu, 9 Apr 2020 18:00:25 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658083A183B for ; Thu, 9 Apr 2020 18:00:25 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id ef12so289970qvb.11 for ; Thu, 09 Apr 2020 18:00:25 -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=zGClR1nT6DI0eEB5VwhcNfiJXdQsKNSmO1kDjbVKBBI=; b=cLP2mmEFQyLaeeVeiOMnu+BiIjW70uGwAofPSplMTBCj61YiHIYi45dV1Q4wT3euZS GP0TiNuwATOtqAx7IDiTRUxG8FPu91jG8gLu6dhFWDIv7ZeW1hzb8jgieGJSY/9bzIh4 76pTeLIhX0gKLE37foOKbAwrcfqNMvcmeLBfE= 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=zGClR1nT6DI0eEB5VwhcNfiJXdQsKNSmO1kDjbVKBBI=; b=WqvgYcJ409lTIQ9QJasDvwbEO/lytx0f1Ao6nqTOi5KNUnvRGYuDsX/PdyGzZyOENU bvxs1E0HdJ2FB1QVnwtb+EKJVbmWWioG0I+n2hohNE0mcEW8xfDuZXTM4ZcTfP2fJ7V0 8cBlkoguhiq1bnSoizJGzlkMrlMyqlQwP1fwlNBFloJTq4HMfTPGf9nRLLazVcpDHE67 CY66pY9hgbcEcjnB7PiHMFiGQDFzhiyrAwOBkLxNS60Zg8BDjOqIOWM095dSZG7GAWRf LI4j7kcy4cCm75TlP75x0Bmku4qDCUwlsyjPwm8dnC+fhIEJp1FLFdk/odu+HtOHKIdH 3CoA== X-Gm-Message-State: AGi0PuZjMztz8Vl/ybhesJxs+Q14Whi787BFT8Ua6TGmnbMwwmDrAblc rLflUQvYt/F42H2Ri8yxdz/Z01sTVfw= X-Google-Smtp-Source: APiQypLM08GZkx/HI9XaK7eOUEHr8w3HMDIFSOKRBvByf7+dUwhWqKq7wj6xGdfJtKabtLiBA+LKnA== X-Received: by 2002:ad4:49cc:: with SMTP id j12mr2945308qvy.94.1586480423903; Thu, 09 Apr 2020 18:00:23 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 26sm430016qka.107.2020.04.09.18.00.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 18:00:23 -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.80.23.2.2\)) Date: Thu, 9 Apr 2020 21:00:22 -0400 References: <13217D97-7C22-4829-8910-0AEA6774AF51@sn3rd.com> To: MLS List In-Reply-To: <13217D97-7C22-4829-8910-0AEA6774AF51@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Planning: IETF 107 Virtual Meeting 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, 10 Apr 2020 01:00:27 -0000 hi MLS, It appears we have a slight preference for April 21st. I will submit = the interim request shortly. spt > On Apr 2, 2020, at 14:42, Sean Turner wrote: >=20 > hi MLS, >=20 > There were enough people that could not make the 31st that we decided = to try for another day. We have looked at the scheduled virtual interims = (https://datatracker.ietf.org/meeting/upcoming) in the coming weeks and = have decided that either the 16th or the 21st could work both in terms = of getting the formal approvals (we need a week) as well as making sure = we do not have major clashes (we want to make sure participants can = attend). This virtual would be 1.5 hours long. >=20 > We also want to determine how often we should meet after that. The two = choices that seem reasonable are weekly and bi-weekly. >=20 > Finally, we need pick a time. There are four main clusters of = participants are in the following timezones EDT, PDT, CEST, and BST. = With the four time zones there really is no good time: = https://www.timeanddate.com/worldclock/meetingtime.html?month=3D4&day=3D16= &year=3D2020&p1=3D263&p2=3D37&p3=3D136&p4=3D224&iv=3D0 > Since the other virtual interims were scheduled for 0600am PST, we = ought to give them a break and not have it so early. So, I=E2=80=99ve = proposed four times later in the day. >=20 > Please fill out the doodle poll to let us know what works: >=20 > https://forms.gle/oBAtkAxVNwrb31j2A >=20 > spt >=20 >> On Mar 19, 2020, at 14:34, Nick Sullivan = wrote: >>=20 >> Hello MLSWG members, >>=20 >> Since the IETF 107 is no longer happening in person, it may be useful = to have a virtual meeting for MLS instead. There are a number of PRs and = ideas to discuss. >>=20 >> Please fill out the following poll to help us determine interest: >> = https://docs.google.com/forms/d/e/1FAIpQLSdGgMT16UcwL21KWbO_RFwqkozuDkBRV-= FJh-VmVF_C204H8g/viewform?usp=3Dsf_link >>=20 >> Nick & Sean >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 From nobody Thu Apr 9 18:10:01 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 91A843A1855; Thu, 9 Apr 2020 18:09:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls@ietf.org, sean@sn3rd.com, mls-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158648099939.10946.5135954156023367724@ietfa.amsl.com> Date: Thu, 09 Apr 2020 18:09:59 -0700 Archived-At: Subject: [MLS] mls - New Interim Meeting Request 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, 10 Apr 2020 01:10:00 -0000 A new interim meeting request has just been submitted by Sean Turner. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-11 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Meeting Type: Virtual Meeting Session 1: Date: 2020-04-21 Start Time: 14:00 America/New_York Duration: 01:30 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m92ea16ea97a73422258dbd600c056a27 Agenda Note: --------------------------------------------------------- From nobody Fri Apr 10 05:53:25 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 F3F143A090E; Fri, 10 Apr 2020 05:53:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls-chairs@ietf.org, mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158652320387.10581.3897643093014655796@ietfa.amsl.com> Date: Fri, 10 Apr 2020 05:53:23 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Interim Meeting Cancelled (was 2020-05-07) 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, 10 Apr 2020 12:53:24 -0000 The Messaging Layer Security (mls) interim meeting for 2020-05-07 from 09:00 to 17:00 Europe/Berlin has been cancelled. From nobody Fri Apr 10 06:14:27 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 572993A097B; Fri, 10 Apr 2020 06:14:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158652446121.19076.15530618640349687988@ietfa.amsl.com> Date: Fri, 10 Apr 2020 06:14:21 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-04-21 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, 10 Apr 2020 13:14:22 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-04-21 from 14:00 to 15:30 America/New_York (18:00 to 19:30 UTC). Agenda: # Protocol # Architecture # AOB Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m92ea16ea97a73422258dbd600c056a27 From nobody Fri Apr 17 00:48: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 2F4C33A0FBC for ; Fri, 17 Apr 2020 00:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk1x7PVGFTkR for ; Fri, 17 Apr 2020 00:48:00 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51273A0FBD for ; Fri, 17 Apr 2020 00:48:00 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id w11so706053pga.12 for ; Fri, 17 Apr 2020 00:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=lYi7UN6lrAEnrEC6wIAKqkaUHlFt7yrMRKDki8myCL0=; b=vgJwho7TxO1s1KMTVmhBHNN6QfuxCm7ZfRTlyyoKvEtcGiA4oKLvkgT9YDJ9X97Qk/ HaVCtYd0evHFS6/N96MDrME3Ok0T4FGS6c11GS17CFbhdiuWxv3XhggrHIUVpNKM7tRM KgrNAOY+j8GKqTckA/omkdpiPTrFtxVvkqHZLu0ANXhqxVG7EAM3L+Z12kXDRcDgw8QG lk646E1I3d1juUt//AX+Z+8xWLFoilKCz83Vfho2W+lH0Mh6064DEnA42VC7qUxSFSn1 wmYyqKRsLLWrxCTJfuSWhtfzVu9+0P+gID0TpgArBShc3FtOLq7kUwoFowiXISvO3amH grng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=lYi7UN6lrAEnrEC6wIAKqkaUHlFt7yrMRKDki8myCL0=; b=EakQvdTHuVvIacOzAPacKy32OcNZLWx1x3RjFKGUgDqLsz7Si9tA6bF1Ai9Q1q5uPu UcCLf2/MAIHLfTWccB0HoTkRlB5CKk+/o/e/crc/41EOXQyTjEqksrWz7W2oj9CZzvm4 ZRCDSVc1r7YzhJ4F6e3W3a+Psnr5WkEIH4kzxFTY+hPVAjpBkud0KvEQaaqgZqkUBk/i j02U5AN5EnbBrsqzLxuVd2WRB+rUI3yhzmV2jbR7Et8vrOj10u3MicNJoea5Z8cmh5OH u8smwNrT7wHpOx7dL9RgUKRcFdV10cJbci1Tce87KhwFoplYz4w5k3pDF6PkIG5RlEac 4LrA== X-Gm-Message-State: AGi0PuZUXBmG8uJ1q48awfK8rFlp/R5Dm54sOOREc/Sj2h4j/99WiSlz 5D7uFjGQIdGiqVXgJrtZnFVNDK8sjIg= X-Google-Smtp-Source: APiQypJuml0+U47QlAqWkk7/VOUAJDUCuP4vYqk16wu2dNKveTQRh/vziMrtWQN4DgEaULhM/1PVjA== X-Received: by 2002:aa7:8bc8:: with SMTP id s8mr1957261pfd.252.1587109679003; Fri, 17 Apr 2020 00:47:59 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id k193sm642829pga.43.2020.04.17.00.47.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 00:47:58 -0700 (PDT) To: Messaging Layer Security WG From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: Date: Fri, 17 Apr 2020 16:47:56 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] reusing HPKE keys from welcome messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:48:02 -0000 Hey Everyone, Sandro Coretti and I have a few suggestions. To keep threads on the list topic specific I'm putting the suggestions in separate emails so please excuse the spam. Here goes. Issue: HPKE Key Reuse Suppose Alice (commits to a proposal that) invites Bob to a group. For this she uses a Key Bundle for Bob with an HPKE pub key in it. That pub key has 2 functions (and correct me if I'm wrong here). On the one it becomes the HPKE key in Bob's leaf in the new ratchet tree. On the other hand, the Welcome message to Bob is also encrypted to that HPKE key. Problem: Bob must keep around the corresponding HPKE secret until he updates or leaves the group. Thing is, that same HPKE sec key lets you reprocess that welcome message. Ergo, until he does an update we have no FS for all MLS epochs after his join. (See PS. at end of email for more.) Proposed Solution: Separate HPKE keys for welcome message and initial leaf key. E.g. Key Bundles registered on the Key Server have two HPKE keys. One for the welcome message only and the other used as new leaf's HPKE key. As soon as Bob processes the welcome message he deletes the HPKE key he used for it. Thoughts? - Joël & Sandro PS. For those familiar, this is basically a special case of the FS issues with TreeKEM we address with RTreeKEM in eprint/2019/1189. But normally attacks on the FS of some TreeKEM epoch msg still requires u to somehow know the previous epochs init_secret. Thats why, normally, FS attacks on TreeKEM "only" translate to PCFS attacks on MLS. But for the welcome message variant that's different. The whole point of the welcome message is to bootstrap from that one HPKE secret key all the way to full-state MLS (including current key schedule). So the attacker no longer needs an extra init_secret if they leak that one HPKE secret key. Thus, this goes from the usual PCFS attack for MLS to being a plain FS one. From nobody Fri Apr 17 00:51: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 9AD463A0FCA for ; Fri, 17 Apr 2020 00:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTY22CDwU4br for ; Fri, 17 Apr 2020 00:51:18 -0700 (PDT) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (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 9120A3A0FCC for ; Fri, 17 Apr 2020 00:50:57 -0700 (PDT) Received: by mail-pj1-x1041.google.com with SMTP id a22so728626pjk.5 for ; Fri, 17 Apr 2020 00:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=IEMyvTL0jVK7qJvA44W7u1CdnXWq2TaA3jtcrh6m9rg=; b=C/E2yZwaDPovkebLA1YEnuNSUHh+WgHBMDJ/4vXjjINKx10gC53xM8ZkGdXmkwQMPt wdctKHtY2mcZZslUSHfxKm6wmlAcionyiaQvtxqWw3Dsz+rklbb4yJ/Cu7egyqs+6H/8 WoDoExoFxCY8fM831xyIjJ1B/1w0YhgxRCNKH3CP9iaURFx5lD64aw1f4Q3hjMui9W2w qGxEk0ahNtTjqwwD5VAeie1VbF5GqDifQL6yh0yM9v+IZ2045JRQTVluq2xn/+UQyGhn 74F6uKGu/Xy5eIP5BmtbgXLrdRfG7E3dEk4MFKOJVoU7rXtKu4gkdxtnwSixBkRE0srY bskQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=IEMyvTL0jVK7qJvA44W7u1CdnXWq2TaA3jtcrh6m9rg=; b=CztZvyOnGxN4yvjWe1G4vBxwcBMhBHgiKyuLvC559YiGuyERPoNIlWo8/s5J8/sNf9 9y0wYDNY2omTQHcOHf1LmtxBsF/y6GeW448qg6Q+tPkHKSgSKzrRsZRLNk/9qdbvFjM7 yPVyskusT4awXw31vl7qsyFusQGCEVUW6M3jhUDsnsSzXS95gFqa9xVVhP5S99C+EmH3 oFM3FS0AaxSixW5clxpE6AbEt/CkQKFkhVNbwIXASXIpM3Up5UqeUjcdU0vEJdUh+vbM laWZ3cClv/InPqc+kFgW0fVAZMAb2L4Me9oihSIpNTqrvdfn5Jz6mtcH0zi4J7bZ19DB L0yg== X-Gm-Message-State: AGi0PuY/LdwGOmMHLyjr5RweDpM/BL+2jxDsFDizLUsO0/qKrivSxtlp XvGSzPSmhr5f9nuJ8ug/lWcZJAdERC4= X-Google-Smtp-Source: APiQypI2reSgCUmREXjXXj7VGu/83LitHZn7n2vJ64J/HsGEFcKwzlvGBuQdVihEXhX7KFP2MFWw4A== X-Received: by 2002:a17:90a:77cb:: with SMTP id e11mr3011399pjs.0.1587109856815; Fri, 17 Apr 2020 00:50:56 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id b11sm18890358pfr.155.2020.04.17.00.50.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 00:50:56 -0700 (PDT) To: Messaging Layer Security WG From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <17d24e72-c331-3a2d-3d33-5dfd59d069ab@wickr.com> Date: Fri, 17 Apr 2020 16:50:54 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] somewhat better PCFS for cheap 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 Apr 2020 07:51:22 -0000 Hey Everyone, Sandro Coretti and I have the following suggestions for how "hash up the tree" during a Commit works. (C.f. Section 5.4 in MLS protocol version 9). The goal is to (cheaply) fix the FS of TreeKEM (ergo the PCFS of MLS). The Issue: Currently all new keys inserted into the ratchet tree in a commit (not to mention the resulting commit_secret) are all derived deterministically from leaf_hpke_secret of committer's new leaf key. That value is in turn sampled freshly at commit time by the committer. For concreteness: offending lines in mls-protocol-09 Pg. 17 -------- snip ---------- The generator of the Commit starts by using the HPKE secret key "leaf_hpke_secret" associated with the new leaf KeyPackage (see Section 7) to compute "path_secret[0]" and generate a sequence of "path secrets", one for each ancestor of its leaf. path_secret[0] = HKDF-Expand-Label(leaf_hpke_secret, "path", "", Hash.Length) -------- snip ---------- The Problem: Suppose Alice commits. If her resulting leaf HPKE priv key ever leaks, the adversary learns all keys generated in her commit. Thing is, thats true even if all those keys have since been overwritten and removed from her state by the time her state leaks. Her leaf priv key alone is enough to re-derive all of them. Zooming out a bit, for TreeKEM this means poorer FS than need be. Zooming out further, for MLS we get poorer PCFS than need be. Proposed Solution: We say "poorer than need be" because there are many easy fixes here. E.g. - Option 1 (simplicity) sample the HPKE leaf key pair using fresh random bytes. Also sample a "derive_secret" independently for doing the deterministic deriving up the tree. - Option 2 (saves on consumed random bytes) sample a pre-seed. Expand it (e.g. with HKDF-Expand) to two independent secrets. Use one to generate HPKE pub/priv key pair for leaf. Use the other to do the hashing up the tree. (This is how we modeled TreeKEM in eprint/2019/1189.) Personally, I'm partial to 2 because, as a general rule of thumb, I like to conserve entropy demand. It can be a rare commodity in some deployments and when implementers start doing things like calling /dev/random instead of /dev/urandom you can end up depleting entropy. So, for concreteness how about this? -------- snip ---------- pre-seed <-- {0,1}^secparam //first half of output goes in seed, second half in leaf_hpke_secret seed, leaf_hpke_secret = HPKDF-Expand(pre-seed, "leafgen", "", Hash.Length) -------- snip ---------- leaf_hpke_priv, leaf_hpke_pub = Derive-Key-Pair(seed) - Joël & Sandro From nobody Fri Apr 17 01:22: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 713DB3A107C for ; Fri, 17 Apr 2020 01:22:36 -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 JqcCwO3oQgvr for ; Fri, 17 Apr 2020 01:22:34 -0700 (PDT) Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B06A3A1078 for ; Fri, 17 Apr 2020 01:22:31 -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 493Tbn3NXDzQlJR for ; Fri, 17 Apr 2020 10:22:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id BgH-VInzR5y7 for ; Fri, 17 Apr 2020 10:22:24 +0200 (CEST) To: mls@ietf.org References: From: Konrad Kohbrok Message-ID: Date: Fri, 17 Apr 2020 10:22:24 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 42F45174A X-Rspamd-Score: -5.25 / 15.00 / 15.00 Archived-At: Subject: Re: [MLS] reusing HPKE keys from welcome messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:22:37 -0000 Hi everyone, nice catch! Although I have to say I'm surprised this is how it's currently defined in the draft. I just checked back in draft-8 (which is what we're currently analyzing) and back then it was like your proposed Option 2 (if I understand it correctly). I think deriving a key/secret from an HPKE private key is a very bad idea in terms of key separation. I must have missed this change and the corresponding discussion back when it got into the draft. What was the reason for the change from how it worked in draft-8 in the first place? If it doesn't break anything, I would very much like to adopt one of the options proposed by Joël & Sandro. If it does break something, we should still reconsider the current design. Cheers, Konrad On 17.04.20 09:47, Joel Alwen wrote: > Hey Everyone, > > Sandro Coretti and I have a few suggestions. To keep threads on the list topic > specific I'm putting the suggestions in separate emails so please excuse the > spam. Here goes. > > Issue: HPKE Key Reuse > Suppose Alice (commits to a proposal that) invites Bob to a group. For this she > uses a Key Bundle for Bob with an HPKE pub key in it. That pub key has 2 > functions (and correct me if I'm wrong here). On the one it becomes the HPKE key > in Bob's leaf in the new ratchet tree. On the other hand, the Welcome message to > Bob is also encrypted to that HPKE key. > > Problem: Bob must keep around the corresponding HPKE secret until he updates or > leaves the group. Thing is, that same HPKE sec key lets you reprocess that > welcome message. Ergo, until he does an update we have no FS for all MLS epochs > after his join. (See PS. at end of email for more.) > > Proposed Solution: Separate HPKE keys for welcome message and initial leaf key. > E.g. Key Bundles registered on the Key Server have two HPKE keys. One for the > welcome message only and the other used as new leaf's HPKE key. As soon as Bob > processes the welcome message he deletes the HPKE key he used for it. > > > Thoughts? > > - Joël & Sandro > > > > PS. For those familiar, this is basically a special case of the FS issues with > TreeKEM we address with RTreeKEM in eprint/2019/1189. But normally attacks on > the FS of some TreeKEM epoch msg still requires u to somehow know the previous > epochs init_secret. Thats why, normally, FS attacks on TreeKEM "only" translate > to PCFS attacks on MLS. But for the welcome message variant that's different. > The whole point of the welcome message is to bootstrap from that one HPKE secret > key all the way to full-state MLS (including current key schedule). So the > attacker no longer needs an extra init_secret if they leak that one HPKE secret > key. Thus, this goes from the usual PCFS attack for MLS to being a plain FS one. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Fri Apr 17 01:23:59 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 470853A1077 for ; Fri, 17 Apr 2020 01:23:57 -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 7A1dpPgu_Hz0 for ; Fri, 17 Apr 2020 01:23:55 -0700 (PDT) Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [IPv6:2001:67c:2050::465:202]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA363A1080 for ; Fri, 17 Apr 2020 01:23:54 -0700 (PDT) Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 493TdM4VJJzQlHD for ; Fri, 17 Apr 2020 10:23:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id iiy9GI1GhuyH for ; Fri, 17 Apr 2020 10:23:39 +0200 (CEST) From: Konrad Kohbrok To: mls@ietf.org References: Message-ID: <2471e14d-ddc6-15fb-c100-e13b47161c64@datashrine.de> Date: Fri, 17 Apr 2020 10:23:39 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5B94517F6 X-Rspamd-Score: -5.25 / 15.00 / 15.00 Archived-At: Subject: Re: [MLS] reusing HPKE keys from welcome messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:23:57 -0000 Ah, replied to the wrong mail. This was meant to be a reply to "somewhat better PCFS for cheap". Sorry about that! Konrad On 17.04.20 10:22, Konrad Kohbrok wrote: > Hi everyone, > > nice catch! Although I have to say I'm surprised this is how it's currently > defined in the draft. I just checked back in draft-8 (which is what we're > currently analyzing) and back then it was like your proposed Option 2 (if I > understand it correctly). > > I think deriving a key/secret from an HPKE private key is a very bad idea in > terms of key separation. I must have missed this change and the corresponding > discussion back when it got into the draft. > > What was the reason for the change from how it worked in draft-8 in the first > place? If it doesn't break anything, I would very much like to adopt one of the > options proposed by Joël & Sandro. If it does break something, we should still > reconsider the current design. > > Cheers, > Konrad > > On 17.04.20 09:47, Joel Alwen wrote: >> Hey Everyone, >> >> Sandro Coretti and I have a few suggestions. To keep threads on the list topic >> specific I'm putting the suggestions in separate emails so please excuse the >> spam. Here goes. >> >> Issue: HPKE Key Reuse >> Suppose Alice (commits to a proposal that) invites Bob to a group. For this she >> uses a Key Bundle for Bob with an HPKE pub key in it. That pub key has 2 >> functions (and correct me if I'm wrong here). On the one it becomes the HPKE key >> in Bob's leaf in the new ratchet tree. On the other hand, the Welcome message to >> Bob is also encrypted to that HPKE key. >> >> Problem: Bob must keep around the corresponding HPKE secret until he updates or >> leaves the group. Thing is, that same HPKE sec key lets you reprocess that >> welcome message. Ergo, until he does an update we have no FS for all MLS epochs >> after his join. (See PS. at end of email for more.) >> >> Proposed Solution: Separate HPKE keys for welcome message and initial leaf key. >> E.g. Key Bundles registered on the Key Server have two HPKE keys. One for the >> welcome message only and the other used as new leaf's HPKE key. As soon as Bob >> processes the welcome message he deletes the HPKE key he used for it. >> >> >> Thoughts? >> >> - Joël & Sandro >> >> >> >> PS. For those familiar, this is basically a special case of the FS issues with >> TreeKEM we address with RTreeKEM in eprint/2019/1189. But normally attacks on >> the FS of some TreeKEM epoch msg still requires u to somehow know the previous >> epochs init_secret. Thats why, normally, FS attacks on TreeKEM "only" translate >> to PCFS attacks on MLS. But for the welcome message variant that's different. >> The whole point of the welcome message is to bootstrap from that one HPKE secret >> key all the way to full-state MLS (including current key schedule). So the >> attacker no longer needs an extra init_secret if they leak that one HPKE secret >> key. Thus, this goes from the usual PCFS attack for MLS to being a plain FS one. >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> From nobody Fri Apr 17 05:42: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 4244F3A064C for ; Fri, 17 Apr 2020 05:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbIrX137anw0 for ; Fri, 17 Apr 2020 05:42:14 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53083A0640 for ; Fri, 17 Apr 2020 05:42:14 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 188so1035834pgj.13 for ; Fri, 17 Apr 2020 05:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=T25Bckq0Aj6ayIox588bnPtEV+yGyImkKDg+yJU5kd4=; b=g1bceUOuejjMEOdQPruMuCN2WgnhuIZYqFJFEnVuEEs5wglKqiEgYVWRzzXyBsayyG s9nrlxj/U9rkusNQ0s9PaOTJ9C0ybpluBsRkGE3FvwCVAooo7BQiBCd4s/Fwd1G9jRLf ufpTwY30e2QQngRoEQgZdGdKnl1/eHywUVKyia0XJAcOjt8eU6Pw7ALaC887qG1c6duU c3C5U6E4Jr/aIUIgdg4JKrIMPTCFX8QTqzMRQ9y1h8jiyluiZv87h3+qw54YNqSedVqG co5crkTdJ591S24zIdcbGQAkBYsF13d7RLANYThQS9Zm8m3THZFbGT3F2kK2doLS8IZ6 mXuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=T25Bckq0Aj6ayIox588bnPtEV+yGyImkKDg+yJU5kd4=; b=hNg7mQ4huYsdx3tv1NPB4vYR4+ohVfBO6T1ZH8rMowwLSyen8yeVJfXvcZBPt6UuUs FsyWZw5+Tdv4mHOyDZeRbuTtMP6Wxijncb6khsaQBCfgRonF3p1vJA1hWPyDAa0YbVO1 4Yi5yTj2Xx5L2N9CS5Zmq/2TQfHOmyo114qIQhktJeJbHV9hLNzKREkaGz9B7Toqd7iN U0wkbRzH4V9xLhwV3E8YVOBuBekuEWgC0lr3CM2EF+P1V22uQo9sMEMhO2BCAEzKLdQc Ivts+FPAdI167AlTXbBfQGYiAKSQ5LZz5OU2oNDBGRMbFFCT2DqGZCOk+QRiknQ0V5pO yNTQ== X-Gm-Message-State: AGi0PuYuk/BWki3+G+zRTojM2UyidElM5HHmvWH5iFZutxr3odttDXuv RdmltzEXp1NR8l5rqATOA1UwAhxx+E4= X-Google-Smtp-Source: APiQypK5T1yAw/aMRS5Pmdmh3pCIY+weHtKO15rFJg9uKxLDnHjQrZ597AqSuW+ctyJV6wb+iJ6gXA== X-Received: by 2002:a63:cd08:: with SMTP id i8mr2813026pgg.55.1587127333675; Fri, 17 Apr 2020 05:42:13 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id h11sm19522441pfn.125.2020.04.17.05.42.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 05:42:13 -0700 (PDT) To: Messaging Layer Security WG From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> Date: Fri, 17 Apr 2020 21:42:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] hardening MLS against bad randomness 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 Apr 2020 12:42:16 -0000 hey everyone, Sandro Coretti and I have the following suggestions around MLS's defenses against bad randomness. The Issue: Currently the (CGKA) protocol TreeKEM relies heavily on people continuously having good randomness available. The problem: Good randomness may not always be available though in which case things can go pretty wrong. E.g. Say, Alice does a Commit with too little entropy (from the adversaries perspective). This results in all new keys on her Direct Path (and the update_secret) having too little entropy because they are all derived deterministically *purely* from the entropy she samples in that procedure. To be clear, by "bad randomness" we're not just talking about low entropy because of an on-device attacks by an adversary. We also mean things like very deterministic boot process/environments. (E.g. on some VMs, embedded device or even sometimes mobiles.) There's also buggy RNGs. (Things like the Infineon keygen bug in the Estonian ID cards. Also the stuff in "Mining you Ps and Qs".) The point is, low entropy can be a practical concern even when an adversary can *not* access the rest of your local state. The fix: We thought of 2 types of fixes to reduce the dependence on continuous fresh entropy. General Fix ----------- Basic Idea: MLS explicitly mandates a local entropy pool. Whenever MLS needs random bytes (i.e. when doing KeyBundle gen, or a Commit) call the OS/crypto-lib to get some (supposed) random bytes B from outside. HKDF bytes B with your local entropy pool. First part of output overwrites your entropy pool. Second part are the bytes you actually pass on to the calling MLS function. This gives you 2 nice properties. First, you are accumulating any entropy B *may* have into your pool. So even with consistently low (but not 0) external entropy your pool fills up and eventually your good for ever more (till your state leaks of course). That's true even if your external calls start going back to 0 entropy (e.g. say you update to a buggy external RNG implementation or your in a VM and the OS is getting (poorly) initialized from some fixed snapshot but your apps local state is persistent). Second, if your pool leaks, then as soon as your OS/lib gives you enough good entropy again you back to having a good pool to. So you have PCS for leaked randomness. As long as either pool or external entropy are good the resulting being passed to MLS have enough entropy. Pro: general catch-all solution. efficient, easy to analyze. Con: requires implementors to handle cryptographically valuable randomness & probably, to hook calls from their crypto-libs; a new and maybe touchy practical requirement for implementors compared to what MLS currently asks of them. MLS Specific Fix ---------------- To avoid the above cons (and maybe others we didnt think of) here's an alternate solution approach using only already defined functions from the MLS spec. We demonstrate it on the case of a Commit as this is probably the most egregious case. (If Alice uses bad randomness it doesnt just "pollute" her own leaf like when she does an update proposal. It pollutes a whole chunk of the ratchet tree.) Basic idea: Whenever sampling/deriving a new secret key, make it also depend on the old secret key and on the application key schedule. That way, if either the old secret or application key schedule was secure, then so will the new one be *even when using bad randomness*. Mixing in the application key schedule is valuable if there was no old secret e.g. when we're assigning a new key pair to a previously blank node. For concreteness here's how that can work for the Commit operations (C.f. Section 5.4 in MLS protocol version 9) commit_secret = HKDF-Expand(epoch_secret, "mls 1.0 welcome", Hash.length) ---------- snip ----------- path_secret[0] = HKDF(leaf_hpke_secret||commit_secret, "path", "", Hash.Length) If node n on direct path is blank sk[n] := ciphersuite key length number of 0 bytes. Else sk[n] := old_node_priv[n] path_secret[n] = HKDF(path_secret[n-1]||sk[n], "path", "", Hash.Length) new_node_priv[n], new_node_pub[n] = Derive-Key-Pair(path_secret[n]) ---------- snip ----------- Pros: only uses existing MLS functions. other parties implicitly verify that the fix is being used by re-deriving same key material as commiter. no need to hook RNG calls. Con: less general so full fix requires changing other parts of MLS where security critical randomness is used. In particular, key bundle generation (or at least updating in an existing session). - Joël & Sandro From nobody Fri Apr 17 06:32:37 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 239ED3A088E for ; Fri, 17 Apr 2020 06:32: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 eiph3wXJxNdV for ; Fri, 17 Apr 2020 06:32: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 0E8563A088C for ; Fri, 17 Apr 2020 06:32:32 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id o10so1880161qtr.6 for ; Fri, 17 Apr 2020 06:32:32 -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=px4r3JtHnDiCKioRBQ203k821iioutm0zlp+0Gq74ZM=; b=oa6GrHFRdRwYwFHPw190MVXHiwfFXGbLJcUPFsSFHz78rhPBPHnwWLwbjHiUEfTHmV F2Eb5RkKE2PrD6aXg83udzp8wXMZ5ca9Ct1Cc3QgkTWM71+lniPTVkbOhjpS3B1ttnkK mEV/3IIZvAZuXgYwlHadroJRm2LaL+aNeDDrAAEqn1jW0buZL1//9xYkZ/K1PgspcVQG ylUxoqxjd4AaolNgT8hkQnZvKnkR+r9W0RhR1irDBSB0T9IQyjCPnM3//B64YbiD/2cg FiYz0WYJZdunWWfHAeXKlxDgRrXA3GdA1FSEKkHQbZ2jQub4SKww03IFW/tggVMSDOFH I9Lg== 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=px4r3JtHnDiCKioRBQ203k821iioutm0zlp+0Gq74ZM=; b=RrBqW0XojKaLOy1vOUUVfmm9j1cUrB11q0TxnQcpCL5U8Hl9eaKx1IjcI7daGJxKFg t1viwIbt6AqWdJD6HE/j9aKRPvlEeJjSNS3rAEHnbG1pXyswx5eRta5geP2aHQq8xgxw TRsHjJTLL42kepQxM0XG98ERV5aYsNuID2oj0YDtDmzclOzQNbOGcH24WtvuD52yLf11 HceGZCuSQTr/GdUdEF00AC3mNPRu+08dcgAGqFBvwKIygx2/LR4xJN1DEQ1SNrglShsU IEaBhwLG0B4ugwHz3pxWqktEwgzFKYOFLa2RoDc4RT7HtEN/QkWw5UDWJ5BDsR+hJR90 by4A== X-Gm-Message-State: AGi0PuY1yRztg44IwzRlOTMr6NX3+OPIY9vLhCryCwH4BdEnrqPZvRHn 8FdWdYNa8AwZqquiigMhWcMGe16BZM2TxdF+Z2hH4KRsgT0= X-Google-Smtp-Source: APiQypI8Y2uj9mli/yZoJTi1aeCz58m8oDQf1v2aCt3cLu04HUNhCN39bTn9wxxmv0ufOQPBpz7iya5BXVnU7XEtEZQ= X-Received: by 2002:ac8:6d23:: with SMTP id r3mr2845300qtu.84.1587130351807; Fri, 17 Apr 2020 06:32:31 -0700 (PDT) MIME-Version: 1.0 References: <17d24e72-c331-3a2d-3d33-5dfd59d069ab@wickr.com> In-Reply-To: <17d24e72-c331-3a2d-3d33-5dfd59d069ab@wickr.com> From: Richard Barnes Date: Fri, 17 Apr 2020 09:32:14 -0400 Message-ID: To: Joel Alwen Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d501a805a37c9480" Archived-At: Subject: Re: [MLS] somewhat better PCFS for cheap 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 Apr 2020 13:32:35 -0000 --000000000000d501a805a37c9480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jo=C3=ABl (and Sandro), Thanks for the thoughts. I agree that Option 2 makes sense. In fact, I think it agrees pretty much with what I was thinking, and the current doc is wrong. In particular, where it says "the HPKE secret key "leaf_hpke_secret"" in the text you quote, I would have expected that "leaf_hpke_secret" to be a secret from which the leaf HPKE private key was derived, basically the same as your pre-seed. One note to all this, though: None of this is visible to anyone except the holder of the leaf. So the other members of the group have to trust that the leaf holder is doing the right thing. The issue is the same as with decoherence higher up the path; either way, we lack a way to prove that two public keys correspond to private keys that are derived from sequential path secrets going up the tree. As before, I don't think this is fatal, and we should proceed. Do you want to draft a PR? --Richard On Fri, Apr 17, 2020 at 3:51 AM Joel Alwen wrote: > Hey Everyone, > > Sandro Coretti and I have the following suggestions for how "hash up the > tree" > during a Commit works. (C.f. Section 5.4 in MLS protocol version 9). The > goal is > to (cheaply) fix the FS of TreeKEM (ergo the PCFS of MLS). > > The Issue: Currently all new keys inserted into the ratchet tree in a > commit > (not to mention the resulting commit_secret) are all derived > deterministically > from leaf_hpke_secret of committer's new leaf key. That value is in turn > sampled > freshly at commit time by the committer. > > For concreteness: offending lines in mls-protocol-09 Pg. 17 > -------- snip ---------- > The generator of the Commit starts by using the HPKE secret key > "leaf_hpke_secret" associated with the new leaf KeyPackage (see > Section 7) to compute "path_secret[0]" and generate a sequence of > "path secrets", one for each ancestor of its leaf. > > path_secret[0] =3D HKDF-Expand-Label(leaf_hpke_secret, > "path", "", Hash.Length) > -------- snip ---------- > > The Problem: Suppose Alice commits. If her resulting leaf HPKE priv key > ever > leaks, the adversary learns all keys generated in her commit. Thing is, > thats > true even if all those keys have since been overwritten and removed from > her > state by the time her state leaks. Her leaf priv key alone is enough to > re-derive all of them. Zooming out a bit, for TreeKEM this means poorer F= S > than > need be. Zooming out further, for MLS we get poorer PCFS than need be. > > Proposed Solution: We say "poorer than need be" because there are many ea= sy > fixes here. E.g. > - Option 1 (simplicity) sample the HPKE leaf key pair using fresh random > bytes. > Also sample a "derive_secret" independently for doing the deterministic > deriving > up the tree. > - Option 2 (saves on consumed random bytes) sample a pre-seed. Expand it > (e.g. > with HKDF-Expand) to two independent secrets. Use one to generate HPKE > pub/priv > key pair for leaf. Use the other to do the hashing up the tree. (This is > how we > modeled TreeKEM in eprint/2019/1189.) > > Personally, I'm partial to 2 because, as a general rule of thumb, I like = to > conserve entropy demand. It can be a rare commodity in some deployments > and when > implementers start doing things like calling /dev/random instead of > /dev/urandom > you can end up depleting entropy. > > So, for concreteness how about this? > > -------- snip ---------- > pre-seed <-- {0,1}^secparam > > //first half of output goes in seed, second half in leaf_hpke_secret > seed, leaf_hpke_secret =3D HPKDF-Expand(pre-seed, "leafgen", > "", Hash.Length) > -------- snip ---------- > > leaf_hpke_priv, leaf_hpke_pub =3D Derive-Key-Pair(seed) > > > - Jo=C3=ABl & Sandro > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d501a805a37c9480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jo=C3=ABl (and Sandro),

T= hanks for the thoughts.=C2=A0 I agree that Option 2 makes sense.=C2=A0 In f= act, I think it agrees pretty much with what I was thinking, and the curren= t doc is wrong.=C2=A0 In particular, where it says "the HPKE secret ke= y "leaf_hpke_secret"" in the text you quote, I would have ex= pected that "leaf_hpke_secret" to be a secret from which the leaf= HPKE private key was derived, basically the same as your pre-seed.

One note to all this, though: None of this is visible= to anyone except the holder of the leaf.=C2=A0 So the other members of the= group have to trust that the leaf holder is doing the right thing.=C2=A0 T= he issue is the same as with decoherence higher up the path; either way, we= lack a way to prove that two public keys correspond to private keys that a= re derived from sequential path secrets going up the tree.=C2=A0 As before,= I don't think this is fatal, and we should proceed.

=
Do you want to draft a PR?

--Richard


On Fri, Apr 17, 2020 at 3:51 AM Joel Alwen <jalwen@wickr.com> wrote:
Hey Everyone,

Sandro Coretti and I have the following suggestions for how "hash up t= he tree"
during a Commit works. (C.f. Section 5.4 in MLS protocol version 9). The go= al is
to (cheaply) fix the FS of TreeKEM (ergo the PCFS of MLS).

The Issue: Currently all new keys inserted into the ratchet tree in a commi= t
(not to mention the resulting commit_secret) are all derived deterministica= lly
from leaf_hpke_secret of committer's new leaf key. That value is in tur= n sampled
freshly at commit time by the committer.

For concreteness: offending lines in mls-protocol-09 Pg. 17
-------- snip ----------
The generator of the Commit starts by using the HPKE secret key
"leaf_hpke_secret" associated with the new leaf KeyPackage (see Section 7) to compute "path_secret[0]" and generate a sequence of=
"path secrets", one for each ancestor of its leaf.

path_secret[0] =3D HKDF-Expand-Label(leaf_hpke_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 "path"= ;, "", Hash.Length)
-------- snip ----------

The Problem: Suppose Alice commits. If her resulting leaf HPKE priv key eve= r
leaks, the adversary learns all keys generated in her commit. Thing is, tha= ts
true even if all those keys have since been overwritten and removed from he= r
state by the time her state leaks. Her leaf priv key alone is enough to
re-derive all of them. Zooming out a bit, for TreeKEM this means poorer FS = than
need be. Zooming out further, for MLS we get poorer PCFS than need be.

Proposed Solution: We say "poorer than need be" because there are= many easy
fixes here. E.g.
=C2=A0- Option 1 (simplicity) sample the HPKE leaf key pair using fresh ran= dom bytes.
Also sample a "derive_secret" independently for doing the determi= nistic deriving
up the tree.
=C2=A0- Option 2 (saves on consumed random bytes) sample a pre-seed. Expand= it (e.g.
with HKDF-Expand) to two independent secrets. Use one to generate HPKE pub/= priv
key pair for leaf. Use the other to do the hashing up the tree. (This is ho= w we
modeled TreeKEM in eprint/2019/1189.)

Personally, I'm partial to 2 because, as a general rule of thumb, I lik= e to
conserve entropy demand. It can be a rare commodity in some deployments and= when
implementers start doing things like calling /dev/random instead of /dev/ur= andom
you can end up depleting entropy.

So, for concreteness how about this?

-------- snip ----------
pre-seed <-- {0,1}^secparam

//first half of output goes in seed, second half in leaf_hpke_secret
seed, leaf_hpke_secret =3D HPKDF-Expand(pre-seed, "leafgen",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "", Hash.Length)=
-------- snip ----------

leaf_hpke_priv, leaf_hpke_pub =3D Derive-Key-Pair(seed)


- Jo=C3=ABl & Sandro

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000d501a805a37c9480-- From nobody Fri Apr 17 07:02:28 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 80B0C3A07BD for ; Fri, 17 Apr 2020 07:02:26 -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, HTML_MESSAGE=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 H8HWU4ytMs2q for ; Fri, 17 Apr 2020 07:02:24 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEF93A092C for ; Fri, 17 Apr 2020 07:01:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C038E300B5E for ; Fri, 17 Apr 2020 10:01:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DW4AU6PrRJxB for ; Fri, 17 Apr 2020 10:01:12 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id B634F300A02; Fri, 17 Apr 2020 10:01:12 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B0833351-000A-46F4-852B-6FC3083946CB" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 17 Apr 2020 10:01:13 -0400 In-Reply-To: Cc: Messaging Layer Security WG To: Joel Alwen References: <17d24e72-c331-3a2d-3d33-5dfd59d069ab@wickr.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [MLS] somewhat better PCFS for cheap 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 Apr 2020 14:02:27 -0000 --Apple-Mail=_B0833351-000A-46F4-852B-6FC3083946CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mixing new and old is a clean solution. Thanks for writing it down so = clearly. Russ > On Apr 17, 2020, at 9:32 AM, Richard Barnes wrote: >=20 > Hi Jo=C3=ABl (and Sandro), >=20 > Thanks for the thoughts. I agree that Option 2 makes sense. In fact, = I think it agrees pretty much with what I was thinking, and the current = doc is wrong. In particular, where it says "the HPKE secret key = "leaf_hpke_secret"" in the text you quote, I would have expected that = "leaf_hpke_secret" to be a secret from which the leaf HPKE private key = was derived, basically the same as your pre-seed. >=20 > One note to all this, though: None of this is visible to anyone except = the holder of the leaf. So the other members of the group have to trust = that the leaf holder is doing the right thing. The issue is the same as = with decoherence higher up the path; either way, we lack a way to prove = that two public keys correspond to private keys that are derived from = sequential path secrets going up the tree. As before, I don't think = this is fatal, and we should proceed. >=20 > Do you want to draft a PR? >=20 > --Richard >=20 >=20 > On Fri, Apr 17, 2020 at 3:51 AM Joel Alwen > wrote: > Hey Everyone, >=20 > Sandro Coretti and I have the following suggestions for how "hash up = the tree" > during a Commit works. (C.f. Section 5.4 in MLS protocol version 9). = The goal is > to (cheaply) fix the FS of TreeKEM (ergo the PCFS of MLS). >=20 > The Issue: Currently all new keys inserted into the ratchet tree in a = commit > (not to mention the resulting commit_secret) are all derived = deterministically > from leaf_hpke_secret of committer's new leaf key. That value is in = turn sampled > freshly at commit time by the committer. >=20 > For concreteness: offending lines in mls-protocol-09 Pg. 17 > -------- snip ---------- > The generator of the Commit starts by using the HPKE secret key > "leaf_hpke_secret" associated with the new leaf KeyPackage (see > Section 7) to compute "path_secret[0]" and generate a sequence of > "path secrets", one for each ancestor of its leaf. >=20 > path_secret[0] =3D HKDF-Expand-Label(leaf_hpke_secret, > "path", "", Hash.Length) > -------- snip ---------- >=20 > The Problem: Suppose Alice commits. If her resulting leaf HPKE priv = key ever > leaks, the adversary learns all keys generated in her commit. Thing = is, thats > true even if all those keys have since been overwritten and removed = from her > state by the time her state leaks. Her leaf priv key alone is enough = to > re-derive all of them. Zooming out a bit, for TreeKEM this means = poorer FS than > need be. Zooming out further, for MLS we get poorer PCFS than need be. >=20 > Proposed Solution: We say "poorer than need be" because there are many = easy > fixes here. E.g. > - Option 1 (simplicity) sample the HPKE leaf key pair using fresh = random bytes. > Also sample a "derive_secret" independently for doing the = deterministic deriving > up the tree. > - Option 2 (saves on consumed random bytes) sample a pre-seed. Expand = it (e.g. > with HKDF-Expand) to two independent secrets. Use one to generate HPKE = pub/priv > key pair for leaf. Use the other to do the hashing up the tree. (This = is how we > modeled TreeKEM in eprint/2019/1189.) >=20 > Personally, I'm partial to 2 because, as a general rule of thumb, I = like to > conserve entropy demand. It can be a rare commodity in some = deployments and when > implementers start doing things like calling /dev/random instead of = /dev/urandom > you can end up depleting entropy. >=20 > So, for concreteness how about this? >=20 > -------- snip ---------- > pre-seed <-- {0,1}^secparam >=20 > //first half of output goes in seed, second half in leaf_hpke_secret > seed, leaf_hpke_secret =3D HPKDF-Expand(pre-seed, "leafgen", > "", = Hash.Length) > -------- snip ---------- >=20 > leaf_hpke_priv, leaf_hpke_pub =3D Derive-Key-Pair(seed) >=20 >=20 > - Jo=C3=ABl & Sandro >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_B0833351-000A-46F4-852B-6FC3083946CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mixing new and old is a clean solution.  Thanks for = writing it down so clearly.

Russ

On Apr 17, 2020, at 9:32 AM, = Richard Barnes <rlb@ipv.sx> wrote:

Hi Jo=C3=ABl (and Sandro),

Thanks for the = thoughts.  I agree that Option 2 makes sense.  In fact, I = think it agrees pretty much with what I was thinking, and the current = doc is wrong.  In particular, where it says "the HPKE secret key = "leaf_hpke_secret"" in the text you quote, I would have expected that = "leaf_hpke_secret" to be a secret from which the leaf HPKE private key = was derived, basically the same as your pre-seed.

One note to all this, = though: None of this is visible to anyone except the holder of the = leaf.  So the other members of the group have to trust that the = leaf holder is doing the right thing.  The issue is the same as = with decoherence higher up the path; either way, we lack a way to prove = that two public keys correspond to private keys that are derived from = sequential path secrets going up the tree.  As before, I don't = think this is fatal, and we should proceed.

Do you want to draft a = PR?

--Richard


On Fri, Apr 17, 2020 at 3:51 AM Joel Alwen <jalwen@wickr.com> = wrote:
Hey Everyone,

Sandro Coretti and I have the following suggestions for how "hash up the = tree"
during a Commit works. (C.f. Section 5.4 in MLS protocol version 9). The = goal is
to (cheaply) fix the FS of TreeKEM (ergo the PCFS of MLS).

The Issue: Currently all new keys inserted into the ratchet tree in a = commit
(not to mention the resulting commit_secret) are all derived = deterministically
from leaf_hpke_secret of committer's new leaf key. That value is in turn = sampled
freshly at commit time by the committer.

For concreteness: offending lines in mls-protocol-09 Pg. 17
= -------- snip ----------
The generator of the Commit starts by using the HPKE secret key
"leaf_hpke_secret" associated with the new leaf KeyPackage (see
Section 7) to compute "path_secret[0]" and generate a sequence of
"path secrets", one for each ancestor of its leaf.

path_secret[0] =3D HKDF-Expand-Label(leaf_hpke_secret,
                    =                   "path", = "", Hash.Length)
-------- snip ----------

The Problem: Suppose Alice commits. If her resulting leaf HPKE priv key = ever
leaks, the adversary learns all keys generated in her commit. Thing is, = thats
true even if all those keys have since been overwritten and removed from = her
state by the time her state leaks. Her leaf priv key alone is enough = to
re-derive all of them. Zooming out a bit, for TreeKEM this means poorer = FS than
need be. Zooming out further, for MLS we get poorer PCFS than need = be.

Proposed Solution: We say "poorer than need be" because there are many = easy
fixes here. E.g.
 - Option 1 (simplicity) sample the HPKE leaf key pair using fresh = random bytes.
Also sample a "derive_secret" independently for doing the deterministic = deriving
up the tree.
 - Option 2 (saves on consumed random bytes) sample a pre-seed. = Expand it (e.g.
with HKDF-Expand) to two independent secrets. Use one to generate HPKE = pub/priv
key pair for leaf. Use the other to do the hashing up the tree. (This is = how we
modeled TreeKEM in eprint/2019/1189.)

Personally, I'm partial to 2 because, as a general rule of thumb, I like = to
conserve entropy demand. It can be a rare commodity in some deployments = and when
implementers start doing things like calling /dev/random instead of = /dev/urandom
you can end up depleting entropy.

So, for concreteness how about this?

-------- snip ----------
pre-seed <-- {0,1}^secparam

//first half of output goes in seed, second half in leaf_hpke_secret
seed, leaf_hpke_secret =3D HPKDF-Expand(pre-seed, "leafgen",
                    =                     =                 "", = Hash.Length)
-------- snip ----------

leaf_hpke_priv, leaf_hpke_pub =3D Derive-Key-Pair(seed)


- Jo=C3=ABl & Sandro

_______________________________________________
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=_B0833351-000A-46F4-852B-6FC3083946CB-- From nobody Fri Apr 17 07:40: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 6FB8A3A0AD8 for ; Fri, 17 Apr 2020 07:40:47 -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 5xtUmBWFh6OT for ; Fri, 17 Apr 2020 07:40:45 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 984773A0AD5 for ; Fri, 17 Apr 2020 07:40:45 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id 20so2554684qkl.10 for ; Fri, 17 Apr 2020 07:40: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=vsR8PgL41Yg2kT/kLzfBuWx2nzKHgcFsYEF8BBNbnvw=; b=sWJjl7zWmM/s8sZsJJE2SwU587UP17O9Chgav7T2/tPOltS+dImf4fKNCVeYkMXRWe V09J7xpp0W3YqSZQPDyxWea2QF3x9eSKKwhPx7EOoszVmKB6+mqX/ocvTf9ewfiIcdLl ZUkMHa7baWrW7hs+V+bKRYflrZpnycSoWq+V0vuUFXxDYU4ElwpAkRF3mdC8kYLDUp64 EXKvLoA00TAJRhNEbeZSwd6D7m5zcq8QqydB94AW3r+fQ/XLEHfrwlSJ9D9HfqIiEb4c HKcQ5lINEE5ou1Ka4cQHd/yOFCgNLDb51quGXvBCXB/vFJaLU18x8zwjVksv0AgbEjkW ENKg== 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=vsR8PgL41Yg2kT/kLzfBuWx2nzKHgcFsYEF8BBNbnvw=; b=bCG7SWqta3JdxxHF3n7c0RG1pCBOY+TzesGQoJuZUu6rli/dRxBWBObNOBnUnuxojZ f5RHI8lEkCyCLOaYXPeCcEBi+NAvSLeHhtQreTDtZxl5V7Kja7EC+ChGCIHcXvlQTt++ aOf3vAhiQ7z29rIJ/Ni2Fg0YU/wXEz8p/rNokEoXt/CHhBiJxpQ8ou+FakR+c17pSIR3 nkBCjRzrF2Y4GW54ZzLjG9SKwXfYsEAnqRftsv9fV3n94ZnBA0kwGkTlnEN6T7AnxXpl GVWEcmnm9q7QsvM6Wk7S8q5uvlmIpPkrnoOqRykXFhb471S8A4DWKubo4IOVa+AhZcmr 8SzQ== X-Gm-Message-State: AGi0PuYhnoK0gI7UoAnGtHIx3mkzdQzlaCe3UTwOMI2/1+VrdCk/rv33 l6M3kLfa0M+DZE3BuAn1pG57MVJxuWwiBZ9wcj3nw14i X-Google-Smtp-Source: APiQypKhfjjPoqborYiKxVv4mt0uPV6sH6IA+kxrzaDnw7ZyFGCxZhVEzD3dm9dWC3wsACQcqTbOlVQLraDIYnAGqX4= X-Received: by 2002:a37:9f4a:: with SMTP id i71mr3529804qke.132.1587134444104; Fri, 17 Apr 2020 07:40:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Fri, 17 Apr 2020 10:40:26 -0400 Message-ID: To: Joel Alwen Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000c07d3405a37d88cd" Archived-At: Subject: Re: [MLS] reusing HPKE keys from welcome messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 14:40:48 -0000 --000000000000c07d3405a37d88cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This seems like a reasonable trade-off in terms of performance. There are some mechanical issues to address because we use the same KeyPackage struct for initialization and for leaves in the tree. In particular, if we have both "WelcomeKey" and "LeafKey" in the package, we probably don't want the leaves to keep making new WelcomeKeys forever. I think that's adequately addressed, though, by just putting the WelcomeKey in an extension, and requiring that extension to be present in KeyPackages used for initialization. Alternatively, it seems like this issue could be papered over operationally if a member updates on joining. That would push the expense to join time instead of KP generation time. I don't think this is a great trade-off, though, just wanted to document it. --Richard On Fri, Apr 17, 2020 at 3:48 AM Joel Alwen wrote: > Hey Everyone, > > Sandro Coretti and I have a few suggestions. To keep threads on the list > topic > specific I'm putting the suggestions in separate emails so please excuse > the > spam. Here goes. > > Issue: HPKE Key Reuse > Suppose Alice (commits to a proposal that) invites Bob to a group. For > this she > uses a Key Bundle for Bob with an HPKE pub key in it. That pub key has 2 > functions (and correct me if I'm wrong here). On the one it becomes the > HPKE key > in Bob's leaf in the new ratchet tree. On the other hand, the Welcome > message to > Bob is also encrypted to that HPKE key. > > Problem: Bob must keep around the corresponding HPKE secret until he > updates or > leaves the group. Thing is, that same HPKE sec key lets you reprocess tha= t > welcome message. Ergo, until he does an update we have no FS for all MLS > epochs > after his join. (See PS. at end of email for more.) > > Proposed Solution: Separate HPKE keys for welcome message and initial lea= f > key. > E.g. Key Bundles registered on the Key Server have two HPKE keys. One for > the > welcome message only and the other used as new leaf's HPKE key. As soon a= s > Bob > processes the welcome message he deletes the HPKE key he used for it. > > > Thoughts? > > - Jo=C3=ABl & Sandro > > > > PS. For those familiar, this is basically a special case of the FS issues > with > TreeKEM we address with RTreeKEM in eprint/2019/1189. But normally attack= s > on > the FS of some TreeKEM epoch msg still requires u to somehow know the > previous > epochs init_secret. Thats why, normally, FS attacks on TreeKEM "only" > translate > to PCFS attacks on MLS. But for the welcome message variant that's > different. > The whole point of the welcome message is to bootstrap from that one HPKE > secret > key all the way to full-state MLS (including current key schedule). So th= e > attacker no longer needs an extra init_secret if they leak that one HPKE > secret > key. Thus, this goes from the usual PCFS attack for MLS to being a plain > FS one. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c07d3405a37d88cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems like a reasonable trade-off in terms of pe= rformance.=C2=A0 There are some mechanical issues to address because we use= the same KeyPackage struct for initialization and for leaves in the tree.= =C2=A0 In particular, if we have both "WelcomeKey" and "Leaf= Key" in the package, we probably don't want the leaves to keep mak= ing new WelcomeKeys forever.

I think that'= s adequately addressed, though, by just putting the WelcomeKey in an extens= ion, and requiring that extension to be present in KeyPackages used for ini= tialization.

Alternatively, it seems like this iss= ue could be papered over operationally if a member updates on joining.=C2= =A0 That would push the expense to join time instead of KP generation time.= =C2=A0 I don't think this is a great trade-off, though, just wanted to = document it.

--Richard


On = Fri, Apr 17, 2020 at 3:48 AM Joel Alwen <jalwen@wickr.com> wrote:
Hey Everyone,

Sandro Coretti and I have a few suggestions. To keep threads on the list to= pic
specific I'm putting the suggestions in separate emails so please excus= e the
spam. Here goes.

Issue: HPKE Key Reuse
Suppose Alice (commits to a proposal that) invites Bob to a group. For this= she
uses a Key Bundle for Bob with an HPKE pub key in it. That pub key has 2 functions (and correct me if I'm wrong here). On the one it becomes the= HPKE key
in Bob's leaf in the new ratchet tree. On the other hand, the Welcome m= essage to
Bob is also encrypted to that HPKE key.

Problem: Bob must keep around the corresponding HPKE secret until he update= s or
leaves the group. Thing is, that same HPKE sec key lets you reprocess that<= br> welcome message. Ergo, until he does an update we have no FS for all MLS ep= ochs
after his join. (See PS. at end of email for more.)

Proposed Solution: Separate HPKE keys for welcome message and initial leaf = key.
E.g. Key Bundles registered on the Key Server have two HPKE keys. One for t= he
welcome message only and the other used as new leaf's HPKE key. As soon= as Bob
processes the welcome message he deletes the HPKE key he used for it.


Thoughts?

- Jo=C3=ABl & Sandro



PS. For those familiar, this is basically a special case of the FS issues w= ith
TreeKEM we address with RTreeKEM in eprint/2019/1189. But normally attacks = on
the FS of some TreeKEM epoch msg still requires u to somehow know the previ= ous
epochs init_secret. Thats why, normally, FS attacks on TreeKEM "only&q= uot; translate
to PCFS attacks on MLS. But for the welcome message variant that's diff= erent.
The whole point of the welcome message is to bootstrap from that one HPKE s= ecret
key all the way to full-state MLS (including current key schedule). So the<= br> attacker no longer needs an extra init_secret if they leak that one HPKE se= cret
key. Thus, this goes from the usual PCFS attack for MLS to being a plain FS= one.

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000c07d3405a37d88cd-- From nobody Sun Apr 19 18:03:11 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 029C13A0B23 for ; Sun, 19 Apr 2020 18:03:10 -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 mHffpxqyFT9M for ; Sun, 19 Apr 2020 18:03:08 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 9537D3A0B24 for ; Sun, 19 Apr 2020 18:03:08 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id v38so3931826qvf.6 for ; Sun, 19 Apr 2020 18:03:08 -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=z155HpCB7N//JCy808hv3YrjbPPViQq7Gczc4zRJUcY=; b=jrrO+r3D3evF0Mxdb7TA1GIlBS3GQ8D+uuJ6w/w5Lf5D8SKt6uJrIsGm5DKTtanqtY O+YRHL0rbEOEsidfBg1DG5Og01N/phAzNUJyB1+zY63Ttcyn6g1PE5m7hIFbwWd1153n 9VB8LfDFXbK/JxO7cMkOVVNXVRagU7sEX/ot4= 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=z155HpCB7N//JCy808hv3YrjbPPViQq7Gczc4zRJUcY=; b=f+t3P7I/eYFb3YIMymCaIu6ILp5/NJPSQlRKdv1VdW0CVWXqO2TAoXeA4ibuEA2PIm jYUFRjjexnzIrF2CwOSgANpM+/P1oWHxlsJUwh2Jl2D5LrCcmdfrDDhDvSWhmScLeBWB 378v0c5WPqKyMmRKIayg8RnextMAn3OUIkQhU63daVNSrUDr1jn25gyPNqHNTt2MeYL3 OHq8dO9LaCXhGO9DuwrOyicQdVzijKsW6xRvryqliDLV5mB1XHXklELD0ZBdFdHjhNz7 WrTG4YkFu95pDiJvmq/wtlQC4pi3cZnDxHRC1Vpd/kMXAlBmx1EYj52XELCEd1gRdWVu KI8g== X-Gm-Message-State: AGi0PuYC/70u1IYjLej0MuTNIJ2vFHaZdgozpTcyOvZydDwqxfjX/Atv jM2pea7AvyWKj20SQ6/llSUbHiVHWgo= X-Google-Smtp-Source: APiQypKh3M5FksviRd86QaQ+W5IaKWrFDUJfvXLvvspUi5JA1eu7S9SsCP2qfaav2dtUdTmnjDCZWg== X-Received: by 2002:a0c:b503:: with SMTP id d3mr13102366qve.176.1587344587155; Sun, 19 Apr 2020 18:03:07 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id r128sm21755214qke.95.2020.04.19.18.03.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2020 18:03:06 -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.80.23.2.2\)) Date: Sun, 19 Apr 2020 21:03:05 -0400 References: <158652446121.19076.15530618640349687988@ietfa.amsl.com> To: MLS List In-Reply-To: <158652446121.19076.15530618640349687988@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-04-21 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 Apr 2020 01:03:10 -0000 hi MLS, We have a virtual meeting scheduled for Tuesday. The agenda has been = posted to the ietf datatracker and is also available viaa the GitHub = repo: https://github.com/mlswg/wg-materials/tree/master/vietf107 You will note that the agenda is fairly light on detail, but the plan = all along has been to review the open issues and pull requests and work = through them. Britta/Konrad did request 15min to discuss some changes = related to a PR, but I think we can work that during PR reviews. Also, we need a minute taker so if you=E2=80=99re interested taking = minutes please let us know. spt > On Apr 10, 2020, at 09:14, IESG Secretary = wrote: >=20 > The Messaging Layer Security (mls) Working Group will hold > a virtual interim meeting on 2020-04-21 from 14:00 to 15:30 = America/New_York (18:00 to 19:30 UTC). >=20 > Agenda: > # Protocol > # Architecture > # AOB >=20 >=20 > Information about remote participation: > = https://ietf.webex.com/ietf/j.php?MTID=3Dm92ea16ea97a73422258dbd600c056a27= >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Tue Apr 21 10:32: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 60C7D3A07E1 for ; Tue, 21 Apr 2020 10:32:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 lvIDYgilUBc2 for ; Tue, 21 Apr 2020 10:32:48 -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 38D9C3A07CB for ; Tue, 21 Apr 2020 10:32:48 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id c16so12307867qtv.1 for ; Tue, 21 Apr 2020 10:32:47 -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=xFfZ4KXoo8w9rb+LNe2Nlpc1K1vEuMCrXUS/Kkm5fe4=; b=W9fNpvbRVUSXve3C34+KDfxkSp1ykJFpRyp5RuPF+o71xkd8APN6CaBTwD5ORkkUEB b3FPEQXIWoWyiRbLilgg3F+dYteNAZGN6KecBZPg6mDv/u8QEkfYMckeK3mbaDEaD102 NPvxQDOuLeKZgj2zsMGk1HoknyqvP8J74vruM= 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=xFfZ4KXoo8w9rb+LNe2Nlpc1K1vEuMCrXUS/Kkm5fe4=; b=X2Y1KjMi5YmHUC73x1Bcg+MLxWfc1mCgxvT/Lbi6AjpR3nPHOf0stxw8Gh1IgRb9CC zdJcaab4E+y6e9XZi9Vj36lKfiHVR+iGdL9UYtXLYzUp2TqOMviJkssnXdyntrEDAvre 0tIDpchEE6/m2Ekyatgdy66cUz/VyQXVBSYMgYhDyt7I9T9wW9wCfAwWPp8Uqw8R46T/ 4ucRoCsuOdAEf9udZ+X1T1KfeaI6qWOslmYwa59rZ6M/xc2hwID0lSwEy8emGtpyeUFf qFY48ZBvfS8+PxY+GKQliHjUwOGo5v3Kuyv864jOI3Hi8cRPHUZmj4xPnUstzvUg1oAe s6lQ== X-Gm-Message-State: AGi0PuZo9pTo/FQDTGvZu6w80hnTxM2JNsQZNFMHRBILnqfyvOYsaPx0 VUAytw8FDahUbMkMUoX7/fjbI0gHsmU= X-Google-Smtp-Source: APiQypL/U7jZffFkb28VIiSV4vSj1+6m/L/G+ITG0G+0gmI/vuqz7ngg3fO1bJTC6DgiD0MGM1eZnw== X-Received: by 2002:aed:221c:: with SMTP id n28mr20736704qtc.235.1587490364370; Tue, 21 Apr 2020 10:32:44 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id m187sm2135619qkc.30.2020.04.21.10.32.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 10:32: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.80.23.2.2\)) Date: Tue, 21 Apr 2020 13:32:43 -0400 References: <158652446121.19076.15530618640349687988@ietfa.amsl.com> To: MLS List In-Reply-To: Message-Id: <5F278B10-3964-4E24-A34D-CDDD91650962@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-04-21 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, 21 Apr 2020 17:32:51 -0000 The session will begin at the top of the hour. Webex: = https://ietf.webex.com/ietf/j.php?MTID=3Dm92ea16ea97a73422258dbd600c056a27= Etherpad: = https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-mls-11?useMonospa= ceFont=3Dtrue spt > On Apr 19, 2020, at 21:03, Sean Turner wrote: >=20 > hi MLS, >=20 > We have a virtual meeting scheduled for Tuesday. The agenda has been = posted to the ietf datatracker and is also available viaa the GitHub = repo: https://github.com/mlswg/wg-materials/tree/master/vietf107 >=20 > You will note that the agenda is fairly light on detail, but the plan = all along has been to review the open issues and pull requests and work = through them. Britta/Konrad did request 15min to discuss some changes = related to a PR, but I think we can work that during PR reviews. >=20 > Also, we need a minute taker so if you=E2=80=99re interested taking = minutes please let us know. >=20 > spt >=20 >> On Apr 10, 2020, at 09:14, IESG Secretary = wrote: >>=20 >> The Messaging Layer Security (mls) Working Group will hold >> a virtual interim meeting on 2020-04-21 from 14:00 to 15:30 = America/New_York (18:00 to 19:30 UTC). >>=20 >> Agenda: >> # Protocol >> # Architecture >> # AOB >>=20 >>=20 >> Information about remote participation: >> = https://ietf.webex.com/ietf/j.php?MTID=3Dm92ea16ea97a73422258dbd600c056a27= >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From nobody Tue Apr 21 12:37: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 0B3E53A08C1 for ; Tue, 21 Apr 2020 12:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_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=heapingbits.net header.b=eTVwcGZ/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jG1w3Yqm 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 D4wfZOyM7tEx for ; Tue, 21 Apr 2020 12:37:31 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163C23A088D for ; Tue, 21 Apr 2020 12:37:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F0BF65C007C for ; Tue, 21 Apr 2020 15:37:29 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 15:37:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=LiVEz DSVBonuefb0d2LuMReTZCH61TyFFcmJ35q8amM=; b=eTVwcGZ/qvoi1E5MWAyXQ MZLD+wmoL538sRPk1mR9qTOm2sBw8+tHjaxs7DWS63aIu+S1hC+bJG7rDhJkIt8F iWoc4WnhpoL05G0jLle39MGihlf7XzqK05n0aB9GmOgh1HAGXEKgs4x0y39FcVAv Iz/VQMogBaLXfR8w/UXGDUlsgUIcxbmqr///S1DUVsO8pcEiAmxnGKa54kC6yEd9 YJGA5VIfvTNcKgPHo6fd6ctzA+6v6G+fgVc0f9+caGGy0bmhAnFP05wKGkjObQ4g rZ3vlDthy8UmDpWOrm6cIIxnFRPPEbS0dJP5N67CeAE2hZef86LqtBVs5opnm0jX Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=LiVEzDSVBonuefb0d2LuMReTZCH61TyFFcmJ35q8a mM=; b=jG1w3YqmrTrE5/X/dpzbyiydJRRZm0FQzppgZBDWEgRjK89bdtJQbqRux 0+bcSJPgFGTe9/zRXfmDYVR+JCKFWKb1butreP5Z0lw/sLSTEQANtnwiDbtuoBHg dMDx2l4iGv8NOYh9Hi1TXYvC03TCvrV+z66R3ceLJwZWiRfMvaRB5sz/yv2wdFhS yzGdLNjA0Coy3HzT/S6z8PbSDQx9YAw73yyHU6S03esA/6nicrOc/hN9ObhMy/59 GAtRcPO0gC4OdE9PSkoazJOjmc7DuPVuh8ZAp7BqP1R7Lr/XksaZGT88CVQLSCrq wVU6qJp23jzOI72U9XXb1Av4AX+2A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgif sehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 799DA180093; Tue, 21 Apr 2020 15:37:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <6c40ac86-5861-4617-97c8-fa960f66943f@www.fastmail.com> In-Reply-To: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> Date: Tue, 21 Apr 2020 12:37:09 -0700 From: "Christopher Wood" To: mls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 21 Apr 2020 19:37:45 -0000 For what it's worth, I lean towards the general fix. This doesn't seem t= o be a protocol issue, so mitigating it with a protocol-specific fix doe= sn't seem ideal.=20 Best, Chris On Fri, Apr 17, 2020, at 5:42 AM, Joel Alwen wrote: > hey everyone, >=20 > Sandro Coretti and I have the following suggestions around MLS's defen= ses > against bad randomness. >=20 > The Issue: Currently the (CGKA) protocol TreeKEM relies heavily on peo= ple > continuously having good randomness available. >=20 > The problem: Good randomness may not always be available though in whi= ch case > things can go pretty wrong. E.g. Say, Alice does a Commit with too lit= tle > entropy (from the adversaries perspective). This results in all new ke= ys on her > Direct Path (and the update_secret) having too little entropy because = they are > all derived deterministically *purely* from the entropy she samples in= that > procedure. >=20 > To be clear, by "bad randomness" we're not just talking about low entr= opy > because of an on-device attacks by an adversary. We also mean things l= ike very > deterministic boot process/environments. (E.g. on some VMs, embedded d= evice or > even sometimes mobiles.) There's also buggy RNGs. (Things like the Inf= ineon > keygen bug in the Estonian ID cards. Also the stuff in "Mining you Ps = and Qs".) > The point is, low entropy can be a practical concern even when an adve= rsary can > *not* access the rest of your local state. >=20 > The fix: We thought of 2 types of fixes to reduce the dependence on co= ntinuous > fresh entropy. >=20 > General Fix > ----------- > Basic Idea: MLS explicitly mandates a local entropy pool. >=20 > Whenever MLS needs random bytes (i.e. when doing KeyBundle gen, or a C= ommit) > call the OS/crypto-lib to get some (supposed) random bytes B from outs= ide. HKDF > bytes B with your local entropy pool. First part of output overwrites = your > entropy pool. Second part are the bytes you actually pass on to the ca= lling MLS > function. >=20 > This gives you 2 nice properties. First, you are accumulating any entr= opy B > *may* have into your pool. So even with consistently low (but not 0) e= xternal > entropy your pool fills up and eventually your good for ever more (til= l your > state leaks of course). That's true even if your external calls start = going back > to 0 entropy (e.g. say you update to a buggy external RNG implementati= on or your > in a VM and the OS is getting (poorly) initialized from some fixed sna= pshot but > your apps local state is persistent). Second, if your pool leaks, then= as soon > as your OS/lib gives you enough good entropy again you back to having = a good > pool to. So you have PCS for leaked randomness. As long as either pool= or > external entropy are good the resulting being passed to MLS have enoug= h entropy. >=20 > Pro: general catch-all solution. efficient, easy to analyze. > Con: requires implementors to handle cryptographically valuable random= ness & > probably, to hook calls from their crypto-libs; a new and maybe touchy= practical > requirement for implementors compared to what MLS currently asks of th= em. >=20 >=20 > MLS Specific Fix > ---------------- > To avoid the above cons (and maybe others we didnt think of) here's an= =20 > alternate > solution approach using only already defined functions from the MLS=20= > spec. We > demonstrate it on the case of a Commit as this is probably the most=20= > egregious > case. (If Alice uses bad randomness it doesnt just "pollute" her own=20= > leaf like > when she does an update proposal. It pollutes a whole chunk of the=20 > ratchet tree.) >=20 > Basic idea: Whenever sampling/deriving a new secret key, make it also = depend on > the old secret key and on the application key schedule. That way, if e= ither the > old secret or application key schedule was secure, then so will the ne= w one be > *even when using bad randomness*. Mixing in the application key schedu= le is > valuable if there was no old secret e.g. when we're assigning a new ke= y pair to > a previously blank node. >=20 > For concreteness here's how that can work for the Commit operations (C= .f. > Section 5.4 in MLS protocol version 9) >=20 > commit_secret =3D HKDF-Expand(epoch_secret, "mls 1.0 welcome", Hash.le= ngth) >=20 > ---------- snip ----------- > path_secret[0] =3D HKDF(leaf_hpke_secret||commit_secret, "path", > "", Hash.Length) >=20 > If node n on direct path is blank > sk[n] :=3D ciphersuite key length number of 0 bytes. > Else > sk[n] :=3D old_node_priv[n] > =09 > path_secret[n] =3D HKDF(path_secret[n-1]||sk[n], "path", "", Hash.Leng= th) >=20 > new_node_priv[n], new_node_pub[n] =3D Derive-Key-Pair(path_secret[n]) > ---------- snip ----------- >=20 > Pros: only uses existing MLS functions. other parties implicitly verif= y that the > fix is being used by re-deriving same key material as commiter. no nee= d to hook > RNG calls. >=20 > Con: less general so full fix requires changing other parts of MLS whe= re > security critical randomness is used. In particular, key bundle genera= tion (or > at least updating in an existing session). >=20 >=20 > - Jo=C3=ABl & Sandro >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Tue Apr 21 12:47:41 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F153F3A08FC for ; Tue, 21 Apr 2020 12:47:38 -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 pJg-mt9c_2GZ for ; Tue, 21 Apr 2020 12:47:35 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04183A0902 for ; Tue, 21 Apr 2020 12:47:05 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id w29so12657706qtv.3 for ; Tue, 21 Apr 2020 12:47:05 -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=3Nw4hSmQCvYiX6I3ag5JvibMizxAkPXB+QIRbA2ooTk=; b=GXkFO9KLJRrGP7o7zszT4AHbSALdi+Ps9jV5+B0VG3cyq2nmTbJkMknvNA5WTb4s5C 7cLovxv5Cg5oG0sC2osVH7zEPAv/CHdiNznBjqv/aVi7uWY/EI1TMIlwc8BsIFmaFzCS 8gBbVze1IQCtcB5ecPdlLtFRTa4iIGrHT5RFDuZn5S/C16zuCTAb4KVj23Dk8glctBvv Ffum3ZcatV/LoOlvMQhioPbmssNdJxgJuFmeL+Ga0DPtasuuDzncJhxkOb6QYevhzvw6 XRmRQ9NDbOzOhWTvEqi17j8OECG7ZmUZDN9XggCxmgXiMj2ZYVmCcXXbVIqp2d/aoTal 5HeQ== 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=3Nw4hSmQCvYiX6I3ag5JvibMizxAkPXB+QIRbA2ooTk=; b=j3LGDwi8czvxjDe7tY4ybzeUmWEMhJj+wfvyHwYWpQExnxuZC8OFnLQBpK08aIAPWQ c9Cl8xFf3M38wmolk5+ys+ZBhmIqB0pCFFhy451vXvrly1wUg54KaISkqgnR0jdZzWw4 6BVxngGrtvbN5c4+u8kYh4L/YmIivV/etiNHd5in1yMZOb/Nrhrv1FxqYOVCuaEtKs6t ezaHqzYf8imjRQhOy1vorXmZ9QHYCqGO9GIQkF/FqnNxywnHJYPQEinMY0JJKSV+OU7v BIZUYPSqRvRjgxDhYo8z1/WiPaOTMAmya7KUVYCosakPy2Dk7c07SzNf/ArwxAOo44Kd jPug== X-Gm-Message-State: AGi0PuYAW5jWdlKeI+I8IHCk2a5EMRyzRh3k1lxdVdWpX0puldqugFwD iDgEpO4S7hAuXz174O5b5YKzjUo7IHbY3aiAp8e6eTdV X-Google-Smtp-Source: APiQypKYxxbo1NehPvBocDClep81lWPTf9TKJ5z0NgL7Y08D+RQrvoQLFITJVJXSdSHhGe4IxH/eALDOUPQjzP8No5g= X-Received: by 2002:ac8:764e:: with SMTP id i14mr9162096qtr.191.1587498419636; Tue, 21 Apr 2020 12:46:59 -0700 (PDT) MIME-Version: 1.0 References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> In-Reply-To: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> From: Richard Barnes Date: Tue, 21 Apr 2020 15:46:37 -0400 Message-ID: To: Joel Alwen Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000062633b05a3d24729" Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 21 Apr 2020 19:47:39 -0000 --00000000000062633b05a3d24729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jo=C3=ABl, Thanks for thinking about this, and for the reminder on the call. I'm inclined to say that this is not a matter for the MLS spec. It's not a protocol / interoperability issue, it's a consideration for how you build your client. So I definitely would rather go for the general fix. If some better platform guidance is needed, run it through CFRG. Maybe describe the implications of bad randomness in the Security Considerations to the protocol. --Richard On Fri, Apr 17, 2020 at 8:42 AM Joel Alwen wrote: > hey everyone, > > Sandro Coretti and I have the following suggestions around MLS's defenses > against bad randomness. > > The Issue: Currently the (CGKA) protocol TreeKEM relies heavily on people > continuously having good randomness available. > > The problem: Good randomness may not always be available though in which > case > things can go pretty wrong. E.g. Say, Alice does a Commit with too little > entropy (from the adversaries perspective). This results in all new keys > on her > Direct Path (and the update_secret) having too little entropy because the= y > are > all derived deterministically *purely* from the entropy she samples in th= at > procedure. > > To be clear, by "bad randomness" we're not just talking about low entropy > because of an on-device attacks by an adversary. We also mean things like > very > deterministic boot process/environments. (E.g. on some VMs, embedded > device or > even sometimes mobiles.) There's also buggy RNGs. (Things like the Infine= on > keygen bug in the Estonian ID cards. Also the stuff in "Mining you Ps and > Qs".) > The point is, low entropy can be a practical concern even when an > adversary can > *not* access the rest of your local state. > > The fix: We thought of 2 types of fixes to reduce the dependence on > continuous > fresh entropy. > > General Fix > ----------- > Basic Idea: MLS explicitly mandates a local entropy pool. > > Whenever MLS needs random bytes (i.e. when doing KeyBundle gen, or a > Commit) > call the OS/crypto-lib to get some (supposed) random bytes B from outside= . > HKDF > bytes B with your local entropy pool. First part of output overwrites you= r > entropy pool. Second part are the bytes you actually pass on to the > calling MLS > function. > > This gives you 2 nice properties. First, you are accumulating any entropy= B > *may* have into your pool. So even with consistently low (but not 0) > external > entropy your pool fills up and eventually your good for ever more (till > your > state leaks of course). That's true even if your external calls start > going back > to 0 entropy (e.g. say you update to a buggy external RNG implementation > or your > in a VM and the OS is getting (poorly) initialized from some fixed > snapshot but > your apps local state is persistent). Second, if your pool leaks, then as > soon > as your OS/lib gives you enough good entropy again you back to having a > good > pool to. So you have PCS for leaked randomness. As long as either pool or > external entropy are good the resulting being passed to MLS have enough > entropy. > > Pro: general catch-all solution. efficient, easy to analyze. > Con: requires implementors to handle cryptographically valuable randomnes= s > & > probably, to hook calls from their crypto-libs; a new and maybe touchy > practical > requirement for implementors compared to what MLS currently asks of them. > > > MLS Specific Fix > ---------------- > To avoid the above cons (and maybe others we didnt think of) here's an > alternate > solution approach using only already defined functions from the MLS spec. > We > demonstrate it on the case of a Commit as this is probably the most > egregious > case. (If Alice uses bad randomness it doesnt just "pollute" her own leaf > like > when she does an update proposal. It pollutes a whole chunk of the ratche= t > tree.) > > Basic idea: Whenever sampling/deriving a new secret key, make it also > depend on > the old secret key and on the application key schedule. That way, if > either the > old secret or application key schedule was secure, then so will the new > one be > *even when using bad randomness*. Mixing in the application key schedule = is > valuable if there was no old secret e.g. when we're assigning a new key > pair to > a previously blank node. > > For concreteness here's how that can work for the Commit operations (C.f. > Section 5.4 in MLS protocol version 9) > > commit_secret =3D HKDF-Expand(epoch_secret, "mls 1.0 welcome", Hash.lengt= h) > > ---------- snip ----------- > path_secret[0] =3D HKDF(leaf_hpke_secret||commit_secret, "path", > "", Hash.Length) > > If node n on direct path is blank > sk[n] :=3D ciphersuite key length number of 0 bytes. > Else > sk[n] :=3D old_node_priv[n] > > path_secret[n] =3D HKDF(path_secret[n-1]||sk[n], "path", "", Hash.Length) > > new_node_priv[n], new_node_pub[n] =3D Derive-Key-Pair(path_secret[n]) > ---------- snip ----------- > > Pros: only uses existing MLS functions. other parties implicitly verify > that the > fix is being used by re-deriving same key material as commiter. no need t= o > hook > RNG calls. > > Con: less general so full fix requires changing other parts of MLS where > security critical randomness is used. In particular, key bundle generatio= n > (or > at least updating in an existing session). > > > - Jo=C3=ABl & Sandro > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000062633b05a3d24729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jo=C3=ABl,

Thanks for thi= nking about this, and for the reminder on the call.

I'm inclined to say that this is not a matter for the MLS spec.=C2=A0= It's not a protocol / interoperability issue, it's a consideration= for how you build your client.

So I definitely wo= uld rather go for the general fix.=C2=A0 If some better platform guidance i= s needed, run it through CFRG.=C2=A0 Maybe describe the implications of bad= randomness in the Security Considerations to the protocol.

<= /div>
--Richard



<= /div>
O= n Fri, Apr 17, 2020 at 8:42 AM Joel Alwen <jalwen@wickr.com> wrote:
hey everyone,

Sandro Coretti and I have the following suggestions around MLS's defens= es
against bad randomness.

The Issue: Currently the (CGKA) protocol TreeKEM relies heavily on people continuously having good randomness available.

The problem: Good randomness may not always be available though in which ca= se
things can go pretty wrong. E.g. Say, Alice does a Commit with too little entropy (from the adversaries perspective). This results in all new keys on= her
Direct Path (and the update_secret) having too little entropy because they = are
all derived deterministically *purely* from the entropy she samples in that=
procedure.

To be clear, by "bad randomness" we're not just talking about= low entropy
because of an on-device attacks by an adversary. We also mean things like v= ery
deterministic boot process/environments. (E.g. on some VMs, embedded device= or
even sometimes mobiles.) There's also buggy RNGs. (Things like the Infi= neon
keygen bug in the Estonian ID cards. Also the stuff in "Mining you Ps = and Qs".)
The point is, low entropy can be a practical concern even when an adversary= can
*not* access the rest of your local state.

The fix: We thought of 2 types of fixes to reduce the dependence on continu= ous
fresh entropy.

General Fix
-----------
Basic Idea: MLS explicitly mandates a local entropy pool.

Whenever MLS needs random bytes (i.e. when doing KeyBundle gen, or a Commit= )
call the OS/crypto-lib to get some (supposed) random bytes B from outside. = HKDF
bytes B with your local entropy pool. First part of output overwrites your<= br> entropy pool. Second part are the bytes you actually pass on to the calling= MLS
function.

This gives you 2 nice properties. First, you are accumulating any entropy B=
*may* have into your pool. So even with consistently low (but not 0) extern= al
entropy your pool fills up and eventually your good for ever more (till you= r
state leaks of course). That's true even if your external calls start g= oing back
to 0 entropy (e.g. say you update to a buggy external RNG implementation or= your
in a VM and the OS is getting (poorly) initialized from some fixed snapshot= but
your apps local state is persistent). Second, if your pool leaks, then as s= oon
as your OS/lib gives you enough good entropy again you back to having a goo= d
pool to. So you have PCS for leaked randomness. As long as either pool or external entropy are good the resulting being passed to MLS have enough ent= ropy.

Pro: general catch-all solution. efficient, easy to analyze.
Con: requires implementors to handle cryptographically valuable randomness = &
probably, to hook calls from their crypto-libs; a new and maybe touchy prac= tical
requirement for implementors compared to what MLS currently asks of them.

MLS Specific Fix
----------------
To avoid the above cons (and maybe others we didnt think of) here's an = alternate
solution approach using only already defined functions from the MLS spec. W= e
demonstrate it on the case of a Commit as this is probably the most egregio= us
case. (If Alice uses bad randomness it doesnt just "pollute" her = own leaf like
when she does an update proposal. It pollutes a whole chunk of the ratchet = tree.)

Basic idea: Whenever sampling/deriving a new secret key, make it also depen= d on
the old secret key and on the application key schedule. That way, if either= the
old secret or application key schedule was secure, then so will the new one= be
*even when using bad randomness*. Mixing in the application key schedule is=
valuable if there was no old secret e.g. when we're assigning a new key= pair to
a previously blank node.

For concreteness here's how that can work for the Commit operations (C.= f.
Section 5.4 in MLS protocol version 9)

commit_secret =3D HKDF-Expand(epoch_secret, "mls 1.0 welcome", Ha= sh.length)

---------- snip -----------
path_secret[0] =3D HKDF(leaf_hpke_secret||commit_secret, "path",<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "", Hash.Length)=

If node n on direct path is blank
=C2=A0 sk[n] :=3D ciphersuite key length number of 0 bytes.
Else
=C2=A0 sk[n] :=3D old_node_priv[n]

path_secret[n] =3D HKDF(path_secret[n-1]||sk[n], "path", "&q= uot;, Hash.Length)

new_node_priv[n], new_node_pub[n] =3D Derive-Key-Pair(path_secret[n])
---------- snip -----------

Pros: only uses existing MLS functions. other parties implicitly verify tha= t the
fix is being used by re-deriving same key material as commiter. no need to = hook
RNG calls.

Con: less general so full fix requires changing other parts of MLS where security critical randomness is used. In particular, key bundle generation = (or
at least updating in an existing session).


- Jo=C3=ABl & Sandro

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000062633b05a3d24729-- From nobody Tue Apr 21 19:26: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 314693A0B16 for ; Tue, 21 Apr 2020 19:26:53 -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 9iz04IviiKhc for ; Tue, 21 Apr 2020 19:26:51 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2793A0B1A for ; Tue, 21 Apr 2020 19:26:51 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id s63so988659qke.4 for ; Tue, 21 Apr 2020 19:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=HagYftoNcowQmm0LANqj6Z6ADnIZvC882Ifk6G6piY4=; b=cMdZXmbiYXQddGcKCba1v7X0jp400IPTApc/Wvz/BkV5vqY0Ly2AVhu6o6J/2+I76t pRo8m6AeCCk28s6s//Am958FwUbreFvMTq3Jrsl+vhZY/c4K3h53305auWw47jvi4cGh KJ5Gu5Ux+gC5i7EzWy8tIQhld1d/BOPbhxX2c= 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=HagYftoNcowQmm0LANqj6Z6ADnIZvC882Ifk6G6piY4=; b=G/+suoDO0sAbxry8gfUKH2FrKON22PAVwljBSmoVMm+PTtHHXfZJOLcU3Ax0KjgG4E ozHZed+5Ah48Y26SGuknyxuXWciaMpI48hGgwgpzShGXb1QQLii94x89G36NjH/EEh/+ C7kQdp4b+kevRWmYWkJaa+STotLlOge3lL7dnH7m2GX1SpsM1MC9aQfXczuY0P+Ja7lK eWxg4/GWVFT+bML7JJxQfS32NW+LGdd0lCgGzs9m+C/1mXjJLrvoezaNFiXVZjPvVD81 RFGM8GcxRiwr+rAaBPBxOkI4OQgna8xX5PELloksLaYGldnWKCgXo9Gp5jqoVofGu1u9 /D8A== X-Gm-Message-State: AGi0Pub39iePF+x62L9UA0ep60zs/gxrwYWW/sNFTpB/1dH1B+185dbr jaP8p2rKPFy6yxNhCLJ5FBnegSuosFM= X-Google-Smtp-Source: APiQypIDKpoNW2FgM8RGpOCdNlSsnruQFDCds1zEN/7RQUnWIg4TD5IoxAJugdtx038xLFSMffZ0iQ== X-Received: by 2002:a37:7ac1:: with SMTP id v184mr23405043qkc.245.1587522410328; Tue, 21 Apr 2020 19:26:50 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id d63sm1415096qkb.52.2020.04.21.19.26.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 19:26:49 -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, 21 Apr 2020 22:26:47 -0400 To: MLS List X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [MLS] Virtual Interim Meeting Times 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, 22 Apr 2020 02:26:53 -0000 hi MLS, We are planning four more virtual interim meetings: 5 May, 19 May, 2 = June, and 16 June. Please let us know which time works best for you = here: https://forms.gle/PS1CFPkZYRVLTGqC6 Thanks! Nick and Sean= From nobody Wed Apr 22 05:15:22 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 358B83A0ADB for ; Wed, 22 Apr 2020 05:15:20 -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=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2KbJBuBG5HD for ; Wed, 22 Apr 2020 05:15:14 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 E7BFF3A0AD9 for ; Wed, 22 Apr 2020 05:15:13 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id t40so863831pjb.3 for ; Wed, 22 Apr 2020 05:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EG7Gmu9N/oLUL348LxbtUi7qsPajvZztoe0vlyQIbfs=; b=UlousOnSEJI/f2NigfFq7gk6TXucdfyla9RE3MMftwXSBM1j02B4MnzLXuRF3DR5SG KVSoTt8v652cvdFK/IRm1LDVelPA6fPqaxqRpcMw8Lc82GlhgddKA3u1HPYlkLZFm4yc JBAGZEjgS46AGhd9KKsCEHaN2VBK4M2drTcw7vw5R3nuKHyKQBy5Q55wP8QqUMVBTSrP Vi84Ga/SQP5Ms6TiUcZm6saVu4sWHOpHhAebW51EtFxjORRtsRpM/0VdcdS+A8NXd5UT jnBtRGOQQqqALyJU+hhF24FLffw6NnPsEd+uMNdCzd9iVx9o84KYQW2VZVEBOtt5kopZ OdVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=EG7Gmu9N/oLUL348LxbtUi7qsPajvZztoe0vlyQIbfs=; b=ZwJ41CMH0ijJI1EpQ1qK0Q3x4/iYSbv4QIk7HjzHeElajecsSH4MjH075HBTy5FSKn 9dYsGyhC8hazKbq7zO+0aBnkoJ+RpnpZaKfCQLO0NQ6Mx9k5ffAHAuClrVvxj79m1fM6 LwwlHqZcO9ueUf7mY5DqI87w26H9JldAqzWXKXX6XSdU+uXQOE6LARw0CwqFSYz0BY5g DJnyTaZaTzQ3huFUlFWAlsaj1oP2Ej0wQm5AQzMgshntmYkNDjOH+t9NY2e1i0RjQVfD 0UJrJSuVIxu4p+oeqn/A/rz5vndq6k1r0fGMsMLGraKp0mfiErzOClk6vNXVTYJH7DLT 2P3Q== X-Gm-Message-State: AGi0PuYiklzvHSbvfFJpXgGMuff6YA9C/18BS3qAV4qwdnkbM7E5X5ia CHDuOgMd/oCPwfMbd01crlFfJu6+p2M= X-Google-Smtp-Source: APiQypLqreyo31XXLMgs/xlsk5PzhzBUJLjYPDZ1kfshwysEjU5UgYVypPmhQR2SkW5GJY/uomYOvw== X-Received: by 2002:a17:90a:104f:: with SMTP id y15mr11359405pjd.191.1587557712409; Wed, 22 Apr 2020 05:15:12 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id c15sm5288013pfo.188.2020.04.22.05.15.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2020 05:15:11 -0700 (PDT) To: Richard Barnes Cc: Messaging Layer Security WG References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <9966939a-6e26-1f54-ff22-c78af72d80a5@wickr.com> Date: Wed, 22 Apr 2020 21:15:08 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 22 Apr 2020 12:15:21 -0000 Hey Richard, > I'm inclined to say that this is not a matter for the MLS spec. > So I definitely would rather go for the general fix. I'm not sure I understood you. Could you clarify? Are you leaning towards putting the general fix in the protocol RFC or rather leave it out? Or something else? As for not being in spec. My take is a bit different. In principle at least, I like the idea of designing crypto/security tools to withstand bad randomness when possible (at a reasonable cost). Two examples of modern designs which I believe take a similar view are EdDSA (i.e. Ed25519 & Ed448) and AES-GCM-SIV (and other nonce reuse/misuse resistant AEADs). They all include mechanisms to reduce the impact of bad randomness. I think similar defenses could be in scope for MLS too. Could you elaborate why you lean towards this not being a matter for the MLS spec? In the mean time, continuing with the EdDSA / AES-GCM-SIV analogies, the general fix is philosophically closer to the EdDSA's approach. Functionality doesn't depend on actually implementing the defense. (The verifier of an EdDSA signature would still accept signatures if R where chosen differently than specified in the spec. Similarly, a Commit msg receiver in MLS wouldn't know if the sender is using an entropy pool.) None-the-less the EdDSA designers felt it a good idea to design their scheme with such a defense in place. The second solution for MLS -- "hashing in old keys" -- is more inline with AES-GCM-SIV in that if you don't implement it as specified then you loose functionality. Receivers wont decrypt / process your output correctly. - Joël On 22/04/2020 04:46, Richard Barnes wrote: > Hi Joël, > > Thanks for thinking about this, and for the reminder on the call. > > I'm inclined to say that this is not a matter for the MLS spec.  It's not a > protocol / interoperability issue, it's a consideration for how you build your > client. > > So I definitely would rather go for the general fix.  If some better platform > guidance is needed, run it through CFRG.  Maybe describe the implications of bad > randomness in the Security Considerations to the protocol. > > --Richard > > > > > On Fri, Apr 17, 2020 at 8:42 AM Joel Alwen > wrote: > > hey everyone, > > Sandro Coretti and I have the following suggestions around MLS's defenses > against bad randomness. > > The Issue: Currently the (CGKA) protocol TreeKEM relies heavily on people > continuously having good randomness available. > > The problem: Good randomness may not always be available though in which case > things can go pretty wrong. E.g. Say, Alice does a Commit with too little > entropy (from the adversaries perspective). This results in all new keys on her > Direct Path (and the update_secret) having too little entropy because they are > all derived deterministically *purely* from the entropy she samples in that > procedure. > > To be clear, by "bad randomness" we're not just talking about low entropy > because of an on-device attacks by an adversary. We also mean things like very > deterministic boot process/environments. (E.g. on some VMs, embedded device or > even sometimes mobiles.) There's also buggy RNGs. (Things like the Infineon > keygen bug in the Estonian ID cards. Also the stuff in "Mining you Ps and Qs".) > The point is, low entropy can be a practical concern even when an adversary can > *not* access the rest of your local state. > > The fix: We thought of 2 types of fixes to reduce the dependence on continuous > fresh entropy. > > General Fix > ----------- > Basic Idea: MLS explicitly mandates a local entropy pool. > > Whenever MLS needs random bytes (i.e. when doing KeyBundle gen, or a Commit) > call the OS/crypto-lib to get some (supposed) random bytes B from outside. HKDF > bytes B with your local entropy pool. First part of output overwrites your > entropy pool. Second part are the bytes you actually pass on to the calling MLS > function. > > This gives you 2 nice properties. First, you are accumulating any entropy B > *may* have into your pool. So even with consistently low (but not 0) external > entropy your pool fills up and eventually your good for ever more (till your > state leaks of course). That's true even if your external calls start going back > to 0 entropy (e.g. say you update to a buggy external RNG implementation or your > in a VM and the OS is getting (poorly) initialized from some fixed snapshot but > your apps local state is persistent). Second, if your pool leaks, then as soon > as your OS/lib gives you enough good entropy again you back to having a good > pool to. So you have PCS for leaked randomness. As long as either pool or > external entropy are good the resulting being passed to MLS have enough entropy. > > Pro: general catch-all solution. efficient, easy to analyze. > Con: requires implementors to handle cryptographically valuable randomness & > probably, to hook calls from their crypto-libs; a new and maybe touchy practical > requirement for implementors compared to what MLS currently asks of them. > > > MLS Specific Fix > ---------------- > To avoid the above cons (and maybe others we didnt think of) here's an alternate > solution approach using only already defined functions from the MLS spec. We > demonstrate it on the case of a Commit as this is probably the most egregious > case. (If Alice uses bad randomness it doesnt just "pollute" her own leaf like > when she does an update proposal. It pollutes a whole chunk of the ratchet > tree.) > > Basic idea: Whenever sampling/deriving a new secret key, make it also depend on > the old secret key and on the application key schedule. That way, if either the > old secret or application key schedule was secure, then so will the new one be > *even when using bad randomness*. Mixing in the application key schedule is > valuable if there was no old secret e.g. when we're assigning a new key pair to > a previously blank node. > > For concreteness here's how that can work for the Commit operations (C.f. > Section 5.4 in MLS protocol version 9) > > commit_secret = HKDF-Expand(epoch_secret, "mls 1.0 welcome", Hash.length) > > ---------- snip ----------- > path_secret[0] = HKDF(leaf_hpke_secret||commit_secret, "path", >                                                         "", Hash.Length) > > If node n on direct path is blank >   sk[n] := ciphersuite key length number of 0 bytes. > Else >   sk[n] := old_node_priv[n] > > path_secret[n] = HKDF(path_secret[n-1]||sk[n], "path", "", Hash.Length) > > new_node_priv[n], new_node_pub[n] = Derive-Key-Pair(path_secret[n]) > ---------- snip ----------- > > Pros: only uses existing MLS functions. other parties implicitly verify that the > fix is being used by re-deriving same key material as commiter. no need to hook > RNG calls. > > Con: less general so full fix requires changing other parts of MLS where > security critical randomness is used. In particular, key bundle generation (or > at least updating in an existing session). > > > - Joël & Sandro > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Apr 22 05:25:11 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 287213A0B0C for ; Wed, 22 Apr 2020 05:25:09 -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 vObOtZ12iQ3p for ; Wed, 22 Apr 2020 05:25:06 -0700 (PDT) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F85B3A0B0B for ; Wed, 22 Apr 2020 05:25:05 -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-102.mailbox.org (Postfix) with ESMTPS id 496flK70jczKmbT for ; Wed, 22 Apr 2020 14:25:01 +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 dj8yUvMcjG1N for ; Wed, 22 Apr 2020 14:24:56 +0200 (CEST) To: mls@ietf.org References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> From: Konrad Kohbrok Message-ID: <8f0933dd-7dc3-3603-9401-a5907b85fac2@datashrine.de> Date: Wed, 22 Apr 2020 14:24:55 +0200 MIME-Version: 1.0 In-Reply-To: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 91C4D175F X-Rspamd-Score: -5.26 / 15.00 / 15.00 Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 22 Apr 2020 12:25:09 -0000 > The second solution for MLS -- "hashing in old keys" -- is more inline with > AES-GCM-SIV in that if you don't implement it as specified then you loose > functionality. Receivers wont decrypt / process your output correctly. One way to keep it transparent for the receiver (if that is indeed what we want) would be for the updating party to include the previous epoch's path_secret[0] when creating a fresh path_secret[0] and then KDF'ing up the tree as before. In other words, follow your MLS specific suggestion, but only for the leaf secrets. Since that is (I think?) the only place new randomness comes into the tree anyway, it would have about the same effect, wouldn't it? Also, it would be a minor change to the protocol and the receiver wouldn't even notice if the sender did it (for better or worse). Cheers, Konrad On 17.04.20 14:42, Joel Alwen wrote: > hey everyone, > > Sandro Coretti and I have the following suggestions around MLS's defenses > against bad randomness. > > The Issue: Currently the (CGKA) protocol TreeKEM relies heavily on people > continuously having good randomness available. > > The problem: Good randomness may not always be available though in which case > things can go pretty wrong. E.g. Say, Alice does a Commit with too little > entropy (from the adversaries perspective). This results in all new keys on her > Direct Path (and the update_secret) having too little entropy because they are > all derived deterministically *purely* from the entropy she samples in that > procedure. > > To be clear, by "bad randomness" we're not just talking about low entropy > because of an on-device attacks by an adversary. We also mean things like very > deterministic boot process/environments. (E.g. on some VMs, embedded device or > even sometimes mobiles.) There's also buggy RNGs. (Things like the Infineon > keygen bug in the Estonian ID cards. Also the stuff in "Mining you Ps and Qs".) > The point is, low entropy can be a practical concern even when an adversary can > *not* access the rest of your local state. > > The fix: We thought of 2 types of fixes to reduce the dependence on continuous > fresh entropy. > > General Fix > ----------- > Basic Idea: MLS explicitly mandates a local entropy pool. > > Whenever MLS needs random bytes (i.e. when doing KeyBundle gen, or a Commit) > call the OS/crypto-lib to get some (supposed) random bytes B from outside. HKDF > bytes B with your local entropy pool. First part of output overwrites your > entropy pool. Second part are the bytes you actually pass on to the calling MLS > function. > > This gives you 2 nice properties. First, you are accumulating any entropy B > *may* have into your pool. So even with consistently low (but not 0) external > entropy your pool fills up and eventually your good for ever more (till your > state leaks of course). That's true even if your external calls start going back > to 0 entropy (e.g. say you update to a buggy external RNG implementation or your > in a VM and the OS is getting (poorly) initialized from some fixed snapshot but > your apps local state is persistent). Second, if your pool leaks, then as soon > as your OS/lib gives you enough good entropy again you back to having a good > pool to. So you have PCS for leaked randomness. As long as either pool or > external entropy are good the resulting being passed to MLS have enough entropy. > > Pro: general catch-all solution. efficient, easy to analyze. > Con: requires implementors to handle cryptographically valuable randomness & > probably, to hook calls from their crypto-libs; a new and maybe touchy practical > requirement for implementors compared to what MLS currently asks of them. > > > MLS Specific Fix > ---------------- > To avoid the above cons (and maybe others we didnt think of) here's an alternate > solution approach using only already defined functions from the MLS spec. We > demonstrate it on the case of a Commit as this is probably the most egregious > case. (If Alice uses bad randomness it doesnt just "pollute" her own leaf like > when she does an update proposal. It pollutes a whole chunk of the ratchet tree.) > > Basic idea: Whenever sampling/deriving a new secret key, make it also depend on > the old secret key and on the application key schedule. That way, if either the > old secret or application key schedule was secure, then so will the new one be > *even when using bad randomness*. Mixing in the application key schedule is > valuable if there was no old secret e.g. when we're assigning a new key pair to > a previously blank node. > > For concreteness here's how that can work for the Commit operations (C.f. > Section 5.4 in MLS protocol version 9) > > commit_secret = HKDF-Expand(epoch_secret, "mls 1.0 welcome", Hash.length) > > ---------- snip ----------- > path_secret[0] = HKDF(leaf_hpke_secret||commit_secret, "path", > "", Hash.Length) > > If node n on direct path is blank > sk[n] := ciphersuite key length number of 0 bytes. > Else > sk[n] := old_node_priv[n] > > path_secret[n] = HKDF(path_secret[n-1]||sk[n], "path", "", Hash.Length) > > new_node_priv[n], new_node_pub[n] = Derive-Key-Pair(path_secret[n]) > ---------- snip ----------- > > Pros: only uses existing MLS functions. other parties implicitly verify that the > fix is being used by re-deriving same key material as commiter. no need to hook > RNG calls. > > Con: less general so full fix requires changing other parts of MLS where > security critical randomness is used. In particular, key bundle generation (or > at least updating in an existing session). > > > - Joël & Sandro > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Apr 22 05:47:59 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 885BD3A0B6C for ; Wed, 22 Apr 2020 05:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ2iudFDCnK4 for ; Wed, 22 Apr 2020 05:47:56 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 0B1363A0B6B for ; Wed, 22 Apr 2020 05:47:55 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id x77so1037205pfc.0 for ; Wed, 22 Apr 2020 05:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TtWetv6cXwRzcBsBXOUgDfh3PlQgErxkZLf+URURQlk=; b=0Wh+O5H4vTpmsm2VL5wPOZPRjuwqrIv8hMQO0WNbmApr+LbQUdapmLj9HsVDqtvkp5 rDUi2vvmqx2KNubNZ9pDrxe8JQ+lnhqsXcU+Zu5tuR54buYbDnyZ9Vg5TOuZgw5tSupj HQMuyedjSxxvnI856kwJfgDMxAqkNDyYgRQACJyISVGXZHHmVzAWT5I6N07/2W8h6BrE nsLVHfNm1mp+GrLlFU3w7ls1OI9s1WqFxpAKZWercoQAOi9LBffbodF40DdF1/2/IiEk CMN4D3iy16WiOm0edyRLtJgbLMBTrUaiw8MjSPdDkuY0ZV4DTzAHAMtDwEGr7t+qUPfC gmyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TtWetv6cXwRzcBsBXOUgDfh3PlQgErxkZLf+URURQlk=; b=cCFtk42hRNgp1KtufgaF+hPB23YX9mQqRPrIDSQeYq9itX9512nffUFm5dXbPQOYh9 e05++1FBJHJI6Wge4Wruy2aklwplHLeydOk4aVjJk6dqkC6X02D0+zIzl5k89HXMT6f5 t00k6lOLyi810k7yAJiLUr+6Sp/Kh6Go3+FkKsMFZonaQ1t/WNSOdOc0Ihs06kESPZFV 8dX9uQK9JovutF4zPNpWYglOnbACkhClP5iQ/7G7h1xmj29dA/GciQlKoqG5nlhXTRT9 dAr7iLneneF7DVhpZU4rNfrhHhPdzJHavUN4mnBSsJUt4Kybx7iDAH1jyUT7Bd7fg+qG qDUA== X-Gm-Message-State: AGi0PuZVvtMcO663bOA7BzYgiBVdlI1+9C8XqVFHQcNVUYlbXAmmEdEq 9EKLG33YhD5FcUoydpOnyqqjDSTkysA= X-Google-Smtp-Source: APiQypIGyBl85vEKYvHgmB9DaaR8QF/vzNOZduCcIpb+3mO7O8wggP/SiKRoOx5fWgjyUC5sQMZ7ZQ== X-Received: by 2002:aa7:8b42:: with SMTP id i2mr14669678pfd.21.1587559675089; Wed, 22 Apr 2020 05:47:55 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id 6sm5445909pfj.123.2020.04.22.05.47.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2020 05:47:54 -0700 (PDT) To: mls@ietf.org References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> <8f0933dd-7dc3-3603-9401-a5907b85fac2@datashrine.de> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <732de8b8-7be9-eac3-8966-eb97ca985a02@wickr.com> Date: Wed, 22 Apr 2020 21:47:52 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <8f0933dd-7dc3-3603-9401-a5907b85fac2@datashrine.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 22 Apr 2020 12:47:58 -0000 Hey Konrad! On 22/04/2020 21:24, Konrad Kohbrok wrote: > One way to keep it transparent for the receiver (if that is indeed what we want) > would be for the updating party to include the previous epoch's path_secret[0] > when creating a fresh path_secret[0] and then KDF'ing up the tree as before. In > other words, follow your MLS specific suggestion, but only for the leaf secrets. > Since that is (I think?) the only place new randomness comes into the tree > anyway, it would have about the same effect, wouldn't it? Also, it would be a > minor change to the protocol and the receiver wouldn't even notice if the sender > did it (for better or worse). I like that this is less invasive in terms of changes. (Though IMO its actually a Pro not a Con that functionality breaks when you don't implement any given defense correctly, including those against bad randomness.) One nit: better to derive something off of the old path_secret[0] and use that rather than use path_secret[0] directly. Don't want to keep path_secret[0] around after a commit (bad for FS of TreeKEM / PCFS of MLS). I do think that using only path_secret[0] defends a bit less though. E.g. say Alice & Bob are siblings (and everything is delivered & process immediately). Here's an execution. 1) Alice commits. 2) Leak Alice's state to adversary. 3) Bob commits. 4) Alice commits with bad randomness. Mixing in only something from path_secret[0] means all keys in commit (4) are now bad. But mixing in something from old path_secret[n] for new pub/priv key n means all but her leaf are now good keys. - Joël From nobody Wed Apr 22 05:50: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 35A6F3A0B7B for ; Wed, 22 Apr 2020 05:50:44 -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=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNqlZdMaPYkV for ; Wed, 22 Apr 2020 05:50:42 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 823D23A0B79 for ; Wed, 22 Apr 2020 05:50:42 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id h11so884808plr.11 for ; Wed, 22 Apr 2020 05:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YivFJU2JylubC5boGDBC9NHoSx0AjTQK82pvV42kw5A=; b=Um1UMk6Oc/fDAAYWnFwNKiYgRT9xzAAvn+pOqJUpZ6huMdtJqE7cPS9aGq/Br27aLX +1N+b5LMS72JizR4sri4bbZRivSq6FafLqRKTUyxF0SJvqAaHN++XrC1/76MUBk+edP9 tbcXVUcH86sWDvmo5hHZRdcuueBtmLSVloYJ2jEbOOPl6h+N5bYvJoUa379061C4n0uC ThrBJlcx8gc+LRcgDz8mME/dzYQN78kM6HRBdBD+DAOZLwWk92UjpgNlK8KGa2DTzGci GTnsUXeMWCMUgbzctm2Ff8fsCRKkrxGTdr8+Ybk2WVNwZUicEwMLEPZHY9p79eIDXzeM S4qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=YivFJU2JylubC5boGDBC9NHoSx0AjTQK82pvV42kw5A=; b=R63Z2KOZ/mlK4I6qrksuuccba41ha8rwT6fNAepe7fDcKCxzMkKP6lm8RL0I67P3N9 otboppMo5nbFIDp3LsG6pFZcCx0Ao6X+s9SzyrxDQ0wi3KNypCcBzGGZgo/cfaZd+/rM JhmHHi6e0IrY3tRv1uI/IUngIW34YlbvGNZoL1UoIUBOX8yMf0z40d86P0G8hnLIi0yB gnb/rDx1LEuyqTM/3/qbKmSzshlOUvgN4/fqSbkCadVN5Z74OlBr4RbLHWyWuTpQyzWB goO5PxNzjKhzC9XyP67oalch4IA06ROyWt96BI2xvULGRzIK9p9M0qSdfLD3uQsZD09t zv0w== X-Gm-Message-State: AGi0PuZzEZQQQjasTB2lIl5mRFCCFMp8nHTwcNiyWhV54FqAU4iWLKXk kNKTkBo9JDykjF7fSFc/nR67AgxwsaY= X-Google-Smtp-Source: APiQypJ5fwZrCPpppMd33TA9GsX/PT3KhvVvK7HsnMZq4mDWf+br2nJG4/pgiKqdbilFB5t+ymeVww== X-Received: by 2002:a17:90a:7482:: with SMTP id p2mr11447555pjk.151.1587559841626; Wed, 22 Apr 2020 05:50:41 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id j26sm5050444pgm.20.2020.04.22.05.50.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2020 05:50:41 -0700 (PDT) To: Richard Barnes Cc: Messaging Layer Security WG References: <17d24e72-c331-3a2d-3d33-5dfd59d069ab@wickr.com> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <21a5b40a-480e-71d5-a4b6-61a80a73f7bd@wickr.com> Date: Wed, 22 Apr 2020 21:50:38 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] somewhat better PCFS for cheap 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, 22 Apr 2020 12:50:44 -0000 > Do you want to draft a PR? Yup, I'll go for it. - Joël On 17/04/2020 22:32, Richard Barnes wrote: > Hi Joël (and Sandro), > > Thanks for the thoughts.  I agree that Option 2 makes sense.  In fact, I think > it agrees pretty much with what I was thinking, and the current doc is wrong.  > In particular, where it says "the HPKE secret key "leaf_hpke_secret"" in the > text you quote, I would have expected that "leaf_hpke_secret" to be a secret > from which the leaf HPKE private key was derived, basically the same as your > pre-seed. > > One note to all this, though: None of this is visible to anyone except the > holder of the leaf.  So the other members of the group have to trust that the > leaf holder is doing the right thing.  The issue is the same as with decoherence > higher up the path; either way, we lack a way to prove that two public keys > correspond to private keys that are derived from sequential path secrets going > up the tree.  As before, I don't think this is fatal, and we should proceed. > > Do you want to draft a PR? > > --Richard > > > On Fri, Apr 17, 2020 at 3:51 AM Joel Alwen > wrote: > > Hey Everyone, > > Sandro Coretti and I have the following suggestions for how "hash up the tree" > during a Commit works. (C.f. Section 5.4 in MLS protocol version 9). The goal is > to (cheaply) fix the FS of TreeKEM (ergo the PCFS of MLS). > > The Issue: Currently all new keys inserted into the ratchet tree in a commit > (not to mention the resulting commit_secret) are all derived deterministically > from leaf_hpke_secret of committer's new leaf key. That value is in turn sampled > freshly at commit time by the committer. > > For concreteness: offending lines in mls-protocol-09 Pg. 17 > -------- snip ---------- > The generator of the Commit starts by using the HPKE secret key > "leaf_hpke_secret" associated with the new leaf KeyPackage (see > Section 7) to compute "path_secret[0]" and generate a sequence of > "path secrets", one for each ancestor of its leaf. > > path_secret[0] = HKDF-Expand-Label(leaf_hpke_secret, >                                       "path", "", Hash.Length) > -------- snip ---------- > > The Problem: Suppose Alice commits. If her resulting leaf HPKE priv key ever > leaks, the adversary learns all keys generated in her commit. Thing is, thats > true even if all those keys have since been overwritten and removed from her > state by the time her state leaks. Her leaf priv key alone is enough to > re-derive all of them. Zooming out a bit, for TreeKEM this means poorer FS than > need be. Zooming out further, for MLS we get poorer PCFS than need be. > > Proposed Solution: We say "poorer than need be" because there are many easy > fixes here. E.g. >  - Option 1 (simplicity) sample the HPKE leaf key pair using fresh random bytes. > Also sample a "derive_secret" independently for doing the deterministic deriving > up the tree. >  - Option 2 (saves on consumed random bytes) sample a pre-seed. Expand it (e.g. > with HKDF-Expand) to two independent secrets. Use one to generate HPKE pub/priv > key pair for leaf. Use the other to do the hashing up the tree. (This is how we > modeled TreeKEM in eprint/2019/1189.) > > Personally, I'm partial to 2 because, as a general rule of thumb, I like to > conserve entropy demand. It can be a rare commodity in some deployments and when > implementers start doing things like calling /dev/random instead of /dev/urandom > you can end up depleting entropy. > > So, for concreteness how about this? > > -------- snip ---------- > pre-seed <-- {0,1}^secparam > > //first half of output goes in seed, second half in leaf_hpke_secret > seed, leaf_hpke_secret = HPKDF-Expand(pre-seed, "leafgen", >                                                         "", Hash.Length) > -------- snip ---------- > > leaf_hpke_priv, leaf_hpke_pub = Derive-Key-Pair(seed) > > > - Joël & Sandro > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Apr 22 07:58:39 2020 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00863A0E1B for ; Wed, 22 Apr 2020 07:58:37 -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, 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 xl94Wwu8aW8G for ; Wed, 22 Apr 2020 07:58:35 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id CAD013A0E18 for ; Wed, 22 Apr 2020 07:58:35 -0700 (PDT) X-ASG-Debug-ID: 1587567514-0e394549633cea50001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id OGs4hHYZmQ4QhFZc; Wed, 22 Apr 2020 07:58:34 -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; Wed, 22 Apr 2020 07:58:33 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.105) 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; Wed, 22 Apr 2020 07:58:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J3Yw1FNTto9aVsTv/8bZR7ouz3i1NpgGe4PgNvC2vlO6GbF6fmoUtkof+AeIbvrfMNufTpd0TRn3ucZKaz3fETTc8Awf7MC21YRA1s0xy50dveX0xK14LvQVGT27zRqKbkBjBdkzh5lv1C4jx/0abJUYS3lxee/LVp3l5fOedL+BpCpUxbFx/hAsL22qGvMQ5hu0UfUX20Kf7mG+ABjBJi6VuXkoI5mg4ilvAilS7B1laf6sq0we0jGvtGUuUELPOfjuXMAyhhselvrVtinTn3MFhCy/JCD+JCLc2DA0zJxVkr1Gy/Bsh4brNWHXddxolyYugSpF3xQ0vDJh6Kav+w== 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=V0WlKUBAI73lk9iNzsPn23t6o5vz5dex+nnjA6mwXWI=; b=WyObUsfoE/grHUvx37hS9DRkORo5uJupp8DUirk+lMwG+4v7+lOVF5qFW8iq4ypG2XR3VWcicxX0TJPUJ5kDIl6h4iMqQd8OlFdlozkA89JsBcvm2fZ/KlZgDB3U3dGZqnGVFaCUN5TES3Z5Kr0xJUIUdLpR8gFCHeIkUEfkIF6e36zhXfOZmi1OEGvq/8AYtAaM9QIqdkE6YC2GmRCmcxRR9aUDUwwtWBPZm/e9EtCyAY2PuKWGdtDkouAW2FqWlL6AK3QYHBuGklfcbCPqrRnkSSmzRwh51sCaR9EfV99OPIXbhv+wiu/dKUOUibqRBEaXOhzijrVAhA7bDHY2tQ== 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 BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3796.namprd13.prod.outlook.com (2603:10b6:a03:22a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Wed, 22 Apr 2020 14:58:32 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::b93a:9f12:aa45:6194]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::b93a:9f12:aa45:6194%7]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 14:58:31 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:22a::16] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:22a::16 From: "Hale, Britta (CIV)" To: Joel Alwen , "mls@ietf.org" Thread-Topic: [MLS] hardening MLS against bad randomness X-ASG-Orig-Subj: Re: [MLS] hardening MLS against bad randomness Thread-Index: AQHWFLWofXOAPH5gNE6s9ckk8yY+RaiFGKOAgAAGagD//68jgA== Date: Wed, 22 Apr 2020 14:58:31 +0000 Message-ID: <83DBF73B-7CD2-4E36-8C3D-4A361A1D4A02@nps.edu> References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> <8f0933dd-7dc3-3603-9401-a5907b85fac2@datashrine.de> <732de8b8-7be9-eac3-8966-eb97ca985a02@wickr.com> In-Reply-To: <732de8b8-7be9-eac3-8966-eb97ca985a02@wickr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.14.200307 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [69.226.214.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a3dcaa3-c439-4b59-a936-08d7e6cd9fba x-ms-traffictypediagnostic: BY5PR13MB3796: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03818C953D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3013.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(376002)(366004)(396003)(39850400004)(8936002)(66476007)(2616005)(66446008)(316002)(66556008)(66946007)(76116006)(110136005)(64756008)(6506007)(186003)(8676002)(478600001)(53546011)(26005)(6512007)(66574012)(33656002)(966005)(81156014)(786003)(36756003)(2906002)(6486002)(5660300002)(86362001)(71200400001)(75432002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jNS32qrCxofMicN2mAwVG2WRnF+ukMY6J0mLxSIYxdq9FZU+l7gpIkYh6BEvrDhKUm+DGQ9++HInObDBiR/4EjMFGmKMZ2NJ1gmP1OmHDqfbMxWAfNwJTHLAcu8AfKdIjqtkm1iBWf96X+609v8nv1O6sDqYb8HwpgBkIqE58FS7KnLvBQJ9k+i2usx/4xaoagGFDHRvn8oMYGJmcvs0rK6Z8XzR0c5q2mLrR+cK01QBNddSRLYvofC1ySeT3Wt9OpYDKJbStqPIMbKqmIvArc4xZlgbx5liq2ezQbasVccs5UW5A8Lmif8mtUaWZfMR4oH54gaieXp7UtMYOVAqPy30Eq6Fryyg5GRIqELcA8PufT8xw3W3wZcFRNE1xqSVCY9AZ3rENtH6MOgS0h98xetPGDyYiUOedlSPADA2UYiug2qD1SJn7Vbau1pglHI6zzcGN7APmRAK/mEZAnqXJLerITXX8IZAMORq6C2gotWIFOwY1w1L97GvTXBTk6065qu7jIMGKkZuwzYVhvCDrw== x-ms-exchange-antispam-messagedata: 7zlGtGwiwUh5PhcCCcuncT+9eW5Roiw9j3vuMe1/P+FS6GxbLfY49/SYBGAaDOzsNB4t5mIUz4/7cCVtAQQSea4T4RK5NeUePfDhvaUEw2OROaibNCtDtFpbUtS+C3vfxW+FYOJBZVEw/Wzk0TmrHA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a3dcaa3-c439-4b59-a936-08d7e6cd9fba X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 14:58:31.6880 (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: 2PsY2cOWYNo4QoYaAvJdTscskRwWQuAAW24LSyay4PW//gCzUaHkwd1kRiodajzTfvVe8jt7BzxQwCM4NriH6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3796 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1587567514 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: 3046 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.81354 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 22 Apr 2020 14:58:38 -0000 SSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgdGhyZWF0IG1vZGVsIHdlIGFyZSB3b3JraW5n IHdpdGggb24gdGhpcy4gV2hlbiB0cnlpbmcgdG8gcHJvdGVjdCBhZ2FpbnN0IGJhZCByYW5kb21u ZXNzLCB0aGUgZ29hbCB3b3VsZCBzZWVtIHRvIGJlIHRvIHByb3RlY3QgYSByZWNlaXZlciBhZ2Fp bnN0IHBvdGVudGlhbGx5IGJhZCByYW5kb21uZXNzIGZyb20gdGhlIHNlbmRlci4gSG93ZXZlciwg aWYgcmVjZWl2ZXIgd291bGQgbm90IG5vdGljZSBpZiB0aGUgc2VuZGVyIHRvb2sgdGhlIGNvcnJl Y3Qgc3RlcHMsIHRoZW4gdGhleSBkbyBub3QgaGF2ZSBhbnkgZ3VhcmFudGVlIC0gaW4gZmFjdCwg YSBzZW5kZXIgY291bGQganVzdCBpbmNvcnJlY3RseSBpbXBsZW1lbnQgdGhpcyB3aXRob3V0IGJy ZWFraW5nIGZ1bmN0aW9uYWxpdHkgYW5kIG5vIG9uZSB3b3VsZCBiZSB0aGUgd2lzZXIgdGhhdCB0 aGUgYmFkLXJhbmRvbW5lc3MgcHJvdGVjdGlvbiBoYXMgYmVlbiBsb3N0IChpZiBJIHVuZGVyc3Rh bmQgdGhlIHByb3Bvc2FsIGNvcnJlY3RseSkuDQoNClNvIGlzIHRoZSBnb2FsIHRvIHByb3RlY3Qg dGhlIHNlbmRlciBmcm9tIHRoZWlyIG93biBiYWQgcmFuZG9tbmVzcywgb3IgdG8gcHJvdGVjdCBh biB1bmF3YXJlIHJlY2VpdmVyLCBpbiB0aGUgZXZlbnQgdGhhdCB0aGUgc2VuZGVyIGFjdHVhbGx5 IGJlaGF2ZXMgY29ycmVjdGx5PyBUaGVyZSBjYW4gc3RpbGwgYmUgYSBnYWluIGZyb20gc3VjaCBh IGNoYW5nZSwgYnV0IGl0IHNlZW1zIHRvIGJlIGEgZmFyIHdlYWtlciBndWFyYW50ZWUgaWYgdGhl cmUgaXMgbm8gYXdhcmVuZXNzIGF0IHRoZSByZWNlaXZlci4gDQoNCldlIGFsc28gbmVlZCB0byBi ZSBjYXJlZnVsIGluIHRoZSBkaWZmZXJlbnRpYXRpb24gb2YgbGVha2luZyBzdGF0ZSB0byB0aGUg YWR2ZXJzYXJ5LCB3aGljaCBtYXkgd2VsbCByZXZlYWwgdGhlIGVudGlyZSBjdXJyZW50IHN0YXRl LCBhbmQgYSBiYWQgcmFuZG9tIGdlbmVyYXRvci4NCg0KLS0gQnJpdHRhDQoNCg0K77u/T24gNC8y Mi8yMCwgNTo0OCBBTSwgIk1MUyBvbiBiZWhhbGYgb2YgSm9lbCBBbHdlbiIgPG1scy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBqYWx3ZW5Ad2lja3IuY29tPiB3cm90ZToNCg0KICAgIEhl eSBLb25yYWQhDQogICAgDQogICAgT24gMjIvMDQvMjAyMCAyMToyNCwgS29ucmFkIEtvaGJyb2sg d3JvdGU6DQogICAgPiBPbmUgd2F5IHRvIGtlZXAgaXQgdHJhbnNwYXJlbnQgZm9yIHRoZSByZWNl aXZlciAoaWYgdGhhdCBpcyBpbmRlZWQgd2hhdCB3ZSB3YW50KQ0KICAgID4gd291bGQgYmUgZm9y IHRoZSB1cGRhdGluZyBwYXJ0eSB0byBpbmNsdWRlIHRoZSBwcmV2aW91cyBlcG9jaCdzIHBhdGhf c2VjcmV0WzBdDQogICAgPiB3aGVuIGNyZWF0aW5nIGEgZnJlc2ggcGF0aF9zZWNyZXRbMF0gYW5k IHRoZW4gS0RGJ2luZyB1cCB0aGUgdHJlZSBhcyBiZWZvcmUuIEluDQogICAgPiBvdGhlciB3b3Jk cywgZm9sbG93IHlvdXIgTUxTIHNwZWNpZmljIHN1Z2dlc3Rpb24sIGJ1dCBvbmx5IGZvciB0aGUg bGVhZiBzZWNyZXRzLg0KICAgID4gU2luY2UgdGhhdCBpcyAoSSB0aGluaz8pIHRoZSBvbmx5IHBs YWNlIG5ldyByYW5kb21uZXNzIGNvbWVzIGludG8gdGhlIHRyZWUNCiAgICA+IGFueXdheSwgaXQg d291bGQgaGF2ZSBhYm91dCB0aGUgc2FtZSBlZmZlY3QsIHdvdWxkbid0IGl0PyBBbHNvLCBpdCB3 b3VsZCBiZSBhDQogICAgPiBtaW5vciBjaGFuZ2UgdG8gdGhlIHByb3RvY29sIGFuZCB0aGUgcmVj ZWl2ZXIgd291bGRuJ3QgZXZlbiBub3RpY2UgaWYgdGhlIHNlbmRlcg0KICAgID4gZGlkIGl0IChm b3IgYmV0dGVyIG9yIHdvcnNlKS4NCiAgICANCiAgICBJIGxpa2UgdGhhdCB0aGlzIGlzIGxlc3Mg aW52YXNpdmUgaW4gdGVybXMgb2YgY2hhbmdlcy4gKFRob3VnaCBJTU8gaXRzIGFjdHVhbGx5DQog ICAgYSBQcm8gbm90IGEgQ29uIHRoYXQgZnVuY3Rpb25hbGl0eSBicmVha3Mgd2hlbiB5b3UgZG9u J3QgaW1wbGVtZW50IGFueSBnaXZlbg0KICAgIGRlZmVuc2UgY29ycmVjdGx5LCBpbmNsdWRpbmcg dGhvc2UgYWdhaW5zdCBiYWQgcmFuZG9tbmVzcy4pDQogICAgDQogICAgT25lIG5pdDogYmV0dGVy IHRvIGRlcml2ZSBzb21ldGhpbmcgb2ZmIG9mIHRoZSBvbGQgcGF0aF9zZWNyZXRbMF0gYW5kIHVz ZSB0aGF0DQogICAgcmF0aGVyIHRoYW4gdXNlIHBhdGhfc2VjcmV0WzBdIGRpcmVjdGx5LiBEb24n dCB3YW50IHRvIGtlZXAgcGF0aF9zZWNyZXRbMF0NCiAgICBhcm91bmQgYWZ0ZXIgYSBjb21taXQg KGJhZCBmb3IgRlMgb2YgVHJlZUtFTSAvIFBDRlMgb2YgTUxTKS4NCiAgICANCiAgICBJIGRvIHRo aW5rIHRoYXQgdXNpbmcgb25seSBwYXRoX3NlY3JldFswXSBkZWZlbmRzIGEgYml0IGxlc3MgdGhv dWdoLiBFLmcuIHNheQ0KICAgIEFsaWNlICYgQm9iIGFyZSBzaWJsaW5ncyAoYW5kIGV2ZXJ5dGhp bmcgaXMgZGVsaXZlcmVkICYgcHJvY2VzcyBpbW1lZGlhdGVseSkuDQogICAgSGVyZSdzIGFuIGV4 ZWN1dGlvbi4NCiAgICANCiAgICAxKSBBbGljZSBjb21taXRzLg0KICAgIDIpIExlYWsgQWxpY2Un cyBzdGF0ZSB0byBhZHZlcnNhcnkuDQogICAgMykgQm9iIGNvbW1pdHMuDQogICAgNCkgQWxpY2Ug Y29tbWl0cyB3aXRoIGJhZCByYW5kb21uZXNzLg0KICAgIA0KICAgIE1peGluZyBpbiBvbmx5IHNv bWV0aGluZyBmcm9tIHBhdGhfc2VjcmV0WzBdIG1lYW5zIGFsbCBrZXlzIGluIGNvbW1pdCAoNCkg YXJlDQogICAgbm93IGJhZC4gQnV0IG1peGluZyBpbiBzb21ldGhpbmcgZnJvbSBvbGQgcGF0aF9z ZWNyZXRbbl0gZm9yIG5ldyBwdWIvcHJpdiBrZXkgbg0KICAgIG1lYW5zIGFsbCBidXQgaGVyIGxl YWYgYXJlIG5vdyBnb29kIGtleXMuDQogICAgDQogICAgLSBKb8OrbA0KICAgIA0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgTUxTIG1haWxp bmcgbGlzdA0KICAgIE1MU0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWxzDQogICAgDQoNCg== From nobody Wed Apr 22 08:30: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 188AD3A0EC1 for ; Wed, 22 Apr 2020 08:30:44 -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=wickr-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcvTLT0VYCLA for ; Wed, 22 Apr 2020 08:30:42 -0700 (PDT) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 28DF53A0EC5 for ; Wed, 22 Apr 2020 08:30:41 -0700 (PDT) Received: by mail-pj1-x102f.google.com with SMTP id 7so2577291pjo.0 for ; Wed, 22 Apr 2020 08:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/Pg022Q5tX7HkNFzEfd3xeeZuNn6YQxfmQukvukZhkE=; b=vLzeWWPxL9qbxwB+rOg9NiPLCqKF9IGtSHE5uplgwRndZCQYEOTGBPCo7+/53IeYLe U9WmUzn7ZzLnHGOQGpCDVeVUjoGwr5qWJ64ui1nrAeLp10FFmOZcdkxEYePAi0PgFQZ1 Z5dlz3fmrKrFRovP4oBuBKjMrQHrS8H1bshkETGDbv4qMlnSMqiil8dAznbJznN8SOZh HdCUJhpIrHmfIbCCPHHBUnl6Jvhcdkz/3mHNVYaPhpL3FwmG+ixiW/xB2YmzKt85XLz5 h/PR3PU4pt4yLI5mNQK1N1+27Acr0lTxCkgXJNBOD8BH6bAJgt9stKGNkdoQqAV9sOU2 Imag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/Pg022Q5tX7HkNFzEfd3xeeZuNn6YQxfmQukvukZhkE=; b=TiH2HCrfLao6TPOeZc/oQayaMfVFhZLkOII6eEhMkrnMYNCXQaeOlsL/Wn1IoCwPKa jTVdL5viZSb1BVDMhvY0MzBZo41y4UmOyl9MMJ8XTSoSEGWVmaNoY8i9C3L1RyGIU/P2 A2P9SGTkBfGX0sJUwNXrneC/g5ICmqDUaCElH4y4AxprsALsjAp9o+jPaN3kZUobwpDi emBJzVpr3to6xqmxs8TGp9wiwES+2q86xodeO2tRp6V/QgcvP9RlOA2s6JSO6xqnCndT Q7EIyizdpiOiEGqadOO1xgfZq/0y4YP72YZOZStHG2Qz7WgFP5+QvGq2ZkIVOnCQ9gF1 LYIA== X-Gm-Message-State: AGi0Pua4XwVmuqdnFn6DtrjuI/8rUjxA5Bvjr7KvfH+w+2uLPg7ih6q2 zWnMYZJB197cMv7D1gTIpcD6jJ9468c= X-Google-Smtp-Source: APiQypIoJ+T9YtOpzSZSTcjKso8wIhlnlJOA13ej2icfTFkf/gbQehMcd06Tu7qLkEufcHhT8u+a2g== X-Received: by 2002:a17:90a:2ac7:: with SMTP id i7mr12618371pjg.130.1587569441079; Wed, 22 Apr 2020 08:30:41 -0700 (PDT) Received: from [192.168.0.24] (zaq3dc06154.zaq.ne.jp. [61.192.97.84]) by smtp.gmail.com with ESMTPSA id s44sm6016272pjc.28.2020.04.22.08.30.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2020 08:30:40 -0700 (PDT) To: "Hale, Britta (CIV)" , "mls@ietf.org" References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> <8f0933dd-7dc3-3603-9401-a5907b85fac2@datashrine.de> <732de8b8-7be9-eac3-8966-eb97ca985a02@wickr.com> <83DBF73B-7CD2-4E36-8C3D-4A361A1D4A02@nps.edu> From: Joel Alwen Autocrypt: addr=jalwen@wickr.com; keydata= mQENBFyIZvABCAC65JupY1w7gzhhNo41ftIk09n7Lid9p31jDR8Jefv9R5sWL+HZFGDeABAY 1J1JvV6vOaMsfdy9iUFfGS1GhMJ3+mh799SIsB3JSfPq/eq6Jut57D2yPtILmc7ZbuJyBHg0 xuYfKCQQAYikW+v2LJQU1Y+BUDbVldpzxSc8Z3PPSfunWdzhY6qAAhyCv+Y8EzJlQivMwD5B f6737krf8SoBsjsqCHQrRo/r+BSj5Wtd5/K3FkmWLOUAFoYK23+cpoFntGJKZfss27gDPhyS gX9ibXcBGQqBEF4qDPEzEHK8iQmXTxLul5Y7lQ6ADf69xH15WM4GmRBeCvR3Uanxcr2/ABEB AAG0HUpvZWwgQWx3ZW4gPGphbHdlbkB3aWNrci5jb20+iQFUBBMBCAA+FiEEYFNg9IH2SV6e 03O3FR5tDZv8eygFAlyIZvICGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ FR5tDZv8eyjSywgApQNIRcL4IKTJ0I4XwcQRhICu1Bht3c2fUnG2YziJXjGf6DZ49uKKtuIu fk8mNS+vKRLoLZ7+u+Pv/Yjmk8jtrr6Saz1vnfsle3GgmXG5JaKOM5cOfeo5JnlNUP3QonR7 LMZwY1qVKg2mzNmwi0jG1zIGgQ5fiAwqe+YTNFli5bc/H1O9LcSmbrLV9OyucARq11DIiAvU fDknZ17OahQls+9mgfAXH5vZjzo296tYvzkOJQ2A6GPxdMHIXGbJM/vjuMe2QJl6C0zaqOtm JvFcx/HpNhmugYI9OsNAd7846HASDp8BKyfY5FYP7bn0/JBuCpg18Aykru6xyFjG3gv0Lw== Message-ID: <3e877976-5300-d5b4-f755-2ef7738030dd@wickr.com> Date: Thu, 23 Apr 2020 00:30:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83DBF73B-7CD2-4E36-8C3D-4A361A1D4A02@nps.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 22 Apr 2020 15:30:44 -0000 Roughly speaking, I'd say the goal is to protect honest group members from members unintentionally using bad randomness (i.e. randomness with low entropy for the adversary) but who otherwise follow the protocol. This includes the sender using bad randomness and the receivers. Of course, there are limits to what can be achieved but that's the ideal. In practical terms, this can well be caused by poor configurations, overly deterministic boot processes or straight up buggy logic rather than actual explicit attacks by an adversary. So put differently, the idea is to reduce what an attacker with information (or influence over) randomness can achieve in terms of breaking privacy, authenticity and whatever other security goals we have for MLS. > However, if receiver would not notice if the sender took the correct steps, then they do not have any guarantee Yup, some solutions have that property (e.g. the "entropy pool" approach and Konrad's proposal). Others are more tightly connected to correctness like the "mixing in old keys" approach. (Personally I favor the latter. I like things noticeably breaking when security precautions aren't being taken.) > So is the goal to protect the sender from their own bad randomness, or to protect an unaware receiver, in the event that the sender actually behaves correctly? There can still be a gain from such a change, but it seems to be a far weaker guarantee if there is no awareness at the receiver. What do you mean by far weaker? From what I can tell whats lost when receivers can (in fact, are forced to) verify that defenses are being applied is that it becomes harder to implement the protocol poorly. Is that what you mean? Or is there more? > We also need to be careful in the differentiation of leaking state to the adversary, which may well reveal the entire current state, and a bad random generator. I agree. Both are interesting and different attacks / failure modes. (In Sandro, Yiannis and my work on security analysis of MLS we're treating these as two different types of corruption modes available to the adversary.) - Joël On 22/04/2020 23:58, Hale, Britta (CIV) wrote: > I am trying to understand the threat model we are working with on this. When trying to protect against bad randomness, the goal would seem to be to protect a receiver against potentially bad randomness from the sender. However, if receiver would not notice if the sender took the correct steps, then they do not have any guarantee - in fact, a sender could just incorrectly implement this without breaking functionality and no one would be the wiser that the bad-randomness protection has been lost (if I understand the proposal correctly). > > So is the goal to protect the sender from their own bad randomness, or to protect an unaware receiver, in the event that the sender actually behaves correctly? There can still be a gain from such a change, but it seems to be a far weaker guarantee if there is no awareness at the receiver. > > We also need to be careful in the differentiation of leaking state to the adversary, which may well reveal the entire current state, and a bad random generator. > > -- Britta > > > On 4/22/20, 5:48 AM, "MLS on behalf of Joel Alwen" wrote: > > Hey Konrad! > > On 22/04/2020 21:24, Konrad Kohbrok wrote: > > One way to keep it transparent for the receiver (if that is indeed what we want) > > would be for the updating party to include the previous epoch's path_secret[0] > > when creating a fresh path_secret[0] and then KDF'ing up the tree as before. In > > other words, follow your MLS specific suggestion, but only for the leaf secrets. > > Since that is (I think?) the only place new randomness comes into the tree > > anyway, it would have about the same effect, wouldn't it? Also, it would be a > > minor change to the protocol and the receiver wouldn't even notice if the sender > > did it (for better or worse). > > I like that this is less invasive in terms of changes. (Though IMO its actually > a Pro not a Con that functionality breaks when you don't implement any given > defense correctly, including those against bad randomness.) > > One nit: better to derive something off of the old path_secret[0] and use that > rather than use path_secret[0] directly. Don't want to keep path_secret[0] > around after a commit (bad for FS of TreeKEM / PCFS of MLS). > > I do think that using only path_secret[0] defends a bit less though. E.g. say > Alice & Bob are siblings (and everything is delivered & process immediately). > Here's an execution. > > 1) Alice commits. > 2) Leak Alice's state to adversary. > 3) Bob commits. > 4) Alice commits with bad randomness. > > Mixing in only something from path_secret[0] means all keys in commit (4) are > now bad. But mixing in something from old path_secret[n] for new pub/priv key n > means all but her leaf are now good keys. > > - Joël > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > From nobody Wed Apr 22 09:30: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 431E83A0FAC for ; Wed, 22 Apr 2020 09:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QNfiIuMCpzhC for ; Wed, 22 Apr 2020 09:28:53 -0700 (PDT) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 12B123A0FAB for ; Wed, 22 Apr 2020 09:28:52 -0700 (PDT) X-ASG-Debug-ID: 1587572932-0e394549633cf900001-bGA3T6 Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id eksyigfKP8S4yfVH; Wed, 22 Apr 2020 09:28:52 -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; Wed, 22 Apr 2020 09:28:52 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) 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; Wed, 22 Apr 2020 09:28:51 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sre2QA9fUs/Rk7qrQH6D5WTzuusy5dipzXZlrRzpXyO4sJOpEhEE19TJ/qa8w1RHU52A6k8xmth8CuDiihiRyt1Q3lSGMIoRKozVL2GU9JN+GAhtiP5npKv8Xc9DHJ4M0Hyu8sqVH9tb8yOumdgeK9fGBv5wcv4j1SYDso4TBV8RR1kRGQ9F0IXR3fOWmkm/UNApVKmwif5Av/hShTEJGYrp3yJNCxGtlTWi1gdQ4LqfG3AxWL0g4LFBhxfyavL8OxNgq90ldoWSiw/B3d38VfUDilBOTfy34wEyqjsqxuyAnnnj4A/4TAFcmCoXhTrAb53jJenM4UFidWHcZNulYg== 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=k6GRzx1RORDNB3NQMLGwwvUTn8f9EeFKKSQdaQY36JE=; b=RgnlB0TfDrpGusZ4I1cLlx66fjKX9izqyV8wCvcCzqDS5K/yCHN6oSBWJjenbwUNmIuRRcNEA99GYQ1bKWhiDuKOnxAScG3fMFwOaaPrt5oRQuGbRD0CP9ZYTwgf6It5/svEUgBAdgmd5g/c/cZWQWSMv/iw2v7e6avEgNUQKR081cg3ZD70JU2GuxK9SoCt63OhgrXjANd7Wemb6LA08ZffA1gsTSDr9vF5LTe33tSBwVY8KpJSZL0QYGNLoG4oq54gdSmsIQO1/eEZX+vd1Xg8aMbb/5jSnsGyFQHG1IcChuK/Vvd/RT//2oiLJdjUYJ5AucU17gLlcYE3Cub0Uw== 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 BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) by BY5PR13MB3507.namprd13.prod.outlook.com (2603:10b6:a03:1a8::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Wed, 22 Apr 2020 16:28:50 +0000 Received: from BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::b93a:9f12:aa45:6194]) by BY5PR13MB3013.namprd13.prod.outlook.com ([fe80::b93a:9f12:aa45:6194%7]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 16:28:50 +0000 X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:1a8::27] X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:1a8::27 From: "Hale, Britta (CIV)" To: Joel Alwen , "mls@ietf.org" Thread-Topic: [MLS] hardening MLS against bad randomness X-ASG-Orig-Subj: Re: [MLS] hardening MLS against bad randomness Thread-Index: AQHWFLWofXOAPH5gNE6s9ckk8yY+RaiFGKOAgAAGagD//68jgIAAflQA//+a6YA= Date: Wed, 22 Apr 2020 16:28:50 +0000 Message-ID: <4AFC4961-AC70-48A0-A53C-71A2F1E6CBC1@nps.edu> References: <717aea51-d03b-c555-3863-a7b2b7a0eed6@wickr.com> <8f0933dd-7dc3-3603-9401-a5907b85fac2@datashrine.de> <732de8b8-7be9-eac3-8966-eb97ca985a02@wickr.com> <83DBF73B-7CD2-4E36-8C3D-4A361A1D4A02@nps.edu> <3e877976-5300-d5b4-f755-2ef7738030dd@wickr.com> In-Reply-To: <3e877976-5300-d5b4-f755-2ef7738030dd@wickr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.14.200307 authentication-results: spf=none (sender IP is ) smtp.mailfrom=britta.hale@nps.edu; x-originating-ip: [69.226.214.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 96b62ac2-1dd8-401f-db89-08d7e6da3d8c x-ms-traffictypediagnostic: BY5PR13MB3507: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03818C953D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3013.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(136003)(366004)(376002)(39850400004)(75432002)(66556008)(66446008)(110136005)(66476007)(316002)(5660300002)(786003)(8936002)(36756003)(6512007)(76116006)(66946007)(86362001)(64756008)(8676002)(26005)(6486002)(81156014)(2616005)(478600001)(71200400001)(186003)(33656002)(6506007)(2906002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: nps.edu does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NRFyWbcdnIx/a5Cx3CaVGY4jI2Y8FuSfPENKHIU7NOrpDBxibqUYhzrgQ23fhht/V599/5Ern75GRcPNceJNEyJ3wLKLNMRj51M2e/rYr/zltlVX/GxtopuWOjNj4VY8XwXajQtDylkI3y+KFUfGJgJpV0EUQgZAKsQQT3ukIF2umz22rkRUipocX4/FaRSnjp6JiqUxy9goLs1U8HSL6MB58FZXipZDrQg/k1WPAPzI5U+StrynL3Q0Fg+1RCNaSPPWZcj2834222xNCyyTkvWG1N80tINUeKNWsHisLKIhGib3ylepvY3Hbp16hvnhf6Yxk/kmAvbBzsA1/5GLRddo7CZm5hm6lDO+jDsTTqNsP7NHyg5564NzVydfVNkBMz9QYAUEvDTFw5CjRDopJbVbPjn6v0h9kQLFXNjylRAORM8pugi6RWs05D0A9ak+ x-ms-exchange-antispam-messagedata: FM6coRr3AQNIvFM8LRcn+rMo8ubxNzgL9O4GE+CgreX7RQhyqFEk2WVZcdlulQ+8G61OKCz89VEui1K9CcZKLZqJ7cOuFuoAdnpQKXLGtUtd5cYrUJxFp9d2QsbUWb7XWcsqDdmG+xco7ra3+eEQiA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4DC2BE1A625AD7439FD1583704AF64BB@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 96b62ac2-1dd8-401f-db89-08d7e6da3d8c X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 16:28:50.4146 (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: oiiOLzg+hdrFUzB3hGQhEDsBTSmdVflYmBhsQUKl8aZ5su5yYVa86Mgf4UJZFmzLxoAwCli4zL6oryb40nPYwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3507 X-OriginatorOrg: nps.edu X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117] X-Barracuda-Start-Time: 1587572932 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: 1971 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.81356 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [MLS] hardening MLS against bad randomness 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, 22 Apr 2020 16:28:55 -0000 DQrvu79PbiA0LzIyLzIwLCA4OjMwIEFNLCAiSm9lbCBBbHdlbiIgPGphbHdlbkB3aWNrci5jb20+ IHdyb3RlOg0KDQogICAgV2hhdCBkbyB5b3UgbWVhbiBieSBmYXIgd2Vha2VyPyBGcm9tIHdoYXQg SSBjYW4gdGVsbCB3aGF0cyBsb3N0IHdoZW4gcmVjZWl2ZXJzDQogICAgY2FuIChpbiBmYWN0LCBh cmUgZm9yY2VkIHRvKSB2ZXJpZnkgdGhhdCBkZWZlbnNlcyBhcmUgYmVpbmcgYXBwbGllZCBpcyB0 aGF0IGl0DQogICAgYmVjb21lcyBoYXJkZXIgdG8gaW1wbGVtZW50IHRoZSBwcm90b2NvbCBwb29y bHkuIElzIHRoYXQgd2hhdCB5b3UgbWVhbj8gT3IgaXMNCiAgICB0aGVyZSBtb3JlPw0KDQpCYXNp Y2FsbHksIGJ5IGxvc2luZyBkZXRlY3Rpb24gZ3VhcmFudGVlcyBvbiB0aGUgcmVjZWl2ZXIsIHdl IGFsc28gbG9zZSBhbGwgYXNzdXJhbmNlIG9mIHByb3RlY3Rpb24gZnJvbSBiYWQgcmFuZG9tbmVz cy4gVGhhdCBpcyBub3QgdGhlIHNhbWUgYXMgbG9zaW5nIHByb3RlY3Rpb24gLSB3aGljaCB3ZSBz dGlsbCBoYXZlIGlmIGFsbCBwYXJ0aWVzIGFyZSBhY3RpbmcgaW4gZ29vZCBmYWl0aCAtIGJ1dCB3 ZSBkbyBsb3NlIGFzc3VyYW5jZSBvZiBpdC4gDQoNCktvbnJhZCdzIHNvbHV0aW9uIHN0aWxsIGhh cyBiZW5lZml0cyBmb3IgYSBzZW5kZXIgKGlmIHRoZSBwcm90b2NvbCBpcyBhbiBob25lc3QgaW1w bGVtZW50YXRpb24gYW5kIHRoZSByYW5kb21uZXNzIGdlbmVyYXRpb24gaXMgYmFkKSwgYW5kIGZv ciBhIHJlY2VpdmVyIChpZiB0aGUgc2VuZGVyIGhhcyBhbiBob25lc3QgaW1wbGVtZW50YXRpb24p LiBIb3dldmVyLCBzaW5jZSB0aGUgcmVjZWl2ZXIgb25seSBnZXRzIGd1YXJhbnRlZXMgYmFzZWQg b24gYW4gdW52ZXJpZmlhYmxlIGFzc3VtcHRpb24sIHRoZSBiZW5lZml0IGlzIGZhciB3ZWFrZXIu IFBlcnNvbmFsbHksIEkgZmF2b3IgdGhlIHZlcmlmaWFibGUgYXBwcm9hY2ggKHJlY2VpdmVyIGNh biBkZXRlY3QpLiAgIA0KDQpIb3dldmVyLCBpZiB0aGUgY29tcHV0YXRpb25hbCBjb3N0IGlzIGxv dyAod2hpY2ggaXQgc2VlbXMgdG8gYmUpLCB0aGVuIGl0IGlzIHN0aWxsIHdvcnRod2hpbGUgdG8g bWFrZSB0aGF0IGNoYW5nZSBpZiBub3QgZ29pbmcgZm9yIHRoZSBmdWxsIGFzc3VyYW5jZSBhcHBy b2FjaC4gVGhlcmUgaXMgY2VydGFpbmx5IG90aGVyIHdvcmsgYmFzZWQgb24gdGhlIGFzc3VtcHRp b24gb2YgYSAibW9zdGx5IGhvbmVzdCIgc2VuZGVyLCB3aGVyZSBhbiBhZHZlcnNhcnkgY2FuIGNv bnRyb2wgcGFydGlhbCBpbnB1dHMuIA0KDQogICAgSSBhZ3JlZS4gQm90aCBhcmUgaW50ZXJlc3Rp bmcgYW5kIGRpZmZlcmVudCBhdHRhY2tzIC8gZmFpbHVyZSBtb2Rlcy4gKEluIFNhbmRybywNCiAg ICBZaWFubmlzIGFuZCBteSB3b3JrIG9uIHNlY3VyaXR5IGFuYWx5c2lzIG9mIE1MUyB3ZSdyZSB0 cmVhdGluZyB0aGVzZSBhcyB0d28NCiAgICBkaWZmZXJlbnQgdHlwZXMgb2YgY29ycnVwdGlvbiBt b2RlcyBhdmFpbGFibGUgdG8gdGhlIGFkdmVyc2FyeS4pDQoNCk9LLCB0aGVuIEkgbWlzdW5kZXJz dG9vZCB5b3VyIG1lYW5pbmcuIFlvdXIgKDEtMi0zLTQpIGV4YW1wbGUgaGFkIGV4cGxpY2l0bHkg ZGVzY3JpYmVkIGEgUmV2ZWFsIHF1ZXJ5LXR5cGUgc2V0dGluZyB3aXRoIGxlYWthZ2Ugb2YgdGhl IHdob2xlIHN0YXRlLCB2aWNlIGJhZCByYW5kb21uZXNzIGdlbmVyYXRpb24uIA0KDQpGaW5hbCBj b21tZW50OiANCiAgICBCdXQgbWl4aW5nIGluIHNvbWV0aGluZyBmcm9tIG9sZCBwYXRoX3NlY3Jl dFtuXSBmb3IgbmV3IHB1Yi9wcml2IGtleSBuIG1lYW5zIGFsbCBidXQgaGVyIGxlYWYgYXJlIG5v dyBnb29kIGtleXMuDQoNCkkgd2FudCB0byBub3RlIHRoYXQgdGhpcyBzb2x1dGlvbiBoYXMgdGhl IGFkZGVkIGJlbmVmaXQgb2YgYSBtYWludGFpbmluZyBhIGZvcm0gb2YgdHJhbnNjcmlwdCBoaXN0 b3J5IHBlciBrZXkuDQoNCi0tIEJyaXR0YQ0KDQoNCg0K From nobody Sun Apr 26 00:48: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 AD03D3A0F9F for ; Sun, 26 Apr 2020 00:48:04 -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, HTML_MESSAGE=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=eTqnEh3Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q74tOltC 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 EQwkQ-fRVe-y for ; Sun, 26 Apr 2020 00:48:03 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48DC3A0F9E for ; Sun, 26 Apr 2020 00:48:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4ADB45C02FE for ; Sun, 26 Apr 2020 03:32:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 26 Apr 2020 03:32:52 -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= fm2; bh=Jf3bFlEwWEpwJKOgrq366JkpP8/sSzxKoAKHlvz8RvI=; b=eTqnEh3Q Nr6PUtATo9utiHsE7V4qoTxGGRRVxTo+3jytgLGUEbQvMcTCG+NQZgVVVSuzoEm8 57BnuNY91U41D/QyJvQNwzrEFMESclIvbbez12yN5Hz6i5vCxo8FzXBMtztqjv3x k+kSpV6zsWOKafKiyUxC91xM3osjfpL7hF7dr7uhzAnmvfqXZpItn6iz25UY3tIx M+znNyvHrp6ofWKnfrGjYWYujLvz7PkALqTSHpc0iljaAf5JTE2DBIbHluW4G6vx fXBNW2zG2iP3Wxib9nZVHJEhTFZxOcvbgYcnOukV7z3ldbf0KGbAyZT0yzLrI6FZ AICwaC8PJMKzrA== 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=fm2; bh=Jf3bFlEwWEpwJKOgrq366JkpP8/sS zxKoAKHlvz8RvI=; b=q74tOltCNo7y722PGDa7YS2xsE9ZVYilugIcI5uehMu+q vjQLtPJRLr6/PMwR9KxsBaXA/1ynq7+DWPDL0fYX6zNZyMv8BN8MCkwDufVJ3LcC RaOR7jze4K4h04lU/EUCyQ+973B+2v11/VW4jHQnb4r8FXVkRjuulWHkYqv3VNsV WAmoriz5WToE1+HdulIufVIHsIQyy7zxhqJ7rC4k5oKkmocfwSnl6HTK+dq27bk/ rqHrcy08xgj2C9UaeS3Om/VPNnIgxKckHOMCuDi+f1XlJ6v7uqfP3UCszdpxGkc7 NW6RhhpJ6Uh18FRHKlBxZ2YRX0cNwRSYjb0njHrkQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppedufedrledtrddvvdeirddvtddvnecuvehluhhsthgv rhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplh ihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az86.internal.cloudapp.net (unknown [13.90.226.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 156253065E0F for ; Sun, 26 Apr 2020 03:32:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6549649544096217723==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: mls@ietf.org Message-Id: <20200426073252.156253065E0F@mailuser.nyi.internal> Date: Sun, 26 Apr 2020 03:32:52 -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 Apr 2020 07:48:05 -0000 --===============6549649544096217723== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * mlswg/mls-protocol (+0/-0/=F0=9F=92=AC4) 3 issues received 4 new comments: - #323 Fix context for new-member-initiated Add (2 by Bren2010, bifurcati= on) https://github.com/mlswg/mls-protocol/issues/323 [bug]=20 - #301 Targeted message (1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/301 [discussion] [function= ality] [privacy]=20 - #300 Order in which proposals should be applied is a little bit vague (= 1 by bifurcation) https://github.com/mlswg/mls-protocol/issues/300=20 Pull requests ------------- * mlswg/mls-protocol (+0/-3/=F0=9F=92=AC4) 1 pull requests received 4 new comments: - #320 Use node type instead of leaf index in tree hashes. (4 by Bren2010= , bifurcation) https://github.com/mlswg/mls-protocol/pull/320=20 3 pull requests merged: - Change expiration extension to lifetime extension. https://github.com/mlswg/mls-protocol/pull/317=20 - Use correct type for uint32. https://github.com/mlswg/mls-protocol/pull/319=20 - Fix markdown formatting issue for Ciphersuite section https://github.com/mlswg/mls-protocol/pull/318=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/mlswg/mls-architecture * https://github.com/mlswg/mls-protocol * https://github.com/mlswg/mls-federation --===============6549649544096217723== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (MLS Working Group summary)

Sunday April 26, 2020

Issues

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

3 issues received 4 new comments:

Pull requests

mlswg/mls-protocol (+0/-3/=F0=9F=92=AC4)

1 pull requests received 4 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============6549649544096217723==-- From nobody Mon Apr 27 17:57:32 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 5DA9A3A0A60 for ; Mon, 27 Apr 2020 17:57:30 -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 34z1jVGavga0 for ; Mon, 27 Apr 2020 17:57:29 -0700 (PDT) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (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 068FD3A0A5D for ; Mon, 27 Apr 2020 17:57:28 -0700 (PDT) Received: by mail-qv1-xf2e.google.com with SMTP id di6so9601479qvb.10 for ; Mon, 27 Apr 2020 17:57:28 -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=Z9hifXXLDfHQozx3lWXXi6r3mQpO8q3dFQuR0lllAYA=; b=CJeydyqhzpwe6gRMBVfEsCq/49X84/QyEp+Dac4QH7kgcNVmjRMt8CyCde4Vw7ZhSk dHcuMVGcnFR4I6ufQuFQ8F+ws+L03dhpts7ICJakqFT8AOWtE0LmVaoa/A0Bl11V5Hpo uT7rrH5tjpjIqeJgAiqOKNUsU20nPrqafdYqM= 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=Z9hifXXLDfHQozx3lWXXi6r3mQpO8q3dFQuR0lllAYA=; b=OYt4vzEiBki2yT0/2ny4YGxjfV4YSqu5w01ba8rij9CIbisEQ+Khcf8rx+dpFynIs8 W3uQlC6OG99/qZXtGfDeB/M3CWdem3PLwpN2zenwJxLumkyKW/z2cnFDEbvAvs9WKGF6 H0zZoHGpUAmKq8Bw6NJlOl35t2W+mH058G4QRgiKpCyi7TJqzP+LcIVNvmpLbyrIiihT 7NiKHRWk3/IacmD9fwOHwcvvFcWqYv7S3QUwxN8icFFCupSLq7RHzmg9krHYWna5keQK eem575AuxNmHF3rLfoeKC2EEZX8qI1kO3arJD6FcyX/igM9Uj67PNfz32FY6w7A3gJ6z hc0w== X-Gm-Message-State: AGi0PuaYq6znxkqrR3tZ/qoESwczfgiKjBhtf5dQKDgiWPZpCGHpkuHk 9oV2WQ9olBDzidyN5y/XZRAuEib8n9k= X-Google-Smtp-Source: APiQypK+KHAqIa4Nr8zlm6ay+l7i8oRYbtFB8p0ArVCkQSb0ohdsOT8OAvPAwGbAbiswwCfcu4eBIA== X-Received: by 2002:a05:6214:7a7:: with SMTP id v7mr20841810qvz.27.1588035447566; Mon, 27 Apr 2020 17:57:27 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id b42sm13039188qta.29.2020.04.27.17.57.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 17:57:26 -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.80.23.2.2\)) Date: Mon, 27 Apr 2020 20:57:26 -0400 References: To: MLS List In-Reply-To: Message-Id: <12F5469A-F972-4B19-86A1-B13201BCD9CD@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] Virtual Interim Meeting Times 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 Apr 2020 00:57:30 -0000 hi MLS! We got equal responses for: 1600 UTC =3D 1800 CEST =3D 1700 BST =3D 1200 ET =3D 0900 PT and 1700 UTC =3D 1900 CEST =3D 1800 BST =3D 1300 ET =3D 1000 PT Let=E2=80=99s shoot for the former. Stay tuned for a meeting invite. spt > On Apr 21, 2020, at 22:26, Sean Turner wrote: >=20 > hi MLS, >=20 > We are planning four more virtual interim meetings: 5 May, 19 May, 2 = June, and 16 June. Please let us know which time works best for you = here: > https://forms.gle/PS1CFPkZYRVLTGqC6 >=20 > Thanks! >=20 > Nick and Sean From nobody Mon Apr 27 18:02:24 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 02ED73A0A8E; Mon, 27 Apr 2020 18:02:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, mls@ietf.org, sean@sn3rd.com, mls-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158803574083.19043.1196953972603957712@ietfa.amsl.com> Date: Mon, 27 Apr 2020 18:02:21 -0700 Archived-At: Subject: [MLS] mls - New Interim Meeting Request 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: Tue, 28 Apr 2020 01:02:22 -0000 A new interim meeting series request has just been submitted by Sean Turner. This request requires approval by the Area Director of the Security Area The meetings can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 Meeting: 1 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Meeting Type: Virtual Meeting Session 1: Date: 2020-05-05 Start Time: 12:00 America/New_York Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 Agenda Note: --------------------------------------------------------- Meeting: 2 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Meeting Type: Virtual Meeting Session 1: Date: 2020-05-19 Start Time: 12:00 America/New_York Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 Agenda Note: --------------------------------------------------------- Meeting: 3 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Meeting Type: Virtual Meeting Session 1: Date: 2020-06-02 Start Time: 12:00 America/New_York Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 Agenda Note: --------------------------------------------------------- Meeting: 4 --------------------------------------------------------- Working Group Name: Messaging Layer Security Area Name: Security Area Session Requester: Sean Turner Meeting Type: Virtual Meeting Session 1: Date: 2020-06-16 Start Time: 12:00 America/New_York Duration: 01:00 Remote Participation Information: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 Agenda Note: --------------------------------------------------------- From nobody Mon Apr 27 18:35: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 6B96C3A0B59 for ; Mon, 27 Apr 2020 18:35: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 u_DR_8NtKjNP for ; Mon, 27 Apr 2020 18:35:05 -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 2BAED3A0B6C for ; Mon, 27 Apr 2020 18:35:05 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id w29so16106607qtv.3 for ; Mon, 27 Apr 2020 18:35:05 -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=qaqXy91IyZ03tvwfLCNgbzRDlHYY+1SaDud9Pl53mys=; b=XFFEwrayt1wmfES/iEm0nRgnaH2E5gg29Q/Gypm/lwmZut8VWSNGTXQVTOFp+eAxDm 0IxMJ1lHhn3FIBhvKedQutfJVVjKYXqOxeHOdrsBoDZjg3h5smpFeUzMsGzLysPVtjxi EqZe8n3VSnYSXEW7UTnCtg6NjbEt/6ku0f4ik= 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=qaqXy91IyZ03tvwfLCNgbzRDlHYY+1SaDud9Pl53mys=; b=fV5yKQenm0vEabMGxZCuiwHyUscaIgjBGz3ectPSzcm+grw5XBw8sgtplqq6DOVTg+ PxuUcj/D10G3gb11QoSfVNRRrHT8rR5Q/Fru7UFf7cuWmSSWE+YsLGUlRWVHzTy7mqIy 9uUJdrAFf1qIht6Q/Tee9z7TJJuGOSzoeK+SbY5NEM+388mj2Gmw6pSeqiPvsX8WSS9N FqWgfeDFzjEE/earZeNhp7Fs0QNtT62Y1EsGXGAyIar55vCMZQ4H4VZlpkCRQl+1JzxD gW8elkrC38b4frJjTDC3TqMxcXYdRRCl6d/Td3UMWWFjrdB9X4ruY1o+sNRwLyrkk5oO 8UOg== X-Gm-Message-State: AGi0PuYrn3PPtbk5P1IzhEQvf+zgWuIn4hXxOsoULKRIQmhJuUJvkRqc agJYGc41TRiivO4pLAFNTeak+cyjQW4= X-Google-Smtp-Source: APiQypK937i+9iKniju2N/R5aQyBsnxJMO7TikeP/CUi/ZXh36ahmakF0alPQ63dsmR3MT2QpdQqcQ== X-Received: by 2002:ac8:46d0:: with SMTP id h16mr26790644qto.242.1588037704076; Mon, 27 Apr 2020 18:35:04 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id j92sm12378845qtd.58.2020.04.27.18.35.03 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Apr 2020 18:35:03 -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, 27 Apr 2020 21:35:02 -0400 References: <158803574083.19043.1196953972603957712@ietfa.amsl.com> To: MLS List In-Reply-To: <158803574083.19043.1196953972603957712@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [MLS] mls - New Interim Meeting Request 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 Apr 2020 01:35:16 -0000 > On Apr 27, 2020, at 21:02, IETF Meeting Session Request Tool = wrote: >=20 >=20 > A new interim meeting series request has just been submitted by Sean = Turner. >=20 > This request requires approval by the Area Director of the Security = Area >=20 > The meetings can be approved here:=20 > = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-12 > = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-13 > = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-14 > = https://datatracker.ietf.org/meeting/interim/request/interim-2020-mls-15 >=20 >=20 > Meeting: 1 > --------------------------------------------------------- > Working Group Name: Messaging Layer Security > Area Name: Security Area > Session Requester: Sean Turner >=20 > Meeting Type: Virtual Meeting >=20 > Session 1: >=20 > Date: 2020-05-05 > Start Time: 12:00 America/New_York > Duration: 01:00 > Remote Participation Information: = https://ietf.webex.com/ietf/j.php?MTID=3Dm7822117cbe3d654736b2dbaf0078e353= > Agenda Note:=20 Please note that the first of these interim meeting (the one above) will = be dedicated to key schedule related issues/PRs. spt= From nobody Tue Apr 28 06:06: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 408D83A14FA; Tue, 28 Apr 2020 06:06:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158807918320.16111.16696571564470627952@ietfa.amsl.com> Date: Tue, 28 Apr 2020 06:06:23 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-05-05 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: Tue, 28 Apr 2020 13:06:30 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-05-05 from 12:00 to 13:00 America/New_York (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 From nobody Tue Apr 28 06:25:35 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 011313A1517; Tue, 28 Apr 2020 06:25:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158808031968.5463.14178606778347083083@ietfa.amsl.com> Date: Tue, 28 Apr 2020 06:25:19 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-05-19 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: Tue, 28 Apr 2020 13:25:20 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-05-19 from 12:00 to 13:00 America/New_York (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 From nobody Tue Apr 28 06:25:42 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 06B713A1551; Tue, 28 Apr 2020 06:25:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158808033097.20358.2585562133589654148@ietfa.amsl.com> Date: Tue, 28 Apr 2020 06:25:31 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-06-02 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: Tue, 28 Apr 2020 13:25:37 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-06-02 from 12:00 to 13:00 America/New_York (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353 From nobody Tue Apr 28 06:26:21 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 02A933A159C; Tue, 28 Apr 2020 06:26:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158808037298.23270.15850918637799923757@ietfa.amsl.com> Date: Tue, 28 Apr 2020 06:26:13 -0700 Archived-At: Subject: [MLS] Messaging Layer Security (mls) WG Virtual Meeting: 2020-06-16 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: Tue, 28 Apr 2020 13:26:20 -0000 The Messaging Layer Security (mls) Working Group will hold a virtual interim meeting on 2020-06-16 from 12:00 to 13:00 America/New_York (16:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7822117cbe3d654736b2dbaf0078e353