:boost_requested: Pitching a new federation protocolpolyproto is an up-and-coming federation protocol with features like lossless account migration, resilience against loss of identity because of homeserver shutdown and tamper-resistant data exchange inherent to how it works under the hood.
The best part is that it doesn't re-invent the wheel, and builds on extremely well-known and widely used technologies such as X.509 (the technology powering all the SSL/TLS certificates—the thingies responsible for the padlock 🔒 symbol in your browser), regular ol' digital signature schemes, JSON, HTTP and Websockets.
If you are so inclined, feel free to find out more at polyproto.org or feel free to polyproto.org/docs/protocols/core (which I have tried my best to write in a way that doesn't induce a deep sleep on the reader).
The project wants to eventually yield a federated, self-hosted Discord alternative usable by everyone, not just computer nerds, and hosts it's source code at codeberg.org/polyphony . It is not currently in any usable or demoable state, sadly, but that is being worked on.
shouldn't the signature field in 3.2.3.5 have some seperator or such defined to deal with canonicalization problems?
Well, if anything, this would apply to the way the concatenation operation works, not the resulting signature. But that might be a good point, especially since this is already defined later in the spec. It should be referenced there.
also how does/would compression deal with mixing secret and untrusted data?
Could you perhaps elaborate on this question? I don't quite understand what it means
> how is server authentication handled? is it pki or something else?
Well, "authentication" means a lot of things, and there are different steps involved (I.e. cold-auth (logging in or registering) vs. hot-auth (using a session token to re-authenticate further requests). I have been thinking about how to handle authentication for a while now, and while the protocol already describes authentication paradigms to ensure requests are, well, authenticated properly, there's stuff like "How do we do registration and login" which are not yet part of the protocol. To make a long story short, I have been considering using OIDC for this, as it is yet another well-known, trusted standard, implemented by many and with vast community support in all sorts of programming languages—just like all the other technologies polyproto builds on. I think that this will be the way to proceed with this, and I want to draft some specifics about OIDC very soon, after I took yet another look at it, deciding whether it is truly a great fit for the protocol.
Thank you for the questions c: please do feel free to ask more!
about compression: I'm referring to attacks such as CRIME and BREACH (both against TLS). As an example, if you can get an account to post arbitrary data (@keysmash is a good example) AND you can monitor the ciphertext going between it's client and server AND session tokens are compressed together with the post, then you can recover the token (see the exploits for how).
about auth: I'm referring to authenticating that the client is talking to the real homeserver/remote server instead of a MITM, not authenticating clients. I was unclear, sorry.
re: security questions@luna Ah! I have not actually yet heard of BREACH and CRIME, so a million billion thanksies for letting me know! I'll research that then!
1
1
2
1
1
1
1
1
1