Now that my mailer (listener) and poller (client) are in production on
a few sites ~ and I have joined a couple of networks that wish to be
"under the radar". I wanted to check around about 2 possibly changes to
the BinkP protocol.

Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3

Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2

Optional support for .REQ files could stay for backward compatability.
However, this approach would help define an M_REQ means a POLL request,
instead of how it is documented now, as a if you didn't get any M_FILE
from the client, it must be assumed as being a POLL.

The other change to the BinkP protocol - really applies to the workflow
of the protocol ~ for example, if you telnet to my BinkP mailer, it
accepts a connection and sends the MD5 CRAM and waits. If I do not
receive a MsgHdr Len M_<command> then I assume (a) User, (b) port
scanner, (c) EMSI Session (because I could send **REQ before the CRAM).

The other part of the workflow change is not to present all M_ADR as a
couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is
optional for products still in development ~ but adds a small layer of anonymity for said networks.

I am in the process of implementing these changes to the systems
running my mailer, so we can iron out any quirks. However, it was
suggested that I present my thoughts in FTSC_PUBLIC.

Ozz Nixon
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

Re: Two changes to BinkP inquiry...
By: Ozz Nixon to ALL on Mon Mar 02 2020 12:33 pm

Hey Ozz,

Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

This sounds OK to me - how is it different to REQ, ie: why is it better, or why
does it need to change?

accepts a connection and sends the MD5 CRAM and waits. If I do not
receive a MsgHdr Len M_<command> then I assume (a) User, (b) port
scanner, (c) EMSI Session (because I could send **REQ before the CRAM).

What happens when it is a) User or c) EMSI - is it your intention that binkp becomes a "frontdoor", and if it isnt a mail (in the case of a) - you launch the BBS login screen. For the later, C) EMSI, is it enabling EMSI on the binkp port? Why would this be needed over just connecting to a different port that serves EMSI?

The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is

I'm not sure I understand the value of this one - if the server wants to not reveal who it is first (because the sysop doesnt want the connect mailer to know it is part of secret network), is it possible that the client would want that as well (not to reveal which network its a part of until the server reveals itself)?

Maybe I dont understand the value..?

I like the ideas though - we should see more of them ... :)
...deon


... Liberals are a Labour-saving device.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

Good ${greeting_time}, Ozz!

02 Mar 2020 12:33:36, you wrote to ALL:

Now that my mailer (listener) and poller (client) are in production
on a few sites ~ and I have joined a couple of networks that wish
to be "under the radar". I wanted to check around about 2 possibly
changes to the BinkP protocol.

Proposals for the binkp protocol should be filed as a pull request for its' reference implementation - the binkd mailer.

If something is not in the binkd, it's not in the binkp.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

I wanted to check around about 2 possibly changes to the BinkP protocol.

Are you certain you're barking up the right tree ?

\%/@rd

--- D'Bridge 4
* Origin: If you build it he will come (2:292/854)

Hello Ozz!

02 Mar 20 12:33, you wrote to all:

Now that my mailer (listener) and poller (client) are in production on
a few sites ~ and I have joined a couple of networks that wish to be "under the radar". I wanted to check around about 2 possibly changes
to the BinkP protocol.

You are free to implement your changes in your software, although you should attempt to do so in a manner that will not affect compatibility with existing mailers.

Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3

Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2

Optional support for .REQ files could stay for backward compatability.

.REQ files are currently the standard method of requesting files in FTN networks, used by both POTS mailers (ie. FTS-6 and EMSI) and most BinkP mailers. In some cases the mailer may rely on an external request processor to handle received .REQ files; binkd is an example of such a mailer. It should also be noted that you cannot assume a node supports file requests unless it flies a FREQ flag (XA/XB/XC/XP/XR/XW/XX) in the nodelist. You also don't indicate if your proposal will include any support for update requests as defined in FTS-6 (WaZOO) and FTS-8 (Bark).

