Re: [MLS] Masking sender data

Richard Barnes <> Tue, 28 July 2020 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF4653A0B0A for <>; Tue, 28 Jul 2020 11:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZS8sF1o3_J-u for <>; Tue, 28 Jul 2020 11:47:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 908873A0AFA for <>; Tue, 28 Jul 2020 11:47:17 -0700 (PDT)
Received: by with SMTP id e5so1637237qth.5 for <>; Tue, 28 Jul 2020 11:47:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zk0Th73kvmVxCYI2zCK41WvkD9HowbIspOjqeZH+zzQ=; b=fd0HyKeTUvQbdyvOcNm5GLUIb4RxQW2dY+00LAKLgPp7QHUEbnN+hXEL+4UqD4IvmQ 4pqYe/zCAo0C9M1hgEmoX9rUxbqc7zaw2qaD+jJJ2L5zp47KRe7gx9PYEQM89j4MSdot VE3Jp3Jih/JHQzFj88wPcQmdOJBk3t0YCDXJwECfFHy5SIIKlYgJ5JMdZFR6t3MQNckn QWytTZ207xPJeqtJF4q5ill4YfAexg3tzcaEPWjVDOxwFPw5JHVSeHUCeu9DUIcZLCcI ZKOst/GYAOUt4i8e4P6dUBHJFEQjnE+kRW/loOk27+/tou031kLa07u7naiQrJuqI/jW iL5Q==
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=zk0Th73kvmVxCYI2zCK41WvkD9HowbIspOjqeZH+zzQ=; b=AVKB0eX8pJxgPcXNMRc+NiPL2zSRgjhnGD/I1tNkPg8g2K9Nfqp/mpnDC25R3x/A06 wF7f9fGekS4m5AnBEgM2wFLoNut67gO19Va5eXQIqBqG6Jk7NSyCdZ+y9EUau+i/BmsZ K1al9bJ5SW5CpsKlu0fapz9IQJMvefLk6wJ+tvi1+3okcUivC1vNDvbNjbROnrXCVCxh zVHZL538V8zPdXUCBNARdv48cIlEhKBQwOivq9bE9PmHiHTM5FE2qP1OAlX3vICMYn+u pMaVL2lInZncnL9szRWAlbpBwbyqI0eBqcH7TA9QSDZV9st9xPHlXuIKy1uVdk956V0e W9ig==
X-Gm-Message-State: AOAM531mIuH378bk4pvOx94JkPYzYqiuCOad/SG5RTbeFAcIJ6pJ/nV4 nKgaEUp8JMvyT3Bj9Ovos/jTEYSlRzfh1OvYoui0Lg==
X-Google-Smtp-Source: ABdhPJzY2kUR8k2mg/rAC3+EOWZ7BfFbjXS5Rx1oh39CzQ1e5hCGrKcgm3ZbRNT+ZG4l5IqnDK3J2oUKFMG+3m62NOo=
X-Received: by 2002:ac8:2a3d:: with SMTP id k58mr27636697qtk.265.1595962036461; Tue, 28 Jul 2020 11:47:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Tue, 28 Jul 2020 14:46:46 -0400
Message-ID: <>
To: Brendan McMillion <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="000000000000423a3205ab84de5a"
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:47:36 -0000

Just to recap the options as I understand them:

a) Today:
   encrypted_sender_data = AEAD(sender_data_key, sender_data_nonce,
(groupID, epoch), sender_data)
   encrypted_content = AEAD(app_key[i][j], app_key[i][j], (groupID, epoch,
encrypted_sender_data), content)

b) Sample sender data nonce from ciphertext (saves explicit nonce)
   encrypted_content = AEAD(app_key[i][j], app_nonce[i][j], (groupID,
epoch), content)
   encrypted_sender_data = AEAD(sender_data_key, sample(encrypted_content),
(groupID, epoch, encrypted_content), sender_data)

c) Drop auth tag from content encryption (saves explicit nonce and content
auth tag)
   encrypted_content = Enc(app_key[i][j], app_nonce[i][j], content)
   encrypted_sender_data = AEAD(sender_data_key, sample(encrypted_content),
(groupID, epoch, encrypted_content), sender_data)

Here (c) is meant to be the option Brendan prefers.

For me, I think (c) is a step too far.  It does result in more savings, but
it complicates the story in some other ways:
- The authenticity of the ciphertext is dependent on the sender_data_key,
not the key from the key schedule.
- I'm wary that the deaggregated Encrypt-then-MAC scheme, especially with
unrelated keys, will complicate analysis even if it ultimately works.
- We now need to define a non-AEAD encryption algorithm in addition to the

By contrast, the only question with (b) is whether using
sample(encrypted_content) as the nonce will cause nonce reuse.  That seems
easier to reason about, since it should be effectively the same as using a
random nonce.

So I would propose that we go with (b).


On Tue, Jul 28, 2020 at 2:24 PM Brendan McMillion <>

> 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
> ciphertext.
> 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