Subject: [MLS] AEAD data in messages

From: Peter Slatala <[email-masked]>
Date: Mon, 12 Aug 2019 16:15:01 -0700

Hello!
I was wondering if you considered allowing additional plaintext but
authenticated data in MLS messages.

While I can't think of immediate, compelling use cases right now, 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 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.
* 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.
* authenticating message id (but make it visible to server to avoid
redelivery),
* other use cases that I can't think of right now.

Have you considered supporting AEAD, or is it already supported and I
missed it?

Thanks,
Peter

---

From: Jeff Burdges <[email-masked]>
Date: Tue, 13 Aug 2019 08:24:37 +0200

> On 13 Aug 2019, at 01:15, Peter Slatala <psla=2Bmls=[email-masked]> wrote:
> I was wondering if you considered allowing additional plaintext but authenticated data in MLS messages.

It’d be outside the header encryption, making the AEAD would be the header encryption?

How would the delivery service authenticate it?

> * sending a 'sending device identifier' in case if delivery service can't differentiate different user devices from each other.

I’d hope the delivery service does not care too much to which device it communicates.

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

> * authenticating message id (but make it visible to server to avoid redelivery),

ACKs and message ids should often be done fully encrypted, but yeah making one ACK or message id notify both the delivery service and the end user makes sense in some use cases.

Jeff

---

From: Peter Slatala <[email-masked]>
Date: Tue, 13 Aug 2019 07:19:50 -0700

> How would the delivery service authenticate it?

 Delivery service is often TLS encrypted so client-server connection should
be secure.

> > * sending a 'sending device identifier' in case if delivery service
> can't differentiate different user devices from each other.
>
> ACKs and message ids should often be done fully encrypted, but yeah making
> one ACK or message id notify both the delivery service and the end user
> makes sense in some use cases.
>
> Jeff
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 13 Aug 2019 10:21:49 -0400

I don't think we have a slot for this, but it seems sensible enough.
Basically you'd just be changing the API from
session.encrypt(application_data) to session.encrypt(aad,
application_data).  I'd be happy to review a PR.

--Richard

On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala <psla=2Bmls=
[email-masked]> wrote:

>  Delivery service is often TLS encrypted so client-server connection
> should be secure.
>
>
>> > * 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.
>>
>> ACKs and message ids should often be done fully encrypted, but yeah
>> making one ACK or message id notify both the delivery service and the end
>> user makes sense in some use cases.
>>
>> Jeff
>>
>>
>> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Tue, 13 Aug 2019 16:43:05 +0200

I gave quite a lot of thoughts to this since my last discussion with Peter but I am going back and forth on this.

1. We can provide a very simple API at the MLS layer that gives
weak group membership authentication as you suggest, the danger being applications
sending plaintext instead of ciphertext or confusing authentication guarantees.

2. The alternative, which I find more flexible but also more dangerous, would be
for the application to use the exporter to externally authenticate messages which would
not got through the MLS secure channel at all; the danger being to have people
doing completely broken stuff.

I think I would prefer 1. but I would be curious to know what people think…

Ben

> On Aug 13, 2019, at 4:21 PM, Richard Barnes <[email-masked]> wrote:
> 
> I don't think we have a slot for this, but it seems sensible enough.  Basically you'd just be changing the API from session.encrypt(application_data) to session.encrypt(aad, application_data).  I'd be happy to review a PR.
> 
> --Richard
> 
> On Tue, Aug 13, 2019 at 10:20 AM Peter Slatala <psla=2Bmls=[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Mon, Aug 12, 2019 at 11:24 PM Jeff Burdges <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 13 Aug 2019, at 01:15, Peter Slatala <psla=2Bmls=[email-masked] <mailto:[email-masked]>> wrote:
>  Delivery service is often TLS encrypted so client-server connection should be secure.
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>

---

From: Benjamin Beurdouche <[email-masked]>
Date: Tue, 13 Aug 2019 16:47:32 +0200

> On Aug 13, 2019, at 4:43 PM, Benjamin Beurdouche <[email-masked]> wrote:
> 

Well, actually the inner signature should still be there and cover the prefix of the ciphertext
(including the AAD) so, you would have strong authentication after decrypting and checking the signature…

That makes me go towards 1. even more…
B.

>> On Aug 13, 2019, at 4:21 PM, Richard Barnes <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Peter Slatala <[email-masked]>
Date: Tue, 13 Aug 2019 07:13:24 -0700

---

From: Jon Callas <[email-masked]>
Date: Tue, 13 Aug 2019 15:03:34 -0700

> On Aug 12, 2019, at 4:15 PM, Peter Slatala <psla=2Bmls=[email-masked]> wrote:
> 
> Hello!

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.

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

---

From: Peter Slatala <[email-masked]>
Date: Thu, 15 Aug 2019 09:03:57 -0700

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

>
>
> On Aug 12, 2019, at 4:15 PM, Peter Slatala <
> psla=2Bmls=[email-masked]> wrote:
>
> Hello!
> 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,
>
>
> 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
> 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.
>
>
> * 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
>

---

From: Jon Callas <[email-masked]>
Date: Sat, 17 Aug 2019 16:58:42 -0700

> 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