On Mar 7, 2010, at 4:47 AM, Masataka Ohta wrote: > Jim Reid wrote: > >> The Bad Guy won't have the private keys, > > Wrong. > > While the Bad Guy as an ISP administrator won't have the private > keys, the Bad Guy as a zone administrator will have the private > keys. > > That is, DNSSEC is not secure cryptographically, which is another > reason why not to deploy DNSSEC.
I don't see what your argument here is. DNSSEC is a "PKI in disguise", and like ANY PKI, you still depend on trust up the heirarchy, as that is exactly how a PKI is supposed to work: One level up says something about the levels down. But DNS has ALWAYS depended on trust-up-the-heirarchy anyway, so this aspect of DNSSEC doesn't increase the level of trust required in DNS, it just only codifies it in cryptographic terms so there is no trust (that isn't made explicit) beyond the scope up the heirarchy. This is actually why DNSSEC is useful: it IS a PKI, who's heirarchical nature already matches the existing heirarchy on naming. In the end, signing A records is useless. But signing TXT and CERT records will be incredibly useful, if validated on the end-host application. Additionally, since it would be end-host application validating those signatures, it can enforce that "there must exist a signature path from the root" (aka, it is actually a PKI). [1] But since unless you manually or do some other finagling can't easily establish trust if you don't have trust above, root-servers.net should only sign after .net is signed at this point in the rollout. And any PROPER useage of DNSSEC won't rely on root-servers.net ever being signed at all, because its only on the name path for resolvers. [1] Thus, you don't have to worry about also needing the name path for the resolvers signed or the DOS attack by a MitM stripping signatures as part of their changing DNS results. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
