Subj : Re: Is binkp/d's security model kaputt?
To   : Oli
From : tenser
Date : Fri Sep 03 2021 09:16 am

On 02 Sep 2021 at 09:42a, Oli pondered and said...
 
 Ol> IMHO binkd/binkp offers lots of pseudo security and several security and 
 Ol> usability pitfalls. Are there any good workarounds or do we need a
 Ol> binkp/2.0?

What you really need is an HTTPS-based transport.

Part of the issue is that there is the protocol (which is superfluous)
and the implementation(s), which vary widely in terms of quality and
robustness.  All of the points you raise with the protocol are obviated
by using HTTPS instead: mutual authentication, secure transport, etc;
also compression, parallelization, transfer resumption, checksumming,
etc.

I propose an exchange where a client connects to a server, GET's a list
of articles offered by the server from a generic "offer" resource.  The
offer list includes a resource identifying each article.  The client
retrieves whatever it's interested in via a normal HTTP GET against the
corresponding resource.

The client indicates the disposition of everything it was offered by
posting to a generic "ack" resource; the body of the post is basically
the same list but with a disposition for each article: "ack" (received),
"nack" (neither received nor wanted) or "defer" (will try again later).
The default for an article missing from the list is "defer".  Note that
simply completing a successful GET is not the same as an "ack"; the
requesting side may have some difficulty saving the article, etc, so it
must wait for an "ack" before removing the article from a list bound
for the requester.

The inverse of this would also be done: an HTTP "POST" to the offer
resource; the server resource to the POST would contain a body (this is
unusual, but allowed by the protocol) of a list of articles to send
and resources to send them to: the client would then execute HTTP "PUT"
requests for each article indicated by the server.  Finally, it would
issue a "GET" against the "ack" resource to retrieve the disposition
of each article it offered to the server, as above.

A text-based serialization for article data using something like JSON
would also be nice.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.