Subject: Re: [MLS] AEAD data in messages

From: Peter Slatala <[email-masked]>
Date: Mon, 16 Sep 2019 13:54:22 -0700

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 <[email-masked]> wrote:

>
>
> On Aug 15, 2019, at 9:03 AM, Peter Slatala <[email-masked]> 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
>
>
>

---

From: Peter Slatala <[email-masked]>
Date: Tue, 24 Sep 2019 13:51:10 -0700

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 <[email-masked]> wrote:

>> 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.
>>
>> When you say header encryption, what exactly do you mean? (I don't
>> believe draft mentions this).
>>
>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 30 Sep 2019 11:10:38 +0200

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=
[email-masked]> wrote:

>>> 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
>>> > Actually the header encryption exists to protect MLS metadata from
>>> the delivery service, so ideally most systems should deploy it.
>>> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>