Re: WGLC on rollover-requirements and trustudpate-timers

[Thierry Moreau <[e-mail]>]

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 
(draft-ietf-dnsext-trustupdate-timers-04.txt).

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 
Rescorla in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01026.html , 
and then replied in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01035.html 
and http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01037.html .

Incidentally, it is almost by accident that the rollover-requirements 
paragraph 5.13. (Non-degrading trust) remains in the current draft 
(compare 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00624.html 
and 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00695.html 
). 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 
http://www.dnssec-tools.org/docs/trust-anchor-comparison-v02.htm brought 
to the DNSEXT wg attention in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00862.html 
). This does not prevent this same expert from supporting the IETF 
expected solution for automated TAK rollover 
(http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01311.html)

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* ( 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00630.html 
). 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 
rollover.

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 
analysis.

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 ( 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00239.html 
). 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.

CONCLUSION

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).

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/>