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

Richard Barnes <rlb@ipv.sx> Tue, 18 August 2020 15:26 UTC

Return-Path: <rlb@ipv.sx>
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 233EF3A0CF3 for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 08:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 phV0NKEHg_Tz for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 08:26:40 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 5D59D3A0CF1 for <mls@ietf.org>; Tue, 18 Aug 2020 08:26:40 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id 2so18560857qkf.10 for <mls@ietf.org>; Tue, 18 Aug 2020 08:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h7Lto+a3CHlxihkraWWYezJFZPe3GrDK0iwbwyyIsOQ=; b=HljuG/h4oHViXCNMRHW+n92oKo7tyJhjhxLKBPOwa/Hiv6Zwz5+iSwPuwNxvsqKnpu RomC/eOb2sbbsQmLUUuSY8rWnqVKcjUZikkgO6N9vqbktD+R8wgT9emLolFWrmQnBZhQ 4gG3mQmz/37uu9dih6pca5FHTgslFHiuqwF42qkWYhhzwfknQmtF93CAluf+CPncNhzn dN31mJ7hrWhxpA7fbMhmGTmlGPLErvEgBH/XIYg8i/NH5DAFiMp7W+m71SDpfeaCIn+R 6SUVDpvErV+SjtOXOebWzRMpSQmSRTtrf4DYWnE0IyoX2toLBM/tpJzyvrkvzrIP+Gx+ 7/GQ==
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=h7Lto+a3CHlxihkraWWYezJFZPe3GrDK0iwbwyyIsOQ=; b=R3TTKEHeMWu4AmpFDAWiNmVQk5YrWsV6c8PZjpiCcTHP81SnXkxoj1ZhbGtwTvHy8M Rl92toG7tpi429rrGSm3NdYuOA9ZvIrbSfwlMCrPWa24S0ige9kUp5tr8MnvIuOAp88V 2/4AsJPmbTKenlgalLEobiEp0YiZykeCcFAMckncvQKBBWvZUfRB6nrS480d5mgFyDFS 0owcUrrmK6FJxDX/63euaEtpJek1hdrIS/rQK0zEoW1GAHZ8d4/956CD4er7twyJgwkW eSAA0eeJg5SjyUru7HCWF4cYmTjaD0Tgqn0zAv8RtnhCNR2P5Wq5Rlrvzf+F5F73hA0t BINA==
X-Gm-Message-State: AOAM531TxLZLO1ObBgopYV70XO6QDLdQ+Mdqa7JAxzp4ky0iU5VioWRx S4ytLck+eROOyOPFSTUoiMAJB7IP6OYwzDirzzvmfw==
X-Google-Smtp-Source: ABdhPJyKQWXmgGYqYZu7WjcuVEHoWLcbzX+Sgzn1imhLqvwx4dh03vZAHnbkRjoyk3KuvjOADp9CA/cjq8QzxP1jpWM=
X-Received: by 2002:a37:8287:: with SMTP id e129mr15712084qkd.132.1597764399138; Tue, 18 Aug 2020 08:26:39 -0700 (PDT)
MIME-Version: 1.0
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com> <F5B1E029-D8B4-4BEA-BF7A-CDD531D662BD@wire.com>
In-Reply-To: <F5B1E029-D8B4-4BEA-BF7A-CDD531D662BD@wire.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 18 Aug 2020 11:26:18 -0400
Message-ID: <CAL02cgRTtZp+gHKA0hXxxEn_L6SWRRTJa-U+bhQUhpvM8qZ+Cg@mail.gmail.com>
To: Raphael Robert <raphael=40wire.com@dmarc.ietf.org>
Cc: Joel Alwen <jalwen@wickr.com>, Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007223f005ad288354"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/MO7syaR7pS_z-dcXTNoiN73WiQ8>
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 15:26:43 -0000

Thanks for pointing this out, Joël.  I agree that the attacks you're
describing should work as things are currently specified.  And they're
salient, especially the "replace Alice in the group" one.

Also agree with Raphael is correct that Commit is not affected by this,
since someone who is not a member won't be able to generate the right
confirmation value.  However, I don't think this is actually the right
design to adopt for a general solution to this problem.  Confirmation
verifies group membership *after* processing the handshake message; the
point here is that we should also have a membership check *before*
processing handshake messages.  In particular, I would propose that we do
need something additional on Commit messages as well as Proposals.

Thinking about solutions here, a couple of options come to mind:

1. Use MLSCiphertext, but with an integrity-only encapsulation
2. Incorporate in the signature something that is only known to the group
(e.g., confirmation_key or MAC(confirmation_key; confirmed_transcript_hash
|| Proposal/Commit))

Option (1) has the appeal that you would only ever send MLSCiphertext,
though switching between encrypted/not could be problematic.  Option (2)
seems a lot more appealing: It doesn't add any overhead, since the
group-secret value doesn't need to be sent.  And we already switch between
the signature context that is added for group members vs. external.  In
fact, I think option (2) would just amount to a one-line change to include
an extra, secret value in the context at the top of the MLSPlaintextTBS
struct.
https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption

The only thing that seems odd about (2) is overloading signature
verification in that way, i.e., using the ability to generate a signature
over a secret thing to prove you know the secret thing.  That doesn't seem
obviously flawed to me, but worth thinking about.

Does that make sense to folks?

--Richard


On Tue, Aug 18, 2020 at 10:55 AM Raphael Robert <raphael=
40wire.com@dmarc.ietf.org> wrote:

> Hi Joel,
>
> For context: this would only apply when applications use cleartext
> MLSPlaintext for HS messages. The recommendation is still to encrypt them
> and send them around as MLSCiphertext.
> That being said, we said we would like to support scenarios where HS
> messages are not necessarily encrypted.
>
> Question: would this attack work with Commit messages? I’m thinking that
> they would be rejected because the attacker cannot compute the
> confirmation_tag.
>
> As you mention in the PS, the easy target would be Proposal messages.
>
> I’d be interested to see what exactly you would propose as a mitigation
> mechanism.
>
> Raphael
>
> > On 18 Aug 2020, at 16:36, 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
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>