(C) Alec Muffett's DropSafe blog.
Author Name: Alec Muffett
This story was originally published on allecmuffett.com. [1]
License: CC-BY-SA 3.0.[2]
networking – dropsafe
2021-11
So there’s this piece in CircleID by Anthony Rutkowski
New Nails in the Crypto-Anarchism Containment Coffin
—
Read it here / by Tony Rutkowski
https://t.co/FjxZ4hTACd — CircleID (@CircleID) January 3, 2021 And I suppose that I should not be surprised that the CircleID URL starts with “http://” rather than “https://” when the post contains gems like this:
Until the mid-90s, the development and deployment of cryptographic communication techniques was largely the province of governments and regulated network service providers, and small numbers of companies and academics that supported both. This comparative stasis changed dramatically — especially in the U.S. — twenty-five years ago because of three concurrent developments. One was the enactment of what is known as Section 230 which provided essentially complete immunity for online service providers. The second was a decision by the U.S. Administration to end all regulatory oversight of internet developments and promote a single, highly vulnerable network protocol — TCP/IP — and embrace its institutions — in part to achieve global strategies. The third was the Administration’s concurrently ending the support for public network security and trust platforms developed over the previous decade known as SDNS (Secure Data Network System).
Anthony blames the horror that is modernity upon Section 230 of the Communications Decency Act (“a ‘preemptive pardon’ for providers of hosted online sites by designating them as content distributors and establishing a broad policy of encouraging unfettered online distribution of almost anything and everything”) and the adoption of TCP/IP – which meant that nobody was properly in charge of network development, that any university nerd could be permitted to innovate in the space of communications, and that “anarchists” could rule the day via IETF:
Back in 1988 is when I got my first Unix job at the University of Wales, Aberystwyth; the campus was connected to the UK Joint Academic Network (JANET) via a 64-kilobit synchronous X.25 connection.
At the time it was strongly verboten to tunnel TCP/IP over that connection because communication protocols were politically and administratively contentious, various funding bodies were fighting over their adoption, and there was a horror that data coming from “commercial” or “public” networks might be shared over the link – thereby consuming resources which were meant to be purposed for PURE RESEARCH™ with consequent impact upon future funding.
I mention this because to my dying day I will remember the look of abject horror on the face of Phil Brennan, the university’s X.25 networking expert and plumber, when I told him that in TCP/IP that anyone could create a listener (X.25: “NSAP”) without requiring any permission from anyone, so long as the port number was between 1024 and 64k. That two Unix processes, separated by arbitrary distance, could communicate without intercession by a wizard like him was utterly unthinkable – in X.25 “OSI” networks the configurations were like phone exchanges, with “servers” needing to be properly configured and registered and approved and advertised, like a more complicated, ceremonial, and obligatory form of firewall NAT port-forwarding.
I wonder if Anthony feels like Phil did, because he writes stuff like:
However, the zeal didn’t stop with TLS 1.3, but also included an array of additional synergistic protocol variants intended to defeat any attempts to eliminate all manner of cyber defenses as well as detection and control of unwanted or illegal traffic. Indeed, when TLS 1.3 is paired with a multistream protocol known as QUIC, many opaque parallel paths can be created — making it ideal for the illegal streaming of multimedia works. Wow, so, if you can stream something fast, that inherently must be bad because it enables crime…
Now, here’s the thing: my take is that TLS 1.3 actually is one of those cyber defenses that Anthony is bemoaning the loss of; to not think of it in those terms is to avoid asking “who should these cyber-defenses serve?” – and in Anthony’s case I don’t believe that the answer would be “the user” nor “the individual”.
I suspect that he would consider such answers to be “crypto-anarchistic”, which appears to be the reactionary complement to the critical theory’s dismissal of such tech as “crypto-utopian and cyber-libertarian”.
But Anthony did write one thing which absolutely, in the context of 2020, nailed me to my seat – he mentioned SDNS (the “Secure Data Network System”) which is only mentioned in-passing in Wikipedia:
…developed through a joint initiative begun in August 1986, among the National Security Agency, the National Bureau of Standards, the Defense Communications Agency, and twelve communications and computer corporations who initiated a special project called the Secure Data Network System (SDNS).[11] The program was described in September 1987 at the 10th National Computer Security Conference in an extensive set of published papers. The innovative research program focused on designing the next generation of secure computer communications network and product specifications to be implemented for applications on public and private internets. It was intended to complement the rapidly emerging new OSI internet standards moving forward both in the U.S. government’s GOSIP Profiles and in the huge ITU-ISO JTC1 internet effort internationally. Originally known as the SP4 protocol, it was renamed TLS and subsequently published in 1995 as international standard ITU-T X.274| ISO/IEC 10736:1995.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Secure_Data_Network_System
But Anthony linked to one of his earlier articles, and thence to one of the early papers, and, well, a little googling later and holy shit…
Today (if I am reading this right) the SDNS is only interesting because a chunk of it (per Wikipedia; see also “SP4” referenced in this PDF on page 154) got broken-out and became / was reused as TLS edit: was published as a standalone X.274 under the name TLS, which may have provided inspiration to SSL which also later (and confusingly also became called) TLS, per some IETF discussion and discussion on Twitter:
In response to your specific concern about the term TLS, TC CYBER notes that the Transport Layer Security protocol and TLS originated as part of the ITU-T – ISO/IEC JTC1 X,802, Lower Layers Security Model (04/1995) as Rec. ITU-T X.274, (ISO/IEC 10736-4:1995), Transport Layer Security Protocol (X.tlsp) (Jul 1994). The IETF’s TLS protocol v1.0 in the form of RFC2246 followed in 1999 as a derivative of the Netscape Corporation’s Secure Sockets Layer (SSL) – which itself was a derivative of many other transport layer specifications which had existed for many years. Ref. RFC 6101, The Secure Sockets Layer (SSL) Protocol Version 3.
https://datatracker.ietf.org/liaison/1612/
Some kind of filial relationship would be plausible because the cited OSI (non-TCP) communications stacks at which X.274-TLS was targeted did include X.25, which depended a lot on the kind of /OU=Foo,/CN=Bar X.500 Directory verbiage which today most people fortunately only ever experience in X.509 certificates, TLS, and LDAP, rather than in X.400 email addressing. This may be solely due to X.509, however.
But it turns out that there was a whole other world of work in SDNS – some of which, if you remove the Phil Brennan-esque centralised controls of public key infrastructure, sounds a bit like Tor’s “onion networking”
The OSI 7-layer model is a bad model for almost all network protocols
I can’t agree with Anthony on most of what he wrote – not least since the TLS 1.3 which he derides appears to be extremely aligned with the goals of the SDNS project which he celebrates, if one ignores the question of who performs key management for the edifice, and what backdoors and escrows they might want to thrust upon the users.
But I am grateful to him for waking me up to SDNS, to see the obvious direct or parallel-evolutionary influences of some of its other projects upon TLS, IPsec, Tor and VPNs, and to help prove that 30 years ago the NSA were looking to splice end-to-end encryption into all future networking, inevitably OSI, communications … which they were content to do on the assumption that they were would be in possession of a spare set of keys.
And it was safely assumed that that upstart TCP/IP competitor would be prettymuch nowhere in the final implementation
ps: if you would like a verbal comparison of Onion Networking to the 7-Layer Model:
[END]
[1] URL:
https://alecmuffett.com/article/tag/networking
[2] URL:
https://creativecommons.org/licenses/by-sa/3.0/
BoingBoing via Magical.Fish Gopher News Feeds:
gopher://magical.fish/1/feeds/news/alecmuffett/