.%*. .-.
.%@@@+. .--=%@@@-
=@@@@@@- :--+@@@@@@@@@*
*@%@@@@@%: :--=#@@@@@@@@@@@@#@@+
@@::%@@@@@@-: :::-=%@@@@@@@@@@@@@@%#*- :@*
.@@ =@@@@@@@@@+-:::::::-=*@@@@@@@@@@@@@@@@@@@%##- @@:
#@# +%@@@@@@@@@@@@@@@@@@@@@@@@@@@@@%%#*: -@@
#@- *%@@@@@@@@@@@@@@@@@%%%#= %@=
@@: -=+++== .. @@:
@@ . -@@@ +@@
#@% =@@@@- +@@@@# *+ %@#
#@- -@@@@@@@. +@@@@@% .%@@@@= @@:
@@: +@@@@@@@@@ +@+ +@@@ %@@@@@@@@@ -@@
@@ *@%@* :@@@ *@+ -@@@ %@@@@@@@@@@@# @@@
#@% %@ @% %@@ *@* .@@@ =@@@*@@ :@@@@ @@:
%@:## *@+ :@@ :@@ @@@ %@@: @# .@@@ .@@
@@:. @@: .@@ @@ @@@ %@: @@ @@% @@%
@@ -@@. =@@ @@. @@@ %@. #@- @@# @@.
%@% +@@. @@. %@- @@@ #@ @@. :@@ -@@
%@: +@@+ .@% #@= @@@.@ *@@ +@+ @@*
@@: +@@%. .%% *@+ @@@ %@@ -@# @@
@@ :@@@@@@% :@@ @@% %@@ @# *@@
%@@ #@@@@* @@ @@% %@@. %@. @@:
@@: ===: @@. @@% %@@: =@%. .@@
@@. #@= @@% %@@%+%@#. @@%
@@ +@* @@# -@@@@@* .@@
%@@ :@@ @@# %@@#: =@@
@@: .@@ @@# : @@=
@@. @@. @@# :@@
@@ #@= @@% %@%
#@@ +@+ #@% .@@
@@: =@# +@% =@%
@@ :@% -@@ @@+
@@ .@@ -@: -@@
-@@ @% .: *@#
@@* # @@.
@@ =@@
.@@ @@*
.@@ .@@
*@@ =@#
@@* @@*
@@ -@@
.@@ +@*
.@@ @@-
-@@ =@@
%@% #@*
@@ @@:
@@ +@@
.@@ %@+
:@% @@.
:@% *@%
-@. %@=
%@ @@.
@@ *@%
@@ %@=
@% @@:
:@% +@@
:@* =+- #@+
:@: .%@@@. @@-
-@ =@@@@@# :@@
=@ *@#.=@@% #@%
*@ #@- -@@% %@-
@@ #@: :@@% @@:
@@ #% .@@% .#@@* -@@
@% #% .@@% +@@@@@- %@%
@# %@ :@@% .@@@@@@@@ %@:
@# %@ :@@% +@@% .@@@@ @@:
@# %@ :@@% #@@: :@@@ -@@
@# @@. .@@@ .@@% .@@@= %@%
@# @@. .@@@: %@@- @@@% %@:
@# @@ @@@@ %@@@ *@@@ @@:
@# .@@ @@@@@@@@@@= :@@@ @@
* @@@ :@@@@@@@@. :@@@ *@@
.@@@@@% -@@@@@. .@@@ @@=
@@@@@: .. @@@ @@.
-@%: @@@ @@.
@@@ @@
-@@ =@@
.@@ @@+
.@@:@@.
@@#@-
@@@.
+@-
-
mediocregopher's lil web corner
I was digging around in the configuration of my email server (probably a separate post on that forthcoming), and kept stumbling over the many various extensions which have been made to the email protocol over the years. SPF, DMARC, MTA-STS, oh my! Most of these extensions have been bolted on top of email in the hopes of preventing spam and forgery of messages, but at this point there's so many that I began to wonder which are actually necessary from a server admin's point of view. So I did some research.
One of these extensions is DKIM, which stands for... something. It doesn't matter. The aim of DKIM is to prevent undesirables from spoofing the From address of an email. This is accomplished by sticking a public key in a well known DNS entry, and then signing all outgoing messages with the associated private key. Mail servers receiving email which (ostensibly) comes from your domain are expected to check that the signature on the received email matches the public key on the DNS record.
"DKIM seems pretty foolproof" was my first thought. But I soon learned that DKIM's main weakness is that it depends on the message receiver to fetch the public key using DNS. An attacker can, without much difficulty, intercept and modify the responses to DNS requests. If you've ever run into an ISP-level website block (or perhaps a country-level one) then you know this pain.
If an attacker can intercept DNS requests they can easily change the DKIM public key returned for any domain, and therefore spoof emails from anyone.
At this point it occurred to me that DNSSEC is a thing I knew of but didn't know much about. Shouldn't it solve this? Well yes, it turns out it does. Using it requires adding a DS entry at the DNS registrar level (next to the NS records) to grant trust to your nameserver's own signing keys. The registrar is able to grant trust to the nameserver because it is able to prove that trust has been granted to it by the root nameserver run by ICANN. Clients inherently trust the root ICANN servers because their machines were shipped with both the IP addresses and public keys of those servers.
So yes, DNSSEC would solve this. But using it requires the server admin to that DS entry, which no one does. And so DNSSEC is about as well adopted as IPv6, and so DKIM is not enough.
The goal of DKIM is to establish trust. I cannot trust that a message has come from the name which is attached to it using only information from the sender themselves (because the sender is, obviously, suss). I need to defer to a third party which is trusted both by me and by the real sender. This is a fundamental fact of identity and trust in technology.
Why does email have this problem, but not the web? Well, the reason is because the web uses a different mechanism to establish trust. The mechanism looks rather like DNSSEC, but differs in who is trusted. Every web client ships with a set of trusted public keys which are managed by entities called "certificate authorities" (CA). The server admin asks a CA to sign a message containing both the public key and domain name of the server. This signed message is presented to clients when they connect to the server. Since clients trust the signature they can trust that the public key is "bound" to the domain name.
These CAs are in reality just for-profit companies, and for a very long time you had to pay a fee to get your own public key signed, even though doing so is zero-cost for the CA. In the last few years this situation has improved in some ways, but between this and various security breaches at the CA level, CAs have not endeared themselves to the tech community at large.
From a high level view, the web relies on two sets of trusted third parties: the DNS root servers (used to translate a domain name to an IP) and the certificate authorities (used to create secure connections). One of these parties isn't actually all that trusted. Could we do without it? With DNSSEC in place yes, yes we could.
The solution would look basically exactly like DKIM. As a server admin I would stick both my server's IP address and its public key in DNS, and clients would query both when they want to connect to my domain. Assuming DNSSEC is being used the public key can be inherently trusted. And not a greasy certificate authority in sight.
Could we take this even further? There are more protocols than web and email on the internet. It should be possible to develop a generalized standard which sits on top of DNSSEC and allows a client to authenticate the server they're speaking to (and even, potentially, vice-versa) using public keys stored as DNS entries. That way new protocols can be developed and inherit the security capabilities of the protocols which came before, without needing to re-invent the wheel.
Yes, such a thing is possible, and in fact it's called DANE (DNS-based Authentication of Named Entities). It defines a new DNS record type called TLSA, which allows for specifying the hash of a public key which will be served on any hostname+port.
RFC 6698: A bit of light reading
As far as I understand it, given DNSSEC adoption, DANE would replace the need for all of the following:
By the last point I mean the following: during the initial connection handshake the client is able to provide their own public key to the server, and the server can verify that the public key belongs to a particular domain name which is owned by the client's user, the same way the client is doing for the server. This domain name then becomes a cross-server, cross-protocol, verifiable identity for the user. There's no need for usernames or passwords, 2FA, account management, SSO, DDIds, etc... You stick a hash string in a DNS entry, and if you need to change your public key you just change that hash.
Another nicety of DANE is that it's not obtrusive. I could add DANE support to my gemini capsule and it would not get in the way of any existing gemini clients. Similarly, I could import a DANE-verified certificate to any gemini client and the client wouldn't know the difference. It's simple and beautiful.
In short, I'm now DANE-pilled. DNSSEC support on my domain coming imminently.
There's still one nagging issue. We've successfully factored CAs out of our lives (great job everyone, give it up for yourselves), but in their place we've put ICANN, which is just some US government agency at present. "Single-point-of-failure" is a trigger word for most engineers, so I won't say more here.
While crypto is, obviously, 100% a scam and an environmental catastrophy and only used by criminals and the most annoying guy in your apartment building, it has made some inroads in this area that are worth thinking about.
A very early fork of Bitcoin was called Namecoin. It aimed to be a decentralized name system, but even then some people recognized it could also solve the problem of binding public keys and domain names.
One of those people was me, in one of my earliest, and most successful, posts.
(I like to think my writing has improved in the last ten years, but apparently giant paragraphs about the basics of public-private key cryptography are what the people want.)
Namecoin, may it rest in peace, is dead. In its place we now have ENS, which lives on the Ethereum blockchain, as well as other less-popular-but-roughly-equivalent systems which live on other chains. These all work just like DNS, except the state lives on a distributed blockchain rather than the configuration of some server.
The appeal of these distributed name services is that A) they are easier to work with than DNSSEC while B) providing the same level of verifiability. To check that a public key is bound to some name I can look up that name on ENS and check that the hash of that public key is present as well; exactly how DANE works. I can trust the answer I get back to the extent that the blockchain is secure from 51% attacks, possibly running my own full node if I'm truly paranoid, but most likely using the API of someone else I trust who is doing so instead.
(A note, in anticipation of some criticism here: If it strikes you as wrong to trust someone else to query the blockchain for you, but you don't run your own recursive DNS resolver, then you have some research to do.)
There are already web browsers which support ENS out of the box (notably Brave), and other browser can have support added via extensions. Similarly other systems besides ENS can be added to browsers via extensions. Support for all of these, with appropriate translation from blockchain record->TLSA record, could also be done at the OS level via the DNS stub that most OSs run locally.
Finally, if my comments about using DANE as the backbone of a digital identity seem far-fetched due to their requiring users to manage public/private keys, crypto has something to teach us here as well. Extensions like Metamask allow users to log into dApps via public/private key signatures, and they make it incredibly easy to do so. Money aside, it's an experience I vastly prefer over usernames, passwords, email recovery, 2fa, and all the rest. And unlike in crypto, the cost to losing your private key is nil; you just generate a new one and stick it in your DNS.
My point here isn't to push crypto, but more to show that a lot of the problems inherent to our imminent DANEtopia have solutions which come from that area, and are worth knowing about.
TLDR; Email is a shitshow, set up DNSSEC on your domains to bring on the coming DANEtopia, crypto is a scam don't ever buy any for any reason
Published 2023-08-24
This site can also be accessed via the gemini protocol: gemini://mediocregopher.com/