On 21-Aug-2009, at 10:08, W.C.A. Wijngaards wrote:
Is available for review and comment. This represents my take on how to perform trust-anchor management for a validator without having a system update mechanism (which works with unsafe DNS).
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.
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.
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.
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.
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.
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).
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".
Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
