Re: [MLS] Masking sender data

[Richard Barnes <[e-mail]>]

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 <[e-mail]>
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.
>
> 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 <[e-mail]> 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.
>>
>> 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=
>> [e-mail]> 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. 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
>>> _______________________________________________
>>> MLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>>