Subject: [MLS] Hiding content type

From: Richard Barnes <[email-masked]>
Date: Mon, 13 Jul 2020 09:55:55 -0400

Hi all,

Recall that PR#349 does two things (1) use an opaque epoch ID, and (2)
encrypt the content type of the message (application / proposal / commit)
[1].

There was some discussion on the call last week that encrypting the content
type might not be that useful, since an application that relies on a server
to assure ordering of commits will need to at least be able to tell commits
from other things.  Of course, even if the content type is encrypted by
default, the application can add it back in authenticated data, or in some
unauthenticated wrapper.

Net of those considerations, I'm personally still inclined to merge the PR,
to have a conservative baseline.  But those on the call thought it would be
useful to pose this to the group, so please speak up if you have concerns.

--Richard

[1] https://github.com/mlswg/mls-protocol/pull/349

---

From: Brendan McMillion <[email-masked]>
Date: Mon, 13 Jul 2020 09:57:28 -0500

With respect to using an opaque epoch id, I believe this was proposed in
#245 <https://github.com/mlswg/mls-protocol/pull/245> and consensus was
against it because it makes it more difficult to implement the DS. It's
also not clear to me what security properties you want from an opaque epoch
id, because the current PR doesn't provide collision resistance and I'd
expect this to be a source of confusion and bugs.

With respect to encrypting the content type, it also seems to me that this
would cause issues because different content types have different delivery
guarantees. Specifically: messages are allowed to be unordered and lossy,
proposals are allowed to be unordered but not lossy, and commits are both
ordered and not lossy. In the deployment scenarios we've talked about, the
DS essentially always needs to know the content type to provide this.
Conversely, you don't get much additional privacy from encrypting the
content type because an eavesdropper can see the epoch id change and infer
which message was a commit, or see a dropped message getting re-sent and
infer it was a proposal.

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <[email-masked]> wrote:

> There was some discussion on the call last week that encrypting the
> content type might not be that useful, since an application that relies on
> a server to assure ordering of commits will need to at least be able to
> tell commits from other things.  Of course, even if the content type is
> encrypted by default, the application can add it back in authenticated
> data, or in some unauthenticated wrapper.
>
> Net of those considerations, I'm personally still inclined to merge the
> PR, to have a conservative baseline.  But those on the call thought it
> would be useful to pose this to the group, so please speak up if you have
> concerns.
>
> --Richard
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 13 Jul 2020 11:56:35 -0400

> expect this to be a source of confusion and bugs.

I think the discussion on #245 got derailed a bit by the focus on
non-linear epochs.  The point here is that even in a case where you have
linear history, I think there's intrinsic value in the epoch ID being
opaque because it gives intermediaries less opportunity for ossification.

As far as collision resistance, I'm not too worried about collisions among
64-bit random values, especially as the scope for collision is fairly
small, arguably just one epoch.

> which message was a commit, or see a dropped message getting re-sent and

I don't disagree that there are different guarantees you need, but like I
said, I think the idea here is to be conservative by default.  There are
systems in which you can hide the metadata you're talking about with things
like mixnets and dropboxes.  Keeping the ciphertext as opaque as possible
keeps the door open to running MLS over those systems without MLS's own
metadata undermining their privacy properties.

FWIW, in the systems I'm looking at building, this PR does not make any
difference, because clients use separate channels for Proposals/Commits vs.
application data and the server doesn't check.

--Richard

---

From: Raphael Robert <[email-masked]>
Date: Mon, 13 Jul 2020 18:32:02 +0200

As mentioned on the call, I think that “privacy by design” is the right approach (unless proven otherwise in specific cases) and we should go forward with this.

Raphael

