On 31 Mar 2019, at 00:19, Tedd Sterr <teddst...@outlook.com> wrote: > > http://logs.xmpp.org/council/2019-03-27?p=h#2019-03-27-237ca0091c8adb57 > > Dave is having a catastrophic day, so would be grateful for skipping the > meeting this week. > Jonas and Georg would like to at least get the vote started on the Compliance > Suites. > Georg volunteers to chair - Dave takes up his generous offer. > > 1) Welcome everybody, roll call! > Present: Georg, Jonas, Link > Distracted: Dave > Apologies: Kev > > 2) Agenda Bashing > Georg has XEP-0412 (XMPP Compliance Suites 2019) and Automatic Trust Transfer > (ATT). > Jonas notes that there is an open PR. > > 3a) Advance to Draft: XEP-0412 XMPP (Compliance Suites 2019) - > https://xmpp.org/extensions/xep-0412.html > Jonas: +1 > Link: +1 > Georg: +1 > Dave: [on-list] (wonder if we should consider a last call once more given the > change of author) > Kev: [pending]
-0. I’m still of the opinion that our current model of Compliance Suites that we update annually, with lots of noise and time, is unhelpful but won’t block progress. > 3b) Proposed XMPP Extension: Automatic Trust Transfer (ATT) - > https://xmpp.org/extensions/inbox/automatic-trust-transfer.html > Link: [on-list] > Jonas: [on-list] > Dave: [on-list] > Georg: [on-list] > Kev: [pending] There’s weirdness here. It’s not clear to me what’s being bought by using a URI for the trust message format, and that URI seems to be OMEMO-specific, although OMEMO is probably not the long-term future, so some genericity seems appropriate here. It talks about Devices with authentication, but until I reached section 6 I was struggling to understand if this is meant to be a user’s own devices, or any device in the graph - I think this would benefit from mentioning much earlier (or in a way that was clearer to idiots like me). I think the MUSTs on trusting anything sent to you from an authenticated device is wrong here - I might have verified that Dave is Dave, but that’s a long way from saying that I trust Dave to verify that Cath is Cath (this seems to be an authc/authz mismatch issue - I may authenticate Dave, but I don’t necessarily authorise him to perform authentication for me), and I very much don’t trust Dave to authenticate my new devices for me (I might have multiple identities, and ‘own device’ is likely to start breaking down here) - and revoking keys here is much worse. It says “authenticate a key” and things like it frequently when I think it means “treat the key as authenticated” or somesuch. There’s a fun amplification attack here, which probably needs mentioning. "A client MUST save the information of a trust message until the key of the device which sent the trust message is authenticated, so that the key can then be authenticated or revoked” - That seems well-intentioned but open to abuse from malicious users. There are also fun race conditions - you can easily send an approval, then revoke the key you sent the approval to, then revoke the key you approved, and then log in the device to which you sent it, leaving dangling approvals that then get added back into the graph. Indeed, on a large graph, it’s easy to end up with revoked keys getting added back in just because of transmission latency (which includes waiting for devices to come online). " If it is not possible to authenticate a key before encrypting with it but it is desired to communicate with the key's device, it is RECOMMENDED to blindly trust new keys until the first authentication has been made.” Is well-intentioned, but I think needs careful wording to avoid just making TOFU the default. Plus, once that new key is blindly trusted, someone’s going to send it out over ATT. And the minor issue that after reading it I don’t immediately understand what the protocol here is. -1 - I don’t think it’s possible to implement from the spec as-is, but more crucially I think that there are fundamental security considerations here that are missing (or aren’t obvious enough that I understood them on first reading), and given OMEMO’s history of getting picked up and deployed early I think publishing this right now would be ill-advised > 3c) PR #764 - XEP-0308: Clarify correcting a message multiple times > -https://github.com/xsf/xeps/pull/764 > Link thinks this will break existing clients which correct based on the > previous ID (rather than the original, as this PR does) - Jonas believes it > should. > > Jonas: +1 (it's the obvious reading of the XEP in my opinion, though others > may have their own 'obvious readings'; we should pick an official obvious > reading) > Dave: [on-list] > Georg: -1 (the XEP is in dire need of clarification, but it's more logical to > correct the last message, not the first, e.g. when fetching partial MUC > history) > Link: 0 (will break clients, but so will the other way, even if that seems > more logical to me) > Kev: [pending] +1. And whether Georg is right about it being more logical or not, this is a clarification that follows from the existing text that says that correction affects a message’s payloads, not its identity, i-not a change of behaviour and so is largely Editorial. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
