[{"author": "Nick Doty", "text": "

do remote participants have a way of getting cute mimi stickers?

", "time": "2023-07-26T16:35:15Z"}, {"author": "Tim Geoghegan", "text": "

I'd love to mail them out but I'm not sure if IETF provides stamps

", "time": "2023-07-26T16:36:31Z"}, {"author": "Mallory Knodel", "text": "

Nick Doty said:

\n
\n

do remote participants have a way of getting cute mimi stickers?

\n
\n

I got you

", "time": "2023-07-26T16:38:43Z"}, {"author": "Phillip Hallam-Baker", "text": "

Can I get a sticker?

", "time": "2023-07-26T16:40:30Z"}, {"author": "Alissa Cooper", "text": "

You can get them from the chairs' table after the session ends.

", "time": "2023-07-26T16:40:51Z"}, {"author": "Phillip Hallam-Baker", "text": "

Thanks

", "time": "2023-07-26T16:41:02Z"}, {"author": "Thom Wiggers", "text": "

will there be more in Prague :thinking:

", "time": "2023-07-26T16:41:19Z"}, {"author": "Alissa Cooper", "text": "

I actually forgot to bring my half of the sticker stack down to the meeting -- I'll put them out in the registration area later.

", "time": "2023-07-26T16:42:10Z"}, {"author": "Matthew Hodgson", "text": "

. o O ( does zulip not support stickers? )
\n. o O ( and moreover, does MIMI content support extensible events so one can put stickers over MIMI? :P )

", "time": "2023-07-26T16:42:41Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Thom we have to start the BJORK WG in Prague so we can have a Sweedish Chef

", "time": "2023-07-26T16:43:03Z"}, {"author": "Phillip Hallam-Baker", "text": "

I support TLS encoding because nobody can specify a canonicalization for it.

", "time": "2023-07-26T16:43:46Z"}, {"author": "Nick Doty", "text": "

can we make it visible to other clients that a telephony server is mimicking the clients with server-operated credentials?

", "time": "2023-07-26T16:52:11Z"}, {"author": "Daniel Gillmor", "text": "

@Nick Doty i don't see how you enforce that technically

", "time": "2023-07-26T16:52:29Z"}, {"author": "Richard Barnes", "text": "

in the way that STIR-SHAKEN gets implemented, it is visible, bc when the SP is the endpoint, only the SP ID is authenticated

", "time": "2023-07-26T16:53:09Z"}, {"author": "Richard Barnes", "text": "

but not sure we want to import that model here

", "time": "2023-07-26T16:53:18Z"}, {"author": "Konrad Kohbrok", "text": "

Daniel Gillmor said:

\n
\n

Nick Doty i don't see how you enforce that technically

\n
\n

Depending on the architecture, you can split authentication and delivery service. Then at least they would have to collaborate.

", "time": "2023-07-26T16:53:57Z"}, {"author": "Cullen Jennings", "text": "

Like to +1 EKR point that thinking about SPAM mitigation is really key to choice of design here

", "time": "2023-07-26T16:57:53Z"}, {"author": "Richard Barnes", "text": "

@Cullen Jennings do you think spam mitigation is in tension with the privacy objective that Giles raised?

", "time": "2023-07-26T16:59:58Z"}, {"author": "Nick Doty", "text": "

@rlb so the server would authenticate sending a message to the hub, and then only the group clients themselves would realize that the sender wasn't in the group and drop the message?

", "time": "2023-07-26T17:01:11Z"}, {"author": "Konrad Kohbrok", "text": "

Raphael is going to discuss a more privacy preserving design in a few slides. Then we can discuss these questions a bit more concretely.

", "time": "2023-07-26T17:03:19Z"}, {"author": "Richard Barnes", "text": "

@Nick Doty it seems like a scheme where the servers only authenticate membership (not individual identities) is compatible with any anti-spam scheme that doesn't look inside of groups. but maybe the set of such schemes is small.

", "time": "2023-07-26T17:10:08Z"}, {"author": "Konrad Kohbrok", "text": "

The reduced metadata variant does authenticate individual group members, except that it uses per-group pseudonyms. So it can do rate-limiting on a per-group, per-member level. For a per-user or per-client level, we believe Privacy Pass is a good solution.

", "time": "2023-07-26T17:11:45Z"}, {"author": "Daniel Gillmor", "text": "

you don't even need to do spam abatement at a per-member level for the server, as long as there is some client in the group who is capable of rolling the group keys while excluding a spamming member.

", "time": "2023-07-26T17:12:40Z"}, {"author": "Konrad Kohbrok", "text": "

You can find our PoC implementation here. It's pretty rough, though: https://github.com/phnx-im/infra

", "time": "2023-07-26T17:13:32Z"}, {"author": "Nick Doty", "text": "

is there even much of an incentive for spam messages that no client will decrypt or display? DDoS is possible, but it doesn't really seem like spam

", "time": "2023-07-26T17:15:04Z"}, {"author": "Konrad Kohbrok", "text": "

Since it's the more complex target, we have focused our effort on implementing the reduced metadata variant. The full metadata one is yet to come.

", "time": "2023-07-26T17:15:23Z"}, {"author": "Murray Kucherawy", "text": "

Just noticed the milestones for this WG could use an update.

", "time": "2023-07-26T17:16:35Z"}, {"author": "Konrad Kohbrok", "text": "

Good point @Nick Doty. We should probably define the threat model and security goals more clearly before we embark on this discussion.

", "time": "2023-07-26T17:16:53Z"}, {"author": "Alissa Cooper", "text": "

good point Murray

", "time": "2023-07-26T17:19:05Z"}, {"author": "Alissa Cooper", "text": "

This is the relevant charter text:

", "time": "2023-07-26T17:19:32Z"}, {"author": "Alissa Cooper", "text": "

Recognizing the need for a standardized security protocol to support group key establishment, authentication, and confidentiality services for messaging, the IETF has specified the Messaging Layer Security (MLS) protocol [I-D.ietf-mls-protocol] and architecture [I-D.ietf-mls-architecture]. MLS is agnostic to the identity system used within any given messaging service; it provides confidentiality of sessions once the participants in a conversation have been identified. To achieve interoperable messaging, the MIMI working group will specify how one or more identity building block technologies (for example, X.509 certificates or Verifiable Credentials) can be used to establish end-to-end cryptographic identity across messaging services, assuming the use of MLS for key establishment.

\n

Interoperable messaging in federated environments requires consensus on a common delivery service and a transport protocol between federated domains. Specifically, the MLS protocol requires ordering of handshake messages within groups to ensure clients can synchronize despite asynchronous message delivery. This working group will specify a flexible solution for transport and delivery that takes into account typical requirements and best practices from the industry.

", "time": "2023-07-26T17:19:34Z"}, {"author": "Dan Sexton", "text": "

Companies like WhatsApp use metadata to \"prevent illegal activity\", will metadata reduction not impact on messaging providers ability to do that?

", "time": "2023-07-26T17:20:12Z"}, {"author": "Ted Hardie", "text": "

I think Richard's point is not considering the update mechanisms needed to achieve interoperability through that transition.

", "time": "2023-07-26T17:20:55Z"}, {"author": "Konrad Kohbrok", "text": "

@Dan Sexton That's one of the reasons why we propose the full-metadata variant first with the reduced metadata one being essentially an optional mode of operation
\n.

", "time": "2023-07-26T17:21:37Z"}, {"author": "Ted Hardie", "text": "

That transition worked in part because Google brought QUIC to the IETF in part to manage that change--since it wanted to have a single crypto stack across QUIC nd its fallback protocol.

", "time": "2023-07-26T17:21:50Z"}, {"author": "Ted Hardie", "text": "

If there is no similar driver here, then shifting from one to another will have backwards compatibility issues and it will be difficult to align the incentives to get that done.

", "time": "2023-07-26T17:22:32Z"}, {"author": "Richard Barnes", "text": "

i think we probably need a design team

", "time": "2023-07-26T17:27:32Z"}, {"author": "Mohammad Al Abbadi", "text": "

Is the path part of the set of destinations

", "time": "2023-07-26T17:30:11Z"}, {"author": "Richard Barnes", "text": "

hard to have gateways with E2E encryption, JDR

", "time": "2023-07-26T17:30:12Z"}, {"author": "Matthew Hodgson", "text": "

i think merging MIMI-DS & LM completely is really tricky as there is a fundamental philosophical gap between \"MLS-underpins everything\" versus \"layer MLS on top, and support a migration path\"

", "time": "2023-07-26T17:30:34Z"}, {"author": "Mallory Knodel", "text": "

Konrad Kohbrok said:

\n
\n

Good point Nick Doty. We should probably define the threat model and security goals more clearly before we embark on this discussion.

\n
\n

Seems like the main spam issue is in the initiation of groups, but also namely groups of 2 or 1-1 messages.

", "time": "2023-07-26T17:31:57Z"}, {"author": "Richard Barnes", "text": "

@Matthew Hodgson i think the architectural decision is whether the E2E crypto goes at the very top of the stack (as in current LM) or as far down as possible (as in MIMI-DS). what i think merits investigation is whether we can re-slice LM to move the crypto layer down (MLS or not totally aside)

", "time": "2023-07-26T17:32:42Z"}, {"author": "Britta Hale", "text": "

Interop is needed but it is not clear that linearized matrix achieves that with any more assurance than the DS proposal. Both have been implemented. Matrix has been used in more deployments but that is not the same as interop. So, since neither is a guarantee on that, the discussion should really focused on the technical properties.

", "time": "2023-07-26T17:33:06Z"}, {"author": "Matthew Hodgson", "text": "

Richard Barnes said:

\n
\n

Matthew Hodgson i think the architectural decision is whether the E2E crypto goes at the very top of the stack (as in current LM) or as far down as possible (as in MIMI-DS). what i think merits investigation is whether we can re-slice LM to move the crypto layer down (MLS or not totally aside)

\n
\n

that's precisely what we've gone and done

", "time": "2023-07-26T17:34:20Z"}, {"author": "Matthew Hodgson", "text": "

at least a sketch

", "time": "2023-07-26T17:34:26Z"}, {"author": "Richard Barnes", "text": "

@Matthew Hodgson i look forward to your Internet-draft :)

", "time": "2023-07-26T17:34:49Z"}, {"author": "Travis Ralston", "text": "

Britta Hale said:

\n
\n

Interop is needed but it is not clear that linearized matrix achieves that with any more assurance than the DS proposal. Both have been implemented. Matrix has been used in more deployments but that is not the same as interop. So, since neither is a guarantee on that, the discussion should really focused on the technical properties.

\n
\n

implemented by the author versus third party is a bit different, I think. Linearized Matrix has 3 implementations (1 truly independent) whereas MIMI DS only has 1.

", "time": "2023-07-26T17:35:25Z"}, {"author": "Matthew Hodgson", "text": "

Richard Barnes said:

\n
\n

Matthew Hodgson i look forward to your Internet-draft :)