> On 13 Jul 2020, at 17:56, Richard Barnes <[email-masked]> wrote:
> 
> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <[email-masked] <mailto:[email-masked]>> wrote:
> With respect to using an opaque epoch id, I believe this was proposed in #245 <https://github..com/mlswg/mls-protocol/pull/245> and consensus was against it because it makes it more difficult to implement the DS. It's also not clear to me what security properties you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect this to be a source of confusion and bugs.
> 
> I think the discussion on #245 got derailed a bit by the focus on non-linear epochs.  The point here is that even in a case where you have linear history, I think there's intrinsic value in the epoch ID being opaque because it gives intermediaries less opportunity for ossification.
> 
> As far as collision resistance, I'm not too worried about collisions among 64-bit random values, especially as the scope for collision is fairly small, arguably just one epoch.
> 
>  
> With respect to encrypting the content type, it also seems to me that this would cause issues because different content types have different delivery guarantees. Specifically: messages are allowed to be unordered and lossy, proposals are allowed to be unordered but not lossy, and commits are both ordered and not lossy. In the deployment scenarios we've talked about, the DS essentially always needs to know the content type to provide this. Conversely, you don't get much additional privacy from encrypting the content type because an eavesdropper can see the epoch id change and infer which message was a commit, or see a dropped message getting re-sent and infer it was a proposal.
> 
> I don't disagree that there are different guarantees you need, but like I said, I think the idea here is to be conservative by default.  There are systems in which you can hide the metadata you're talking about with things like mixnets and dropboxes.  Keeping the ciphertext as opaque as possible keeps the door open to running MLS over those systems without MLS's own metadata undermining their privacy properties.
> 
> FWIW, in the systems I'm looking at building, this PR does not make any difference, because clients use separate channels for Proposals/Commits vs. application data and the server doesn't check.
> 
> --Richard
> 
>  
> 
> Recall that PR#349 does two things (1) use an opaque epoch ID, and (2) encrypt the content type of the message (application / proposal / commit) [1].
> 
> There was some discussion on the call last week that encrypting the content type might not be that useful, since an application that relies on a server to assure ordering of commits will need to at least be able to tell commits from other things.  Of course, even if the content type is encrypted by default, the application can add it back in authenticated data, or in some unauthenticated wrapper.
> 
> Net of those considerations, I'm personally still inclined to merge the PR, to have a conservative baseline.  But those on the call thought it would be useful to pose this to the group, so please speak up if you have concerns.
> 
> --Richard
> 
> [1] https://github.com/mlswg/mls-protocol/pull/349 <https://github.com/mlswg/mls-protocol/pull/349>_______________________________________________
> MLS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>

---

From: Brendan McMillion <[email-masked]>
Date: Mon, 13 Jul 2020 11:37:28 -0500

> small, arguably just one epoch.

The issue isn't with accidental collisions, it's with malicious ones. An
attacker can purposefully (and quickly) generate commits that create
duplicate epoch ids, and send them to a client to corrupt their group state.

I think the idea here is to be conservative by default.  There are systems
> in which you can hide the metadata you're talking about with things like
> mixnets and dropboxes.
>

It's not just being more conservative, you're making changes specifically
for very niche use-cases where I don't think the security of the whole
system has been thought through. Maybe you have an example in mind, but I
can't think of a system where this change provides any additional privacy.

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <[email-masked]> wrote:

>> With respect to encrypting the content type, it also seems to me that
>> this would cause issues because different content types have different
>> delivery guarantees. Specifically: messages are allowed to be unordered and
>> lossy, proposals are allowed to be unordered but not lossy, and commits are
>> both ordered and not lossy. In the deployment scenarios we've talked about,
>> the DS essentially always needs to know the content type to provide this.

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Tue, 14 Jul 2020 14:38:52 +0000

Ensuring the most conservative design by default seems advisable; however it is not clear that this proposal for hiding content type is actually doing that. Indeed, if an application is concerned about hiding the content type, would not that same type of application also be concerned about collisions?

As Brendan notes, we are not talking about accidental collisions here. Pre-computation is entirely possible, such as by a malicious group member, so the window of attack is not limited to one epoch.

If this is this PR particular is of particular interest to some, then it would be good to see a clarifying explanation as to the security it achieves (i.e. why this is “security by design” despite introducing such collision possibilities), or a concrete use-case. Alternatively, are we really limited to a 64-bit field, or can that length be adjusted to mitigate the introduced problems?

A clarifying point for those following this thread: some references in the email chain state that this is encryption of the epoch ID. That is not the case. The proposal being discussed is about a hash thereof (hence discussion on collisions).

Britta

From: MLS <[email-masked]> on behalf of Brendan McMillion <brendan=[email-masked]>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <[email-masked]>
Cc: Messaging Layer Security WG <[email-masked]>
Subject: Re: [MLS] Hiding content type

The issue isn't with accidental collisions, it's with malicious ones. An attacker can purposefully (and quickly) generate commits that create duplicate epoch ids, and send them to a client to corrupt their group state.

