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

From: Tony Finch <[email-masked]>
Date: Sun, 1 Apr 2018 15:23:24 +0100

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.

I think that's a good suggestion for the short term. For the longer
term I would like it to be possible to say that DANE is a reasonable
way to authenticate software updates, but at the moment it is not.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Variable, mainly northerly 3 or 4,
occasionally 5 for a time. Slight or moderate. Wintry showers. Good
occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 01 Apr 2018 10:59:28 -0700

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

i believe that software packaging systems will never put that many 
moving parts between their users and their updates. it'll remain some 
flavour of non-distributed keying, like pgp and ssh, simply because of 
the risk/benefit ratio of adding third parties.

i see a bright future for DANE, because of user-driven web and e-mail 
transactions, that are not point-source trust models.

-- 
P Vixie

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 1 Apr 2018 15:20:50 -0400

On Sun, Apr 1, 2018 at 1:59 PM, Paul Vixie <[email-masked]> wrote:

> i believe that software packaging systems will never put that many moving
> parts between their users and their updates. it'll remain some flavour of
> non-distributed keying, like pgp and ssh, simply because of the
> risk/benefit ratio of adding third parties.
>
> ​
   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698
<https://tools.ietf.org/html/rfc6698>, August 2012.

​The RFC was published six years ago. Has anything happened since that
suggests this is the basis for a ubiquitous infrastructure? I am not aware
of anything.

I see a big future for using DNSSEC to distribute authenticated security
policies. But not via the TLSA record. It was tried, it failed.

Prefixed TXT records work and they do not demand end entities consider
their DNSSEC trust root to be trustworthy. Which is kind of essential if
you find yourself in the part of the world where the government is going to
insist that you trust their national DNSSEC root and not the ICANN one.

The only root of trust that is ever going to be acceptable to me is me. And
I am not the only person who thinks that way, ​the US federal government
developed the BridgeCA concept because US government agencies can't agree
who is going to be the ultimate source of trust among them. So you can be
absolutely certain they are never going to agree to it being ICANN.

​
​
On Fri, Mar 30, 2018 at 12:06 PM, Tony Finch <[email-masked]> wrote:

> Phillip Hallam-Baker <[email-masked]> wrote:
>
> > But even if we accept the need for updates, where does the ground truth
> > for the updates come from?
>
> Your vendor gets to decide :-)
>
>
Well that is precisely the point. One of the chief reasons I uninstall
software on machines is that it keeps making demands for updates.

What people tell each other is good security practice is often wrong or
even broken. We told people to change their passwords frequently for
decades until people did actual research and found that it was a terrible
idea and makes things worse, not better.

Keeping software up to date is one security CONCERN. It is one control that
addresses one potential source of risk in a system. It does not trump every
other concern.

In particular, I have managed systems in the past that have been either
subject to nation state level attack or are obvious targets for such
attack. The idea that such an actor would suborn a
​manufacturer is far from far-fetched, it has happened.

Hence my requirement that every actor be their own ultimate source of trust
but with the option to delegate management of that source of trust to a
third party of their choice.​

---

From: Michael StJohns <[email-masked]>
Date: Wed, 11 Apr 2018 18:31:43 -0400

Sorry its taken me so long to get back to this.

On 3/31/2018 7:09 PM, Tony Finch wrote:
> 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.

You forgot:

* A 5011 trust system is maintained as part of the root zone - as long 
as the root zone is maintained, the 5011 trust system is maintained.

* The "requires close cooperation" bullet is just wrong.  It turns out 
that the SPECIFIC mechanism they're currently using requires everyone to 
show up in a certain place, but that's an artifact of process, not of 
protocol.  (Happy to sketch out a different protocol - its pretty 
straight forward).

* But time also requires a source of trust - if you can spoof enough 
witnesses, you can spoof time.  In any event, time is irrelevant  at the 
system level- each relying party is responsible for figuring out its 
source of time - in both systems.

One of the reasons I went away was to try and figure out how to 
accurately analyze your approach.

Before you start down this approach, you need to figure out at least a 
few parameters:

1) How many total witnesses?  (Since you won't be maintaining the 
system, these are all there ever will be)

2) How many of the witnesses are enough to assume trust?

3) How long do you want this system to work?

It turns out that the lifetime of an un-maintained M of N system has 
exactly the same characteristics as a nuclear decay analysis. E.g. Given 
a starting population of N, an ending population of M and a period of Y, 
what is the half-life of the system?   From the half-life of the system, 
you can calculate the minimum average mean time to failure of any given 
witness.

And its nice that there is this 
http://www.calculator.net/half-life-calculator.html online.

So let's start out with a 3 of 10 system with a required lifetime of 20 
years (240 months).  The half-life of the system is 138.2 months and the 
average required MTTF is 199 months or about 16.5 years.   That means 
that you have to expect that any given witness will be around and 
available AT the place it was originally available at for around 17 years.

It gets better with more witnesses, say 3 of 15:  149 months or about 
12.5 years MTTF.  That's a bit better, but that's an average - you still 
have to ensure that 3 of those systems will be around for the 20 years, 
and you have to ensure they aren't compromised in the mean time.

But it gets worse if you increase the number of required witnesses - say 
5 of 15 - 218 months or a required average MTTF of 18.2 years for that 
set of 15 witnesses.

Now you could add a maintenance protocol, and the ability to add and 
delete witnesses, but guess what - you end up looking like 5011, but 
with the problem of how to manage the trust set of the trust set.

This reminds me of the "Turtles all the way down" recursion.

Later, Mike