The other change to the BinkP protocol - really applies to the
workflow of the protocol ~ for example, if you telnet to my BinkP
mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
port scanner, (c) EMSI Session (because I could send **REQ before the CRAM).

As binkd is the reference implementation (and most widely used) of the BinkP protocol, this should really be discussed with the binkd developers. I can tell you that if your change is not added to binkd, it is highly unlikely that it will ever meet the "widespread use" requirement for documentation as a FidoNet Technical Standard by the FTSC.

The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is
optional for products still in development ~ but adds a small layer of anonymity for said networks.

Some BinkP mailers already can be configured to selectively choose which AKAs to present to the remote system. binkd has the hide-aka and present-aka keywords in the configuration file.

I am in the process of implementing these changes to the systems
running my mailer, so we can iron out any quirks. However, it was suggested that I present my thoughts in FTSC_PUBLIC.

You need to test your changes thoroughly to ensure that they do not cause any issues for other software used in FidoNet.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

Hello Ozz!

02 Mar 20 12:33, you wrote to all:

Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME
Multiple files, MsgHdr Len M_REQ FILENAME1,FILENAME2,FILENAME3
Passworded files, MsgHdr Len M_REQ FILENAME1 PASS,FILENAME2

Optional support for .REQ files could stay for backward compatability. However, this approach would help define an M_REQ means a POLL
request, instead of how it is documented now, as a if you didn't get
any M_FILE from the client, it must be assumed as being a POLL.

Could you please elaborate in the advantage of this? As far as I see the FTS for binkp, both sides send their files, ready for sending, after the session setup is finished with M_OK. After that part is does not matter if it was a poll or a dialout. The only advantage I see, is the receiving mailer does not have to check for *.req naming of the file, for serving the file request within
the same session, but can deceide on the command. I am not sure, if that would initiate me to think about a protocol change.

The other change to the BinkP protocol - really applies to the
workflow of the protocol ~ for example, if you telnet to my BinkP
mailer, it accepts a connection and sends the MD5 CRAM and waits. If I
do not receive a MsgHdr Len M_<command> then I assume (a) User, (b)
port scanner, (c) EMSI Session (because I could send **REQ before the CRAM.

I go along with the comment of why wanting to turn the mailer into a frontdoor as IP with it ports does not need such a mechanism to allow multiple services on the same machine.

One advantage I see in the binkp protocol is that it is so very simple.

The other part of the workflow change is not to present all M_ADR as a couple networks I have joined prefer to be a little more under the
radar ~ the easy way to help improve this would be to require the
client (polling process) to share the address(es) associated with the connection it is expecting (incase we share two or more networks and
said connection is my uplink/downlink). This tweak of course is
optional for products still in development ~ but adds a small layer of anonymity for said networks.

Nice idea, like that part, but I do not see the necessaty of a protocol change.
FTS does not request that you show all addresses you have. It just requests that the originating side does not wait for any response before sending M_PWD and that for password checking all presented addresses (by the originating side, no other makes sense) are using the same password, if any.

The originating side could just present the networks it wants to present (hiding akas is already sugested in the FTS for the purpose of working with different passwords on different akas). If the answering side only presents 'public' akas and akas fitting to those presented by the originating side, I do
not see any violence of the current binkp protocol and can see no harm to the network, too. Maybe I am overlooking something?

Ozz Nixon
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

Greetings,
Joachim

--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

Introducing a M_REQ command, MsgHdr Len M_REQ FILENAME

This sounds OK to me - how is it different to REQ, ie: why is it better, or >why does it need to change?

a) I did not grow up on BinkleyTerm, nor did I jump onto BinkD.

So, yes, I am more FrontDoor oriented in my head. So, instead of
dropping a <unique>.REQ - my poll command can also act as a REQ
command. We are using it for software updates ~ and I pondered, as a
n00b reading the specs, and implementing them over the past 2 years ~
that it helps clarify what the original draft has about doing a FREQ
during the negotiation phase. And as a n00b looking at the specs and
the workflow of the BSO environments ~ why would I receive an empty pkt
from a system that was forcing a poll. * Not all systems do this, but,
a couple have.

