At 8:13 AM -0700 9/29/08, Wes Hardaker wrote:
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.
Fully agree.
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.
Yep.
Thus, if you care about people using your data, all keys must be rolled as if they're trust anchors.
A better way to say this is "if you care that people might use your key as a trust anchor, it is relatively easy to help them by acting in some ways like a trust anchor".
The planning for being a trust anchor is quite different than the actions you need to take if you have a parent and you just want to sign your zone and maybe later care about rollover. Having 4641bis say "you must be able to act like a trust anchor whether or not you want to" is bad advice and will deter the vast majority of zones that should be signed from wanting to be signed.
One way to deal with this is to describe the ways that some users might want to use your parent zone to get your initial DS key and then use your key as a trust anchor. There are reasons for this that are not covered in any RFC I have seen, and a reader of 4641bis might get value out of thinking about this.
After that, we could talk about the few steps needed to act like a trust anchor by following RFC 5011. There are two aspect here: following the timing, and updating old keys with the REVOKE flag. This does *not* mean publishing your key outside the DNS as current TLDs need to; saying that every zone should do that will scare them away.
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).
Fully agree. DNS's use of UDP makes the middle very un-middle-like.
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.
Agree that this would not be simple to prove. If it is a real concern, someone could put out a bunch of dispersed collectors that log all responses in the hope that the attacker sends one of them the spoofed reply. That's very hit-and-miss, of course.
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.
Exactly right. --Paul Hoffman, Director --VPN Consortium _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
