MSGID: 2:5030/1997@fidonet 5dfd8f09   
   REPLY: 7267.binkd@1:103/705 226279a5   
   CHRS: CP866 2   
   TZUTC: 0300   
   TID: FastEcho 1.46.1 43272   
   Hello Rob!   
      
   On Fri, 20 Dec 2019 at 11:55 -0800, you wrote to me:   
      
    >> So far you didn't provide a single fact proving that good STARTTLS   
    >> implementation is less secure than TLS on a dedicated port.   
    RS> Opportunistic TLS gives both the client and the server (or a MitM) the   
    RS> ability to "opt-out" of using TLS.   
      
   Depends on implementation. Protocol (binkp) may require to drop connection if   
   TLS negotiation fails with a node that supports TLS according to nodelist.   
      
    RS> With an Implicit TLS session, no such option is availble; the entire   
    RS> TCP session is secure, or it doesn't exist.   
      
   And how is it more secure than above?   
      
    >> Use of self-signed certs without a well-defined and implemented   
    >> mandatory mechanism to verify these certs (either trusted CA or any   
    >> other similar way) just turns whole security talk into a joke.   
    >> Seriously.   
    RS> A less funny joke than Binkd's CRYPT option. Seriously.   
      
   Sure, but did I ever speak about it?   
      
    >>  >> Why not? It is perfectly mitigated and I explained that a few   
    >> times   
    >>  >> already. You gotta stop looking back at old SMTP implementation   
    >>  >> that wasn't designed against active MitM attacks in the first   
    >>  >> place.   
    >>  RS> I look at all the applications of Opportunistic TLS and   
    >> they're all   
    >>  RS> less secure than Implicit TLS.   
    >>   
    >> Examples?   
      
    RS> NNTP, FTP, IRC.   
      
   Sure, all very old designs without security in mind. Also, all of these are   
   just services while FIDONET is an ecosystem and has a nodelist where TLS   
   support can be indicated. That makes a perfect platform for a truly secure   
   STARTTLS implementation.   
      
    >> Maybe you are just looking at bad / not suitable implementations.   
    >> Not all implementations are focused on MitM protection and that is   
    >> fine, similar to use of self-signed certs just to make it a bit   
    >> harder to sniff the traffic.   
    RS> Security is a moving target. If you're going to implement something,   
    RS> as I have with binkps, you shoot for the state of the art, today's   
    RS> best practices, not yesterday's.   
      
   Like I said earlier, there is no universal standard for everything. When you   
   design something, you gotta be smart and understand well what you are doing   
   and why.   
      
    RS> STARTTLS is yesterday's solution   
      
   Nope, only a few not very well designed implementations are `yesterdays   
   solution`.   
      
      
    RS> It would be silly to   
    RS> implement STARTTLS in a newly-defined TCP applictaion protocol today.   
      
   Nope, it will be silly to design a protocol that has no future.   
      
      
   ... 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