[MLS] Masking sender data

Brendan McMillion <brendan@cloudflare.com> Thu, 16 July 2020 16:30 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 7E9783A0BDE for <mls@ietfa.amsl.com>; Thu, 16 Jul 2020 09:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cPYeD2ADZ0D8 for <mls@ietfa.amsl.com>; Thu, 16 Jul 2020 09:30:58 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 DDF5E3A0BD9 for <mls@ietf.org>; Thu, 16 Jul 2020 09:30:57 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id w34so5376008qte.1 for <mls@ietf.org>; Thu, 16 Jul 2020 09:30:57 -0700 (PDT)
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=srHpAmjPIJ7wRfuBBmFohNfQCyI2iYgPwAAsuqZB2i4=; b=NNmnJX1r0SnBceidoSLxt8pv4ZQ+L3UcsIN+2FKSTrxaZ+cYJuUVyfX6NUuvPhYNz/ WgEDPGbN2qPcufN6YEltq0FlUAEPGP0m20B8Uv9RWv6iMRW5p6RM8COkr5cGeXsiq0Rs rBBTu5War8RV/pYMwEJDMpkmUJg+wFcOROEWQ=
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=srHpAmjPIJ7wRfuBBmFohNfQCyI2iYgPwAAsuqZB2i4=; b=piQzW7QpoN4bhp6WoIDtUFei2Yjt5iQKCZguiBmQAIbu1gLgBqMxy3kGmsW2rRfsG6 WwYVUvXdSK3MsoV04xuA0e6BLmIDpxRCRSjGlqTAk46hBMvQA5w7cYeZ+4liMR2ebmAg /HdahI7LvqiznCS3XZfPOIsnIYr/Rb9nTJAQ8aWw7MUvfv2XuG1VBMcKGDwq6cGToWsO /hOAwWaYeH8x8UzMj0MAKZ1QR0LzIq0HzGss49bD9l+JvQnDTqUey5Ol86j3xBXoAkC8 UZ1lwIVXN5FvpGWpotY8A9xohRXe0AU9WfR03CUbrhgPRox4DF1n3dVp+pEkY59+Dv8N /Qog==
X-Gm-Message-State: AOAM5331MOJvGqeXeazarZNTDCeTPuxlNQ6Gz1QtYCpgntSuo12vKdy/ wdlUzptATg+nJ2RCQQb+afFHvJVqYYQtuz5MA1l98Adrk7y54w==
X-Google-Smtp-Source: ABdhPJweuKj/1OdCgSMGDCwXbZIdTqtO+7v6onkT5AKX4zzSJCNkyXrhHgyz3PZRJD7gqt1iFA4hDrIA75/g23f+k8Y=
X-Received: by 2002:ac8:444c:: with SMTP id m12mr6158503qtn.281.1594917056168; Thu, 16 Jul 2020 09:30:56 -0700 (PDT)
MIME-Version: 1.0
From: Brendan McMillion <brendan@cloudflare.com>
Date: Thu, 16 Jul 2020 09:30:45 -0700
Message-ID: <CABP-pSRhWrhTYEp0CXpoGVYyJ-wH0vddykZkA4a5fBKTUmw18Q@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000947df405aa9190ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/0it8ioRDOzMstYdDXsExFxNzeP4>
Subject: [MLS] Masking sender data
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, 16 Jul 2020 16:31:00 -0000

Hello mls@

There's been an open ticket [1] on MLS for a while now to explore masking
sender data instead of encrypting it with an AEAD. I opened a PR [2] with
an initial attempt to achieve this, which I wanted to now introduce to the

The first major change is to encrypt the first block of `ciphertext` under
a derived key with AES-ECB, and XOR the encoded SenderData with that value.
The masked sender data replaces the `encrypted_sender_data` and obsoletes
`sender_data_nonce`. The PR also specifies that the auth tag should be
truncated from the `ciphertext` because the full MLSCiphertext is now
authenticated with a MAC under a shared key, and this MAC is stored on its
own in an `auth_tag` field on MLSCiphertext.

The process of masking the sender data is designed to match the
construction HN1 in [3]. The reason for messing around with the MAC
structure, is that it allows us to validate the integrity of the sender
data before we use it to generate sender-specific keys, while still only
have one MAC total.

One of the downsides to this proposal is that it requires two passes over
the ciphertext, since we'd now encrypt and authenticate in separate passes.
While I'd like to get rid of this, I don't think it will be a big
performance issue for implementations.

Feedback welcomed!

1. https://github.com/mlswg/mls-protocol/issues/302
2. https://github.com/mlswg/mls-protocol/pull/360
3. https://eprint.iacr.org/2019/624.pdf