Subject: [MLS] Masking sender data

From: Brendan McMillion <[email-masked]>
Date: Thu, 16 Jul 2020 09:30:45 -0700

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Jul 2020 16:02:18 -0400

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.

https://github.com/mlswg/mls-protocol/pull/360#discussion_r457656760

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=
[email-masked]> wrote:

> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Brendan McMillion <[email-masked]>
Date: Tue, 28 Jul 2020 11:24:00 -0700

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 <[email-masked]> wrote:

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2020 14:46:46 -0400

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

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

--Richard

On Tue, Jul 28, 2020 at 2:24 PM Brendan McMillion <[email-masked]>
wrote:

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