\n
\n

yup, wish we'd got further than a one-pager sketch; bit frazzled out from the LM<->Android Messages hackathon at the weekend.

", "time": "2023-07-26T17:36:03Z"}, {"author": "Jonathan Rosenberg", "text": "

I dont think this is about a battle on who has more implementations. My main point is that - when you are building a gateway protocol, the ability to incrementally deploy so that you dont need to rip out the internals in order to participate in the gateway - this is a feature of protocol designs, not a bug.

", "time": "2023-07-26T17:37:15Z"}, {"author": "Richard Barnes", "text": "

@Jonathan Rosenberg unforatunately, anything that is E2E-secure is not purely a gateway

", "time": "2023-07-26T17:39:53Z"}, {"author": "Jonathan Lennox", "text": "

Unless you're gatewaying someone's existing E2E protocol.

", "time": "2023-07-26T17:40:22Z"}, {"author": "Eric Rescorla", "text": "

No, even then it's not E2E

", "time": "2023-07-26T17:40:52Z"}, {"author": "Eric Rescorla", "text": "

Then it's decrypted at the gateway

", "time": "2023-07-26T17:41:02Z"}, {"author": "Matthew Hodgson", "text": "

i really hope nobody is proposing breaking E2EE at gateways - we sure aren't :)

", "time": "2023-07-26T17:42:11Z"}, {"author": "Jonathan Lennox", "text": "

