Hello Alan!

On Sun, 15 Dec 2019 at 14:12 -0800, you wrote to me:

 AF>> Instead of having binkp tunneled through external TLS connection,
 AF>> something like STARTTLS should be implemented in binkp proto,
 AF>> removing the need of an additional port. This is how TLS works in
 AF>> SMTP on standard 25 port. This way no changes would be needed in
 AF>> either nodelist flags or DNS. If a node supports TLS, it will be
 AF>> negotiated and used. If not, plain-text protocol will be used,
 AF>> unless it is configured to use TLS-only on a supporting node.
 AI> I prefer running TLS on it's own port.

With STARTTLS you can.

 AI> STARTTLS is not a bad thing and would be better than nothing but
 AI> leaves room for a man in the middle attack.

No it doesn't. MitM attack can only fool client into thinking that TLS is not
supported. But you can require TLS on a client side and it will just
disconnect, no harm done.

 AF>> So, what is the rush here? Why trying to push a very poor
 AF>> implementation as soon as possible without involving binkd
 AF>> developers at least?
 AI> I don't think anyone is rushing anything, just moving in that
 AI> direction.

That's a wrong direction. Before moving into some direction it is nice to
weight all opinions, especially ones from current binkd developers.

 AI> Synchronet's implementation is looking good to me. Direct TLS and is
 AI> working in my experience.

Still it requires modification to configurations, nodelist changes and probably
DNS changes as well. STARTTLS would eliminate all of that.

 AI> The binkd developers are most welcome although I am not sure who they
 AI> are. Alexey perhaps but I am not sure. There is some discussion of all
 AI> this in the BINKD area that I have been following and hoping to see
 AI> the binkd developers there.

In fact this doesn't look like a good place to discuss technical stuff, BINKD
seems like a better one.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707