Subj : Binkd and TLS
To   : Michiel van der Vlist
From : Richard Menedetter
Date : Wed Dec 18 2019 09:38 am

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)

.