Re: [MLS] hardening MLS against bad randomness

Joel Alwen <jalwen@wickr.com> Wed, 22 April 2020 12:47 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 885BD3A0B6C for <mls@ietfa.amsl.com>; 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 <mls@ietfa.amsl.com>; 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 <mls@ietf.org>; Wed, 22 Apr 2020 05:47:55 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id x77so1037205pfc.0 for <mls@ietf.org>; 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 <mls@ietf.org> (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 <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: <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: <https://mailarchive.ietf.org/arch/msg/mls/O8_0Pmjn12L6UoMCeJTV6KGBLvo>
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 <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: 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