Re: [MLS] hardening MLS against bad randomness

"Hale, Britta (CIV)" <britta.hale@nps.edu> Wed, 22 April 2020 14:58 UTC

Return-Path: <britta.hale@nps.edu>
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 <mls@ietfa.amsl.com>; 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 <mls@ietfa.amsl.com>; 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 <mls@ietf.org>; 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)" <britta.hale@nps.edu>
To: Joel Alwen <jalwen@wickr.com>, "mls@ietf.org" <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: <BY5PR13MB37968EAEEBF38F79713D6787FBD20@BY5PR13MB3796.namprd13.prod.outlook.com>
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: <C6FB3DCA0910894F8419A6E2F04456DE@namprd13.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/mls/ghX5L5P5NKcwbCxoXTeHKwHAB5E>
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 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" <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