No, I mean everyone has to do the iMessage E2E protocol or whatever. So it's a gateway for the hub and new E2E implementation for the others. I don't think this is a good outcome - it's partially still proprietary APIs.

", "time": "2023-07-26T17:42:27Z"}, {"author": "Eric Rescorla", "text": "

Right, but that works when you have consistent E2E protocols

", "time": "2023-07-26T17:42:30Z"}, {"author": "Eric Rescorla", "text": "

Ah.

", "time": "2023-07-26T17:42:38Z"}, {"author": "Eric Rescorla", "text": "

Hopefully what I just said at the microphone clarifies the point I am trying to make above

", "time": "2023-07-26T17:47:15Z"}, {"author": "Christopher Patton", "text": "

When we say \"gatekeeper\" do we mean iMessage, and maybe Google?

", "time": "2023-07-26T17:47:21Z"}, {"author": "Matthew Hodgson", "text": "

Britta Hale said:

\n
\n

Interop is needed but it is not clear that linearized matrix achieves that with any more assurance than the DS proposal. Both have been implemented. Matrix has been used in more deployments but that is not the same as interop. So, since neither is a guarantee on that, the discussion should really focused on the technical properties.

\n
\n

The key difference technically of LM is that group management and policy control can start off without being anchored by MLS... and then shift to it being anchored in MLS as the providers adopt MLS.

", "time": "2023-07-26T17:47:27Z"}, {"author": "Mallory Knodel", "text": "

They self identify based on user numbers in March

", "time": "2023-07-26T17:47:35Z"}, {"author": "Travis Ralston", "text": "

Christopher Patton said:

\n
\n

When we say \"gatekeeper\" do we mean iMessage, and maybe Google?

\n
\n

We mean \"large messaigng providers\" at this point, effectively. The DMA hasn't really formalized gatekeepers yet

", "time": "2023-07-26T17:47:54Z"}, {"author": "Matthew Hodgson", "text": "

christopher: yes; gatekeeper is the legal jargon used to describe a big messaging provider who will be regulatorily obligated to interoperate in Mar 2024.

", "time": "2023-07-26T17:47:57Z"}, {"author": "Mohammad Al Abbadi", "text": "

Gatekeeper as defined by the EU\u060cDMA act

", "time": "2023-07-26T17:48:04Z"}, {"author": "Matthew Hodgson", "text": "

this sort of thing: https://ec.europa.eu/commission/presscorner/detail/en/STATEMENT_23_3674

", "time": "2023-07-26T17:48:20Z"}, {"author": "Mallory Knodel", "text": "

Recalling probably one of the biggest gatekeepers is e2ee voice/audio (eg gaming), not messaging.

", "time": "2023-07-26T17:48:58Z"}, {"author": "Christopher Patton", "text": "

^ thanks, all

", "time": "2023-07-26T17:49:20Z"}, {"author": "Matthew Hodgson", "text": "

and the choice of the gatekeepers is:

\n", "time": "2023-07-26T17:50:40Z"}, {"author": "Matthew Hodgson", "text": "

i haven't found any who would consider the 3rd option.

", "time": "2023-07-26T17:51:04Z"}, {"author": "Eric Rescorla", "text": "

I'm finding it very hard to understand what you think (2) consists of

", "time": "2023-07-26T17:51:37Z"}, {"author": "Eric Rescorla", "text": "

Like, what cryptographic protocol would be in use in that case

", "time": "2023-07-26T17:51:51Z"}, {"author": "Matthew Hodgson", "text": "

for option 2, the WG spec would obviously be MLS for group membership & crypt

", "time": "2023-07-26T17:52:25Z"}, {"author": "Ted Hardie", "text": "

@Matthew I am not sure it is a leap, but since you have raised the issue: have any committed to taking the onramp, once provided? If they won't do it now, in other words, what will cause them to do it in the future?

", "time": "2023-07-26T17:52:34Z"}, {"author": "Matthew Hodgson", "text": "

nobody has hard-committed, but obviously there's some interest in the LM approach that we've demoed - both from Google, Cloudflare and smaller players

", "time": "2023-07-26T17:53:16Z"}, {"author": "Ted Hardie", "text": "

You know, we haven't had a good hum lately...

", "time": "2023-07-26T17:53:38Z"}, {"author": "Matthew Hodgson", "text": "

Matthew Hodgson said:

\n
\n

for option 2, the WG spec would obviously be MLS for group membership & crypt

\n
\n

but it wouldn't be a hard dependency.

", "time": "2023-07-26T17:53:46Z"}, {"author": "Jonathan Rosenberg", "text": "

im in favor of giving the LM team a few weeks to see where they can get to.

", "time": "2023-07-26T17:54:10Z"}, {"author": "Eric Rescorla", "text": "

Matthew Hodgson said:

\n
\n

Matthew Hodgson said:

\n
\n

for option 2, the WG spec would obviously be MLS for group membership & crypt

\n
\n

but it wouldn't be a hard dependency.

\n
\n

I don't understand what that means. How would you actually deploy the alternative

", "time": "2023-07-26T17:54:11Z"}, {"author": "Eric Rescorla", "text": "

Jonathan Rosenberg said:

\n
\n

im in favor of giving the LM team a few weeks to see where they can get to.

\n
\n

I am fine to do a mimi-ds call, but I don't see it getting consensus

", "time": "2023-07-26T17:54:32Z"}, {"author": "Mallory Knodel", "text": "

It seems to me that without any additional effort by MIMI that option 2 would still be possible. It\u2019s ultimately a market decision. But without MIMI there is no option 3

", "time": "2023-07-26T17:54:42Z"}, {"author": "Jonathan Lennox", "text": "

Short-term anyone who wants to interop with a particular gatekeeper would have to implement that gatekeeper's E2E?

", "time": "2023-07-26T17:54:52Z"}, {"author": "Konrad Kohbrok", "text": "

Also, if the gatekeepers invest into a transition to MLS anyway, is it really that much more heavy lifting to just use MLS to do all the other things as well?

", "time": "2023-07-26T17:55:17Z"}, {"author": "Eric Rescorla", "text": "

@j
\nJonathan Lennox said:

\n
\n

Short-term anyone who wants to interop with a particular gatekeeper would have to implement that gatekeeper's E2E?

\n
\n

But this just means that mixed gatekeeper groups don't work

", "time": "2023-07-26T17:55:31Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, you'd have to have clients be multi-headed in their crypto implementations.

", "time": "2023-07-26T17:56:07Z"}, {"author": "Britta Hale", "text": "

Matthew Hodgson said:

