REPLY: 2:5030/1997@fidonet 5df82b49   
   MSGID: 2:280/464.47@fidonet 5df88a07   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: UTF-8 4   
   TZUTC: 0100   
   TID: CrashMail II/Linux 1.7   
    AF>>> No it doesn't. MitM attack can only fool client into thinking   
    AF>>> that TLS is not supported. But you can require TLS on a client   
    AF>>> side and it will just disconnect, no harm done.   
    AI>> I believe it does.   
      
    AF> It's not about believing. You can read on wikipedia for example about   
    AF> MitM and STARTTLS. MitM can fool client into thinking STARTTLS is not   
    AF> supported. Mitigation is requiring encryption on client side. As   
    AF> simple as that.   
      
   If you already know that the other side supports encryption and you want to   
   enforce it, you don't need STARTTLS.   
      
    AI>> I don't think the binkd developers are going to bring STARTTLS to   
    AI>> the table but we need to hear from them.   
      
    AF> Exactly.   
      
   The had plenty of time. binkp is not only used by binkd. Direct TLS works   
   today with binkd with some helper software.   
      
    AF> Synhcronet is not the only software out there. And manual   
    AF> configuration is not even an option. Globally, (1) a new nodelist flag   
    AF> is required to indicate support if binkps and its port;   
      
   Now we need to stop introducing new nodelist flags?   
      
    AF> (2) binkps must be supported on DNS level as well, i.e. _binkps._tcp   
    AF> SRV records;   
      
   not need if you have a nodelist flag. nodelist flag not needed if there is a   
   _binkps._tcp record.   
      
    AF> (3) nodelist parsers must be updated to understand new flag;   
      
   Yeah, you should use a nodelist parser that gets updated occasionally.   
      
    AF>  (4) additional configuration must be introduced in mailers to support   
    AF> binkps, and for binkd it may be an issue since node records were not   
    AF> designed for multiple protocols based on different ports.   
      
   So software has to be updated in both cases, especially the mailer. You still   
   can use unencrypted or CRYPTed sessions, if your software doesn't has support   
   for any new encryption scheme.   
      
    AF> With STARTTLS none of this is a problem. Additional configuration flag   
    AF> to require TLS connection is easy to implement, nodelist flag is   
    AF> optional and may be used to tell client to require TLS when connecting   
    AF> to supporting node, and additional DNS SRV records are not needed as   
    AF> well.   
      
   Do we have a proposal for binkp STARTTLS that doesn't leak unencrypted   
   meta-data?   
      
    * Origin: kakistocracy (2:280/464.47)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 227/114 229/101 200   
   SEEN-BY: 229/354 426 1014 240/5832 249/307 317 280/464 5003 5555 292/854   
   SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250   
   PATH: 280/464 229/426