Re: [Mimi] Gatekeeper comparison Re: Recap of June 7 virtual interim

[Mallory Knodel <[e-mail]>]

Hey Alissa,

On Wed, 25 Oct 2023 at 16:53, Alissa Cooper <[e-mail]> wrote:

> Hi Mallory,
>
> On Oct 25, 2023, at 3:10 PM, Mallory Knodel <[e-mail]> wrote:
>
> On Wed, Oct 25, 2023 at 2:59 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>> On Wed, Oct 25, 2023 at 11:45 AM Mallory Knodel <[e-mail]> wrote:
>>
>>> On Wed, Oct 25, 2023 at 2:39 PM Eric Rescorla <[e-mail]> wrote:
>>>
>>>>
>>>> On Wed, Oct 25, 2023 at 11:20 AM Mallory Knodel <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Eric and Raphael,
>>>>>
>>>>> On Tue, Oct 24, 2023 at 2:29 PM Eric Rescorla <[e-mail]> wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Oct 24, 2023 at 10:22 AM Mallory Knodel <mknodel=
>>>>>> [e-mail]> wrote:
>>>>>>
>>>>>>> Hi Raphael,
>>>>>>>
>>>>>>> On Tue, 24 Oct 2023 at 12:56, Raphael Robert <ietf=
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>> Hi Mallory,
>>>>>>>>
>>>>>>>> See comments inline.
>>>>>>>>
>>>>>>>> On 23. Oct 2023, at 21:47, Mallory Knodel <mknodel=
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I've been gleaning some insights into what I think are
>>>>>>>> generalisations about how messaging/video/voice gatekeepers are likely to
>>>>>>>> (minimally) comply with the DMA, either for 1-1 or group messaging.
>>>>>>>>
>>>>>>>> If MIMI's work were along a spectrum, this minimal compliance sits
>>>>>>>> at the opposite pole from what the design team is heroically working
>>>>>>>> towards: a suite of documents that describes ideal interoperable group
>>>>>>>> messaging.
>>>>>>>>
>>>>>>>> I think the scope is a bit smaller here: we are trying to find an
>>>>>>>> mvp, the scope has already been reduced to what folks think is necessary.
>>>>>>>> The current points of contention are around the viability of it all.
>>>>>>>>
>>>>>>>> And to not at all detract from that important work, I aimed to look
>>>>>>>> for gaps or "modular" specifications that would be helpful in addition to
>>>>>>>> the core specifications ("arch", "transport", "signaling" and "ds") if one
>>>>>>>> approaches the architecture from the opposite direction, eg status quo.
>>>>>>>>
>>>>>>>> The modularity is also something that is being discussed currently.
>>>>>>>> There might be fewer documents in the end.
>>>>>>>>
>>>>>>>>
>>>>>>>> After some digging I see two concrete specifications that would
>>>>>>>> support both minimum compliance for 1-1 messaging: client integrity and
>>>>>>>> end-point definition. I had actually stumbled on a third, a mvp
>>>>>>>> 3p-client-to-host-server protocol feature set, but it was rightly pointed
>>>>>>>> out that MIMI has already taken the decision to not deal with the
>>>>>>>> 3p-client-to-host protocol, which is fair enough.
>>>>>>>>
>>>>>>>> On the content: Can you comment on your interest in seeing these
>>>>>>> two areas of work progressed, more substantively?
>>>>>>>
>>>>>>
>>>>>> Can you say a few more words on what those areas of work entail?
>>>>>>
>>>>>
>>>>> Certainly and thanks for asking.
>>>>>
>>>>> I took the Julia Len / Paul Grubbs approach to evaluating the status
>>>>> quo versus ideal across three elements: Identity; Protocol; Abuse
>>>>> mitigation.
>>>>>
>>>>> Within various combinations of those problem spaces, you'll find
>>>>> client integrity begins to matter quite a lot not just for authentication
>>>>> (implicated across all three), but for how changes to any one system must
>>>>> now start to evolve the entire ecosystem (see Moxie's ever-quoted piece on
>>>>> standards and ossification). So, how is client integrity handled, even in
>>>>> the absolute bare-minimum case of inerop where the gatekeeper basically
>>>>> controls everything but 3p messages still make it through.
>>>>>
>>>>
>>>> Sorry for asking a basic question, but can you explain what you mean by
>>>> "client integrity"?
>>>>
>>>> What a very in-scope question for an exercise in specification.
>>>
>>> I mean client software integrity.
>>>
>>
>> I see. So specifically you're talking about cases in which the client
>> demonstrates/attests that it is running a specific piece of software? Are
>> you including in this cases where the operator of the software wishes to
>> represent that they are running one piece of software when actually they
>> are running another?
>>
>> The point is to approximate the status quo-- right now closed systems
> have control over client integrity. Interop of any degree reduces that
> control. So no, I wouldn't think those cases would be central to the
> document. Probably a security considerations section mention that this
> specification doesn't cover that case or other active attacks (future
> work?).
>
>
> I’m not quite following this. Since the WG is specifying server-to-server
> protocols, what protocol work do you view as being in scope related to
> clients and their integrity?
>

The design team is doing server to server protocols, of course. But MIMI is
about end-to-end, so clients matter.

