Re: [MLS] AEAD data in messages

[Peter Slatala <[e-mail]>]

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.

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

Peter

On Tue, Aug 13, 2019 at 3:03 PM Jon Callas <[e-mail]> wrote:

>
>
> On Aug 12, 2019, at 4:15 PM, Peter Slatala <
> psla=2Bmls=[e-mail]> wrote:
>
> Hello!
> I was wondering if you considered allowing additional plaintext but
> authenticated data in MLS messages.
>
>
> I have a small raised eyebrow about this. Similar to rlb's comment, it's
> not hard.
>
> My primary concern is that any AAD in the message is ripe for putting in
> things that are side-channel or traffic analysis leaks. I have a secondary
> concern that if one uses this to talk to the delivery service, it's
> unauthenticated from the service's viewpoint, and consequently creates an
> opportunity for an attacker to fuzz the delivery service. Moreover that
> attacker could be a legitimate user of the service.
>
> I note that you said, "Delivery service is often TLS encrypted so
> client-server connection should be secure" in follow-on discussion, but
> that's in my opinion a reason *not* to have this feature. That's either a
> layering violation or you could achieve the same effect by just sending
> an unauthenticated message to the service that is protected by TLS. By
> putting a server message in the AAD of an AEAD message,
>
>
> While I can't think of immediate, compelling use cases right now,
>
>
> That strikes me as a reason *not* to do it, but again, along with rlb, I'm
> willing to look at a proposal. Note that my concerns here suggest things
> you should address in that proposal.
>
> I am wondering if such extensibility wouldn't be desired. For example, in
> encrypted video calls, resolution, framerate, or audio volume can be put in
> plaintext so that the selective forwarding unit can decide which streams to
> forward to the group members (and the recipient also uses this data)..
>
>
> Here's a sample attack. In this, Alice and Bob are communicating over the
> service and Harry the Hacker has compromised the router nearest Alice and
> thus can see or modify all messages. Harry modifies one of Alice's
> messages, changing the volume field to maximum volume. The server acts on
> the changed volume, but Bob drops the message, because the MAC fails. If
> the message gets retransmitted, Harry doesn't change the volume. Alice and
> Bob likely see the volume of the call going to max for no readily
> understandable reason. As you note, using TLS is a quick mitigation.
>
> Another attack uses Gary the Griefer instead of Harry. Gary is an
> authenticated used of the service and is in a session with Alice and Bob.
> Gary does exactly what Harry did above -- send a message that the server
> will act on, setting the volume to max -- but knows that this message will
> dropped by Alice and Bob.
>
> I believe that if someone wants to send a command to the service, then it
> shouldn't be piggybacked inside the normal messages, but that there needs
> to be a separate edge-to-service key and command set.
>
>
> Here are some use-cases for MLS that I can think of:
> * sending a 'sending device identifier' in case if delivery service can't
> differentiate different user devices from each other.
>
>
> This is a traffic-analysis data leak.
>
> * sending 'message type' that server can act upon. For example, delivery
> report sent by the recipient to the sender, which also acts as an ACK to
> the server that the message was persisted.
>
>
> Again, this should be done under the aegis of an edge-to-service key.
>
> * authenticating message id (but make it visible to server to avoid
> redelivery),
>
>
> That's also an information leak.
>
> * other use cases that I can't think of right now.
>
>
> I have one more that's perhaps at least mildly paranoid and perhaps not
> entirely fair.
>
> * sending information needed for "exceptional access" such as the GCHQ
> Ghost User proposal. This could put in trap/trace data, copies of the
> messages encrypted to access keys, etc.
>
> That's not fair because if we presume government-compelled software mods,
> they could mandate a lot of things. However, this provides a mechanism that
> could enable a single gimmicked client to undermine the security of the
> whole system transparently. This would really be true of the plaintext AAD
> was typically ignored by the client. Preventing this is thorny, because it
> would require defining what the syntax of the AAD is, and mandating some
> dramatic failure if unknown AAD is present.
>
> Despite this, I'd love to see a proposal. It could be useful. It could
> also be a major flaw, and this is why I would like to see a real use case
> as well as mitigations against abuse in the proposal.
>
> Jon
>