REPLY: 2:280/5555 5df8f26b   
   MSGID: 2:310/31 5df9e7c6   
   CHRS: LATIN-1 2   
   TZUTC: 0100   
   TID: hpt/lnx 1.9.0-cur 2019-01-08   
   Hi Michiel!   
      
   17 Dec 2019 16:10, from Michiel van der Vlist -> Richard Menedetter:   
      
    RM>> There is potential value. (eg. passwords can be very easy to   
    RM>> guess ... toor, passw0rd, ...)   
    MV> That is not a shortcoming of the protocol, it is a shortcoming of the   
    MV> user.   
      
   But the protocol allows it.   
   With client certificates that problem does not exist.   
   (but others do ;))   
      
    RM>> client certificates are much more secure than eg. 8 digit   
    RM>> passwords.   
    MV> Binkd session passwords are not limited to 8 characters.   
      
   I know.   
   But many passwords are 8 characters.   
   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".   
      
   If you are using a good password, then yes.   
      
    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.   
    MV> Frankly I see no significant added value at this point. It just adds   
    MV> overhead...   
      
   I have the gut feeling that proper implemented TLS is much more secure against   
   crypto analysis then the current crypt implementation.   
   And no, it is just a gut feeling, I cannot provide a link to a paper.   
      
    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...   
      
   Pre Snowden it was not broken.   
   As long as there is no quantum attack ongoing I believe it to be quite secure   
   currently.   
   On the other hand the number of stable QBits in publicly known quantum   
   computers is increasing rapidly.   
   If a government has much more advanced quantum computers, then it is   
   absolutely possible that those codes can be broken.   
      
    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 session   
    MV> password and CRYPT.   
      
   That was the usecase of just slap a stunnel before the whole thing.   
   I think nobody seriously thought about replacing passwords.   
      
    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. (relying on passwords, not client   
    RM>> certificates)   
    MV> The Synchronet fans do not seem to like starttls, they want a diffrent   
    MV> port. So we alreay have two competing standards...   
      
   (Nearly) nobody will use it with a different port.   
      
   The only way to gain any traction is to implement it transparently, and if   
   both partners implement the extension, then TLS will be used, otherwise you   
   fallback to the current method.   
      
   My 2 cents.   
      
   CU, Ricsi   
      
   ... Do what comes naturally now. Seethe and fume and throw a tantrum.   
   --- GoldED+/LNX   
    * Origin: A little enthusiasm never hurt anybody... (2:310/31)   
   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: 310/31 280/464 229/426