Re: [MLS] AEAD data in messages

[Peter Slatala <[e-mail]>]

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