Note takers: Orie Steele & Sean Turner; after lunch, dkg
takes notes.
Rohan: Agenda bash: Konrad should go right after -protocol.
Alissa: Sure.
Presenting: Rohan Mahy
Slides: Link
No changes to I-D. Will post a "new" version soonest.
Presenting: Rohan Mahy
Slides: Link
Slide 12
ekr: What's you definition of absolutely nec.
Rohan: The reason that GCE requires an update path because it might
require something needs an update path.
ekr: Does not make sense. I am looking for the security rationale. This
is going to create a hole and need to understand why that hole is there.
Rohan: If the state that is being changed but doesn't change MLS, then
you can use application.
Femi: Can you talk about changing the mood of the room.
Rohan: Mood is meta data about the room: mood=happy, sad, excited.
Konrad: Depends on the state that is being modified. If you need to
change the MLS membership list then if you feel then you might do an
update.
Jonathan: This is binding MiMI directly to properties of MLS. Maybe we
should keep the substrate different.
Rohan: I think you're misunderstanding the context here.
Jonathan: It would still be better if there were two proposals.
Rohan: I will pass that on to MLS!!!!
Slide 14
Mark N (aka mnot): There is an HTTP Directorate; please ask for an early
review.
Rohan: We have a directory.
Mark N: I love you. :) <3 <3
Slide 22
Jon: Wasn't clear where the message contents are integrity protected.
How is it including the in the frank.
Rohan: Cannot recall exactly what Franking Tag covers, I need a
momentekr to reconstruct.
Jon: Not clear how the Franking covers the message content.
Seems like sending decrypted messages to the hub could be a problem.
ekr: This goes to Jon's questions. This didn't work as well as we hoped.
Want to make sure it is safe.
Rohan: This a an adaptation of FB franking scheme.
ekr: That scheme is not safe.
Rohan: We got it reviewed and got some amount of buy off.
ekr: I would like the security of this scheme to be reviewed by CFRG.
Rohan: Fair 'nuff.
Slide 22
Rohan: beware - https://github.com/ietf-wg-mimi/mimi-protocol/issues/89
Konrad: Since we shared keys somewhere, couldn't we do something
awesome: MAC it with a key we already shared with the hub.
Rohan: That sounds interestgin; we can work on it.
Jon: I think there was some identity draft at some point, it would be
good if that draft got incorporated.
Rohan: we are using MLS credentials... this is about keys for the hub...
which are not discussed in mimi identity.
Jon: Not clear why user identity is not discussed.
Raphael: I like it. Adding more context; provides the right balance.
Slide 24
Rohan: This seems like this should be mandatory.
Alissa: Wondering who is implementing this:
Rohan & Raphael
https://datatracker.ietf.org/doc/draft-kohbrok-mimi-metadata-minimalization/
Presenter: Konrad Kohbrok
PResenter: Rohan
Slides: Link
Rohan: answering Jon before, I have shared the answer to the franking
tag question in the chat
ekr: Agree with problem statement, but how is this set those properties.
Rohan: Use a stopwatch icon.
ekr: Now you have two sliders. How does this work?
ekr: why not just do relative?
Rohan: I will ask the list, to see if anyone wants to keep absolute
ekr: in a large group, the consequence is that messages may never be
deleted.
Rohan: people seem to know this.
Alissa: Coming back to the expiration, Will asks how do you address
self-deleting messages and reporting?
Rohan: As long as the franck, message, and frank context a report can be
generated.
self deleting messages are a client concern, the hub cannot control
them.
Jonathan: How does message franking work with editing messages.
Rohan: Frank effects a message that has an ID.
Jon: This works as intended.
Will Earp: If you need to report self-deleted message after it is
deleted.
Rohan: The client determines how to respect the self deleteing timer,
the client could decide to pause the self delete if an abuse report was
in progress.
your client can still delete the message after, the message has been
sent to the hub.
Last slide
Raphael: No strong opinion, but you might be right that we don't need
it.
Rohan: WRITE CODE!!! Also, I take PRs.
Presenter: Rohan (again)
Slides: Link
Timo: Do these need to be boolean?
Rohan: Good question.
Thibault: This is vry rol based. If I only want to use one role, then I
need to update the role list.
Rohan: Yes, you need to create a new role, and then set the capabilities
to that role, and then bind the role to you as a member
Raphael: it would be good to see how this maps to what a hub can enforce
as well. obviously hub can only enforce some of it
Rohan: there is a list in the draft of what the hub can enforce... hub
can block a lot of things, but not everything
Konrad: This is great work, bubt there are lots of lists. How do we add
to this list? Is there capability negotiation?
Rohan: Yeah I have a headache ...
Chairs what do we do with this?
Rohan: Would like to keep it seperate.
Konrad: Need something like this so let's adopt it! But, keep it
seperate.
Alissa: We will take it to the list! We can also ask in the room,
Result of Poll: 16 in favor of adopting & 8 no opinion with 40
participants.
Presenter: Femi Olumofin
Slides: Link
Rohan: Can I have different records at CISPs? But there are multiple
phone numbers per CSIP?
Femi: Yes, you can be discoverable single phone number, multiple CSIP.
Jon: Any telephone number, can have multiple CSIP
ekr: CLairfy that because CSIP is the granter, but they are not the ..
Jon: There needs to be a binding .... (string of acronmyn lots of 'em
start with 'C' :)
ekr: like domain names, the way to manage is to verify receipt
ekr: who is CSIP for phone number? T-Mobile?
jon: yes, and CSIP for email is Gmail.
ekr: we had some back and forth; this dos not provide a mapping to CSI
and the specific identifier. Only from CSI to MSP.
Alissa: recipient CSI needs to be verifiable by the recipient.
Jon: Let's do this after lunch!
[notetaker transitions to dkg]
(slide 14)
ekr: is "recipient vs. sender" the right terminology? we want origin
authentication
Jon: bring back the mimi identity draft, explain how sending and
receiving work the same way. agree that the terminology needs
improvement.
ekr: if you're a large MSP, you can impersonate anyone with any CSI to
anyone else.
Jon: the three-way handshake is supposed to prevent that; we need to
make sure we can require it properly.
Konrad: who is the recipient here? the person holding the identifier
isn't involved?
(back to slide 12)
Jon/Femi: these are preconditions to communication
(back to slide 14 (Recipient Requirements))
ekr: requirement 1 here should be that we want the mapping to go from
CSI to MSP,SSI tuple, not just to the MSP
Jon: MSP internal routing might be opaque
dkg: The only in req 1is unclear, what does it apply to?
... only the recipient MUST be authorized?
Femi: thanks, it means that the recipient needs to be involved.
(no objections to req 2)
Harald Alvestrand: req 3 is missing a case: how does the MSP reassign
the SSI? If the MSP reassigns their own internal ID for the user, and
the MSP can't make this change on its own, then there will exist a case
where a lingering mapping remains.
ekr: req 1 and req 3 seem interrellated. Can the user claim control over
an MSP's SSI?
Femi: including the MSP in the mapping process, it makes it more
complex.
Jon: we have a good idea of how to create the mappings, and a less-good
understanding of how to remove them. This smells like revocation,
expiration, CRLs, or short-lived certs. Do we have a cadence or
freshness expectation? I'm concerned because the CSIP can't necessarily
even know when a mapping exists.
Femi: when a new number is assigned, it might mean we need to broadcast
a deletion message to all mapping providers.
ekr: should a recipient be able to embed a mapping to an MSP/CSI that
they don't directly control?
dkg: it seems to assume there exists a well known global set of mapping
providers.
femi: we are thinking about requirements, we are considering this as a
possibility.
dkg: if csip needs to know all providers, it makes dynamic federation
harder.
femi: we don't know if there is federation, there may not be.
requirements should be agnostic to architecture which will follow.
jon: csip does not need to be involved. The discovery provider and
mapping distribution might be handled entirely by MSPs, or by CSIPs, or
by someone else. discovery provider is a logically independent thing.
Femi: yes, but we do need a way to change a mapping.
ekr: We want a globally consistent view of the mapping table, right?
Jon: A federation might decide that its information is only visible to
members of its federation.
ekr: do we want a sender,recipient pair to always have the same view? I
think we need some kind of consistency requirements.
Jon: can we move this to the discovery provider requirements?
(slide 15: Sender Requirements)
Konrad: for req 4, how do we ensure that the "all" is met?
Tim: is req 5 satisfied if an online interaction with a CSIP is required
to verify the authenticity of the mapping?
Jon: I think the answer to Tim's question is "yes", though we would
discourage that in many cases. Where your CSIP might be the telco that
provides RCS. What this requirement is saying is that the sender needs
to be able to see a cryptographic assertion that can be traced back to a
reasonable authority.
Tim: the sender should be able to see a self-contained object that they
can verify, but there could be some cases where direct interaction might
be necessary.
Jon: if the CSIP and the MSP are the same party, we wouldn't want to
exclude that use case.
(Slide 16: Discovery Provider Requirements)
ekr: req 6: does "0" mean "i've published that there are no mappings" or
"no records found"? this is similar to the difference between a proof
that there are no records and no proof that there are any records. Think
about DNSSEC proof of non-existence. This means that we can't prevent a
discovery provider from censoring you, because they can generate the "no
recods found" response and you can't tell.
Harald: how do we mark deceased people? i'd like to have a clear signal
that i can no longer contact this person.
Jon: we're not doing NSEC3 here. The CSI belongs to your government.
The survivors of a deceased person might be the ones to publish "no
such mapping". We could invent a novel "does not exist" mapping, but
that could also be abused. more work needed here.
Tim: maybe we handle the deceased scenario at the messaging tooling, not
at the discovery. (e.g. when you send a dead person a message, the MSP
responds on their behalf)
dkg: I like the intention of req 7, but the framing could be improved.
The DS must not learn the first bullet or the second bullet, not both.
ekr: if the MSPs are involved in the process, then this gets more
complicated. the MSP eventually learns who you're talking to.
Alissa: I like this too. I put a high-level framing in the chat. ("I
think the high-level requirement here, restated, is that the DP must be
prevented from learning who is querying whom."). Should clarify that
this is on a query-by-query basis.
Konrad: for req 8, can we include information about the substance of the
query as well? can we avoid announcing information to peers who don't
need to know? i'd like to see "disclose only as much as necessary" but i
don't know whether we can do it or not.
ekr: what does req 8 give us? If i have a service fronted by cloudflare,
this prevents cloudflare from sending data about the client making the
connection. we should be clearer what "server" means here.
Jon: 8 should be no more onerous than 7. It might be that 7 is
sufficient, but then we don't necessarily need 8. 7 should include the
case that more than server is responding.
Tim: different participants will have different capabilities. A smaller
participant might not be capable of handling the load borne by whats app
(Slide 17 (Discovery provider requirements part 2))
ekr: req 9, just remove "between clients and servers"
Femi: ok, will remove.
dkg: defense against enumeration attacks are usually partial... its hard
to provide absolute protection... its usually a cost or time tradeoff...
this requirement seems difficult to satisfy clearly... I like that its
here, but its hard to measure.
femi: agree.
ekr: i'm skeptical of "reasonably hard". consider a system with 10^10
mappings, and i have 10^8 people, each of whom have 10^2 people, then
i'm going to do 10^10 queries anyway. how does this work with large
gateways with enormous users?
Femi: there are different techniques to limit requests to the database.
Thibault Meunier: we're talking about DPs when we say "databases",
right?
Femi: rate limiting is only between the client and the DP
Jon: what's the difference between sending my contact book to the DP vs.
spamming all MSPs when we send to a CSI? I'm not confident that the rate
limiting will work well. I don't know how much value there is in
protecting these mappings.
Temi: if the mapping is just CSIāMSP, is that all that sensitive?
Jon: if i send a message to $CSI@$MSP then it'll still go through,
right?
ekr: i go back and forth on the point that Jon was making. if we do
this, it seems like it might constrain the architecture a lot, and we
don't even know how to do it.
Femi: can we establish whetherthis data is sensitive? if so,
dkg: I think this can be sensitive, but maybe not everyone... an example
where it counts, if we have several MSPs like 20, and if a user is
connected to some set of MSPs, could be unique... when a device joins a
network, these connections could be a fingerprint.
femi: I agree its sensitive
Ben Bucksch: this applies also to email, maybe this is already an issue?
Jon: This is input to the CSI... I am not sure I follow...
dkg: My point was enumeration ... fingerprints <... confusiom...>
agreement we are talking past eachother.
dkg: if the db needs to be protected against enumeration attacks,
enumeration is senstivie, because...
ekr: dkg, you are suggesting that connections fingerprint specific
users?
dkg: if you have 20 MSPs, and frequency of use is different, people who
connect to a unique set of MSPs, they are easily identified.
... this by itself is a problem, because of how it can be related to
other data sets.
konrad: this is sensitive information, even with less than 20... even a
single msp can be a problem. You don't want someone to be able to query
the list and figure out a list of all phone numbers that have an account
on a given MSP. if that MSP is marked as "bad", you don't want this
system to provide a trivial lookup of all users of that MSP.
Jon: Not sure that how this is written will help us. there are other
things that we can describe the problem more clearly.
ekr: i think this is nice to do, and we should do it if we can, but if
we can't, we shouldn't stop the whole project. can we make this more
like a SHOULD instead of a MUST?
Ben: I also read this differently: is this trying to defend against an
attack against an MSP, against a user?
Femi: we were advised that a requirement shouldn't assign roles(?)
dkg: I agree with ekr... we should make this a SHOULD.
Alissa: open call for adoption on the mailing list. please take this
discussion back to the list, and spin a new version based on the
feedback here. If you had comments, please let the list know whether the
new version addresses those concerns.
Tim: more interims? what cadence?
Rohan Mahy: i don't want to anything more often than every 2 weeks, and
being able to cancel is fine
Raphael Robert: every 2 weeks is a maximum.
Tim: watch for adoption call on list about room policy draft.