[MLS] Encryption vs Masking for the sender information

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Thu, 02 May 2019 09:05 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 AF441120026 for <mls@ietfa.amsl.com>; Thu, 2 May 2019 02:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 xvJ2K95sCi6p for <mls@ietfa.amsl.com>; Thu, 2 May 2019 02:05:27 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 B344D12001E for <mls@ietf.org>; Thu, 2 May 2019 02:05:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,421,1549926000"; d="scan'208";a="304622039"
Received: from wifi-pro-82-017.paris.inria.fr ([128.93.82.17]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2019 11:05:23 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
In-Reply-To: <0DB5B36D-5A31-461A-83DF-94693284B071@gmail.com>
Date: Thu, 2 May 2019 11:05:23 +0200
Cc: Richard Barnes <rlb@ipv.sx>, ML Messaging Layer Security <mls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E272B306-A4DB-4762-9CF3-FBBDE94E24D8@inria.fr>
References: <CAFDDyk-+pC5Q4A=TJ4L0hoj+nY0ZKU_aHesKaVTR_AdSAKopYw@mail.gmail.com> <CAL02cgQixLhetC4hj5KeVDuVbAqM+W2he+HHKdD14Tnt5seFfA@mail.gmail.com> <0DB5B36D-5A31-461A-83DF-94693284B071@gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/YKVwt37wg5YxWzQ-ICSQ5C4yarQ>
Subject: [MLS] Encryption vs Masking for the sender information
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, 02 May 2019 09:05:30 -0000

> On May 2, 2019, at 10:02 AM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>; wrote:
> 
> Looking at: https://github.com/mlswg/mls-protocol/pull/155
> 
> I see that there is a change in metadata encryption:
> 
>>      "sample = ciphertext[:Hash.length]
>> 	mask = HMAC(sender_data_secret, sample)[:8]
>> 	encrypted_sender_data = sender_data ^ mask
>> 	~~~~~
>> 	
>> 	This approach is similar to the one used for protection of header
>> 	information in QUIC (see Section 5.4 of {{?I-D.ietf-quic-tls}}).
>> 	Note that the sender data values are authenticated by the AEAD
>> 	and the signature, while the masked_sender_data is not and only
>> 	benefit from passive security because it depends on the ciphertext
> 
> I disagree with this change, because it is too early to put in optimizations,
> especially those that rely on non-standard cryptographic constructions.
> I would prefer that we go back to using plain AEAD for the sender_data,
> and that we add this kind of optimization once we have a proof that it is secure.

Using AEAD was in my original PR (#131), but multiple PRs have been
opened and merged together over the last few weeks leading to this state.
I have operationnal control over #155 right now and it is not merged, so
I would be completely fine with going back to use AEAD for now as it
provides better protection against active adversaries anyway...

B.