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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf