Subj : BINKP over TLS To : Alan Ianson From : Alexey Fayans Date : Fri Dec 20 2019 15:41:00 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) .