Dave Lawrence <tale@dd.org> wrote:
Yes, exactly, which makes me scratch my head every time someone proposes a list of pre-generated keys as the solution to this problem.
Right, pre-generated keys don't make any meaningful difference to the cryptographic security of the system: they are to do with operational preparedness. But it's arguable whether they help very much with that either :-) The underlying issue is that we don't have a bootstrap system. If we did, then it ought to be able to solve the device-on-a-shelf problem and the compromise problem. (And the time problem!) Currently the consensus seems to be, let vendors deal with the problem; or (like unbound-anchor) rely on the ICANN publication signing keys, which just moves the problem from one key to another more mysterious key. A few years ago I wrote down some ideas about having a set of third-party "witnesses" that can answer questions about the current root key and time. No witness is trusted by itself; instead a client only believes an answer if enough witnesses agree. A client is pre-configured with several long-lived witness IP addresses and keys. The client requires a quorum of some subset of its configured witnesses when it is bootstrapping. A few witnesses can fail for whatever reason (compromise, bankruptcy, ...) and clients can still bootstrap OK. So there's no single point of failure, and the lifetime of devices on shelves depends only on the attrition rate of witnesses. I originally thought of implementing this idea on top of DNS; then later https; now I think roughtime might be a good option. But the hard part is getting witnesses lined up and committing to provide the service. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Southeast Iceland: Southwesterly 5 to 7, occasionally gale 8 later. Moderate or rough, becoming very rough later. Rain then showers. Good, occasionally poor.