TID: FMail-W32 2.1.3.7-B20170919   
   RFC-X-No-Archive: Yes   
   TZUTC: 0100   
   CHRS: CP850 2   
   MSGID: 2:280/5555 5dfbef8c   
   REPLY: 2:310/31 5df9e7c6   
   Hello Richard,   
      
   On Wednesday December 18 2019 09:38, you wrote to me:   
      
    MV>> That is not a shortcoming of the protocol, it is a shortcoming of   
    MV>> the user.   
      
    RM> But the protocol allows it.   
      
   Binkd is for use by sysops. Sysops are supposed to have more knowledge of   
   these things than Otto Normalverbraucher.   
      
    RM> With client certificates that problem does not exist.   
    RM> (but others do ;))   
      
   Indeed, there are other problems with certificates. such as "how do we know we   
   can trust the CA?"   
      
    RM>>> client certificates are much more secure than eg. 8 digit   
    RM>>> passwords.   
      
    MV>> Binkd session passwords are not limited to 8 characters.   
      
    RM> I know.   
      
   So what is stopping someone from using a much longer password of one feels   
   eight is not enough?   
      
    RM> But many passwords are 8 characters.   
      
   Indeed, some passwords in use in Fidonet are limited to 8 characters. That   
   does not make ALL passwords in Fidonet "weak".   
      
    RM> That is why I put the eg. there.   
      
    MV>> A properly choosen 25 byte string is impossible to guess I'd say.   
    MV>> A brute force attack won't work very well with binkd either. So I   
    MV>> don't think that part of binkd can be considered "weak".   
      
    RM> If you are using a good password, then yes.   
      
   So I see no problem.   
      
    RM>>> I doubt that that added value is "worth it" in fidonet, where   
    RM>>> many people used ancient software, and only a small minority is   
    RM>>> interested to roll out new features.   
      
   Don't fix it if it ain't broke...   
      
    MV>> Frankly I see no significant added value at this point. It just   
    MV>> adds overhead...   
      
    RM> I have the gut feeling that proper implemented TLS is much more secure   
    RM> against crypto analysis then the current crypt implementation. And no,   
    RM> it is just a gut feeling, I cannot provide a link to a paper.   
      
   Possibly. Probabably even. My filosofy on this is that the level of protection   
   should match te nature of the threat. "More" sounds nice, but I am not a fan   
   of the "more is better club". I can protect my toilet with 10 cm armour and   
   triple locks against unauthorised use, but that would just make things harder   
   fo myself. Unauthorised use is not a great theat.   
      
    RM>>> Breaking TLS gains you lots of $$$, so many people try it.   
    RM>>> (without any knowledge of then being successful.)   
      
    MV>> I suspect it is already boken by government agencies.   
    MV>> Those are the ones that have the resources...   
      
    RM> Pre Snowden it was not broken.   
      
   1) Snowdon does not know everything.   
      
   2) That was how many years ago?   
      
   Plus that ever so often security is not broken because of a weakness in the   
   algoritm but because of other things. One of the problems with certificats   
   issued by a "trusted authority" is "can I really trust the authority?.   
   Letsencrypt is located in the US. Are they up against a governement that has   
   been proven to install spyware in routers? How about the Patriot Act?   
      
   I very much prefer the block chain like mechanisme of PGP than a US based   
   "trusted authority" ...   
      
    RM> As long as there is no quantum attack ongoing I believe it to be quite   
    RM> secure currently. On the other hand the number of stable QBits in   
    RM> publicly known quantum computers is increasing rapidly. If a   
    RM> government has much more advanced quantum computers, then it is   
    RM> absolutely possible that those codes can be broken.   
      
   In the end only quantum encryption based on quantum entanglement wil be   
   unbreakable. But I do not know if I will live to see that...   
      
    RM>>> (eg. if you break the stunnel, you still are left with the same   
    RM>>> binkp stream that you would have had previously.) And adding a   
    RM>>> TLS option for clients that support it, will not be weaker than   
    RM>>> our existing crypt implementation.   
      
    MV>> Unless you use TLS not in addition to but instead of binkp   
    MV>> session password and CRYPT.   
      
    RM> That was the usecase of just slap a stunnel before the whole thing.   
    RM> I think nobody seriously thought about replacing passwords.   
      
   Are you sure? Binkd session passwords require a pre arranged password with   
   every node that one wants a secure link. TLS only requires each node to have a   
   certificate signed by a trusted authority. Just ONE certificate per node to   
   make secure links between ever pair of nodes. I would say that if this gets   
   widely used, one could easely drop the effort of arraging session password   
   with all others. Thinking TLS it is just as safe without the binkp session   
   password...   
      
    RM>>> The easiest target would be to have a second port where you can   
    RM>>> make stunnel connections. (this is not very practicable from my   
    RM>>> point of view, outside of PoC) Or the second easiest but more   
    RM>>> useable target would be to implement starttls and use it if both   
    RM>>> parties support it.   
      
   I have not made up my mind yet...   
      
    RM>>> (relying on passwords, not client certificates)   
      
   Yep.   
      
    MV>> The Synchronet fans do not seem to like starttls, they want a   
    MV>> diffrent port. So we alreay have two competing standards...   
      
    RM> (Nearly) nobody will use it with a different port.   
      
   Perhaps. It seems cumbesome.   
      
    RM> The only way to gain any traction is to implement it transparently,   
    RM> and if both partners implement the extension, then TLS will be used,   
    RM> otherwise you fallback to the current method.   
      
   Even then. If it is not integrated in binkd I don't give it much of a chance.   
      
    RM> My 2 cents.   
      
   My EU 0.02 also.   
      
      
      
   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