TID: FMail-W32 2.1.3.7-B20170919   
   RFC-X-No-Archive: Yes   
   TZUTC: 0100   
   CHRS: CP850 2   
   MSGID: 2:280/5555 5df8f26b   
   REPLY: 2:310/31 5df8dd29   
   Hello Richard,   
      
   On Tuesday December 17 2019 14:31, you wrote to me:   
      
    RM> But this does not make it less standard, only less used. You can   
    RM> import a client certificate into Firefox and other browsers for a long   
    RM> period of time. And you can use this as a more secure means of   
    RM> authentication.   
      
   OK, "less used" describes it better than "non standard".   
      
    RM>>> But naturally then every client needs a signed certificate, and   
    RM>>> the server needs to verify that client certificate.   
      
    MV>> Indeed. And what is the added value of that?   
      
    RM> There is potential value. (eg. passwords can be very easy to guess ...   
    RM> toor, passw0rd, ...)   
      
   That is not a shortcoming of the protocol, it is a shortcoming of the user.   
      
    RM> client certificates are much more secure than eg. 8 digit passwords.   
      
   Binkd session passwords are not limited to 8 characters. I just tried a 25   
   byte string and it functions. I say "bytes" because I inserted a cyrillic   
   UTF-8 character. Changing the last byte results in a password error, so all   
   bytes are used. Case sensitive. I don't know what the limit is, but it is at   
   least 25.   
      
   A properly choosen 25 byte string is impossible to guess I'd say. A brute   
   force attack won't work very well with binkd either. So I don't think that   
   part of binkd can be considered "weak".   
      
    RM> I doubt that that added value is "worth it" in fidonet, where many   
    RM> people used ancient software, and only a small minority is interested   
    RM> to roll out new features.   
      
   Frankly I see no significant added value at this point. It just adds   
   overhead...   
      
    MV>> Binkp's CRYPT protects against unauthorised listeners on the   
    MV>> channel. I am not aware of binkp's security being compromised.   
      
    RM> I am also not aware of it. But you have to admit that security   
    RM> researchers have more prestigeous targets then binkd crypt. (So I   
    RM> assume that it was never really challenged and analyzed.)   
      
   Yes, there is that. It was probably never really challenged.   
      
    RM> Breaking TLS gains you lots of $$$, so many people try it. (without   
    RM> any knowledge of then being successful.)   
      
   I suspect it is already boken by government agencies. Those are the ones that   
   have the resources...   
      
    MV>> Plus that I still wonder what we are protecting against whom. Do   
    MV>> we really need 10 cm armour and triple locks to protect Fidonet   
    MV>> content?   
      
    RM> Why not? ;)   
    RM> Using binkp in a stunnel definitely will not weaken the security.   
      
   Not if you do it right. If you do it wrong....   
      
    RM> (eg. if you break the stunnel, you still are left with the same binkp   
    RM> stream that you would have had previously.) And adding a TLS option   
    RM> for clients that support it, will not be weaker than our existing   
    RM> crypt implementation.   
      
   Unless you use TLS not in addition to but instead of binkp session password   
   and CRYPT.   
      
    RM> So it is doable, and would benefit security from my point of view.   
    RM> But I do not think many people would use it.   
      
   Like I said before, I may give it a try just for the sake of the technical   
   challenge. I don't consider the added security of such magnitude that I'd   
   start using it large scale..   
      
    RM> The easiest target would be to have a second port where you can make   
    RM> stunnel connections. (this is not very practicable from my point of   
    RM> view, outside of PoC) Or the second easiest but more useable target   
    RM> would be to implement starttls and use it if both parties support it.   
    RM> (relying on passwords, not client certificates)   
      
   The Synchronet fans do not seem to like starttls, they want a diffrent port.   
   So we alreay have two competing standards...   
      
      
   Cheers, Michiel   
      
   --- GoldED+/W32-MSVC 1.1.5-b20170303   
    * Origin: http://www.vlist.eu (2:280/5555)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 6 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 5019/40   
   SEEN-BY: 5020/1042 5053/58   
   PATH: 280/5555 464 229/426