b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a
poll. If LEN>1 then its a CVS string of 1 or more requests. And to keep
with security (.REQ lacks) if the M_REQ file is passworded, the system
cound using the same MD5-CRAM logic for the individual file
password(s). Why? Security.

What happens when it is a) User or c) EMSI - is it your intention that binkp >becomes a "frontdoor", and if it isnt a mail (in the case of a) - you launch >the BBS login screen. For the later, C) EMSI, is it enabling EMSI on the

binkp

port? Why would this be needed over just connecting to a different port that >serves EMSI?

* For systems that the Mailer/BBS work as one ~ yes, I let the user
login - like a "FroDo" design (and MANY other systems).

One port vs multiple ports. Security acceptance. The companies I have
worked for over the years, network CISO do not like to open multiple
ports for any reason. And while many may run a BBS at home ~ in the
corporate world, it would be nice to see the BBS and the MAILER serve a
purpose again.

So part of my question/inquiry was to see if anyone sees a value or
not for the protocol itself. I do, but, I am that American guy who
develops on his production system... ;-)

Ozz
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

I'm not sure I understand the value of this one - if the server wants to not >reveal who it is first (because the sysop doesnt want the connect mailer to >know it is part of secret network), is it possible that the client would want >that as well (not to reveal which network its a part of until the server >reveals itself)?

I am replying to this as a different line of thought. Per the "M_ADR",
when a client is polling, sending a file, requesting a file.

1. If I am polling, then I should present first "whom" I think I am
polling in my M_ADR list... as 99.9% of the time its to pickup mail.
2. If I am sending a file, then I would present my M_ADR of the network
I am part of that is relative to the receiver... 99.9% of the time
sending my outbound mail.
3. If I am requesting a file, then I would present first "whom" I think
I am polling (meaning NETWORK not their ADR).

With that in mine, then the listener would not send any M_ADR
information until the client has presented it's networks that it thinks
or knows we have in common. Even in the original BInkP proposal it does
address in one of the state machine examples ~ waiting for the M_ADR
from the originator. My thought is ~ why not have an option that the
answering side only presents "matching" zones in it's M_ADR reply.
Again, for security reasons ~ it's not "scientific" but every level of prevention and protection helps.

Ozz
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

Nice idea, like that part, but I do not see the necessaty of a protocol >change. FTS does not request that you show all addresses you have. It just >requests that the originating side does not wait for any response before >sending M_PWD and that for password checking all presented addresses (by the >originating side, no other makes sense) are using the same password, if any.

The originating side could just present the networks it wants to present >(hiding akas is already sugested in the FTS for the purpose of working with >different passwords on different akas). If the answering side only presents >'public' akas and akas fitting to those presented by the originating side, I >do not see any violence of the current binkp protocol and can see no harm to >the network, too. Maybe I am overlooking something?

* Okay, it may not be a protocol improvement ~ however, as you see, it introduces a little layer of security ~ which they want to achieve.
However, if it was mentioned in the specification that you do not have
to present all of your addresses (to me AKAs is wrong wording) you
could simply reply wiht the matching zones ~ so M_PWD can proceed as
planned. And a snoopy nose does not see, oh, he's a member of 666
network.

Now you mention matching passwords ~ I will ask a OPT MPWD question.

Ozz
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

a) I did not grow up on BinkleyTerm, nor did I jump onto BinkD.

With all due respect, are you not in the wrong echo ?

\%/@rd

--- D'Bridge 4
* Origin: If you build it he will come (2:292/854)

Hello Ozz!

06 Mar 20 22:19, you wrote to Deon George:

b) by providing MsgHdr LEN M_REQ (where LEN=1) - then I know its a
poll. If LEN>1 then its a CVS string of 1 or more requests. And to
keep with security (.REQ lacks) if the M_REQ file is passworded, the system cound using the same MD5-CRAM logic for the individual
file password(s). Why? Security.

