MSGID: 2:5030/1997@fidonet 5df8b29e   
   REPLY: 2:280/464.47@fidonet 5df88a07   
   CHRS: CP866 2   
   TZUTC: 0300   
   TID: FastEcho 1.46.1 43272   
   Hello Oli!   
      
   On Tue, 17 Dec 2019 at 08:33 +0100, you wrote to me:   
      
    AF>> It's not about believing. You can read on wikipedia for example   
    AF>> about MitM and STARTTLS. MitM can fool client into thinking   
    AF>> STARTTLS is not supported. Mitigation is requiring encryption on   
    AF>> client side. As simple as that.   
    Ol> If you already know that the other side supports encryption and you   
    Ol> want to enforce it, you don't need STARTTLS.   
      
   STARTTLS is needed to run TLS on the same port, and I already explained why it   
   is essential to run it on the same port.   
      
    AI>>> I don't think the binkd developers are going to bring STARTTLS   
    AI>>> to the table but we need to hear from them.   
    AF>> Exactly.   
    Ol> The had plenty of time. binkp is not only used by binkd. Direct TLS   
    Ol> works today with binkd with some helper software.   
      
   This implementation is a proof of concept, but obviously will not be adopted   
   by most sysops. And what is the point in security when no-one uses it?   
      
    AF>> Synhcronet is not the only software out there. And manual   
    AF>> configuration is not even an option. Globally, (1) a new nodelist   
    AF>> flag is required to indicate support if binkps and its port;   
    Ol> Now we need to stop introducing new nodelist flags?   
      
   I didn't say that.   
      
    AF>> (2) binkps must be supported on DNS level as well, i.e.   
    AF>> _binkps._tcp SRV records;   
    Ol> not need if you have a nodelist flag. nodelist flag not needed if   
    Ol> there is a _binkps._tcp record.   
      
   That is not true. Some mailers do not support nodelists and rely on DNS. For   
   example, binkd.   
      
    AF>> (3) nodelist parsers must be updated to understand new flag;   
    Ol> Yeah, you should use a nodelist parser that gets updated occasionally.   
      
   Sure. But if something can be done without requiring updates to software, it   
   should be done this way. Less requirements means better adoption.   
      
    AF>>  (4) additional configuration must be introduced in mailers to   
    AF>> support binkps, and for binkd it may be an issue since node   
    AF>> records were not designed for multiple protocols based on   
    AF>> different ports.   
    Ol> So software has to be updated in both cases, especially the mailer.   
      
   Yes, the difference is how big are the updates and how much software will need   
   to be updated.   
      
    Ol> You still can use unencrypted or CRYPTed sessions, if your software   
    Ol> doesn't has support for any new encryption scheme.   
      
   Of course. And I am sure that most sysops will not move to dedicated TLS port   
   because of the complexity. Why designing something that will not be adopted -   
   that is the big question.   
      
    AF>> With STARTTLS none of this is a problem. Additional configuration   
    AF>> flag to require TLS connection is easy to implement, nodelist   
    AF>> flag is optional and may be used to tell client to require TLS   
    AF>> when connecting to supporting node, and additional DNS SRV   
    AF>> records are not needed as well.   
    Ol> Do we have a proposal for binkp STARTTLS that doesn't leak unencrypted   
    Ol> meta-data?   
      
   Client can initiate STARTTLS right away. Server can wait for STARTTLS   
   handshake a few seconds before starting unencrypted session (this will   
   probably introduce a few seconds delay with older mailers). Just an example.   
   Probably developers can think of a better way.   
      
      
   ... 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