One document matched: draft-wijngaards-dnsext-trust-history-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="yes"?>
<rfc ipr="full3978" category="std" docName="draft-wijngaards-dnsext-trust-history-01">
<front>
<title abbrev="Trust History Service"> DNSSEC Trust Anchor History Service </title>

        <author fullname="Wouter Wijngaards" initials="W.C.A." surname="Wijngaards">
                <organization> NLnet Labs </organization>
                <address>
                        <postal>
                                <street>Kruislaan 419</street>
                                <code>1098 VA</code>
                                <city>Amsterdam</city>
                                <country>The Netherlands</country>
                        </postal>
                        <phone>+31-20-888-4551</phone>
                        <facsimile>+31-20-888-4462</facsimile>
                        <email> wouter@nlnetlabs.nl </email>
                </address>
        </author>

<date month="October" year="2007"/>
<area> Internet Area </area>
<workgroup> DNS Extensions Working Group </workgroup>
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
<keyword>DNSKEY</keyword>
<keyword>history</keyword>
<keyword>rollover</keyword>
<keyword>trust anchor</keyword>
<keyword>KEYHIST_SIG</keyword>
<keyword>KEYHIST_CHAIN</keyword>
<keyword>KEYHIST_LOC</keyword>
<abstract><t>
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.
</t></abstract>

<note title="Requirements Language">
<t>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  <xref target="RFC2119">RFC 2119</xref>.</t>
</note>

</front>
<middle>

<section title="Introduction">
<t>
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.
</t><t>
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 <xref target="prime"/>. 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. 
</t><t>
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. 
</t>
</section>

<section title="Theory of Operation">
<t>
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.
</t>

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

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

<t>
To be able to request and serve historical DNSKEY RRSets, new RR Types are 
added, KEYHIST_LOC, KEYHIST_CHAIN and KEYHIST_SIG.
</t>

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

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

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

</section>

<section title="Key History Resource Record Types">
<section title="The KEYHIST_LOC RRType">
<t>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. </t>
<t>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). </t>

<section title="Wire Format">
<t><figure title=""><preamble></preamble><artwork>
                     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)             /   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork><postamble></postamble></figure></t>
<t>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 is present, forming a cyclic linked list.
All domain names are stored in uncompressed format. </t>
</section> <!-- wireformat -->
<section title="Presentation Format">
<t><figure title=""><preamble></preamble><artwork>
<owner> <ttl> <class> KEYHIST_LOC <flags> <prev_domain> 
        <next_domain> <more_domain>
</artwork><postamble></postamble></figure></t>
<t>
<list style="hanging">
<t hangText="flags:">
unsigned integer octet representing flags. Bit 0 means 'no next record'.
Bit 1 means 'no previous record'. Bit 7 means 'priming keys'. 
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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. 
</t>
</list>
</t>
</section> <!-- pres format -->
</section> <!-- KEYHIST_LOC -->

<section title="The KEYHIST_CHAIN RRType">
<t>The KEYHIST_CHAIN RR type has type code (TBD) (decimal). It is class
independent. </t>
<t>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.
</t>

<section title="Wire Format">
<t><figure title=""><preamble></preamble><artwork>
                     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 ...            /   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork><postamble></postamble></figure></t>
<t>
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.
</t>
</section> <!-- wireformat -->
<section title="Presentation Format">
<t><figure title=""><preamble></preamble><artwork>
<owner> <ttl> <class> KEYHIST_CHAIN <flags> <algo> 
        <hash_length> <num_keys> <prev_hash> <this_hash> 
        <next_hash> <timestamp> <key_ids>...
</artwork><postamble></postamble></figure></t>
<t>
<list style="hanging">
<t hangText="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.
</t>
<t hangText="algo:">
Hash algorithm used. Unsigned integer presentation format, one octet. 
Same list of values as the DS record.
</t>
<t hangText="hash_length:">
This field is presented as an unsigned integer.
</t>
<t hangText="num_keys:">
The number of DNSKEYs in the DNSKEY RRset covered by this_hash. Unsigned 
integer, one octet.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="next_hash:">
Encoded like prev_hash. Hash over the next DNSKEY RRset. If there is no
next DNSKEY RRset, it is not present.
</t>
<t hangText="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 <xref target="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.
</t>
<t hangText="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.
</t>
</list> </t>
</section> <!-- presformat -->
</section> <!-- KEYHIST_CHAIN -->
<section title="The KEYHIST_SIG RRType">
<t>
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.
</t><t>
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.
</t><t>
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.
</t>
</section> <!-- KEYHIST_SIG -->
</section> <!-- Key History RRs -->
<section title="Processing">
<section title="Rollover of Stale Trust Anchors">
<t><list style='numbers'>
<t> 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 rollover algorithm MUST end up at this DNSKEY RRset.
If any or all of these checks fail the rollover fails.
</t>
<t> 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.
</t>
<t> The validator checks the gathered types, as described in 
<xref target="nodecheck"/>.  If checks fail, the rollover fails.
</t>
<t> 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.
</t>
<t> Fetch the history RRs from the data domains. Check them as described in 
<xref target="nodecheck"/>.
</t>
<t> 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.
</t>
<t> 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.
</t>
<t> The validator continues to an older DNSKEY RRset, go to step 4.
</t>
</list></t>
</section> <!-- stale anchor rollover -->
<section title="Validator Check of History Node" anchor="nodecheck">
<t>
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.
</t><t>
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.
</t><t>
The hashvalues prev_hash and next_hash MUST also be correct. The 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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
The timestamp MUST be smaller (using serial arithmatic 
<xref target="RFC1982" />) than the timestamp from the last seen newer node.
</t>
</section> <!-- nodecheck -->
</section> <!-- processing -->

<section title="Signer Considerations">
<t>
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.
</t><t>
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.
</t>
</section>

<section title="Example" anchor="histexample">
<t>
To illustrate the use of history, an example zone is listed below. The
zone name is example.com. and it has several history points.
</t>
<t>
<figure>
<preamble></preamble><artwork>; 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;
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;
; 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
</artwork><postamble></postamble>
</figure>
</t>
<t>
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.
</t><t>
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 can be
left out without affecting the draft-timers based key rollover.
</t><t>
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.
</t><t>
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. 
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t>
</section>
<section title="Priming Keys" anchor="prime">
<t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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.
</t><t>
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. 
</t><t>
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.
</t>
</section>

<section anchor="Security" title="Security Considerations">
<t>
If the attacker does not crack current keys, or spoof the initial queries, 
the trust roll over will end at the current SEP keys.
</t><t>
The situation where the attacker cracks current keys is not considered
further. There is no security using key history service in that case.
</t><t>
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.
</t><t>
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.
</t><t>
If operators feel that their zone needs additional security against this
threat, they can use the priming keys option, described in 
<xref target="prime"/>.
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.
</t><t>
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.
</t><t>
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.
</t><t>
The priming keys algorithm does not use time periods, and the final 
keyset is trusted immediately.
</t>

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

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

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

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

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

</section>

<section anchor="IANA" title="IANA Considerations">
<t>
New Resource Record type codes for KEYHIST_LOC, KEYHIST_CHAIN and KEYHIST_SIG.
</t>
</section>

</middle>

<back>
        <references title="Normative References">
                <?rfc include="reference.RFC.1982" ?>
                <?rfc include="reference.RFC.2119" ?>
                <?rfc include="reference.RFC.4034" ?>
        </references>
</back>
</rfc>