Phil,
That's a specious argument. As several others have noted on this list,
it's perfectly feasible for any relying parties (sovereign nations or
otherwise) to not use the IANA root, simply by creating their own root.
This is a little more complicated than just redirecting IP traffic,
but not by much.
To quote from Mark's earlier message:
Mark Andrews wrote:
> Stephen Kent writes:
>>
>> 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.
--Richard
Phillip Hallam-Baker wrote:
Steve,
The sovereign nations that object to US control of the root are
willing to accept the current status quo preciely because they have an
exit option. Should the US defect on its obligations and order ICANN
to drop Cuba or Palestine out of the root or to take any other action
that was considered to be abusive, the countries that objected could
simply direct their local ISPs to redirect all IP traffic to the A
thru M root servers to another set of servers of their choice.
At the moment the ICANN has the theoretical ability to defect, but can
only do so at the cost of becomming irrelevant. The global DNS outside
the US would swiftly pass to the ITU.
With the proposed root arrangement for DNSSEC, this changes. Not only
does the US have effective control, it has perpetual control of any
apparatus that chains to the ICANN root of trust.
This is bad for the US, bad for ICANN and bad for other sovereign
states. First, consider the likely source of a defection, some idiot
member of Congress from Florida grandstanding for votes. Such a move
is going to give the career civil service a fit, particularly the
diplomats who prefer to end rather than begin international crises. I
have spoken to very enior members of this administration on this
topic, they had come to the exact same conclusion themselves.
Now consider ICANN. Let us imagine that they do hold the master root
key. What is then to stop some armed terrorist nut cases laying siege
to the key repository? Their objective might not be to drop a country
out, they might want to insert some irredentist domain of their own.
Ordinary PKIs are not subject to this type of pressure, because they
are not the lynchpin of the global communication system.
While the various splinter-roots may appear to be complete jokes, they
have had one significant result, they have drawn attention to the
issue. In particular very much doubt that the Turkish secret service
are too amused at the whole process given some of their experiences.
On Wed, Jun 10, 2009 at 1:11 PM, Stephen Kent<kent@xxxxxxx> wrote:
Joe,
You have argued that DNSSEC is not viable because it requires that everyone
adopt IANA as the common root. 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf