Internet DRAFT - draft-fanf-dnsop-trust-anchor-witnesses
draft-fanf-dnsop-trust-anchor-witnesses
Domain Name System Operations (dnsop) T. Finch
Internet-Draft University of Cambridge
Intended status: Standards Track February 13, 2014
Expires: August 17, 2014
The WS resource record: dispersing trust in the DNSSEC root keys
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 17, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Finch Expires August 17, 2014 [Page 1]
Internet-Draft DNSSEC trust anchor witnesses February 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The WS resource record . . . . . . . . . . . . . . . . . . . . 4
3. How validators use WS records . . . . . . . . . . . . . . . . 5
3.1. Trust anchor configuration . . . . . . . . . . . . . . . . 5
3.2. When to try a trust anchor update . . . . . . . . . . . . 5
3.3. Trust anchor update process . . . . . . . . . . . . . . . 6
4. How witnesses publish WS records . . . . . . . . . . . . . . . 7
4.1. Contents of a witness zone . . . . . . . . . . . . . . . . 7
4.2. Lifecycle of witness zones . . . . . . . . . . . . . . . . 8
5. The root trust anchor . . . . . . . . . . . . . . . . . . . . 8
5.1. Locating root trust anchor witness zones . . . . . . . . . 8
5.2. Root trust anchor witness organizations . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative references . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Questions . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Finch Expires August 17, 2014 [Page 2]
Internet-Draft DNSSEC trust anchor witnesses February 2014
1. Introduction
At the moment the root DNSSEC key is a single point of trust and a
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.
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.
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).
o The concentration of trust in the root is politically
uncomfortable.
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.
This mechanism has the following advantages:
o There is no single point of failure since there are many witnesses
not one of which is completely trusted.
o There are no special timing constraints as in [RFC5011].
Witnessed trust anchor updates are like normal KSK rollovers.
o The mechanism is in-band, using only DNS, even for bootstrapping.
o The same procedure works for online and offline key rollovers.
o Rollovers can become routine.
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.
Finch Expires August 17, 2014 [Page 3]
Internet-Draft DNSSEC trust anchor witnesses February 2014
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.
There are some limitations and disadvantages:
o It does not disperse trust in the root zone signing key or root
zone maintenance.
o A lot more co-ordination between organizations is necessary, for
the witnesses to get out-of-band authentication of new trust
anchors.
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.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The WS resource record
The WS (witness signer) resource record contains a cryptographic
digest of a DNSKEY record at a DNSSEC trust anchor. WS records are
published separately from the trust anchor by trust anchor witnesses
to show that the witnesses vouch for the trust anchor DNSKEY(s). WS
records are used by validators to update their trust anchors.
The WS resource record RDATA has exactly the same wire format and
presentation format as the DS RR, as described in [RFC4034] section
5. Although WS has the same syntax as DS, its semantics differ as
described below.
The WS resource record type number is [TBD]
The WS RR is treated as a normal RR for signing, serving, resolving,
and validating. None of the special behaviour for DS records
described in [RFC4035] sections 2.4, 2.6, 3.1 applies to WS records.
Unlike DS records (where the DS record on the parent side of a zone
Finch Expires August 17, 2014 [Page 4]
Internet-Draft DNSSEC trust anchor witnesses February 2014
cut refers to a DNSKEY record on the child side of the zone cut at
the same name), WS records do not explicitly indicate the name of the
trust anchor DNSKEY records that they refer to. This information is
part of the valiator configuration (see Section 3.1).
WS records SHOULD be placed at the apex of a witness zone. They
SHOULD refer to DNSKEY records with the SEP (secure entry point) flag
set [RFC3757].
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.
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.
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.)
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.
When starting, a validator can find that its existing trust anchor
does not work, perhaps because a key rollover happened while it was
Finch Expires August 17, 2014 [Page 5]
Internet-Draft DNSSEC trust anchor witnesses February 2014
offline. In this situation it cannot serve clients until the update
process completes successfully.
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.
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).
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.
Finch Expires August 17, 2014 [Page 6]
Internet-Draft DNSSEC trust anchor witnesses February 2014
A WS RR can be trusted when this count reaches the required quorum.
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.
The timing of trust anchor rollovers is the same as for KSK rollovers
[RFC6781], except that instead of updating parental DS records,
withess WS records must be updated.
4.1. Contents of a witness zone
o A SOA record.
o NS records and name server address records. The name server names
SHOULD be in the witness zone. (Section 5.1 below explains this
requirement.)
o A DNSKEY RRset. This SHALL contain exactly one record with the
SEP flag set, corresponding to the witness trust anchor. The
DNSKEY RRset SHALL be signed by this key. As usual, the DNSKEY
RRset SHOULD contain other keys which are used as zone-signing
keys.
o A WS RRset. There MAY be multiple WS records to allow for
multiple digest types and/or multiple trust anchor keys.
o Other DNSSEC RRs necessary for a signed zone.
o There MAY be other records to provide information about this
witness zone. There SHOULD NOT be any records unrelated to
witness operations, such as delegations.
Finch Expires August 17, 2014 [Page 7]
Internet-Draft DNSSEC trust anchor witnesses February 2014
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.
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.
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
Finch Expires August 17, 2014 [Page 8]
Internet-Draft DNSSEC trust anchor witnesses February 2014
trust anchor.
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.
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.
Since the referral from root-witnesses.arpa is to a zone for which
the validating resolver has a trust anchor, it does not need to
validate the delegation chain through the witness zone's parents.
Depending on its validation strategy, a bootstrapping validator might
need special logic to avoid validaing this delegation chain or to
ignore validation failures in it, in particular when its root trust
anchor is stale.
5.2. Root trust anchor witness organizations
In order to populate the root-witnesses.arpa zone, IANA has to select
a number of root witness organizations who will receive delegations
from this zone.
These might be selected from TLD operators, root server operators,
registry service providers, accredited registrars, and others who
have an interest in the security and robustness of the DNS.
6. Security Considerations
This memo aims to improve the security and robustness of the DNS.
There are security-related requirements and recommendations
throughout.
Finch Expires August 17, 2014 [Page 9]
Internet-Draft DNSSEC trust anchor witnesses February 2014
7. IANA Considerations
A DNS RR type number is required for the WS RR.
This memo directs IANA to set up the root-witnesses.arpa zone and
manage ongoing liaison with the root trust anchor witnesses.
8. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, April 2004.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
December 2012.
Appendix A. Questions
Should this this scheme be extended to be more like DLV? That is,
witness zones could vouch for any trust anchors. Validators would
look up WS records by concatenating the name of the automatically
updated trust anchor name and the witness zone name. There would be
an implicit many-to-many relationship between witnesses and
automatically updated trust anchors, instead of an explicit many-to-
one relationship.
Finch Expires August 17, 2014 [Page 10]
Internet-Draft DNSSEC trust anchor witnesses February 2014
Author's Address
Tony Finch
University of Cambridge Computing Service
Roger Needham Building
7 JJ Thomson Avenue
Cambridge CB3 0RB
ENGLAND
Phone: +44 797 040 1426
Email: dot@dotat.at
URI: http://dotat.at/
Finch Expires August 17, 2014 [Page 11]
