Subj : BINKP over TLS
To : Alan Ianson
From : Alexey Fayans
Date : Fri Dec 20 2019 03:41 pm
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
* Origin: Music Station |
https://ms.bsrealm.net (2:5030/1997)
