An out-of-scope analysis of in-scope TAK rollover proposals

[Thierry Moreau <[e-mail]>]

Dear DNSEXT particpants:

Your current consideration of TAK rollover issues is appreciated.

I assume that the draft-ietf-dnsext-rollover-requirements-02 is about to 
be last called and thus reflects the IETF view on TAK rollover 
requirements. I also assume to be applicable the short list of three TAK 
rollover proposals from 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00829.html, i.e.
	1) draft-ietf-dnsext-trustupdate-threshold,
	2) draft-ietf-dnsext-trustupdate-timers, and
	3) draft-laurie-dnssec-key-distribution
(for the purpose of the present message, I do not put into question 
Olaf's view on the presence of my own proposal in the list of TAK 
rollover porposal).

I assume that either the -threshold or the -timers proposal gets 
selected as the IETF TAK rollover procedure. See e.g. 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00848.html.

Then, the IAB carries the good news to the DNS root zone administrator 
that DNSSEC protocols are ready for deployment at the root (the privacy 
issue driving the NSEC3 protocol refinement does not apply to the DNS 
root zone). Accordingly, the DNS root zone administrators will set up N 
(>=2) TAKs (i.e. KSK DNSKEY RRs having the SEP bit set to 1).

So, the DNS root zone administrator turns to the world with the big news 
that the DNS will be secured, with N (>=2) TAKs at the root and the 
reassuring confidence that any simultaneous breach of M (<N) TAKs will 
be recovered by an automated TAK rollover protocol.

Up to now, this is in scope for IETF DNSEXT activities. But I now use 
concepts from draft-moreau-dnsext-tak-req-00 which were not accepted in 
the IETF TAK rollover requirements document. Specifically, the following 
requirement are useful for my analysis:

	The "catastrophic failure mode" of trust anchor key operation 
specification is defined as the circumstances leading to, and 
consequences of, a failure of any of the cryptographic mechanisms relied 
upon for the rollover operation. A trust anchor key management scheme 
must disclose the details of its catastrophic failure mode.

and

	The DNS zone manager should make prudent application of generally 
agreed security principles throughout the DNSSEC digital signature key 
life cycle. A trust anchor key management scheme must disclose which 
aspects of these security principles are needed for the avoidance of the 
scheme's critical failure mode.

With either the -threshold or the -timers proposal, the catastrophic 
failure mode is the simultaneous breach of m (M<m<=N) TAKs. It is thus 
important that each of the N TAKs be handled securely and 
*independently* form each other (otherwise, the likelihood of 
simultaneous breach of every TAKs is practically the same as the 
likelihood of a single TAK breach).

This analysis can be made by security experts in the world who are not 
bound by the IETF prior work for TAK rollover requirements. They would 
then question the DNS root zone manager about the actual implementation 
of the above TAK handling independence. I doubt adequate answers can be 
provided, from a) my understanding of how sensitive cryptographic key 
material is handled in "reputed" organizations, and b) the 
shortsightedness of operational and budgetary planning in most 
organizations. Accordingly, there is no convincing argument that either 
the -threshold or the -timers proposal achieves any significant security 
enhancement.

In summary, the IETF DNSEXT handling of the automated TAK rollover issue 
is coherent within its own logic and process (i.e. the internal logic of 
draft-ietf-dnsext-rollover-requirements-02 and the consensus-based 
process for the selection of a solution from a requirements document). 
Even if the above out-of-scope analysis was relevant to a few security 
experts, it faces the consensus barrier created by the DNSEXT culture of 
caring for other challenges more typical of DNS protocol developments.

(For now, I abstain from commenting on my own proposal in this context, 
leaving the DNSEXT forum attention to what is being achieved with the 
three proposals under consideration.)

Regards,


-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>