Re: [MLS] hardening MLS against bad randomness

Joel Alwen <jalwen@wickr.com> Wed, 22 April 2020 15:30 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 188AD3A0EC1 for <mls@ietfa.amsl.com>; 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 <mls@ietfa.amsl.com>; 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 <mls@ietf.org>; Wed, 22 Apr 2020 08:30:41 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id 7so2577291pjo.0 for <mls@ietf.org>; 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)" <britta.hale@nps.edu>, "mls@ietf.org" <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 <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: <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: <https://mailarchive.ietf.org/arch/msg/mls/LPCXnM2SkRm3HiYPfzveuYM8nrg>
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 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" <mls-bounces@ietf.org on behalf of jalwen@wickr.com> 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
>     
>