Just going along that line, but without rewriting FTS-1, or using the idea as a gating method from the new FTS to FTS-1:
We do have mails and we do have files. [...]
Change/evolution in Fidonet has only happened when "someone did it". So, are you available to work on this, not just propose it, take all the blame and see marc lewis take all the credit?
Change/evolution in Fidonet has only happened when "someone did it". AC>WD> So, are you available to work on this, not just propose it, take all AC>WD> the blame and see marc lewis take all the credit?
Thank you for your reminder that this network is not the most
welcoming one.
Am 17.02.22 schrieb Joachim Probst@2:240/6309 in FTSC_PUBLIC:
Hallo Joachim,
Just going along that line, but without rewriting FTS-1, or using the idea as a gating method from the new FTS to FTS-1:
We do have mails and we do have files. [...]
I like that idea. What do the software developers, like Rob or Tim,
think of that?
WHY is there any need for a new packet format?There isn't and wasn't.
It is my belief (in line with some of the points brought up recently), that the fidonet infratstucture should be improved (also on the
software side) to
- make large messages (in the order of magnitude of up to a few MB) a non-issue for most users,
- enable embedding of images and (small) binary data in messages in a compatible way,
and later on
- enable private communication between endpoints (i.e., encrypted authenticated netmail)
- maybe support (well-defined?) HTML mail (quite debateable) or the
like
- enable private communication between endpoints (i.e., encrypted authenticated netmail)
It is my belief (in line with some of the points brought up recently),
that the fidonet infratstucture should be improved (also on the software
side) to
- make large messages (in the order of magnitude of up to a few MB) a
non-issue for most users,
- enable embedding of images and (small) binary data in messages in a
compatible way,
and later on
- enable private communication between endpoints (i.e., encrypted
authenticated netmail)
- maybe support (well-defined?) HTML mail (quite debateable) or the
like
This already exists. It's called email. ;)
It is my belief (in line with some of the points brought up recently),
that the fidonet infratstucture should be improved (also on the software side) to
- make large messages (in the order of magnitude of up to a few MB) a non-issue for most users,
- enable embedding of images and (small) binary data in messages in a compatible way,
Ok, seems we all agree here.
Hmmmmm ... would a totally different zone help? Even just as a test-platform?
Hmmmmm ... would a totally different zone help? Even just as a
test-platform?
I seem to recall something like that being proposed back in the late
1990's in order to facillitate the new-fangled ip based nodes.
A test zone might be something worth investigation
but given the numbers I think it would be wise to stick together as much as possible.
For private messages, there is little sense in competing with email. Surely fidonet netmail is not going to replace email during the next 5 years. However, it makes a lot of sense to provide comparable
capabilities just to enable users to make consistent use of netmail and echomail while having basic capabilities that are just not worse than email 20 years ago. Currently thats not remotely the case.
For private messages, there is little sense in competing with email. Surely fidonet netmail is not going to replace email during the next 5 years. However, it makes a lot of sense to provide comparable capabilities just to enable users to make consistent use of netmail and echomail while having basic capabilities that are just not worse than email 20 years ago. Currently thats not remotely the case.
I don't think I was involved in that...
I don't think I was involved in that...
I forget now who spearheaded the ip fidonet stuff but he was definetly European with a Zone 2 address.
an ad-hoc workgroup and IP-flags were introduced on Nov 11 1998.
He was pretty pissed when I facilitated those flags in the
nodelist
Synchronet and Mystic support direct BINKP over SSL natively which
is a good start to securing transmission.
Of course SSL doesn't stop routed netmail from being read by a SysOp
in the middle though, so in this case Mystic does AES-256 encrypted
netmail if its setup with an encryption key for the address being netmailed.
Synchronet and Mystic support direct BINKP over SSL natively which
is a good start to securing transmission.
It's the most stupid thing that could be done.
The SSL was good 15...20 years ago, but now it doesn't conform to modern
Of course SSL doesn't stop routed netmail from being read by a SysOp in the middle though, so in this case Mystic does AES-256 encrypted
Using the artifically weakened cryptography is a very, very unwise idea.
Synchronet and Mystic support direct BINKP over SSL natively which is a good start to securing transmission.
It's the most stupid thing that could be done.
The SSL was good 15...20 years ago, but now it doesn't conform to modern
Okay so tell me what is better than TLS 1.3 then since you seem to think you know more about security than the entire security industry.
Synchronet and Mystic support direct BINKP over SSL natively
which
It's the most stupid thing that could be done.Okay so tell me what is better than TLS 1.3 then
The SSL was good 15...20 years ago, but now it doesn't conform to
modern
since you seem to think you know more about security than the entire security industry.
Every enterprise on the planet uses an iteration of secure socket
layer most commonly TLS 1.2 in 2022.
If the widespread enterprise-level adoption of AES-256 is inferiorOf course SSL doesn't stop routed netmail from being read by aSysOp
in the middle though, so in this case Mystic does AES-256encrypted
Using the artifically weakened cryptography is a very, very unwise
idea.
and very very unwise for two-way encryption, then please let us (and
the rest of the security world) know what should be used instead?
How will be ever protect our highly classified FidoNet netmail with
the never-been-compromised AES-256? lolol
Assuming there is no future flaw discovered in the algorithm, it
would take every single computer on the planet thousands of years to
brute force a single AES key.
I don't think you could have possibly missed the mark any more than
you did with this post lol.
You both mentioned SSL, not TLS.
Synchronet and Mystic support direct BINKP over SSL natively
When quoting, the correctly written software should add one '>'
character to _the_ _tail_ of existing quote prefix, so /^ XY>>/ should become /^ XY>>>/
Your software fails to quote the text correctly. For example, this word:
which
^^^^^
wasn't written by me.
When quoting, the correctly written software should add one '>'Can you show me where the committee for BBS standards made this law?
character to _the_ _tail_ of existing quote prefix, so /^ XY>>/
should become /^ XY>>>/
Synchronet and Mystic support direct BINKP over SSL natively which is a good start to securing transmission. At one point I had a opportunistic SSL version of BinkP as well.
Of course SSL doesn't stop routed netmail from being read by a SysOp in
the middle though, so in this case Mystic does AES-256 encrypted netmail if its setup with an encryption key for the address being netmailed.
Hello Tim!
24 Feb 22 15:19, you wrote to Wilfred van Velzen:
For private messages, there is little sense in competing with email.
Surely fidonet netmail is not going to replace email during the next 5
years. However, it makes a lot of sense to provide comparable
capabilities just to enable users to make consistent use of netmail and
echomail while having basic capabilities that are just not worse than
email 20 years ago. Currently thats not remotely the case.
E-mail has not changed either in te last 20 years. The only thing that has changed are the user clients that can now display mime encapsulated messages.
Designing a different way of encapsulation for fidonet is hardly productive. Mime encapsulation is not hostile to the content section of fidonet messages.
No changes have to have to be made to Fidonet. The only changes are at the presentation layer, wich is not subject to fidonet standards.
Kees
--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
That already helps a lot. Have to add this. However, this in the end requires some additional information for the clients to connect to be aware of SSL/TLS support !?
The key distribution is the interesting part. Also, probably one should probably employ a combination of asym/sym (e.g., RSA+AES) as usal, so the symmetric keys are used only once.
That already helps a lot. Have to add this. However, this in the end
requires some additional information for the clients to connect to be
aware of SSL/TLS support !?
Yes you are right for direct SSL connections there would need to be some way for a node to know if the connection is compatible with SSL when transmitting netmail via unsecure connections.
Maybe a nodelist flag,
or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP port.
For these reasons, I was experimenting with opportunistic SSL for BINKP. With opportunistic SSL the connection is always on the same port and if both clients support SSL it will convert the connection prior to any authentication.
It also gives us the capability to decide if a connection should be accepted in real-time. For example, if unsecure node then maybe SSL is required otherwise known nodes can use cleartext.
BINKP would be able to make decisions as to what it will and won't allow in "real-time" and then gracefully accept or refuse connections with a proper error message.
We would not require any broader changes (nodelist flags, etc) outside of BINKP client that supports opportunistic SSL extension and it is fully backwards compatible with BINKP that does not support the extension.
A nodelist flag that states that a node may require SSL would still be ideal in the long run, but we would not depend on it for this to work well.
The key distribution is the interesting part. Also, probably one should
probably employ a combination of asym/sym (e.g., RSA+AES) as usal, so
the symmetric keys are used only once.
I agree this would be where the challenge is for unsecure transfer. The AES in Mystic was done a while back and is a bit outdated. It does not have any way to circulate a keystore in a peer-to-peer way so it only works for known nodes.
One thing I found is that many end users didn't really seem to grasp the SSL keystores/certs/keys concepts all that well, so in Mystic I present
an "Encryption password" and when that is set for a known node, Mystic will AES256 encrypt.
Behind the scenes it takes that password and then uses SHA256 to create the actual 256-bit key that is used. It uses AES256-CBC which today
isn't as ideal, but it does use a randomized IV and it does have authentication of the decrypted data to help secure tampering. In 2022 a GCM version would be better though instead of using proprietary means to secure CBC.
One benefit of using this approach is that there is a lot of AES256 code available for just about any language that people can leverage, and I think that would be highly important for adoption.
A nodelist flag that states that a node may require SSL would
still be ideal in the long run, but we would not depend on it for
this to work well.
Having it for information purpose is fine.
Regards,
Tim
or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP TS> JC> TS> JC> TS> JC> port
Better than the nodelist flag. Should be another "unused" port ...
Before it comes up (there is always a troll): probably TLS rather than SSL, but admittedly I also someimes keep talkin about SSL when referring whatever session layer protocol is actually in charge. Educated people know what its about ...
I am not sure if this makes sense. So you want to use an unsecured connection to have the session password transmitted? ;)
This brings us to a potential integration into BinkP itself. That would server the above issues, but overall it is more compliated to implement and does not hide the nature of the communication itself, which maybe a point. (I already see VPN arguments coming up ...)
Jep, straightforward. However, it is not ideal from a security and usability perspective. (No, I have no better proposal at hand for now).
For these reasons, I was experimenting with opportunistic SSL for BINKP. With opportunistic SSL the connection is always on the same port and if both clients support SSL it will convert the connection prior to any authentication.
That was my first thought as well.
or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP port.
Better than the nodelist flag. Should be another "unused" port ...
FYI, a few years ago, I applied for an IANA sanctioned TCP port number assignment for BINKPS (BINKP over implicit TLS, e.t port 24553). After a few back-and-forths, this was their final answer:
So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is the
future for BINKP if it's going to become any kind of Internet standard.
FYI, a few years ago, I applied for an IANA sanctioned TCP port
number assignment for BINKPS (BINKP over implicit TLS, e.t port
24553). After a few back-and-forths, this was their final answer:
The reviews for port assignments is subject to RFCs 6335 and 7605.
We have provided advice according to those docs. The way forward
that has been chosen and deployed is not consistent with those
docs; we therefore do not recommend approval of the request.
So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is
the future for BINKP if it's going to become any kind of Internet standard.
FYI, a few years ago, I applied for an IANA sanctioned TCP port number assignment for BINKPS (BINKP over implicit TLS, e.t port 24553). After a few back-and-forths, this was their final answer:
Well the answer sucks, but your foresight in this issue was awesome :)
So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is the future for BINKP if it's going to become any kind of Internet standard.
I hadn't considered the IANA aspect of this. I have no experience with that stuff so naturally I yield to those who do. Is it a dead end to try again?
I can see BINKPS not having a large enough use-case to warrant a port. But if they did give us BINKP port then I feel there is a case to be made that they must also support the secure version of it.
If you are still willing to support a STARTTLS BINKP I am down to pick that up again and work on something together (and with whoever else wants to join in). I can look for a backup of the code that did it (this weekend) and send something your way, or we can start from scratch... Whatever works for you.
That's the case I was trying to make (along with all the other "prior
art" of insecure Internet protocols that have an alternate/secure port
for implicit TLS connections, e.g. telnets) - but they weren't buying it.
Yeah, we should do that. :-) I have a number of STARTTLS implementations in Synchronet already (e.g. SMTPS, FTPS), so I don't expect it'd be much different, thought I suppose this would be the first one I'd do in JavaScript (since BinkIT is written in JS).
Yeah, we should do that. :-) I have a number of STARTTLS implementations in Synchronet already (e.g. SMTPS, FTPS), so I don't expect it'd be much different, thought I suppose this would be the first one I'd do in JavaScript (since BinkIT is written in JS).
Yep it shouldn't be too difficult. I also have it working for some protocols like POP3/SMTP in Mystic. I don't think my FTP does it though so maybe I can look into that after this since it'd also probably benefit DoveNet security.
I have a document with an outline and some requirements/notes for TLS BINKP that I can e-mail you. It might save us a little time not having to reinvent the entire wheel, assuming you think its usable of course :)
Maybe once we agree on what we want to do and have it working then we can clean it up and circulate it or make a proposal or whatever?
Is there a preferred e-mail you like to use? Or I could Netmail whatever works best.
Sure, either way. rob at synchro dot net or FTN netmail. They end up in the same inbox.
Synchronet and Mystic support direct BINKP over SSL natively
When quoting, the correctly written software should add one '>' character to _the_ _tail_ of existing quote prefix, so /^ XY>>/ should become /^ XY>>>/
Can you show me where the committee for BBS standards made this law? Because can show you a massive history of 30 years of BBS software that disagree wit you.
You can show me that right after you tell me why TLS 1.3 is unsafe to use to secure transmission via sockets which you seemed to ignore. Or why AES-256 unsafe to use to secure FidoNet netmail despite it literally being the curre recommended standard that has never been compromised.
A bogus complaint about quote format is what people do when they jump into something and are horribly off the mark. They refer with childish tactics l this because what their comments on the actual subject are complete nonsense
... Why is the man who invests all your money called a broker?
Sure, either way. rob at synchro dot net or FTN netmail. They end up in
the same inbox.
Cool deal I will send it along.
I ended up having a backup of the code and the document so I put it all back into Mystic this evening. I am in the process of putting up a build for anyone to test that supports the STARTTLS implementation of the document I will send.
I haven't tested it much though just enough to see it actually work once between a Mystic client/server.
The documentation is a bit sloppy, not really intended to be anything formal.
So is there now any implementation BinkP implementation using STARTTLS
and what are the details?
BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)
So is there now any implementation BinkP implementation using STARTTLS
and what are the details?
BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)
BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)
So is there now any implementation BinkP implementation using STARTTLS
and what are the details?
BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)
I've been following this thread for some time, and I don't understand how it concerns our FTN network.
You probably missed that we (no matter what the subject says) actually discussed, how BinkP connections can be secured by TLS?
BTW: RFC8314 suggests already in the introduction that for
email, implicit TLS should be preferred over STARTTLS :)
I've been following this thread for some time, and I don'tYou probably missed that we (no matter what the subject says)
understand how it concerns our FTN network.
actually discussed, how BinkP connections can be secured by TLS?
Unless I missed something, the messages people write are currently
mostly transported using BinkP, which makes this sort of relevant.
TLS is not about the security - it is (really "was") mostly about the mutual authentification. It could work as designed (in the era of SSL 2.0 and before), but the emerge of HTTPS killed some key features of it.
Unless I missed something, the messages people write are currently
mostly transported using BinkP, which makes this sort of relevant.
You appear to be missing the key point: binkp is defined by its'
reference implementation (binkd), and the FTS-1026 plays the secondary role.
So is there now any implementation BinkP implementation using STARTTLS and what are the details?
BTW: RFC8314 suggests already in the introduction that for email, implicit TLS should be preferred over STARTTLS :)
Yes there is. I did a STARTTLS-enabled BINKP a few years ago and its currently available in Mystic that you can download here:
http://www.mysticbbs.com/downloads/prealpha/
I have sent the documentation over to Rob for implementation and/or feedback but I didn't want to post it here yet to avoid trolling. I'd be happy to e-mail it along to you as well if you're interested in supporting it!
BTW: RFC8314 suggests already in the introduction that for email, implicit TLS should be preferred over STARTTLS :)
Implicit would be great (and Mystic actually implements both implicit and opportunistic TLS v1.2 with BINKP), but the problem with implicit is two-fold:
1) For mass adoption, having a self-upgrading connection is probably the most realistic to be used. In other words, existing setups wouldn't have to be changed in order to support it. No additional nodelist flags, etc, would be needed. It wouldn't break any existing systems while those that support it would simply just work.
2) The IANA has denied officially giving us a port for BINKPS, which means that implicit SSL can never be an official standard unless they were to some how be persuaded to change their mind.
Mostly due to #2 it seems to me like the best approach for us to move forward would be to adopt Mystic's opportunistic TLS or some variation of it. Or to support both, ideally?
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 131 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 87:24:27 |
| Calls: | 3,190 |
| Calls today: | 1 |
| Files: | 195 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 366,079 |
| Posted today: | 0 |