Re: [MLS] Masking sender data

Brendan McMillion <> Tue, 28 July 2020 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B13F3A0AE5 for <>; Tue, 28 Jul 2020 11:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5oXsz2wH_GTx for <>; Tue, 28 Jul 2020 11:24:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 096B93A0B0A for <>; Tue, 28 Jul 2020 11:24:12 -0700 (PDT)
Received: by with SMTP id g26so19657655qka.3 for <>; Tue, 28 Jul 2020 11:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZI7OclXDrq/9a71xihMCKDhSnMSQSY+FlTMkTruwUBA=; b=vd5f66uBfcqOLPr3fBWXEVDXXKk7hSUrfQZgxueXBDMP93BXQiqsQGTEu7ZdZbTW2f ngOuO449xAq0xqo60DOA2CTfeNa30NAjdYTjAt4CB7kXDEoJOax72g6gnsQA8U3mCLUC clXIywDvpes3YdGQGEUJatxS14Fw7S25+4bck=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZI7OclXDrq/9a71xihMCKDhSnMSQSY+FlTMkTruwUBA=; b=GxqpDwp+BcXt638hDR/iBgXok3JnsYc4Te1V0napb9gnGJkgKKo1/HbW3zYJUvyPMy 9ODlxqgDZK6b1Z150r0igt1LKGhyEpqjxaDU8QISyzOnlhuYNrklTfQwT453uzguRpvl bYqFWoSLzDtQMC/8ZMtfVCm4+yME/eaPm63EQaPI4yLi44vCBrvbguZ+Vpkzd4opJdRm QraYu0R0dmF5ZlfYQRkoXgDdiY9LogmG3FDZLTcYH8NV9WsscTH5YsCV+HDlyNkh5Q3D 8pxVn1L7ducuUzkRWJnFLrd9gBKsiTNSFWzgNk1PMYsh/sDXWr4JiDx8j0zet2NfJEvB 23UQ==
X-Gm-Message-State: AOAM531XB0cqP9CArHrV9/EP+cuFL5fh+sEzvqMgktw+mpeLtT1yO+tv /97W44vz5ZqYBBmX8nE03046WSErPqvgB9YESdWP8/l4DfY=
X-Google-Smtp-Source: ABdhPJwdw3l8ScawE0d7FpuwHSqtO2memEnosNe1cSGHeD26uCyerHRFWSGBKaALDqH64dfWsj/4oihtSJKcpMhZ/RY=
X-Received: by 2002:a05:620a:cd6:: with SMTP id b22mr28189684qkj.443.1595960651863; Tue, 28 Jul 2020 11:24:11 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brendan McMillion <>
Date: Tue, 28 Jul 2020 11:24:00 -0700
Message-ID: <>
To: Richard Barnes <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000bb085505ab848bae"
Archived-At: <>
Subject: Re: [MLS] Masking sender data
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jul 2020 18:24:15 -0000

This PR was discussed at IETF 108 this morning, and the one issue that came
up is whether or not we should really truncate the auth tag from the

Personally I see no problem with it, as everything in MLSCiphertext is
still authenticated. And with the auth tag truncated, performance-sensitive
applications can optimize away the "second pass" on the ciphertext by using
AES-CTR (or the corresponding unauthenticated cipher mode for their AEAD).
Implementations that don't mind the second pass also have good options, for
example: the same operation used to encrypt (AEAD encrypt and truncate auth
tag), when applied to the ciphertext, returns the plaintext. So the same
code does encryption and decryption.

I'm curious to hear how others feel

On Mon, Jul 20, 2020 at 1:02 PM Richard Barnes <> wrote:

> Hi Brendan,
> Thanks a lot for writing this up!  I agree that this addresses the
> authenticity concerns that had been raised on earlier iterations of this
> problem.  I've suggested a few corrections and simplifications in the PR.
> Either way (what you suggested or with my edits), it's clear that there's
> some non-trivial complexity involved here.  Both in terms of getting the
> operations in the right order (content encryption, then sender data
> encryption, and reverse for decryption), and in terms of constructing all
> the different AAD values.  So I wonder how people feel about that taking
> that compexity cost in the interest of removing an explicit nonce.
> Personally, I'm probably still inclined to do it, since explicit nonces
> make me nervous, but I would like to hear what other folks think.
> --Richard
> On Thu, Jul 16, 2020 at 12:31 PM Brendan McMillion <brendan=
>> wrote:
>> 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
>> list.
>> 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.
>> 2.
>> 3.
>> _______________________________________________
>> MLS mailing list