Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

[Tony Finch <[e-mail]>]

Paul Vixie <[e-mail]> wrote:
>
> devices which cannot be updated by their makers must expire

Definitely.

I think the problem that most concerns me is the device that spends 3 or 6
months in a box between manufacturing and deployment, and which expects to
do a software update when it is plugged in, but there was a DNSSEC root
key rollover in the intervening time.

At the moment the only solution we can offer is to turn off DNSSEC until
the device has done enough updating to be able to turn DNSSEC on again.
Which is to say, DNSSEC is a hindrance not a help. This is an embarrassing
failure.

RFC 5011 with long-lived standby keys helps with this problem, but it has
not been deployed that way, and there are good engineering reasons for not
changing that, and no desire to try to do so.

My aim for the trust anchor witnesses is to cut the circular dependency
loops as simply as I can, so that when a device boots and finds the world
has changed around it, it has a straightforward way to get itself working.

There are a few pertinent differences between trust anchor witnesses and
the undeployed RFC 5011 many-keys setup:

* in RFC 5011 each key is completely trusted, whereas no witness is
  trusted; compromise of an RFC 5011 key compromises the whole system,
  whereas compromise of a witness is equivalent to unavailability (up
  to the quorum size);

* RFC 5011 requires close co-operation between key holders for updating
  the DNSKEY RRset and its signatures, whereas trust anchor witnesses
  operate independently.

* Part of the circular dependency loop is accurate time, and it's easy to
  get trust anchor witnesses to tell you the time as well; not so easy
  purely within the DNS.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Sole: Southeast becoming cyclonic, 6 to gale 8. Moderate or rough. Rain or
showers. Moderate, occasionally poor.