Re: [MLS] AEAD data in messages

Peter Slatala <psla+mls@google.com> Mon, 16 September 2019 20:54 UTC

Return-Path: <psla@google.com>
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 3FB1C1202A0 for <mls@ietfa.amsl.com>; Mon, 16 Sep 2019 13:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17
X-Spam-Level:
X-Spam-Status: No, score=-17 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 bKECZbFuaSbE for <mls@ietfa.amsl.com>; Mon, 16 Sep 2019 13:54:50 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 39D39120845 for <mls@ietf.org>; Mon, 16 Sep 2019 13:54:50 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id n7so1604693qtb.6 for <mls@ietf.org>; Mon, 16 Sep 2019 13:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LNGGZH60P51ntW0NjkZw3tLqR2jbzIlwiO8BXzxpDq8=; b=Qldlx6ATWNj4WyFzanWGGiRV8VeY9dELLCzgBc1oDYwLRQb3jTm4j/G3KdQz9XWftl 1z2ga2gKXOf/wO3/+guetc0w+ZRNN3xv/8GvIjcAGmJD7FGDL1gP0cEptLnu9poWqIff t7m6HjGxBF8r8uyA/r8+bkzG57u1Lb10iHwc1LGwFwZbbYfKn0EVYwFvtjoZkFwJwFKE mXlIGDv4Q89qxc4h6IclkYxU1jY+9uBYCzTrOwY5oKYRxVF72NGf5iiGK9TMUcy08ACz /gjOl1Pjbkwdw+r+DETs4HBD6n37nV0l5wVF4UE4e72QRu7rp5+27WN9hrRp2jXfQa/J kbkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LNGGZH60P51ntW0NjkZw3tLqR2jbzIlwiO8BXzxpDq8=; b=q2llxI+OIawxK3qpXhRg499rpHiZQ2NyAygIb4jaeGBC20IjS+Y8GfE3MOxXgs9Go0 rTC8R0lkJtVH5kEvK3f3qTPWqq0f8ifim1dzJ9KC7AEAOJSZggxc18ZGgJIMBiNzD7ib ovk9FFNPbFlRZ4Dpz/LBCP7stYlrSp90Axl/8GGCiT+om5jBh7e5sJh+0Yi3Lmg8H8UK 2G3ENud3y9Fy+ssoBL8fNIye3ZluSsgWdx94R8lSaA09nEPrZ6cj+Qf9l3exqRVYwJQc zkWmUS9GsxAyiC5xuKss85f8LvIb1MStxp7IbpiJ8iVIm5UgNcHltHVJHqni4P+B3lBK DicA==
X-Gm-Message-State: APjAAAUMvNuDn6X4OM4b4jcxq5zfEwvKfBF8uJMh1Wvm500bGP3jR39D nAV49WfI2FPsGxp/UCt3Jcj+LaGoL426WqhUCtn7MQ==
X-Google-Smtp-Source: APXvYqzwdenwfyRqe7l7QRTIUzrtACYopaHLcSbKICNbvMMY5I753zYVxeQJa40FY7/mqBfe0TTWRYX6OELcR7HqGC0=
X-Received: by 2002:ac8:73cf:: with SMTP id v15mr341861qtp.131.1568667288760; Mon, 16 Sep 2019 13:54:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ1bmRnw3WmQZstaHi2+gmA1jrQKy_A2vAk6AYVEG3QwGke7MQ@mail.gmail.com> <BC3D8868-1498-4455-8C52-9EC712A03058@callas.org> <CAJ1bmR=ON=qH5Ho7ew13V0H_5rz90ykFfJB6wLFN72E+=bw+ig@mail.gmail.com> <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org>
In-Reply-To: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org>
From: Peter Slatala <psla+mls@google.com>
Date: Mon, 16 Sep 2019 13:54:22 -0700
Message-ID: <CAJ1bmR=vwmKXFkk=Cb_hPYb64SmN1Eui+Jx820FF8TRYGCJY4w@mail.gmail.com>
To: Jon Callas <jon@callas.org>
Cc: Messaging Layer Security WG <mls@ietf.org>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Content-Type: multipart/alternative; boundary="00000000000084f3ec0592b1d00c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ahcnXG2_F62LKZFhSIkQo4FQpYw>
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: Mon, 16 Sep 2019 20:55:00 -0000

Thanks Benjamin, Jon & Jeff for the discussion so far.

I have wrote made a tiny proposal (
https://github.com/mlswg/mls-protocol/pull/208 ) 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 <jon@callas.org>; wrote:

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