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)