Sure, if "making the DNS totally unreliable", "baking 1990s crypto into the core of the Internet", and "conceding the CA PKI to world governments" is your idea of "better use of CAs".
> "conceding the CA PKI to world governments" is your idea of "better use of CAs".
How much different is this than the current CA situation? Just recently a subordinate CA of ANSSI (the French Network and Information Security Agency) issued a wildcard cert that could MITM just about anything.[^1] Firefox's list of trusted CAs includes:[^2]
China Internet Network Information Center (CNNIC)
Government of France
Government of Hong Kong (SAR), Hongkong Post
Government of Japan, Ministry of Internal Affairs and Communications
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
Government of Spain (CAV), Izenpe S.A.
Government of The Netherlands, PKIoverheid
Government of Taiwan, Government Root Certification Authority (GRCA)
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
Hong Kong
Firefox's list of pending CAs includes additional government CAs.[^3] Things are no different in Redmond. There are at least 56 government CAs (56 of the certs start with government probably others with less obvious names) in Microsoft's Root Certificate Program.[^4]
That was my point, too: the theorized system already exists. I'm definitely not advocating its use.
Ultimately, the URL bar needs to go away. More fundamentally, the asymmetric relationship between very large organizations that authenticate their identity with browser CA certs, and individuals who authenticate their identity with passwords needs to change.
Cryptographically generated addressing schemes like Telehash can do the automate-able stuff better than the current CA situation. The problem (and solution) I'm struggling to articulate involves the fact that granular authorization systems and trust databases need better UI before we can really fix this.
I suspect cheaper hardware tokens will play a significant role.
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.
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.
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.
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.)
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.
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.
>> 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).