Preliminary Comparison between the different Trust Anchor Rollover Proposals
(last modified: 28 June 2006)
Older Versions
trust-anchor-comparison-v00.htm
This document makes a preliminary comparison between the different trust anchor rollover proposals. The requirements listed in the first column below were drawn from draft-ietf-dnsext-rollover-rquirements-02.
The comments/rationale and notes for each of the approaches have been entered based solely on my interpretation and evaluation of the requirements, proposals and various mail exchanges on namedroppers. The idea is to encourage discussion so that the correct set of evaluation parameters may be identified.
Please send any updates or corrections directly to: suresh at sparta dot com
draft-ietf-dnsext-rollover-rquirements-02
ID	Functional Requirement Interpretation	Comments/Rationale	M-of-N	Timers	Laurie	Vixie	Moreau
1. Scalability	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 apex keyset has not changed (TTL)	Queries to make sure apex keyset has not changed + one query during the add-hold period for each new key + one query per revoked-key advertisement window	As the number of islands grows, there are more certificates to retrieve recursively. You can also specify "effectivity periods" for tust anchors (through the X509 infrastructure) and use this as the bootstrapping interval.	query for apex when hash of keyset changes. Periodic queries (TTL) for apex keyset may be needed if no other data within this zone has been queried for.	Queries to make sure that the keyset has not changed (TTL) + queries for the SDDA. Might be able to augment initial distribution or the SDDA records with effectivity periods for keys to use as an optimal polling interval.
	Procedure to re-establish initial trust must be manageable over the scale of the Internet	Although initial trust is out of scope, I believe this to be relevant	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
2. No Intellectual Property Encumberance	No known IPR encumberance	Encourage deployment	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. General Applicability	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, it is not essential that all zone administrators will 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
	Support all types of stub resolvers	are there any resolver scenarios where there might not be sufficient memory to store the initial trusted configuration/state?	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 previously 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
4. Support Private Networks	Must support all types of networks	What are the different types of networks?
5. Detection of Stale Trust Anchors	Failure conditions must be identifiable and detectable	This might be refering to distinguishing between genuine loss of synchronization and spoof attacks	Difficult to make this distinction if the name sever rolls its keys faster than the polling interval.	Two different timing parameters to consider: revocation and addition. 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,	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
6. Manual Operations Permitted	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 made clear 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. Planned and Unplanned Rollovers	Support for scheduled and un-scheduled types of rollover	Why do we want to separate these two? Is it only rollovers or does revocation count?	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	quickly distribute TA material to resolvers	May be same as emergency rollover requirement
9. High Availability	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; obtaining past keys is not	obtaining current keys is easy; obtaining past keys is not	The CAs provide the repository of current and past (CRL) keys	obtaining current keys is easy; obtaining past keys is not	Past keys (or their hash) can be known by inspecting the pre-distributed list
	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
10. New RR Types	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
	Must be an in-band mechanism	No reliance on other pieces that can fail separately (I think this is relevant)	If re-sync is not needed, completely in-band	If re-sync is not needed, completely inband	DNSSEC rollover fails if X509 infrastructure fails	If re-sync is not needed, completely inband	If re-sync is not needed, completely inband
11. Support for Trust Anchor Maintenance operations	Should support add, remove, replace(as a single operation)	Basic operations.	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 (in which case the key is not added). Replace is not possiblein one step (because of the add-hold timer)	Supports add. Remove and replace are only possible if keys are revoked.	Same as M-of-N	Supports add, remove and replace operations
	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. May not have the full set of revoked keys if we're offline for a while.	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.
	Must not impose a limit on how many keys can be added, removed, replaced	Does it matter. Should there be a limit?
12. Recovery from Compromise	must support revocation and knowledge about which keys are the target of revocation	Supporting revocation is the key here I'd imagine.	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
13. Non-degrading trust	Trustworthiness must not degrade after a rollover	May be a policy issue (which algorithm to allow etc). How does one define degraded trustworthyness?