Dot-US ccTLD Opened for DNSSEC signing, new SSL Certificate Authority model proposal
Well, kind of. In order to get your Dot-US (.US) ccTLD DS record to be added to the Dot-US zone, you need to have NeuStar as your Registrar. NeuStar is the Registry for Dot-US (and Dot-BIZ), but not the Registrar of all Dot-US domains. In my case, I have two Dot-US domains. Roysdon.us and Roysdon.Modesto.CA.US. The first is registered through GKG.net, so they are my Registrar there. GKG, nor any other Registrar other than NeuStar have officially been listed as having Dot-US DNSSEC support yet, so I have to wait. However, my "US Locality" domain, Roysdon.Modesto.CA.US, does have NeuStar as my Registrar, as it is a legacy domain, back from when Dot-US domains were where for free and allowed citizens, businesses, organizations and government agencies establish unique, memorable American identities online.
Eventually the Dot-US Registrars will get ramped up and give support to the johnny-come-lately folks who don't have US Locality domains, but the DNS infrastructure is there now.
Well, kind of (yeah, just a few of these "kind of's"). If you want to allow anyone with a little technical skill to list your entire Dot-US zone. If you don't mind them seeing every single record you have, well, then you can add DNSSEC DS records into the Dot-US zone and have a trust chain all the way from the Root, through Dot-US, to your domain. Why is this information security hole required? Well, right now Dot-US is only allowing NSEC record algorithms 3 (DSA/SHA1) and 5 (RSA/SHA1), but not NSEC3 record algorithms 6 (DSA-NSEC3-SHA1) and 7 (RSASHA1-NSEC3-SHA1). NSEC3 is important for those who wish to keep their zone data from being enumerated (listed) and therefore exposed to anyone who has just a little technical skill. The full list of DNSSEC algorithms should be supported by all Registry/Registrars so, and hopefully the lesson to be learned by other Registry/Registrars before they implement DNSSEC support for customers.
I'm confident that the Dot-US Registry, NeuStar, will address this and open up the zone to allow domain owners to submit any valid DNSSEC DS algorithm type, and I have requested they do so.
As others have said, DNS is public info, but that's not 100% true. It's mostly public info. It's sort of like the Freedom of Information Act: You have to know what to ask for to get it. You can't, normally, say, "Give me all your DNS records." A proper DNS administrator will block AXFRs (Zone Transfers) to anyone except the servers that need AXFR access for replication. As I said, if you sign your zone with DNSSEC NSEC, then all your base are belong to us [sic].
To prevent zone enumeration via "NSEC walking" you want to sign your zone with NSEC3. However, you cannot generate NSEC DS records from NSEC3 keys (and visa-versa). So if you want to submit your DS record to NeuStar, you need to sign with NSEC, which means you need to expose all your records to being listed.
For now, I came up with a work-around: Sign my Roysdon.Modesto.CA.US zone with NSEC so I could submit my NSEC DS record to NeuStar, but have no records in it except the bare-minimum requirements (SOA, NS, MX), and the delegation of a child domain via NS & DS records. The child domain, home.roysdon.modesto.ca.us, is signed with NSEC3, and its NSEC3 DS record can in the parent NSEC-signed zone without issue. As home.roysdon.modesto.ca.us is NSEC3-signed, it is immune to NSEC walking, and my records secure.
It's not like my NSEC3 zones have some top-secret records, but I do put a lot of information in there. HINFO records are a nice way to store the Hardware and OS, LOC records for storing LAT/LON coordinates (which can be dynamically updated and obtained from and cell phones using GPS or Wifi APs can be used to cross-reference approximate LAT/LON coordinates), RP records for who owns a system, TXT records for whatever you might want to store (try and find out what Ox.roysdon.org, Eagle.roysdon.net, Lion.roysdon.us have to say in their TXT records), but you could store Serial/Asset numbers in them, WAN Circuit IDs, even vendor support contracts and numbers. Not to mention just a list of all the hosts themselves - why do you need to know how many systems I have? It's nunya.
I also store SSHFP records, which allow me to SSH to one of my hosts from a new host and not yet have the SSH key. By using SSHFP records in a DNSSEC-signed zone, I know that the SSHFP record wasn't tampered with in the DNS reply, and I can verify that the SSH key that my server is sending wasn't tamped with by verification of the SSH Fingerprint record.
I think a revamp of the SSL Certificate Authority (CA) model is order now as well. SSL CA digests should be stored in DNS for the zones of which they are to issue Certificates. SSL CAs should become hierarchical, the same as the DNSSEC trust model is. A browser with zero Root CAs installed, and only the Root DNSSEC Trust Anchor. From there, it could bootstrap the entire CA architecture for each record needed for SSL requests. For instance, use DNS to find out the NS of roysdon.modesto.ca.us and be able to verify each reply from the DNS Root down to my NS servers (which can be done now, that infrastructure is there and all records are DNSSEC-signed), and then request a "CA" record and "CAFP" fingerprint record from the zone. My proposed "CA" record would be the name of the Certificate Authority, and the "CAFP" would be fingerprint digest such that after the CA Certificate was downloaded, the CAFP would verify that it was the correct CA Cert.
The great thing with this model is that a domain owner would have the ability to chose how they want to host their domain's CA. They could do it internally or use a third-party CA, either because they didn't want to host the infrastructure for a CA themselves, or because they wanted some sort of Extended Verification (EV) done by the CA. Verisign, et al. would not like my plan, as they'd only make money for folks not hosting their own CA themselves, or where free CA's could not be found. Invalid self-signed SSL certificates would become a thing of the past. DNS hijacking and spoofing won't work as DNSSEC will block it, and potential rogue CA's like Etisalat (thanks to Verizon/GTE) and CNNIC won't be able to create their own Intermediate CAs for just any zone they want and monitor traffic.
Not to re-invent the wheel completely, it looks like RFC4398 which specifies CERT records may be able to be used for not just CA's but also GPG keys. Whatever the RR is matters not to me, so long as it puts the control of the SSL Cert into the hands of the domain owner (or any cert for that matter, as GPG keys would be nice as well).
By the way, even if you remove Root CA's you don't trust in Windows, Microsoft will add them back for you, unless you disable this feature. I don't see any need to trust CNNIC, so I've removed this Root CA from my browsers, but am still debating removing Verizon/GTE's Root CA.
Update as of July 18, 2010:
I received word that that I passed the new 642-832 TSHOOT Beta exam that I took on March 26! Woot, CCNP recerted, and by passing this test my CCDP and CCVP are renewed as well for 3 more years.
