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

Joel Alwen <jalwen@wickr.com> Thu, 20 August 2020 15:02 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 D79503A0A97 for <mls@ietfa.amsl.com>; Thu, 20 Aug 2020 08:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.848
X-Spam-Level:
X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 nJGld0ZCbdQx for <mls@ietfa.amsl.com>; Thu, 20 Aug 2020 08:02:00 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 69C383A0A9D for <mls@ietf.org>; Thu, 20 Aug 2020 08:02:00 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id t10so2877165ejs.8 for <mls@ietf.org>; Thu, 20 Aug 2020 08:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wickr-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mFodT7JPFT+C51brw7Zl729KBG48mOgTMjYbLU9SF5E=; b=sOOIig+v/5RaYn3dERoy8z2TihGJsfw/HIL9hMBz7Cek8PQdsNYvdqfY2wVfUUiUY1 rfE1BQUcHWK5wnQVn8YTQ1SDCxn2ch6SlPdii7DcQfzyZNUulnyRGjvU/klFIN9l/F3d 9DCnFogsAKwzNRs9K4ODhpyW+3jPcHPpN0p+LEg6qPnKJ/oYC0IXLgvgnavheMbFbpr5 PDr9jMou8viw3ise1S1KhXCxF5o6PC9aNMeXchniYHH2eJXyUSjOFRF3ZFGEvVucAV/q xL7ndMqbik5fpib8UM7JH3/w/BqCxO/7c7fG1DAvOGHVW5+ENRWJNJ2HtR2Yvfkye57M A0Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=mFodT7JPFT+C51brw7Zl729KBG48mOgTMjYbLU9SF5E=; b=kyu3yZ221+Fih86nTnUOJhh8gn639PHpTsu91SAApfPDYa2G+/QDAdqnKrkbCUnT9s Elgro3mSMTmipfPZd3Uy4I9zaXfNVZdclek+6CeCTI93Fg+CykH/5TWQ9JUcF5HxbroV 8hV6xrGjFZV5wou/TTtxSabvJSE9SsM3wKK2gAMNYGa14CJJfzgMprqeITRV3wLbyFqR tz3cyH5rG6KUyK7rrGzAMJSB8EweXW/tv6CKN9Qv41SZ18iuJJm7DiorgYWhRcYT9Rad AQEk/FxR5ZLGSoW04v1RJlXsg5nwroFDB0+l+UEySG4VHE2C02Wc14BBHS5bhwZxoiRL AqvQ==
X-Gm-Message-State: AOAM532bI7A5Yk/NIkzae7wDBt76dBQKZ3OIr8KfkJf41SGALQBfT0qN jNZRNYXCfgxsqIJidPppaTbgaP7lCIaHDw==
X-Google-Smtp-Source: ABdhPJxhA/rQLHNc5jCbCg4bFB/0nCKFqbNTy9uLN/Y57TaVZZ95/2X0NC2LDLQxfbVK//ZuDQ9QKw==
X-Received: by 2002:a17:906:5902:: with SMTP id h2mr3839127ejq.423.1597935718243; Thu, 20 Aug 2020 08:01:58 -0700 (PDT)
Received: from [192.168.1.137] (84-114-27-5.cable.dynamic.surfer.at. [84.114.27.5]) by smtp.gmail.com with ESMTPSA id sd17sm1601749ejb.93.2020.08.20.08.01.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Aug 2020 08:01:57 -0700 (PDT)
To: Cornelissen Eric <eric.cornelissen@aalto.fi>, Richard Barnes <rlb@ipv.sx>, Raphael Robert <raphael=40wire.com@dmarc.ietf.org>
Cc: Messaging Layer Security WG <mls@ietf.org>
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com> <F5B1E029-D8B4-4BEA-BF7A-CDD531D662BD@wire.com> <CAL02cgRTtZp+gHKA0hXxxEn_L6SWRRTJa-U+bhQUhpvM8qZ+Cg@mail.gmail.com> <19861857231648008e6c280815c86546@aalto.fi>
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: <cdb2710c-3086-764b-2268-246d52eb537a@wickr.com>
Date: Thu, 20 Aug 2020 17:01:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <19861857231648008e6c280815c86546@aalto.fi>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/Nomkf-ds7fvZGFG_i7zKb2cK60c>
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: Thu, 20 Aug 2020 15:02:04 -0000

Hey Eric,

What I think ur saying here is that an update proposal (MLSPLaintext) packets
should be signed using the sig key contained in that packet's key package. Am I
getting that right?

This makes no difference for the forging of Add and Remove proposals so those
attacks should still work as before. It might prevent forging updates but only
if both:

A) all updates proposals MUST update to new credentials and
B) when leaking Alice's state I only obtained 1 valid credential of hers.

But for that we'd have to mandate A) as thats not currently the case. I think
would be a mistake though, at least in general. Fresh certs may be comparatively
difficult to come by even for honest users. Yet that shouldn't stop them from
updating their HPKE keys frequently. At best, maybe this could be a group
specific policy? E.g. for deployments where fresh certs are very easy to come by
(say, generated locally) so people could be expected to refresh their sig keys
just as often as their HPKE keys.

> Then again, I would be very much in favor of including something group-binding
> in handshake messages as it would prevent some replay attacks (*) that I have
> been considering for a while.

Yup, this seems more like a complimentary solution.

I'm curious about those replay attacks though! :-) If you're ready to tell us
more I'm all ears...

- Joël

On 19/08/2020 10:17, Cornelissen Eric wrote:
> I was wondering what the implications are of using the key advertised in an
> update Proposal's KeyPackage for signing, instead of the long-term key pair,
> just like new_memberexternal proposals
> <https://github.com/mlswg/mls-protocol/blob/c3db39266505e9d202158d642d65918d35870e77/draft-ietf-mls-protocol.md#external-proposals>.
> I'm confident it prevents the original weakness pointed out by Joël, but I'm
> unsure as to whether or not it introduces any new problems.
> 
> 
> Then again, I would be very much in favor of including something group-binding
> in handshake messages as it would prevent some replay attacks (*) that I have
> been considering for a while.
> 
> 
> Regards,
> 
> Eric
> 
> 
> 
> (*): Replays from adversarially controlled groups where the attacker managed to
> have the group id, epoch, and tree structure to match those of a target group.
> 
> 
> 
> --------------------------------------------------------------------------------
> *From:* Richard Barnes <rlb@ipv.sx>
> *Sent:* Tuesday, August 18, 2020 6:26 PM
> *To:* Raphael Robert
> *Cc:* Joel Alwen; Messaging Layer Security WG
> *Subject:* Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric
> key schedule
>  
> 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
> <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>
> 	
> mls-protocol/draft-ietf-mls-protocol.md at master · mlswg/mls-protocol · GitHub
> <https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md#content-signing-and-encryption>
> github.com
> MLS protocol. Contribute to mlswg/mls-protocol development by creating an
> account on GitHub.
> 
> 
> 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 <mailto: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
>     <mailto: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 <mailto:MLS@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/mls
> 
>     _______________________________________________
>     MLS mailing list
>     MLS@ietf.org <mailto:MLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mls
>