>>>>> On Sun, 28 Sep 2008 21:14:38 -0700, Paul Hoffman <[EMAIL PROTECTED]> said:
Again, I completely agree with the goal of trying to remove some of the key-rollover requirements because of key-length and usage issues that are likely bogus. However, I think your proposed edits fail to take into account other issues. PH> If this is a trust anchor, everyone relying on the trust anchor PH> needs to roll over to the new key, which is a very big deal. [... and later ...] PH> Here's the biggie. Separate all of section 4 into two distinct PH> sections: zones publishing trust anchors, and zones publishing DS PH> records to a parent. Make each heading clear which one is being PH> discussed. Life and documentation may have been a lot easier if the technical specifications said "If a parent zone has a properly signed DS record for a zone, the DNSKEY for that zone MUST NOT be used as a trust anchor". But it doesn't. Any key may be used as a trust anchor and it's impossible for a zone operator to tell whether their DNSKEY's in their zone are used for trust anchors or not. There are plenty of previously discussed reasons for using a list of trust anchors that include zones with a parent-child DS in place. I won't get into the politics or even state which side I'm on. That's not the point; the point is that the reality of the situation is that you can't ensure your key isn't being used as a trust anchor. Thus, if you care about people using your data, all keys must be rolled as if they're trust anchors. PH> An attack can only be used if the compromise is unnoticed and the PH> attacker can act as an MITM in an unnoticed way. Please don't use MITM terminology when it comes to DNS... DNS is much more vulnerable to man-not-quite-in-the-middle attacks than other protocols due to poisoning attacks and spoofing issues. (I don't think you put MITM wording in your proposal text anywhere, however, and are only using it in your arguments). PH> If .com is compromised and the attacker forges answers for PH> somebank.com and sends them out as an MITM, when the attack is PH> discovered it will be simple to prove that .com has been compromised PH> and the KSK will be rolled. I doubt it will be simple to prove. Proof requires records, which are usually the first thing an attacker attempts to delete when compromising something (robust systems will protect against this issue of course). Either way, proving to an external entity that a key was compromised vs an intentional malicious action by the key owner is rarely possible. PH> Defining a long-term successful attack is difficult for keys at any PH> level. I suspect that a long term targeted attack on MX records for email sniffing purposes isn't as hard to pull off as you'd think. The type of attack makes all the difference in the world as far as how easy it is to detect. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
