-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joe,
You remove a part I think is very important: > So the rollover is clearly effective. 99% of people pick up that > new key within the timeframe, and 99.9% after 2 timeframes. > And with trust history, it works for the remaining 0.1% too. > > Therefore, you get the benefits of rollover. That means that > the old keys are phased out. It is automated too. I think that is very important because I think especially for important trust anchors, the trust anchor must roll over. Also for the root. On 08/28/2009 12:29 AM, Joe Abley wrote: >> Well, in practice that means someone holding such a software >> update key. That does not change at all. For 20 years or so? >> I do not see how this would be more secure. > > It at least matches the security in the rest of the operating system, I > guess. So, how do you propose I manage the unbound validator root trust anchor distribution? (I understand you are saying Microsoft can use Windows Update ; I am not saying what they have to do, the draft we are discussing is how I propose to do it). > I appreciate that a leap of faith can be a reasonable thing to make > occasionally. No, I said for specific persons. You seem to latch on to that statement as if everyone now has to do so. This is not true. If the zone owner says his keys are right for 4 years and you configure an end date for those keys in 4 years then those people are not making any leaps of faith. They have full security. > The mechanism you propose provides a means for an automated leap of > faith, one which might be made without an end-user being explicitly made > aware of it. Well, if the user dares to make a leap of faith and configures his software to do so, then he gets leaps of faith, right? > My concern is that a compromised key might allow the linked list of > historical keys to be compromised, which might have the effect of > leading disconnected clients down a contrived path to a rogue trust > anchor. If the trust-anchor mechanism is automated and implemented, then > the effect might be that there is a large population of clients with > naive users whose trust anchors could gradually become subverted with > really no obvious way to measure it happening. So, your concern is a compromised key. Which people use to divert old machines (thus, 4 year old machines or so?) down a bad path. Of course the draft already contains a mechanism to make such attempts highly visible, did you consider those mechanisms? (i.e. did you read that part; otherwise it may soothe you considerably, as it makes attempts to subvert highly visible and easy for measurement) And we assume now that whatever attacker is working around those mechanisms (and is thus some sort of powerful MitM, the ISP or so). If the ISP wants to hide this act from measurement, then you won't see it, right? So with any compromised key the system can be subverted. This is also the case with the 'one single key' that you propose above. If that is broken also all computers are going to be subverted with no obvious way to measure whatever. Of course, if someone does not have trust anchors that match the current zone, then he cannot access anything, except stuff that is fed to him by the MitM, right? That would be obvious? If the MitM seeks to just add one key of its own, then as soon as the target manages to make a normal DNSKEY query (and sees an updated root DNSKEY set, without the MitM key) he loses that key again. So we add a statement saying that if you see an updated keyset, in the course of normal resolution, and this keyset verifies, then this updated keyset MUST be stored on stable storage? So, what exactly are you afraid of, can you give more details? And what would you like to measure happening? How should this be measurable? I am sort of confused. You seem to think that trust history must somehow be invincible against compromised keys. But that some other mechanism, which relies on a single key kept for 20 years, does not have to do so? Also RFC5011 is vulnerable to a single compromised key, right? This can be used to install an additional trust anchor that even if the machine resumes normal operation stays 'dormant' in the MISSING state? Of course it takes 30 days to do so, but that is why in the trust history lookup also a 30 day wait period is installed. Trust history lookup does have a lot of mechanisms in place to provide additional protection (but not cryptographical) when a key does get compromised. This makes it more resistant against compromise than the 'single key 20 years', but of course, once that cryptographic key is broken, you get no more cryptographically strong protection. > The root zone is arguably the one for which accurate dissemination of > the trust anchor is the most critical, since the security of the rest of > the DNS for a single-anchored validator depends on it. Yes, I agree, the root anchor is important. > Your points about the applicability of this approach depending on the > characteristics and security policy of the zone whose anchor is being > published are well-made. > > So perhaps I can modulate my initial concern to: > - IoT operators should be aware of the risks of publishing using this > approach that I outlined earlier, and balance those against the > convenience of having an automated trust re-sync mechanism So if operators say, I will publish trust anchors, roll them every year, and say that after 5 years you can no longer trust them. So if you use a key that is older than 5 years then you could be really making leaps of faith. Then everyone can configure their systems as to their perception what security they want out of this? The zone owner could even publish more detailed explanation about how trustworthy keys of 1year old, 2 yrs old, and so on, are. And then people can pick their level of security. You want to discuss 'why should a trust anchor perform rollover'? I think trust anchors must roll over. This mechanism gives the advantage that you can reduce the exposure on older keys. So it gives the zone owner a way to distribute new trust anchors. And most will pick it up instantly. And it does not 'disconnect' the older ones. > - I don't think this is a good idea for the root zone. Well how do you suggest ex-offline validators pick up their root key? Is the root key going to be only for people who are online every 30 days, so they can do rfc5011 ? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqXiZcACgkQkDLqNwOhpPh1WACbBl/vlj1OYMMUQy9zl9Q3qVfa 7PcAoIWHI/DT9/4LfCrcAG1I7JHMbsmD =sCZV -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
