Could you elaborate on how you would the key negotiation. While it's always interesting to hear the how others would make things different, or maybe their design is based on different assumptions/starting points, I think it's also relevant to this discussion.
Basically I see this as one of the highest security use-cases we have in XMPP. Since this protocol will give access to plain offline messages, even those that have been encrypted with OMEMO, OX or any other technology before, there is absolutely no room for security compromise here. That's why I'm planning a two-step negotiation mechanism that is performed with as little server involvement as possible. The first step would be opening a peer-to-peer channel and agreeing on the crypto primitives used (in a downgrade-protected manner), the second step would be confirming the absence of a MITM and enabling encryption of the p2p channel. This might sound horrible for usability, but the way I'm envisioning it, it would be fully automated and enabled by quick and comfortable QR-code scans. I'll create a quick and dirty draft so that we have a better basis for discussion.
In any case, I think most specifications are simply abandoned due the lack of implementation(s). Many probably never ever had a prototype implementation, let alone two interoperable implementations.
Okay that's good to know and matches my impression, thanks :)
Isn't "all we need"™ an encryption/authentication layer over (bidirectional) streams potentially negotiated by Jingle?
Yes exactly, just that ^^
And for the latter, there is the <security/> element which JET (xep391) / jingle-xtls also uses. - Florian
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
