Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule

Brendan McMillion <brendan@cloudflare.com> Tue, 18 August 2020 16:34 UTC

Return-Path: <brendan@cloudflare.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 EC5943A0EAC for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 09:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=cloudflare.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 wSUmIN1LtYsz for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 09:34:55 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 74DA83A0F2E for <mls@ietf.org>; Tue, 18 Aug 2020 09:34:53 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id e5so15568424qth.5 for <mls@ietf.org>; Tue, 18 Aug 2020 09:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cWOE9XzEZMCYeqS37aXBMiH/VA3kMr54zVletvoFxLE=; b=ylA4j8QhEVOoeUnOcrj6Sous/jPj7YUHhxod+GKT2NmIlkaM50wRPz7q0L525rUGqn +1twNnlOO3CcvhHf+5c7qtqGs85czyM554HjclPPyW19WDiG7PcO7ee+an+S32h76Qx2 9pjYWcbUqDUVjTVSWP0KpXlSQn2vzdnc9azFw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cWOE9XzEZMCYeqS37aXBMiH/VA3kMr54zVletvoFxLE=; b=A4jE/dynburXLg0FlEH45epWDRnz3EOofRP7ss8NcHxnrjWK+UpVZFlihGOQhDGYMK B6EHMEmrywcrFtrVEWbrf+/+NWbc91oJ8Qw/L7sy50qkWi14/dpt+CZPjESbnGHIaURK 0x7hM9Cg1+LlSyr9M3Nd82PG+cpFfUFuIndgniozjNlCDSXPBKHJ7omZgtwXp7GXZ4Um cQax8CrAiHdlGrG5xIrvhRP4WoiyRExDeSvZ5KjSdHE/BnJ/sxOpvDSTCOVy/Avv6b0I DY//rwQtXAlXV72Jama6MoafUA78EK/oWd2merSHYVSWpt3Vcp0mrzOW2EKfgWeXa57H +DMw==
X-Gm-Message-State: AOAM5302mnQ+zNDidfqpZiVL/OraADhiemrbpt0cLX3Ya6HlPLx7dSOQ N2n9m2j/A1OLqpQg1b1zpg2EoJh0YgBTBTcN1kYpxQ==
X-Google-Smtp-Source: ABdhPJwDC2NbaGWgNcaUkebFMssY5UyHDJnsBoSHDogj9E18jKYbbqnhznKmZNXFX6YyC+nY02nSPXq08nd9v6T0e1Y=
X-Received: by 2002:aed:27d5:: with SMTP id m21mr19264377qtg.4.1597768492263; Tue, 18 Aug 2020 09:34:52 -0700 (PDT)
MIME-Version: 1.0
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com>
In-Reply-To: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com>
From: Brendan McMillion <brendan@cloudflare.com>
Date: Tue, 18 Aug 2020 09:34:41 -0700
Message-ID: <CABP-pSSBcf_BUXPp=uxWMpBviBday8-utGzo=ksPG4Ei=_x3ag@mail.gmail.com>
To: Joel Alwen <jalwen@wickr.com>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006a547d05ad2977ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/gtU1gE1GZr3mW1y6LcmJCxKvRsY>
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule
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: Tue, 18 Aug 2020 16:34:57 -0000

>
> So to that end, how
> about we modify MLS such that MLSPlaintext packets coming from group
> members
> must also be authenticated using something from the application key
> schedule.


My objection to this is that Alice can still be impersonated by members in
the group, if we only have symmetric forward-secure authentication.

There's been some discussion in the past about using forward-secure
signatures that might be worth looking into instead, which would fully
address this attack vector:
https://mailarchive.ietf.org/arch/msg/mls/o3fmIul_4s6STmnqmz514cjADpw/


On Tue, Aug 18, 2020 at 7:36 AM Joel Alwen <jalwen@wickr.com> wrote:

> Hey everyone,
>
> Something thats been bugging Marta Mularczyk and Daniel Jost and me for a
> bit
> now is that handshake messages sent out as MLSPlaintext packets are only
> authenticated using signatures, but not using the group's key schedule. For
> non-members that makes sense but for group members that's weaker than need
> be.
>
> Suppose Alice is in a group using signing key pair (spk, ssk). I corrupt
> her to
> learn ssk. Now I loose access to her device again. Later she generates a
> fresh
> key package with her same spk but a new HPKE key for her leaf. She sends
> out and
> update proposal for her new key package and someone commits to the update.
>
> Expected result: she (and the group at large) has achieved PCS again.
>
> Actual result: using her stolen ssk I can still forge a new proposal's
> (sent as
> MLSPlaintext packets) coming from Alice. Some things I could do with this
> power:
>  - I can generate a new key package kp for Alice using her spk and some
> HPKE key
> she doesn't know. Then I forge an update proposal for Alice with kp. If it
> gets
> committed I've effectively kicked her out of the group.
>  - I could forge Add's and Remove's coming from Alice, so I could trick the
> group into thinking Alice is trying to Add my account to the group or
> remove
> some other group member.
>
> Lemme know if I've missed something here in that scenario...
>
>
> If I didn't miss anything and the attacks really work as advertised then
> IMO
> this is kinda weak sauce and worth avoiding if possible. So to that end,
> how
> about we modify MLS such that MLSPlaintext packets coming from group
> members
> must also be authenticated using something from the application key
> schedule.
> Now the above attacks fail. As soon as Alice's update is gets committed I
> no
> longer know the group's key schedule and so can't forged packet from
> Alice. More
> generally, this brings the PCS guarantees when using MLSPlaintexts
> frameing in
> line with what we're getting from MLSCiphertext packets.
>
> Any thoughts?
>
> - Joël
>
>
>
> PS. For concreteness, we could probably extend the current mechanism for
> getting
> concistancy (the confirmation_tag) to also provide symmetric key
> authentication.
> E.g. include most of the MLSPlaintext content into whats being tagged by
> confirmation_tag. That would cover the case of a commit packet and doesn't
> even
> grow the size of MLSPlaintext packets over the current design.
>
> For a proposal packet we could also have a confirmation_tag but this one is
> computed using the *current* epoch's confirmation_key and
> confirmed_transcript_hash.
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>