[MLS] reusing HPKE keys from welcome messages

Joel Alwen <jalwen@wickr.com> Fri, 17 April 2020 07:48 UTC

Return-Path: <jalwen@wickr.com>
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 <mls@ietfa.amsl.com>; 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 <mls@ietfa.amsl.com>; 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 <mls@ietf.org>; Fri, 17 Apr 2020 00:48:00 -0700 (PDT)
Received: by mail-pg1-x531.google.com with SMTP id w11so706053pga.12 for <mls@ietf.org>; 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 <mls@ietf.org> (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 <mls@ietf.org>
From: Joel Alwen <jalwen@wickr.com>
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: <f5323320-49d8-d0cd-3ad5-85f1cf46dff0@wickr.com>
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: <https://mailarchive.ietf.org/arch/msg/mls/M0mb893lr8dGL-Pw5KpUAt15wuQ>
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 <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=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.