\n
The key difference technically of LM is that group management and policy control can start off without being anchored by MLS... and then shift to it being anchored in MLS as the providers adopt MLS.\n````\nWe are already tied to MLS. That is the charter. So the only difference there is the assumption that gatekeepers would phase over to the LM transport before phasing over to MLS. But then the DS draft can already run over LM potentially, so even assuming the 'phased' case, which may be niche, there does not seem to be much reason to wait.\n
", "time": "2023-07-26T17:56:55Z"}, {"author": "Jonathan Lennox", "text": "

So it seems very unlikely you get inter-gatekeeper groups, rather than 3rd parties who can talk to multiple gatekeepers.

", "time": "2023-07-26T17:57:02Z"}, {"author": "Nick Doty", "text": "

are the mimi-ds authors indicating that they aren't interested in working on a design team?

", "time": "2023-07-26T17:57:13Z"}, {"author": "Britta Hale", "text": "

+1 Ted

", "time": "2023-07-26T17:58:08Z"}, {"author": "Daniel Gillmor", "text": "

i agree with ted and rohan and mallory that it's worth actually trying to adopt a draft. it can be changed if we discover that we need to change it.

", "time": "2023-07-26T17:58:35Z"}, {"author": "Richard Barnes", "text": "

i don't understand what people are calling \"maximalist\"

", "time": "2023-07-26T17:58:48Z"}, {"author": "Mallory Knodel", "text": "

Hard

", "time": "2023-07-26T17:59:13Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes i think it means \"tightly bound to MLS\"

", "time": "2023-07-26T17:59:13Z"}, {"author": "Matthew Hodgson", "text": "

Eric Rescorla said:

\n
\n

Matthew Hodgson said:

\n
\n

Matthew Hodgson said:

\n
\n

for option 2, the WG spec would obviously be MLS for group membership & crypt

\n
\n

but it wouldn't be a hard dependency.

\n
\n

I don't understand what that means. How would you actually deploy the alternative

\n
\n

like we've done already with Google. Google have said they're going to MLS for Android Messages, but right now they talk DR. So you start DR for them, then go to MLS once they've rolled it out. And converge on MIMI-DS... but without a hard dependency on MLS.

", "time": "2023-07-26T17:59:36Z"}, {"author": "Daniel Gillmor", "text": "

that is, has maximal concrete requirements of each participating party

", "time": "2023-07-26T17:59:40Z"}, {"author": "Cullen Jennings", "text": "

I viewed \"maximalist\" as more or less meaning interoperable with E2E encryption

", "time": "2023-07-26T18:00:05Z"}, {"author": "Konrad Kohbrok", "text": "

If we're tied to MLS, then I don't understand the argument with a swappable crypto layer.

", "time": "2023-07-26T18:01:31Z"}, {"author": "Ted Hardie", "text": "

What Matthew argues for is not desirable property, long term. It is transition approach that can never be removed from the architecture, with all the risks that implies.

", "time": "2023-07-26T18:01:35Z"}, {"author": "Mohammad Al Abbadi", "text": "

In favor of adopting the draft for all the good reasons that have been brought up.

", "time": "2023-07-26T18:02:34Z"}, {"author": "Ted Hardie", "text": "

Nothing in the IETF experience indicates that short-term approaches disappear in the short term or long term. \"Nothing is so permanent as a temporary patch.\"

", "time": "2023-07-26T18:02:35Z"}, {"author": "Britta Hale", "text": "

MLS is a complex protocol with very strong security guarantees. Having a too modular 'boil the ocean' type of transport can introduce hard-to-spot security issues not to mention privacy issues. It seems to be a more careful approach to keep them (MLS/DS) tied closely.

", "time": "2023-07-26T18:02:51Z"}, {"author": "Daniel Gillmor", "text": "

and each point of flexibility is another place that a protocol can break or fail

", "time": "2023-07-26T18:03:09Z"}, {"author": "Ted Hardie", "text": "

@Daniel Gillmor agreed.

", "time": "2023-07-26T18:03:28Z"}, {"author": "Daniel Gillmor", "text": "

this is a call for adoption of a call for adoption

", "time": "2023-07-26T18:03:52Z"}, {"author": "Konrad Kohbrok", "text": "

I strongly agree with @Britta Hale. Another layer just adds more complexity to an already complex protocol.

", "time": "2023-07-26T18:04:10Z"}, {"author": "Patrick Tarpey", "text": "

poll has finished...

", "time": "2023-07-26T18:04:59Z"}, {"author": "Richard Barnes", "text": "

i am a hum maximalist

", "time": "2023-07-26T18:05:36Z"}, {"author": "Andrew Campling", "text": "

That doesn\u2019t work well for remote participants

", "time": "2023-07-26T18:05:59Z"}, {"author": "Monika Ermert", "text": "

Has humming been deprecated ;-)

", "time": "2023-07-26T18:06:00Z"}, {"author": "Richard Barnes", "text": "

humming is not remote-friendly

", "time": "2023-07-26T18:06:11Z"}, {"author": "Daniel Gillmor", "text": "

+1 @Cullen Jennings

