Re: [MLS] AEAD data in messages

Peter Slatala <> Tue, 24 September 2019 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C233120071 for <>; Tue, 24 Sep 2019 13:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.999
X-Spam-Status: No, score=-16.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8_G9reRcB9SR for <>; Tue, 24 Sep 2019 13:51:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 303B8120020 for <>; Tue, 24 Sep 2019 13:51:37 -0700 (PDT)
Received: by with SMTP id r5so3913396qtd.0 for <>; Tue, 24 Sep 2019 13:51:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EMOsc6KWOpKWABoZcHAipCx2a87piy6sOv5GhfpA4Rc=; b=Z/R+A6u3KbeGgCzoFoLyzKIBPvSLZeXBx1X5z9u4zCabtnRAAh0NBM6816y1SXpcp7 4KmR6J55Hk9KyjYAS+SBU9dUOrmX9YXWVLAvAVqTNlGlWsX/4K/23FZ1BR77UqXBPTsv WxNw37pRbgZ1WI1IMWUuVvbiOdlm7bxK2tzuY8XZgoTGG88X/PwnmgA7cQqJRJMc6mMK yhdgAveYziCTx9ikzzZayYgCmb1viM4aek1SABd8vXUhO6yG9HvNekZNJRDzXlRZW7tO qV5ZGS/mrxXjWGc7zevjOjlcUQ1BoHdvlavFEuGTKMhAl4qH8n+gRwgmRI0bX12MOrG/ QY/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EMOsc6KWOpKWABoZcHAipCx2a87piy6sOv5GhfpA4Rc=; b=h/aozyqiR7gvIIGo2cxVn568snWE83od2RGSwT8DXhJ3nUgf3cifVmwo5qPL7DzV0A 0wm0b4pJoRKBlNUwCpnNHeFXIEmtYYuLpuvazvN5CgkA6+pWsqfEiD8tTOiGOSwJxwAI SfOEogqucFMSlK0YhmpMybu0sVk/8/1lL2FGsYPMj6s/FZ9J1pH4dxZIXbLjgIQ1VWZ7 rrxv2rTE1huXrJk+aZT9d8ekpcRrskkHNDj4tFkTNKEecKfi/ImsP95YfaeA8CKdIr5T WuJ8B/xHgWut2qUXFfj8z9hz/XUDHm1JrTZOv9xNFP9wtQNTyPtJlTnM5BbVImrijbd6 gn/Q==
X-Gm-Message-State: APjAAAUM02GS2FN4p+2bEI+KVlved1kSYXrYJ0CIkzNIMjv50gOE9LER plpViNFMw/b2n6S5e5+2KehANm8ADYlYybScMN8Xlw==
X-Google-Smtp-Source: APXvYqyMfZzvZeC78jddT8abBkmYHD74m82Ew2GnAEGSO/2m8Xz/MTu7mpakPCP4zXZTUVq7R6KSVQq264+n3U4yAlw=
X-Received: by 2002:aed:2902:: with SMTP id s2mr4965465qtd.205.1569358295956; Tue, 24 Sep 2019 13:51:35 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Peter Slatala <>
Date: Tue, 24 Sep 2019 13:51:10 -0700
Message-ID: <>
To: Jon Callas <>
Cc: Messaging Layer Security WG <>, Benjamin Beurdouche <>
Content-Type: multipart/alternative; boundary="000000000000c1e163059352b30f"
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, 24 Sep 2019 20:51:40 -0000

I haven't heard back from anyone. Please let me know if there is interest,
and if so, what's the best way to continue this discussion.


On Mon, Sep 16, 2019 at 1:54 PM Peter Slatala <> wrote:

> Thanks Benjamin, Jon & Jeff for the discussion so far.
> I have wrote made a tiny proposal (
> ) to add AAD. It doesn't
> look like the spec is the place to discuss possible applications or
> tradeoffs, so we can do it in a pull request :)
> Let me know what's the best way to proceed here (discussion in the pull
> request? interim? continuing in the email thread?)
> Looking forward to your comments and suggestions,
> Peter
> On Sat, Aug 17, 2019 at 4:58 PM Jon Callas <> wrote:
>> On Aug 15, 2019, at 9:03 AM, Peter Slatala <> wrote:
>> Thanks Jon! This is a lot of good feedback. As you mentioned, a lot of
>> this AAD can be addressed by a separate edge-to-service key; what we
>> optimize for here is message overhead. Overhead is less of a concern for
>> messaging (unlike for real-time media), so it may be fine to have TLS +
>> edge-to-service + encrypted message itself. The quirk is that some of the
>> metadata would then have to be repeated in both delivery service encrypted
>> message & e2ee encrypted message, which is what I wanted to optimize. By
>> putting the info in AAD & using TLS we essentially save overhead (from
>> duplicating data, and from extra encryption overhead to the server).
>> I'll think about it more and see if I can come up with a reasonable
>> proposal, but I am afraid I won't be able to come up with a solution that
>> will address all of your concerns.
>> Come up with the proposal.
>> In general, I'm not opposed to features. Features are good and features
>> are bad. Too few makes a system brittle, too many makes it hard to assess
>> overall security and might introduce problems.
>> Putting in a feature ought to do one of two things: enable something that
>> is reasonable for someone to do, but no one is doing it yet (future
>> expansion) or to head off a potential problem.
>> On its surface, putting in AEAD doesn't sound bad, but we should avoid a
>> situation where when Alice sends a message to Bob, there's something in
>> there that is not directly relevant to that. A server in the middle ideally
>> is just routing cipher text that is interpreted when Bob gets it, or is a
>> message from Alice to the server. You gave lots of examples of things Alice
>> might want to say to the server. I think it's a bad idea to conflate those
>> into a single message. I also think it's a bad idea to have plaintext
>> metadata in a message. A server can be compromised in subtle ways, like
>> exceptional access, and making the protocol access-ready with metadata
>> seems suboptimal.
>> Without an obvious upside to an AEAD message -- meaning something that
>> the AAD does that can't be done another way, my intuition is to leave it
>> out. We have scenarios that are downside, with no obvious upside, so the
>> risk calculus says to leave it out in my thinking.
>> Obviously, with a use case for the AAD, that changes. That means
>> describing something where the AAD permits us to do X that we couldn't do
>> any other way.
>> > Actually the header encryption exists to protect MLS metadata from the
>> delivery service, so ideally most systems should deploy it.
>> When you say header encryption, what exactly do you mean? (I don't
>> believe draft mentions this).
>> I searched through this thread, and I haven't found where I said "header
>> encryption." The first mention is from Jeff Burdges; perhaps he's the best
>> one to define it.
>> Jon