One document matched: draft-wijngaards-dnsext-trust-history-01.txt
Differences from draft-wijngaards-dnsext-trust-history-00.txt
DNS Extensions Working Group W. Wijngaards
Internet-Draft NLnet Labs
Intended status: Standards Track October 10, 2007
Expires: April 12, 2008
DNSSEC Trust Anchor History Service
draft-wijngaards-dnsext-trust-history-01
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
When DNS validators have trusted keys, but have been offline for a
longer period, key rollover will fail and they are stuck with stale
trust anchors. History service allows validators to query for older
DNSKEY RRsets and pick up the rollover trail where they left off.
The service can be made to withstand multiple key compromises and
large-scale spoofing.
Wijngaards Expires April 12, 2008 [Page 1]
Internet-Draft Trust History Service October 2007
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3
3. Key History Resource Record Types . . . . . . . . . . . . . . 4
3.1. The KEYHIST_LOC RRType . . . . . . . . . . . . . . . . . . 4
3.1.1. Wire Format . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Presentation Format . . . . . . . . . . . . . . . . . 5
3.2. The KEYHIST_CHAIN RRType . . . . . . . . . . . . . . . . . 5
3.2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Presentation Format . . . . . . . . . . . . . . . . . 6
3.3. The KEYHIST_SIG RRType . . . . . . . . . . . . . . . . . . 7
4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Rollover of Stale Trust Anchors . . . . . . . . . . . . . 7
4.2. Validator Check of History Node . . . . . . . . . . . . . 8
5. Signer Considerations . . . . . . . . . . . . . . . . . . . . 10
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Priming Keys . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Wijngaards Expires April 12, 2008 [Page 2]
Internet-Draft Trust History Service October 2007
1. Introduction
When DNS validators have trusted keys, but have been offline for a
longer period, trusted key rollover will fail. A method is presented
to establish trust in current DNSKEYs. The method requires new RR
types to hold the historical information, and requires implementation
of the algorithm by the zone signer and validator. Zone operators
and validators can deploy the method independently and incrementally.
The stale trust anchor rollover is vulnerable to a single key
compromise coupled with a server take-over. A more secure rollover
method can be selected by the zone owner. This more secure priming
(with the prime bit set) rollover is described in Section 7. The
priming rollover method can resist N-1 key compromises, with N the
number of keys in the trusted priming key set held by the validator.
For priming keys, which are retrieved using many small queries, key
size is limited by the size that will fit in one packet. The number
of keys can be up to 255. A zone operator can choose the keysize and
number of keys.
2. Theory of Operation
The basic mode of operation for the trust anchor history is to
present a playback of historical states of the DNSKEY RRSet to the
validator. The validator can then roll-forward the trust anchor
using its trust anchor rollover algorithm. It is assumed [draft-
timers] is used to rollover, however, if it fails with stale trust
anchors the mechanism from this draft can be used to freshen the
trust anchors. If the prime bit is used, as described later, [draft-
timers] does not have to be in use.
The validator that requests history replay starts by requesting the
DNSKEY RRSet as is currently present for the trust point. The
validator then requests the previous RRSet, which comes signed and
dated with a timestamp. The validator continues to request previous
RRSets until it finds one that is signed by a key it trusts, or the
server indicates no more are available. The validator can then
reconstruct the key rollover from the past timepoints to the current
keyset at the trust point.
The validator does not have to cache all of the zone history, it can
use queries to walk forwards and backwards through the list of
keysets.
To be able to request and serve historical DNSKEY RRSets, new RR
Types are added, KEYHIST_LOC, KEYHIST_CHAIN and KEYHIST_SIG.
Wijngaards Expires April 12, 2008 [Page 3]
Internet-Draft Trust History Service October 2007
The KEYHIST_LOC RR is used to locate the historical information. The
historical information can be spread out over a number of domains, so
that packet size can stay small. The validator queries each of these
domains, and assembles the final set of DNSKEY, KEYHIST_SIG and
KEYHIST_CHAIN RRs together. In this way the zone operator can use
very large key sizes, while keeping packets within acceptable limits.
The DNSKEY RRs hold the keys. The KEYHIST_CHAIN RR holds hashes of
DNSKEY RRsets, and is signed. It securely links together the
historical information.
The KEYHIST_SIG RR is the same format as an RRSIG, but the signature
is historical. The signature it holds can be expired, but valid in
the past. It is used to sign the DNSKEY and KEYHIST_CHAIN types.
The time at which the KEYHIST_SIGs are valid is stored in the
KEYHIST_CHAIN type.
3. Key History Resource Record Types
3.1. The KEYHIST_LOC RRType
The KEYHIST_LOC RR type has type code (TBD) (decimal). It is class
independent. History RR types pertaining to DNSKEYs MUST be of the
same class as those DNSKEYs.
This RR Type is used to find the historical information that is
stored in the DNS. It is signed with the regular zone signing
key(s).
3.1.1. Wire Format
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|P|MBZ flags|I| Previous moment (dname) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next moment (dname) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ more history storage (dname) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the N or P flag (Bit 0, 1) is set, then the Next or Previous
moment field is not present. Other flag fields MUST be set to zero,
validators MUST ignore KEYHIST_LOC RRs with these flags set. Bit 7
(I) is the prime flag, denoting that the validator needs to have a
priming key set to use this set of history data. The more history
storage dname is always present. At this domain another KEYHIST_LOC
Wijngaards Expires April 12, 2008 [Page 4]
Internet-Draft Trust History Service October 2007
is present, forming a cyclic linked list. All domain names are
stored in uncompressed format.
3.1.2. Presentation Format
<owner> <ttl> <class> KEYHIST_LOC <flags> <prev_domain>
<next_domain> <more_domain>
flags: unsigned integer octet representing flags. Bit 0 means 'no
next record'. Bit 1 means 'no previous record'. Bit 7 means
'priming keys'.
prev_domain: The domain name where a KEYHIST_LOC older than this set
of information can be found. Stored as an uncompressed domain
name. Not presented if the 'no previous record' flag is set.
next_domain: The domain name where a KEYHIST_LOC newer than this
information can be found. Stored as an uncompressed domain name.
Not presented if the 'no next record' flag is set.
more_domain: A domain name where another KEYHIST_LOC is present.
And also more historical data is present at that point. The
KEYHIST_LOCs form a cyclic linked list with the more_domains
pointing to another. The prev and next moment of all the
KEYHIST_LOCs in the same more_domain list are all the same. This
is where the historical information can be found. At these
domains the RR Types KEYHIST_CHAIN, KEYHIST_SIG and DNSKEY can be
found. Stored as uncompressed domain name.
3.2. The KEYHIST_CHAIN RRType
The KEYHIST_CHAIN RR type has type code (TBD) (decimal). It is class
independent.
This RR Type is used to sign hashes of historical DNSKEY RRsets. It
MAY be signed with the regular zone signing keys as well, but MUST be
signed with KEYHIST_SIG signatures by all keys in the DNSKEY RRset
covered by this_hash. The DNSKEY keys and KEYHIST_SIG signatures are
spread out over the list of domains from the KEYHIST_LOC type.
3.2.1. Wire Format
Wijngaards Expires April 12, 2008 [Page 5]
Internet-Draft Trust History Service October 2007
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|P|MBZ Flags|I| Hash algo. | Hash length | number of keys|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous hash data octets /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| This hash data octects /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next hash data octets /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | first key_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key_id ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If bit 0 or 1 (Next or Previous omitted) is set, the previous hash or
the next hash field is omitted. The this_hash field is always
present. The hash length is in octets. The hashes use the same
algorithm, and so have the same length, if they are present. The
hash length depends on the hash algorithm. The MBZ flags MUST be set
to zero. Validators MUST ignore RRs with these flags set. The I
field, bit 7, is the priming keys flag, denoting that all keys MUST
match the known trusted keys by the validator, for the validator to
consider trusting this KEYHIST_CHAIN and ending rollover.
3.2.2. Presentation Format
<owner> <ttl> <class> KEYHIST_CHAIN <flags> <algo>
<hash_length> <num_keys> <prev_hash> <this_hash>
<next_hash> <timestamp> <key_ids>...
flags: Presented as unsigned integer. Bit 7 means 'priming keys'.
Bits 0 and 1 are set if there are no next or previous historical
rrsets. The hashes are then ommitted from presentation.
algo: Hash algorithm used. Unsigned integer presentation format,
one octet. Same list of values as the DS record.
hash_length: This field is presented as an unsigned integer.
num_keys: The number of DNSKEYs in the DNSKEY RRset covered by
this_hash. Unsigned integer, one octet.
prev_hash: The hashes are presented by a sequence of hexadecimal
characters. The field is ommitted if not present. The prev_hash
is the hash algorithm applied to the DNSKEY RRset before this one,
the owner names of the DNSKEY RRset are set to the zone apex when
taking the hash and signatures (exactly as the DNSKEY RRset was
when it was in use). If there is no previous DNSKEY RRset it is
not present.
Wijngaards Expires April 12, 2008 [Page 6]
Internet-Draft Trust History Service October 2007
this_hash: Encoded like prev_hash. Hash over the DNSKEY RRset as
found when querying all data_domains from the KEYHIST_LOC RR,
taken together, with owner name equal to the zone apex.
next_hash: Encoded like prev_hash. Hash over the next DNSKEY RRset.
If there is no next DNSKEY RRset, it is not present.
timestamp: The timestamp is presented the same as the RRSIG
timestamps. Either as an unsigned decimal integer indicating
seconds since 1 January 1970 00:00:00 UTC, or in the form
YYYYMMDDHHmmSS in UTC [RFC4034]. This is the time at which this
DNSKEY RRset is valid. The KEYHIST_SIGs over the DNSKEY and
KEYHIST_CHAIN RRsets MUST be valid at this time. The timestamp
can be used by the validator to index storage of historical
(priming) keys, grouping keys from the same timestamp together.
key_ids: The Key ID of every DNSKEY RR key is given, in ascending
order as unsigned 16-bit numbers. If there are keys in the RRset
with the same ID, that ID is stated twice. This is the same ID as
stored in RRSIGs. These ids are present to assist validator
lookups, so that the validator can check number and IDs of keys
that were fetched before attempting validation.
3.3. The KEYHIST_SIG RRType
This RRtype has type code (TBD) (decimal). The presentation and
wireformat of the rdata is the same as for the RRSIG type. It is
used to sign the DNSKEY and KEYHIST_CHAIN types. It is different
from RRSIG in that the signature may be expired, but was valid at the
time in the timestamp from the KEYHIST_CHAIN.
Another difference with RRSIGs is that KEYHIST_SIG does not require
special processing. It is queried for directly. KEYHIST_SIG
signatures may be stored at a different node than the RRset they
sign. The KEYHIST_LOC type provides the location of the historical
RRsets and signatures.
Both historical DNSKEY and historical KEYHIST_CHAIN types require
that the owner name be set to the zone apex name of the zone for
which trust anchors are sought, before the KEYHIST_SIG signature is
validated.
4. Processing
4.1. Rollover of Stale Trust Anchors
1. The first step is a query that looks exactly like a regular
rollover query. This query is for the zone DNSKEY RRset. It
MUST be exactly like a regular rollover, so that an attacker
finds it hard to distinguish clients with stale keys from regular
clients. The results from this query MUST be stored. The
Wijngaards Expires April 12, 2008 [Page 7]
Internet-Draft Trust History Service October 2007
rollover algorithm MUST end up at this DNSKEY RRset. If any or
all of these checks fail the rollover fails.
2. The validator then looks for history service. Query for
KEYHIST_LOC at the zone apex. If no history is available, the
rollover fails. If history is available, the KEYHIST_LOC type
will point to the data domains where the KEYHIST_CHAIN, DNSKEY
and KEYHIST_SIG RRs for the DNSKEY rrset that is currently in use
can be found. The validator MUST fetch these. The DNSKEYs found
MUST equal the SEP keys from the set found in step 1.
3. The validator checks the gathered types, as described in
Section 4.2. If checks fail, the rollover fails.
4. The validator fetches the KEYHIST_LOC type from the domain name
listed in the prev_domain field. This can lead to a subzone of
the original zone. In that case the delegation MUST be signed
(with valid DS) by the keys from step 1. This KEYHIST_LOC type
MUST be signed by one of the zone keys from step 1. The
validator checks that the data names are below the zone apex, and
that the delegation (if any) is secure.
5. Fetch the history RRs from the data domains. Check them as
described in Section 4.2.
6. If this RRset contains trusted keys, then the rollover is done.
The trust anchor state can be brought into correct state by
performing key rollover at the timepoints from KEYHIST_CHAIN.
This rollover MUST end in the keyset from step 1. The most
recent history keyset can be stored with timestamp on stable
storage to allow for future rollovers.
7. Because of DNS timing issues, the trust keys held by a validator
may not be exactly one DNSKEY RRset from the history. In that
case some of the trusted keys can be found in older DNSKEY
RRsets. This cannot happen if the prime bit is set.
8. The validator continues to an older DNSKEY RRset, go to step 4.
4.2. Validator Check of History Node
This section describes the checks needed to validate a history node.
First the necessary information MUST be queried from the more data
domains listed in the KEYHIST_LOC type. Also the owner name of the
KEYHIST_LOC RR MUST be queried for historical data. Note that the
last KEYHIST_LOC more_domain points back to the first, and all have
the same priming flag, previous and next values.
The hashvalue of the DNSKEY RRset at this node, with the owner names
replaced by the zone apex (of the zone that is rolled over) MUST
match the this_hash value. The reason to replace the owner name
before hashing is so that the history data may be moved after
creation without needing the old key private data.
The hashvalues prev_hash and next_hash MUST also be correct. The
Wijngaards Expires April 12, 2008 [Page 8]
Internet-Draft Trust History Service October 2007
next_hash value MUST be NULL if the KEYHIST_LOC has been retrieved
from the rollover zone apex domain name. The prev_hash value is only
NULL if no more history is available. The prev_hash value MUST be
equal to the hash of the DNSKEY RRset from the previous history node.
The next_hash value MUST be equal to the hash of the DNSKEY RRset
from the next history node.
Since the validator algorithm specifies to walk the history from new
to old, the hash checking is as follows. The this_hash is checked
for the current node. The last seen node's prev_hash value MUST
equal the hash of the DNSKEYs found in the current node. The
next_hash value for this node MUST equal the hash of the DNSKEYs from
the last seen node.
The KEYHIST_SIG, RRSIG, DNSKEY and KEYHIST_CHAIN RRs can have
different algorithm values for signatures and hashing. This allows
the zone operator to switch algorithms. To check a hash in a
KEYHIST_CHAIN the hash algorithm from that RR is used.
The number of DNSKEYs in the KEYHIST_CHAIN, and the key ids in the
KEYHIST_CHAIN MUST be correct. With many keys, an 16 bit ids, it is
likely to have keys with the same id, that id is then listed multiple
times in the KEYHIST_CHAIN.
The KEYHIST_SIG over the KEYHIST_CHAIN MUST validate. Validation is
performed at the time from the timestamp in the KEYHIST_CHAIN. All
keys in the DNSKEY RRset MUST sign the KEYHIST_CHAIN in this way.
This signs the timestamp, and hashes of the current, previous and
next DNSKEY RRsets.
The KEYHIST_SIG over the DNSKEY MUST validate. Validation is
performed at the time from the timestamp in the KEYHIST_CHAIN. All
keys in the DNSKEY RRset MUST sign the DNSKEY RRset in this way.
Keys MUST NOT be used for signatures over the DNSKEY set and the
KEYHIST_CHAIN RR, using KEYHIST_SIG entries in the history chain,
when they have previously been revoked. Keys are revoked via a self-
signed revocation signature. The revocation flag in DNSKEY is
discussed in [draft-timers]. To check that this does not happen, the
validator MUST keep track of the keys that have been used to sign
keysets in the future, which means it has seen them already since it
queries from future to past. If a revocation of a key is seen which
is also used for signatures at a future moment, then the rollover
fails.
The timestamp MUST be smaller (using serial arithmatic [RFC1982])
than the timestamp from the last seen newer node.
Wijngaards Expires April 12, 2008 [Page 9]
Internet-Draft Trust History Service October 2007
5. Signer Considerations
The zone, or a signed subzone, is used to store history snapshots.
New snapshots are added to the history whenever the key-signing
keyset for the zone changes. The operator MAY opt to make snapshots
at different times, but these snapshots MUST allow for orderly
rollover by a validator. So the operator can omit intermediate or
emergency recovery zone states from the history list. A change of
ZSK keys does not trigger a new history snapshot, because the KSKs
sign the new ZSK.
The zone operator is to provide a key history to the server, produced
by a signer. The RR formats are such that private key data for old
keys can be discarded, only the current and the previous set of keys
are needed. The data can be treated as unknown RR types by servers,
caches and intermediate resolvers. The zone operator may opt to move
the history data after it has been created, since it is not the
location but content that verifies the keys. The data may be moved
without needing private key data, since the KEYHIST_LOC type is
signed using the current zone signing keys. Also, the owner name of
DNSKEY and KEYHIST_CHAIN types is changed to the rollover zone apex
name before hashing or verifying signatures. The zone operator may
move history service to a signed subzone of the zone, to move key
history query load to other authoritative servers. The history store
is stored at domain names chosen by the operator, for example
numbered sequentially, or by date. The data may be divided onto many
domains to make packet sizes smaller. The signer SHOULD provide an
option to set a maximum history reply size that is acceptable so that
it can divide the data over multiple domains as needed. The signer
produces normal zone signing RRSIGs as well as KEYHIST_SIGs as needed
for historical data storage points.
6. Example
To illustrate the use of history, an example zone is listed below.
The zone name is example.com. and it has several history points.
; example.com. zone apex
example.com. SOA ns.example.com. hostmaster.example.com. (
2007100701 7200 3600 604800 86400)
example.com. RRSIG SOA by ZSK;
example.com. NS ns.example.com.
example.com. RRSIG NS by ZSK;
example.com. DNSKEY ZSK; id=1
example.com. DNSKEY KSK; id=101
example.com. DNSKEY KSK; id=102
example.com. RRSIG DNSKEY by ZSK;
example.com. RRSIG DNSKEY by KSK 101;
Wijngaards Expires April 12, 2008 [Page 10]
Internet-Draft Trust History Service October 2007
example.com. RRSIG DNSKEY by KSK 102;
; this RR provides location of more history information.
example.com. KEYHIST_LOC 128 (
hist200709.example.com. hist200710.example.com. )
example.com. RRSIG KEYHIST_LOC by ZSK;
; the nameserver address
ns.example.com. A 192.0.2.10
; zone content.
www.example.com. AAAA 2001:DB8::10
; more history information for the zone apex (current keyset).
; The KEYHIST_LOC RR completes the more information chain
; for the zone apex by pointing back to the apex.
hist200710.example.com. KEYHIST_LOC 128 (
hist200709.example.com. example.com. )
hist200710.example.com. RRSIG KEYHIST_LOC by ZSK;
; The KEYCHAIN RR, the hash_ words would be actual hexadecimal
; data in practice. Lists the current KSKs: 101 and 102.
hist200710.example.com. KEYHIST_CHAIN 128 5 20 2 (
hash_prev_hex hash_101_102_hex 20071007000000 101 102 )
; Signatures valid at the snapshot time above.
hist200710.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 101;
hist200710.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 102;
; signatures over the DNSKEY set comprised of key 101 and 102.
hist200710.example.com. KEYHIST_SIG DNSKEY by key 101;
hist200710.example.com. KEYHIST_SIG DNSKEY by key 102;
; these signatures sign the KEYHIST_LOC and _CHAIN with
; ZSK to be backward compatible with software that does
; DNSSEC but not keyhistory. the server can continue to
; treat KEYHIST_ types as unknown RR types. These signatures
; are not needed during a historical key update.
hist200710.example.com. RRSIG KEYHIST_CHAIN by ZSK
hist200710.example.com. RRSIG KEYHIST_SIG by ZSK
; previous history moment. The operator has instructed the
; zone signer to divide this up into two domain names.
; One with the public key data, one with the _CHAIN data.
; The KEYHIST_* RRs can be distributed in any way; even splitting
; apart the KEYHIST_SIG and DNSKEY RRsets.
hist200709.example.com. KEYHIST_LOC 0 (
hist200708.example.com. hist200910.example.com.
hist200709_2.example.com.)
hist200709.example.com. RRSIG KEYHIST_LOC by ZSK;
hist200709.example.com. DNSKEY KSK; id = 102
hist200709.example.com. DNSKEY KSK; id = 103
hist200709.example.com. KEYHIST_SIG DNSKEY by key 102;
hist200709.example.com. KEYHIST_SIG DNSKEY by key 103;
Wijngaards Expires April 12, 2008 [Page 11]
Internet-Draft Trust History Service October 2007
; backwards compatibility RRSIGs.
hist200708.example.com. RRSIG DNSKEY by ZSK
hist200709.example.com. RRSIG KEYHIST_SIG by ZSK
; more data for 200709.
hist200709_2.example.com. KEYHIST_LOC 0 (
hist200708.example.com. hist200910.example.com.
hist200709.example.com.)
hist200709_2.example.com. RRSIG KEYHIST_LOC by ZSK
hist200709_2.example.com. KEYHIST_CHAIN 0 5 20 2 (
hash_prev_hex hash_102_103_hex hash_next_hex
20070907000000 102 103 )
; Signatures valid at the snapshot time above.
hist200709_2.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 102;
hist200709_2.example.com. KEYHIST_SIG over KEYHIST_CHAIN by key 103;
; backwards compatibility RRSIGs.
hist200709_2.example.com. RRSIG KEYHIST_SIG by ZSK
hist200709_2.example.com. RRSIG KEYHIST_CHAIN by ZSK
; 200708 is the oldest moment in the example history chain.
; the operator had the information put on one domain name
hist200708.example.com. KEYHIST_LOC 64 (
host200709.example.com. hist200708.example.com. )
hist200708.example.com. RRSIG KEYHIST_LOC by ZSK
hist200708.example.com. KEYHIST_CHAIN 64 5 20 2 (
hash_103_104_hex hash_next_hex
20070807000000 103 104 )
hist200708.example.com. DNSKEY KSK; id = 103
hist200708.example.com. DNSKEY KSK; id = 104
hist200708.example.com. KEYHIST_SIG DNSKEY by key 103;
hist200708.example.com. KEYHIST_SIG DNSKEY by key 104;
hist200708.example.com. KEYHIST_SIG KEYHIST_CHAIN by key 103;
hist200708.example.com. KEYHIST_SIG KEYHIST_CHAIN by key 104;
; backwards compatibility RRSIGs. These are not required for
; history rollover
hist200708.example.com. RRSIG DNSKEY by ZSK
hist200708.example.com. RRSIG KEYHIST_SIG by ZSK
hist200708.example.com. RRSIG KEYHIST_CHAIN by ZSK
The above zone would also need NSEC denial of existance information,
not shown in the example. The zone has three history moments, 200710
(that is linked from the zone apex and contains the current keys),
200709 and 200708. The KSK keys have been rolled from 104,103 to
103,102 to 102,101 at the current time.
The zone operator can choose to leave out some zone changes from the
history list. For example, if during change from keys 104,103 to
103,102 the zone briefly becomes signed only with key 103, this state
Wijngaards Expires April 12, 2008 [Page 12]
Internet-Draft Trust History Service October 2007
can be left out without affecting the draft-timers based key
rollover.
The zone operator may also insert extra history moments when the
valid zone keys do not change. This may not seem very useful, but
emergency key revocations can be inserted in this way, without
waiting for key rollover.
If an attacker compromises key 103, then this key is not in current
use, and cannot directly be used to sign data (draft-timers will have
removed the key from usage, and priming keys do not have ZSK bit set
in the validator). However, if a validator that trusts key 103 (and
has no more recent key) tries to perform history rollover, key 103
can be used to subvert rollover and insert a new key of attackers
choice. A single key compromise breaks security in this case.
For this reason the priming bit can be set. If in the above example
the prime bit were set, then the validator armed with both keys 103
and 104 (a full keyset from 200708), is not subverted using only key
103. If both keys 103 and 104 are compromised, then again, rollover
can be subverted. When the prime bit is set, compromise of all keys
breaks security.
When the zone operator learns of the compromise of key 103, he will
want to retract that key. He has discarded old private key
information, including that for key 103, but has kept a self-signed
keyset of key 103 with the REVOKE key flag. The operator can insert
the key 103 revocation DNSKEY and RRSIG in the zone. This change of
KSKs creates a new history moment, where keys 101 and 102 sign
everything and key 103 only its revocation. In this way key
revocations are also historically archived, so that later validators
that perform history rollover will encounter them.
The RRSIG over key 103 revocation has timestamps in the past. For
this reason, the signature can be stored in a KEYHIST_SIG RR type.
The outdated timestamps can be ignored; because a key revocation at
any time results in a revoked key. By including key 103 and its
KEYHIST_SIG not in the zone apex itself, but only in
hist200710.example.com, the key revocation can be included in the
history information for the zone apex without affecting older
validators; specifically since it is not part of the zone apex DNSKEY
keyset, it does not have to sign the zone apex DNSKEY keyset, which
the operator cannot do because the private key data for key 103 has
been discarded.
Wijngaards Expires April 12, 2008 [Page 13]
Internet-Draft Trust History Service October 2007
7. Priming Keys
Because the stale trust anchor rollover presented before can be
broken by an attacker obtaining the key material for one of the trust
keys, a more secure method is presented here. The zone owner can opt
to provide priming keys. These keys MUST NOT be kept up to date
using frequent polls. A validator only needs to rollover priming
keys when this becomes necessary.
Priming key sets MUST be stored by the validator with all keys from
the set. All the priming keys from that set MUST be used whenever
the set is used to sign or validate. The priming bit in the flags
field of KEYHIST_LOC and KEYHIST_CHAIN RRs found MUST be set, when
validating a priming key rollover.
The method for rollover is the same. However, rollover does not stop
when one trust key is detected, but when the set of DNSKEYs equals a
complete set of priming keys that the validator trusts, and all
signatures validate.
The effect is that instead of one trust anchor key, all priming keys
provide protection. Since no rollover algorithm intermediate states
are retrieved, the keys found in step 1 are set as trusted keys
without performing the rollover algorithm and the updated set of
priming keys is stored for later use, preferably on stable storage as
well.
Priming keys MUST have the SEP bit set, but SHOULD NOT have the ZSK
bit set. This makes priming keys unable to sign ordinary zone data.
It reduces the possible abuse of the priming keys.
The validator SHOULD update its keys if they are one year old, or
older. This reduces the chance that validators are stuck with
ancient keys when rollover fails. One year is suggested as default
value. The validator MUST randomly determine ancient key update time
so that the first updates start after a year, and one year later all
clients have updated. This avoids congestion when all clients update
ancient keys at the same time. If the priming keys are updated in
another manner in the meantime (e.g. using software update), then a
new update time has to be determined.
8. Security Considerations
If the attacker does not crack current keys, or spoof the initial
queries, the trust roll over will end at the current SEP keys.
The situation where the attacker cracks current keys is not
considered further. There is no security using key history service
Wijngaards Expires April 12, 2008 [Page 14]
Internet-Draft Trust History Service October 2007
in that case.
Assuming the attacker spoofs the initial queries, in addition the
attacker needs to have obtained the trusted keys that the validator
possesses. An additional obstacle presented to the attacker by
history service is that validators with stale trust anchors are not
distinguishable from validators with valid ones, when they query for
the current zone DNSKEY RRset. And further, the validator does not
reveal which trust anchor it is holding until it stops the query
process. An attacker needs other information (such as IP addresses)
to identify victims. Or the attacker provides false information to
validators with correct trust anchors. Those validators will flag
the information as bogus, and attract attention from the zone
operator, revealing the attack attempt.
In the case that the attacker has obtained the old trust anchor, can
spoof all of the queries, and is able to identify the victim or
willing to reveal the attack in progress, then the algorithm for
stale trust anchor rollover fails to be secure.
If operators feel that their zone needs additional security against
this threat, they can use the priming keys option, described in
Section 7. A validator can download a set of priming keys using a
valid trust anchor at any time, or get them via software updates.
The priming keys can be very large, and a large number. Priming keys
are only rolled over when trust anchors go stale. Priming keys are
always obtained in a full set and they MUST all verify the RRsets
together. This means an attacker needs to obtain the key material
for all of the priming keys, and spoof queries as for the above case,
to be able to subvert the rollover.
The validator can follow a signed delegation to a subzone to get
history information. The signature uses the untrusted current zone
keys. A spoofing attacker can redirect a validator in this way.
However, this simply amounts to more spoofing by the attacker. The
signatures and DS are validated to raise the bar on spoofing the
delegation.
The stale trust anchor rollover performs rollover of the trust anchor
according to [draft-timers]. However, the final state is then under
a hold-down timer of 30 days. This means no trust anchors may be
used for 30 days, which is not attractive for people who have been
offline for a long time (and need their software security updates
from a secure site). The KEYHIST_CHAIN self-signed timestamps MAY be
used to determine if the hold-down period has passed for some of the
keys from the final keyset, but this fails to provide real timing
security.
Wijngaards Expires April 12, 2008 [Page 15]
Internet-Draft Trust History Service October 2007
The priming keys algorithm does not use time periods, and the final
keyset is trusted immediately.
None of the historical key private material needs to be online for a
server to provide history service. They are only needed by the
signer, when the key is rolled over. Private key material may be
discarded for old keys.
Because the validator walks the history in reverse first, it will see
all revoked keys with the revocation bit on first. The validator
MUST NOT trust such keys for present-day validation. A validator may
choose to remove all stale trust anchors when the priming rollover
completes, removing the need for revocation determination.
Keys that have been revoked can be used to self-sign keysets at time
moments before their revocation. The older entries are unchanged,
partly to make it possible to discard old key private data. And
partly because the validator can handle these cases. Since the
validator walks the history backwards, it sees revocations first, and
can ignore signatures from revoked keys on older keysets in the
history chain. If all keys that a validator trusts are revoked,
then, although rollover fails, the validator has gained the
revocation knowledge and will not put false trust in these keys.
The KEYHIST_CHAIN requires second preimage resistance of the hash
function. The rollover after a year should make sure where possible
that keys with very old algorithms signed with KEYHIST_CHAIN RRs with
very old hash algorithms are not in use by clients.
The algorithm can be abused to provide a secure method to get (close
to) the current month or year. Validators without clock then know
the date that validates DNSKEY RRSIGs currently in use by the zone.
9. IANA Considerations
New Resource Record type codes for KEYHIST_LOC, KEYHIST_CHAIN and
KEYHIST_SIG.
10. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
Wijngaards Expires April 12, 2008 [Page 16]
Internet-Draft Trust History Service October 2007
RFC 4034, March 2005.
Author's Address
Wouter Wijngaards
NLnet Labs
Kruislaan 419
Amsterdam 1098 VA
The Netherlands
Phone: +31-20-888-4551
Fax: +31-20-888-4462
EMail: wouter@nlnetlabs.nl
Wijngaards Expires April 12, 2008 [Page 17]
Internet-Draft Trust History Service October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wijngaards Expires April 12, 2008 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 03:25:31 |