Subj : BINKP over TLS
To   : Rob Swindell
From : Alexey Fayans
Date : Fri Dec 20 2019 01:24 am

Hello Rob!

On Wed, 18 Dec 2019 at 20:54 -0800, you wrote to me:

RS> binkps requires no protocol change, therefore will be adopted way
RS> faster.

Explain, how can something that requires manual configuration changes be
adopted way faster than something that doesn't, if at all?

>> 1.2. Can work out of the box without additional configuration.
RS> Not sure what "box" you're referring to, but there's currently no
RS> BinkP mailers that support STARTTLS, so how could you possibly know
RS> what configuration will be needed?

I mean that STARTTLS-enabled mailers will continue to connect with older
versions and vice versa, and once both sides support STARTTLS, it will start
working without any additional actions or configuration changes.

>> 1.3. Requires significantly less software modified.
RS> I actually implemented binkps is less than an 30 minutes.

I already explained what I mean. Not a protocol implementation on a single
node, but whole infrastructure to make it all work on all nodes.

Or in other words, why my binkp still not using TLS when connecting to your
node? Do you get what I mean?

>> 1.4. Not less secure than TLS on a dedicated port because it is
>> possible to announce TLS support via nodelist.
RS> STARTTLS is well known to be less secure than Implicit TLS:
RS> https://www.agwa.name/blog/post/starttls_considered_harmful

I already said a few times that this and other articles criticize existing
implementations flaws. I will say that again. If designed properly, it will be
as secure as TLS on a dedicated port, just more flexible. And FIDONET ecosystem
allows that.

>> 2. For any kind of TLS something must be decided on certificate
>> authority.
RS> Nope. Self-signed certificates provide privacy via TLS just fine.
RS> A CA is only needed if you're going to use TLS for trust. If you're
RS> only using TLS for privacy, then a CA-signed certificate is not
RS> needed.

The whole sentence is wrong. CA is required to make sure that the certificate
provided by server was not replaced by an attacker during MitM attack. With
self-signed certificate you can never tell that you are connecting to the real
system, unless you know a CA pubkey used to sign that self-signed certificate.
That's kinda basic stuff.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)