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

From: Michael StJohns <[email-masked]>
Date: Mon, 26 Mar 2018 14:27:52 -0400

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?

---

From: Tony Finch <[email-masked]>
Date: Wed, 28 Mar 2018 11:36:15 +0100

Michael StJohns <[email-masked]> wrote:

Interesting thoughts, thanks. I have a slightly different starting point,
which doesn't disagree with your argument, but leads to somewhat different
consequences.

> 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)).

I think it should be possible to automate this judgment call, given a
suitable distributed publication/endorsement mechanism. This is the point
of my trust anchor witnesses draft. The HITL doesn't select the trust
anchor directly, but instead selects the witnesses.

> 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).

With multiple trust anchor witnesses, a validator can survive the
compromise of a witness (or a witness ceasing operations, or multiple
witness failures) if it requires a large enough quorum when setting up or
recovering a trust anchor, and enough working witnesses remain. No need
for a HITL in these cases.

Loss of all witnesses should be extremely unlikely!

> 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.

Right.

My idea is different because witnesses are not individually trusted: only
a quorum is enough to establish trust. A compromised witness is basically
equivalent to an unavailable witness (unless the compromise is as big as
the quorum!)

The aim is to disperse trust, not to move it around.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Biscay, Fitzroy, Sole: West or northwest 5 to 7, increasing gale 8 at times.
Rough or very rough, occasionally high later in west Fitzroy. Rain or thundery
showers. Good, occasionally poor.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 29 Mar 2018 19:55:41 -0400

Apologies for the top post.

Thanks for the commentary.  My guess is that we're starting from 
different assumptions.

There are three questions I have about your solution - 1) Do you expect 
it to be usable each time a device boots?  2) If (1), how long in years 
to you expect it to be usable?  3) if (1), do you expect that any query 
will change your default trust state (e.g. the selection of witnesses)?

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.

If the answer to (1) is "No, this is only used for the first 
bootstrapping", then I would suggest one of two alternatives - one of 
which is similar to your proposal.  The first is that the device when 
first connected immediately downloads new firmware (which would include 
the most recent DNS trust anchor).  That becomes a don't care for DNSOP, 
but is really the correct way to deal with consumer devices which are 
the once mostly likely to be placed on the network without 
(knowledgeable) human intervention - at least for the maintenance 
lifetime.   The second is that, absent of knowledge of the DNS root of 
trust, a client queries ALL of the roots (A, B, C, etc) in the kickstart 
file and accepts a SEP DNSKEY  that appears in the root zone served by 
the majority of them.

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.

If the answer to (3) is yes, then this looks a lot like 5011.  If no, 
then you have to have a maintenance item for the set of witnesses if not 
a protocol.

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.

Trust models have bit rot.  It's just the nature of the beast.  In 
figuring out how to build a system that resists bit rot, you need to 
answer the three questions I asked, and then figure out the various 
probabilities of any given witness going dark (e.g. moving addresses, 
changing keys, shutting down, being comprimised) and figuring out the 
probability of a given client getting a "good" trust anchor at various 
points in its lifetime given changes in witnesses - e.g. a 100% 
probability at inception vs a 20% probability at year 12.  RFC5011 
considered the requirements as stated in RFC4986 and provided a system 
that was designed to be relatively bit-rot resistant (on a system basis) 
for a design life in excess of 40 years given reasonable attention to 
administration.  No system related to the DNS can be 100% bit-rot 
resistant for all clients given the one-way nature of the DNS data flows.

More in line.

> anchor directly, but instead selects the witnesses.

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.

> Loss of all witnesses should be extremely unlikely!

This is where you fall down.  This is motherhood rather than analysis.

The question needs to read:  "Given a set of N <describe the witnesses>, 
and a policy which requires M of them to be applicable, and given a 
probability of p that any given witness goes dark and stays dary in any 
given month after the start, what is the cumulative probability after X 
years, that M witnesses are available?  After Y years?  Is this 
probability > Pa - the acceptable probability (as agreed to over beer at 
IETF 102)?" Seriously, if you've got a system that has a 1% probability 
of failing after 10 years then that may not be acceptable - but I don't 
know what that probability is nor what people would find acceptable.

I'm happy to have this conversation - I think its a possible approach, 
but you need to get the assumptions correct, and then you need to 
compare the output against the requirements to see if this meets them.

> The aim is to disperse trust, not to move it around.

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. 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.

Again - thanks for the commentary - Mike

---

From: Tony Finch <[email-masked]>
Date: Fri, 30 Mar 2018 14:54:55 +0100

Michael StJohns <[email-masked]> 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.

> on the shelf without requiring some intervention is somewhat optimistic.

Put me in the crazy optimist tent then :-)

> 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.)

> 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.

> you".  In either case, the client executes the policy engine to get a

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

> 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  <[email-masked]>  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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Mar 2018 11:04:46 -0400