", "time": "2023-07-26T18:08:22Z"}, {"author": "Nick Doty", "text": "

is there a potential for collaborative rather than competitive work here?

", "time": "2023-07-26T18:08:30Z"}, {"author": "Richard Barnes", "text": "

i was going to say \"even if we adopted, we can still have a design team, just focused on how to evolve the adopted thing as opposed to making a thing to adopt\"

", "time": "2023-07-26T18:08:30Z"}, {"author": "Ted Hardie", "text": "

I think a statement like \"another call will be issued by the end of September, if not before\" would be useful now.

", "time": "2023-07-26T18:09:16Z"}, {"author": "Ted Hardie", "text": "

The author teams need some deadline.

", "time": "2023-07-26T18:09:29Z"}, {"author": "Daniel Gillmor", "text": "

agreed, there is nothing wrong with a hard deadline

", "time": "2023-07-26T18:09:38Z"}, {"author": "Vittorio Bertola", "text": "

Nick Doty said:

\n
\n

is there a potential for collaborative rather than competitive work here?

\n
\n

I would hope that there can be a design that keeps both approaches possible.

", "time": "2023-07-26T18:10:04Z"}, {"author": "Konrad Kohbrok", "text": "

With the MIMI DS draft, the server has full visibility to all of the metadata and policy decisions and can mirror everything on a higher layer if it wants to.

", "time": "2023-07-26T18:10:52Z"}, {"author": "Mohammad Al Abbadi", "text": "

The impression I have is that mimi-ds is the migration path and lm is a complicated detour or holding pattern for operators who don't want to commit to MLS yet, is that fair?

", "time": "2023-07-26T18:10:57Z"}, {"author": "Konrad Kohbrok", "text": "

MLS is in the charter, so I doubt that the WG will adopt anything that will allow gatekeepers to avoid committing to MLS.

", "time": "2023-07-26T18:13:08Z"}, {"author": "Richard Barnes", "text": "

i thought the pitch was more something based on LM+MIMI-DS as a long-term target, with something more pure LM as an intermediate step

", "time": "2023-07-26T18:13:30Z"}, {"author": "Britta Hale", "text": "

Whether there is a design team draft or not, if we come back with more than one draft in future discussions it would be useful for concrete security/privacy tradeoffs to be presented. Much of this discussion today has been around time constraints and unknown potential for interop, with not a lot of clarity about differences between the drafts on what is visible on the wire or on the servers/hubs. (Each has discussed this to some extent, and the DS draft to a greater extent, but a direct tradeoff comparison is missing.) That is very pertinent information for any decision point in the WG as we are focused on supporting E2EE and secure messaging.

", "time": "2023-07-26T18:16:41Z"}, {"author": "Matthew Hodgson", "text": "

i think we've done a bad job on the LM side of trying explain that all we're doing is proposing syncing the MLS group management into the transport layer, so that parties who don't speak MLS yet can route/policy-control/transport messages around.

", "time": "2023-07-26T18:17:29Z"}, {"author": "Matthew Hodgson", "text": "

which means that (for instance) the policy decisions then get made based on the transport layer (obviously preferring the MLS-owned properties too, where they exist) - which is a major shift from the current MIMI-DS draft.

", "time": "2023-07-26T18:19:01Z"}, {"author": "Konrad Kohbrok", "text": "

But if the data is synced between the MLS layer and the transport layer, where is the difference? The MIMI DS draft anchors it in MLS, but doesn't hide it from the server.

", "time": "2023-07-26T18:19:52Z"}, {"author": "Matthew Hodgson", "text": "

however, i am confident that if we can get to agreement that it's desirable to provide a migration path, rather than optimising purely for the long-term idealist architecture from the outset, then we can get aligned with LM providing the transport, MIMI-DS being a MLS DS, and everyone wins.

", "time": "2023-07-26T18:19:56Z"}, {"author": "Mohammad Al Abbadi", "text": "

But they still won't be anywhere closer to speaking MLS after, so it's sounding to me less of a migration and more of an opt out

", "time": "2023-07-26T18:20:18Z"}, {"author": "Konrad Kohbrok", "text": "

Can we agree that using DR is not an option?

", "time": "2023-07-26T18:20:43Z"}, {"author": "Eric Rescorla", "text": "

DR?

", "time": "2023-07-26T18:21:12Z"}, {"author": "Richard Barnes", "text": "

Double Ratchet

", "time": "2023-07-26T18:21:18Z"}, {"author": "Konrad Kohbrok", "text": "

Sorry. Double Ratchet.

", "time": "2023-07-26T18:21:22Z"}, {"author": "Frode Kileng", "text": "

In parts of the world, people have multiple SIMs, exchange SIMS, and buy new and drop SIMs. I.e. phone numbers may not be a good choice for persistent identities

