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

[Mallory Knodel <[e-mail]>]

On Wed, 25 Oct 2023 at 19:55, Mallory Knodel <[e-mail]> wrote:

> 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.
>
MIMI is based on MLS!

>
> 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
>>
>>
>>