Re: [MLS] Hiding content type

[Brendan McMillion <[e-mail]>]

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

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 <[e-mail]> wrote:

> On Mon, Jul 13, 2020 at 10:57 AM Brendan McMillion <[e-mail]>
> 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
>
>
>
>>
>> On Mon, Jul 13, 2020 at 8:56 AM Richard Barnes <[e-mail]> wrote:
>>
>>> 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
>>> _______________________________________________
>>> MLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mls
>>>
>>