Re: [DNSOP] draft-fanf-dnsop-trust-anchor-witnesses-00.txt

[Tony Finch <[e-mail]>]

Joe Abley <[e-mail]> wrote:

> Hi Tony,

Hi Joe, many thanks for the thorough review. It is greatly appreciated.

I think it's fairly obvious that I wrote just enough to get the idea
across in a reasonably complete form, but didn't bother with thorough
references (in particular not to your previous work, sorry!) or thorough
review of formal terminology.

> >    o  The root key is a single point of failure with no standby, though
> >       its storage and management is extremely resilient and trustworthy
> >       (in stark contrast to the out-of-band trust anchor update keys).
>
> I presume by that you mean the X.509 certs published on
> data.iana.org/root-anchors. The goal there was to facilitate
> endorsements by multiple independent actors, each following a documented
> and audited process to verify that what they were signing was accurate.
> The use of X.509 certificates anticipated vendors of operating systems
> and embedded devices already having certificate machinery for
> code-signing, and hence this seemed like an approach that had a low
> implementation cost.
>
> Turns out the actual approach (do nothing) had an even lower implementation cost.

Yeah :-/

> >    o  The concentration of trust in the root is politically
> >       uncomfortable.
>
> This may be true, depending on exactly what you mean, but I doubt it's
> universally true (perhaps not even widely true). I'm not sure I
> understand the motivation for including that statement has in a
> technical specification, especially when you consider that the intended
> trust mechanisms were designed to be dispersed amongst multiple (e.g.
> vendor) authorities.

Unfortunately the X.509 signatures do not disperse trust, they duplicate
it. A bootstrapping validator trusts (== is vulnerable to compromise of)
any one of its X.509 CAs.

The key point of the quorum-of-witnesses idea is that no single witness is
trusted in the way that an X.509 CA is.

> crash -> emergency, presumably.

Yes. (When my wife had her first C-section I learned that the
obstetricians use the term "emergency" to mean "proceed with normal
preparation timing" and "crash" to mean "do it right now or someone will
die".)

> The existing mechanisms (again, lamentably light on implementation)
> would also facilitate this. The mechanisms in the validator-bootstrap
> draft I referred to earlier allow trust anchor retrieval with no ability
> to validate, authenticating the retrieved data using appropriate local
> methods (e.g. the key that signed the code is used to test the signature
> of the data the code retrieved).

However the existing mechanisms rely on a lot of infrastructure which has
to be accessed with validation turned off. My root witnesses idea uses
only the DNS and leaves validation switched on while bootstrapping.

> >    o It could allow a smaller root DNSKEY RRset
>
> I suspect a transition to a single key solution would be a difficult
> transition from an administrative perspective, bordering on the
> non-actionable. Listing impossible things as advantages seems like a bit
> of a stretch. :-)

Yes, I'm rather tentative about that one.

However I generally want root trust anchor rollovers to be utterly routine
and relatively frequent, so we are sure they work, and so we have a better
chance of being able to upgrade algorithms when necessary.

So I have a vague idea that we could keep the existing KSK around to
support old validators, while validators that know about witnesses use
different more frequently updated keys for their trust anchors.

> >    o A lot more co-ordination between organizations is necessary, for
> >       the witnesses to get out-of-band authentication of new trust
> >       anchors.
>
> This should not be underestimated (or at least should be characterised).
> Presumably if we expect people (and devices) to trust a collection of
> witnesses to the authenticity of a particular copy of the KSK, we don't
> want that process to dilute the security of the process used to
> generate, store and exercise the KSK. Are we talking about additional
> ceremonies, potentially tens or hundreds of them, with each witness? Or
> are we talking about something that might fit with minimal change into
> the existing ceremonies?

The latter.

If the witnesses are just authenticating the root KSK then they only need
to do so when it changes.

If we go for the slightly more radical idea of authenticating the ZSK
instead, then the witnesses would have to observe each ceremony so they
can vouch for the new ZSK(s).

Witnesses will have their own key generation and publication processes.
IANA will run the root-witnesses.arpa registry so that validator vendors
can find the witnsesses, but IANA doesn't need to do anything with the
witness keys.

> >    This mechanism can be used to automatically update any trust anchor,
> >    though it is designed for and includes some special considerations
> >    for the root trust anchor.  The root-witnesses.arpa zone is set up to
> >    enable a validator to bootstrap trust when it has no working trust
> >    anchors other than its witnesses.
>
> I'm not sure I understand the benefit of making this a general
> mechanism. The only real application it has, in these heady days of DS
> RRSet proliferation, is in the root zone; it's hard to imagine it being
> easier to set up a plausible array of witnesses for an island with an
> otherwise insecure delegation than it is to sign the parent (or just
> choose a different parent).

