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