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

From: Tony Finch <[email-masked]>
Date: Thu, 13 Feb 2014 20:56:25 +0000

There was some discussion last month about dispersing trust in the root.
http://www.ietf.org/mail-archive/web/dnsop/current/msg10977.html

This inspired me to write up a concrete proposal for the
quorum-of-witnesses idea that I have vaguely suggested several
times over the last few years.

All thoughts / suggestions / criticisms welcomed.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  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.

---------- Forwarded message ----------
Date: Thu, 13 Feb 2014 12:50:35 -0800
From: [email-masked]
To: Tony Finch <[email-masked]>, Tony Finch <[email-masked]>
Subject: New Version Notification for
    draft-fanf-dnsop-trust-anchor-witnesses-00.txt

A new version of I-D, draft-fanf-dnsop-trust-anchor-witnesses-00.txt
has been successfully submitted by Tony Finch and posted to the
IETF repository.

Name:		draft-fanf-dnsop-trust-anchor-witnesses
Revision:	00
Title:		The WS resource record: dispersing trust in the DNSSEC root keys
Document date:	2014-02-13
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-fanf-dnsop-trust-anchor-witnesses-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fanf-dnsop-trust-anchor-witnesses/
Htmlized:       http://tools.ietf.org/html/draft-fanf-dnsop-trust-anchor-witnesses-00

Abstract:
   At the moment the root DNSSEC key is a single point of trust and a
   single point of failure for the whole system.  This memo describes a
   mechanism for dispersing trust in the root key.  Witnesses vouch for
   the root trust anchor by publishing WS records in the DNS.
   Validators only update their root trust anchors if multiple witnesses
   agree.  The root-witnesses.arpa zone enables a validator to bootstrap
   trust when it has no working trust anchors other than its witnesses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Matthäus Wander <[email-masked]>
Date: Fri, 14 Feb 2014 00:45:38 +0100

> times over the last few years.

The proposed approach disperses the trust into which TA to choose and
when to rollover to a new TA. However, it does not disperse the trust
that the TA is not misused and not compromised. If I have to fully trust
the TA private key holder anyway, my personal assessment would be to
trust their TA publication channel as well, e.g. the ones in
draft-jabley-dnssec-trust-anchor.

The problem I see is the asymmetry of roles between the TA private key
holder and the witnesses. The witnesses have no means to assert that the
TA holder does not share the key with their government or anybody else.
To disperse the trust of a key, you would need a threshold cryptosystem
where the TA private key portions are shared among equal peers.

Regards,
Matt

-- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg

---

From: Joe Abley <[email-masked]>
Date: Thu, 13 Feb 2014 19:02:26 -0500

Hi Tony,

> All thoughts / suggestions / criticisms welcomed.

I agree with your thoughts in the draft that (to paraphrase) there has been remarkably little interest in working on (or implementing) the suggestions in draft-jabley-dnssec-trust-anchor.

The ability to bootstrap the trust anchor for the root zone without operator intervention (e.g. on embedded devices, or any computer system or application with a non-technical user) is weak as currently deployed. An approach which is robust and for which there is enthusiasm to implement is sorely needed.

Some additional thoughts on the actual text, below. This started off being brief, but then I got on a roll. Sorry about that.

One comment, in case it's not obvious: I once worked for ICANN, and I once had some responsibility for parts of the root zone DNSSEC system. I no longer work for ICANN, however, and anything you read below that looks like a fact should be treated with distrust and suspicion.

> Abstract

You're using "root key" and "root trust anchor" a bit loosely here; my presumption is that you're talking about the root zone KSKs, and a trust anchor set which corresponds to a set of active (non-revoked, published) KSKs in the root zone.

> 1.  Introduction
>    single point of failure for the whole system.  It has a number of
>    problems:
> 
>    o  Root trust anchor rollovers using [RFC5011] require validators to
>       be online while the rollover happens.  With the current root key
>       management plan, rollovers take a few weeks.  This is
>       uncomfortably long for emergency rollovers.

I don't believe the various systems that manage DNSSEC in the root zone have a way to execute an emergency KSK roll whilst still following RFC 5011 semantics. There's a single active key, for example, and no standby key. What was specified in the root zone was the use of 5011 timers for scheduled rollovers; a definitive compromise of the active KSK would trigger other action. It would be nice if this was more definitively specified (and better mechanisms to bootstrap trust would help with that).

>    o  Systems that are offline during a rollover have to use an out-of-
>       band mechanism to update their trust anchors, relying on non-DNS
>       sources of trust.  There is no clear specification or security
>       analysis for this process.

Well, there were a couple of attempts:

  draft-jabley-dnssec-trust-anchor-08
  draft-jabley-dnsop-validator-bootstrap-00 (expired)

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

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

