[MLS] Mandating the expiration of KeyPackages (redux)

Brendan McMillion <brendan@cloudflare.com> Fri, 06 March 2020 20:26 UTC

Return-Path: <brendan@cloudflare.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8CA2B3A09C7 for <mls@ietfa.amsl.com>; Fri, 6 Mar 2020 12:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Status: No, score=-2.089 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, T_KAM_HTML_FONT_INVALID=0.01, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GBurfCPcdZJ1 for <mls@ietfa.amsl.com>; Fri, 6 Mar 2020 12:26:32 -0800 (PST)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 85AC63A09C6 for <mls@ietf.org>; Fri, 6 Mar 2020 12:26:32 -0800 (PST)
Received: by mail-qv1-xf2a.google.com with SMTP id bt20so1210289qvb.11 for <mls@ietf.org>; Fri, 06 Mar 2020 12:26:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=GrybI10zKT7CmQZbm9XKNJ5ePpi9cHK5H5QsKJ5FUHY=; b=bQpKGn/wmURcKyeT5/MSfXxM6i4D7+ONvwL4Lit9ob1S8c2ZuNmD5+6mhS9O30b6hp 7nJRl7fpjKJrdZopSbKfCKEjLasvEdYirXhy0BFStFpG0oPpcE0tKZVdxMr/FI8aReZM crM9Tgf/3MERwU0LQZrLhc0GaEpm4BtMPUSV0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GrybI10zKT7CmQZbm9XKNJ5ePpi9cHK5H5QsKJ5FUHY=; b=iw8i2bpnQY4YKCGLYi2cNtWOYWPZwnkpwJH68LE3Bdow23/l7sjyG06sJ1mvIbcAIT 9elsL3jKfo6vuO0LBnrhfm8cf36CnTweG/CBzwKk/+w2OiXRx4Tu+h5cvIRBCWf2VW/x pMLdC0cNO6yxrn0DXP6MpvREiCmWdDkxhDxBEjcoBpPx+4Zvnly7hDho3QZlu/0MWFMg Rue2aD6BPLPQw7rIAmr4wZrgODr0CBXdfloimoXaaakbyJUatCa/eVqE05fLUmkdcb58 B93sQpc/HfmIBlchlQAW7EnULwJNK6uC+JCXhmJ5+RkDzgkQr+rXP1+MSEP/HGjh+2Rm KgXA==
X-Gm-Message-State: ANhLgQ1WyXtAJ4qezgd721WtztyMmeWH2bVnXOy85ZXMpuXJ5vjHqB7g 2w526xdY3eUGA8+J2iEdKFPWK1d+LtA8mOBWkf1Llq+iyNuing==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvXCiVTbLrCcvmNbcNEvdJjOImOo5mQfRTQVUsk?= =?utf-8?q?qdBbOBupoSDIKNwc3iKW+LlpT8UrWWizI7+KDNlftNGF/iA=3D?=
X-Received: by 2002:a0c:f684:: with SMTP id p4mr4488283qvn.172.1583526390998; Fri, 06 Mar 2020 12:26:30 -0800 (PST)
MIME-Version: 1.0
From: Brendan McMillion <brendan@cloudflare.com>
Date: Fri, 6 Mar 2020 12:26:20 -0800
Message-ID: <CABP-pSRkDeRc5_1nPViXqpa1XkqfA92t72fOWmmOZ9sDPoX3kQ@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000007505f05a03578bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/EOKwp5D0KSS5kp2ZdWI4hDfAbgU>
Subject: [MLS] Mandating the expiration of KeyPackages (redux)
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: Fri, 06 Mar 2020 20:26:40 -0000

Hello mls@

In PR #275 <https://github.com/mlswg/mls-protocol/pull/275/files>, we
started mandating the expiration of KeyPackages. However, the PR also
allows applications to set the expiration of the KeyPackage to the maximum
value for Last Resort keys -- meaning they never expire.

I think this is conflating the problem that Last Resort keys solve with
something else. Last Resort keys are a solution to DoS attacks, where
somebody sends a user a lot of messages in a short period of time, to
exhaust their cache of one-time-only keys and prevent anyone else from
sending messages to the user. Last Resort keys are not a solution to the
problem of the user being offline for an indefinite period of time. Trying
to use Last Resort keys in this way can pose a problem for PCS, because if
a user is compromised then any of these KPs can be used to “add” the user
to the group, when they’re actually adding an adversary.

It’s tempting to say that the PCS issue is solved by rotating the user’s
identity key, as this invalidates all the previous KeyPackages that were
never going to expire. However, this implies that the user’s identity key
needs to be rotated as often as new KeyPackages would ideally be generated,
which could create a substantial burden on the Authentication Service.
Practically, I think it’s unlikely that identity keys will really be
rotated this often, or that reliable revocation will be implemented by many
operators. And finally, the rotation requirement is incompatible with the
multitude of signature schemes that don’t require a new credential to be
issued to achieve PCS.

The improvement I proposed in the PR was to remove this guidance, along
with modifying the Expiration extension to be a (notBefore, notAfter) pair.
Having start and end dates allows everyone to see the total lifetime of a
KeyPackage, and enforce that the total lifetime is below some
application-defined limit.

I’ve opened PR #317 <https://github.com/mlswg/mls-protocol/pull/317> with
my suggested changes. Feedback welcome!