16 Jul
2024
16 Jul
'24
3:14 a.m.
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