Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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?


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: