> An attacker (Mallory) with access to the trust anchor keys runs a > man-in-the-middle attack on sender and recipient. He forges the > OPENPGPKEY RRs, the ZSK-RRs and KSK-RRs of the sender and recipient > domains and the TLDs but uses the current origin keys of the trust > anchor to sign the forged DNSSEC RRs. > ... > It seems DNSSEC/DANE helps against most hackers and attackers but cannot > protect from attackers which have access to both the trust anchor keys > and routing infrastructure. > > Do the DNSSEC RFCs allow to distribute public KSKs of TLDs with resolver > software?
Yes, not only can anyone distribute the public keys of the TLDs, but each TLD public key is readily accessible at any time from anywhere on the Internet, by sending a single DNS request to any of the root servers. This is one of the improvements that DNSSEC made, over the prior art of public key infrastructure. So, not only can resolver software come with a set of TLD keys, but that software can also compare the built-in set of keys with the set currently published online. (And if Mallory has MITM'd Alice, she will see discrepancies, unless Mallory has also obtained the private zone signing key of the TLD that Alice is accessing.) This comparison can be done when the newly installed OS first boots and joins the Internet. It can be done every time the OS boots. It can be done every time a TLD's key is used in a given day. It can be done by comparing keys obtained last month or last year, to keys obtained now. It can be done by comparing today's keys to keys provided by one or several other servers that you personally trust (e.g. a home machine, or one run by your company), over a connection secured by crypto known only to you. You can make the detection software arbitrarily complex, which will make Mallory's job arbitrarily complex. It's all "a simple matter of software". The challenge is that TLDs are *intended* to roll over their keys, so there will always be some discrepancies between keys frozen in a resolver software package from a few months or years ago, versus the keys used on the live Internet. That's why we have root keys: to authenticate the changes in the TLD keys. So if the root says, "This new TLD key is valid", yet it doesn't match the local database, is it an attack, or a key rollover? What does the software do? What does the user do? Making the software pop up a warning box at that point -- or, more stringently, fail to connect to the intended destination, as ssh does -- will likely cause Alice to bypass the warning or to accept the key update. "Get out of my way, stupid software!" Her other option is to decline to connect, until she can find out what's going on via some other means -- but ordinary Alices won't do that. Google Chrome's "key pinning" prints a big ugly message that encourages the user to report the message to Google tech support. But that only works the first few times -- then Mallory learns that he must not only forge the keys, but also prevent access to Google tech support (or worse -- Mallory pretends to *be* Google tech support, accepts the report, and responds with soothing reassurances that all is well). So, there are ways to detect key rollover / key compromise. But unless you think of something useful to do at that point, there is little reason to do that work. As with much of crypto / computer security, it is far easier to detect and repel mass surveillance than it is to detect and repel tightly targeted surveillance. And luckily, this is also in line with most people's social goals (disallow suspicionless mass surveillance, but allow targeted surveillance with responsible, e.g. independent judicial, oversight). So my suggestion is that if these mechanisms are built, they should focus on detecting mass surveillance and reporting that to the public. Such as IETF's Certificate Transparency work: http://www.certificate-transparency.org/ or EFF's Decentralized SSL Observatory: https://www.eff.org/observatory https://www.eff.org/press/releases/new-https-everywhere-version-warns-users-about-web-security-holes John _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
