Dear all:

As the TAK rollover WGLC nears completion within the DNSEXT wg, I
attempt to summarize my views on this activity. I include in a single
message a critique on the TAK management requirements document
(draft-ietf-dnsext-rollover-requirements-03.txt) and the IETF expected
solution for automated TAK rollover

There are no new arguments in the present message, nor an attempt to
change other participants' opinions. It's just a summary.


Although DNSSEC is an IT security protocol, when it came to an automated
TAK rollover protocol, the DNSEXT wg omits a documented security model
as a side issue. For trustupdate-timers, this has been raised by Eric
Rescorla in ,
and then replied in
and .

Incidentally, it is almost by accident that the rollover-requirements
paragraph 5.13. (Non-degrading trust) remains in the current draft
). Moreover, an expert review of the TAK rollover alternatives found the
requirement ill-defined: "May be a policy issue (which algorithm to
allow etc). How does one define degraded trustworthiness?" (from at brought
to the DNSEXT wg attention in
). This does not prevent this same expert from supporting the IETF
expected solution for automated TAK rollover

At one point, I argued that the actual scope of rollover-requirements
was too broad ("trust anchor management"), and should instead focus on
the automated trust anchor rollover operation, perhaps even more
narrowly on rollover *within the DNS protocol* (
). Indeed, the only use of rollover-requirements is the selection of an
automated TAK rollover solution. In progressing a high level "trust
anchor management" requirements document, the DNSEXT wg stayed away from
a reasonable statement for a security model for automated trust anchor

The lack of a security model is perhaps coherent with the limited
operational guidelines found in trustupdate-timers. This seems to shift
some of the work to DNSOP, and/or to DNS zone administrations that
cannot avoid the island-of-trust status (e.g. ICANN as the DNS root zone
administration). However, an IT security scheme is strengthened when the
various aspects (e.g. technological, parameter selection,
implementation, operations) are considered at once in a single security


IPR encumbrance has been discussed at length in the DNSEXT wg mailing
list. The draft-ietf-dnsext-rollover-requirements-03.txt document, in
its paragraph 5.2, varies the IPR-related process defined in RFC 3668.
In one message, I argued that the working group used an "a-priori option
abandonment formulation" in this paragraph 5.2, committing itself to
reject one of the solution, without a reasonable justification (
). Despite mitigating observations by DNSEXT chairman and minor
rewording in the -02 draft revision, the paragraph 5.2 was quite
effective as an a-priori option abandonment.

The adoption of draft-ietf-dnsext-rollover-requirements-03.txt as an
informational RFC may establish a precedent in wg process for the
selection of a technology, shifting the balance towards an ideological
avoidance of IPR encumbered solutions. Perhaps the IESG wishes to keep
RFC 3668 as the sole authoritative text on these matters.


I object to the progress of draft-ietf-dnsext-rollover-requirements-03.txt.

Since draft-ietf-dnsext-rollover-requirements-03.txt is likely to be
adopted, I abstain about draft-ietf-dnsext-trustupdate-timers-04.txt
(i.e. the lack of a security model in rollover-requirements makes
trustupdate-timers a "good enough" solution).



- Thierry Moreau

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

Tel.: (514)385-5691
Fax: (514)385-5900

web site:

to unsubscribe send a message to with
the word 'unsubscribe' in a single line as the message text body.