I think the idea here is to be conservative by default.  There are systems in which you can hide the metadata you're talking about with things like mixnets and dropboxes.

It's not just being more conservative, you're making changes specifically for very niche use-cases where I don't think the security of the whole system has been thought through. Maybe you have an example in mind, but I can't think of a system where this change provides any additional privacy.

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <[email-masked]> wrote:
On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <[email-masked]<mailto:[email-masked]>> wrote:
With respect to using an opaque epoch id, I believe this was proposed in #245<https://github.com/mlswg/mls-protocol/pull/245> and consensus was against it because it makes it more difficult to implement the DS. It's also not clear to me what security properties you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect this to be a source of confusion and bugs.

--Richard

--Richard

[1] https://github.com/mlswg/mls-protocol/pull/349
_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 Jul 2020 14:04:42 -0400

I'm honestly really confused by the worry about collisions here.  The
current epoch ID collides trivially -- it's just a counter!  And the group
ID is assumed to be public anyway.  So if your authentication scheme is
broken when you have a (group ID, epoch ID) collision, then your scheme is
already broken.

If we're going to block this change on this basis, then we need to see
clearly articulated an authentication scheme that is secure in the current
model, but broken in the case where epoch IDs are derived off of the key
schedule.

--Richard

On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <[email-masked]>
wrote:

> Ensuring the most conservative design by default seems advisable; however
> it is not clear that this proposal for hiding content type is actually
> doing that. Indeed, if an application is concerned about hiding the content
> type, would not that same type of application also be concerned about
> collisions?
>
>
>
> As Brendan notes, we are not talking about accidental collisions here.
> Pre-computation is entirely possible, such as by a malicious group member,
> so the window of attack is not limited to one epoch.
>
>
>
> If this is this PR particular is of particular interest to some, then it
> would be good to see a clarifying explanation as to the security it
> achieves (i.e. why this is “security by design” despite introducing such
> collision possibilities), or a concrete use-case. Alternatively, are we
> really limited to a 64-bit field, or can that length be adjusted to
> mitigate the introduced problems?
>
>
>
>
>
>
>
> A clarifying point for those following this thread: some references in the
> email chain state that this is encryption of the epoch ID. That is not the
> case. The proposal being discussed is about a hash thereof (hence
> discussion on collisions).
>
>
>
> Britta
>
>
>
>
>
> *From: *MLS <[email-masked]> on behalf of Brendan McMillion
> <brendan=[email-masked]>
> *Date: *Monday, July 13, 2020 at 9:37 AM
> *To: *Richard Barnes <[email-masked]>
> *Cc: *Messaging Layer Security WG <[email-masked]>
> *Subject: *Re: [MLS] Hiding content type
>
>
>

---

From: Brendan McMillion <[email-masked]>
Date: Sat, 25 Jul 2020 10:50:31 -0700

Take for example, a broadcast channel that's ordered but lossy. A Commit
gets sent where the new epoch id collides with the previous epoch id, but
not all members get the Commit. So now the group is fractured and there's
no way for members in the previous epoch to know that they missed a
message. What the application developer needs to do to detect lost
messages, is immediately re-implement the counter epoch id that you've just
removed.

That's an example of a system where this change is pointless / harmful. If
you could provide an example of a system where the change is *helpful*,
that would be more interesting.

On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <[email-masked]> wrote:

>> A clarifying point for those following this thread: some references in
>> the email chain state that this is encryption of the epoch ID. That is not
>> the case. The proposal being discussed is about a hash thereof (hence
>> As far as collision resistance, I'm not too worried about collisions
>> among 64-bit random values, especially as the scope for collision is fairly
>> I think the idea here is to be conservative by default.  There are
>> like mixnets and dropboxes.
>>
>>
>>
>> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <
>> [email-masked]> wrote:
>>
>> As far as collision resistance, I'm not too worried about collisions
>> among 64-bit random values, especially as the scope for collision is fairly

---

From: Richard Barnes <[email-masked]>
Date: Sat, 25 Jul 2020 15:38:33 -0400

Just so we're clear, in your example, are you concerned about accidental or
adversarial collisions?  I hope we agree that we can fix the accidental
case just by making a longer epoch ID.  In the adversarial case, this seems
like a partial DoS at worst, since the members who incorrectly think they
are in the previous epoch will no longer be decrypting with the right keys.

As far as a positive example: Imagine a Generic Commit Sequencing Service
that provides a reliable broadcast/ledger over anonymous channels (e.g., as
an onion service), but will only broadcast/record one message for each
groupID/epoch.  If the groupID/epoch is opaque, then such a service can be
provided without learning anything about the groups it serves or their
evolution.

On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion <[email-masked]>
wrote:

>>> Ensuring the most conservative design by default seems advisable;
>>> however it is not clear that this proposal for hiding content type is
>>> actually doing that. Indeed, if an application is concerned about hiding
>>> the content type, would not that same type of application also be concerned
>>> about collisions?
>>>
>>>
>>>
>>> It's not just being more conservative, you're making changes
>>> specifically for very niche use-cases where I don't think the security of
>>> the whole system has been thought through. Maybe you have an example in
>>> mind, but I can't think of a system where this change provides any
>>> additional privacy.
>>>
>>>
>>>
>>> I don't disagree that there are different guarantees you need, but like
>>> I said, I think the idea here is to be conservative by default.  There are

---

From: Brendan McMillion <[email-masked]>
Date: Sat, 25 Jul 2020 15:10:15 -0700

I’m concerned about adversarial collisions, that'd cause a partial DoS like you say. There are other ways to cause partial DoS in an MLS group, but I think it’s good to minimize the avenues for attack.

In your example, it sounds like you’re trying to achieve unlinkability between messages, with a Generic Commit Sequencing Service which is basically a KV store that only accepts one write per key. So in this scenario, I think you would be much better off by simply truncating the group ID and epoch from MLSCiphertext (making them implicit), and choosing the key that each message is stored under with some function of: 1.) a group secret, and 2.) a message counter.

Would that work?

> On Jul 25, 2020, at 12:38 PM, Richard Barnes <[email-masked]> wrote:
> 
> Just so we're clear, in your example, are you concerned about accidental or adversarial collisions?  I hope we agree that we can fix the accidental case just by making a longer epoch ID.  In the adversarial case, this seems like a partial DoS at worst, since the members who incorrectly think they are in the previous epoch will no longer be decrypting with the right keys.
> 
> As far as a positive example: Imagine a Generic Commit Sequencing Service that provides a reliable broadcast/ledger over anonymous channels (e.g., as an onion service), but will only broadcast/record one message for each groupID/epoch.  If the groupID/epoch is opaque, then such a service can be provided without learning anything about the groups it serves or their evolution.
> 
> 
> On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion <[email-masked] <mailto:[email-masked]>> wrote:
> Take for example, a broadcast channel that's ordered but lossy. A Commit gets sent where the new epoch id collides with the previous epoch id, but not all members get the Commit. So now the group is fractured and there's no way for members in the previous epoch to know that they missed a message. What the application developer needs to do to detect lost messages, is immediately re-implement the counter epoch id that you've just removed.
> 
> That's an example of a system where this change is pointless / harmful. If you could provide an example of a system where the change is *helpful*, that would be more interesting.
> 
> I'm honestly really confused by the worry about collisions here.  The current epoch ID collides trivially -- it's just a counter!  And the group ID is assumed to be public anyway.  So if your authentication scheme is broken when you have a (group ID, epoch ID) collision, then your scheme is already broken.
> 
> If we're going to block this change on this basis, then we need to see clearly articulated an authentication scheme that is secure in the current model, but broken in the case where epoch IDs are derived off of the key schedule.
> 
> --Richard
> 
> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
> From: MLS <[email-masked] <mailto:[email-masked]>> on behalf of Brendan McMillion <brendan=[email-masked] <mailto:[email-masked]>>
> Cc: Messaging Layer Security WG <[email-masked] <mailto:[email-masked]>>
> With respect to using an opaque epoch id, I believe this was proposed in #245 <https://github.com/mlswg/mls-protocol/pull/245> and consensus was against it because it makes it more difficult to implement the DS. It's also not clear to me what security properties you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect this to be a source of confusion and bugs.
> 
>  
> 
> [1] https://github.com/mlswg/mls-protocol/pull/349 <https://github.com/mlswg/mls-protocol/pull/349>

---

From: Chelsea Komlo <[email-masked]>
Date: Mon, 27 Jul 2020 22:01:29 -0600

I would like to affirm the positive use case Richard described, and say
that minimizing metadata where possible is valuable and leaves open the
possibility of using MLS in less-trusted settings. There are messaging
applications currently being developed in practice [1] that provide
metadata resistance (and hopefully more will follow this trend in the
future). It would be good to keep the door open to the use of MLS in these
settings.