>    This memo describes a mechanism for dispersing trust in the root key.

"another mechanism" :-)

>    Witnesses vouch for the root trust anchor by publishing WS records in
>    the DNS.  Validators only update their root trust anchors if multiple
>    witnesses agree.
> 
>    There are some potential advantages:
> 
>    o  It can allow for a crash rollover of the root key, in the event
>       that it is lost or compromised, with validators recovering
>       automatically rather than having to be manually forced to fetch
>       and authenticate the replacement trust anchor.

crash -> emergency, presumably.

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

>    o  It could allow a smaller root DNSKEY RRset by allowing the
>       witnesses to vouch for the root ZSK directly instead of via a KSK.
>       This saves the cost of high-assurance storage for the root KSK,
>       but requires more frequent communication between the root DNSSEC
>       key managers and the witnesses.

As I'm sure you appreciate, this advantage would only be realised if there was a change in the way that the work is divided up amongst the root zone partners. At present, there is a deliberate separation between KSK management and ZSK management. The intersection between the two is entirely conducted at key ceremonies which are widely scrutinised.

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

>    There are some limitations and disadvantages:
> 
>    o  It does not disperse trust in the root zone signing key or root
>       zone maintenance.

"root zone signing key" is a bit vague. I presume you mean the ZSK.

"root zone maintenance" is a bit vague. I presume you mean the process of applying changes to the root zone and signing it by the root zone maintainer, and not the various other pieces of the system?

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

I realise you're not trying to boil the ocean with this -00; this is not criticism, just ideas for future typing :-)

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

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

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

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

> 3.2.  When to try a trust anchor update
> 
>    The validator SHALL keep track of the DNSKEY records from the DNS at
>    the trust anchor name. It only tracks the set of all records with
>    the SEP flag set, or the subset of SEP keys with algorithms supported
>    by the validator.  (This is so that ZSK rollovers do not trigger
>    trust anchor updates.)

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.

>    When the validator notices that this set has changed it SHOULD
>    attempt to update the trust anchor as described below.  During the
>    update process it SHOULD continue to serve clients and use the
>    existing trust anchor to validate responses.
> 
>    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?

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

>    A broken trust anchor is not expected to happen during normal
>    operations, since validation ought to work at every point in a key
>    rollover.  However, if some disaster occurs and the trust anchor
>    private key is lost or compromised, there might be a disruptive crash
>    key rollover.
> 
>    When it sees a crash rollover, a validator will not be able to
>    validate the new DNSKEY RRset, so will discard it and retry the query
>    in an attempt to obtain a working version.  If this problem persists
>    the validator MAY attempt to update the trust anchor using an invalid
>    DNSKEY response.
> 
> 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.

>    The validator queries for the WS RRset at each of the trust anchor's
>    witnesses.  The witnesses SHOULD be queried in a random order, so
>    that the validator avoids relying too much on a subset of the
>    witnesses.  The query process SHOULD stop when a quorum has been
>    achieved for one or more WS RRs.  The queries MAY be performed
>    concurrently to improve performance (though it doesn't make sense to
>    use a level of concurrency greater than the quorum size).

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?

>    The witness queries follow normal DNS resolution and DNSSEC
>    validation rules.  The response from a witness MUST validate as
>    secure using that witness's trust anchor.  (The special arrangements
>    for the root trust anchor witnesses described in Section 5.1 ensure
>    that the requirements in this paragraph can be satisfied even when
>    the root trust anchor is broken.)
> 
>    The validator MUST ensure there are no duplicate WS RRs in the
>    response from a witness.  Duplicate RRs are not allowed (see
>    [RFC2181] section 5), but it is particularly important to prevent
>    duplicate WS RRs so that a witness cannot count more than once
>    towards a quorum.
> 
>    The validator SHOULD ignore a WS RR if it does not contain a valid
>    digest of a DNSKEY record with the SEP flag set.  This ensures that
>    the validator does not count a quorum of useless WS RRs.
> 
>    For each usable WS RR that the validator receives from a witness, it
>    keeps a count of the number of responses that contained that WS RR.
> 
>    A WS RR can be trusted when this count reaches the required quorum.

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?

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.

>    If the trust anchor that is being updated is configured with DS RRs,
>    then the validator converts the trusted WS RRs into DS RRs by
>    changing their RR TYPE fields and uses those for the new
>    configuration.  If the trust anchor is configured with public keys,
>    then the new keys are taken from the DNSKEY RRs that are
>    authenticated by the trusted WS RRs.
> 
> 
> 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.

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