*.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.

Following you line with M_REQ and line length 1 or more, or no line. This would
mean, you do not only use M_REQ just for a file request, but also for initiating a general poll. THIS is - I think - no good, as it clutters a fairly
simple protocol with some implicit stuff.

I can understand (even so I think it is not needed) to have M_REQ to superceed the old *.req file. But in that case it should be only file requests and not a hidden mechanism on top.

What happens when it is a) User or c) EMSI - is it your intention
that binkp becomes a "frontdoor", and if it isnt a mail (in the case
of a) - you launch the BBS login screen. For the later, C) EMSI, is
it enabling EMSI on the

binkp

port? Why would this be needed over just connecting to a different
port that serves EMSI?

* For systems that the Mailer/BBS work as one ~ yes, I let the user
login - like a "FroDo" design (and MANY other systems).

One port vs multiple ports. Security acceptance. The companies I have worked for over the years, network CISO do not like to open multiple
ports for any reason. And while many may run a BBS at home ~ in the corporate world, it would be nice to see the BBS and the MAILER serve
a purpose again.

I might be not in my master part of competance, but security should be much better with a single protocol on a single port. Why? I can watch the port traffic and easily see a protocol misuse. When running multiple protocols on the same port I lack the posibility. Having the FrontDoor mechanism and EMSI headers and so on is a relict of having only one physical port so that you had to split for different protocols later. So here I clearly would vote against supporting this. Once for security reasons, second not to make the protocol more complicated.

Ozz

Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

Hello Ozz!

06 Mar 20 22:35, you wrote to me:

Nice idea, like that part, but I do not see the necessaty of a
protocol change. FTS does not request that you show all addresses you
have. It just requests that the originating side does not wait for
any response before sending M_PWD and that for password checking all
presented addresses (by the originating side, no other makes sense)
are using the same password, if any.

The originating side could just present the networks it wants to
present (hiding akas is already sugested in the FTS for the purpose
of working with different passwords on different akas). If the
answering side only presents 'public' akas and akas fitting to those
presented by the originating side, I do not see any violence of the
current binkp protocol and can see no harm to the network, too. Maybe
I am overlooking something?

* Okay, it may not be a protocol improvement ~ however, as you see, it introduces a little layer of security ~ which they want to achieve. However, if it was mentioned in the specification that you do not have
to present all of your addresses (to me AKAs is wrong wording) you
could simply reply wiht the matching zones ~ so M_PWD can proceed as planned. And a snoopy nose does not see, oh, he's a member of 666
network.

So, we just told the same. And I do not see, where it is a change in protocol. As origin and answering side are not doing anything with akas they can not match, it is no problem not presenting these akas. That means, we do not have a
change in protocol, but only a more sofisticated handling of akas by the software. I like it. I would not have a use case for that upto now, but I like it.

Ozz

Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

*.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.

M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure
protocol over insecure sessions. The HMAC repliy from the originator
makes it next to impossible for MTM packet snooping like you have
mentioned to monitor how a protocol is working (which only happens over insecure sessions), thus your *.REQ file with its antiquated !pwd would
allow MTM attacks to see a password in plain text. My concept avoids
this, as the M_REQ password on a HMAC session cannot be "replayed", it
was only valid for that session.

Having multiple handshakes on a single port, I understand can muddy the
water, however, the companies I have worked for, getting more than one
protocol port open on the front-end firewall is a challenge let along
security compliance requirements for auditing the need for multiple
ports.

I have successfully communicated with a FroDo 2.33ml using the
**EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still
receive my BinkP mail also. So, it does not seem to "break" either
protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
or EMSI, or whatever else may still be in operation. Ports can trigger
off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
the BinkP only environments that may or may not be running a BBS.

