Re: [MLS] AEAD data in messages

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Tue, 13 August 2019 14:43 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 9800B12022D for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 07:43:51 -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 7KYpyKmJ7AZ2 for <mls@ietfa.amsl.com>; Tue, 13 Aug 2019 07:43:49 -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 08770120219 for <mls@ietf.org>; Tue, 13 Aug 2019 07:43:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.64,381,1559512800"; d="p7s'?scan'208,217";a="395298143"
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:43:11 +0200
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Message-Id: <53E54F3E-6D9B-4CFF-A13A-F60CB171EE71@inria.fr>
Content-Type: multipart/signed; boundary="Apple-Mail=_891F48E3-28C6-44EA-AA5C-A6A94A0899C7"; 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:43:05 +0200
In-Reply-To: <CAL02cgRYcwRQ==4LbBvgi8q45KaAp=rgNdnP+W2zxLRnvzg9dQ@mail.gmail.com>
Cc: Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org>, ML Messaging Layer Security <mls@ietf.org>, Jeff Burdges <burdges@gnunet.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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/XWyKdTllirJeJuvlYyYibiC-doU>
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:43:51 -0000

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.

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>; 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
> https://www.ietf.org/mailman/listinfo/mls