Subject: [MLS] key update guidance

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Jul 2018 18:18:29 -0400

At the discussion today, it sounded to me like there was a general
agreement that we want to document some sort of guidance for the
frequency of key updates.

This might end up being more complex than just "update your own key once
per day" -- as Jon pointed out, for a large group that could result in
a storm of key update messages.

One thing we did not discuss is how key update frequency guidance might
be either communicated or enforced.

 (a) should peers in a conversation have a way to communicate explicit
     expectations about key rotation frequency?  Establishing a shared
     expectation of key rotation can make enforcement more
     straightforward and comprehensible (both for the user who gets
     kicked, and for the people remaining in the conversation when a
     member gets kicked).

 (b) if there is an expectation of key rotation frequency, does MLS
     contemplate any enforcement mechanism?  if there is enforcement,
     who should enforce: participants in the group, or the server?

My gut feeling is that (a) we should be able to communicate rotation
expectations to the group, and (b) participants, not the server, should
be responsible for enforcement.  I don't have a specific protocol
proposal for how to do either step, though.

    --dkg

---

From: "Katriel Cohn-Gordon" <[email-masked]>
Date: Fri, 20 Jul 2018 12:02:18 +0100

>      kicked, and for the people remaining in the conversation when a

+1 this could perhaps be one of the group parameters that gets agreed on setup.

Is there likely to be a need to change this for an existing group? I'm inclined to say no.

>      who should enforce: participants in the group, or the server?

+1 clients know when they got a key from someone else, so they could unilaterally decide not to accept messages under a too-old key.

This could lead to confusing transcripts if one client accepts a message (say it has clock skew) and another doesn't, but I think this is no worse than a network adversary which drops a message. Ideally the expiry time is well above the actual update frequency, so clients under normal operation should rarely hit it.

k

---

From: Jon Millican <[email-masked]>
Date: Fri, 20 Jul 2018 12:30:07 +0000

> On 20 Jul 2018, at 12:03, Katriel Cohn-Gordon <[email-masked]> wrote:
> 
> This could lead to confusing transcripts if one client accepts a message (say it has clock skew) and another doesn't, but I think this is no worse than a network adversary which drops a message.

This could perhaps be server assisted? I.e. the server should be cooperative and force updates at appropriate times, but clients will ultimately enforce it if the server fails to do so. Intuitively I don't think we're relying on the server for a security property here, and as it will likely always be capable of corrupting the conversation, I don't think it will make this significantly worse either.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 20 Jul 2018 23:15:22 -0400

On Fri 2018-07-20 12:30:07 +0000, Jon Millican wrote:
>> This could lead to confusing transcripts if one client accepts a
>> message (say it has clock skew) and another doesn't, but I think this
>> is no worse than a network adversary which drops a message.
>
> This could perhaps be server assisted? I.e. the server should be
> cooperative and force updates at appropriate times, but clients will
> ultimately enforce it if the server fails to do so.

That would oblige us to expose the fact of keying updates (and possibly
the keying material itself) to the DS, right?  what advantage would that
have?

    --dkg

---

From: "Alexey Ermishkin" <[email-masked]>
Date: Sun, 22 Jul 2018 16:29:55 +0500

Is there a need for key rotation for a member who does not send messages?
Probably there is.
On the one hand, "advertising" new keys in actual message's header (like
Signal does) simplifies message processing logic. 
On the other, Sending "rekey" messages could provide better overall key
rotation flow.

As for the enforcement, I think the possible solution could be ordered
rotation.
Example: 
- The group implicitly agrees on the order members rotate their keys (sorts
members by ID). 
- Each member sends the new key in his turn or after timeout in case
someone's offline.
  - This can be done by either assigning each member a time slot or allowing
next member to send key after a certain amount of time after previous one to
prevent flooding.

Pros: Each member gets his key updated, no message tsunami
Cons: Skipped members should wait for the next key rotation round

-----Original Message-----
From: MLS <[email-masked]> On Behalf Of Daniel Kahn Gillmor
Sent: Friday, July 20, 2018 3:18 AM
To: [email-masked]
Subject: [MLS] key update guidance

At the discussion today, it sounded to me like there was a general agreement
that we want to document some sort of guidance for the frequency of key
updates.

This might end up being more complex than just "update your own key once per
day" -- as Jon pointed out, for a large group that could result in a storm
of key update messages.

One thing we did not discuss is how key update frequency guidance might be
either communicated or enforced.

My gut feeling is that (a) we should be able to communicate rotation
expectations to the group, and (b) participants, not the server, should be
responsible for enforcement.  I don't have a specific protocol proposal for
how to do either step, though.

    --dkg

_______________________________________________
MLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jul 2018 10:33:59 -0400

> the keying material itself) to the DS, right?  what advantage would that

I don't think necessarily requires exposing the fact that an update has
happened to the DS.  The DS could simply tell the group, "Here is a window
for X to update", without being able to know whether X actually did update,
inside or outside that window.  This would only become an issue if the
*only* way you could update was if the DS opened a window for you.

Returning to the original question: I'm going to push back on the notion
that this protocol needs to enable endpoints to communicate their
expectations about update frequency.  That seems like metadata that could
be negotiated at a different layer.  By way of analogy, TLS peers don't
negotiate when to send KeyUpdate (which is not quite the same, but still).

The space of things that are specifically germane to MLS is fairly bounded,
something like:

* Update provides the PCS boundaries w.r.t. the sender
  * It is thus important for all nodes to regularly send Update messages,
even they are not otherwise transmitting
  * However, receiving Update messages imposes a computational burden on
receivers, especially in large groups
* Applications using MLS MUST ensure that members of a group regularly send
Update messages, independent of other transmission schedules
  * Each endpoint SHOULD send an Update no less frequently than once per day
  * Updates SHOULD be limited to a level that maintains an acceptable
burden on receivers
  * If Updates need to be limited, applications SHOULD prioritize updates
from members that have updated least recently

That is, the precise update schedule needs to be decided by the application
(possibly involving some negotiation), but we can (1) mandate that an
update schedule exists and (2) recommend some bounds on what the schedule
looks like.

--Richard