MLS @ IETF 102 2018-07-29 @ 09:30 EDT ================================ # 0. 10min Administrivia (Chairs) No actions. # 1. 05min Charter Review (10Kft level) https://datatracker.ietf.org/group/mls/about/ No actions. # 2. 10min Architecture (Emad) https://datatracker.ietf.org/doc/draft-omara-mls-architecture/ rlb: Yes, the draft should provide guidance on key update defaults, but allow flexibility. Philip P: Shouldn't be based on the strength of keys? Raphael Robert: I don't think the server should be trusted. Benjamin Beurdouche: The suggestion to provide guidance is a good idea. Stanislav Smyshlyaev: I totally agree we should provide guidance. ekr: Yes, we should provide guidance on key update, and guide people on how to think about the problem, too. - The server should not be trusted to manage group membership, but it should be trusted to note group membership. - We should not do anything about traffic analysis mitigation here. Jon Millican: We should we include guidance that makes sense for small (0 - 10) and large ( 50k+) groups. Emad: The guidance can be when you are sending versus just receiving. Jon M: We need to be careful, in case *any* member is compromised. However, I agree with you. dkg: I recommend framing it as min/max guidance. - I think we shouldn't get too deep into multi-device for privacy reasons. - We need to include a mechanism for padding, but do not have to define specifics. Lucia B: Having a recommendation would be useful, but a strict requirement will hinder adoption. Bob Moskowitz: Good guidance for different class of scenarioes would be most useful. - I think group membership store is out of scope for MLS. - MLS needs to include traffic analysis mitigation for itself. Karthik: It's important to ask what to expect for group membership at this stage, should all members maintain the list of be able to query for it? rlb: Largely +1 on other points (from key updates) - You might have a subtree of the devices under the overall tree of user members, but we don't need to get into the details of device hiding right now. - We might use the server to be a group membership cache, but not require it to store the full tree (group state but no identity information) - Not worried about protecting key exchange messages, but with actual message protection scheme (and we should have some mechanism left to apps to define). ACTIONS: Authors will add min/max recommended guidance on key updates. Authors will await further discussion on whether the group membership server is authoritative. Authors will add a reserve space for traffic analysis mitigation without details. Room consensus is to adopt -mls-architecture as a WG item (to be confirmed on list). # 3. 25min Handshake message ordering / server trust (Emad) rlb: The architecture document should have a clear statement on handshaking. - If the client can rely on forced order delivery, then their implementation becomes simpler. - Comfortable with server-enforced ordering, as long as don't trust to guarantee service emad: My concern with server trust is specific denials, but we can mitigate that dkg: The requirements note the client must be able to detect out-of-order delivery. - I don't know what this means in a distributed messaging system. rlb: The risk here is with handshake messages that the key messages rely on a certain state. - If they are not delivered in the same order to all clients, then the clients have an inconsistent state. - The goal is for clients to agree on the cryptographic state of the group membership. ekr: The system can't guarantee order with simultaneous updates from two different clients. - We can guarantee messages from a given client are delivered in the same order. - There are limits to what is possible, but we should be able to detect suppressed or reordered messages. Raphael Robert: This should be part of the -mls-architecture document. - We need a way for clients to depend on the order without relying on the server, and that is difficult. - The ordering requirement comes down to ART vs. TreeKEM, and the best solution is to trust the server to enforce ordering. - I don't think starvation is a problem if just worried about handshake messages. Jonathan Lennox: The problem with starvation is genuine overload vs a malicious server, and you should be able to detect that difference. Bob: Where's the state machine here? We should have the state machine before we can talk about ordering. - Starvation is DoS attacks, and we should understand that. Jon Millican: It is desireable if the server could do nothing to compromise security short of denial of delivery. rlb: The order that is important to preserve is the order that messages are delivered; two-phase commit is useful there. - I think it's worth adding a section on starvation, and the server can help for client-side issues. - I'm surprised federation hasn't come up with this ordering requirement. daniel franke: We can't absolute order, but we can use things like vector clocks to track relative ordering. michael motavsky: Messages specific to state are important to preserve ordering and maybe bound cryptographically, but others it doesn't matter as much. We should separate those more. Leif Johansson: Thinking about the federated case, would it make sense to indicate to the user whether or not there is message order contention. michael motavsky: There's not much you can do with respect to starvation, you might want to create a mechanism to allow the client to back out until a recovery mechanism is in place if they were unable to participate for a period. Brian Weiss: We are trying to trust clients (or not trust anyone) but not servers, and that's not clear in these requirements. That should be clarified. Jon Millican: With locked-out clients, the protocol might be able to automatically expire clients somehow. rlb: We should have consideration on how to detect starvation that we can address when appropriate. We should docuement it can happen, and what the server can do to help in the face of malicious clients. ACTIONS: Authors should add this to the -mls-architecture document. Authors should add the server enforces a delivery order, and provision for clients to detect ordering. Authors should add discussion on starvation and guidance for servers in the face of malicious clients. # 4. 25min ART vs. TreeKEM vs. both (Jon) rlb: What do we need for right now to move forward: which of these do we want to keep? Right now it's "use either", but that's not ideal. They are mostly interchangeable, so maybe we can pick one for now and swap later after further analysis. - I don't think there's a strong winner here. Katriel: I would like to hear on-list from pro-federation people on concurrency concerns. Stansilav: We really need to analyze TreeKEM properties, and CFRG can help with that. - Both constructions are so similar we can get away with either or both, but I prefer ART's construction Benjamin Beurdocuche: We should keep both in the spec for now. Both need more analysis, and they are so similar. Karthik: There are a lot of purposeful commonalities to keep other open questions orthoganal to the ratchet mechanism. - We hope to address the analysis question in the coming moths. rlb: Despite the requirement for consistency, it doesn't require blockchain serialization. - It's important to understand the lifetime of an epoch, and when it is ok to discard for a later one. - The delivery consistency makes this a little easier, but it doesn't necessarily mean TreeKEM is better here. - We should operate under the assumption both are secure, and work and pick the one that is better operationally. - Having two makes life hard. Ben Kaduk: Don't send the document to the IESG with both, pick one before submitting! Raphael Robert: ART vs TreeKEM has a big impact on passive members, and has impact on key update guidance. - ART is expensive for passive members to calculate the group key every update, that TreeKEM does not require. rlb: With regard to epochs, we have the problem for self updates as well as group updates. - We need to have a convergence algorithm to reach a consistent state. - Recommend keeping things ambiguous for now to work it out in a "hackathon" in Sept. - Maybe we cross the trees: If we think updates are super-frequent, we use TreeKEM to keep them efficient and ART for adds/removes? - The keys are derived differently, but they are still public keys. Katriel: /facepalm Shivan: If we go with both options, then we detail the pros/cons better, either here or in a separate draft. Emad: There is still O(n*log(n)) for public key ops (for the actor only, though). Actions: No actions # 5. 25min Message Protection (Benjamin w/ local support from Richard) ekr: What does the "Weakened Forward Secrecy (if you never send)" mean? The key is never used ... Benjamin B: The keys are kept for a long time. ekr: If the group is always ratcheting, then keeping around an unused key is not an actual risk. rlb: I agree we should get something in the -mls-protocol document. - Comparing the key schedule, the "killer app" is the reduced storage (favoring group ratcheting) - Not sure the ordering will be a big problem. - We should keep one of these and swap it out if needed. - I recommend the signature be mandatory. Benjamin B: I would like the signature for handshake messages, but maybe not for content messages. rib: I think we should have it as the default. dkg: I also don't see the forward secrecy advantages for group ratcheting, and sender ratcheting is the clear winner. ekr: I'm concerned about the window of state a receiver needs to keep to deal with reordering. -- missed (minute taker in mic line) -- emad: Per-participant makes more sense. Jon Macillican: I'm concerned that we build for low-end devices as well as iPhone X (-: Jonathan Lennox: If you want per-participant signatures, you'll need that key which will be **much** larger that these keys. ACTIONS: Authors to discuss amongst themselves about next steps. # 6. 25min Authentication (Richard) Jon Millican: When clients have the full list, why not store the entire tree for removes? rlb: I think it's totally plausible clients have the entire tree, but the hard part is initializing that tree for new clients. Jon Millican: concerns -- It seems require the server to store more metadata. Why not have the server store the entire tree + commitment. rlb: If you have the commitment of tree-over-tree, the server could strip out identity bits (keeping less metadata), and use OOB for identity information. Karthik: Hard to get PCS with signature keys, because of long-lived identity keys. Benjamin might have a method of mitigating that, but I'm less worried about the authentication keys vs. confidentiality keys. Lucia Ballard: What are the authentication properties for receivers (how do I validate long-term passive participants are still valid)? rlb: Mostly concerned about joins; the simplistic model is to retransmit the transcript of the changes. Benjamin B: I don't like signing things with a long-term identity key, but we could get better by having ephemeral signature keys. - For denialability if we disconnect the identity key from the group key (??). - In general, this should not impede progress. rlb: These schemes for denialability and PCS are additive, so we can assume we have long-term identity keys for now and add short-term signature keys later. Stanislav Smyshlyaev: If we have long-term identity keys, then these proposals are fine. - Do we want to give recommendations for users that want to be truly anonymous (e.g., provide an OOB mechanism)? rlb: The authentication server is mostly separate, so the credential here could be opaque for group key operations, but means something to the authentication server. Stanislav Smyshlyaev: It would be very good to have recommendations to protect privacy cases. Raphael Robert: The attacker might be able to compromise group key and identity keys with local access, but the mostly separated architecture protects from most other parallel attacks. - The only pratcial approach is to have optional denialabity in order to move forward for now. dkg: Potential user experience confusion in SIGMA because of a success in one part but a failure in another, unless we expect "all or none" for validation. - We should add guidance for what happens for partial SIGMA failures. # 7. Working Group Actions The consensus in the room to adopt the https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/ draft in the WG. # A. 25min A.O.B ## A.1 Versioning / extensibility ## A.2 Interop testing framework ## A.3 Interim plans (Late sept, Berlin?) To be announced.