= Сообщение: 5154 из 7128 ====================================== FTSC_PUBLIC = От : Joachim Probst 2:240/6309 12 Mar 20 17:21:58 Кому : Ozz Nixon 12 Mar 20 17:21:58 Тема : Two changes to BinkP inquiry... FGHI : area://FTSC_PUBLIC?msgid=2:240/6309+5e6a6358 На : area://FTSC_PUBLIC?msgid=1:1/123.0+5E65CECF = Кодировка сообщения определена как: LATIN1 ================================= ============================================================================== Hello Ozz!
09 Mar 20 05:16, you wrote to me:
>> *.req files follow the FTS-0006.002 guideline of file requests. That >> file format is supporting passwords. Each line in the *.req file >> starts with the filename of the requested file and may be followed by >> a blank, an exclamation mark and the password.
ON> M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure ON> protocol over insecure sessions. The HMAC repliy from the originator ON> makes it next to impossible for MTM packet snooping like you have ON> mentioned to monitor how a protocol is working (which only happens ON> over insecure sessions), thus your *.REQ file with its antiquated !pwd ON> would allow MTM attacks to see a password in plain text. My concept ON> avoids this, as the M_REQ password on a HMAC session cannot be ON> "replayed", it was only valid for that session.
Yes, see that. Ok, that would be a pro to have file requests within the sesison scope of the transmission for this reason!
ON> Having multiple handshakes on a single port, I understand can muddy ON> the water, however, the companies I have worked for, getting more than ON> one protocol port open on the front-end firewall is a challenge let ON> along security compliance requirements for auditing the need for ON> multiple ports.
ON> I have successfully communicated with a FroDo 2.33ml using the ON> **EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still ON> receive my BinkP mail also. So, it does not seem to "break" either ON> protocol ~ and simplifies the nodelist to just say <domain>, and BINKP ON> or EMSI, or whatever else may still be in operation. Ports can trigger ON> off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for ON> the BinkP only environments that may or may not be running a BBS.
I did not think about possibilities. I had been using FroDo in my former Fido time on calling lines. As I said, there it was even necessary to get it working at all.
For today on IP lines, I just do not see the advantage for the more complex (it is more complex) and more implicit asumptions to the nodelist. It's - in my eyes - a protocol change for personal view to a topic without getting an objective advantage for everyone.
So I still will keep not going along with you in this part. You see more advantages, I see no advantages being worth a protocol change :)