", "time": "2023-07-26T18:21:22Z"}, {"author": "Richard Barnes", "text": "

Disaster Recovery

", "time": "2023-07-26T18:21:23Z"}, {"author": "Richard Barnes", "text": "

Dominican Republic

", "time": "2023-07-26T18:21:26Z"}, {"author": "Eric Rescorla", "text": "

Ah, yes, that seems like to does not solve the problem

", "time": "2023-07-26T18:21:31Z"}, {"author": "Nick Doty", "text": "

yay for explicitly including having multiple clients on multiple providers

", "time": "2023-07-26T18:21:35Z"}, {"author": "Matthew Hodgson", "text": "

Mohammad Al Abbadi said:

\n
\n

But they still won't be anywhere closer to speaking MLS after, so it's sounding to me less of a migration and more of an opt out

\n
\n

no, because if they don't speak MLS they won't be able to speak to each other in the wider MIMI interoperable network :)

", "time": "2023-07-26T18:21:39Z"}, {"author": "Matthew Hodgson", "text": "

Konrad Kohbrok said:

\n
\n

But if the data is synced between the MLS layer and the transport layer, where is the difference? The MIMI DS draft anchors it in MLS, but doesn't hide it from the server.

\n
\n

the difference is that MIMI-DS assumes that everyone is already speaking MLS. but they are not.

", "time": "2023-07-26T18:22:04Z"}, {"author": "Konrad Kohbrok", "text": "

By everyone, do you mean clients or servers?

", "time": "2023-07-26T18:22:29Z"}, {"author": "Matthew Hodgson", "text": "

instead, they get up and running with a non-MIMI-WG approach with whatever crypto they have today - e.g. using the LM ID

", "time": "2023-07-26T18:22:29Z"}, {"author": "Ted Hardie", "text": "

@Matthew. you say things like \"long-term idealist architecture from the outset\" when there are implementations. That's starting to sound like counter-marketing rather than an analysis, and I'd prefer it if you'd stick to characterizing your own system rather than others.

", "time": "2023-07-26T18:22:45Z"}, {"author": "Matthew Hodgson", "text": "

Konrad Kohbrok said:

\n
\n

By everyone, do you mean clients or servers?

\n
\n

both.

", "time": "2023-07-26T18:22:47Z"}, {"author": "Konrad Kohbrok", "text": "

But clients will have to speak MLS anyway.

", "time": "2023-07-26T18:23:02Z"}, {"author": "Matthew Hodgson", "text": "

i'm not trying to market :( i'm trying to explain the reality of what would need to be implemented to be adopted before the DMA window closes.

", "time": "2023-07-26T18:23:09Z"}, {"author": "Matthew Hodgson", "text": "

konrad: we're talking cross purposes because you're thinking of hypothetical future MIMI adherents, whereas i'm talking about the actual parties who exist today.

", "time": "2023-07-26T18:23:37Z"}, {"author": "Phillip Hallam-Baker", "text": "

Users should manage public keys of their contacts end-to-end

", "time": "2023-07-26T18:23:53Z"}, {"author": "Konrad Kohbrok", "text": "

So the MIMI protocol would have to support the double ratchet protocol?

", "time": "2023-07-26T18:23:55Z"}, {"author": "Phillip Hallam-Baker", "text": "

Unless public key management is end-to-end, the protocol is not end-to-end

", "time": "2023-07-26T18:24:17Z"}, {"author": "Konrad Kohbrok", "text": "

And the iMessage protocol for that matter.

", "time": "2023-07-26T18:24:29Z"}, {"author": "Richard Barnes", "text": "

@Matthew Hodgson it seems like in your \"everyone speaks their own crypto\" vision, a client that talks to multiple providers has to implement multiple cryptos. that seems ... sub-optimal

", "time": "2023-07-26T18:24:30Z"}, {"author": "Matthew Hodgson", "text": "

konrad: absolutely not. but the layering should not have a hard-dependency on MLS to be able to exchange messages.

", "time": "2023-07-26T18:24:31Z"}, {"author": "Eric Rescorla", "text": "

I think it's one thing to say \"It would be good to be able to deploy in test environments without MLS\" and \"One should actually deploy without MLS\"

", "time": "2023-07-26T18:24:41Z"}, {"author": "Matthew Hodgson", "text": "

@Richard Barnes totally suboptimal, but realistic as a temporary measure while everyone rolls out MLS.

", "time": "2023-07-26T18:25:00Z"}, {"author": "Phillip Hallam-Baker", "text": "

Subpoenas against ny service to provide FBI keys are the way to break messaging protocols

", "time": "2023-07-26T18:25:04Z"}, {"author": "Eric Rescorla", "text": "

I'm provisionally onboard with (1) but not so much with (2)

", "time": "2023-07-26T18:25:29Z"}, {"author": "Richard Barnes", "text": "

