Phil,
The examples you give about backed-in trust anchors are valid,
but they point to decisions by vendors to simplify their designs at
the cost of secruity and functionality. I've been told that it is very
hard, if not impossible, to permanently remove some vendor-supplied
TAs in a popular browser. These are not fundamental results of
architectural decisions of the sort the IETF makes, but vendor choices
that lead to possible problems for user.
I think I understand the multi-party, RP-centric threshold
approach to managing the DNSSEC root that you outlined. But, in a
DNSSEC environment, IANA performs two roles:
Any scheme that allows multiple entities to "confirm"
the content of the root zone file also has to include a means for
these entities to independently acquire and verify the master file
data and to create a separate, distinct master file if they disagree.
This is a lot more complex that what you outlined in your message
(from an from an administrative vs. crypto perspective). It also
raises questions about how complex RP software has to be in dealing
with multiple sets of quasi-authoritative root authorities. All
experience to date suggests that RPs fare poorly when trying to deal
with much less complex trust anchor situations in other PKI
environments today.
It is conceivable (under the new administration) that ICANN will
stop being under the control of the U.S DoC, but it also is not clear
that such a change would ameliorate the concerns of all governments
with regard to this issue. I think the set of folks who feel a need to
use other than the current, proposed model (IANA as the DNSSEC root)
are a very small minority of the set of public Internet users and thus
they should bear the burden of dealing with the resulting costs and
complexity for managing alternative root schemes. I don't think that
such costs and complexity should be borne by the vast majority of
Internet users. Its also not clear how long one might spend debating
the question of whether any single scheme would satisfy all of
the players who are not comfortable with the current model.
Steve
Steve
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf