Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    BINKD    |    Support for the Internet BinKD mailer    |    8,958 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 6,482 of 8,958    |
|    Michiel van der Vlist to Alan Ianson    |
|    Binkd and TLS    |
|    17 Dec 19 13:13:01    |
      TID: FMail-W32 2.1.3.7-B20170919       RFC-X-No-Archive: Yes       TZUTC: 0100       CHRS: CP850 2       MSGID: 2:280/5555 5df8c8af       REPLY: 1:153/757 5df8b39b       Hello Alan,              On Tuesday December 17 2019 02:19, you wrote to me:               MV>> Then what problem ARE we trying to fix?               AI> We are not trying to fix problems. We are trying to be secure.              "Secure" is meaningless without specifying against WHAT. What threats are we       securing against?               MV>> Apples and oranges. Nobogus solved problems created by rouge        MV>> CLIENTS. TLS does not protect against that. It only authorises        MV>> the /server/, not the /client/.               AI> TLS needs to be supported and used by both client and server.              I know that. But it is designed for a client/server model. It verifies to the       client that the server is who it claims to be. Not the other way around. (Not       in the standard impelmentatios anyway) The TLS verification mechanism protects       the client against being redirected to a rogue server. It does not protect the       server against a maliciouis client. For that there usually is identification       on the application level. Often called log in. So TLS does not protect against       someone with evil intentions to connect to your binkp server and do something       malicious.               MV>> In what way is TLS "better"? A claim of "better" security has to        MV>> be more specific than just that. Better than what? Better against        MV>> what threats and by whom?               AI> I can't answer why, I don't know all the reasons why. TLS is the        AI> standard method used today to secure traffic on the internet,              That does not make it better for use in Fidonet. Fidonet is not the InterNet,       it just makes use of it.               AI> and I would like to be secure.              You keep saying that, but you can't explain against what we are securing and       you can't explain why using TLS is more secure than using the security binkp       already has,               AI> We could also just stand still and see how it goes.              If you do not know what you are doing, "do nothing" ain't such a bad       strategy...               AI> I am just being proactive WRT security.              In order to move forward, one first has to know which direction matches       "forward".               AI>>> It does require some setup. Synchronet's BinkIT mailer currently        AI>>> has support for a binkps listener setup like this in        AI>>> Synchronet's services.ini               MV>> The world of Fidonet is bigger than Synchronet (Thank god). You        MV>> make it sound like "Synchronet supports it, so it must be a good        MV>> thing". Sorry, I am not of the "Synchronet is better" club.               AI> True. I want us all to be secure regardless of our choice of software.              I am not convinced that adding TLS to binkp enhances security. Especially with       security, just "moving forward" withou knowing exactly what you are doing is a       bad idea. You may actually be less secure after the move.               AI>>> This was all done without changing binkp. We have simply put        AI>>> binkp on a secure channel.               MV>> But why? I still have no answer for that. Let me put it this way:               MV>> If binkd over TLS is the solution, what is the problem?               AI> There is no problem here that we are trying to solve.              If there is no problem then why add TLS to binkp?               AI> Binkd currently supports an option called CRYPT, for the purposes of        AI> security.              First there is the session password. That protects the server against a rogue       client posing as a trusted party.               AI> That was a good option when it was implemented.              What makes you think the CRYPT option of binkp is no longer a good option?               AI> Today TLS is used for the purposes of security.              It is used by many. That's no guarantee it is "better".               AI> I could be all wrong but I think TLS is a better option, that's all.              When it concern security I'd rather not rely on "think". I prefer demonstrated       facts.               AI> Maybe I said that wrong. How about this. Binkd's CRYPT option is weak        AI> (by todays standards).              In what way is it weak? Has it been cracked? Is there a known vulnerability?       Is there a backdoor? Are there any known cases of damage to Fidonet because of       a weakness in CRYPT?               AI> Maybe we should think about using something more up to date, like TLS.              "More up to date" is not better by definition. With governments that keep       pushing for backdoors in encryption, "someting more up to date" may actually       be a step back.              Cheers, Michiel              --- GoldED+/W32-MSVC 1.1.5-b20170303        * Origin: http://www.vlist.eu (2:280/5555)       SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 6 227/114 229/101 200       SEEN-BY: 229/354 426 1014 240/5832 249/307 317 280/464 5003 5555 292/854       SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250 5019/40       SEEN-BY: 5020/1042 5053/58       PATH: 280/5555 464 229/426           |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca