: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 Regarding "verifying server identity": Perhaps more can be done here (input wanted!) but I was intending that this would be covered by existing MITM defense mechanisms such as DNSSEC
I guess you could have a HPKP system; that'd significantly challenge a practical MITM attack.That and having servers compare a given servers cert among themselves (A and B co-operate to check that they get the same cert from C). Maybe even have clients helping.
I think doing both would make a MITM practically impossible unless the server is MITM'd right from the start, though there needs to be more threat modeling done for this.
re: security questions@luna Yes, I think that there would need to be additional threat modeling done for a hardened, more security-focused application of the protocol. I'd like your opinion on my comment about DNSSEC, if you don't mind, because you seem knowledgeable and also second opinions can't hurt
DNSSEC has the advantage that you basically have two root key(set)s (DNS root and TLD) instead of god-knows many. Also, not everyone agrees about what PKI roots are trusted, which I imagine is going to be an utter pain in the ass. Problem is getting people to adopt it.
Oh, sidenote: have you thought about using TLS client certificates for authenticating to remote servers instead of a homebrew auth protocol?
have you thought about using TLS client certificates for authenticating to remote servers instead of a homebrew auth protocol?
i think that as an authr/n protocol, OIDC has lots of advantages in terms of how familiar users are with it, and how very versatile it is inherently.
But no, I have not thought about it yet :3
About DNSSEC: I have just read a blogpost by Cloudflare about it, and this sounds very funny:
In the Root Signing Ceremony, several selected individuals from around the world come together and sign the root DNSKEY RRset in a very public and highly audited way. The ceremony produces an RRSIG record that can be used to verify the root name server’s public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, we assume that it’s valid because we trust the security procedures around accessing the private KSK.
I guess my thought process here is: "If this is ok for the entire internet to use, then I think it should be okay for me as well". And, regardless:
- Unencrypted communications are, by design, not private enough to be used in a scenario where security is of a large concern - Encrypted communications lean in clear-text metadata and encrypted in ways that explicitly exclude the relaying server from the circle of trust already mitigate the consequences of a potential PITM (puppy-in-the-middle) attack to a good extent. Encrypted communications over polyproto will follow such a design
re: security questions@luna Fair. I thought that, for the purposes in which I intend the core of this protocol to be used in, the current threat model is sufficient. Other use cases can impose their own additional restrictions and guidelines.
1
1
2
1
1
1
1
1
1