Re: [MLS] AEAD data in messages

Jon Callas <jon@callas.org> Sat, 17 August 2019 23:58 UTC

Return-Path: <jon@callas.org>
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 325B012007C for <mls@ietfa.amsl.com>; Sat, 17 Aug 2019 16:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=callas.org
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 4wA1_E3Qe2eb for <mls@ietfa.amsl.com>; Sat, 17 Aug 2019 16:58:47 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F3C12006D for <mls@ietf.org>; Sat, 17 Aug 2019 16:58:47 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id i30so5018392pfk.9 for <mls@ietf.org>; Sat, 17 Aug 2019 16:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i/DXl2NCXBTAzdiRHGbXrd4lAsUOG9iVnUsYp2b1qLM=; b=FHUN3cvrXX6WtgQsfsu2SzRTEPG68WNZy2qkxKQhdvmp4Yf91kWfnHWIjd42Y/lHRb KFvE8eBwUz8zsVRe6ui2va4BjBcfMOgXN1VDkxBZVt78BDwv5ZOXlryW+dvSf169VokZ uOG+btsivFWklmtR/sm0uE3QS37zTk6zeryJr4VG+VkVDec0zj+VES4KxmDkYHF/+acD Q/9vu5yTO30sO/Zziw57725W5F7zZ2NHtqoZ19yzT+9xlOF/BJJKWdwfIgxTj4Afg2wC JwRDDi1yRZhgRcbA6glkeZoIbBuCAtfOWkCNSybK1RzLEJhFvtuCS/TIET5A5076tnz/ uuNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i/DXl2NCXBTAzdiRHGbXrd4lAsUOG9iVnUsYp2b1qLM=; b=ua8IQykX+CxGClamdgLTcLyKOq9NU1C1VCfDo3x/PHprZSVcshbMhky+eQLJE2UxDG zf9gy5CmNUfhFtj9G6ixoYBTlnpHdYxrj2nudInE4kXVpl/f+DUNeuLUDyeP89jIZEgB BWq2QbGK4KcQKwVsmZUZ3ne+ASwPvDP+rFYWL3IAlDVM221xG83TVyj3Fo4BxMkWMe9y zjHrBLdqrbgst/z/2mgmk2oRWwmY9jRp7q1S3sWV9/UF1E8h1dO5L+TG4UoCCdOAq3qZ c/LaknqikA6gw0aFJI5OFeg9hlRlqcCEzDQc3i7ZQJ4o5GrNnEDAJq2PpoVp9sZMqmo9 mIlw==
X-Gm-Message-State: APjAAAVvY7MdvDhI6h5b7QebyOG1K6rkU8rmA8sTxYkmPgTdjp06/HmX 0GwbOsOMl/ZBxNVMuy2YhYJrpg==
X-Google-Smtp-Source: APXvYqxBigcAISDoPIqgWtTzfUHnABr9CP8MW6z9wRQHJlnIeAUylGhlhysLQZby4BFr+hM8F8rcgw==
X-Received: by 2002:a17:90a:224e:: with SMTP id c72mr14301786pje.9.1566086326381; Sat, 17 Aug 2019 16:58:46 -0700 (PDT)
Received: from [10.137.59.86] (fa.c7.0bc6.ip4.static.sl-reverse.com. [198.11.199.250]) by smtp.gmail.com with ESMTPSA id k6sm10698248pfi.12.2019.08.17.16.58.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Aug 2019 16:58:45 -0700 (PDT)
From: Jon Callas <jon@callas.org>
Message-Id: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2C9095E9-3172-4410-BC5D-07D1A4D56463"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sat, 17 Aug 2019 16:58:42 -0700
In-Reply-To: <CAJ1bmR=ON=qH5Ho7ew13V0H_5rz90ykFfJB6wLFN72E+=bw+ig@mail.gmail.com>
Cc: Jon Callas <jon@callas.org>, Messaging Layer Security WG <mls@ietf.org>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
To: Peter Slatala <psla+mls@google.com>
References: <CAJ1bmRnw3WmQZstaHi2+gmA1jrQKy_A2vAk6AYVEG3QwGke7MQ@mail.gmail.com> <BC3D8868-1498-4455-8C52-9EC712A03058@callas.org> <CAJ1bmR=ON=qH5Ho7ew13V0H_5rz90ykFfJB6wLFN72E+=bw+ig@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/At1y3JUqHKQHwYL5C-ZchReGg78>
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: Sat, 17 Aug 2019 23:58:49 -0000


> On Aug 15, 2019, at 9:03 AM, Peter Slatala <psla+mls@google.com> 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