These do not need to be the same thing or issued by the same entity. I propose to modify the system as follows:
1. Register a domain name using an email address and a PGP key.
2. The registrar verifies that the applicant has the private key by requiring a clicked link in an encrypted mail.
3. A phone number is required for "full trust".
4. Thus with a private PGP key and a phone, trust that the applicant is the applicant has been established. It really doesn't matter who or what that applicant is -- just that the applicant and only that applicant has the required items.
5. The registrar passes the public key and the top domain to DNS servers. DNS validates against the registrar. And trust in the domain as an entity is now established.
6. Secure communications with the domain can now be established through the use of certs issued by the top level domain. And the domain becomes it's own authority.
Any changes to registrar/domain information requires decrypting an email and answering a phone. Expensive and compromised CA's go away - Domain records become secure - Trust becomes decentralized - And domain owners hold all the keys... The only thing anyone else has is the domain holder's public key... SSL itself remains in place as is...
Sure, if you lose your private key - you're screwed -- but that's just owning up being a responsible domain owner.
Yes, it's better because you now only trust one party [1] what's much better than 600 random companies around the world. But it's not a panacea, that still puts too much power into governments hands, and still relies too much on a third party that can be hacked, bribed, threatened.
I'd still like it better if browsers pinned the key of every site I access, and issued a warning if it changed without the new key being signed with the old.
[1] Ok, a few, because you don't contact ICANN directly when you get a domain.
First off, a phone call is not full trust. A copy of your driver's license, power bills, social security card, etc are closer to full trust.
Second, all you've described is a certificate authority that works inside DNS. Instead of a CA validating your certificate and the client blindly believing whatever the CA tells it, now it's the DNS validating your PGP key and the client blindly believing whatever DNS tells it. It's the same, only now you've got more eggs in one basket to get owned.
So no, any changes to DNS do not require any key from a domain owner. If the client implicitly trusts the DNS it means the DNS can make any change it wants and the client will believe it. This is the whole reason nobody likes the CA model, because the CA can decide at any time to issue a certificate for any domain and any client will just blindly believe it.
You're defining trust as trust that the entity is who the entity claims to be in societal space. But this is unnecessary. All that needs to be trusted is that the claimed domain owner is the domain owner. It doesn't matter who that entity is in societal space - just cryptographic space.
Each domain is its own CA. And the registrar doesn't need to be trusted at all. All it is doing is dolling out domain names to public keys. There is no need for "true" personal identity to be established - since the only entity that can decrypt the PGP encrypted verification email is the owner of the associated private key.
No, I understand PKI. What you've created is less secure than what we have now.
If computer A wants to connect securely to computer B, and it doesn't want its connection to be MITM'd, computer A trusts a 3rd party (computer C) to tell it that computer B is really computer B and not a fake. If you take over the DNS system (which is your version of computer C in my example) you get to write anything to computer A and it will believe it.
The whole idea behind a MITM is that an attacker controls communication between A and B, and ideally also controls communication between A and C. Just controlling the network isn't enough to subvert the connection, though, because an attacker would need to control one of A, B, or C.
If you are the NSA, and you write up a very nice National Security Letter and go to computer C and say "make a fake DNS record for me, because terrorism," you now get to write blank checks for yourself and computers A and B have effectively no idea that their connection is now subject to MITM.
Specifically to exploit your system all you'd need to do is create a fake A record pointing to computer D, and a fake public key record which matches the PGP key and SSL cert of computer D. If you weren't using DNSSEC you could do this on a regular open wireless network with no extra hacking needed. If you are using DNSSEC (and a mandatory validating stub resolver, which Windows doesn't ship with) you'd need to take over the root DNS servers or the registrar which feeds records to the .com. root DNS servers. But the NSA can do all that. Probably others too.
So, again, it's the exact same state we're in with the CAs, with the exception that DNS would be less secure because the client (computer A) doesn't have any public keys/ca certs stored on it to verify the DNS servers or domains against.
In order to create a fake record, you would need to replace the PGP ID on the registrar's record. In order to that, you'd need to intercept and decrypt a PGP encrypted email. In order to do that you need to be in possession of the private key and have the passphrase. An attacker could steal the private key from the domain owner's computer [not the server] and install a keylogger to get the passphrase ... or an attacker could produce a private key from a public key... good luck with that one...
The system I've laid out would be significantly more secure and less spoof-able than the current system. Further, DNSSEC becomes entirely unnecessary...
Also, it is entirely possible to create a registrar which would store all user record data in an encrypted store which could also be encrypted using a domain owner provided public key... if this were added to the architecture, no government entity could modify anything regarding a domain - except replacement of the entire record.
Of course, since the entire system current and any possible future Internet relies upon computers and networks that are explicitly not under the control of the content provider - any government can at any time break the system... This is always going to be true of any and every system of wide networks.
EDIT: Computer A and B need a third entity C to validate A to B and B to A. True... However, this does not need to be a computer -- it could very well be a cryptographically generated unique ID... In my example "C" is the PGP ID. However, it could be any cryptographic item that is tied to the domain record and only modifiable using the private key that generated the unique cryptographic item... for example, it could be a bit coin address.
> Of course, since the entire system current and any possible future Internet relies upon computers and networks that are explicitly not under the control of the content provider - any government can at any time break the system... This is always going to be true of any and every system of wide networks.
This is the entire reason we are trying to get away from CAs! What we have works perfectly fine. The only reason anyone wants to get away from it is to prevent state actors from overriding a CA's authority. If you want to just reinvent the wheel with the DNS system, use RFC 6698.
My idea was a thought project, and I was not aware of RFC 6698. Thanks for the reading material, it sounds similar to my thought process...
However, my personal reasons to discard the current CA system is to enable secure communications from multiple subdomains without the need to pay a $500 rental fee for a wildcard identity+cert --- As well as enable secure passwordless access to A/MX records without fear of compromise.
The government is going to be able to break any system that's put out there. At the very least, a government can disrupt IP traffic in and out of a node. There is always going to be an open addressing scheme, unless the network is an encrypted peer-to-peer network with every node attempting to decrypt every packet... I seem to remember reading about a block chain peer-to-peer data network being developed. However, my guess is that overhead bandwidth limitations will be a problem for large networks.
1. An identity.
2. A secure communications certificate.
These do not need to be the same thing or issued by the same entity. I propose to modify the system as follows:
1. Register a domain name using an email address and a PGP key.
2. The registrar verifies that the applicant has the private key by requiring a clicked link in an encrypted mail.
3. A phone number is required for "full trust".
4. Thus with a private PGP key and a phone, trust that the applicant is the applicant has been established. It really doesn't matter who or what that applicant is -- just that the applicant and only that applicant has the required items.
5. The registrar passes the public key and the top domain to DNS servers. DNS validates against the registrar. And trust in the domain as an entity is now established.
6. Secure communications with the domain can now be established through the use of certs issued by the top level domain. And the domain becomes it's own authority.
Any changes to registrar/domain information requires decrypting an email and answering a phone. Expensive and compromised CA's go away - Domain records become secure - Trust becomes decentralized - And domain owners hold all the keys... The only thing anyone else has is the domain holder's public key... SSL itself remains in place as is...
Sure, if you lose your private key - you're screwed -- but that's just owning up being a responsible domain owner.