Hello Alan!

On Thu, 19 Dec 2019 at 14:41 -0800, you wrote to me:

 AI>>> I don't think STARTTLS is what we want today.
 AF>> Why?
 AI> Because of what I have read others say on the subject. I really have
 AI> no good idea why it is frowned upon.

Well, it's not a strong argument you know.

 AI> The first encounter I had with binkps was about a year ago when
 AI> SSL/TLS was introduced in Mystic. Mystic has oppotunistic SSL/TLS
 AI> support. It had to be oppotunistic since James knew at the outset
 AI> there would be mailers in the mix that did not support SSL/TLS. James
 AI> received a lot of feedback on the subject that implicit TLS was the
 AI> way to go rather that Opportunistic.

Yeah, I guess similar to something I read here. Just some criticism of existing
imperfect implementations.

 AI> Since then I have looked up the subject. There is a mountain of
 AI> information on the subject and I have not read it all, but I don't see
 AI> folks adopting STARTTLS today, only depricating it.

Any examples of real deprecations? Even if there are, I bet only
implementations where client cannot verify if server supports TLS (like initial
SMTP implementation) are being deprecated.

 AF>> I only see a proposal to deprecate STARTTLS _implementation_ in
 AF>> SMTP and other e-mail protocols because obviously implementation
 AF>> has flaws. If implemented properly, I don't see any reason for
 AF>> deprecation.
 AI> The proposal to depricate STARTTLS is enough for me to depricate it. I
 AI> am relying the the experience of others and best practise today.

Only existing SMTP implementation is deprecated because it was designed in such
a way that client cannot know if server supports TLS.

It's also a good thing to be smart when relying on the experience of others.
You need to understand the reasons why others are making these decisions. And
if these reasons are applicable to the topic (they are not).

 AF>> I don't agree. If it will be implemented this way, I can bet it
 AF>> will be adopted by less than 1% of systems.
 AI> In discussions I have had, I have recieved only possitive feedback on
 AI> the idea of implementing binkps with TLS. I will go ahead and
 AI> implement binkps in my own setup when I can, with nodes who wish it
 AI> and support it.

Sure, it will still less than 1% of all nodes.

 AI> I have done this already with Mystic's mailer (Mystic's implementation
 AI> needs work) and Synchronet's BinkIT mailer. binkps using TLS is a
 AI> reality today for those using the BinkIT mailer. I have successfully
 AI> sent and recieved netmail using Synchronet's BinkIT mailer with binkd
 AI> on the remote side.

I know that it is not hard from technical side. I can even run both TLS and
clear text protocols on the same port via SSLH. What I am talking about is that
it requires some actions from every single node to start using binkps. And
these actions are way more than simple binary update. Knowing how most people
don't like to change configuration I just predict the failure of the protocol
because the majority of sysops will simply ignore it.

 AI> BinkIT's mailer uses implicit TLS and is very secure and I would like
 AI> to be able to do this with binkd as well, since I use binkd on my node
 AI> 153/757.

Let's start talking about "very secure" when there will be a mechanism to
verify/trust peers' certificates. Right now it's as secure as plain text.

 AI> If binkd could listen on a secure TLS port (24553) and poll nodes
 AI> listening on a secure port I'm sure it would be widely accepted
 AI> although I wouldn't guess a pecentage.

Yeah, the problem is that it won't magically start doing that.

 AI> For a start there is the BinkIT mailer that supports TLS now.

Great. How many sysops are using it?

 AI> There are other mailers in use also that likely won't be updated
 AI> (Argus/Irex) but I think the binkd mailer is the most used today
 AI> looking at my own logs. If binkd supported TLS most nodes could use it
 AI> if they choose to.

Have you seen binkd configuration? Currently it is not possible to define a
node supporting two protocols specifying ports. And hardcoding TLS port is not
an option obviously.

And if we imagine that node syntax will be changed, binkd nodelist parser(s)
will need to be updated as well in order to understand nodelist flag where
binkps port is specified (similar to IBN).

 AF>> I am not a true coder, at least, I don't have enough skill/time
 AF>> to implement any kind of TLS support in binkd. If someone will do
 AF>> it, I'll be happy to test.
 AI> I am going to ask some nodes who have done this for advice on how they
 AI> did it and if I can do it will netmail you my findings and we can do
 AI> some testing if you would like.

Sure.


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