It is possible for people set their own roots, but it is not very
practical to maintain them. And this is going to be particularly
difficult if we ever get DNSSEC deployed in platform distributions and
end-entities are configured to check their own DNS chains up to a
baked-in ICANN root.
It is not a sustainable model. Here is what I propose instead, it is a
variation of ideas Carl Ellison and Phil Zimmerman have proposed in
the past, it is thus entirely unencumbered:
1) There are multiple public signers for the apex zone signing key.
These are moderately serious entities employing trustworthy hardware,
secure facilities etc. They publish a CPS describing their practices.
2) Each relying party selects the subset of apex signers they are
willing to trust and the conditions for accepting a signature. This
may be 3 out of 5 or 4 out of 7 or anything the relying party decides.
3) Applications, Servers, etc. ship with default quorum conditions
configured but these can be over-ridden.
This has a number of interesting effects:
1) We have eliminated the incentive to default, not just placed
controls that make it difficult to default. While an apex signatory
can defect, they cannot profit unless they can persuade others to
collude with them. Relying parties can make this rather unlikely by
choosing apex signers that are entirely unlikely to collude (Cuba,
France and the US).
2) Parties that feel that the US has too much influence in the DNS
have something that they can do to counter that influence. Instead of
sitting on the sidelines and throwing spanners into the works, the
countries concerned about their sovereignty being infringed can start
their own apex signatory authority.
3) The system can be stable over very long periods of years, centuries
even, even if the apex signer authorities are not stable. This makes
it viable for a corporation to be a signer. While it is most unlikely
that Google will disappear in the next 5 years, any company can go
bust over a course of decades, as GM and Chrysler are demonstrating.
The same approach can be extended to support long term repositories of
digital data. So imagine that we wanted to set up a long term
repository of academic journal articles in electronic form. Most
people who propose these things understand the necessity of physical
duplication of the data storage, but not the need for failsafe design
of the management institutions.
On Wed, Jun 10, 2009 at 8:41 PM, Mark Andrews<marka(_at_)isc(_dot_)org> wrote:
In message <p06240803c65430cf6e92(_at_)[10(_dot_)10(_dot_)10(_dot_)117]>,
Stephen Kent writes:
Joe,
You have argued that DNSSEC is not viable because it requires that
everyone adopt IANA as the common root.
Which isn't even a requirement. Alternate root providers just need
to get copy of the root zone with DS records and sign it with their
own DNSKEY records for the root.
ISP's that choose to use alternate roots might get complaints however
from their customers if they are validating the answers using the
trust-anchors provided by IANA. This however should be seen as a
good thing as the ISP can no longer tamper with the DNS without
being detected. If a ISP can convince all their customers that the
alternate roots are a good thing then this won't become a issue.
I agree that under the
current IANA management situation many folks may be uncomfortable
with IANA as the root. However, in practice, the world has lived
with IANA as the root for the non-secure version of DNS for a long
time, so it's not clear that a singly-rooted DNSSEC is not viable
based on this one concern. Moreover, DNSSEC is a form of PKI, an din
ANY PKI, it is up to the relying parties to select the trust anchors
they recognize. In a hierarchic system like DNS, the easiest
approach is to adopt a single TA, the DNS root. But, it is still
possible for a relying party to do more work and select multiple
points as TAs. I would expect military organizations in various parts
of the world to adopt a locally-managed TA store model for DNSSEC, to
address this concern. However the vast majority of Internet users
probably are best served by the single TA model.
As for DNSCurve, I agree with the comments that several others have
made, i.e., it doe snot provide the fundamental security one wants in
DNS, i.e., an ability to verify the integrity and authenticity of
records as attested to by authoritative domains, din the face of
caching.
Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
--
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