Preliminary Comparison between the different Trust Anchor Rollover Proposals
(last modified: 15 March 2006)
This document makes a preliminary comparison between the different trust anchor rollover proposals. The requirements listed in the first column below were drawn from the different documents/e-mails that were sumbitted to namedroppers. These are still being discussed and debated, so these requirements may not necessarily be the correct set of parameters to compare the different proposals against.
The comments/rationale and notes for each of the approaches has been entered based on my interpretation and evaluation of the requirements and the proposals -- they may not necessarily be correct. The idea is to encourage discussion so that the correct set (and scope) of these requirements may be identified.
Please send any updates or corrections directly to: suresh at tislabs dot com
XX	Represents requirements that may not form an effective basis for comparison
draft-ietf-dnsext-rollover-rquirements-00
ID	Requirement	Comments/Rationale	M-of-N	Timers	Laurie	Vixie	Moreau
1	Support for large number of resolvers and up to 1000 trust anchors per resolver	Rollover daemons may have to periodically query nameservers to identify apex keyset.	Queries to make sure that the keyset has not changed (TTL)	Queries to make sure keyset has not changed + one query during the add-hold period for each new key + one query per revoked-key advertisement window	Scales well for large number of resolvers. However as the number of islands grows, there are more certificates to retrieve recursively	query for apex when hash of keyset changes + any query to that zone within the period that a key might change (TTL).	Queries to make sure that the keyset has not changed (TTL) + queries for the SDDA
2	No IPR encumberance/ globally deployable	Encourage interoperability	Diversinet patent filed in Israel and also applied for in Canada. Don't understand what it considers "reasonable" (I am not a lawyer)	Diversinet patent filed in Israel and also applied for in Canada. Don't understand what it considers "reasonable" (I am not a lawyer)	None currently known	Suffers from the same patent claim that M-N does(?)	There is some hint that the idea of pre-distribution of digests is not new -- using MASH's is patented though, and the idea is not universally free to use
3,4	Support for all types of zones and networks (tunable to their needs)	Universal solution
5	Support reconnection upto a period of N months	Avoid initial setup if it can be avoided	Does not directly support this	Does not directly support this	As long as you can trust the local CA certificate, resolvers can reconnect without problem	Does not directly support this	If resolvers have the current key in the set of pre-distributed keys, they can reconnect without problem
6	Leave room for manual rollover operations	It is always possible to manually set the trust anchor, so one interpretation of this requirement could be that doing so should not prevent automated mechanisms from taking over thereon	No state is maintained, so no harm done if trust anchors are manually configured	Probably no harm -- specification needs to be updated to specify how the timers are affected if trust anchors change OOB	The bootstrapping process simply gives a list of keys, which can also be configured manually	No state is maintained, so no harm done if trust anchors are manually configured	Should be possible to configure a trust anchor manually
7	Support for pre-scheduled and emergency types of rollover	Why do we want to separate these two?	Supports pre-scheduled well; emergency rollover cannot be detected any sooner	Supports pre-scheduled well; emergency rollover cannot be detected any sooner	rollovers in general can only be detected at the same rate at which bootstrapping is done	Supports pre-scheduled well. Emergency rollover is faster than MofN because any DNS response from that zone can trigger this	Supports pre-scheduled well; emergency rollover cannot be detected any sooner
8	Timeliness	May be same as emergency rollover requirement
9	Ability to inspect issuer's knowledge of possible current and past trust anchors	Resolvers should be able to detect when they need to re-sync.	obtaining current keys is easy; obtaininig past keys is not	obtaining current keys is easy; obtaininig past keys is not	The CAs provide the repository of current and past (CRL) keys	obtaining current keys is easy; obtaininig past keys is not	Past keys (or their hash) can be known by inspecting the pre-distributed list
10	No new RRs shall be needed	No on-the-wire changes in general	No on-the-wire changes	Addition of the revoke bit in the DNSKEY (but this is a feature)	Completely OOB	Modifies name server algorithm. Keyset digest is sent in the authority section. Message size increases	New SDDA RR definition
Pseudo-requirements from draft-ietf-dnsext-rollover-requirements-00
ID	Requirement	Comments/Rationale	M-of-N	Timers	Laurie	Vixie	Moreau
11	trustworthy initialization of trust anchors in resolvers	Initialization must be manageable over the scale of the Internet	Need to establish trust with all zones for which a TA needs to be configured, every time the resolver is offline for a prolonged period	Need to establish trust with all zones for which a TA needs to be configured, every time the resolver is offline for a prolonged period	Need to establish trust with only the local CA.	Need to establish trust with all zones for which a TA needs to be configured, every time the resolver is offline for a prolonged period	Need to establish trust with all zones for which a TA needs to be configured, every time the resolver is offline for a prolonged period
12	Support trust anchors for multiple zones	Support for islands of trust	Supports this	Supports this	Supports this	Supports this	Supports this
13	Support for multiple trust anchors per zone	Pre-publishing, use of diverse algorithms etc	Supports this	Supports this	Supports this	Supports this	Supports this: different SDDA RRs in the RRset can point to different DNSKEYs
14	Should support add, remove, replace(as a single operation)	Basic operations. Remove is different from revoke	Add, remove and replace may not be simultaneously possible. For replace N has to be at least 2, but for single addition N has to be 1.	Supports add and remove operations. Remove is same as revoke unless it is inside the add-hold time interval. Replace is not possiblein one step (because of the add-hold timer)	Supports add. Remove and replace are only possible if keys are revoked.	Add, remove and replace may not be simultaneously possible. For replace N has to be at least 2, but for single addition of key N has to be 1	Supports add, remove and replace operations
15	must support revocation and knowledge about which keys are the target of revocation	Revocation is different from replacement	Does not support revocation	Supports revocation, but may not have knowledge of the complete set of keys that were revoked - it only knows what it sees	Supports revocation through the X509 infrastructure	Does not support revocation	Does not support revocation
16	Ability to define effectivity periods for tust anchors	Helpful for determining a polling interval	Not possible	Not possible	Supports this through the X509 infrastructure	Not possible	Might be able to augment initial distribution or the SDDA records with effectivity periods for keys
draft-moreau-dnsext-tak-req-00
ID	Requirement	Comments/Rationale	M-of-N	Timers	Laurie	Vixie	Moreau
17	Organizations must universally agree to follow guidelines	Maybe this is trying to say that the procedure should be operationally viable, which is the same as requirement 3,4
18, 19	Must include a local store, Must assume an opportunity for initializing the trusted configuration	are there any resolver scenarios where there might not be sufficient memory to store the initial trusted configuration? The requirement may instead be: must keep the amount of local persistent storage to a minimum	Needs memory for storing at least M+N keys per island of trust	Needs sufficient memory for at least two trust anchor keys per island of trust and the set of revoked keys that were seen	Needs sufficient memory to store location and certificate of local CA	Similar to M-of-N	Needs memory to store the series of 4-tuples for every island of trust
20	Trustworthiness must not degrade after a rollover	May be a policy issue (which algorithm to allow etc). How does one define degraded trustworthyness?
21	Failure conditions must be identifiable and detectable	Looking at it differently from revocation (which is given in 15), this might instead refer to distinguishing between genuine loss of synchronization and DoS attacks	Difficult to make this distinction if the name sever rolls its keys faster than the polling interval.	Depends on how much you believe that your revocation information is current. If you suddenly see new keys and you know you haven't missed revocation event, you can ignore the new keys	Rollover is essentially doing the resolver bootstrap all over again. The resolver may treat multiple unknown trust anchors as cue to perform the bootstrap, backing off from this process exponentially	Difficult to make this distinction if the name sever rolls its keys faster than the polling interval.	Since there is no revocation information maintained, you don’t know if the name server operator suddenly decided to change the complete set of pre-published keys
22	Must allow for protection against reuse attacks	Looks like the same as 15
23	Must disclose how dependent the procedure is on OOB distribution of configuration information	This may be trying to say the same thing as 11
24	Must allow for overlapping periods of key validity	This is a requirement for the zone data adminstrator and is not under the control of the trust anchor rollover protocol	If rollover at the zone is not graceful, you would fall back to initial state	If rollover at the zone is not graceful, you would fall back to initial state	Non-graceful rollover of keys at the zone does not adversely impact this approach. You simply bootstrap all over again	If rollover at the zone is not graceful, you would fall back to initial state	Even if rollover at the zone is not graceful, you can still carry on the process if the new key is in your pre-distributed list of keys.
25	It should be possible to identify which keys are have been added/rolled over	There is always local policy that can influence the final decision on whether a key is rolled over at the resolver end	You don't really know if one of the keys in the trusted set was removed. The M and N parameters are additional policy knobs that determine exact key that is rolled over.	The values of the timers can influence the set of keys that are added as trust anchors in the resolver.	You get to see this in the CRLs	You don't really know if one of the keys in the trusted set was removed	Its possible to examine the pre-distributed list to know which keys have been rolled over.
26	Disclosure of which aspects of security principles are needed for avoidance of critical failure	This may be same as 21
Other Requirements
ID	Requirement	Comments/Rationale	M-of-N	Timers	Laurie	Vixie	Moreau
27	Must be an in-band mechanism	No reliance on other pieces that can fail separately	If re-sync is not needed, completely in-band	If re-sync is not needed, completely inband	DNSSEC fails if X509 infrastructure fails	If re-sync is not needed, completely inband	If re-sync is not needed, completely inband
28	Shall work for different types of keys in the keyset (unknown algorithms, only ZSKs, only KSKs)	Since there is no protocol difference between ZSKs and KSKs, you cannot expect all zone administrators to maintain this separation	Needs to have ZSK and KSK separation	Needs to have ZSK and KSK separation	Need not have ZSK and KSK separation	Needs to have ZSK and KSK separation	Need not have ZSK and KSK separation
29	Must not impose a limit on how many keys can be added, removed, replaced or revoked	Does it matter. Should there be a limit?
30	Trust anchor configuration must not significantly increase work for the name server operator	Over and above best practices, i.e.. However, emergency scenarios are different I think and graceful rollover may not be the norm here. This is covered in 24.