This is a discussion on Re: WGLC on rollover-requirements and trustudpate-timers - DNS ; 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 ...
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.
LACK OF A SECURITY MODEL FOR AUTOMATED TRUST ANCHOR ROLLOVER
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
and then replied in
and http://ops.ietf.org/lists/namedroppe.../msg01037.html .
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
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
WG PROCESS OF INTELLECTUAL PROPERTY ISSUE
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
Canada H2M 2A1
web site: http://www.connotech.com
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.