Re: [MLS] [Metadata encryption]

Pascal Junod <pascalj@snap.com> Thu, 31 October 2019 14:42 UTC

Return-Path: <pjunod@snapchat.com>
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 315451200FF for <mls@ietfa.amsl.com>; Thu, 31 Oct 2019 07:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=snap.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 SNdrGBsKxrDv for <mls@ietfa.amsl.com>; Thu, 31 Oct 2019 07:42:38 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 044B21200B8 for <mls@ietf.org>; Thu, 31 Oct 2019 07:42:38 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id p8so5615182ilp.2 for <mls@ietf.org>; Thu, 31 Oct 2019 07:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snap.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6ubR83+FjiWON+kjODzjw3sLoEsKqfW82LWILa2ervg=; b=T0xdxnAkMnsLaKa/J3UZef0s0bCMuYNnw0wTeKUAZGD+Lo+pCwEjeA4q24Ht9nnbJG 8U5C9pg8KbRBVaAJbB8aNXqfMNhjs2TcEW5WEicURE8F9x5BkYjPnXabVpnzTZmEbgQj fcjoXW8Z9RGv1WVFMIgpD0bDuHBTwjIpzBFBA=
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=6ubR83+FjiWON+kjODzjw3sLoEsKqfW82LWILa2ervg=; b=Nc35gZkRlx57sq5V6gGz4RKtKXs9etyRdGV+bX4uLmj8xcNznq3UFusyVlddRPudy4 CZX7kVKpbM4W+L4+CqOOblvZoYpIkYx5gh4vu4eTWPYuDBDvWz0Vqns9nABUG28gkub8 FhX/dplxUayiIMgn1gWcYvQidx9VlRNEMZ5GilNAgqv/6tmc7nZ2+i67++iMTULon518 o9HSm0R/e6J/cx96TkkNLCV3ffKMKQoMXVG6b9c5MKH4DH1XAC5XetIEHs/y1jiYKp7m 7x+2ps81YL2p02oo2dZrTKGUwPD3mo8kgbc6VWWYjpBpM0w4N8ZnLlEDrNpEPwkwnqWu nZHQ==
X-Gm-Message-State: APjAAAWKVzV4UBtWx52kYGH/TSVA4skW6l+k0RY/juGO73DNwGTGIqdI 7qO5Rtp3LbmzQnuM+kMTrTAwc8xfuJ6+2Vt46uFtCQ==
X-Google-Smtp-Source: APXvYqzkauAYYjwKdmu6lEiG6ijTvfX9XC6IjSUBdFmbD6RdvvposeD9LZhP+RcENXRQVYfOf+76+6YQkrM1H6b+bgc=
X-Received: by 2002:a92:db0c:: with SMTP id b12mr6611919iln.71.1572532950569; Thu, 31 Oct 2019 07:42:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAPOUjt7zw=ULd5+RMK07T-Tif4A6ej7jBRY7M0NA=JhrwENtgw@mail.gmail.com> <24F9C4C5-EC56-4C77-8940-E2BF828F6265@inria.fr>
In-Reply-To: <24F9C4C5-EC56-4C77-8940-E2BF828F6265@inria.fr>
From: Pascal Junod <pascalj@snap.com>
Date: Thu, 31 Oct 2019 15:42:19 +0100
Message-ID: <CAPOUjt7=a6PMVr+37J5s5reOUUzH7WanU8nBMFRxGXhavi8OGA@mail.gmail.com>
To: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Cc: ML Messaging Layer Security <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eac8ba059635db92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/UEKJE0Vl54b9flevPCllevwL2ss>
Subject: Re: [MLS] [Metadata encryption]
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: Thu, 31 Oct 2019 14:42:39 -0000

Hi Benjamin ! Thank you for you answer. Actually, it does not really
answer my initial question, so let me be more specific:

 - starting from the sender_data_key (computed in a deterministic way from
the group secret) and a randomly generated (for obvious nonce-reuse-related
reasons) sender_data_nonce, we would like to encrypt sender metadata using
the AEAD scheme (which is AES128-GCM in both currently supported
ciphersuites).

- An AES-GCM API takes a key, a nonce, data to be encrypted, and additional
data to be authenticated, but not encrypted.

- The data to be encrypted are the ones contained in the MLSSenderData
structure (senderID + generation)

- The additional data to be authenticated are the ones contained in the
MLSCiphertextSenderDataAAD structure (group_id, epoch, content_type and
sender_data_nonce).

Why is the MLSCiphertextSenderDataAAD structure containing the
sender_data_nonce ? That nonce will in any case "influence" the AES-GCM
authentication tag, so there is no need to repeat it as attached data to be
authenticated, isn't it ? What did I miss ?

A+

Pascal

On Thu, Oct 31, 2019 at 12:50 PM Benjamin Beurdouche <
benjamin.beurdouche@inria.fr>; wrote:

> Hi Pascal !
>
>
> I have a question regarding the current draft and related to section 8.1:
> what is the purpose of including the sender_data_nonce into the attached
> data? To cover AEAD schemes relying on a non-randomized MAC, like, e.g., an
> AES-CBC-HMAC construction ? Are there plans to support ciphersuites of this
> type in the future ?
>
>
>
> To decrypt messages, a member must
> 1. Look at the group_id and the epoch number to find the correct secrets
> to decrypt in its local state.
> 2. Determine which sender encrypted the message.
> 3. Compute or retrieve the correct sender-specific decryption key from its
> state.
>
> Since we want to protect the sender data for privacy reason, we have to
> encrypt
> it under a group key. That group key is outputed by the key schedule so is
> fully deterministic
> and independent of the sender that will encrypt. Since everybody could use
> that key,
> we want to avoid them to also use a deterministic nonce, so we use a
> random nonce
> that we have to prepend in the header of the message.
>
> Most, if not all other messages are encrypted under member specific keys
> in MLS,
> so nonce reuse is less of a problem except in the case state loss and we
> have a pending fix for it… : )
>
> Does this make sense ?
> Best,
>
> Benjamin
>