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

[Michael StJohns <[e-mail]>]

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?