Trust me - I'm real!
In a post the other day I posited that by "..add[ing] a distillation of DNS with scents of SSL and Certification Authorities.." we can manage the trust issues currently wreaking havoc amongst "cloud" based services. With this post my intention is to clarify WTF I was rambling about 😅
But first – a fair warning 'cause this post gets pretty detailed about the tech. In more layman's terms you could describe it something like this: In order to call Ms. Someone I'll go get a phonebook (or more recently, an online listing site like YellowPages) and start searching for Ms. Someone. I'll end up with a set of digits (because that was how the signaling of the callee's handset/phone is converted from man-readable to machine-understandable) and dialing the sequence will - hopefully - connect me with Ms. Someone. Unless I block the Caller ID (hide my phone number) Ms. Someone will at least learn my phone number. If we are not acquainted all she will have to go by is looking up my number in the inverted listing (ie instead of a name, she will be looking for a name by the number displayed on her handset. Provided the listing service is to be trusted and I'm listed she will learn my name and possibly a postal address.
Quite a number of Internet services rely on DNS which is short for Domain Naming System. It's a fairly simple protocol not too far from the above example. Got a name - get a number. Got a number - get a name. We can utilise this to allow machines looking up the identification of senders merely by providing a sequence of digits. Entertain me on this: in order to allow at least 1 specific number to all humans on Earth we'll need at least 11 digits (99,999,999,999 possible 'addresses') at the moment – we might get away with 10 digits for a while but.. Now let's add some machines and like devices of various sorts and we are looking at perhaps 12 or 13 digits. Throw into that mix the commercialization of this 'tag' – and we end up with something like
WD13CHM4NN
It's short enough for you to remember and not too complex to share. At least it's quite an improvement over john.doe1234@someone.somewhere even if you should end up at the short end of the stick so to say, with something like W3KJ98DF1. Businesses might fight over C0C4C0L4 and N1K3 – I like to think that they absolutely should! Offering the token on a first come first served term will allow for trade and drive adaptation.
10 characters is no coincidence - with 25 letters and 10 digits there will be 36 (if we allow for 'space', ie not filling in every position) to the 10th power affording an incredible 3,656,158,440,062,976 "addresses" leaving well above a staggering 350,000 addresses for each of the first 10 billion people on Earth.
DNS operates on a particular tree like structure of name servers scattered all over the globe with a fairly small number of root servers each holding references to a very large number of domain regional name servers that in turn are responsible for referencing authoritative nameservers each being able to do the name to address conversition for a particular domain like say https://jp.dk. This design affords any machine to having an answer to a simple question in as little as 1 request (if the resolver have the answer cached) or more often, 4 requests, usually in a time range of 50ms - 150ms. The question goes somewhat like this: where should I turn to talk to www.adidas.de? In exactly the same way DNS could be operated to answer another kind of question: Who can tell me where to ask questions regarding B3ATL35
I posit that the DNS protocol be amended allowing machines to receive two pieces of information: an IP address and a public key, and with that information they may request an authentication package using the HTTPS protocol like this
GET https://192.168.1.100/authp
The authentication package would come in two layers of encryption; the protocol based TLS/SSL encryption and inside that, the private/public key encryption which the machine putting forward the question in the first place would use the aforementioned public key to decrypt.
In a totally decentralized state every 'user' would carry their own authentication package on their own device but catering for fault tolerance most likely will require persisting the packages in alternate places in the cloud too, albeit still under the command of the owner of the authentication package.
It might all look something like this (keeping in mind that all 'swim lanes' might be physically running on one device – if the receiver merely is another process; this obviously is what might be considered an edge case though):
As a person with a desire to send messages to others I would go to a certification authority (in person) and submit my biometrics (photo, spit, iris scan, gait, more) to a machine operated by this authority. My device would share a public key for the authority to use in the proces of compiling my authenticatin package.
The chain of command of these certification authorities (CA) is very important as receivers would have to rely on the CA's not being compromised – ie corrupted to collecting false biometrics. It will most probably require a separate protocol to be operated in the open source community and disseminated amongst users (senders and receivers) collecting and verifying biometrics from their peers regularly, thus reporting what they see. Any discrepancies would demote CA's and ultimately close them down if no one trust them to collect and compile biometrics in an orderly manner. One could theorize on the application of "phonebooth" certification authorities operated entirely by machines and completely detached from any networks given the pure functional nature of their operation: provided the same input they will elicit the same output every single time.
Now with my encrypted biometric authentication package compiled for me and handed to me as the service provided to me by the CA, I will persist it on my device/machine and for safe keeping even place it in multiple alternate places in the cloud. I would not know, my self, what the package concists of - neither would the CA as they do not for privacy policy concerns persist any actual datasets pertaining to the transaction with me - except for a hash of the package handed to me along with a copy of the public key, for them to prove when questioned whether they did in fact compile my authentication package at all - no CCTV, facial recognition or any other recordings of me being there.
Depending on my temper and paranoia I will either add my device as the destination for questions regarding authentication or pick one of the alternate places in the cloud as the source of the truth. In any case I am now ready to start exchanging messages with receivers using this decentralized and yet highly centralized authentication system.
Regarding the DNS we are facing a few obsticles with the most important one being that the naming system is divided into something called TLD's (short for top level domains - like .com, .de, .es, and so on) and subsequent second level domains like exxon, maersk, and so on, effectively combining it to names like exxon.com, maersk.dk, etc.
Fitting the tokens/pigeons into this system can be done in a number of ways, one being attaching a bespoke TLD on to the tokens like WD13CHM4NN.tt, another being to add TXT records to a bespoke domain, fx pigeons.tt.
Catering for performance issues this particular 'domain' will receive a tremendous amount of trafic and as such probably be elevated to a particular root service - much like the f-root, but that's another story.