Subject: [MLS] Resync archaeology + analysis + prognosis

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Oct 2021 19:06:53 -0400

OK, I think I have traced back some idea of why we removed the earlier
resync proposal.  Here's a little essay on how we got here, a recap of the
trade-offs, and my thoughts on where we should go.

tl;dr: Earlier decision not dispositive; we should do basically what's in
the PR now.

# History

The story starts all the way back at the January 2019 interim at Mozilla /
Mountain View.  There was a discussion there of ACK/NACK and replay as
related issues [1].  That discussion seems to have led to agreement that a
complete error recovery system was a complex enough topic, and clearly
enough separated from the main protocol that it could be handled in a
separate specification.  As a result, the issues that had been opened for
ACK/NACK and resync were closed [2][3].  When Britta and Konrad posted #336
[4] including a resync mechanism, my review simply cited that earlier
closed issue as a reason for taking it out [5].

One other note with regard to #336 -- It looks to me like the "resync"
mechanism in there was not really fleshed out enough to be implementable.
The state linked above was the last state before my review, and the word
"resync" doesn't actually appear.  Instead the PR talks about "recovering
lost group members" using Add and PSK, which could be elaborated to solve a
version of this problem, but would require the assistance of a continuing
member rather than allowing the lost member to resync unilaterally.  It
would also have the same issues noted in terms of new joiners not having
resync PSKs.

Overall, though, reading this history doesn't seem to me like we really
made a principled decision not to do resync.  We just punted after some
discussion in the abstract, and that stuck.  We have a more concrete
question now.

# Analysis

Since the discussion of #336 in 2020, we have added external commits in
order to have groups you can join unilaterally.  So regardless of the
broader question of resync, we have to decide what proposals a joiner is
allowed to originate in their Commit (sending them by value), in
particular, whether an external Commit can contain a joiner-originated
Remove proposal.  We have a spectrum of options here:

1. Forbid Remove
2. Allow Remove + require the (identity, endpoint_id) and signature key to
match the removed node + require resumption PSK
3. Allow Remove + require the (identity, endpoint_id) and signature key to
match the removed node
4. Allow Remove without restriction

Options (1) and (2) would block an attacker that has compromised a member's
signature key from joining as that member and evicting the old appearance.
Option (2) because of the PSK; option (1) because of the uniqueness
requirements (as Raphael pointed out on the call).

Options (1) and (2) do not allow a client who has lost everything but their
signature key to resync.  Option (1) would require a new endpoint_id and
signature key, which might not be feasible in all cases.  Option (2) would
also need to have extra mechanism to account for recent joiners not having
the required resumption PSK.

Option (1) would also not allow for resync with just a signature key.  As
Raphael pointed out, because we now require signature keys to be unique,
the member would have to mint a new signature key and get it authenticated,
or else their attempt to rejoin would be rejected as a duplicate entry.

Options (3) and (4) would allow a client who has lost everything but their
signature key to resync, at the risk that an attacker who has compromised a
member's signature key could abuse it to join as that member and evict the
old, legitimate appearance.

# Prognosis

After this discussion and analysis, I continue to think that (3) above is
the right answer, with an optional upgade to (2).  Proceeding by
elimination:

Option (4), while technically feasible, is clearly a little silly.  There's
no reason to allow joiners to do a remove in the same operation as they
join; they could do this afterward.

Option (2) does not seem workable in general because of the recent-joiner
problem.  While mechanism could be designed to provide the PSK to recent
joiners, it would add a lot of complexity, and the recent joiners wouldn't
get any benefit from it, which dilutes the value of this mechanism.  (It's
not impossible to arrive at the case where everyone besides the resync'ing
participant is new!)

With option (1), you lose any notion of resync; I think the need for
endpoint_id rotation makes this unworkable in practice.  And it has kind of
an odd notion of security: You are protected against an attacker that has
compromised a current signature key but can't get a new one authenticated.
This is a problem for the authentication system to handle (e.g., with
revocation), not for the key exchange -- if you have valid credentials with
compromised keys floating around, you have bigger problems to solve.  So my
personal assessment is that (1) doesn't provide a big jump in security over
(3), assuming you have a functioning authentication system.

Two side notes about (3): First, if we do (3) but *allow* PSKs, then an
application could opt in to (2).  Second, this whole mechanism is opt-in
for the application, since you can't do an external commit if a
PublicGroupState hasn't been published.

Concretely, my proposal here would be (3) + (2*) -- Allow Remove with
matching parameters, and allow PSKs so that applications can opt in to (2)
where they can make it work.  That way, if an application opts in to
external Commits, they get the benefit of resync and the same
signature-key-compromise bound on impersonation for resync as well as
net-new joins.  And if an application can figure out how to make (2) work,
they can require it.

Looking forward to others' thoughts here!

--RLB

[1]
https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm
[2] https://github.com/mlswg/mls-protocol/issues/92
[3] https://github.com/mlswg/mls-protocol/issues/93
[4]
https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202
[5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Tue, 5 Oct 2021 00:42:08 +0000

Richard,

[TL:DR (3) is not entirely dissimilar to the current security assumptions, but it is conditioned on ensuring that our current signature handling does not prevent rotating signature keys.]

Thank you for the summary and digging through the history. That takes time! The breakdown of options also provides a guiding point for the conversation.

Your investigation notes have jolted my memory to some extent, at least on the state of #336 and some WG decisions leading up to that. There was an interim call in April of 2020 where a slidedeck was presented with various proposal uses; discussion accompanying that slidedeck covered various security pros and cons for different uses. This was presented prior to the PR submission to allow for polishing. “Recovery” was the term applied at that point to refer to what is now being termed “resync”. There was push back at that interim call against recovery and consequently the recovery option was removed entirely; hence why it does not appear in the PR mentioned.

Unfortunately I do not recall the verbal reasons given for that removal and they are not in the minutes. @Konrad Kohbrok<mailto:[email-masked]> and I can take a look in the git repo on the edits leading up to the PR (and therefore the edits which removed recovery), but I am not sure how much that would elucidate. It was decided at the time that MLS should support a graceful restart of the whole group, but for one-off member desynchronization it would be sufficient to perform an add with PSK proof from a prior state. It was not decided what PSK lifetimes would be considered acceptable for this.

---

To the present proposed options, I will note that the ‘new joiners in interim’ case is likely a misleading focus point for the discussion, and we should avoid tripping into that ditch for a number of reasons:

  *   Notably, if everyone except for the re-syncing participant is new, why not just require the re-syncing participant to be added as a new member themselves? It is, after all, practically a brand new group at that point.
  *   It is true that a new member would not gain from a PSK guarantee, but why should we reduce the guarantees for all other participants to that of the new joiner? From the view of the new joiner, all participants are new in any case, so e.g. PCS does not have substantial meaning as of yet. Existing members have more to lose and also have the more to gain from PSK use. I do not believe we want to adapt a stance of ‘if the new joiner doesn’t get a security guarantee, no one should have the security guarantee’ – in fact, the tree structure, commit history, and the like provide insight to longer term members that a new joiner does not have. So (2) offers a new joiner the benefits of (3) but to all others an even stronger guarantee.
  *   As a nod to what a new joiner may gain, we can offer the following: if a re-sync PSK fails, then whichever existing member checks and notes the PSK failure should initiate a removal of the resyncing member. If there is a new joiner, then by continued presence of the re-syncing member they gain the guarantee that at least one other group member has previously seen that member, or else would have ejected them (assuming that the checker is online).

The security goal in the balance here is PCS. Adding a re-sync option of any of the varieties (2)-(4) would break that to some degree, since following a compromise and passive period the adversary is then enabled to regain a foothold. The question is how much of a degree of loss are we willing to tolerate.

  *   I agree that (4) is an immediate discard.
  *   Under (2) a PSK use, the PSK use at least more limited due to the proof of knowledge of a past state (e.g. notes above). This is a worthwhile property to enforce in my view since it balances authentication across two vectors: the signature key and knowledge of group state. Adversary access to only one or the other is insufficient for the adversary to eject Alice and replace her in the group.
  *   Under (3), the attack scenario of Eve compromising Alice (full state + sig key), followed eventually* by removing Alice while adding herself, is not dissimilar from the attack scenario of Eve compromising Alice full state + sig key) followed eventually* by providing an impersonating update in Alice’s name. What has been shown so far is that this type of scenario can be limited by rotating signature keys. A important point that is different in these scenarios is that under the first Alice knows she was removed (a plus) while under the second (currently possible) scenario the group simply goes silent and Alice does not know if it was malicious or not. All said, it could be worse. That does not consider other attack scenarios though, for example when the attacker gains the signature key but not past state/PSK.

*I.e. after a potentially passive period, if we are to show how this behaves in the PCS scenario.

This leads to an important question: does our current uniqueness of sig key predicate limit the ability to rotate signature keys within a group? That is our means of limiting the full state + sig key compromise scenario impacts mentioned above, and therefore the means of limiting the drawbacks of (3). We should make sure that the limiting ability is feasible. If that hindered in any way, then I would vote very strongly for (2) as it at least bootstraps some of the authentication properties from the group state in the scenario that the sig key is compromised.

All the best,

Britta

From: MLS <[email-masked]> on behalf of Richard Barnes <[email-masked]>
Date: Monday, October 4, 2021 at 4:09 PM
To: Messaging Layer Security WG <[email-masked]>
Subject: [MLS] Resync archaeology + analysis + prognosis

OK, I think I have traced back some idea of why we removed the earlier resync proposal.  Here's a little essay on how we got here, a recap of the trade-offs, and my thoughts on where we should go.

tl;dr: Earlier decision not dispositive; we should do basically what's in the PR now.

# History

The story starts all the way back at the January 2019 interim at Mozilla / Mountain View.  There was a discussion there of ACK/NACK and replay as related issues [1].  That discussion seems to have led to agreement that a complete error recovery system was a complex enough topic, and clearly enough separated from the main protocol that it could be handled in a separate specification.  As a result, the issues that had been opened for ACK/NACK and resync were closed [2][3].  When Britta and Konrad posted #336 [4] including a resync mechanism, my review simply cited that earlier closed issue as a reason for taking it out [5].

One other note with regard to #336 -- It looks to me like the "resync" mechanism in there was not really fleshed out enough to be implementable.  The state linked above was the last state before my review, and the word "resync" doesn't actually appear.  Instead the PR talks about "recovering lost group members" using Add and PSK, which could be elaborated to solve a version of this problem, but would require the assistance of a continuing member rather than allowing the lost member to resync unilaterally.  It would also have the same issues noted in terms of new joiners not having resync PSKs.

Overall, though, reading this history doesn't seem to me like we really made a principled decision not to do resync.  We just punted after some discussion in the abstract, and that stuck.  We have a more concrete question now.

# Analysis

Since the discussion of #336 in 2020, we have added external commits in order to have groups you can join unilaterally.  So regardless of the broader question of resync, we have to decide what proposals a joiner is allowed to originate in their Commit (sending them by value), in particular, whether an external Commit can contain a joiner-originated Remove proposal.  We have a spectrum of options here:

1. Forbid Remove
2. Allow Remove + require the (identity, endpoint_id) and signature key to match the removed node + require resumption PSK
3. Allow Remove + require the (identity, endpoint_id) and signature key to match the removed node
4. Allow Remove without restriction

Options (1) and (2) would block an attacker that has compromised a member's signature key from joining as that member and evicting the old appearance.  Option (2) because of the PSK; option (1) because of the uniqueness requirements (as Raphael pointed out on the call).

Options (1) and (2) do not allow a client who has lost everything but their signature key to resync.  Option (1) would require a new endpoint_id and signature key, which might not be feasible in all cases.  Option (2) would also need to have extra mechanism to account for recent joiners not having the required resumption PSK.

Option (1) would also not allow for resync with just a signature key.  As Raphael pointed out, because we now require signature keys to be unique, the member would have to mint a new signature key and get it authenticated, or else their attempt to rejoin would be rejected as a duplicate entry.

Options (3) and (4) would allow a client who has lost everything but their signature key to resync, at the risk that an attacker who has compromised a member's signature key could abuse it to join as that member and evict the old, legitimate appearance.

