[jackalope]

From the article:

Certificates bind a public key and an identity (commonly a DNS name) together.

...when issuing certificates a CA validates ownership of a domain by sending an email, or looking for a specially formed page on the site.

So, if "DNSSEC secures DNS," as you say, why do we need certificates at all? Considering that the CA already depends on DNS to issue (many) certificates, why not cut out the middle man and simply publish the domain's public key in a DNS record? What actual value does a certificate offer other than that? I'm genuinely asking, because I'm curious if DNSSEC provides a way for a domain owner to establish trust in the domain's DNS records, that cannot be tampered with by the domain's registrar.

[einhverfr]

I think the fundamental problem with DNSSEC is it doesn't go far enough. DNS really is the original directory service of the internet. If we could generalize it a bit, and allow TCP queries secured by Kerberos, with far better row-level security, there's no reason we couldn't replace LDAP with something a lot simpler.

If we could replace LDAP with something a lot simpler, we could as replace X.509 with something a lot simpler (LDAP is a mildly simplified version of X.500, of which X.509 is a very closely related OSI legacy standard).

So DNSSEC doesn't go far enough. IMO, we should be working on ensuring that it can be extended to allow for certification of hosts, etc. However, at present it doesn't do this very well.

[dvanduzer]

This sounds very much like the directory system I want to build on top of Telehash.

The problem I still see is creating a global directory of Kerberos realms. There still needs to be a sneakernet component for private key distribution. (Maybe that would be a better use of the armored cars I see making regular stops at the banks around town.)

[einhverfr]

Ok, so suppose registering a domain also required registering a public key for the domain name. This would require a change for the root realm. Suppose we were to extend the DNS protocol so that when you do an NS lookup, you get the keys of the NS's as well (might require SRV records or the like in the root tree). You'd need a mechanism to revoke or rotate keys, but that could be done.

From there it should be quite possible to tie public keys to hosts all the way down since you now have a chain of trust. Should be trivial, but the problem is that I don't see how to get the root zone to publish domain keys.

Yes, that replaces CA's with domain registrars, but that is a healthy trade. Since you would get keys (all allowed keys!) all the way down with your query, you wouldn't need to check revocation because you'd know the keys before making the connection.

[dvanduzer]

What you're suggesting doesn't sound too far from DNSSEC as it is currently implemented to me (ignoring adoption rate). I'm questioning the need of an authoritative global naming system at all.

From a user's perspective, "my bank" and "your bank" might be the same thing, or they might be different. When I care about verifying the identity of these things, why not just go to the source? I can do key exchange every time I visit an ATM.

I can imagine using DNS with multiple contextual root namespaces, with the trust anchors being managed by more direct human relationships. This wasn't feasible when the systems were originally designed, but now we can put public keys in jewelry. Keychains on our literal keychain.

[e12e]

>> Certificates bind a public key and an identity (commonly a DNS name) together.

>

> So, if "DNSSEC secures DNS," as you say, why do we need certificates at all?

Yes and no. Note that a cert binds an identity, not just a DNS name (but that is what is needed for web servers).

DNSSEC doesn't work without resolvers checking for the DNS keys, and it's not immediately clear (to me at least) if the various higher level clients can transparently detect if a DNS name is secure or not (similar to how a web browser can't tell if it's accessing a resource over a secure IP based VPN and can therefore safely transmit credentials via plain auth).

For trust to work, there needs to be integration of the chain of trust all the way from the user to the server. TLS/SSL already provides this -- and with delegation the infrastructure is in place for owners to manage trust for their own domain (and it is already possible, but typically expensive).

In it's barest form DNSSEC only makes DNS secure, which prevents DNS spoofing. If you also place a cert (could be self-signed) in DNS, then you have a "full" solution to securing communications. You would be able to download the cert without DNSSEC, but unless the chain of trust of the cert could be verified some other way, you wouldn't be able to use that cert for secure communications.

It is true that current CAs bind a cert to a domain name, but it's not really the domain name part that is interesting, it's the entity identifed by that name. So your browser can say, I don't care where this authenticated (and encrypted) data stream is comming from, I just care that it is backed by example.com (that is backed by example-ca.com) -- and if the user thinks that Example corp. owns the example.com domain, one can then infer that the browser is really talking to a web site set up by Example corp -- regardless of which IPs and DNS records are involved.

Keep in mind that the same CA infrastructure allows a user to indenify to a server as [e-mail] -- from any ip or doman name -- just as securely, via mutal trust in "Example CA". I think it's somewhat unfortunate that DNS is so tightly integrated into the user interfaces for the web -- asserting things about IP adresses and DNS names isn't really all that interesting -- it's asserting things about entities that is interesting.

While I'm no fan of the current CA system, I'm not convinced DNSSEC is securing the right things at the right protocol level(s).