Doug,
On May 28, 2009, at 2:36 PM, Douglas Otis wrote:
While DNSSEC may protect against data corruption, such protection
depends upon the thorny problem of verifying a key will be solved in
a practical and politically acceptable manner.
If you're talking about the 'who signs the root key' political
problem, I would note there is already an alternative. Folks who
don't trust whoever signs the root can simply include the trust
anchors from the IANA ITAR (http://itar.iana.org/). Yes, this means
managing (many) more trust anchors than the single root anchor, but if
you're that worried that the Men In Black might muck with the root
KSK, you probably prefer to verify what IANA put into the root is
valid by hand anyway.
This protection also requires authoritative servers to rapidly adopt
DNSSEC without also confronting other insurmountable deployment
issues. Fool me once, shame on you. Fool me twice...
If there are insurmountable deployment issues, then it might be worth
raising them in the DNSEXT working group so we can all stop wasting
our time trying to deploy DNSSEC.
Assume SCTP becomes generally available as a preferred transport for
DNS.
"First, boil the ocean..."
If so, an ability to corrupt DNS information would be greatly
reduced, whether data is signed or not. In addition, SCTP can
safely carry larger signed results without the DDoS concerns that
will exist for either TCP or EDNS0 over UDP. Deploying DNS on SCTP
should be possible in parallel with the DNSSEC effort.
I have no objection to anyone proposing DNS over SCTP and would agree
there are benefits. I am simply saying that channel security (such as
DNS over SCTP) does not actually protect what matters, the data that
is returned. Specifically, if a device in the SCTP connection path is
compromised and the data is not signed, you lose. If the data is
signed, it doesn't matter how you get the data or how hostile the path
is. Getting that data via SCTP would be fine. But so would UDP, TCP,
sneakernet, or IP over Carrier Pigeon.
Regards,
-drc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf