Re: [MLS] AEAD data in messages

Richard Barnes <rlb@ipv.sx> Mon, 30 September 2019 09:11 UTC

Return-Path: <rlb@ipv.sx>
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 2A52612013C for <mls@ietfa.amsl.com>; Mon, 30 Sep 2019 02:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 keIBDPFbPPKV for <mls@ietfa.amsl.com>; Mon, 30 Sep 2019 02:11:01 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 0AA5B120046 for <mls@ietf.org>; Mon, 30 Sep 2019 02:11:00 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id k20so10479778oih.3 for <mls@ietf.org>; Mon, 30 Sep 2019 02:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zr1Sgv/7dwaYODSIsN3Ga3Nxrmd/MCNrFRIz6BLXaaE=; b=j+dslfu+IZR/WtJhoOfEHczdTsTIOERrt0+dOGAxxbiIt3iJn3pLGcSinDPQe6+Bwh lmxZtqX6ejoZBGnfhw4YF4p4X7rUsSNVaW1Ydblwe0p7GpBKAcQ5OAE42yOeetvKYdHE p1ENDEvYGYjveE6Ajf8xcCiBr9Ij9WWBL5k2RYe8GkMr+zHoAaz+/gH2Tlw20OTd6oi0 E6SDh+Zy2ZNtMMZXjZD5/8EvU9W2KYht40ITsfeGYJZCyCM8xXXBHe9lTYFBVdF9xgd0 PCwfVEYPxJAYyIR16pQjAtuvbwCjMLwCWMtqJHyNEA5/zWvb2lHkkdjVWDN8aqGSbsjJ lCzQ==
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=zr1Sgv/7dwaYODSIsN3Ga3Nxrmd/MCNrFRIz6BLXaaE=; b=fLY80D5CsNndSbQumF2rFxjVaxYX5LnzZNY24gyTOm6xyH8SvnBikQkjJQQDyCbp58 6CFECvUy9pujG7dtCmmTSzUN1uZOo2YTHiVYTRABhF2Wra703ZIfwEOXIk+ktxUGw4u6 lNnJJzbCMee1dGgBNqJ5dfnIWICyeiFVfifpGE+NWBtYh+ucYK55V0FIPzrYUwyZ1Th7 m9p7o2cbtDq1QYmccgWddYI55YYVuJxgj1vZ1A2twoZUnEEGQrUWXD6U77vM6TGPT62S 362SE01tCIY8YffDG7qnmLwlAe3nwWD9ZERKQdW5T/j9Q3gdtpSsCB9v1zKfxCI4Kixx 7iAw==
X-Gm-Message-State: APjAAAXeTPBs9HXtWVZOIDAln256Fc4TfszYIq/Hr5PVaJGmkQgsGDHR DOj6kF874dC5A3g7i/7YlLnV+Dfu42DYC3kdrfu6kQ==
X-Google-Smtp-Source: APXvYqz4iUJ1E5cgY02JFlKoAeD5vAELbjRp0f40ISPv6UZZ5jo/9F7ENKsZ8NIAWPcG5NhqzZtNEXtjjz1ynob7mCw=
X-Received: by 2002:aca:cc0b:: with SMTP id c11mr16676040oig.169.1569834660025; Mon, 30 Sep 2019 02:11:00 -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> <CAJ1bmR=vwmKXFkk=Cb_hPYb64SmN1Eui+Jx820FF8TRYGCJY4w@mail.gmail.com> <CAJ1bmRnPnkRAZBepLsQKNGVy-NmSHxV-gZxxbNAw70CshwNmGw@mail.gmail.com>
In-Reply-To: <CAJ1bmRnPnkRAZBepLsQKNGVy-NmSHxV-gZxxbNAw70CshwNmGw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 30 Sep 2019 11:10:38 +0200
Message-ID: <CAL02cgQG4Puy0ne=m9Lp2XHqm2xtNw_DKijjNMxNRiR_R50oNw@mail.gmail.com>
To: Peter Slatala <psla=2Bmls=40google.com@dmarc.ietf.org>
Cc: Jon Callas <jon@callas.org>, Messaging Layer Security WG <mls@ietf.org>, Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
Content-Type: multipart/alternative; boundary="0000000000004469360593c19d75"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/o3hh-1KHnpgOjtdKmr1qvqP2G7k>
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, 30 Sep 2019 09:11:03 -0000

Hey Peter,

Sorry for the delay.

I took a look at the PR.  It seems like a reasonable starting point.

Going back to the security analysis: It seems like this field serves a
fairly niche case -- it basically makes the client's communication with the
DS accountable to the rest of the group.  To take Jon's slightly paranoid
example, if someone is going to leak the keys through this vector, they
have to tell the rest of the group about it.

On the one hand, that seems to argue for putting the authenticated data
under the *signature* on the message, rather than just as AAD.  That way,
it's attributable to an individual device (you know who's leaking the
keys).  On the other hand, the group can't rely on this mechanism being
used for communications with the DS (the keys can always be leaked out of
band w.r.t. MLS), so the accountability that this mechanism might seem to
provide is trivially circumvented.

Net of all that, ISTM that the best argument for this is the "SRTP case",
where there's some utility to exposing some stuff to the DS, but you still
want it authenticated E2E, in order to grant the DS the least privilege
needed.  That has been the state of the art with SRTP forever, and it has
the risks that Jon notes.  I would also note that there is some incipient
work on carrying RTP over QUIC [1], which would erase even that
authenticated header information.

So I guess where I'm at is, "Eh, if people are excited about it, sure; but
seems low value to me".  I'm not seeing a killer app.

--Richard


[1] https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01



On Tue, Sep 24, 2019 at 10:51 PM Peter Slatala <psla=2Bmls=
40google.com@dmarc.ietf.org> wrote:

> Hello,
> 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.
>
> Peter
>
> On Mon, Sep 16, 2019 at 1:54 PM Peter Slatala <psla+mls@google.com> wrote:
>
>> 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
>>>
>>>
>>> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>