We have implemented the M_REQ string on 6 systems and as of 0000 GMT
today, I have released the next Alpha round of my software to those 6,
and 10+ systems are scheduled to go inline this week ~ if I see a
problem, I will note it here, however, so far so good. ;-)

Thank you for your eyes/thoguhts!
Ozz
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

With all due respect, are you not in the wrong echo ?

I do not know - am I in the wrong echo for acking something that is
related to FTSC documents, may require some wording changes, etc.? Its
not an FTSC submission, it is not a BINKD patch, it is not a BinkP (oh
no echo for this) topic yet, and my NET_DEV echo has been empty for
almost 2 years. ~~ so I assumed this would be the best place to get
all the kickback on a change ~~~ ;-)

Ozz
--- Legacy/X FTN Tosser/JAM v1-Alpha6
* Origin: Legacy/X WHQ (Legacy ANSI at Today's Speed) (1:1/123)

Good ${greeting_time}, Ozz!

09 Mar 2020 05:20:40, you wrote to Ward Dossche:

I do not know - am I in the wrong echo for acking something that is related to FTSC documents, may require some wording changes, etc.?
Its not an FTSC submission, it is not a BINKD patch, it is not a
BinkP (oh no echo for this)

The binkp protocol is discussed in RU.Binkd
Obviously, only in Russian: this safely keeps away people like you.

topic yet, and my NET_DEV echo has been empty for almost 2 years.
so I assumed this would be the best place to get all the kickback
on a change

You could notice that nobody of binkd|binkp developers answered you.
Guess why :-)


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: http://openwall.com/Owl (2:5020/545)

Re: Two changes to BinkP inquiry...
By: Alexey Vissarionov to Ozz Nixon on Tue Mar 10 2020 12:36 pm

The binkp protocol is discussed in RU.Binkd
Obviously, only in Russian: this safely keeps away people like you.
You could notice that nobody of binkd|binkp developers answered you.
Guess why :-)

Why?
...deon


... If you think education is expensive, try ignorance.
--- SBBSecho 3.10-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (3:633/509)

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.

M_NUL OPT MD5-CRAM-<string> was introduced to produce a more secure protocol over insecure sessions. The HMAC repliy from the originator
makes it next to impossible for MTM packet snooping like you have mentioned to monitor how a protocol is working (which only happens
over insecure sessions), thus your *.REQ file with its antiquated !pwd would allow MTM attacks to see a password in plain text. My concept
avoids this, as the M_REQ password on a HMAC session cannot be
"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!

Having multiple handshakes on a single port, I understand can muddy
the water, however, the companies I have worked for, getting more than
one protocol port open on the front-end firewall is a challenge let
along security compliance requirements for auditing the need for
multiple ports.

I have successfully communicated with a FroDo 2.33ml using the **EMSIREQ<crc16> header before my M_NUL OPT MD5-CRAM string, and still receive my BinkP mail also. So, it does not seem to "break" either protocol ~ and simplifies the nodelist to just say <domain>, and BINKP
or EMSI, or whatever else may still be in operation. Ports can trigger
off the BINKP, EMSI, CM, HO, flags. And the ITA, ITB, ITN strings for
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 :)

Thank you for your eyes/thoguhts!
Ozz

Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

Hello Alexey!

10 Mar 20 12:36, you wrote to Ozz Nixon:

The binkp protocol is discussed in RU.Binkd
Obviously, only in Russian: this safely keeps away people like you.

Will not say anything to that part ...

topic yet, and my NET_DEV echo has been empty for almost 2 years.
so I assumed this would be the best place to get all the kickback
on a change

You could notice that nobody of binkd|binkp developers answered you.
Guess why :-)

... but, as binkp is part of the ftsc, THAT more looks like (as long as you don't know of active developers on binkp due to no international echo) no one is caring about it any more.

I'm not with all of his points, but some make sens as far as I can see or follow his arguments. If not, well, if there ARE developers on binkp currently,
it may be good to here them on international ground, as the protocol is used internationally. Wouldn't it?

Joachim

--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)