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

"Hale, Britta (CIV)" <britta.hale@nps.edu> Wed, 19 August 2020 00:43 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 2ACC53A1070 for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 17:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 lxzsKyCqRTj2 for <mls@ietfa.amsl.com>; Tue, 18 Aug 2020 17:43:13 -0700 (PDT)
Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id A1E133A1067 for <mls@ietf.org>; Tue, 18 Aug 2020 17:43:13 -0700 (PDT)
X-ASG-Debug-ID: 1597797791-0e39454aef1fa50001-bGA3T6
Received: from mail.nps.edu (skywalker.ern.nps.edu [172.20.4.117]) by mule.nps.edu with ESMTP id UysXkMGgiBemBBrD; Tue, 18 Aug 2020 17:43:11 -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; Tue, 18 Aug 2020 17:43:11 -0700
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (104.47.74.46) 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; Tue, 18 Aug 2020 17:43:11 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HVBfmNH7SAGYzqUrdxyz3l+bk5zF1K729pUwaIPiesdGI0uCfwHTho8UeCIBuYrWp5tJSF6KO+p0xuTBt9bjlASKf1oWwf9kXKO0MWf4ln3qPlwgqwTKWsIZ54PimAE7vxGXjohgt3Y4GK/A9dSN+rsX0Ui2/AUEzaXMol6zF1kAjRRYV99lv35BsqpxvM3zlY6cq6zsQoN7QrX6ALTWGrNyACMZWE+WDKlf+8yPcZYFg+ietmffVnMskU23zZgy4T698NYXpdFaN/iuYNVsSDG+nagcmJWBS4l5hJWnO/jo559dZSU4rVIcu45HFpH5Gup/pSOWHhh2XiHHjxJ9aQ==
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=6NWZWX9UfdFNnJoKfLzE+G9ET2bOfaY4XBcNZ+0/wj4=; b=cfF1/eTew1mZ1JNIM+hyBk0JtV6ioUmg1oMZIyS9pCqj5xbQlluDQUw7OukFpdFl1FHIQEuewSfpsKjbx6lFvZxaPuclIj4iRWpDnlXD6ZgXxMGS6EdYIjFgHxLsviCOQMwMoCvOgRYgtH2oaBG3D3HIoPKeua1GwMJb2Z9eOEOLiG7shPD8fxNWmcIGByngGelAEVBn8MsMbBlEMJuiD26TpDNNqX8ni2rnYV58MS//7RdyKlOzSZtgfHs9LfIEDbUbmtQql3g2vjatXSDIX0UMkkzujSOIO3DBYnW1yegArfnPx5B98aRSJ6R4UvTj+RegpcUfpkK5aObuCafjuQ==
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 BY5PR13MB3348.namprd13.prod.outlook.com (2603:10b6:a03:1aa::23) by BY5PR13MB3634.namprd13.prod.outlook.com (2603:10b6:a03:226::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Wed, 19 Aug 2020 00:43:07 +0000
Received: from BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::65b1:6350:343d:c101]) by BY5PR13MB3348.namprd13.prod.outlook.com ([fe80::65b1:6350:343d:c101%7]) with mapi id 15.20.3305.017; Wed, 19 Aug 2020 00:43:07 +0000
X-Barracuda-Effective-Source-IP: UNKNOWN[2603:10b6:a03:226::10]
X-Barracuda-Apparent-Source-IP: 2603:10b6:a03:226::10
From: "Hale, Britta (CIV)" <britta.hale@nps.edu>
To: Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org>, "Richard Barnes" <rlb@ipv.sx>
CC: Messaging Layer Security WG <mls@ietf.org>, Joel Alwen <jalwen@wickr.com>
Thread-Topic: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule
X-ASG-Orig-Subj: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule
Thread-Index: AQHWdWz00GMqSfzrNUeLjUcYEIMnS6k+EBeAgAAukACAAC6tAP//teAA
Date: Wed, 19 Aug 2020 00:43:07 +0000
Message-ID: <D2243F58-192A-41EE-BE51-D69C410AF6C2@nps.edu>
References: <7d7283b6-8c70-d045-81c2-f552219869ad@wickr.com> <CABP-pSSBcf_BUXPp=uxWMpBviBday8-utGzo=ksPG4Ei=_x3ag@mail.gmail.com> <CAL02cgSx7es1KT0VTnZfaw5-J4DNys72=5uU2+qOC5R9G6ijXA@mail.gmail.com> <CABP-pSRM8D0h4Jg7-V03t59s=AHHAhthUx1X1rMY7Di_oSRwgQ@mail.gmail.com>
In-Reply-To: <CABP-pSRM8D0h4Jg7-V03t59s=AHHAhthUx1X1rMY7Di_oSRwgQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.17.200615
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nps.edu;
x-originating-ip: [205.155.65.226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 18b3b593-61a9-41c0-1e09-08d843d8d73d
x-ms-traffictypediagnostic: BY5PR13MB3634:
x-microsoft-antispam-prvs: <BY5PR13MB363424A345BD65C8989BFA3BFB5D0@BY5PR13MB3634.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QlTSeFCnMDYsVqVAieskDardpvYICB2WnUZtx363X+D1ZA34EkWyJlKOH3xVXLN25WfTgBhqOrw0edLNKk9T9bbY7NtDtvoR8/n9T2tmyDeAJzuKAs5C4uvkNgoFlqsuCWTNybmGprIO/DjesZDqyL+4//wIqftLAJtV4fH0e00Y5GeNWOK7M3XRFpr+M3y9H3F8MFAJbWMW1PzNEhVDSgyp7AY/JXcsZ5mNNIdhpR30bDD/IoK8t65ct5ebR/Qg1rMFf9FFibnnqv7YohnqzE+2VpeZZFruk8QKaaNGCGdxSCON1EC6WKbv3JTS3jo2ZCjwjzTgwo4ABJLx6rcfks7E/wyJUyFMFoVJko+7oxqATIwelV8/87J+yOeheSLHalbJQtd+gRTaZP2iwOSAMw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3348.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(366004)(39850400004)(396003)(966005)(83380400001)(36756003)(6506007)(478600001)(75432002)(33656002)(53546011)(2616005)(4326008)(54906003)(786003)(166002)(110136005)(86362001)(66556008)(6486002)(6512007)(66946007)(71200400001)(66446008)(64756008)(66476007)(2906002)(5660300002)(316002)(8936002)(66574015)(76116006)(186003)(26005)(8676002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: xjQzXPcYmgItLV6+yvZqMJ1BuqTQ/hsixjcF9qhoDS+XYSq4gNRj+FyqStcG3inhNmGFyQ47eXTi1k1NkSytq70708Z6lV0wJUEFHP7g/ILl5GlT7zITV8nrbjog5EN5mHN3TdCWmi5143zcn3/WC9v51sSIe+fEABW/YneiRVN/S1mou9FVE5pi2j8qCrOCGa78BmFeuqG4JAzZJ6EQTsbkQOERNZwYi+EVlmFhoJvt9bOoq3WDiZ5DGNwA/vuHzpn18uKIU3iecZKZpwDjNQS3CKTR3TgCL1CLhUE1VBJZaApZavjJe7G9P7fOATajmT3Fl4l0VGCZyjx+QeIMpY8ZxAkLS7rsUNFYErVxduNCX1zAIOSuWcDk4hcNA5fIMGJ/NTVUzn+T7FcVL1RabieehR1Hl0rrwrF0Ra/k00dbz5l1fkWQq8dfZVzERVaWKVq4AkZ9DMPgtCgiBDrh/RrI+bhNEfP/dj5V2Ig2yqvBQcp4snShvlWYg32+/pIN1s1iPV2HupIwOnn9m4Atc591uJZklDSlYa7ywJF1VXEM/qf+3xSSB4Q0h29CP2139qYGKRfac+88nX43mjDFG50j76EvsExiHsFX64/3ZSA9sKOqJiZwaatzT8AaDp7jV1FXx4+FCHIuyS7LgUywRg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_D2243F58192A41EEBE51D69C410AF6C2npsedu_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3348.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 18b3b593-61a9-41c0-1e09-08d843d8d73d
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 00:43:07.4319 (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: Ng3zEJxyRL09QQuIS8W7iZQ0zLQwmLS5x355uHj64ZhRBwb8+IvAiipej8bf8rMfpqGf9N3jdfe/osK4rNSeeQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3634
X-OriginatorOrg: nps.edu
X-Barracuda-Connect: skywalker.ern.nps.edu[172.20.4.117]
X-Barracuda-Start-Time: 1597797791
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: 18170
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=BSF_SC5_SA210e, HTML_MESSAGE
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83996 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SC5_SA210e Custom Rule SA210e
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/oNS5d-5LKUzkbmVwVzcRn1Ro_eo>
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: Wed, 19 Aug 2020 00:43:16 -0000

It is true that this only addresses one aspect and that rotating signature keys is the correct answer, especially with respect to PCS. The currently proposed solution only provides a mitigation to the *current* group. PCS in concurrent groups and those groups that the member has not yet joined is not covered by the proposed solution, while it would be through rotation of signing keys.

That said, if rotation of signature keys is not going to be considered at all for the spec, then mitigating just one of these attacks is better than nothing.


Britta


From: MLS <mls-bounces@ietf.org> on behalf of Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org>
Date: Tuesday, August 18, 2020 at 3:08 PM
To: Richard Barnes <rlb@ipv.sx>
Cc: Messaging Layer Security WG <mls@ietf.org>rg>, Joel Alwen <jalwen@wickr.com>
Subject: Re: [MLS] MLSPlaintext packets aren't authenticated using symmetric key schedule


Brendan: I think you might have the wrong premise in mind here.  The proposal we have been discussing would authenticate *both* that Alice is the sender of the message *and* that she's a member of the group.  So other members of the group could only impersonate Alice if they had compromised her signing key.

Sorry to change arguments, but I think you're right that I missed the point. I actually don't think we should do anything here. That's because: if Alice's long-term signing key is compromised, how can she be impersonated? In all of these ways:

  1.  An outsider can send a message to an existing group.
  2.  An insider can send a message to an existing group.
  3.  An attacker can generate new KeyPackages and intercept Welcome messages intended for her.
  4.  An attacker can forge her existence in a group she's not in.
The PR you opened only addresses attack vector #1. You still have all the other attack vectors and to address them, Alice needs to rotate her long-term signing key.. Rotating the long-term signing key should be the resolution here, not heading off an individual attack.

In the past, we usually considered the long-term signing key to be stored somewhere more secure than everything else, such that it was very unlikely to be compromised, or that it was rotated regularly. That's why we haven't worried about this in the past.

On Tue, Aug 18, 2020 at 12:21 PM Richard Barnes <rlb@ipv.sx> wrote:
Brendan: I think you might have the wrong premise in mind here.  The proposal we have been discussing would authenticate *both* that Alice is the sender of the message *and* that she's a member of the group.  So other members of the group could only impersonate Alice if they had compromised her signing key.


On Tue, Aug 18, 2020 at 12:35 PM Brendan McMillion <brendan=40cloudflare..com@dmarc.ietf.org<mailto:40cloudflare..com@dmarc.ietf.org>> wrote:
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<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