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

[Tony Finch <[e-mail]>]

Michael StJohns <[e-mail]> wrote:
>
> There are three questions I have about your solution -

> 1) Do you expect it to be usable each time a device boots?

Yes.

(It's only necessary to consult the witnesses if the device's stored trust
anchor doesn't work, for whatever reason. This might include an incorrect
clock, so witnesses need to provide the time as well as the root trust
anchors.)

> 2) If (1), how long in years to you expect it to be usable?

(In my current design which I haven't written down properly) each witness
is statically configured with IPv4/IPv6 addresses and a self-signed HTTPS
cert. So your question boils down to, how long can we expect the IP
addresses to remain stable and the TLS private key to remain secure?

The root DNS servers give us a practical upper estimate of 20 years or
more. (I think it's a reasonable comparison because when a device consults
the witnesses, it needs to allow for some attrition, like root priming
queries.) And IP addresses that have been stable for 10 years or more are
not uncommon in normal ops - think of the difficulty of renumbering a
widely-used secondary DNS provider.

X.509 CA certs are typically valid for 30 years, so a witness's private
CA should be able to aim for a similar lifetime.

I think a reasonable goal is that a device should still be able to get a
quorum with a 10-year-old witness configuration, but as you say, it
requires some careful operational modelling (more than I have done so
far) to work out what is feasible.

> 3) if (1), do you expect that any query will change your default trust
> state (e.g. the selection of witnesses)?

No, the witness configuration is static, though it should be kept
relatively fresh by software updates.

> Joe's problem AFAICT simply stated is that 5011 doesn't necessarily work
> for a device that's been on the shelves for 3-4 years.  My counter is
> that anyone who expects a device to come into service after four years
> on the shelf without requiring some intervention is somewhat optimistic.

Put me in the crazy optimist tent then :-)

> If the answer to (1) is "Yes, this is used every time to figure out what
> the trust anchors are" I would suggest that you then have simply moved
> the TA management problem one level up and will need to maintain state
> for each of the witnesses for as long as the answer to (2).  (I.e., if
> you can't answer the question of "how does the system continue to
> operate if N of the witnesses have gone dark and/or been replaced by
> other witnesses?" then you don't have a viable system.

A device only needs to keep state for the root DNSSEC TA. The trust state
for witnesses is static. The lifetime is determined by the number of
witnesses, the size of the quorum, and the witness attrition rate.
We could get attrition rate numbers from looking at lossage of root dns
servers, large DNS providers, certificate authorities, and suchlike.

(It might be a good idea to keep some timing info to avoid spamming the
witnesses, but that's soft state for controlling load, and doesn't affect
trust decisions.)

> The problem with the generic "splitting trust" model, is that you have
> an initial set of pseudo-trusted entities that you combine to gain final
> trust.   In the DNS root model, it is doubtful that you can get a
> sufficiently static set of entities for even a 5-8 year period of time
> except for the roots.  And even then, you can only assume that the
> address mappings of the roots are static, and not any key pairs that
> might identify the end points.

I'm less pessimistic :-) For the key pairs, the right model is probably
for each witness to have a long-term offline key, used for the self-signed
cert that is installed in devices, which chains to the live cert on the
witness https servers - the latter don't need to be static.

> I don't think this invalidates P1 - a human chooses.   The policy
> specified by the human is substituting for: "Take the one DS of the root
> in the file"; with "Go ask N entities, pick the answer that M give
> you".  In either case, the client executes the policy engine to get a
> result.

True, but I think the extra indirection is important for adding long-term
robustness.

> I got it.  And as a point solution where you own both client and
> witnesses, its not a bad one.   But this is an infrastructure system
> that has to work under a lot of really critical assumptions.  5011 was
> designed to be no worse for a generally live client than DNS in general
> - it has no external dependencies (e.g. CA's) and can be used anywhere
> DNS is available.

I want to allow long-sleeping devices to be able to recover trust too.
My external dependencies - the witnesses - are not hard dependencies
individually, in the way that I have seen for CAs in other suggestions.

> Firewalls are a nasty part of the problem and any solution that augments
> or replaces 5011 needs to work around most if not all firewall
> restrictions.

I hope https should work OK :-) I'd prefer something that's DNS only, but
it would require doing really weird stuff (iirc my old draft is like
this), whereas https is very familiar and has abundant tooling.

Thanks for a lot of good probing questions :-)

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Humber: East 4 or 5, backing northeast 5 to 7 for a time. Moderate or rough.
Occasional rain or sleet. Moderate or poor.