But just to be sure, I checked the charter and among a bunch of other
things there is “The working group will specify a solution to the
introduction problem, together with best practice recommendations for
functionality, configuration options, and other aspects.” Those other
aspects probably have a thing or two to do with clients, not to mention the
various other in-scope items in the charter that go beyond protocol.

MLS has client aspects and MIMI is based on clients.

It’s certainly an important problem to be solved. Does MIMI want to work on
it or should we leave it to the gatekeepers to write up their solution in
individual white papers?

-Mallory


>>
>>>
>>>> On the end point problem, this is mostly very contentious territory but
>>>> I would gently suggest it be worth wading in if not to keep intermediary
>>>> interops (think of a 3p service that is not messaging but that provides
>>>> automation or feature integration or ads!) from being within scope for
>>>> interoperability. So, in MIMI do we consider only end points that are
>>>> individual people with accounts or do you also allow the protocol to work
>>>> for bots and such? How does that get defined?
>>>>
>>>> I think the latter might stir some imagination around 3p-client-to-host
>>>> protocol specifications (and what does a minimum set of features entail),
>>>> but I'm not proposing that as work given the group has made the decision
>>>> not to do that.
>>>>
>>>> -Mallory
>>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> -Ekr
>>>>>
>>>>> I wonder if anyone else finds these two areas of work interesting?
>>>>>>> What's nice is that this work can happen totally in parallel to the design
>>>>>>> team as well as potentially have some real shape before the upcoming May
>>>>>>> deadline for gatekeepers for 1-1, where MIMI's DT deliverables are aiming
>>>>>>> for the following year. It might be useful to engage with policy makers
>>>>>>> before then with some concrete deliverable-- or at least informed
>>>>>>> discussion.
>>>>>>>
>>>>>>> Since it's focussed on nudging gatekeeper status quo, another place
>>>>>>> this work would support ongoing efforts is filling in Alissa's draft on
>>>>>>> transport service requirements:
>>>>>>> https://github.com/coopdanger/ietf-wg-mimi/blob/main/mimi-transport-requirements.md
>>>>>>> .
>>>>>>>
>>>>>>> There have been additional discussions about architecture questions
>>>>>>> in interims and the DT. That particular document doesn’t reflect the
>>>>>>> current state anymore.
>>>>>>>
>>>>>>>
>>>>>>> I'd be happy to share more about why I think these are gaps in
>>>>>>> gatekeeper compliance-- I've even got a slide deck. But I'm keen to hear
>>>>>>> others' thoughts about these parallel directions.
>>>>>>>
>>>>>>> I'd say this is something for an interim. Some coordination ahead of
>>>>>>> time would be good in order to make sure you are up to speed with the
>>>>>>> current status of discussion and there’s no overlap.
>>>>>>>
>>>>>>
>>>>>> On the process:
>>>>>>
>>>>>> I’d say the MIMI WG folks who are not in the DT all need to be caught
>>>>>> up to speed as a general matter.
>>>>>>
>>>>>> But the point of this work would be that it shouldn’t matter so much
>>>>>> on the DT work. They would run in parallel.
>>>>>>
>>>>>> Since it would be new-ish work, and in-person meetings tend to cast a
>>>>>> wider net than interims, it might be strategic to talk about this in Prague
>>>>>> so contributors might get engaged enough to make some progress as a WG?
>>>>>>
>>>>>> -M
>>>>>>
>>>>>>
>>>>>>> Raphael
>>>>>>>
>>>>>>>
>>>>>>> -Mallory
>>>>>>> On 6/8/23 11:00 AM, Alissa Cooper wrote:
>>>>>>>
>>>>>>> Recording: https://www.youtube.com/watch?v=FE0Zr-82XAU
>>>>>>>
>>>>>>> Raw notes:
>>>>>>> https://notes.ietf.org/notes-ietf-interim-2023-mimi-05-mimi#
>>>>>>>
>>>>>>> DMA gatekeeper comparison shared by Matthew/Element:
>>>>>>> https://docs.google.com/spreadsheets/d/1FiR4yhU5BpLtoeFFda5ORr86qwT33fYZowY_bWDlPas/edit#gid=1722388534
>>>>>>>
>>>>>>> Homework assignments for the WG:
>>>>>>>
>>>>>>>    - Review latest linearized Matrix I-D and have discussion on the
>>>>>>>    list
>>>>>>>    <https://www.ietf.org/archive/id/draft-ralston-mimi-linearized-matrix-01.html>
>>>>>>>    <https://www.ietf.org/archive/id/draft-ralston-mimi-linearized-matrix-01.html>
>>>>>>>    - Review gatekeeper comparison and raise questions/comments on
>>>>>>>    the list
>>>>>>>    - Get interop testing doing for LM, for those interested
>>>>>>>    - Alissa to take an initial stab at synthesizing requirements
>>>>>>>    discussed from IETF 116 going forward
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alissa
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mallory Knodel
>>>>>>> CTO :: Center for Democracy and Technology
>>>>>>> newsletter :: https://internet.exchangepoint.tech
>>>>>>>
>>>>>>> --
>>>>>>> Mimi mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mimi
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> Mimi mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mimi
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Mallory Knodel
>>>> CTO, Center for Democracy and Technology
>>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>>>
>>>>
>>>
>>> --
>>> Mallory Knodel
>>> CTO, Center for Democracy and Technology
>>> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>>>
>>>
>
> --
> Mallory Knodel
> CTO, Center for Democracy and Technology
> gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
>
>
>