# Prognosis

After this discussion and analysis, I continue to think that (3) above is the right answer, with an optional upgade to (2).  Proceeding by elimination:

Option (4), while technically feasible, is clearly a little silly.  There's no reason to allow joiners to do a remove in the same operation as they join; they could do this afterward.

Option (2) does not seem workable in general because of the recent-joiner problem.  While mechanism could be designed to provide the PSK to recent joiners, it would add a lot of complexity, and the recent joiners wouldn't get any benefit from it, which dilutes the value of this mechanism.  (It's not impossible to arrive at the case where everyone besides the resync'ing participant is new!)

With option (1), you lose any notion of resync; I think the need for endpoint_id rotation makes this unworkable in practice.  And it has kind of an odd notion of security: You are protected against an attacker that has compromised a current signature key but can't get a new one authenticated.  This is a problem for the authentication system to handle (e.g., with revocation), not for the key exchange -- if you have valid credentials with compromised keys floating around, you have bigger problems to solve.  So my personal assessment is that (1) doesn't provide a big jump in security over (3), assuming you have a functioning authentication system.

Two side notes about (3): First, if we do (3) but *allow* PSKs, then an application could opt in to (2).  Second, this whole mechanism is opt-in for the application, since you can't do an external commit if a PublicGroupState hasn't been published.

Concretely, my proposal here would be (3) + (2*) -- Allow Remove with matching parameters, and allow PSKs so that applications can opt in to (2) where they can make it work.  That way, if an application opts in to external Commits, they get the benefit of resync and the same signature-key-compromise bound on impersonation for resync as well as net-new joins.  And if an application can figure out how to make (2) work, they can require it.

--RLB