True. But I think that making the design general helps to ensure it is
clean - good intellectual discipline :-)

There's also the potential for supporting TLD trust anchors to disperse
trust more thoroughly. I would like to make this possible even if it turns
out the lawyers only care about blowing gas and not practical changes.

>
> > 3.  How validators use WS records
> >
> > 3.1.  Trust anchor configuration
> >
> >    A validator's configuration for a trust anchor consists of the the
> >    trust anchor owner name, and either a set of public keys or a set of
> >    DS records, as described in [RFC4035] section 4.4.
> >
> >    A trust anchor that is automatically updated is associated with the
> >    witnesses that vouch for it.  It has a quorum value stating how many
> >    witnesses must agree before the trust anchor is updated.
>
> Where is that quorum parameter published? By the KSK maintainer, or by
> individual witnesses, or is it up to the validator operator to follow
> local policy?

The latter.

> Bad choices in this parameter seem likely to cause pain (too high and
> you need to worry about the currency of a lot of witness zones; too low
> and you are at risk of shenanigans by a small number of conspiring
> witnesses).

Right. And it depends on the size of the witness pool. But even a quorum
of two or three is a lot safer than being vulnerable to dozens of X.509
CAs.

> >    Each witness is a normal statically-configured trust anchor.  That
> >    is, witnesses are not updated automatically except by out-of-band
> >    configuration updates or software updates.  Each witness is
> >    associated with one automatically updated trust anchor for which it
> >    vouches.
>
> I worry slightly that you've just shifted the problem that ICANN
> anticipated with vendors shipping a single trust anchor and made it
> larger, a problem of shipping many trust anchors from different places.
> This is the core problem we're trying to address, I think; if it's also
> a problem that needs to be solved for this proposal, we may have just
> found our own footprints on the beach.

I tried to address this worry in the "lifecycle" section. A reasonably
large level of breakage in the witness trust anchors is OK, so witness
trust anchor updates do not have to be particularly timely - they can
happen as part of the normal software update cycle. The scheme can
tolerate breakage up to P-Q, the witness pool size minus the quorum size,
provided there are fewer than Q witness compromises.

> > 3.2.  When to try a trust anchor update
>
> So, the validator receives responses to the query ./IN/DNSKEY from
> somewhere (not necessarily directly from the authority servers) and
> discards any RRs in the set with SEP=0.

Right.

> >    The validator MAY track the DNSKEY records persistently in order to
> >    make restarts faster.  If so, it SHOULD discard any saved DNSKEY
> >    records after their RRSIG expiry time.  If it does not, it SHOULD
> >    perform an update attempt at restart.
>
> persistently -> regularly?

I intended to mean on non-volatile storage.

> >    When starting, a validator can find that its existing trust anchor
> >    does not work, perhaps because a key rollover happened while it was
> >    offline.  In this situation it cannot serve clients until the update
> >    process completes successfully.
>
> What about queries received from clients with CD=1?

Good point :-) They can be served of course.

> > 3.3.  Trust anchor update process
> >
> >    Trust anchor updates are performed with respect to a DNSKEY RRset
> >    from the trust anchor owner name.  This allows the validator to
> >    ensure that a successful update will lead to a working configuration.
>
> I presume you're talking about the trust anchor for the root zone here,
> and not a trust anchor for any witness zone. "trust anchor owner name"
> is a bit of a weird phrase, but that's probably just me.

Right. I am not particularly happy with the terminology either.

> How does the validator obtain a list of witness zones? That's manually
> configured? How are additions, removals and changes to the list of
> witness zones managed?

Yes, part of the validator configuration, usually shipped by the software
vendor but could be overridden by an admin - like root hints.

> You mean a particular DNSKEY RR, retrieved without authentication from
> some arbitrary source, can be trusted when sufficient validated WS
> responses that match the DNSKEY RR under scrutiny have been retrieved?

Right.

> Surely any WS RRSet can be trusted as well as the locally-configured
> trust anchor for the zone that contains it, once you validate the WS
> RRSet's signature.

The validator needs to be sure that it gets WS records from different
sources, so that its count of the quorum is meaningful. If the validator
accepts WS RRsets that validate regardless of the key that authenticates
them, there is the risk that one compromised witness may be able to
convince the validator that it observed a quorum when really it was
bamboozled by smoke and mirrors.