@Matthew Hodgson so if you're going to have to implement multiple cryptos anyway, what does it matter whether the signaling goes inside or outside the crypto?

", "time": "2023-07-26T18:25:43Z"}, {"author": "Richard Barnes", "text": "

(and if you're going to be implementing new signaling anyway)

", "time": "2023-07-26T18:26:01Z"}, {"author": "Ted Hardie", "text": "

@Matthew. Many IETF systems have lasted decades (e.g. SMTP). Building something for the first six months of deployment when it will stick around forever has turned out to be a bad idea many times (Hello, \"Host\" header). Speaking personally, I think it is more compelling to offer a single transition than a set of stages. I rather suspect that if I called up the relevant teams at Google or Meta and said \"how many transitions do you want here\" the answer would be \"ideally, zero\". Offering them two, rather than one, does not sound like a win, especially given the complexity of any of the transitions in maintaining the appropriate security and privacy characteristics.

", "time": "2023-07-26T18:26:23Z"}, {"author": "Matthew Hodgson", "text": "

Richard Barnes said:

\n
\n

Matthew Hodgson so if you're going to have to implement multiple cryptos anyway, what does it matter whether the signaling goes inside or outside the crypto?

\n
\n

because you can reuse the same signalling if you sync the MLS-specific group management with a common signalling layer.

", "time": "2023-07-26T18:26:49Z"}, {"author": "Matthew Hodgson", "text": "

rather than starting from scratch

", "time": "2023-07-26T18:26:52Z"}, {"author": "Ted Hardie", "text": "

@Richard. What, you don't miss Adium?

", "time": "2023-07-26T18:27:05Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Ted, nobody should miss Adium. It never bloody worked

", "time": "2023-07-26T18:27:31Z"}, {"author": "Matthew Hodgson", "text": "

ted: i'm proposing 1 transition, in two layered phases. first, converge on a common transport layer. second, converge on a common encryption layer.

", "time": "2023-07-26T18:27:45Z"}, {"author": "Nick Doty", "text": "

impersonation does seem like a large risk, especially if there can be multiple providers for the same phone number and the opportunity to overwrite the preferred delivery provider

", "time": "2023-07-26T18:28:08Z"}, {"author": "Ted Hardie", "text": "

@Matthew. I'm afraid I don't think that view matches how the operational reality would unfold.

", "time": "2023-07-26T18:28:26Z"}, {"author": "Eric Rescorla", "text": "

A more complete explanation of PIR can be found at https://educatedguesswork.org/posts/pir/

", "time": "2023-07-26T18:28:59Z"}, {"author": "Jonathan Lennox", "text": "

Yeah, I'm very unclear on how you stop a provider from claiming that someone is their customer.

", "time": "2023-07-26T18:29:57Z"}, {"author": "Eric Rescorla", "text": "

@Jonathan Lennox I think you don't

", "time": "2023-07-26T18:30:08Z"}, {"author": "Matthew Hodgson", "text": "

Matthew Hodgson said:

\n
\n

ted: i'm proposing 1 transition, in two layered phases. first, converge on a common transport layer. second, converge on a common encryption layer.

\n
\n

by telling the big guys that they have to do one enormous jump into the unknown, i am (very) confident they are going to balk. MIMI will end up being a very cool decentralised Signal alternative (and whatever happens here, on the Matrix side we look forward to contributing to it!). But it sure won't help with Google<->Apple or WhatsApp<->Skype or whatever.

", "time": "2023-07-26T18:30:10Z"}, {"author": "Matthew Hodgson", "text": "

/me stops heckling the PIR/discovery pitch; very happy to talk this thru after though.

", "time": "2023-07-26T18:30:42Z"}, {"author": "Jonathan Lennox", "text": "

Then can't any provider MitM any conversation, by claiming the parties' phone numbers as their customers, and then forwarding to the real endpoints?

", "time": "2023-07-26T18:31:06Z"}, {"author": "Eric Rescorla", "text": "

@Jonathan Lennox that's a generic problem here unless you have some kind of global authentication system

", "time": "2023-07-26T18:31:34Z"}, {"author": "Eric Rescorla", "text": "

Like, KT, etc.

", "time": "2023-07-26T18:31:47Z"}, {"author": "Jonathan Lennox", "text": "

Seems like a pretty fatal one to me, though. People will be claiming celebreties' and dissidents' phone numbers immediately.

", "time": "2023-07-26T18:32:25Z"}, {"author": "Nick Doty", "text": "

I agree that it's a generic, hard problem. but do we have any suggested directions or mitigations?

", "time": "2023-07-26T18:32:47Z"}, {"author": "Jonathan Lennox", "text": "

Don't do SII at all, and you have to advertise SSI?

", "time": "2023-07-26T18:34:12Z"}, {"author": "Jonathan Lennox", "text": "

It's awful but I don't see anything else.

", "time": "2023-07-26T18:34:24Z"}]