Subj : Is binkp/d's security model kaputt? To : deon From : Oli Date : Tue Sep 07 2021 11:04 am deon wrote (2021-09-05): d> Re: Is binkp/d's security model kaputt? d> By: Oli to deon on Sat Sep 04 2021 12:18 pm >> I would keep the 5D. We are waiting for decades for full 5D support >> and you want to drop it now, when there is a chance to do it >> properly? d> Yeah, but what value does 5D provide, or what problem does it solve d> (today)? "640K ought to be enough for anybody" [1] Today, it doesn't solve much, because it usually only works at the mailer level (kind of). I'm not sure if there is software that fully supports 5D down to the message base and mail reader. It would give a better separation of FTNs and better support for multi-zone othernets. Maybe it's overkill, but you never know what people are using the software for (as in fun and experimental). Maybe there will be some network that makes use of the full 64-bit (60 bit) address space. I don't know. I think it's just backwards trying to get rid of the 5D addresses. It's an old idea and it persisted. Yes, you could design a modern tech fidonet software for only a limited amount of users / othernets. But why? RFC 1883 (IPv6) was published 1995 (development started much earlier) when only minority of people had access to the internet. Today IPv6-only is still no fun: $ host -t AAAA docker.com docker.com has no AAAA record >> How do you get from 50 to 37 chars by removing the domains? AFAIK >> there is also no official length limit of the domain. Some FSC >> suggest 8 byte, others 64k bytes. Binkd is hard coded to 32 bytes. d> The only reference to domain that I could find was FSP-1028 which d> describes the domain as 8 chars and what those chars can be. http://ftsc.org/docs/frl-1028.002 : This document is a Fidonet Reference Library Document (FRL) This document preserves FSP-1028.002 which was not considered for promoting to a standard. Nope, was rejected as a standard. d> The 8 chars can be encoded in 6 bits for each char, or 6 bytes for all d> 8 chars. Do you really want to add complexity just for saving 4 bytes? On a network were a big chunk of the content are redundant quotes (because the world hasn't figured out a way to reference these quotes. just copy them again and again. Is Ted Nelson still alive?). Or where we transmit the nodelist over and over again, because it's more convenient than a nodediff. >> :) What are the remaining 21 chars? d> In reality, I think a packet header can be very short possibly shorter d> that 21 chars/bytes (havent really thought it through in detail). If d> there is proper authentication of the sender, then a packet from the d> sender doesnt need to have the senders details in the packet header, nor d> even a packet password. In fact it may not need the receipients details d> in the header either - but some other method of identifing whether the d> receipient will accept and process what the sender is sending - d> date/packet sequence number, or just a verifiable "signature" etc. If we were exchanging mails via floppy disks or as email attachments, ftp upload, etc a packet header is useful. But with a properly designed protocol most (if not all) of the data in the packet header is redundant or becomes only a line in your tosser's log. Unfortunately the binkp protocol copied the behavior modem mailers and still relies on packet passwords. If a binkp session were limited to one address on each side, files could be easily and reliably put into a specific inbox like fsxnet/21.3.102.0/inbox/21.2.116.0-secure fsxnet/21.3.102.0/inbox/21.99.99.1-noauth >> edge, core, legacy systems ... interesting choice of words for >> something that doesn't even exist. d> I disagree - there was always a "core", and in some respects there still d> is. "Someobody" assigns you with an address that has a parent. Everyone who has power over the nodelist is part of the core? This seems to be more a social / organizational / I-like-to-wear-a-*C-hat thing than a technical necessity. d> Some d> othernets operate that way even though "fidonet" (or some systems) try d> not to. So there isn't always a defined core? d> That core represents the subset of systems in a network that d> offers and a majority of systems collects mail from. but every node with a good enough tosser and mailer can become part of that subset or can decide to become a leaf node again. Or has arranged private peering with other nodes. There was a time were the majority of system (in some regions) who collect mails were points. who was part of the core then? d> It also represents a d> guarantee of a system to collect mail from, if you dont have other d> arrangements. There are no guarantees. And why would you need guarantees if you can make other arrangements? >> What is it good for if we don't even manage to have proper FTN-style >> paragraphs and quotes? d> Well that's not a problem for the "infastructure" to solve, but I agree, d> it would be nice if it was handled consistently. The infrastructure (or "core") is not really the problem. It's the user interface, stupid. And it sucks big time. [1] Bill Gates never said this. --- * Origin: 1995| Invention of the Cookie. The End. (21:3/102) .