Re: [MLS] [Metadata encryption]

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Thu, 31 October 2019 15:32 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 B3B93120811 for <mls@ietfa.amsl.com>; Thu, 31 Oct 2019 08:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.203
X-Spam-Level: ***
X-Spam-Status: No, score=3.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=10, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no
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 Ete_-exAfuJM for <mls@ietfa.amsl.com>; Thu, 31 Oct 2019 08:32:33 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1DA12081C for <mls@ietf.org>; Thu, 31 Oct 2019 08:32:31 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.68,252,1569276000"; d="png'150?scan'150,208,217,150";a="409819260"
Received: from aannecy-653-1-78-207.w90-41.abo.wanadoo.fr (HELO pc54.home) ([90.41.199.207]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2019 16:32:29 +0100
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <034A69CB-4C6D-4247-A04C-691A514BDD9E@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E0F631DC-BFB8-4FA0-BB94-E419674A60D8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Date: Thu, 31 Oct 2019 16:32:28 +0100
In-Reply-To: <CAPOUjt7=a6PMVr+37J5s5reOUUzH7WanU8nBMFRxGXhavi8OGA@mail.gmail.com>
Cc: ML Messaging Layer Security <mls@ietf.org>
To: Pascal Junod <pascalj@snap.com>
References: <CAPOUjt7zw=ULd5+RMK07T-Tif4A6ej7jBRY7M0NA=JhrwENtgw@mail.gmail.com> <24F9C4C5-EC56-4C77-8940-E2BF828F6265@inria.fr> <CAPOUjt7=a6PMVr+37J5s5reOUUzH7WanU8nBMFRxGXhavi8OGA@mail.gmail.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/DVKyAyQlDAUeE4BG4jEI0yC5bHk>
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 15:32:35 -0000


> On Oct 31, 2019, at 3:42 PM, Pascal Junod <pascalj@snap.com>; wrote:
> 
> 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 ?

Ah, ok sorry I am a bit exhausted…
Since we have to send the fresh nonce for the recipient to decrypt the encrypted sender_data
we place it in the header. If you look at the message format on the wire, we have the practice of
authenticating the entire prefix of what’s encrypted (because we can).


Hopefully the visualization will help here (don’t mind new field it is a thing we introduced in PR208).

The nice thing of doing that is that you don’t have to “construct” the AADs, they already are right there for you.

Does that help ? (Hopefully I understood this time xD... )
Best,

Benjamin