Subj : Is binkp/d's security model kaputt?
To : deon
From : Oli
Date : Fri Sep 03 2021 11:16 am
deon wrote (2021-09-02):
>> I'm trying to figure out how to configure binkd for reliable
>> security. I see several problems. Part design flaw of the binkp
>> protocol (and FTN tradition), part implementation.
>> IMHO binkd/binkp offers lots of pseudo security and several security
>> and usability pitfalls. Are there any good workarounds or do we need
>> a binkp/2.0?
d> So I too, would love to see many improvements - that sees this retro
d> hobby still function (with the retro software), but at the core, it
d> leverages modern technologies for the benefits that they bring (improved
d> security, improved authentication, improved authorisation, alternative
d> transport methods).
For me it's important that it is still simple and works for slow computers and slow connections. And what are modern technologies? Contemporary software is 80% bloat and waste of resources. I'm running Fidonet software, because I don't need 1GB of download and disk space to compile a rust application that does some basic stuff. Or run a messaging server in Python, that wastes a ton of bandwidth and is so complicated that the re-implementation in Go takes forever. Or software where the only supported installation method is a docker container in linux (which installs all the DB software you are already running again).
But that is only a little general rant. I'm very much interested in any new developments in FTN land. What I would like to see is further simplification. The Fidonet standards are a convoluted mess. We have the message as the central building block. I wouldn't touch the message format, because that would break compatibility and would lead to a different network. Everything else can easily be changed. We can use another transmission protocol, just create a nodelist flag (or use DNS SRV records). We don't have to use PKT files (their not even a standard) for transmission. We can get rid of the weird and limited BSO. Tossing / routing could be handled differently ...
d> I actually dont think a binkp/2.0 should do it all (but it probably
d> could). I would also like to see other transport mediums in use - perhaps
d> packet radio, perhaps something like lora - so that systems could
d> communicate independantly of being dependant on a "service provider"
d> (which means whatever is sent between 2 systems should be efficiently
d> sent).
Developing for IoT, low-bandwidth and unreliable connections is not a bad idea. I'm not sure if binkp is the best protocol for these types of transports.
d> I have a few things to sort out with my new mailer, and then I'd be in a
d> position to proto type something new - but I guess that's only useful if
d> there is something else that uses it too. It would be nice to know that
d> other mailer developers were inspired to make enhancements as well.
Good luck with that ;-). Maybe BinkIt, but the rest? Binkd gets only bug fixes and even PRs get ignored. The last time I checked Mystic it was still a binkp/1.0 mailer. ifcico, mbcico, d'bridge, ...?
The best chance would be a drop-in replacement for binkd. Or if it's based on another protocol, something that can run beside the binkp mailer and use the same BSO.
