draft-ietf-dnsop-dnssec-trust-history-00.txt   draft-ietf-dnsop-dnssec-trust-history-01.txt 
Domain Name System Operations W. Wijngaards Domain Name System Operations W. Wijngaards
Internet-Draft O. Kolkman Internet-Draft O. Kolkman
Intended status: Standards Track NLnet Labs Intended status: Standards Track NLnet Labs
Expires: August 26, 2010 February 22, 2010 Expires: August 26, 2010 February 22, 2010
DNSSEC Trust Anchor History Service DNSSEC Trust Anchor History Service
draft-ietf-dnsop-dnssec-trust-history-00 draft-ietf-dnsop-dnssec-trust-history-01
Abstract Abstract
When DNS validators have trusted keys, but have been offline for a When DNS validators have trusted keys, but have been offline for a
longer period, key rollover will fail and they are stuck with stale longer period, key rollover will fail and they are stuck with stale
trust anchors. History service allows validators to query for older trust anchors. History service allows validators to query for older
DNSKEY RRsets and pick up the rollover trail where they left off. DNSKEY RRsets and pick up the rollover trail where they left off.
Requirements Language Requirements Language
skipping to change at page 2, line 38 skipping to change at page 2, line 38
not necessarily need to be published in the zone for which the DNSKEY not necessarily need to be published in the zone for which the DNSKEY
history is being maintained but can be published in any DNS domain. history is being maintained but can be published in any DNS domain.
We will call the entity that offers the trust history the History We will call the entity that offers the trust history the History
Provider. The choice of the History Provider is made by the Provider. The choice of the History Provider is made by the
maintainer of the validator, possibly based on a hint provided, using maintainer of the validator, possibly based on a hint provided, using
the TALINK, by the zone owner. the TALINK, by the zone owner.
The algorithm that the validator uses to construct a history and The algorithm that the validator uses to construct a history and
reconfigure a new key is detailed in Section 3. The algorithms for reconfigure a new key is detailed in Section 3. The algorithms for
how providers of trust history can fetch the DNSKEY data as published how providers of trust history can fetch the DNSKEY data as published
by the zone they track, and publish those in their own domain, are by the zone they track and publish that are explained in Section 4.
explained in Section 4.
2. The TALINK Resource Record 2. The TALINK Resource Record
The DNS Resource Record type TALINK (decimal TBD) ties the elements The DNS Resource Record type TALINK (decimal 58) ties the elements of
of a linked list of DNSKEY RRs together. a linked list of DNSKEY RRs together.
The rdata consists of two domain names. The first name is the start, The rdata consists of two domain names. The first name is the start,
or previous name, and the other name the end or next name in the or previous name, and the other name the end or next name in the
list. The empty label '.' is used at the endpoints of the list. list. The empty label '.' is used at the endpoints of the list.
The presentation format is the two domain names. The wire encoding The presentation format is the two domain names. The wire encoding
is the two domain names, with no compression so the type can be is the two domain names, with no compression so the type can be
treated according to [RFC3597]. The list is a double linked list, treated according to [RFC3597]. The list is a double linked list,
because this empowers low memory hosts to perform consistency checks. because this empowers low memory hosts to perform consistency checks.
3. Trust History Lookup 3. Trust History Lookup
This is the algorithm that a validator uses to detect and resolve the This is the algorithm that a validator uses to detect and resolve the
situation in which a trust-anchor is out of sync with the DNSKEYs situation in which a trust-anchor is out of sync with the DNSKEYs
published by a zone owner. The algorithm uses the TALINK RR type published by a zone owner. The algorithm uses the TALINK RR type
which is used to link various old DNSKEYs as published by the History which is used to link various old DNSKEYs as published by the History
Provider, to arive from the outdated configured Trust Anchor to one Provider, to arrive from the outdated configured Trust Anchor to one
that matches the current DNSKEY. The TALINK RR type is defined in that matches the current DNSKEY. The TALINK RR type is defined in
Section 2. Section 2.
When the algorithm below results in failure the trust history cannot When the algorithm below results in failure the trust history cannot
be build and a new trust anchor will need to be re-configured using be build and a new trust anchor will need to be re-configured using
another mechanism. another mechanism.
Step 1: The validator performs a DNSKEY lookup to the target zone, Step 1: The validator performs a DNSKEY lookup to the target zone,
which looks like any other initial DNSKEY lookup that the which looks like any other initial DNSKEY lookup that the
validator needs to match a trust anchor to the currently used validator needs to match a trust anchor to the currently used
DNSKEY RR set. If the keyset verifies with the trust anchor DNSKEY RR set. If the keyset verifies with the trust anchor
currently held, the trust-anchor is not out-of sync. Otherwise, currently held, the trust-anchor is not out of sync. Otherwise,
store the DNSKEY RR set as result. The algorithm will succesfully store the DNSKEY RR set as result. The algorithm will
build a linked list to this DNSKEY RR or fail. successfully build a linked list to this DNSKEY RR, or delete the
trust point, or fail.
All nameservers (the ones authoritative for the zone or the All nameservers (the ones authoritative for the zone or the
upstream resolver caches when the validator is not full resolver) upstream resolver caches when the validator is not full resolver)
SHOULD be checked to make sure the DNSKEY RR sets are the same. SHOULD be checked to make sure the DNSKEY RR sets are the same.
The results can differ if a key-rollover is in progress and not The results can differ if a key-rollover is in progress and not
all nameservers are in sync yet. This case can be detected by all nameservers are in sync yet. This case can be detected by
checking that the older keyset signs the newer and take the newer checking that the older keyset signs the newer and take the newer
as result keyset. The keysets are distinguished by the average as result keyset. The keysets are distinguished by the average
over the middle of the inception and expiration dates of the over the middle of the inception and expiration dates of the
signatures that are validated by the keyset itself. Otherwise, signatures that are validated by the keyset itself. Otherwise,
the lookup fails. If the check fails then the inconsistency may the history lookup fails. If the check fails then the
be the result of spoofing, or compromise of (DNS) infrastructure inconsistency may be the result of spoofing, or compromise of
elements. (DNS) infrastructure elements.
Step 2: Fetch the trust history list end points. Perform a query of Step 2: Fetch the trust history list end points. Perform a query of
QTYPE=TALINK and QNAME being the domain name that is configured to QTYPE TALINK and QNAME the domain name that is configured to be
be the History Provider for the particular domain you are trying the History Provider for the particular domain you are trying to
to update the trust-anchor for. update the trust-anchor for.
Step 3: Go backwards through the trust history list as provided by Step 3: Go backwards through the trust history list as provided by
the TALINK linked list. Verify that the keyset validly signs the the TALINK linked list. Verify that the keyset validly signs the
next keyset. This is [RFC4034] validation, but the RRSIG next keyset. This is [RFC4034] validation, but the RRSIG
expiration date is ignored. [Editor note: Are we shure that there expiration date is ignored. [Editor note: Are we shure that there
are no server implementations that will not serve expired RRSIG, are no server implementations that will not serve expired RRSIG,
are such 'smart' servers allowed by the specs? In other words do are such 'smart' servers allowed by the specs? In other words do
we need clarification in the DNSSEC-updates document?] Replace we need clarification in the DNSSEC-updates document?] Replace
the owner domain name with the target zone name for verification. the owner domain name with the target zone name for verification.
One of the keys that signs the next keyset MUST have the SEP bit One of the keys that signs the next keyset MUST have the SEP bit
set. The middle of inception and expiration date from the valid set. The middle of inception and expiration date from the valid
signature MUST be older than the signature checked last time. signature MUST be older than that of the signature that validates
Query type TALINK to get previous and next locations. the next keys in the list. Query type TALINK to get previous and
next locations.
If all SEP keys have the REVOKE flag set at this step, and the If all SEP keys have the REVOKE flag set at this step, and the
keyset is signed by all SEP keys, then continue but store that the keyset is signed by all SEP keys, then continue but store that the
end result is that the trust point is deleted, see Section 5 end result is that the trust point is deleted, see Section 5
[RFC5011]. [RFC5011].
If all SEP keys are of an unknown algorithm at this step, continue If all SEP keys are of an unknown algorithm at this step, continue
and at the next step, when you verify if the keyset signs validly: and at the next step, when you verify if the keyset signs validly:
if false, continue with result a failure, if true, continue with if false, continue with result a failure, if true, continue with
the end result that the trust point is deleted. Thus, the keysets the end result that the trust point is deleted. Thus, the keysets
skipping to change at page 4, line 39 skipping to change at page 4, line 40
store the result on stable storage. Use the new trust anchor for store the result on stable storage. Use the new trust anchor for
validation (if using [RFC5011], put it in state VALID). validation (if using [RFC5011], put it in state VALID).
4. Trust History Tracker 4. Trust History Tracker
External trackers can poll the target zone DNSKEY RRset regularly. External trackers can poll the target zone DNSKEY RRset regularly.
Ignore date changes in the RRSIG. Ignore changes to keys with no SEP Ignore date changes in the RRSIG. Ignore changes to keys with no SEP
flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the
owner name to a new name at the history location. Publish the new owner name to a new name at the history location. Publish the new
RRset and TALINK records to make it the last element in the list. RRset and TALINK records to make it the last element in the list.
Update the TALINK in the target zone that advertises the first and Update the TALINK that advertises the first and last name.
last name.
Integrated into the rollover, the keys are stored in the history and Integrated into the rollover, the keys are stored in the history and
the TALINK is updated when a new key is used in the rollover process. the TALINK is updated when a new key is used in the rollover process.
This gives the TALINK and new historical key time to propagate. This gives the TALINK and new historical key time to propagate.
The signer can support trust history. Trust history key sets need The signer can support trust history. Trust history key sets need
only contain SEP keys. To use older signers, move historical RRSIGs only contain SEP keys. To use older signers, move historical RRSIGs
to another file. Sign the zone, including the TALINK and DNSKEY to another file. Sign the zone, including the TALINK and DNSKEY
records. Append the historical RRSIGs to the result. Signing the records. Append the historical RRSIGs to the result. Signing the
zone like this obviates the need for changes to signer and server zone like this obviates the need for changes to signer and server
skipping to change at page 5, line 37 skipping to change at page 5, line 37
by providing the TALINK shown here at example.com at the apex of the by providing the TALINK shown here at example.com at the apex of the
example.net zone. The TALINK at example.com is then not needed. example.net zone. The TALINK at example.com is then not needed.
6. Deployment 6. Deployment
The trust history is advertised with TALINK RRs at the zone apex. The trust history is advertised with TALINK RRs at the zone apex.
These represent alternative history sources, that can be searched in These represent alternative history sources, that can be searched in
turn. The TALINK at the zone apex contains the first and last name turn. The TALINK at the zone apex contains the first and last name
of the list of historical keys. of the list of historical keys.
The History Provider decides the oldest age keys it wants to publish, The historical list of keys grows perpetually. Since most validators
as operations permit. If validators no longer have trust in the keys have recent keys, their processing time remains similar as the list
then they need no longer be published. The oldest key entries can be grows. If validators no longer have trust in the keys then they need
omitted from the list to shorten it. no longer be published. The oldest key entries can be omitted from
the list to shorten it.
The validator decides how long it trusts a key. A recommendation The validator decides how long it trusts a key. A recommendation
from the zone owner can be configured for keys of that zone, or from the zone owner can be configured for keys of that zone, or
recommendations per algorithm and key size can be used (e.g. see recommendations per algorithm and key size can be used (e.g. see
[NIST800-57]). If a key is older than that, trust history lookup [NIST800-57]). If a key is older than that, trust history lookup
fails with it. fails with it and the trust point can be considered deleted. This
assumes the validator has decided on a security policy and also can
take actions when the update of the trust anchor fails. Without such
policy, or if the alternative is no DNSSEC, the approach below can be
used.
In general, the decision can be that any key - no matter how old or
how small - is better than no security. The validator then never
considers a key too old, and the lookup algorithm becomes an
unsecured update mechanism at the time where the key can be trivially
broken. The history provider SHOULD provide these broken keys to
facilitate clients performing the unsecured update. If a key can not
be trivially broken then it provides a non-trivial amount of security
that the history lookup algorithm uses to get the current keys.
Conceivably after the update the result is stored on stable storage
and the client is thereafter safe - it performs a leap of faith. The
validator operator can opt for this set up after considering the
trade-off between loss of DNSSEC, loss of connectivity, and the
argument that perceived security is worse than no security.
The history lookup can be used on its own. Then, the trust history The history lookup can be used on its own. Then, the trust history
is used whenever the key rolls over and no polling is performed. The is used whenever the key rolls over and no polling is performed.
time of the last successful key lookup is stored on stable storage. This has associated risks, in that the immediate rollover without
The trust history algorithm is not started unless the last successful timeout that it provides could be abused, and certainly when taken
key lookup was more than x time ago. This time is suggested to be together with leap-of-faith such systems SHOULD inform their user
the same has the Hold-Down timer in RFC 5011 i.e. 30 days, but can be that the key has changed and urge them to do immediate checks.
signalled by the zone owner with the TTL of the TALINK RRset at the Initially we put a hold down timer on such rollovers to mitigate the
zone apex. This TTL MUST be validated before it is stored for use abuse risks but these make following normal rollovers impossible.
later.
If a validator is also using [RFC5011] for the target zone, then the If a validator is also using [RFC5011] for the target zone, then the
trust history algorithm SHOULD only be invoked if the last [RFC5011] trust history algorithm SHOULD only be invoked if the [RFC5011]
successful probe was more than 30 days ago. If a new key has been algorithm failed due to the inability to perform probes. This is the
announced, invoke the history if no 2 probes succeeded during the add case when the last [RFC5011] successful probe was more than 30 days
hold-down time and there was no successful probe after the add hold- ago. If a new key has been announced, invoke the history if no 2
down time passed. Therefore the time of the last successful probe probes succeeded during the add hold-down time and there was no
MUST be stored on stable storage. successful probe after the add hold-down time passed. Therefore the
time of the last successful probe MUST be stored on stable storage.
For testing the potentially very infrequently used lookup, the For testing the potentially very infrequently used lookup, the
following SHOULD be implemented. For the test the lookup is following SHOULD be implemented. For the test the lookup is
triggered manually by allowing the system to be given a particular triggered manually by allowing the system to be given a particular
keyset with a last successful lookup date in the past, stored TALINK keyset with a last successful lookup date in the past and a test
TTL and a test History Provider. The test History Provider provides History Provider. The test History Provider provides access to a
access to a generated back-dated test history that signs the current generated back-dated test history.
production keyset.
7. Security Considerations 7. Security Considerations
The History Provider only provides copies of old data. If that The History Provider only provides copies of old data. If that
historic data is altered or withheld the lookup algorithm fails historic data is altered or withheld the lookup algorithm fails
because of validation errors in Step 3 of the algorithm. If the because of validation errors in Step 3 of the algorithm. If the
History provider or a Man in the Middle Adversary (MIMA) has access History provider or a Man in the Middle Adversary (MIMA) has access
to the original private keys (through theft, cryptoanalisis, or to the original private keys (through theft, cryptanalisis, or
otherwise), history can be altered without failure of the algorithm. otherwise), history can be altered without failure of the algorithm.
Below we only consider MIMAs and assume the History Provider is a Below we only consider MIMAs and assume the History Provider is a
trusted party. trusted party.
Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of
TALINK and DNSKEY data, can present some alternate history. However TALINK and DNSKEY data, can present some alternate history. However
the DNSKEY RR set trusted that the history should arrive at is the DNSKEY RR set trusted that the history should arrive at is
already fixed by step 1. If an attempt is made to subvert the already fixed by step 1. If an attempt is made to subvert the
algorithm at step 2 or 3, then the result keyset can not be replaced algorithm at step 2 or 3, then the result keyset can not be replaced
by another keyset unnoticed. by another keyset unnoticed.
skipping to change at page 7, line 20 skipping to change at page 7, line 38
This avoids the high visibility of spoofing the current key (see This avoids the high visibility of spoofing the current key (see
previous paragraph) and downgrades to insecure. previous paragraph) and downgrades to insecure.
Finally there is the case that one of the keys published by the Finally there is the case that one of the keys published by the
History Providers has been compromised. Since someone spoofing at History Providers has been compromised. Since someone spoofing at
step 1 of the lookup algorithm and presenting some fake history to a step 1 of the lookup algorithm and presenting some fake history to a
compromised key, of course does not include key revocations and does compromised key, of course does not include key revocations and does
extend the history to contain the compromised key, it therefore is extend the history to contain the compromised key, it therefore is
not really useful for a History Provider to remove the key from the not really useful for a History Provider to remove the key from the
published history. That only makes lookups fail for those validators published history. That only makes lookups fail for those validators
who are not under attack. Useful action would be to update who are not under attack. Useful action could be to update
validators using some other means. validators using some other means.
Rollover with [RFC5011] revokes keys after use. If a History Rollover with [RFC5011] revokes keys after use. If a History
Provider is used, then such revoked keys SHOULD be used to perform Provider is used, then such revoked keys SHOULD be used to perform
history tracking and history lookup. history tracking and history lookup. The old keys that the validator
starts with and final current keys MUST NOT be trusted if they are
revoked.
Depending on choices by the validator operator, it may accept a leap-
of-faith, and possibly allow non-hold-down rollovers. Although this
allows very fast emergency rollover if all clients are known to do
trust-history lookups without the RFC5011-algorithm, it also allows
an attacker with the private key to attempt to take over a zone
quickly and get validators to roll to a trust anchor of the
attacker's choosing.
The SEP bit is checked to make sure that control over the KSK is The SEP bit is checked to make sure that control over the KSK is
necessary to change the keyset for the target zone. necessary to change the keyset for the target zone.
The algorithm can be used to get the inception and expiration times
of signatures on the current keyset, a clock. A MIMA can attempt to
shorten history and put back that clock, but the algorithm attempts
to make this difficult to target and highly visible to others.
If the clock of the validator can be influenced, then setting it
forward is unlikely to give advantage, but setting it backward
enables a replay attack of old DNSSEC data and signatures. This
vulnerability exists also in plain DNSSEC.
8. IANA Considerations 8. IANA Considerations
Resource record type TALINK has been defined using RFC5395 type Resource record type TALINK has been defined using RFC5395 expert
expert review, it has RR type number TBD (decimal). review, it has RR type number 58 (decimal).
9. Acknowledgments 9. Acknowledgments
Thanks to the people who provided review and suggestions, Edward Thanks to the people who provided review and suggestions, Joe Abley,
Lewis, Michael StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
Crocker, Bill Manning, Eric Osterweil, Wolfgang Nagele, Alfred Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
Hoenes, Olafur Gudmundsson, Roy Arends and Matthijs Mekking. Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
Matthijs Mekking.
10. References 10. References
10.1. Informative References 10.1. Informative References
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M.
Smid, "Recommendations for Key Management", NIST Smid, "Recommendations for Key Management", NIST
SP 800-57, March 2007. SP 800-57, March 2007.
[RFC5011] StJohns, M., "Automated Updates of DNS Security [RFC5011] StJohns, M., "Automated Updates of DNS Security
 End of changes. 20 change blocks. 
51 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/