i assume that was audible
", "time": "2023-09-28T19:01:48Z"}, {"author": "Tim Geoghegan", "text": "Yes, it was
", "time": "2023-09-28T19:01:55Z"}, {"author": "Basel Alnaffouri", "text": "I can hear it
", "time": "2023-09-28T19:02:14Z"}, {"author": "Tim Geoghegan", "text": "https://notes.ietf.org/notes-ietf-interim-2023-mimi-08-mimi#
", "time": "2023-09-28T19:03:39Z"}, {"author": "Tim Geoghegan", "text": "Thanks Matthew!
", "time": "2023-09-28T19:03:44Z"}, {"author": "Andrew Morgan", "text": "we can hear you
", "time": "2023-09-28T19:04:56Z"}, {"author": "Benjamin Beurdouche", "text": "MLS Arch 3.6:\"A group in
\n MLS is defined as the set of clients that have knowledge of the
\n shared group secret established in the group key establishment phase
\n of the protocol and have contributed to it.\"
Note that the contribution part is the thing that can be considered the consent
", "time": "2023-09-28T19:20:57Z"}, {"author": "Konrad Kohbrok", "text": "Hm. But then a client that has been added to a group is only a member after it has made a commit?
", "time": "2023-09-28T19:22:20Z"}, {"author": "Konrad Kohbrok", "text": "Or does the KeyPackage cound as a contribution?
", "time": "2023-09-28T19:22:36Z"}, {"author": "Konrad Kohbrok", "text": "count*
", "time": "2023-09-28T19:22:43Z"}, {"author": "Benjamin Beurdouche", "text": "Well technically you have the secrets so you are in the group... We have this annoyance that there is no notion of consent, so we had a long discussion about the fact that updating acts as a consent.
", "time": "2023-09-28T19:23:57Z"}, {"author": "Benjamin Beurdouche", "text": "Maybe we should clarify by using pending/unconfirmed member in contrast to full member
", "time": "2023-09-28T19:24:29Z"}, {"author": "Eric Rescorla", "text": "The point Benjamin is making above is what I was referring to.
", "time": "2023-09-28T19:25:06Z"}, {"author": "Konrad Kohbrok", "text": "I would argue that in the context of MLS, that's not a very meaningful distinction, is it? Either you have the key material or you don't.
", "time": "2023-09-28T19:25:17Z"}, {"author": "Eric Rescorla", "text": "As I said, it's a technicality.
", "time": "2023-09-28T19:25:24Z"}, {"author": "Konrad Kohbrok", "text": "There is no notion of consent in MLS, is there? I agree that it makes sense in the context of MIMI.
", "time": "2023-09-28T19:25:44Z"}, {"author": "Benjamin Beurdouche", "text": "It is a lawyer thing more than a technical thing.
", "time": "2023-09-28T19:26:01Z"}, {"author": "Benjamin Beurdouche", "text": "If I add you to my anarchist group, did you accept?
", "time": "2023-09-28T19:26:17Z"}, {"author": "Benjamin Beurdouche", "text": "I will probably propose unconfirmed member vs confirmed member
", "time": "2023-09-28T19:27:08Z"}, {"author": "Konrad Kohbrok", "text": "Ah, so you're saying that we need to be careful what we say in the MLS arch doc, because people might get the wrong idea?
", "time": "2023-09-28T19:27:23Z"}, {"author": "Benjamin Beurdouche", "text": "correct
", "time": "2023-09-28T19:27:33Z"}, {"author": "Konrad Kohbrok", "text": "I understand. I still think that it should be punted to the application layer. That's worked well in the past ;-)
\nBut I guess we're off MIMI topic here.
What I meant when I said \"this is a technicality\" is merely \"if we are going to refer to someone being an inactive or active in the room and that's contingent on MLS membership\" then we need to be very sharp on what MLS membership is
", "time": "2023-09-28T19:31:48Z"}, {"author": "Eric Rescorla", "text": "Is it possible that one could be in a state where it is not possible to verify that someone was removed
", "time": "2023-09-28T19:32:15Z"}, {"author": "Eric Rescorla", "text": "I do want to respond to this point
", "time": "2023-09-28T19:32:55Z"}, {"author": "Konrad Kohbrok", "text": "Good point. I for one was not aware that MLS \"membership\" depended on some form of consent.
", "time": "2023-09-28T19:33:13Z"}, {"author": "Benjamin Beurdouche", "text": "https://github.com/mlswg/mls-architecture/issues/205
", "time": "2023-09-28T19:33:45Z"}, {"author": "Eric Rescorla", "text": "I feel like this diagram is not intended as a factual statement\"
", "time": "2023-09-28T19:38:07Z"}, {"author": "Eric Rescorla", "text": "Fundamentally these systems just aren't negotiation systems the same way that (say) TLS is in that it's not like counterparties negotiate on an interaction by interaction basis which protocol they use
", "time": "2023-09-28T19:45:51Z"}, {"author": "Konrad Kohbrok", "text": "Fair enough. I meant more in the way that MLS is \"negotiating\" via KeyPackages, etc.
", "time": "2023-09-28T19:46:33Z"}, {"author": "Eric Rescorla", "text": "@Konrad: 100%
", "time": "2023-09-28T19:46:42Z"}, {"author": "Tim Geoghegan", "text": "+1 to ekr, especially since all these docs are in the same WG
", "time": "2023-09-28T19:50:26Z"}, {"author": "Daniel Gillmor", "text": "+1 for re-combining documents where we can
", "time": "2023-09-28T19:50:33Z"}, {"author": "Konrad Kohbrok", "text": "One reason to have at least the DS as a separate document is that it might serve as a blueprint for others who want to use MLS outside the MIMI context, where they might not need any notion of users, but still need a DS to use MLS.
", "time": "2023-09-28T19:53:40Z"}, {"author": "Eric Rescorla", "text": "Well, I think they can reference it
", "time": "2023-09-28T19:54:55Z"}, {"author": "Benjamin Beurdouche", "text": "Ideally having something self contained for platforms to implement would be nice if we can instead of having to look into some beast document. The DS is actually a good example.
", "time": "2023-09-28T19:58:26Z"}, {"author": "Eric Rescorla", "text": "I'm sensitive to the notion of composability, but I'm just saying trying to read all these drafts together is very difficult.
", "time": "2023-09-28T19:58:37Z"}, {"author": "Eric Rescorla", "text": "And the priority of this WG is to deliver something implementable
", "time": "2023-09-28T19:59:03Z"}, {"author": "Benjamin Beurdouche", "text": "Fair enough, we can always let the apps implement the MIMI layer.
", "time": "2023-09-28T19:59:36Z"}, {"author": "Benjamin Beurdouche", "text": "Hmm, that's not possible at the MLS layer right ?
", "time": "2023-09-28T20:04:27Z"}, {"author": "Richard Barnes", "text": "i suspect it's just a convenience / hygeine thing, avoiding things getting wedged
", "time": "2023-09-28T20:06:55Z"}, {"author": "Richard Barnes", "text": "... in exactly the way Konrad says
", "time": "2023-09-28T20:07:21Z"}, {"author": "Eric Rescorla", "text": "Thank you.
", "time": "2023-09-28T20:07:21Z"}, {"author": "Benjamin Beurdouche", "text": "The intuition is that the policy to apply commits at the hub is the same as any other client
", "time": "2023-09-28T20:07:34Z"}, {"author": "Benjamin Beurdouche", "text": "Otherwise you can diverge
", "time": "2023-09-28T20:07:43Z"}, {"author": "Benjamin Beurdouche", "text": "But there is nothing else it can do than DOS the group
", "time": "2023-09-28T20:07:55Z"}, {"author": "Richard Barnes", "text": "one way to view the enforcement -- the hub should reject commits that it knows the clients will reject. if clients are enforcing that the commit confirms the current state and a commit doesn't, then the hub should reject it.
", "time": "2023-09-28T20:09:17Z"}, {"author": "Eric Rescorla", "text": "Naively the cut I would want to draw is \"The hub is responsible for ensuring that correctly functioning clients converge on a state\"
", "time": "2023-09-28T20:09:46Z"}, {"author": "Eric Rescorla", "text": "But \"The hub is not responsible for preventing group partition if a client is malicious\"
", "time": "2023-09-28T20:09:55Z"}, {"author": "Konrad Kohbrok", "text": "+1
", "time": "2023-09-28T20:10:03Z"}, {"author": "Richard Barnes", "text": "sgtm
", "time": "2023-09-28T20:10:12Z"}, {"author": "Daniel Gillmor", "text": "seems to me that the more the hub is obliged to keep some sort of state that is synchronized with client state, the more the metadata of the conversation will leak to the hub. i'd say that means we want to minimzethe amount of enforcement that happens on the hub.
", "time": "2023-09-28T20:10:23Z"}, {"author": "Eric Rescorla", "text": "My loose memory is that we need the hub to do some enforcement to ensure correct function
", "time": "2023-09-28T20:11:23Z"}, {"author": "Andrew Morgan", "text": "note that if you hit page-down in pdf.js, you'll go one slide down without needing to scroll manually
", "time": "2023-09-28T20:11:43Z"}, {"author": "Konrad Kohbrok", "text": "The mute button is greyed out :-(
", "time": "2023-09-28T20:11:44Z"}, {"author": "Richard Barnes", "text": "@EKR note that the scheme here is a lot like what you proposed, where the hub proposes to remove Bob's devices
", "time": "2023-09-28T20:11:50Z"}, {"author": "Konrad Kohbrok", "text": "Please go ahead!
", "time": "2023-09-28T20:11:53Z"}, {"author": "Eric Rescorla", "text": "@Richard: thanks
", "time": "2023-09-28T20:12:07Z"}, {"author": "Basel Alnaffouri", "text": "I think as a guiding principle we probably want to have simpler clients and do more heavy lifting on the server (in secure/private way)
", "time": "2023-09-28T20:12:58Z"}, {"author": "Richard Barnes", "text": "well, also this WG is only chartered to do S2S stuff :)
", "time": "2023-09-28T20:13:44Z"}, {"author": "Basel Alnaffouri", "text": ":grinning:
", "time": "2023-09-28T20:13:58Z"}, {"author": "Richard Barnes", "text": "the phrase \"jump ball\" always comes to mind when it's not clear who should commit, but i wasn't sure if the reference would be clear https://en.wikipedia.org/wiki/Jump_ball
", "time": "2023-09-28T20:17:15Z"}, {"author": "Daniel Gillmor", "text": "thanks for the clarification for those of us who aren't up to speed on sportsball, @Richard Barnes
", "time": "2023-09-28T20:18:16Z"}, {"author": "Benjamin Beurdouche", "text": "The case of two concurrent Remove+Commit is interesting since one will be rejected. In that case the Server should propose and enforce that someone else commits the second removal in the next epoch.
", "time": "2023-09-28T20:19:08Z"}, {"author": "Richard Barnes", "text": "The fact that MLS Proposals are specific to an epoch is both inevitable and unfortunate
", "time": "2023-09-28T20:21:16Z"}, {"author": "Daniel Gillmor", "text": "can someone remind me why the hub needs to know the difference between the participant and their specific clients? (especially for participants who are not native/local to the hub)
", "time": "2023-09-28T20:22:44Z"}, {"author": "Eric Rescorla", "text": "\n", "time": "2023-09-28T20:22:57Z"}, {"author": "Eric Rescorla", "text": "The fact that MLS Proposals are specific to an epoch is both inevitable and unfortunateNot with that attitude
\n
\n", "time": "2023-09-28T20:23:13Z"}, {"author": "Eric Rescorla", "text": "The fact that MLS Proposals are specific to an epoch is both inevitable and unfortunateNot with that attitue
\n
Argh
", "time": "2023-09-28T20:23:17Z"}, {"author": "Daniel Gillmor", "text": "go back to IRC, ekr
", "time": "2023-09-28T20:23:37Z"}, {"author": "Travis Ralston", "text": "@Daniel: it's largely to allow a \"user with zero clients, but doesn't want to go find Alice to get them to send another invite\" case.
", "time": "2023-09-28T20:24:37Z"}, {"author": "Travis Ralston", "text": "The hub doesn't realistically need to track the clients themselves: just ensuring at time of Add that the associated user is participating in the room.
", "time": "2023-09-28T20:25:24Z"}, {"author": "Daniel Gillmor", "text": "@Travis Ralston it seems like overkill for this particular purpose
", "time": "2023-09-28T20:25:55Z"}, {"author": "Konrad Kohbrok", "text": "Daniel Gillmor said:
\n\n\ncan someone remind me why the hub needs to know the difference between the participant and their specific clients? (especially for participants who are not native/local to the hub)
\n
MLS is interested in what clients (represented by their key material) are in the room and needs to track them for authentication purposes and to allow external commits, i.e. to allow new clients to add themselves to the group.
", "time": "2023-09-28T20:26:13Z"}, {"author": "Konrad Kohbrok", "text": "There are means to reduce the metadata footprint, though. We plan on proposing those once we have established agreement on generally how the flows work.
", "time": "2023-09-28T20:26:47Z"}, {"author": "Eric Rescorla", "text": "I wasn't on the design team!
", "time": "2023-09-28T20:28:07Z"}, {"author": "Daniel Gillmor", "text": "My understanding of MLS is that it is flexible enough to have \"server responsible separating out the different clients for a given participant\" as well as \"participants manage their own clients without knowledge from the server\". i want to make sure that latter approach is still maintained in MIMI, because i don't think the servers need to know in principle about different clients.
", "time": "2023-09-28T20:28:50Z"}, {"author": "Eric Rescorla", "text": "Like if I were the person writing, it would be one document!
", "time": "2023-09-28T20:29:05Z"}, {"author": "Daniel Gillmor", "text": "multiple documents is harder from the consumer view as well, not just the producer as Tim describes.
", "time": "2023-09-28T20:30:24Z"}, {"author": "Daniel Gillmor", "text": "generic MLS DS seems distinct from a DS that is capable of handling the federated DS.
", "time": "2023-09-28T20:31:58Z"}, {"author": "Richard Barnes", "text": "fwiw, people refer to the TLS presentation syntax all the time, without it being separate from RFC 8446
", "time": "2023-09-28T20:32:25Z"}, {"author": "Benjamin Beurdouche", "text": "I don't particularly care about the number of docs as long as we have a selfcontained section for the DS
", "time": "2023-09-28T20:33:07Z"}, {"author": "Daniel Gillmor", "text": "@Benjamin Beurdouche agreed that there should be a clear section delimiter :stuck_out_tongue:
", "time": "2023-09-28T20:33:47Z"}, {"author": "Eric Rescorla", "text": "I think the standard here is \"Can I make sense of the document I am reading with only a cursory understanding of the other document\"
", "time": "2023-09-28T20:34:01Z"}, {"author": "Eric Rescorla", "text": "Which, BTW, is also the standard for componentization in a single document. I.e., clear interfaces, information hiding, etc.
", "time": "2023-09-28T20:34:34Z"}, {"author": "Eric Rescorla", "text": "+1 to Alissa
", "time": "2023-09-28T20:34:44Z"}, {"author": "Eric Rescorla", "text": "I also agree with this.
", "time": "2023-09-28T20:35:55Z"}, {"author": "Konrad Kohbrok", "text": "Daniel Gillmor said:
\n\n\nMy understanding of MLS is that it is flexible enough to have \"server responsible separating out the different clients for a given participant\" as well as \"participants manage their own clients without knowledge from the server\". i want to make sure that latter approach is still maintained in MIMI, because i don't think the servers need to know in principle about different clients.
\n
Yes, there is a way to \"hide\" a user's clients underneath a leaf s.t. each leaf represents a user rather than a client. But as far as I'm aware, there are some kinks to be ironed out for that to work. I'm not aware of anyone using MLS using that particular way of representing users. I'm not against it, but we should be sure that we know it actually works and how. Specifically, clients need to synchronize their state very well. But they might have to do synchronize user-level state anyway.
", "time": "2023-09-28T20:37:05Z"}, {"author": "Richard Barnes", "text": "200-page document, here we come!
", "time": "2023-09-28T20:38:01Z"}, {"author": "Richard Barnes", "text": "homework for the DT: read RFC 9000 / 9001
", "time": "2023-09-28T20:38:48Z"}, {"author": "Travis Ralston", "text": "(tabs have been opened)
", "time": "2023-09-28T20:39:33Z"}, {"author": "Richard Barnes", "text": "salient \"TLS-shaped hole\" section: https://bifurcation.github.io/qrfc/rfcs/rfc9000.html#section-7
", "time": "2023-09-28T20:39:33Z"}, {"author": "Richard Barnes", "text": "fun fact, the K in EKR is for \"Kombine all the documents\"
", "time": "2023-09-28T20:41:54Z"}, {"author": "Eric Rescorla", "text": "It kind of is
", "time": "2023-09-28T20:42:58Z"}, {"author": "Benjamin Beurdouche", "text": "All good :+1:
", "time": "2023-09-28T20:44:02Z"}, {"author": "Richard Barnes", "text": "that schedule sgtm
", "time": "2023-09-28T20:44:40Z"}, {"author": "Benjamin Beurdouche", "text": "Bye
", "time": "2023-09-28T20:45:29Z"}, {"author": "Daniel Gillmor", "text": "thanks all! bye
", "time": "2023-09-28T20:45:31Z"}]