Making the root-witnesses.arpa zone unsigned ensures that validators can
only validate a root witness WS RRset with the corresponding witness key.
Other witness zones (if there ever are any) should probably have similar
arrangements. And the validator code should probably check this too, for
added safety.

> > 4.  How witnesses publish WS records
> >
> >    The administrative arrangements for publishing WS records in a
> >    witness zone are analogous to publishing DS records in a parent zone.
> >
> >    There MUST be an out-of-band (non-DNS) communications channel between
> >    the witnesses and the owner of the zone for which they vouch.  This
> >    is used to authenticate WS RRset changes.
>
> If this process is to be trusted as secure, sufficient to allow
> unattended operation, etc then presumably these processes need to be
> carefully specified and audited.

I expect so. I wonder if there is any advantage to having different
witnesses follow different procedures, to reduce the chance of common
vulnerabilities. But perhaps that would be too awkward from IANA's point
of view. There is perhaps easier scope for variation in the witnesses'
publication procedures.

> > 4.2.  Lifecycle of witness zones
> >
> >    A trust anchor SHOULD have many witness zones, in order to provide
> >    resilience as well as dispersal of trust.
> >
> >    Each witness zone is tied to a fixed witness trust anchor.  The zone
> >    lasts as long as its trust anchor.  This SHOULD be at least 10 years,
> >    since old software and configurations cannot function after too many
> >    of their witnesses have been retired.
>
> "10 years" seems like a bit of a hard-coded parameter.

It needs to be long enough to give validators a decent shelf life.

> The root zone KSK was expected to be rolled every 5 years. There is
> enthusiasm in some circles for rolling the root zone KSK much more
> frequently than that. If there are reasons to roll the root zone KSK
> that often, then presumably the same reasons dictate that witness zones'
> KSKs should roll similarly?

No, instead of rolling witness trust anchors, witnesses are replaced.
This is so that witness configurations can be static, so we don't get into
an infinite regress.

But yes, rolling witness replacement should involve fairly frequent
changes to the current recommended set of witnesses.

> It's not obvious from your description how anybody should (a) obtain a
> list of witness zones, or (b) should retrieve authenticated, local trust
> anchors for sufficient witness zones such that a quorum can reliably be
> achieved. These seem like important gaps to fill.

Yes, good point. I have said a bit about that above in this message.

> >    Each witness zone's name servers have names inside that witness zone
> >    so that they can be validated by the witness trust anchor without
> >    depending on any other part of the DNS.
>
> I'm not sure I understand the purpose of this. Are you suggesting that
> if I send a query to address X but find out in the response from the
> server at that address that I should really have been talking to address
> Y, I should apply the mind bleach and start again?

No, you don't need to go that far :-) I was probably wrong to refer to
validation here - the key is being able to resolve the WS RRs with the
absolute minimum of unnecessary dependencies, so you want witness zones to
have in-zone name servers.

> >    The root-witnesses.arpa zone SHALL be served by the root name
> >    servers.  This is so that a bootstrapping validating resolver can
> >    find its witnesses using just its root hints, and get a direct
> >    referral to the right witness zone name servers, again without
> >    depending on any other part of the DNS.
>
> There's some enthusiasm for paring back the root servers even further
> than they are, and having them serve just the root and ROOT-SERVERS.NET
> zones (the latter so that priming responses can be fattened with lovely
> tasty glue).

Yes, I am aware that this part of the proposal might be contentious :-)

> To clarify your intent, are you suggesting the root servers should serve
> ROOT-WITNESSES.ARPA simply because there's a lot of them, i.e. the
> requirement is that those zones be served competently? If not, where
> does the requirement come from?

This is to support bootstrapping without depending on too much
infrastructure, so that a validator with a broken root trust anchor can
still resolve and validate WS RRsets with something very close if not
identical to normal resolution and validation logic.

So it'll make a query like a.root-witnesses.arpa. IN WS ?
It'll start by sending the query to the root servers using its hints. It
will get an immediate referral to the a.root-witnesses.arpa name servers.
It has a trust anchor for that zone so it doesn't need to validate the
referral. It will repeats the WS query to the witness name servers, then
it can validate the query by asking the same servers for their DNSKEY
RRset and using its witness trust anchor.

If the zone were hosted elsewhere, the referral from the root name servers
would be to the arpa servers. Normal logic would be to validate this
referral, but it can't because its root trust anchor is broken. You don't
want bootstrapping to fail so quickly...

Thanks again for the review.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.