As I am just now reading over the latest draft, I don't have much to add at
this moment as to how to derive these fields implicitly, but I am happy to
take a closer look and provide recommendations if the group doesn't come
to consensus in the meeting this week.

[1] https://openprivacy.ca/work/cwtch/

On Sat, Jul 25, 2020 at 4:10 PM Brendan McMillion <brendan=
[email-masked]> wrote:

> I’m concerned about adversarial collisions, that'd cause a partial DoS
> like you say. There are other ways to cause partial DoS in an MLS group,
> but I think it’s good to minimize the avenues for attack.
>
> In your example, it sounds like you’re trying to achieve unlinkability
> between messages, with a Generic Commit Sequencing Service which is
> basically a KV store that only accepts one write per key. So in this
> scenario, I think you would be much better off by simply truncating the
> group ID and epoch from MLSCiphertext (making them implicit), and choosing
> the key that each message is stored under with some function of: 1.) a
> group secret, and 2.) a message counter.
>
> Would that work?
>
> Just so we're clear, in your example, are you concerned about accidental
> or adversarial collisions?  I hope we agree that we can fix the accidental
>> That's an example of a system where this change is pointless / harmful.
>> If you could provide an example of a system where the change is *helpful*,
>>>> If this is this PR particular is of particular interest to some, then
>>>> it would be good to see a clarifying explanation as to the security it
>>>> The issue isn't with accidental collisions, it's with malicious ones.
>>>> An attacker can purposefully (and quickly) generate commits that create
>>>> With respect to using an opaque epoch id, I believe this was proposed
>>>> in #245 <https://github.com/mlswg/mls-protocol/pull/245> and consensus
>>>> was against it because it makes it more difficult to implement the DS. It's

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Tue, 28 Jul 2020 05:16:37 +0000

Privacy-by-default is a goal that I think most on the mailinglist can agree with (at least there have not been objections about that so far). It is *how* it is achieved that is the issue.

A the moment, one method has been presented and strongly argued for, but there does not seem to be a good backing case for that approach. Alternatively, there could be other ways of achieving privacy and content hiding and alleviating some of the various types of concerns that have been raised from different corners.

-  For example, it was proposed on the mailing list on 14 July that we could consider a longer field to avoid collisions.
-  Also, there does not seem to be a firm reason for deriving the epoch ID as proposed. If the hash was instead over only the (current version) group/epoch ID, then there would be no variable input and the epoch ID would be predictable by all members of the group (but not those outside). That would allay some of the forking concerns. A compromise might be found on what inputs to use, so that the epoch ID remains predictable only to group members following an add/removal.
-  Finally, (if we really want to expand on possibilities) if the epoch ID was taken as an encryption of the current group/epoch ID instead of a hash, then it could be uniquely reconcilable when required. The group/epoch ID length is already accounted for in the current spec, so compression with a hash is not really a bonus factor.

Just to be clear, I do not think that the third point above is really a good option. However, it does highlight that there are other options to meet the end goal of content hiding. The other two points ought to be considered.

The “positive use case” described thus far is an argument for the end goal of content hiding, but is not an argument for content hiding in the particular way that has been proposed. Having a positive use case to support the precise proposed change would be helpful.

Ultimately, I would like to see arguments for/against the various other ways of achieving content hiding, such as those listed above (or others). This applies to both the concerns about resistance to collisions as well as the general aim of privacy. It is by no means an absolute fact that we can support only one or the other, so there may be a solution that addresses all concerns discussed so far. It is definitely worthwhile to try for that.

Britta

From: Chelsea Komlo <[email-masked]>
Date: Monday, July 27, 2020 at 9:01 PM
To: "[email-masked]" <[email-masked]>
Cc: "Hale, Britta (CIV)" <[email-masked]>, "[email-masked]" <[email-masked]>, "brendan=[email-masked]" <brendan=[email-masked]>
Subject: Re: [MLS] Hiding content type

I would like to affirm the positive use case Richard described, and say that minimizing metadata where possible is valuable and leaves open the possibility of using MLS in less-trusted settings. There are messaging applications currently being developed in practice [1] that provide metadata resistance (and hopefully more will follow this trend in the future). It would be good to keep the door open to the use of MLS in these settings.

As I am just now reading over the latest draft, I don't have much to add at this moment as to how to derive these fields implicitly, but I am happy to take a closer look and provide recommendations if the group doesn't come to consensus in the meeting this week.

On Sat, Jul 25, 2020 at 4:10 PM Brendan McMillion <brendan=[email-masked]<mailto:[email-masked]>> wrote:
I’m concerned about adversarial collisions, that'd cause a partial DoS like you say. There are other ways to cause partial DoS in an MLS group, but I think it’s good to minimize the avenues for attack.

Would that work?

On Jul 25, 2020, at 12:38 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Jul 25, 2020 at 1:50 PM Brendan McMillion <[email-masked]<mailto:[email-masked]>> wrote:
Take for example, a broadcast channel that's ordered but lossy. A Commit gets sent where the new epoch id collides with the previous epoch id, but not all members get the Commit. So now the group is fractured and there's no way for members in the previous epoch to know that they missed a message. What the application developer needs to do to detect lost messages, is immediately re-implement the counter epoch id that you've just removed.

On Fri, Jul 24, 2020 at 11:05 AM Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
I'm honestly really confused by the worry about collisions here.  The current epoch ID collides trivially -- it's just a counter!  And the group ID is assumed to be public anyway.  So if your authentication scheme is broken when you have a (group ID, epoch ID) collision, then your scheme is already broken.

On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:
Ensuring the most conservative design by default seems advisable; however it is not clear that this proposal for hiding content type is actually doing that. Indeed, if an application is concerned about hiding the content type, would not that same type of application also be concerned about collisions?

Britta

From: MLS <[email-masked]<mailto:[email-masked]>> on behalf of Brendan McMillion <brendan=[email-masked]<mailto:[email-masked]>>
Date: Monday, July 13, 2020 at 9:37 AM
To: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Cc: Messaging Layer Security WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MLS] Hiding content type

On Mon, Jul 13, 2020 at 10:56 AM Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <[email-masked]<mailto:[email-masked]>> wrote:
With respect to using an opaque epoch id, I believe this was proposed in #245<https://github.com/mlswg/mls-protocol/pull/245> and consensus was against it because it makes it more difficult to implement the DS. It's also not clear to me what security properties you want from an opaque epoch id, because the current PR doesn't provide collision resistance and I'd expect this to be a source of confusion and bugs.

--Richard

On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2020 07:49:17 -0400

Inline...

On Tue, Jul 28, 2020 at 1:16 AM Hale, Britta (CIV) <[email-masked]>
wrote:

> Privacy-by-default is a goal that I think most on the mailinglist can
> agree with (at least there have not been objections about that so far). It
> is **how** it is achieved that is the issue.
>
>
>
> A the moment, one method has been presented and strongly argued for, but
> there does not seem to be a good backing case for that approach.
> Alternatively, there could be other ways of achieving privacy and content
> hiding and alleviating some of the various types of concerns that have been
> raised from different corners.
>
>
>
> -  For example, it was proposed on the mailing list on 14 July that we
> could consider a longer field to avoid collisions.
>

To be clear, I am fine with this.  What is your preferred size?  Would
something like 16 bytes work?

> -  Also, there does not seem to be a firm reason for deriving the epoch ID
> as proposed. If the hash was instead over only the (current version)
> group/epoch ID, then there would be no variable input and the epoch ID
> would be predictable by all members of the group (but not those outside).
> That would allay some of the forking concerns. A compromise might be found
> on what inputs to use, so that the epoch ID remains predictable only to
> group members following an add/removal.
>

This seems worse to me.  Basically, you're saying that the group members
can brute-force the epoch IDs when necessary -- but that also means that
the DS can brute force them.

You seem to be presuming that there's a need for clients to be able to
recognize which epoch IDs belong to which groups -- even for epochs where
they are not a member.  That seems of limited utility, since the client
can't do anything with the message other than recognize its existence.  Can
you elaborate why this property seems desirable?

The proposal in the PR provides the more limited property that clients can
recognize epoch IDs for epochs they are members of, which is pretty clearly
required for the protocol to work.

> -  Finally, (if we really want to expand on possibilities) if the epoch ID
> was taken as an encryption of the current group/epoch ID instead of a hash,
> then it could be uniquely reconcilable when required. The group/epoch ID
> length is already accounted for in the current spec, so compression with a
> hash is not really a bonus factor.
>

I agree that this is not a great option, not least because it's not clear
what key you would use.  It is also premised on the idea of epoch IDs being
intelligible by non-members, which seems problematic as above.

--Richard

>
>
> Just to be clear, I do not think that the third point above is really a
> good option. However, it does highlight that there are other options to
> meet the end goal of content hiding. The other two points ought to be
> considered.
>
>
>
> The “positive use case” described thus far is an argument for the end goal
> of content hiding, but is not an argument for content hiding in the
> particular way that has been proposed. Having a positive use case to
> support the precise proposed change would be helpful.
>
>
>
> Ultimately, I would like to see arguments for/against the various other
> ways of achieving content hiding, such as those listed above (or others).
> This applies to both the concerns about resistance to collisions as well as
> the general aim of privacy. It is by no means an absolute fact that we can
> support only one or the other, so there may be a solution that addresses
> all concerns discussed so far. It is definitely worthwhile to try for that.
>
>
>
>
>
> Britta
>
>
>
>
>
> *From: *Chelsea Komlo <[email-masked]>
> *Date: *Monday, July 27, 2020 at 9:01 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"Hale, Britta (CIV)" <[email-masked]>, "[email-masked]" <[email-masked]>,
> "brendan=[email-masked]" <brendan=
> [email-masked]>
> As I am just now reading over the latest draft, I don't have much to add
> at this moment as to how to derive these fields implicitly, but I am happy
> to take a closer look and provide recommendations if the group doesn't come

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2020 08:35:12 -0400

> but I think it’s good to minimize the avenues for attack.

I wonder if this could in part be addressed just by using a longer
identifier to make finding adversarial collisions impractical.

> group secret, and 2.) a message counter.

Interesting, but I don't think so.  I'm concerned about forcing
applications to invent too much here.  It seems like from what we know now,
some applications are going to need to identify the group ID / epoch in the
message, and in some applications, the group ID / epoch is going to be
clear from context.  That latter class of application would probably be OK
with an implicit GroupID / Epoch.  But in the former class, you would be
forcing the application to invent its own scheme for signaling this stuff,
which risks them making decisions that are suboptimal for metadata privacy.

So my preference would still be to provide an identifier that offers the
minimal properties required to make the protocol work.  But I would be
happy to acknowledge that applications can leak more metadata if they need
to, and that metadata can be ultimately authenticated by the protocol.  In
fact, we could make this explicit by making the AAD for the ciphertext
encryption include the GroupID and Epoch counter in addition to the opaque
epoch.

What would folks think about the following proposal:

1. MLSCiphertext includes an opaque EpochID
2. ... with a length that makes finding collisions infeasible (16 bytes?
32 bytes?  KDF.Nh bytes?)
3. We add some explicit text noting that additional metadata can be added
by the application
4. ... and update the AAD for the sender data and content encryptions to
use all three values (group ID, epoch counter, epoch ID)

--Richard

---

From: Brendan McMillion <[email-masked]>
Date: Tue, 28 Jul 2020 07:10:48 -0700

>
> But in the former class, you would be forcing the application to invent
> its own scheme for signaling this stuff, which risks them making decisions
> that are suboptimal for metadata privacy.

Making a metadata-resistant deployment of MLS would already be incredibly
difficult because you'd have to design your application to use the network
in a way that prevents useful traffic analysis. Someone who's capable of
this should definitely be capable of choosing how messages are identified
in their system.

The flip side, is that your construction is already suboptimal for metadata
privacy because the epoch id only changes once per epoch. In the
construction that I described, the opaque identifier changes with each
message. You could also imagine a system where the identifier would change
with time instead of with protocol messages (for example, where messages
are distributed over Tor circuits).

On Tue, Jul 28, 2020 at 5:35 AM Richard Barnes <[email-masked]> wrote:

>>>> On Tue, Jul 14, 2020 at 10:38 AM Hale, Britta (CIV) <
>>>> [email-masked]> wrote:
>>>>
>>>>> in #245 <https://github.com/mlswg/mls-protocol/pull/245> and
>>>>> consensus was against it because it makes it more difficult to implement
>>>>> the DS. It's also not clear to me what security properties you want from an
>>>>> opaque epoch id, because the current PR doesn't provide collision
>>>>> resistance and I'd expect this to be a source of confusion and bugs.
>>>>>
>>>>>
>>>>>
>>>>> I don't disagree that there are different guarantees you need, but
>>>>> like I said, I think the idea here is to be conservative by default.  There
>>>>> are systems in which you can hide the metadata you're talking about with
>>>>> things like mixnets and dropboxes.  Keeping the ciphertext as opaque as
>>>>> possible keeps the door open to running MLS over those systems without
>>>>> MLS's own metadata undermining their privacy properties.
>>>>>
>>>>>
>>>>>
>>>>> FWIW, in the systems I'm looking at building, this PR does not make
>>>>> any difference, because clients use separate channels for Proposals/Commits
>>>>> vs. application data and the server doesn't check.
>>>>>
>>>>>
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Net of those considerations, I'm personally still inclined to merge
>>>>> the PR, to have a conservative baseline.  But those on the call thought it

---

From: Chelsea Komlo <[email-masked]>
Date: Tue, 28 Jul 2020 15:37:29 -0600

> this should definitely be capable of choosing how messages are identified

While the network layer would need to protect against network-level traffic
analysis such as timing and frequency fingerprinting, this can be done in a
generalized way that is agnostic to the application (such as if a mix
network were used to route traffic between the client and the DS). Ideally,
MLS as a higher-level application would not leak additional information
when it is received by the DS after having been sent through such a
network.

> The flip side, is that your construction is already suboptimal for
> metadata privacy because the epoch id only changes once per epoch. In the

It is true that message fields should be bitwise unlinkable to a network
observer (see [1] for more information on how this property is instantiated
in routing protocols). Time can be a dangerous dependency in distributed
systems though, so I would be careful there.

[1] https://www.cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf

---

From: Brendan McMillion <[email-masked]>
Date: Tue, 28 Jul 2020 15:04:59 -0700

>
> While the network layer would need to protect against network-level
> traffic analysis such as timing and frequency fingerprinting, this can be
> done in a generalized way that is agnostic to the application (such as if a
> mix network were used to route traffic between the client and the DS).

In the specific case of a mix network, that's not true. The DS has at least
these variables for traffic analysis:

1. Messages which are requested in quick succession (associating messages
that are requested together with the same group)
2. How many times a message is requested (associating a message with the
number of participants in the group it was sent to)
3. Messages requested over the same circuit (Tor and similar networks often
reuse circuits for efficiency)

and may have more depending on context.

On Tue, Jul 28, 2020 at 2:37 PM Chelsea Komlo <[email-masked]>
wrote:

> While the network layer would need to protect against network-level
> traffic analysis such as timing and frequency fingerprinting, this can be
> done in a generalized way that is agnostic to the application (such as if a
> mix network were used to route traffic between the client and the DS).
> Ideally, MLS as a higher-level application would not leak additional
> information when it is received by the DS after having been sent through
> such a network.
>
>

---

From: Chelsea Komlo <[email-masked]>
Date: Tue, 28 Jul 2020 18:11:25 -0600

I realize this is off topic to the discussion of hiding content type/epoch
ids in MLS, but addressing the below for completeness. I'm happy to
continue this discussion in a separate thread if there is further interest.

On Tue, Jul 28, 2020 at 4:05 PM Brendan McMillion <[email-masked]>
wrote:

> In the specific case of a mix network, that's not true. The DS has at
> least these variables for traffic analysis:
>

The DS can observe access patterns, but the important point is whether it
can then use that information to deanonymize users.

In a mix network instantiated with protocols like Loopix [1], users
generate and send dummy packets (i.e, cover traffic that is dropped at
random points in the network) along with real packets, all which are
delayed by some random time period at each hop in the path. So performing
end-to-end correlation attacks in such systems is harder.

However, even when Tor is used, the question is at what point the DS *can*
learn enough to deanonymize users if it can only observe access patterns
and any exposed metadata (assuming it cannot perform end-to-end correlation
attacks). See next.

> number of participants in the group it was sent to)

Note this problem of access pattern observability is not unique to MLS and
without the use of PIR, access patterns will be observable by any content
provider even when traffic is routed through an anonymity network.

> 3. Messages requested over the same circuit (Tor and similar networks
> often reuse circuits for efficiency)
>

This is only an issue in circuit-switched networks like Tor (where users
maintain a long-lived connections), whereas mix networks like Loopix are
packet-switched, meaning every message is routed independently. Further,
applications using Tor can rotate through circuits more quickly, if desired
(Tor Browser does this).

[1]
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/piotrowska