Hi -
Joe Abley introduced draft-jabley-dnsop-bootstrap-validator [jabbootval]
at the DNSOP session this past week. I was the only (one of the few?)
person who suggested that this was a bad idea. Later that week, we ran
into each other in the bar and chatted for not long enough to sync, but
long enough for him to get the gist of why I was thinking what I'm
thinking. I thought I'd try and get on the record my reasoning.
If you don't want to read this then consider this instead (my conclusion
at the end):
So before we head off to Joe's draft or its ilk, I'd like to suggest
to the chairs that we first review RFC4986 and see if there are
changes to be made there. If the environment has changed such that
the requirements are changed, then a change in the way the root trust
anchors are managed in validators *might* be in order.
These are all described from the point of view of a single resolver.
Assume that the text is written understanding that there are many ways a
given resolver may manage their trust stores, but that this discussion
is looking at no human in the loop after initial root of trust
establishment.
Terms:
* Root of trust - the actual key from which trust may be traced.
* DNS Root Trust anchor - the highest point in the DNS from which
trust may be traced - usually the same as Root of trust, but not the
case in the referenced draft
Proposition 1 (P1): The initial selection of a root of trust (ROT) on
behalf of a validator ALWAYS involves a human in the loop. It may not
be obvious which human(s), but it is always the case someone (not a
computer) decided. The selector may be the person configuring the
validator or the set of people who compile the code with the validator,
or linux distribution manager, but the initial selection always involves
a judgement call of some sort by a human. In many cases, this is a
judgement call is based on external information (like widespread
publication of the ROT information or multiple third party endorsements
(e.g. reputation evaluation)).
[Note: There are HITL both at the publication and validation points -
this discussion concerns the validation points. A human will almost
always be involved on the publication side for invalidating, issuing and
updating trust public keys.]
Proposition 2 (P2): If you have an existing ROT, then you can
replace/supercede the ROT information by doing the process for initial
selection of a root of trust, or by extending the trust you already have
in the current ROT and tracing the chain of trust from that ROT to a new
trusted key. Depending on the model, the new trusted key either becomes
another link in the chain (a subsidiary trust point ), becomes an
additional co-equal ROT (5011s model and transitory ICANN DNS Root
model), or replaces the ROT (ICANN's steadys-state DNS Root model).
Proposition 3 (P3): If you have an existing ROT, then you can
replace/supercede subsidiary trust information by simply re-signing
replacement information. This is [jabbootval]'s model. Note that the
ROT of trust for DNS in [jabbootval] is no longer any of the DNS Root
Trust Anchors, but the CA's key.
Corollary 1 (C1): If P3 is true, the mitigation of a compromised of a
DNS Trust anchor under a CA ROT may be accomplished automatically with
no need for a human in the loop at the validator side ([jabbootval]'s
model).
Proposition 4 (P4): The compromise of a singleton ROT (or more
generally of all ROTs) leading to the "no trust" condition, requires
repeating the "initial root of trust selection process". From the point
of view of the validator, this is almost always a manual action either
directly to the validator (manual configuration update, manual firmware
update), or indirectly through a validators control point (e.g. pushed
by a NOC).
Corollary 2 (C2): If P2 and P4 are true, and assuming there is more than
one ROT, the compromise of a single ROT key does not NECESSARILY require
repeating the initial root of trust selection process. However, each
validator will need to know the process for automatically invalidating
the compromised ROT, and for replacing it in a trustworthy manner. 5011
specifies a process for doing trust anchor updates. Most CAs do not.
However, see Russ Housley's
https://datatracker.ietf.org/doc/draft-housley-hash-of-root-key-cert-extn/
- an extension for a CA to specify its NEXT public key as a possible
approach for CAs.
Corollary 3 (C3): If P4, C1 and P1 are true, simply moving the ROT from
the DNS Root Trust Anchor set to one or more CA ROTs does not mitigate
against ROT compromise, it only moves the responsibility for mitigating
the problem from the DNSSEC system to the CA system.
Corollary 4 (C4): If C3 and P3 are true, and the requirements from
RFC4986 remain unchanged, then a change to a CA centric DNS Root of
Trust will probably require a set of protocols and procedures to update
the set of CA roots of trust in the validators. That might be as
simple as a firmware or config file update, but then begs the question
of what triggers the updates? E.g. do we require a HITL to deal with
cataclysmic failures (CA compromise?).
_____________________________________________________
All of this is a long way of saying that TANSTAAFL - There ain't no such
thing as a free lunch. We could push the ROT management out of the DNS
space, but then we have other similar problems to solve to deal with the
same set of risks and issues at the CA level or whereever. Indirection
doesn't solve problems, it just moves them.
So before we head off to Joe's draft or its ilk, I'd like to suggest to
the chairs that we first review RFC4986 and see if there are changes to
be made there. If the environment has changed such that the
requirements are changed, then a change in the way the root trust
anchors are managed in validators *might* be in order.
Mike
ps - a question for extra credit: If we change the DNS ROT to a CA or
set of CAs, what does that do for the trust model for DANE?
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
