On 20 November 2012 23:47, Tom Ritter <[email protected]> wrote: > 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...
This looks about right to me, just one clarification. Also, as others have said, CT-DNSSEC is probably not the right name for it! > 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.) In CT this is a signature from the log that is in effect a promise to include the cert in the log. This is so that the CT log server can respond immediately to a certificate request without having to generate a whole new tree. We did this in the interest of reliability and uptime (since there can only be one correct tree, it is required that all responses from a server farm are ordered, which is considerably more demanding than it is to store certificates for later ordering, in short). However, if DNSSEC servers are prepared to wait a while, sometimes, then we could make it an actual merkle path - this was the original design of CT, but CAs didn't like the delay. > 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.com > chain 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 > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
