[tekne]

I have often had the thought that CAs could be made obsolete by things like DNSSEC. I have no idea if I am correct, so I would like to ask: please tell me if/why I am wrong. Here is my argument:

- If you control the DNS record at the registrar, you can point it to whatever server you want and get a Let’s Encrypt certificate that way. Never mind the old model. So you need to trust the registrar, if they’re compromised that’s it.

- Back in the day, DNS is cached and plaintext and cannot be trusted

- Now, you can use DNSSEC. And you could have the registrar sign the DNS entry, so a cache/ISP/corporate can’t forge it…

- So: why not stick a key, with metadata (e.g. expiration) in a signed DNS record. Now you only trust one person (the registrar) rather than two (the registrar and the CA)

- And there’s no extra paperwork or process since you need to do all that stuff anyways to register the domain.

I don’t know much networking. What’s the flaw in this argument? Is there one?

I’m imagining a world where instead of a trust database of CAs, you instead trust the keys of the DNS root servers, and the CA system and DNS system merge into one.

This also gives you a neat story for custom certs, etc, as it becomes a domain problem. It’s now perfectly natural to say “I trust the X root of trust for domains Y” for e.g. your internal system because that’s what you’re using to resolve those URLs.

To be fair, part of this is my fascination with the idea of using cryptographic keys as addresses, like in many a cool protocol, making DNS literally into a CA of the form “assign this name to this identity (key)”.

[cpach]

These are two good articles regarding why DNSSEC is not a good alternative to the webPKI.

https://sockpuppet.org/blog/2015/01/15/against-dnssec/

https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-con...

[tekne]

Alright that’s pretty bad. Have some questions though.

- For the bit.ly thing; as far as I understand Gaddafi could at least theoretically order the registrar to point somewhere else and then that somewhere else could get new keys from the automated CA, right? Or am I missing something? Maybe we do want some second layer process for extra security, but couldn’t you solve this by sticking extra certificates in the record? This can also replicate the corporate solution: “trust an extra MyCorp certificate as well as the actual one.”

- So… now that I know the details of DNSSEC beyond “signed encrypted DNS,” I’m not a fan. What stops us from phasing in (beyond, elas, politics and network effects) Actually Good Signed Encrypted DNS? Specifically;

- For backwards compat, can we separate the “signed” and “encrypted” part where you stick a signature on the record which signs the hash of the record minus the signature and any other signatures?

- And then, for encryption, can you just do DNS-over-TLS or something like that? Totally separate from the signing bit; the goal of signing is that you can trust the data, the goal of encryption is that people can’t see what you’re looking up.

- And let’s say we had this nice two-layer protocol. Why do we need proofs of nonexistence? Why not just treat it like https and, when adoption is good enough, default deny insecure HTTP? Seems like another mistake in DNSSEC to have this feature at all…

For a glimpse into the idealized mental model of an idealized future I’m grasping at here:

- An abstract identity is (waves at philosophy)

- A concrete identity is a set of cryptographic keys

- Two problems:

  - How do I find out the identity associated with a name. Related subproblem: key rotation and friends.


  - How do I reach the given identity, over a given network; here the Internet

Technically these can be separate services! DNS can do both at the same time so efficiency, but they’re orthogonal.

- You can have other naming systems. For example, a social network with E2E chat can be viewed as mapping names to identities-as-keys

- You can have other comms channels: see here again the chat, which is at a higher level than the Internet. But also SMS, Tailscale, idk… also, see different kinds of DNS records so one naming system (DNS) can handle multiple reachability kinds!

So, in short, if anyone bothered to read this brain dump, I believe a form for trustable (if you trust the source but not the nodes) hierarchical name => identity systems is a Good Idea so far, and I guess DNSSEC is not the way… but it still seems like CA is also not the way and it should really be part of DNS.

How misguided am I?

/rant

[cpach]

I know that many feel strongly that the web’s trust system should somehow move into DNS.

I think the first questions to ponder are: What is it that is wrong with the current WebPKI? (As it is in 2025, not as it was in 1999.) What would actually become better if we tried to move all of this into DNS?

Ponder this: Why do we place the “trust handling” in the application layer? (HTTP with TLS.) Why not in the IP layer?

[tekne]

Well, because of what you're trusting.

- "I want to connect to IP X" - What IP X is is defined by your ISP. You can probably have a trust model here (ISP X cannot reassign IPs from ISP Y) but people don't usually dial IPs like phone numbers, and if they are, then just get them to dial a public key (only 4x longer!) and you're - done - future proof if the IP changes - Whereas DNS is about names. - Part of that is name to IP, but many names can map to one IP and vice versa, and IPs change - Really it's about names for agents, who have a key - So DNS solves the problem of mapping human readable name => ephemeral agent ID - How do I trust that it's the right agent though? - I need cryptography! But it's exactly the same situation I want from DNS, except that here I only trust the root server.