Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta <[e-mail]>]

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