--- /dev/null
+
+
+
+Domain Name System Operations W. Wijngaards
+Internet-Draft O. Kolkman
+Intended status: Standards Track NLnet Labs
+Expires: August 26, 2010 February 22, 2010
+
+
+ DNSSEC Trust Anchor History Service
+ draft-ietf-dnsop-dnssec-trust-history-01
+
+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.
+
+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].
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and 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 August 26, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 1]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the BSD License.
+
+1. Introduction
+
+ This memo defines a trust history service for DNS validators -- the
+ component in a resolver that performs DNSSEC [RFC4034] validation,
+ validator for short.
+
+ A validator that has been offline or missed an (emergency) rollover
+ can use this service to reconfigure themselves with the current
+ trust-anchor. Using a newly defined resource record (RR) that links
+ old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY
+ RRsets and checks they form a chain to the latest key (see
+ Section 2). The lists of old DNSKEYS, linked with the TALINK RRs, do
+ 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.
+ We will call the entity that offers the trust history the History
+ Provider. The choice of the History Provider is made by the
+ maintainer of the validator, possibly based on a hint provided, using
+ the TALINK, by the zone owner.
+
+ The algorithm that the validator uses to construct a history and
+ reconfigure a new key is detailed in Section 3. The algorithms for
+ how providers of trust history can fetch the DNSKEY data as published
+ by the zone they track and publish that are explained in Section 4.
+
+2. The TALINK Resource Record
+
+ The DNS Resource Record type TALINK (decimal 58) ties the elements of
+ a linked list of DNSKEY RRs together.
+
+ 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
+ list. The empty label '.' is used at the endpoints of the list.
+
+ The presentation format is the two domain names. The wire encoding
+ is the two domain names, with no compression so the type can be
+ treated according to [RFC3597]. The list is a double linked list,
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 2]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ because this empowers low memory hosts to perform consistency checks.
+
+3. Trust History Lookup
+
+ 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
+ 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
+ Provider, to arrive from the outdated configured Trust Anchor to one
+ that matches the current DNSKEY. The TALINK RR type is defined in
+ Section 2.
+
+ 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
+ another mechanism.
+
+ Step 1: The validator performs a DNSKEY lookup to the target zone,
+ which looks like any other initial DNSKEY lookup that the
+ validator needs to match a trust anchor to the currently used
+ DNSKEY RR set. If the keyset verifies with the trust anchor
+ currently held, the trust-anchor is not out of sync. Otherwise,
+ store the DNSKEY RR set as result. The algorithm will
+ 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
+ upstream resolver caches when the validator is not full resolver)
+ 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
+ all nameservers are in sync yet. This case can be detected by
+ checking that the older keyset signs the newer and take the newer
+ as result keyset. The keysets are distinguished by the average
+ over the middle of the inception and expiration dates of the
+ signatures that are validated by the keyset itself. Otherwise,
+ the history lookup fails. If the check fails then the
+ inconsistency may be the result of spoofing, or compromise of
+ (DNS) infrastructure elements.
+
+ Step 2: Fetch the trust history list end points. Perform a query of
+ QTYPE TALINK and QNAME the domain name that is configured to be
+ the History Provider for the particular domain you are trying to
+ update the trust-anchor for.
+
+ Step 3: Go backwards through the trust history list as provided by
+ the TALINK linked list. Verify that the keyset validly signs the
+ next keyset. This is [RFC4034] validation, but the RRSIG
+ expiration date is ignored. [Editor note: Are we shure that there
+ are no server implementations that will not serve expired RRSIG,
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 3]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ are such 'smart' servers allowed by the specs? In other words do
+ we need clarification in the DNSSEC-updates document?] Replace
+ 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
+ set. The middle of inception and expiration date from the valid
+ signature MUST be older than that of the signature that validates
+ 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
+ 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
+ [RFC5011].
+
+ 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:
+ if false, continue with result a failure, if true, continue with
+ the end result that the trust point is deleted. Thus, the keysets
+ with unknown algorithms are stepped over with an end result of
+ failure because the validator cannot determine if unknown
+ algorithm signatures are valid, until the oldest keyset with
+ unknown algorithms is signed by a known algorithm and the result
+ is set to deletion and step 3 continues to a known key.
+
+ Step 4: When the trust anchor currently held by the validator
+ verifies the keyset, the algorithm is done. The validator SHOULD
+ store the result on stable storage. Use the new trust anchor for
+ validation (if using [RFC5011], put it in state VALID).
+
+4. Trust History Tracker
+
+ External trackers can poll the target zone DNSKEY RRset regularly.
+ Ignore date changes in the RRSIG. Ignore changes to keys with no SEP
+ flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the
+ 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.
+ Update the TALINK that advertises the first and last name.
+
+ 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.
+ This gives the TALINK and new historical key time to propagate.
+
+ The signer can support trust history. Trust history key sets need
+ only contain SEP keys. To use older signers, move historical RRSIGs
+ to another file. Sign the zone, including the TALINK and DNSKEY
+ records. Append the historical RRSIGs to the result. Signing the
+ zone like this obviates the need for changes to signer and server
+ software.
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 4]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+5. Example
+
+ In this example example.com is the History Provider for example.net.
+ The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy
+ and paste of the data from example.net.
+
+ $ORIGIN example.com.
+ example.com. TALINK h0.example.com. h2.example.com.
+
+ h0 TALINK . h1.example.com.
+ h0 DNSKEY ...
+ h0 RRSIG ...
+
+ h1 TALINK h0.example.com. h2.example.com.
+ h1 DNSKEY ...
+ h1 RRSIG ...
+
+ h2 TALINK h1.example.com. .
+ h2 DNSKEY ...
+ h2 RRSIG ...
+
+ The example.net zone can advertise the example.com History Provider
+ 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.
+
+6. Deployment
+
+ The trust history is advertised with TALINK RRs at the zone apex.
+ These represent alternative history sources, that can be searched in
+ turn. The TALINK at the zone apex contains the first and last name
+ of the list of historical keys.
+
+ The historical list of keys grows perpetually. Since most validators
+ have recent keys, their processing time remains similar as the list
+ grows. If validators no longer have trust in the keys then they need
+ 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
+ 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
+ [NIST800-57]). If a key is older than that, trust history lookup
+ 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.
+
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 5]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ 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
+ is used whenever the key rolls over and no polling is performed.
+ This has associated risks, in that the immediate rollover without
+ timeout that it provides could be abused, and certainly when taken
+ together with leap-of-faith such systems SHOULD inform their user
+ that the key has changed and urge them to do immediate checks.
+ Initially we put a hold down timer on such rollovers to mitigate the
+ abuse risks but these make following normal rollovers impossible.
+
+ If a validator is also using [RFC5011] for the target zone, then the
+ trust history algorithm SHOULD only be invoked if the [RFC5011]
+ algorithm failed due to the inability to perform probes. This is the
+ case when the last [RFC5011] successful probe was more than 30 days
+ ago. If a new key has been announced, invoke the history if no 2
+ probes succeeded during the add hold-down time and there was no
+ 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
+ following SHOULD be implemented. For the test the lookup is
+ triggered manually by allowing the system to be given a particular
+ keyset with a last successful lookup date in the past and a test
+ History Provider. The test History Provider provides access to a
+ generated back-dated test history.
+
+7. Security Considerations
+
+ The History Provider only provides copies of old data. If that
+ historic data is altered or withheld the lookup algorithm fails
+ because of validation errors in Step 3 of the algorithm. If the
+ History provider or a Man in the Middle Adversary (MIMA) has access
+ to the original private keys (through theft, cryptanalisis, or
+ otherwise), history can be altered without failure of the algorithm.
+ Below we only consider MIMAs and assume the History Provider is a
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 6]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ trusted party.
+
+ 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
+ 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
+ algorithm at step 2 or 3, then the result keyset can not be replaced
+ by another keyset unnoticed.
+
+ To change the keyset trusted as the outcome, the step 1 data has to
+ be spoofed and the key held by the validator (or a newer historic
+ key) has to be compromised. Unless such spoof is targeted to a
+ specific victim, a spoof of the step 1 result has a high visibility.
+ Since most of the validators that receive the spoof have an up-to-
+ date trust anchor most validators that would receive this spoof
+ return validation failure for data from the zone that contains the
+ DNSKEYs. An adversary will therefore have to target the attack to
+ validators that are in the process of an update. Since validators do
+ not announce that they use trust history lookup until step 2
+ adversaries will not be able to select the validators.
+
+ A spoof of data in steps 2 and 3, together with a compromised (old)
+ key, can result in a downgrade. At steps 2 and 3 a faked trust point
+ deletion or algorithm rollover can be inserted in a fake history.
+ This avoids the high visibility of spoofing the current key (see
+ previous paragraph) and downgrades to insecure.
+
+ Finally there is the case that one of the keys published by the
+ History Providers has been compromised. Since someone spoofing at
+ step 1 of the lookup algorithm and presenting some fake history to a
+ compromised key, of course does not include key revocations and does
+ extend the history to contain the compromised key, it therefore is
+ not really useful for a History Provider to remove the key from the
+ published history. That only makes lookups fail for those validators
+ who are not under attack. Useful action could be to update
+ validators using some other means.
+
+ Rollover with [RFC5011] revokes keys after use. If a History
+ Provider is used, then such revoked keys SHOULD be used to perform
+ 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
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 7]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ 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
+ 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
+
+ Resource record type TALINK has been defined using RFC5395 expert
+ review, it has RR type number 58 (decimal).
+
+9. Acknowledgments
+
+ Thanks to the people who provided review and suggestions, Joe Abley,
+ George Barwood, Edward Lewis, Michael StJohns, Bert Hubert, Mark
+ Andrews, Ted Lemon, Steve Crocker, Bill Manning, Eric Osterweil,
+ Wolfgang Nagele, Alfred Hoenes, Olafur Gudmundsson, Roy Arends and
+ Matthijs Mekking.
+
+10. References
+
+10.1. Informative References
+
+ [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M.
+ Smid, "Recommendations for Key Management", NIST
+ SP 800-57, March 2007.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security
+ (DNSSEC) Trust Anchors", RFC 5011, September 2007.
+
+10.2. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
+ Record (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 8]
+\f
+Internet-Draft Trust History Service February 2010
+
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security
+ Extensions", RFC 4034, March 2005.
+
+Authors' Addresses
+
+ Wouter Wijngaards
+ NLnet Labs
+ Science Park 140
+ Amsterdam 1098 XG
+ The Netherlands
+
+ EMail: wouter@nlnetlabs.nl
+
+
+ Olaf Kolkman
+ NLnet Labs
+ Science Park 140
+ Amsterdam 1098 XG
+ The Netherlands
+
+ EMail: olaf@nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wijngaards & Kolkman Expires August 26, 2010 [Page 9]
+\f
projects / thirdparty / bind9.git / commitdiff