It is a hard problem and it is possible that there is actually no solution.

All these systems consist of a chain or a graph of signed assertions. There
is no intrinsic ground truth in PKI. All that you can do is to define a
particular key or set of keys as producing the ground truth for your
particular application.

There is also a psychological angle. People are uncomfortable with the idea
of keys with infinite validity intervals. Yet we know that key rollover
mechanisms are the most complex and error prone parts of any PKI.

Another problem we face is the question of what a device or application
should do if it cannot get an acceptable source of ground truth. A lot of
people assume that the answer should be to simply halt. Which is kind of
the wrong thing if the device is a pacemaker.

ICANN has a mechanism for specifying their ground truth that is ultimately
embodied in a sequence of root keys that are created over time.

One consequence of that approach is that I cannot build a device today for
a 20 year service life using the DNSSEC as ground truth for the PKI. No,
don't tell me why that is not a requirement because it is. 95% of all the
world's SCADA systems run code that was written in the 1990s and has not
had one byte modified since. So don't you dare claim that software updates
are essential, that is an ideological position learned from a limited set
of experience.

But even if we accept the need for updates, where does the ground truth for
the updates come from?

If you want to produce a device that has a 20 year service lifespan, the
only way you can do that is to use a PKI that is expressly designed for
that. Which is of course what CableLabs etc. do (or try to). And we need to
encourage vendors to take that approach rather than assume that they can
apply an off the shelf PKI for their purpose. All the problems of the SHA-1
phaseout in the WebPKI came from groups that had applied it to embedded
devices assuming that this would be OK.

This is of course the approach that browser and O/S vendors have taken.
They do not rely on the DNSSEC or WebPKI for validating updates, they rely
on their own PKI that is answerable only to their requirements.

... but what about user requirements? I have a perfectly good 36" plotter I
paid $50 for that is just as good as a new $2500 machine for my needs. The
only problem being getting round the planned obsolescence of ink cartridge
manufacturing being shut down.

That is why I have developed my SIN proposal which allows devices to be
subordinated to a PKI that is managed by the User/Customer and is within
their sole control.

Let us say that  MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ is the fingerprint of the
master key for the enterprise PKI for example.net This then cross certifies
the ICANN DNSSEC roots as they are published.

Thus the interpretation of the following SIN becomes as robust as the
management of the enterprise PKI:

example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz

Don't want to run the PKI yourself? Get a group of lime minded manufactuers
together and run one as a co-op (e.g. Cable Labs). Outsource management,
etc. etc.

---

From: Tony Finch <[email-masked]>
Date: Fri, 30 Mar 2018 17:06:28 +0100

Phillip Hallam-Baker <[email-masked]> wrote:

> So don't you dare claim that software updates are essential, that is an
> ideological position learned from a limited set of experience.

My position is that software updates extend the lifetime of a device. If a
device depends on external services then there's no way you can provide an
up-front guarantee that it will still work in 20 years time, but I think
it is worth doing what we can to minimize the chance of failure of old
devices and old software.

(Tangentially sort-of related to CableLabs, smart TVs are not a good
example of devices that use external services and continue to work for
many years...)

> But even if we accept the need for updates, where does the ground truth
> for the updates come from?

Your vendor gets to decide :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
a fair voting system for all elections

---

From: Paul Vixie <[email-masked]>
Date: Fri, 30 Mar 2018 09:21:51 -0700

Tony Finch wrote:
> Phillip Hallam-Baker<[email-masked]>  wrote:
>
> ...

devices which cannot be updated by their makers must expire. see:

http://geer.tinho.net/geer.blackhat.6viii14.txt

given this, the effort we're making to update dnssec trust anchors 
in-band, when the X.509 CA trust anchors are updated by the operating 
system, seems misdirected. especially since its complication grows every 
year or two, and we can't test it unit-by-unit as OS vendors do.

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Sun, 1 Apr 2018 00:09:09 +0100

Paul Vixie <[email-masked]> 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  <[email-masked]>  http://dotat.at/
Sole: Southeast becoming cyclonic, 6 to gale 8. Moderate or rough. Rain or
showers. Moderate, occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 31 Mar 2018 18:53:46 -0700

Tony Finch wrote:
> Paul Vixie<[email-masked]>  wrote:

i suggest that bind, unbound, powerdns, and so on change their packaging 
to put the trust anchor in a different upgradeable package (.deb, .rpm, 
etc) than the software itself. until and unless the package manager is 
secured by DANE rather than by ssh/pgp/x509/etc, then the solution for 
being on the shelf for several months is, do a software update before 
you try to go online.

it's only a failure if you think should have been trying to do it in the 
first place, and the more i see from 5011 and the sentinel thread, the 
more convinced i am that this should have been put deliberately out of 
scope, many years ago.

-- 
P Vixie