TZUTC: -0800   
   MSGID: 7267.binkd@1:103/705 226279a5   
   REPLY: 2:5030/1997@fidonet 5dfd11a6   
   PID: Synchronet 3.17c-Linux  Dec 12 2019 GCC 6.3.0   
   TID: SBBSecho 3.10-Linux r3.148 Dec 12 2019 GCC 6.3.0   
   COLS: 80   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.103   
     Re: BINKP over TLS   
     By: Alexey Fayans to Rob Swindell on Fri Dec 20 2019 09:09 pm   
      
    > Hello Rob!   
    >   
    > On Fri, 20 Dec 2019 at 09:56 -0800, you wrote to me:   
    >   
    >  >> Isn't it your main argument against STARTTLS?   
    >  RS> Under no case is Opportunistic TLS (e.g. STARTTLS) as secure as   
    >  RS> Implicit TLS.   
    >   
    > So far you didn't provide a single fact proving that good STARTTLS   
    > implementation is less secure than TLS on a dedicated port.   
      
   Opportunistic TLS gives both the client and the server (or a MitM) the ability   
   to "opt-out" of using TLS. With an Implicit TLS session, no such option is   
   availble; the entire TCP session is secure, or it doesn't exist.   
      
    >  RS> Yes, the use of self-signed certs is less secure than   
    >  RS> CA-signed certs, but that's a different matter and true for both   
    >  RS> Opportunistic and Implicit TLS.   
    >   
    > 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.   
      
   A less funny joke than Binkd's CRYPT option. Seriously.   
      
    >  >> 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?   
      
   NNTP, FTP, IRC.   
      
    > 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.   
      
   Security is a moving target. If you're going to implement something, as I have   
   with binkps, you shoot for the state of the art, today's best practices, not   
   yesterday's. STARTTLS is yesterday's solution to TCP session security and is   
   being phased-out. It would be silly to implement STARTTLS in a newly-defined   
   TCP applictaion protocol today.   
      
                                               digital man   
      
   Synchronet/BBS Terminology Definition #35:   
   HTTP = Hypertext Transfer Protocol   
   Norco, CA WX: 71.9øF, 20.0% humidity, 1 mph W wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.10-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 218/700 221/0 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 712/848 770/1 2452/250   
   PATH: 103/705 280/464 229/426