TZUTC: -0800   
   MSGID: 7252.binkd@1:103/705 226054d9   
   REPLY: 2:5030/1997@fidonet 5dfa0049   
   PID: Synchronet 3.17c-Win32  Sep 20 2019 MSC 1922   
   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 Alan Ianson on Wed Dec 18 2019 01:32 pm   
      
    > Hello Alan!   
    >   
    > On Tue, 17 Dec 2019 at 15:02 -0800, you wrote to me:   
    >   
    >  AI> If you have ideas around security in binkd I would send them directly   
    >  AI> to one of the binkd developers. Alexey Vissarionov is someone active   
    >  AI> in Fidonet and is a binkd deveolper I think. That might be a good   
    >  AI> place to start.   
    >   
    > I believe Michael Dukelsky (2:5020/1042) is the last active binkd developer.   
    >   
    > I've already expressed my ideas, but here's a summary:   
    >   
    > 1. STARTTLS is the best option because:   
    > 1.1. It works on the same port and therefore will be adopted way faster.   
      
   binkps requires no protocol change, therefore will be adopted way faster.   
      
    > 1.2. Can work out of the box without additional configuration.   
      
   Not sure what "box" you're referring to, but there's currently no BinkP   
   mailers that support STARTTLS, so how could you possibly know what   
   configuration will be needed?   
      
    > 1.3. Requires significantly less software modified.   
      
   I actually implemented binkps is less than an 30 minutes. I took a working   
   binkp implementation and made it binkps with less than 10 lines of added or   
   changed code. Others have run completely unmodified BinkD over TLS already. So   
   far, nobody has implemented STARTTLS, so there's nothing to compare it to, but   
   comparing it to zero means binkps wins again.   
      
    > 1.4. Not less secure than TLS on a dedicated port because it is possible to   
    > announce TLS support via nodelist.   
      
   STARTTLS is well known to be less secure than Implicit TLS:   
   https://www.agwa.name/blog/post/starttls_considered_harmful   
      
    > 2. For any kind of TLS something must be decided on certificate authority.   
      
   Nope. Self-signed certificates provide privacy via TLS just fine.   
      
    > 2.1. We can use internet CAs, but this will require additional binding of   
    > fidonet address to internet domain, probably, via nodelist. Doesn't look   
    > shiny. 2.2. We can have own CA but this makes fidonet more centralized, we   
    > will also have to define a secure way of issuing and delivering   
    > certificates.   
      
   A CA is only needed if you're going to use TLS for trust. If you're only using   
   TLS for privacy, then a CA-signed certificate is not needed.   
      
                                               digital man   
      
   This Is Spinal Tap quote #41:   
   Ian Faith: It say's "Memphis show cancelled due to lack of advertising funds."   
   Norco, CA WX: 48.4øF, 42.0% humidity, 0 mph SW 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