>    Witnesses are continually retired.  It is expected that some
>    witnesses will have to retire early, for instance, if their keys are
>    lost or compromised, or if their host organization is no longer able
>    to maintain them.  This is OK since there are plenty of other
>    witnesses.
> 
>    New witnesses are continually introduced.  Validators configured with
>    an up-to-date set of witnesses will have a decent lifetime.  Given an
>    average witness lifetime of W years, a pool of P witnesses, and a
>    quorum size of Q, we expect P/W witness retirements per year.  A
>    validator configuration will last until there are Q witnesses left,
>    that is, until there have been P-Q retirements, which takes V=(P-
>    Q)*(W/P) years.  For example, if P=30, W=10, and Q=6, then V=8.
> 
>    A witness organization may run multiple witness zones on a rolling
>    replacement schedule in order to avoid a hiatus when a zone is
>    retired.  Validators SHOULD be configured to use only one witness
>    zone from each witness organization, to avoid trusting one
>    organization too much.

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.

> 5.  The root trust anchor
> 
> 5.1.  Locating root trust anchor witness zones
> 
>    There is a bootstrapping problem when a validator has an out-of-date
>    root trust anchor: it needs to find the name servers for the witness
>    zones in order to be able to get the WS records that vouch for the
>    new root trust anchor; however it is unable to validate the responses
>    it gets while resolving the name server addresses.  This section
>    describes how to minimize this bootstrapping problem.
> 
>    All root witness zones SHALL be delegated from a single parent zone,
>    called root-witnesses.arpa.  This zone is to be maintained by IANA.
>    A delegation in this zone indicates that there are out-of-band
>    arrangements between the root DNSSEC key managers (XXX do they have a
>    better name?) and the witness organization allowing the witness
>    organization to meaningfully vouch for changes to the root DNSSEC
>    trust anchor.

The Root Zone Manager role is currently carried out by Verisign. They manage the ZSKs, they edit the zone to apply authorised changes, they sign the root zone, and they distribute it to root servers.

The IANA Functions Operator role is currently carried out by ICANN. They manage the KSKs, publish trust anchors, and exercise the KSK during ceremonies to sign enough DNSKEY RRSets provided by the Root Zone Maintainer for the root zone to be re-signed and published for the next N months.

Changes to the root zone are authorised by US DoC NTIA.

Collectively, the Root Zone Manager, the IANA Functions Operator and NTIA are referred to as the Root Zone Partners.

(I think. I no longer have to worry about these details on a daily basis. The IANA Functions Contract and the Cooperative Agreement are public, I think; you'll probably find them on ntia.doc.gov if you're interested. All those phrases are surely in those documents, somewhere.)

>    The root-witnesses.arpa zone SHOULD NOT be signed.  Leaving the zone
>    unsigned prevents the risk that validators will use some higher-level
>    trust anchor to validate responses from a witness zone rather than
>    the witness trust anchor itself.  In particular we want to avoid a
>    compromised root key being used to vouch for itself.  The purpose of
>    the root-witnesses.arpa zone is to contain delegation NS RRs and glue
>    address records for the witness zones, and these records are never
>    signed.  The signed parts of delegations are the DS RRsets; omitting
>    those prevents unsafe witness validation, but also leaves almost
>    nothing in the root-witnesses.arpa zone to sign.
> 
>    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?

Surely it's the WS RRSets we want to validate. How we get them is largely irrelevant. They either validate against a locally-configured trust anchor or they don't. If someone pilosov/kapela's a route for a real witness server and sneakily sends me a perfectly good response which validates, then giddy up, I'm using it.

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

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?

> Appendix A.  Questions
> 
>    Should this this scheme be extended to be more like DLV?

I think the answer to that is no, regardless of what scheme you're talking about. :-)

Joe

---

From: Tony Finch <[email-masked]>
Date: Fri, 14 Feb 2014 21:02:29 +0000

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

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

Yeah :-/

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

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

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

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

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

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

> persistently -> regularly?

I intended to mean on non-volatile storage.

> What about queries received from clients with CD=1?

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

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

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

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

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

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Feb 2014 16:02:56 -0500

Hi Tony,

> review of formal terminology.

Right, completely understood. That's how I read it.

> trusted in the way that an X.509 CA is.

I think there's an inherent assumption here that by validating a certificate, a bootstrapping validator might be vulnerable against any one of the various attacks that have afflicted browsers, the core problem there being that of the browser list and not the mechanics of validating a certificate.

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.

> only the DNS and leaves validation switched on while bootstrapping.

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 tried to spell this out in draft-jabley-dnsop-validator-bootstrap.

It occurs to me that we now have three drafts that speak to an active need (and try to fill a gap in DNSSEC deployment that at least some of us think needs to be filled):

  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.

Suz/Tim/ADs: opinions on whether this is a useful bundle of work for dnsop? (No, I'm not (necessarily) requesting another agenda slot for London :-)

Joe