Subj : Is binkp/d's security model kaputt?
To   : acn
From : Oli
Date : Fri Sep 03 2021 06:21 pm

acn wrote (2021-09-03):

 t>> What you really need is an HTTPS-based transport.

 a> Oh no, not again the idea to pack everything into HTTP/HTTPS.
 a> While this is tempting, I think the main part of the said problems with
 a> BinkP could be solved by using a TLS secured connection.

Yes and no. A simple TLS approach would get you a secured connection and optionally authentication (of one or both sides). We already use binkps, that part is solved.

The problem is in the design of binkp, which replicated some of the design problems of EMSI. The moment one or both sides presents multiple addresses anything goes. Unauthenticated transmissions might be put in the 'secure' inbound, inboxes don't work reliably. The last line of defense are 8 character uppercase ASCII passwords in the PKT and TIC files.

I could imagine ways to negotiate the client and server address with some certificate and SNI magic over TLS before the binkp sessions starts and then do a session only for a single address for each side. But I don't believe that is what you suggested (wäre ein bißchen von von hinten durch die Brust ins Auge). I would expect all kind of new problems and when today several mailers don't even get a basic TLS session right. I also wouldn't put too much logic in the TLS layer as there are alternative encrypted transports, for example Tor, i2p, lokinet and some other overlay networks / p2p VPNs.

 a> The idea behind binkp was that eg. existing tosser software could be used
 a> together with a new mailer component which then talks to other systems.

Which could be done again with a new mailer protocol, even if it was based on HTTP.

---
 * Origin: . (21:3/102)

.