Re: [MLS] AEAD data in messages

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Tue, 13 August 2019 14:47 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 BA73412082C for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 07:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 7rWJlIEWtjoi for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 07:47:40 -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 7E6F7120251 for <mls@ietf.org>; Tue, 13 Aug 2019 07:47:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.64,381,1559512800"; d="p7s'?scan'208,217";a="395298523"
Received: from wifi-pro-83-067.paris.inria.fr ([128.93.83.67]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Aug 2019 16:47:37 +0200
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <CAB3F268-A84A-4827-868B-63FB658922B9@inria.fr>
Content-Type: multipart/signed; boundary="Apple-Mail=_9F22962F-AF41-441D-85AB-9D1CD7EC70F1"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 13 Aug 2019 16:47:32 +0200
In-Reply-To: <53E54F3E-6D9B-4CFF-A13A-F60CB171EE71@inria.fr>
Cc: ML Messaging Layer Security <mls@ietf.org>, Jeff Burdges <burdges@gnunet.org>, Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org>
To: Richard Barnes <rlb@ipv.sx>
References: <CAJ1bmRnw3WmQZstaHi2+gmA1jrQKy_A2vAk6AYVEG3QwGke7MQ@mail.gmail.com> <6A8807D1-D46F-493D-BFDD-C228D31CED2C@gnunet.org> <CAJ1bmRkWNSdUGEoC83tG=BFwqXq-3XXqAR3WHxmGWWJvVL7O+A@mail.gmail.com> <CAL02cgRYcwRQ==4LbBvgi8q45KaAp=rgNdnP+W2zxLRnvzg9dQ@mail.gmail.com> <53E54F3E-6D9B-4CFF-A13A-F60CB171EE71@inria.fr>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/mSJRgxKxwEftot1ileoNY3b0u0I>
Subject: Re: [MLS] AEAD data in messages
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: Tue, 13 Aug 2019 14:47:48 -0000


> On Aug 13, 2019, at 4:43 PM, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:
> 
> I gave quite a lot of thoughts to this since my last discussion with Peter but I am going back and forth on this.
> 
> 1. We can provide a very simple API at the MLS layer that gives
> weak group membership authentication as you suggest, the danger being applications
> sending plaintext instead of ciphertext or confusing authentication guarantees.

Well, actually the inner signature should still be there and cover the prefix of the ciphertext
(including the AAD) so, you would have strong authentication after decrypting and checking the signature…

That makes me go towards 1. even more…
B.

> 2. The alternative, which I find more flexible but also more dangerous, would be
> for the application to use the exporter to externally authenticate messages which would
> not got through the MLS secure channel at all; the danger being to have people
> doing completely broken stuff.
> 
> I think I would prefer 1. but I would be curious to know what people think…
> 
> Ben
> 
> 
> 
>> On Aug 13, 2019, at 4:21 PM, Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>> wrote:
>> 
>> I don't think we have a slot for this, but it seems sensible enough.  Basically you'd just be changing the API from session.encrypt(application_data) to session.encrypt(aad, application_data).  I'd be happy to review a PR.
>> 
>> --Richard
>> 
>> On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote:
>> 
>> 
>> On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges <burdges@gnunet.org <mailto:burdges@gnunet.org>> wrote:
>> 
>> 
>> > On 13 Aug 2019, at 01:15, Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote:
>> > I was wondering if you considered allowing additional plaintext but authenticated data in MLS messages.
>> 
>> It’d be outside the header encryption, making the AEAD would be the header encryption?
>> 
>> How would the delivery service authenticate it?
>>  Delivery service is often TLS encrypted so client-server connection should be secure.
>> 
>> 
>> > Here are some use-cases for MLS that I can think of:
>> > * sending a 'sending device identifier' in case if delivery service can't differentiate different user devices from each other.
>> 
>> I’d hope the delivery service does not care too much to which device it communicates.
>> 
>> > * sending 'message type' that server can act upon. For example, delivery report sent by the recipient to the sender, which also acts as an ACK to the server that the message was persisted.
>> 
>> > * authenticating message id (but make it visible to server to avoid redelivery),
>> 
>> ACKs and message ids should often be done fully encrypted, but yeah making one ACK or message id notify both the delivery service and the end user makes sense in some use cases.
>> 
>> Jeff
>> 
>> 
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org <mailto:MLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org <mailto:MLS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mls
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls