undefined | Better HN

0 pointse12e11y ago0 comments

No, not really. DNSSEC secures DNS, allowing it to be used (among other things) as a secure transport for delivering other certificates.

CAs already provide the same trust infrastructure, but due to incentives do not sign delegating certs by default, but typically charge extra for certs that allow the owner of a domain to set up their own internal CA.

DNSSEC only works (reasonably) for TLDs where DNSSEC is implemented, and when DNS resolvers implement checking -- many ISPs don't. Delegating CAs are already part of SSL/TLS.

DNSSEC requires fidling with the DNS information -- delegating CAs, while requiring issuing certs, only require configuration of the various services (web, imap, smtp etc) -- as per usual.

For delegating CAs to improve the security of any given domain -- some infrastructure would be needed to set up an intermediate CA. I guess for small organizations, OCSP wouldn't really be needed, as the CRLs would be small (assuming different CA for public facing services and stuff like personal certs for users). Another option would be to simply roll certificates frequently.

0 comments

jackalope11y ago

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.

einhverfr11y ago

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.

dvanduzer11y ago

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.)

1 more reply

e12eOP11y ago

>> 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 user@example.org -- 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).

j / k navigate · click thread line to collapse