Joe Abley <jabley@hopcount.ca> wrote:

> To be clear, what was imagined was that a codebase which already has the
> ability to validate signatures over (say) software updates would easily
> be able to validate a certificate retrieved from data.iana.org that has
> the same kind of signature.
>
> The IANA people imagined that they would solicit specific signatures
> from specific keys relevant to bootstrapping, not that they would obtain
> signatures from commercial CAs and trust the browser list to do the
> right thing.
>
> Since the security of iOS (to choose an example at random) already
> relies upon the ability to validate signatures made by some Apple
> private key, using that same key to validate the integrity of a trust
> anchor bundle retrieved in the clear seemed like a nice easy way to
> import trust in something for which trust is important.
>
> As I mentioned, no such vendor has done this. This is just for
> clarification, not because I think it's a better mechanism than the one
> you proposed.

I think that idea is fine and makes a lot of sense, at least for systems
where you are trusting the vendor in that way.

In fact I think using vendor keys is better than what is outlined in
draft-jabley-dnssec-trust-anchor, since vendor keys are an existing point
of trust, whereas the ICANN super-root keys are additional points of
vulnerability.

It would be nice if there were a specification of vendor key
bootstrapping - how they manage their CA, how they liaise with ICANN,
and so on. It should be possible for users to override the vendor's choice
of trusted keys and distribution server and suchlike.

A problem with what you outlined above is that it doesn't scale very well
to lots of vendors. I suppose vendors outside the inner circle could do
some kind of quorum-of-witnesses thing with the officially blessed
signatures :-)

> I think validation categorically needs to be off until the validator has
> been bootstrapped (not just for this proposal, but in general). No
> validation is possible before you have a stable sense of time and a
> trusted set of local DNSSEC trust anchors. Acting as though you are
> validating when you can't possibly be seems like a bad idea, since if
> you can game validators to get stuck in that state you've defeated
> DNSSEC.

We-e-e-e-ell yes, except that you seem to have missed the fact that a
witness trust anchor DOES allow you to validate that witness's zone, using
normal validation logic. It is the combination of multiple witnesses that
allows you to update the root trust anchor, after which you can validate
the rest of the DNS. The root-witnesses.arpa zone is carefully designed to
make it possible to resolve and validate the witnesses when the rest of
the DNS cannot be validated.

Time is an interesting point. I have realised while writing this message
that I have a better answer to this problem than I previously thought.

About four months ago I did an experimental proof-of-concept of the idea
of "quorate secure time". This is based on very similar ideas to the root
witnesses: if several different entities agree on what the current time is
then you can be reasonably sure that time is correct.

https://git.csx.cam.ac.uk/x/ucs/u/fanf2/temporum.git

There are a few difficulties with the PoC, mainly because it parasitically
obtains the time from https servers.

Firstly, the servers only provide the time to one second resolution. This
is not such a big deal because in order to get a quorum we end up
super-sampling the time, so the end result is usually accurate to between
0.01s and 0.1s.

Secondly, you want to avoid using co-located and virtual hosted servers
since they violate the principle that you are getting the time from
different sources. You can do this by careful curation of the server list,
but a curated list is going to become less and less correct over time as
servers move around.

Thirdly, you need to securely authenticate the servers, otherwise a
man-in-the-middle can convince you of the wrong time. A compromised X.509
CA can screw this up, but you can protect against that by checking that
your quorum was authenticated by a sufficiently diverse set of CAs.

Now, combine temporum with the root witnesses and these problems can
easily be fixed. Make the root witnesses provide a secure time service!

Firstly, you can specify the time service to give sub-second resolution.

Secondly, the root witnesses are curated by IANA and we can have solid
assurance that their infrastructure is decently diverse.

Thirdly, we can authenticate the time servers using DNSSEC and TLSA. Each
witness has its own specific trust anchor so there is no way that one
entity can authenticate more than one witness.

I think this is the first idea for bootstrapping time securely that I am
at all happy with. (Except that its foundations do not exist.)

>   draft-jabley-dnsop-validator-bootstrap
>   draft-jabley-dnssec-trust-anchor
>   draft-fanf-dnsop-trust-anchor-witnesses
>
> It's not entirely obvious that dnsop is the right place for these (maybe
> we should talk to opsec? homenet, in the sense that these mechanisms
> need to be automatable without local operators?). But I think if they
> are going to go anywhere they need thorough working group review, and
> should not proceed as independent submissions -- this is an important
> set of definitions for real-world operation of the IANA root zone, and
> it needs to be as right as we can make it.

Definitely.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Shannon: West or southwest 4 or 5 increasing 7 or gale 8, perhaps severe gale
9 later. Rough becoming very rough, then high in southwest later. Rain then
squally showers. Moderate or good.