Re: [MLS] hardening MLS against bad randomness

"Hale, Britta (CIV)" <> Wed, 22 April 2020 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A00863A0E1B for <>; Wed, 22 Apr 2020 07:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xl94Wwu8aW8G for <>; Wed, 22 Apr 2020 07:58:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CAD013A0E18 for <>; Wed, 22 Apr 2020 07:58:35 -0700 (PDT)
X-ASG-Debug-ID: 1587567514-0e394549633cea50001-bGA3T6
Received: from ( []) by with ESMTP id OGs4hHYZmQ4QhFZc; Wed, 22 Apr 2020 07:58:34 -0700 (PDT)
Received: from ( by ( 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 ( by ( 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;; 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;; 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; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
Received: from (2603:10b6:a03:185::31) by (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 ([fe80::b93a:9f12:aa45:6194]) by ([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 <>, "" <>
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: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
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:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; 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 ( 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-Barracuda-Start-Time: 1587567514
X-Virus-Scanned: by bsmtpd at
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 Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Archived-At: <>
Subject: Re: [MLS] hardening MLS against bad randomness
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

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" < on behalf of> 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