-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Joe,
In reply to your email, and the discussion following. On 08/25/2009 03:22 AM, Joe Abley wrote: > I don't remember whether I've expressed my concerns about this work in > e-mail before. I remember talking to people in Stockholm about it. I'm sorry we missed talking. Your email is clear, and well written. > Keys are rolled for a reason. You can't always tell from the outside, as > an automated device, what the reason was -- it could be that it's a > conservative defence against a possible factoring attack having been > executed within a particular time, or it could be due to a key compromise. Given the discussion with Glassey, Manning and Moreau, I think I'll omit discussion of key compromise causes. Keys can be compromised, which is enough, and zone operators can choose to either use the draft or not. > A historical key has been replaced by a new one. A historical key is not > to be trusted. Signatures made by a historical key are not to be trusted. You have a good point here. But trusted by whom and for what. The effect of rollover and the trust history draft is that most people, who are online reasonably often have the latest keys. If you roll at reasonable speed, say months or a year, then that is probably almost everyone, lets call that number 99% here. Some machines however have been offline, say half a year or two years, and this 0.9% of people have the 'previous key'. Then a long list of older and older machines, with older keys, but also few of them. And it ends with some lone geek who still has an original copy of windows-9 or freebsd-9 :-). 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. > This work seeks to solve a real problem, as far as I can see -- the > problem of how a validator which has been disconnected from the network > for some period of time can bootstrap itself based on a trust anchor > that was once good. Yes that is the problem statement. > It's not clear to me that using signatures from keys which are known not > to be trusted is a good way for such validators to bootstrap themselves. > In fact, I suggest that in general it's a bad way to do it, since in the > event of key compromise the result could be the propagation of rogue > trust anchors which might be hard to identify operationally. Well after key compromise and subsequent 'software install', the entire machine could be re-installed with something else... So, if the mechanism is broken, then like any other security mechanism, the machine is compromised. > I have doubts that there is *any* general, in-protocol mechanism for > this problem to be solved. It seems possible to me that the right answer > may be that individual validators need to implement their own > out-of-band mechanisms for acquiring an initial trust anchor, e.g. using > existing software update mechanisms and other cryptographic means of > establishing trust (e.g. TLS/X.509). 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. > If I was to sum up my concern in one sentence, it would be "if you can > trust old keys sufficiently to use them to find a trust anchor, you > don't need to roll them in the first place". No. Because the trust is by different persons. Below I put us in the position of each in turn. The zone owner does not trust it enough, and wants roll over. The zone owner knows that whatever lifetime it gives, it needs to roll after that. 20 years later the number of bits may be a little small, or there are better algorithms, ... and so on. Therefore, the keys must roll. Might as well every year, that keeps staff and operations ready (like a fire drill). Or perhaps there are advantages (less time to do that brute force key cracking) to rolling regularly. If he rolls every year, and the key is cracked after 1year and a month, then that attacker just missed 99% of the targets. And has trouble identifying the remaining 1% hiding amongst the rest. Validator users of course, are usually in that 99%, and have recent and secure keys. For the other 1% of users, they only have this old key. If the user knows the key is compromised via other means, well we have the out-of-band channel done then. Otherwise, this algorithm gives the user every bit's worth of security out of the old key. And a leap of faith if the algorithm is now weaker than rot13. For many users, a leap of faith, only once per several years, may be strong enough security. In that case the user would want to trust keys 'forever'. Thus, "trust old keys sufficiently" means something different for different people. Does this alleviate your concerns, Joe? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqWmRoACgkQkDLqNwOhpPhX/gCfdAUIpp3aYvnT3DXYu3mRggo5 CkQAniJwJEL3c9OGDmfrJ62mWNv1mvPm =M8sU -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
