Joe Abley wrote:
As I wrote "rely on DNS cookie or something like that", an example
is in rfc7873.
Could I perhaps summarise what you're saying as follows?
1. The cost of DNSSEC signing is high, e.g. due to increased
complexity, brittleness of the DNS, perhaps as shown by relatively
low demonstrated system-wide deployment;
No, cost of DNSSEC is high because PKI, in general, is against
the end to end principle, which automatically means that
it is not cryptographically secure, actually because it blindly
depends on untrustworthy TTPs.
If we can be secure by just declaring some third parties not
under control of the first or the second party are trustworhy,
we can just declare that all the third parties of ISPs between
the first and the second, even with BGP route attacks, parties
are trustworthy.
2. The threats that DNSSEC protects against are not high-probability
threats, especially following the adoption of various
resolver-hardening techniques adopted following the late Dan
Kaminsky's various observations;
Partially yes, because DNSSEC is not cryptographically secure.
3. The threats that DNSSEC protects against are not high-impact
either since they affect one layer amongst many for most
applications;
No, MitM attacks on CA chains has as high or low impact as
MitM attacks on ISP chains.
4. Protocols and applications that depend on cryptographic assurances
in the DNS (DNS as PKI)
Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.
5. The cryptographic assurances in DNSSEC
No, there is no such assurances.
6. Better to avoid the cost of DNSSEC deployment
For no security improvement beyond plain DNS with long enough message
IDs? Yes.
Masataka Ohta
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
