Subj : Binkd and TLS To : Richard Menedetter From : Michiel van der Vlist Date : Thu Dec 19 2019 10:41 pm 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) .