MSGID: 2:5030/1997@fidonet 5dfbf8b7   
   REPLY: 7252.binkd@1:103/705 226054d9   
   CHRS: CP866 2   
   TZUTC: 0300   
   TID: FastEcho 1.46.1 43272   
   Hello Rob!   
      
   On Wed, 18 Dec 2019 at 20:54 -0800, you wrote to me:   
      
    RS> binkps requires no protocol change, therefore will be adopted way   
    RS> faster.   
      
   Explain, how can something that requires manual configuration changes be   
   adopted way faster than something that doesn't, if at all?   
      
    >> 1.2. Can work out of the box without additional configuration.   
    RS> Not sure what "box" you're referring to, but there's currently no   
    RS> BinkP mailers that support STARTTLS, so how could you possibly know   
    RS> what configuration will be needed?   
      
   I mean that STARTTLS-enabled mailers will continue to connect with older   
   versions and vice versa, and once both sides support STARTTLS, it will start   
   working without any additional actions or configuration changes.   
      
    >> 1.3. Requires significantly less software modified.   
    RS> I actually implemented binkps is less than an 30 minutes.   
      
   I already explained what I mean. Not a protocol implementation on a single   
   node, but whole infrastructure to make it all work on all nodes.   
      
   Or in other words, why my binkp still not using TLS when connecting to your   
   node? Do you get what I mean?   
      
    >> 1.4. Not less secure than TLS on a dedicated port because it is   
    >> possible to announce TLS support via nodelist.   
    RS> STARTTLS is well known to be less secure than Implicit TLS:   
    RS> https://www.agwa.name/blog/post/starttls_considered_harmful   
      
   I already said a few times that this and other articles criticize existing   
   implementations flaws. I will say that again. If designed properly, it will be   
   as secure as TLS on a dedicated port, just more flexible. And FIDONET   
   ecosystem allows that.   
      
    >> 2. For any kind of TLS something must be decided on certificate   
    >> authority.   
    RS> Nope. Self-signed certificates provide privacy via TLS just fine.   
    RS> A CA is only needed if you're going to use TLS for trust. If you're   
    RS> only using TLS for privacy, then a CA-signed certificate is not   
    RS> needed.   
      
   The whole sentence is wrong. CA is required to make sure that the certificate   
   provided by server was not replaced by an attacker during MitM attack. With   
   self-signed certificate you can never tell that you are connecting to the real   
   system, unless you know a CA pubkey used to sign that self-signed certificate.   
   That's kinda basic stuff.   
      
      
   ... 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