Re: [MLS] AEAD data in messages

Jeff Burdges <> Tue, 13 August 2019 06:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22F8712008B for <>; Mon, 12 Aug 2019 23:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.534
X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OKv4CWE6Ok65 for <>; Mon, 12 Aug 2019 23:24:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A331B12008A for <>; Mon, 12 Aug 2019 23:24:46 -0700 (PDT)
Received: from [] ( [IPv6:2001:4ca0:2001:42:225:90ff:fe6b:d60]) by (Postfix) with ESMTP id 574241C00D2; Tue, 13 Aug 2019 08:26:06 +0200 (CEST)
From: Jeff Burdges <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_68403F65-6EA3-4A07-9682-33EB1776E429"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 13 Aug 2019 08:24:37 +0200
In-Reply-To: <>
To: Peter Slatala <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [MLS] AEAD data in messages
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Aug 2019 06:24:49 -0000

> On 13 Aug 2019, at 01:15, Peter Slatala <> 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?

> 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.