I agree the resources are non-trivial
But it creates a put-up or shut-up point for the non-US objectors to
the sole US controlled root. What it does not do is to address the
state dept concerns that the root is a liability. And the cost of
setting up an apex authority are much less than the cost of fracturing
the root.
Given the complete lack of interest that the DNSSEC community has had
in consultation with deployment stakeholders, the quorate approach
might well be important as a way to co-opt the existing Domain
Validated SSL cert providers to seed a DNSSEC deployment in a DLV
structure.
One of the administrative parts of the puzzle that nobody seems to
have thought out is why the registrars are going to play ball. Or for
that matter what the charge for a DNSSEC zone entry is going to be.
On Thu, Jun 11, 2009 at 8:35 PM, Stephen Kent<kent(_at_)bbn(_dot_)com> wrote:
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:
- it coordinates the info from the gTLDs and ccTLDs and constructs
the authoritative root zone file
- it signs the records of that file
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
--
--
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf