Hello Richard,

On Tuesday December 17 2019 14:31, you wrote to me:

 RM> But this does not make it less standard, only less used. You can
 RM> import a client certificate into Firefox and other browsers for a long
 RM> period of time. And you can use this as a more secure means of
 RM> authentication.

OK, "less used" describes it better than "non standard".

 RM>>> But naturally then every client needs a signed certificate, and
 RM>>> the server needs to verify that client certificate.

 MV>> Indeed. And what is the added value of that?

 RM> There is potential value. (eg. passwords can be very easy to guess ...
 RM> toor, passw0rd, ...)

That is not a shortcoming of the protocol, it is a shortcoming of the user.

 RM> client certificates are much more secure than eg. 8 digit passwords.

Binkd session passwords are not limited to 8 characters. I just tried a 25 byte
string and it functions. I say "bytes" because I inserted a cyrillic UTF-8
character. Changing the last byte results in a password error, so all bytes are
used. Case sensitive. I don't know what the limit is, but it is at least 25.

A properly choosen 25 byte string is impossible to guess I'd say. A brute force
attack won't work very well with binkd either. So I don't think that part of
binkd can be considered "weak".

 RM> I doubt that that added value is "worth it" in fidonet, where many
 RM> people used ancient software, and only a small minority is interested
 RM> to roll out new features.

Frankly I see no significant added value at this point. It just adds
overhead...

 MV>> Binkp's CRYPT protects against unauthorised listeners on the
 MV>> channel. I am not aware of binkp's security being compromised.

 RM> I am also not aware of it. But you have to admit that security
 RM> researchers have more prestigeous targets then binkd crypt. (So I
 RM> assume that it was never really challenged and analyzed.)

Yes, there is that. It was probably never really challenged.

 RM> Breaking TLS gains you lots of $$$, so many people try it. (without
 RM> any knowledge of then being successful.)

I suspect it is already boken by government agencies. Those are the ones that
have the resources...

 MV>> Plus that I still wonder what we are protecting against whom. Do
 MV>> we really need 10 cm armour and triple locks to protect Fidonet
 MV>> content?

 RM> Why not? ;)
 RM> Using binkp in a stunnel definitely will not weaken the security.

Not if you do it right. If you do it wrong....

 RM> (eg. if you break the stunnel, you still are left with the same binkp
 RM> stream that you would have had previously.) And adding a TLS option
 RM> for clients that support it, will not be weaker than our existing
 RM> crypt implementation.

Unless you use TLS not in addition to but instead of binkp session password and
CRYPT.

 RM> So it is doable, and would benefit security from my point of view.
 RM> But I do not think many people would use it.

Like I said before, I may give it a try just for the sake of the technical
challenge. I don't consider the added security of such magnitude that I'd start
using it large scale..

 RM> The easiest target would be to have a second port where you can make
 RM> stunnel connections. (this is not very practicable from my point of
 RM> view, outside of PoC) Or the second easiest but more useable target
 RM> would be to implement starttls and use it if both parties support it.
 RM> (relying on passwords, not client certificates)

The Synchronet fans do not seem to like starttls, they want a diffrent port. So
we alreay have two competing standards...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303