[1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0>
[2] https://github.com/mlswg/mls-protocol/issues/92<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0>
[3] https://github.com/mlswg/mls-protocol/issues/93<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0>
[4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0>
[5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Oct 2021 22:31:31 -0400

Hi Britta,

Couple of responses inline...

On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <[email-masked]>
wrote:

> [trimmed]
>
>
>
> To the present proposed options, I will note that the ‘new joiners in
> interim’ case is likely a misleading focus point for the discussion, and we
> should avoid tripping into that ditch for a number of reasons:
>
>    - Notably, if everyone except for the re-syncing participant is new,
>    why not just require the re-syncing participant to be added as a new member
>    themselves? It is, after all, practically a brand new group at that point.
>    - It is true that a new member would not gain from a PSK guarantee,
>    but why should we reduce the guarantees for all other participants to that
>    of the new joiner? From the view of the new joiner, all participants are
>    new in any case, so e.g. PCS does not have substantial meaning as of yet.
>    Existing members have more to lose and also have the more to gain from PSK
>    use. I do not believe we want to adapt a stance of ‘if the new joiner
>    doesn’t get a security guarantee, no one should have the security
>    guarantee’ – in fact, the tree structure, commit history, and the like
>    provide insight to longer term members that a new joiner does not have. So
>    (2) offers a new joiner the benefits of (3) but to all others an even
>    stronger guarantee.
>    - As a nod to what a new joiner may gain, we can offer the following:
>    if a re-sync PSK fails, then whichever existing member checks and notes the
>    PSK failure should initiate a removal of the resyncing member. If there is
>    a new joiner, then by continued presence of the re-syncing member they gain
>    the guarantee that at least one other group member has previously seen that
>    member, or else would have ejected them (assuming that the checker is
>    online).
>
> I don't mean to over-rotate on this case, but software being software, we
need an algorithm to implement that covers all the cases.  While the
"everyone is new" scenario is outlandish, it wouldn't be all that
surprising to have one or two new members, so it's a case that would need
addressing.  The seemingly most obvious approach to addressing this problem
is to encrypt the PSK to new members, which requires you at least have
enough state to figure out who the new members are.

It also occurs to me now that the PSK approach presumes that you know when
your state went bad, since you would want to use a PSK from before that
point.  In Raphael's example where persistent storage is corrupted, all you
know is that messages stopped decrypting, which gives you an upper bound on
the time of corruption, but not really a way to go back and figure out
what's good.

The security goal in the balance here is PCS. Adding a re-sync option of
> any of the varieties (2)-(4) would break that to some degree, since
> following a compromise and passive period the adversary is then enabled to
> regain a foothold. The question is how much of a degree of loss are we
> willing to tolerate.
>

I'm not sure I would really characterize this as a PCS violation.  PCS is a
guarantee that you get when you take a certain action.  For example, when a
member issue an Update or a Commit with a fresh HPKE key pair, you should
get PCS with regard to that participant's HPKE key pair; likewise with
rotating signature keys.  Here, the signature key has not been rotated, so
there's no PCS boundary.

It is worth considering whether this mechanism gives the attacker any
additional capabilities in the event that (1) the signature key is
compromised, and (2) the compromised member issues an Update or Commit
rotating the signature key.  ISTM that you still get PCS there in option
(3), since the requirement that the signature keys match ensures that the
old, compromised signature key is not allowed to resync back into the
group.  There's still a risk that the compromised key / credential could be
used for a fresh, non-resync join, but that's an inherent risk with
external Commit / freely joinable groups, and also an opportunity for the
AS's revocation/invalidation system to help.

Will take a look at the remainder in the morning...

--RLB

>
>    - I agree that (4) is an immediate discard.
>    - Under (2) a PSK use, the PSK use at least more limited due to the
>    proof of knowledge of a past state (e.g. notes above). This is a worthwhile
>    property to enforce in my view since it balances authentication across two
>    vectors: the signature key and knowledge of group state. Adversary access
>    to only one or the other is insufficient for the adversary to eject Alice
>    and replace her in the group.
>    - Under (3), the attack scenario of Eve compromising Alice (full state
>    + sig key), followed eventually* by removing Alice while adding herself, is
>    not dissimilar from the attack scenario of Eve compromising Alice full
>    state + sig key) followed eventually* by providing an impersonating update
>    in Alice’s name. What has been shown so far is that this type of scenario
>    can be limited by rotating signature keys. A important point that is
>    different in these scenarios is that under the first Alice knows she was
>    removed (a plus) while under the second (currently possible) scenario the
>    group simply goes silent and Alice does not know if it was malicious or
>    not. All said, it could be worse. That does not consider other attack
>    scenarios though, for example when the attacker gains the signature key but
>    not past state/PSK.
>
>
>
> This leads to an important question: does our current uniqueness of sig
> key predicate limit the ability to rotate signature keys within a group?
> That is our means of limiting the full state + sig key compromise scenario
> impacts mentioned above, and therefore the means of limiting the drawbacks
> of (3). We should make sure that the limiting ability is feasible. If that
> hindered in any way, then I would vote very strongly for (2) as it at least
> bootstraps some of the authentication properties from the group state in
> the scenario that the sig key is compromised.
>
>
>
>
>
> All the best,
>
>
>
> Britta
>
>
>
>
>
>
>
> *From: *MLS <[email-masked]> on behalf of Richard Barnes <[email-masked]
> >
> *Date: *Monday, October 4, 2021 at 4:09 PM
> *To: *Messaging Layer Security WG <[email-masked]>
> *Subject: *[MLS] Resync archaeology + analysis + prognosis
>
>
>
> Options (1) and (2) would block an attacker that has compromised a
> member's signature key from joining as that member and evicting the old
> appearance.  Option (2) because of the PSK; option (1) because of the
> uniqueness requirements (as Raphael pointed out on the call).
>
> Options (1) and (2) do not allow a client who has lost everything but
> their signature key to resync.  Option (1) would require a new endpoint_id
> and signature key, which might not be feasible in all cases.  Option (2)
> would also need to have extra mechanism to account for recent joiners not
> having the required resumption PSK.
>
> Option (4), while technically feasible, is clearly a little silly.
> There's no reason to allow joiners to do a remove in the same operation as
> they join; they could do this afterward.
>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0>
> [4]
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0>
>

---

From: Konrad Kohbrok <[email-masked]>
Date: Wed, 6 Oct 2021 08:05:22 +0200 (CEST)

Hi,

If I understand correctly, the solutions (2) and (3) (discarding 1 and 4 for now) represent trade-offs in security guarantees and their applicability depends on the specific deployment scenario. My understanding is that external joins will be subject to some sort of policy anyway. Should we then be strict in the spec in terms of what we mandate the exact policy w.r.t. PSKs is? 

Since I don't think either solution represents much of a foot-gun, I propose we include the capability to include resync PSKs in the spec for this purpose, but don't mandate them. Instead we relegate the policy decision to the application layer and detail the security trade-offs in the architecture document. I realize that delegating decisions to the application layer is a bit of a cop-out solution, but I think in this case it makes sense to include the mechanism in the spec and then let the application decide.

Cheers,
Konrad

> Richard Barnes <[email-masked]> hat am 05.10.2021 04:31 geschrieben:
> 
> 
> Hi Britta,
> 
> On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <[email-masked]> wrote:
> > [trimmed]
> >  
> I don't mean to over-rotate on this case, but software being software, we need an algorithm to implement that covers all the cases. While the "everyone is new" scenario is outlandish, it wouldn't be all that surprising to have one or two new members, so it's a case that would need addressing. The seemingly most obvious approach to addressing this problem is to encrypt the PSK to new members, which requires you at least have enough state to figure out who the new members are.
> 
> It also occurs to me now that the PSK approach presumes that you know when your state went bad, since you would want to use a PSK from before that point. In Raphael's example where persistent storage is corrupted, all you know is that messages stopped decrypting, which gives you an upper bound on the time of corruption, but not really a way to go back and figure out what's good.
> 
> 
> I'm not sure I would really characterize this as a PCS violation. PCS is a guarantee that you get when you take a certain action. For example, when a member issue an Update or a Commit with a fresh HPKE key pair, you should get PCS with regard to that participant's HPKE key pair; likewise with rotating signature keys. Here, the signature key has not been rotated, so there's no PCS boundary.
> 
> It is worth considering whether this mechanism gives the attacker any additional capabilities in the event that (1) the signature key is compromised, and (2) the compromised member issues an Update or Commit rotating the signature key. ISTM that you still get PCS there in option (3), since the requirement that the signature keys match ensures that the old, compromised signature key is not allowed to resync back into the group. There's still a risk that the compromised key / credential could be used for a fresh, non-resync join, but that's an inherent risk with external Commit / freely joinable groups, and also an opportunity for the AS's revocation/invalidation system to help.
> 
> > From:MLS <[email-masked]> on behalf of Richard Barnes <[email-masked]>
> >  Date:Monday, October 4, 2021 at 4:09 PM
> >  To:Messaging Layer Security WG <[email-masked]>
> >  Subject:[MLS] Resync archaeology + analysis + prognosis
> >  
> >  [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0)
> >  [2] https://github.com/mlswg/mls-protocol/issues/92 (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0)
> >  [3] https://github.com/mlswg/mls-protocol/issues/93 (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0)
> >  [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202 (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0)
> >  [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0)

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Oct 2021 11:55:38 -0400

I've updated the PR to do basically what Konrad proposes.  Namely, allow
Remove, but suggest that applications can apply additional constraints.

https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873

Britta, does that work for you?

On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok <[email-masked]>
wrote:

> Hi,
>
> If I understand correctly, the solutions (2) and (3) (discarding 1 and 4
> for now) represent trade-offs in security guarantees and their
> applicability depends on the specific deployment scenario. My understanding
> is that external joins will be subject to some sort of policy anyway.
> Should we then be strict in the spec in terms of what we mandate the exact
> policy w.r.t. PSKs is?
>
> Since I don't think either solution represents much of a foot-gun, I
> propose we include the capability to include resync PSKs in the spec for
> this purpose, but don't mandate them. Instead we relegate the policy
> decision to the application layer and detail the security trade-offs in the
> architecture document. I realize that delegating decisions to the
> application layer is a bit of a cop-out solution, but I think in this case
> it makes sense to include the mechanism in the spec and then let the
> application decide.
>
> Cheers,
> Konrad
>
> > >   * Notably, if everyone except for the re-syncing participant is new,
> > >   * It is true that a new member would not gain from a PSK guarantee,
> > >   * As a nod to what a new joiner may gain, we can offer the
> following: if a re-sync PSK fails, then whichever existing member checks
> and notes the PSK failure should initiate a removal of the resyncing
> member. If there is a new joiner, then by continued presence of the
> re-syncing member they gain the guarantee that at least one other group
> member has previously seen that member, or else would have ejected them
> (assuming that the checker is online).
> > I don't mean to over-rotate on this case, but software being software,
> we need an algorithm to implement that covers all the cases. While the
> > It also occurs to me now that the PSK approach presumes that you know
> when your state went bad, since you would want to use a PSK from before
> that point. In Raphael's example where persistent storage is corrupted, all
> you know is that messages stopped decrypting, which gives you an upper
> bound on the time of corruption, but not really a way to go back and figure
> out what's good.
> >
> >
> > > The security goal in the balance here is PCS. Adding a re-sync option
> of any of the varieties (2)-(4) would break that to some degree, since
> > I'm not sure I would really characterize this as a PCS violation. PCS is
> a guarantee that you get when you take a certain action. For example, when
> a member issue an Update or a Commit with a fresh HPKE key pair, you should
> > >   * Under (2) a PSK use, the PSK use at least more limited due to the
> > >   * Under (3), the attack scenario of Eve compromising Alice (full
> state + sig key), followed eventually* by removing Alice while adding
> herself, is not dissimilar from the attack scenario of Eve compromising
> Alice full state + sig key) followed eventually* by providing an
> impersonating update in Alice’s name. What has been shown so far is that
> this type of scenario can be limited by rotating signature keys. A
> important point that is different in these scenarios is that under the
> first Alice knows she was removed (a plus) while under the second
> (currently possible) scenario the group simply goes silent and Alice does
> not know if it was malicious or not. All said, it could be worse. That does
> not consider other attack scenarios though, for example when the attacker
> gains the signature key but not past state/PSK.
> > >
> > > This leads to an important question: does our current uniqueness of
> sig key predicate limit the ability to rotate signature keys within a
> group? That is our means of limiting the full state + sig key compromise
> scenario impacts mentioned above, and therefore the means of limiting the
> drawbacks of (3). We should make sure that the limiting ability is
> feasible. If that hindered in any way, then I would vote very strongly for
> (2) as it at least bootstraps some of the authentication properties from
> the group state in the scenario that the sig key is compromised.
> > >
> > >
> > > All the best,
> > >
> > > Britta
> > >
> > >
> > >
> > >  The story starts all the way back at the January 2019 interim at
> Mozilla / Mountain View. There was a discussion there of ACK/NACK and
> replay as related issues [1]. That discussion seems to have led to
> agreement that a complete error recovery system was a complex enough topic,
> and clearly enough separated from the main protocol that it could be
> handled in a separate specification. As a result, the issues that had been
> opened for ACK/NACK and resync were closed [2][3]. When Britta and Konrad
> posted #336 [4] including a resync mechanism, my review simply cited that
> earlier closed issue as a reason for taking it out [5].
> > >
> > >  One other note with regard to #336 -- It looks to me like the
> "resync" mechanism in there was not really fleshed out enough to be
> implementable. The state linked above was the last state before my review,
> and the word "resync" doesn't actually appear. Instead the PR talks about
> "recovering lost group members" using Add and PSK, which could be
> elaborated to solve a version of this problem, but would require the
> assistance of a continuing member rather than allowing the lost member to
> resync unilaterally. It would also have the same issues noted in terms of
> new joiners not having resync PSKs.
> > >
> > >  Overall, though, reading this history doesn't seem to me like we
> really made a principled decision not to do resync. We just punted after
> some discussion in the abstract, and that stuck. We have a more concrete
> question now.
> > >
> > >  # Analysis
> > >
> > >  Since the discussion of #336 in 2020, we have added external commits
> in order to have groups you can join unilaterally. So regardless of the
> > >  2. Allow Remove + require the (identity, endpoint_id) and signature
> key to match the removed node + require resumption PSK
> > >  Option (1) would also not allow for resync with just a signature key.
> As Raphael pointed out, because we now require signature keys to be unique,
> > >  Options (3) and (4) would allow a client who has lost everything but
> their signature key to resync, at the risk that an attacker who has
> compromised a member's signature key could abuse it to join as that member
> and evict the old, legitimate appearance.
> > >
> > >  # Prognosis
> > >
> > >  After this discussion and analysis, I continue to think that (3)
> above is the right answer, with an optional upgade to (2). Proceeding by
> elimination:
> > >
> > >  Option (2) does not seem workable in general because of the
> recent-joiner problem. While mechanism could be designed to provide the PSK
> to recent joiners, it would add a lot of complexity, and the recent joiners
> wouldn't get any benefit from it, which dilutes the value of this
> mechanism. (It's not impossible to arrive at the case where everyone
> besides the resync'ing participant is new!)
> > >
> > >  Two side notes about (3): First, if we do (3) but *allow* PSKs, then
> an application could opt in to (2). Second, this whole mechanism is opt-in
> (
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0
> )
> > >  [2] https://github.com/mlswg/mls-protocol/issues/92 (
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0
> )
> > >  [3] https://github.com/mlswg/mls-protocol/issues/93 (
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0
> )
> > >  [4]
> (
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0
> )
> > >  [5]
> https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ (
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0
> )
>

---

From: Raphael Robert <[email-masked]>
Date: Wed, 6 Oct 2021 19:59:27 +0200

Thanks Richard for digging up all the past history!

I think the options you listed indeed cover all possibilities and I agree that (4) should be discarded right away. Option (1) would prohibit any resync mechanism based on external commits, so it’s obviously a non-starter for the discussion. Giving applications the choice between (2) and (3) generally sounds reasonable.

I would however like to point out that all of the options for “resync” are conditional on external commits being allowed (remember that they are generally optional) and that therefore the public group state needs to be available to clients at all times. This only covers a subset of the possible MLS deployment scenarios and therefore it is not a general resync mechanism. I want to emphasise this, because I feel we have lost sight of this somehow.

We can decide to leave it at that, bolstered by the sensible argument that external commits is the only mechanism that works unilaterally anyway. Alternatively, we could broaden the scope by also trying to address the scenarios where external commits are not possible/allowed. An argument in favour of it would be that if we don’t broaden it, applications will have to solve it anyway – possibly doing so by not making the best decisions.

In a scenario where external commits are not an option, members that are out-of-sync have no choice but to send an out-of-band distress message to the rest of the group and ask to be removed and subsequently re-added again. This is where we could offer some guidance at least. PSKs might still be an option here, additionally the distress message could be encrypted to a group key from a previous epoch.

I would be good to know how others feel about broadening the scope. 

Thanks

Raphael

> On 6. Oct 2021, at 17:55, Richard Barnes <[email-masked]> wrote:
> 
> I've updated the PR to do basically what Konrad proposes.  Namely, allow Remove, but suggest that applications can apply additional constraints.
> 
> https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873 <https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873>
> 
> On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> > Richard Barnes <[email-masked] <mailto:[email-masked]>> hat am 05.10.2021 04:31 geschrieben:
> > 
> > 
> > Hi Britta,
> > 
> > On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <[email-masked] <mailto:[email-masked]>> wrote:
> > > [trimmed]
> > >  
> > > From:MLS <[email-masked] <mailto:[email-masked]>> on behalf of Richard Barnes <[email-masked] <mailto:[email-masked]>>
> > >  To:Messaging Layer Security WG <[email-masked] <mailto:[email-masked]>>
> > >  [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm <https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0>)
> > >  [2] https://github.com/mlswg/mls-protocol/issues/92 <https://github.com/mlswg/mls-protocol/issues/92> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0>)
> > >  [3] https://github.com/mlswg/mls-protocol/issues/93 <https://github.com/mlswg/mls-protocol/issues/93> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0>)
> > >  [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202 <https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0>)
> > >  [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/ <https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0>)
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Oct 2021 13:22:24 -0400

Ok, it sounds like folks are pretty much on the same "2-plus-optional-3"
page.  I'll wait another day or two before merging to give a chance for any
more discussion.

Re: broadening scope -- Let's not.  Pretty much the only firm conclusion
out of that history research was WG consensus that a full resync solution
is a complex enough topic for another draft.  (And IMO would benefit from
some deployment experience with the base protocol.)  All we're talking
about here is how to cover a single resync case that is easily solved with
external commit.  That's not to say the problem isn't worth solving, just
that it's beyond the scope of the core protocol.

--RLB

On Wed, Oct 6, 2021 at 1:59 PM Raphael Robert <[email-masked]>
wrote:

> I think the options you listed indeed cover all possibilities and I agree
> that (4) should be discarded right away. Option (1) would prohibit any
> resync mechanism based on external commits, so it’s obviously a non-starter
> for the discussion. Giving applications the choice between (2) and (3)
> generally sounds reasonable.
>
> I would however like to point out that all of the options for “resync” are
> conditional on external commits being allowed (remember that they are
> generally optional) and that therefore the public group state needs to be
> available to clients at all times. This only covers a subset of the
> possible MLS deployment scenarios and therefore it is not a general resync
> mechanism. I want to emphasise this, because I feel we have lost sight of
> this somehow.
>
> We can decide to leave it at that, bolstered by the sensible argument that
> external commits is the only mechanism that works unilaterally anyway.
> Alternatively, we could broaden the scope by also trying to address the
> scenarios where external commits are not possible/allowed. An argument in
> favour of it would be that if we don’t broaden it, applications will have
> to solve it anyway – possibly doing so by not making the best decisions.
>
> In a scenario where external commits are not an option, members that are
> out-of-sync have no choice but to send an out-of-band distress message to
> the rest of the group and ask to be removed and subsequently re-added
> again. This is where we could offer some guidance at least. PSKs might
> still be an option here, additionally the distress message could be
> encrypted to a group key from a previous epoch.
>
> On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok <
> [email-masked]> wrote:
>
>> Hi,
>>
>> > >   * Notably, if everyone except for the re-syncing participant is
>> new, why not just require the re-syncing participant to be added as a new
>> member themselves? It is, after all, practically a brand new group at that
>> point.
>> > I'm not sure I would really characterize this as a PCS violation. PCS
>> is a guarantee that you get when you take a certain action. For example,
>> when a member issue an Update or a Commit with a fresh HPKE key pair, you
>> should get PCS with regard to that participant's HPKE key pair; likewise
>> with rotating signature keys. Here, the signature key has not been rotated,
>> so there's no PCS boundary.
>> >
>> > > OK, I think I have traced back some idea of why we removed the
>> earlier resync proposal. Here's a little essay on how we got here, a recap
>> of the trade-offs, and my thoughts on where we should go.
>> > >
>> > >  Options (1) and (2) do not allow a client who has lost everything
>> but their signature key to resync. Option (1) would require a new
>> endpoint_id and signature key, which might not be feasible in all cases.
>> Option (2) would also need to have extra mechanism to account for recent
>> joiners not having the required resumption PSK.
>> > >
>> > >  Option (1) would also not allow for resync with just a signature
>> key. As Raphael pointed out, because we now require signature keys to be
>> unique, the member would have to mint a new signature key and get it
>> authenticated, or else their attempt to rejoin would be rejected as a
>> duplicate entry.
>> > >
>> > >  Concretely, my proposal here would be (3) + (2*) -- Allow Remove
>> with matching parameters, and allow PSKs so that applications can opt in to
>> (2) where they can make it work. That way, if an application opts in to

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Thu, 7 Oct 2021 17:46:04 +0000

That sounds reasonable to me as a way forward.

The question posed before (“This leads to an important question: does our current uniqueness of sig key predicate limit the ability to rotate signature keys within a group? That … [is what limits] the drawbacks of (3).”) still stands. I do not think this inhibits moving forward with the PR, but it is important to address. If there is a trade-off between an implementation allowing remove+resync and rotating out signature keys, then that should be noted in the architecture document if not the protocol spec itself. We are not going to go through all the possible options for implementation, but when there is significant space in the protocol spec devoted to an optional functionality (e.g. external commits and resync) then it would be good to note trade-offs that will come with it. We would not have a well-written specification if it could potentially lead an implementor far down one optional path that precludes desired security guarantees, and gives no context on that (i.e. let’s try to minimize obvious cases of “I wish I had known…” for implementors).

Britta

From: Richard Barnes <[email-masked]>
Date: Wednesday, October 6, 2021 at 8:55 AM
To: Konrad Kohbrok <[email-masked]>
Cc: "Hale, Britta (CIV)" <[email-masked]>, Messaging Layer Security WG <[email-masked]>
Subject: Re: [MLS] Resync archaeology + analysis + prognosis

https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F481%2Ffiles%23diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549319483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=01mtq0KS3FDnZZ1JyygD8RXKo9N61BwdlUYuq%2FxOsQo%3D&reserved=0>

On Wed, Oct 6, 2021 at 2:05 AM Konrad Kohbrok <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Cheers,
Konrad

> Richard Barnes <[email-masked]<mailto:[email-masked]>> hat am 05.10.2021 04:31 geschrieben:
>
>
> Hi Britta,
>
> On Mon, Oct 4, 2021 at 8:42 PM Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:
> > [trimmed]
> >
> > From:MLS <[email-masked]<mailto:[email-masked]>> on behalf of Richard Barnes <[email-masked]<mailto:[email-masked]>>
> >  To:Messaging Layer Security WG <[email-masked]<mailto:[email-masked]>>
> >  [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549329477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WkyZ5IcB5Kftd4hJjnneW%2F4QEgc3zYrdP4leod%2BKYmI%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549339474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zCGp0xQsGQPiYN9BqsHA9JG%2FF8maQhm4eUOURAfbGHo%3D&reserved=0>)
> >  [2] https://github.com/mlswg/mls-protocol/issues/92<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549339474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zu5JJjXBKOPrrxU779xFBI8pST1XmUsx7kBFfBcDDnQ%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549349464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z7GdiBVN7bUKUKF62W6K5o%2FGMAZLNyeYNStBeusk7jY%3D&reserved=0>)
> >  [3] https://github.com/mlswg/mls-protocol/issues/93<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549349464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8A%2BW7ZVJikyIFdA%2BONW%2BJz9B1j5M8Wz1%2F4EGb2LwmQc%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549359460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4s%2FUgRViLPkX6BUcqBHPxBDkuetjD7MuLLFy4jmBVnU%3D&reserved=0>)
> >  [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549359460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1nJyVcCdqXIzXGoQAUpXhBuxfQ%2FjMCwxFa6dNSB%2B8dA%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549369456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wvg9BE8QuksoGuYVZsD279qzxGud706Fj%2BLBRAO1noA%3D&reserved=0>)
> >  [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549369456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eUwVmSssNjAAE9xpJqyguqSbHM7CThmkJhz9yi7wFTM%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549379445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kPxZ1hiHfcv%2FTtZsSHknga2zKxna6Cgkbi5m6%2BzvoDY%3D&reserved=0>)

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Oct 2021 13:57:27 -0400

(Changing subject line because we're diverging a little...)

Hi Britta,

Could you explain a little more how you think the uniqueness requirements
could make it more difficult to rotate signature keys?

It doesn't seem to me like there's really any interaction between signature
key rotation and either external commit or signature key uniqueness
requirements.  The only intersection is that the requirement that a resync
operation have the same signature key means that you can't rotate the
signature key at the same time that you resync.  However, you could send a
second commit rotating the signature key immediately after.

--Richard

On Thu, Oct 7, 2021 at 1:46 PM Hale, Britta (CIV) <[email-masked]>
wrote:

> The question posed before (“This leads to an important question: does our
> current uniqueness of sig key predicate limit the ability to rotate
> signature keys within a group? That … [is what limits] the drawbacks of
> (3).”) still stands. I do not think this inhibits moving forward with the
> PR, but it is important to address. If there is a trade-off between an
> implementation allowing remove+resync and rotating out signature keys, then
> that should be noted in the architecture document if not the protocol spec
> itself. We are not going to go through all the possible options for
> implementation, but when there is significant space in the protocol spec
> devoted to an optional functionality (e.g. external commits and resync)
> then it would be good to note trade-offs that will come with it. We would
> not have a well-written specification if it could potentially lead an
> implementor far down one optional path that precludes desired security
> guarantees, and gives no context on that (i.e. let’s try to minimize
> obvious cases of “I wish I had known…” for implementors).
>
>
>
> Britta
>
>
>
>
>
> *From: *Richard Barnes <[email-masked]>
> *Date: *Wednesday, October 6, 2021 at 8:55 AM
> *To: *Konrad Kohbrok <[email-masked]>
> *Cc: *"Hale, Britta (CIV)" <[email-masked]>, Messaging Layer
> Security WG <[email-masked]>
> *Subject: *Re: [MLS] Resync archaeology + analysis + prognosis
>
>
>
>
>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F481%2Ffiles%23diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549319483%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=01mtq0KS3FDnZZ1JyygD8RXKo9N61BwdlUYuq%2FxOsQo%3D&reserved=0>
>
>
>
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549329477%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WkyZ5IcB5Kftd4hJjnneW%2F4QEgc3zYrdP4leod%2BKYmI%3D&reserved=0>
> (
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549339474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zCGp0xQsGQPiYN9BqsHA9JG%2FF8maQhm4eUOURAfbGHo%3D&reserved=0>
> )
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549339474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zu5JJjXBKOPrrxU779xFBI8pST1XmUsx7kBFfBcDDnQ%3D&reserved=0>
> (
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549349464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z7GdiBVN7bUKUKF62W6K5o%2FGMAZLNyeYNStBeusk7jY%3D&reserved=0>
> )
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549349464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8A%2BW7ZVJikyIFdA%2BONW%2BJz9B1j5M8Wz1%2F4EGb2LwmQc%3D&reserved=0>
> (
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549359460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4s%2FUgRViLPkX6BUcqBHPxBDkuetjD7MuLLFy4jmBVnU%3D&reserved=0>
> )
> > >  [4]
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549359460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1nJyVcCdqXIzXGoQAUpXhBuxfQ%2FjMCwxFa6dNSB%2B8dA%3D&reserved=0>
> (
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549369456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wvg9BE8QuksoGuYVZsD279qzxGud706Fj%2BLBRAO1noA%3D&reserved=0>
> )
> > >  [5]
> https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549369456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eUwVmSssNjAAE9xpJqyguqSbHM7CThmkJhz9yi7wFTM%3D&reserved=0>
> (
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C00c30bc5d58744cc199008d988e1c533%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637691325549379445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kPxZ1hiHfcv%2FTtZsSHknga2zKxna6Cgkbi5m6%2BzvoDY%3D&reserved=0>
> )
>
>

---

From: "Hale, Britta (CIV)" <[email-masked]>
Date: Tue, 12 Oct 2021 15:46:02 +0000

Certainly, Richard.

The uniqueness requirement limits one key to each user. Under an Add, the credential identity (not just credential) must be unique and different from others already in the group. External Commits also disallow a remove+add under a different credential (which is a good thing). This begs the question though of how to rotate out signature keys. It seems that the way to do this would be for the member to propose to remove themselves and re-add (using the updated credential) as one action – otherwise, it is not clear how rotating signature keys can be smoothly performed while not interfering with the other restrictions.

Given the various features that have been added during recent changes and credential/identity restrictions on them (e.g. External Commits), I propose that we clearly delineate in the draft how rolling a member’s credential may be performed. The draft is approaching the point where it states a multitude of ways that action may not be done, but does not give direction on how it may be done.

Britta

From: Richard Barnes <[email-masked]>
Date: Thursday, October 7, 2021 at 10:57 AM
To: "Hale, Britta (CIV)" <[email-masked]>
Cc: Konrad Kohbrok <[email-masked]>, Messaging Layer Security WG <[email-masked]>
Subject: Signature key uniqueness and rotation (Re: [MLS] Resync archaeology + analysis + prognosis)

Hi Britta,

Could you explain a little more how you think the uniqueness requirements could make it more difficult to rotate signature keys?

It doesn't seem to me like there's really any interaction between signature key rotation and either external commit or signature key uniqueness requirements.  The only intersection is that the requirement that a resync operation have the same signature key means that you can't rotate the signature key at the same time that you resync.  However, you could send a second commit rotating the signature key immediately after.

--Richard

On Thu, Oct 7, 2021 at 1:46 PM Hale, Britta (CIV) <[email-masked]<mailto:[email-masked]>> wrote:
That sounds reasonable to me as a way forward.

Britta

From: Richard Barnes <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 6, 2021 at 8:55 AM
To: Konrad Kohbrok <[email-masked]<mailto:[email-masked]>>
Cc: "Hale, Britta (CIV)" <[email-masked]<mailto:[email-masked]>>, Messaging Layer Security WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MLS] Resync archaeology + analysis + prognosis

https://github.com/mlswg/mls-protocol/pull/481/files#diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F481%2Ffiles%23diff-7c369b85b26a746a7e70cd2884037896defe03b3098bec976f79c994d22a604aR2873&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639702298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yO07Ro375CvtEUP80fZMV20yGe99XJz33vSFcjV86Y4%3D&reserved=0>

Cheers,
Konrad

> >  [1] https://github.com/mlswg/wg-materials/blob/main/interim-2019-01/minutes.md#acks-and-nacks-jonm<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639702298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1upcBXSI3p3jYM8r40xuN7O2gvYPcL3%2FV8XFnLqQRBw%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931844808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BEprQMOVk%2BINhdtRxHL5JfGQ%2FeP6tCFvcAM3uopMFq4%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fwg-materials%2Fblob%2Fmain%2Finterim-2019-01%2Fminutes.md%23acks-and-nacks-jonm&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639712292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aDU5gBQrLt4KVIvl9goY0l7C6xIMW8BS7BYsObErFmQ%3D&reserved=0>)
> >  [2] https://github.com/mlswg/mls-protocol/issues/92<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639712292%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BlL5CFtawFK3RATPZNwhG%2FmlsrFKMCWC1BFobimknCo%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lFeYwyHCGZlsHz%2BO2cVPG7eUTUjzoLhzQ0fniz%2Fblmc%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F92&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639722279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PbEKhJccRD6xdmOMmIYLvpEQotoub8fcCNPRoSDRkUo%3D&reserved=0>)
> >  [3] https://github.com/mlswg/mls-protocol/issues/93<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639732277%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y6M0hrHyRIpFPJCn8tbCxuIKKlH%2FwM8IKUIb2BTf8UE%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931854800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zpW%2BCQz%2BeEwklYbp4NQmFcUeHBGmAh0jKBRC05CyVBs%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fissues%2F93&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639732277%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y6M0hrHyRIpFPJCn8tbCxuIKKlH%2FwM8IKUIb2BTf8UE%3D&reserved=0>)
> >  [4] https://github.com/mlswg/mls-protocol/pull/336/files/20145e49acce01dcedca7db2d05c57908a292202<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639742268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Y%2Blxi18MXmtBWTYMIq6ydigW37eKJHuel%2BL4zivxws%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931864794%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0OgVddc%2BIzju61MwfQFNiYjejZINtrIqf08CkIgGm%2BQ%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmlswg%2Fmls-protocol%2Fpull%2F336%2Ffiles%2F20145e49acce01dcedca7db2d05c57908a292202&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639742268%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8Y%2Blxi18MXmtBWTYMIq6ydigW37eKJHuel%2BL4zivxws%3D&reserved=0>)
> >  [5] https://mailarchive.ietf.org/arch/msg/mls/Hs_nAX3luDjiQ4mIwkiKu1CFSAE/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639752271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fI74PJEU13We09RjCr5HWnIc6feYC4iFLBB8jhB23jg%3D&reserved=0> (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7C1ebf96c30cc44fc96e1d08d9878bb6b5%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637689857931874789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=moUAZJ3tOAhFI%2BMMFq99B111wJpxBRBwbRPYs5lDxC0%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fmls%2FHs_nAX3luDjiQ4mIwkiKu1CFSAE%2F&data=04%7C01%7Cbritta.hale%40nps.edu%7Cff729a0e25f24af7285a08d989bbf502%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637692262639752271%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fI74PJEU13We09RjCr5HWnIc6feYC4iFLBB8jhB23jg%3D&reserved=0>)