MSGID: 2:5030/1997@fidonet 5dfcc840   
   REPLY: 1:153/757 5dfc0a31   
   CHRS: CP866 2   
   TZUTC: 0300   
   TID: FastEcho 1.46.1 43272   
   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)   
   SEEN-BY: 1/123 50/109 90/1 103/705 154/10 203/0 221/0 6 227/114 229/101   
   SEEN-BY: 229/200 354 426 1014 240/5832 249/307 317 280/464 5003 5555   
   SEEN-BY: 292/854 310/31 342/200 396/45 423/120 451/30 452/166 463/68   
   SEEN-BY: 469/122 712/848 770/1 2452/250 5000/111 5001/100 5005/49   
   SEEN-BY: 5015/255 5019/40 42 5020/290 329 715 806 828 846 848 921   
   SEEN-BY: 5020/1042 1519 2047 2140 4441 12000 5022/128 5023/12 24 5030/1081   
   SEEN-BY: 5030/1900 1997 5034/13 5053/54 57 58 5054/8 5057/19 5060/900   
   SEEN-BY: 5064/56 5080/68 102 5083/444   
   PATH: 5030/1997 5023/24 5020/715 4441 1042 280/5555 464 229/426