[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Tony Finch]

Dave Lawrence <tale at 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 at 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.