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