On 17 November 2012 22:57, Paul Wouters <[email protected]> wrote: > CT-PKIX addresses an issue where there are 600 roots and you can't > trust all of them (although TLSA solves that too). I'm still unsure > what CT-DNSSEC would solve, as just pulling history from DNS does not > add anything, and I have no idea how to authenticate to the CT-DNSSEC > audit log to start an alternative path of trust, especially if you are > defendining against a rogue root or rogue .com key being used secretly > to sign alternative records, or a compromised DNSSEC private key.
I'd like to state what I think CT-DNSSEC would solve, and how it would work. I'll use .com as my example root, and google as my example CT notary. Hopefully I don't screw up the DNSSEC part or the CT part too much... I submit an entry for the DS record for example.com to the .com operator. The operator in turn contacts google but preferably multiple notaries and says "This is the DS record for example.com" and google puts it into their log, and gives back a signed statement as proof of such. It then enters this proof in some new type of record, we'll call it DSProof. After the .com operator has the proof, it updates the DS and DSProof records. Now a user wants to connect securely to example.com. They query the A record for example.com, and get back the response plus the RRSIG, the signature for the A record. However, the client can't check the signature, it doesn't have the key. I'm unsure if in implementations this query happens in parallel, in the same query or what - but it reaches out and gets the ZSK for example.com, the KSK for example.com, and the DS record for example.com - so it has the complete chain of keys from example.com -> .com -> (root). At this point it can verify the entire chain of signatures. But when it retrieves the DS record for example.com it also retrieves the DSProof. The client can verify that the DSProof is valid and comes from the google notary (I'm not 100% sure if this is a signature of a merkle path ending in a signature but it functions like a signature.) The client ensures that the DSProof is valid and from the google notary, meaning it has an entry in the append-only merkel tree, which we can verify (and there are verifiers for it.) That gets into the CT side of things. At this point, everything under example.com - whether it's the A record or the TLSA record - is signed as normal, and the signatures under example.comchain to a key that has been entered into a public log. If a TLD wants to fraudulently sign a response for the A or TLSA record for a site, they will have to also enter the key into the notary. The operator of example.com will be able to see there is a DS record they did not authorize in the notary, and can start investigations or other mitigation processes. (Ideally the presence of the notaries will be the deterrent against the attack.) I think CT-DNSSEC is important. We've seen domain seizures before. The new gTLD program will open the internet to vast numbers of root operators, and not all of them will be competent or lack malice. Root keys will get stolen. Maybe it'll be .bugatti and not .bank but it will still happen. We should build this in now, while we can flesh it out pre-widespread deployment of DNSSEC. -tom
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
