Re: [MLS] Masking sender data

Richard Barnes <rlb@ipv.sx> Mon, 20 July 2020 20:02 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626A3A0E7B for <mls@ietfa.amsl.com>; Mon, 20 Jul 2020 13:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxaSR3jtWEIw for <mls@ietfa.amsl.com>; Mon, 20 Jul 2020 13:02:45 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 878AF3A0E75 for <mls@ietf.org>; Mon, 20 Jul 2020 13:02:45 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id u64so3618723qka.12 for <mls@ietf.org>; Mon, 20 Jul 2020 13:02:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xUSk9zl9lOEb4bDS+hLU8bMfgKQlUTekGyVl0MR9sZ8=; b=IOKcPqTCTUwe/7seuj76luL7zN8dDUquKTXCaqBD6hChZDTTbmhd6Ij/oEChDjbIM3 elEEwVZtSydLof8TQ5hsPI8tlXLaMkbx2OnVoMQTamTBK9Hy2p//b0Dvxi/KmvpNdMK6 LHx/seIJh7mfYd8y6P+f8N51P01s/NQ+wbYX+bRiT+5cFCr38io4gFhJ8pP28uezF5mJ OOhZiw5qIAJXtNhBxA6RNsBydxT8c4KsA+pyNl+SYe13VfG2/1O21Loe4BxJclWbjrId 49ah8U/PIbCwISk8btHvbiQq5jV/i+0DiEaFDuh7agBCqvjbiOx7PG5+F2GmNwiFh+V7 VYJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xUSk9zl9lOEb4bDS+hLU8bMfgKQlUTekGyVl0MR9sZ8=; b=nDNwVdeZqKJEzu0ml8pd08bPu048V53hC0v82qQmiD12mv5J5eyZ4s38f2bzdj5HBL CFYUHL86jxwKglfi2W106xA18BYUVxmeUfxKB/dCj2HTRXUApwbvPZ5BoUK3ww9fmhAS xX1m29NXC9DNVeH12tilP+8d37BWNyE4qnOVGBIAwOWfnzGG3WifVi9ZSd3XaiHoYFCM drh5wAn+1y7iE9//3w12iqbfmyss0EpNx4WjuTFaFkgPmN+r6d64T4VtGgBuZ2dTWrJi D5A1RVGJN5WvwflSRjrEQnKAjCw1l/D32+xzrbdAW4JHRWMhKg+gtaDM6L9kclqqJSJJ NszA==
X-Gm-Message-State: AOAM5326ksm0mrSwZQvMMxygq55/4ssTO7cOYO5QJNNvdR8a0x56ZhXq Bg1+Ut1CTrZLvXpxs6GCU6xDwAQis3zBJGh4dsRKdg==
X-Google-Smtp-Source: ABdhPJw9Gopcgv39r6hS2ctweG3HzZuBL6m1V1hGyUVJ4012za8mwJ4SkOfKOd/Q7tzZOsy1rtrZlMgSz6+9I1oGqHU=
X-Received: by 2002:a05:620a:1478:: with SMTP id j24mr6620760qkl.347.1595275364083; Mon, 20 Jul 2020 13:02:44 -0700 (PDT)
MIME-Version: 1.0
References: <CABP-pSRhWrhTYEp0CXpoGVYyJ-wH0vddykZkA4a5fBKTUmw18Q@mail.gmail.com>
In-Reply-To: <CABP-pSRhWrhTYEp0CXpoGVYyJ-wH0vddykZkA4a5fBKTUmw18Q@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 20 Jul 2020 16:02:18 -0400
Message-ID: <CAL02cgSUuphYZSY74KbNWJ_nT+Z+Gt80Zm_+6gYYhYC76vA4YA@mail.gmail.com>
To: Brendan McMillion <brendan=40cloudflare.com@dmarc.ietf.org>
Cc: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000654db705aae4fd06"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/3qQ8YRj3hZrOaWYFPh2T3xcIZGY>
Subject: Re: [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: Mon, 20 Jul 2020 20:02:48 -0000

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=
40cloudflare.com@dmarc.ietf.org> 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
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>