Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta <[e-mail]>]

Brian Dickson wrote:

> The difference between this model (client to server transport
> security using IDs) and DNSSEC, is that DNSSEC is resistant to any
> MITM attacks, so long as the resolver's root trust anchor is the same
> as the one published by ICANN/IANA and used to sign the root zone.

Wrong.

If a TLD with its key signed by the root is compromised, which
is a MitM attack, child zones under the TLD are easy victim
of the attack.

Or, if your theory is that we can blindly trust any entity
blessed by ICANN/IANA through some chain as an trustworthy
TTP, then, according to your theory, we can blindly trust
all the ISPs as trustworthy TTPs, because they are blessed
by ICANN/IANA through RIRs, which means there can be no MitM
attacks on ISP chains.

 > I think this is where your argument fails. The trust in DNSSEC is
 > not blind. The validation which is done by a resolver can be
 > confirmed by an end-host, along the entire chain (tree) from root to
 > leaf.

You are totally confused, because I never assumed any compromised
resolver.

 > The validation which is done by a resolver can be
 > confirmed by an end-host, along the entire chain (tree) from root to
 > leaf.

"The validation which is done by a resolver" is not compromised.

I merely mean MitM attacks on some part of the zone chain is
effective both to the resolver and the end-host.


					Masataka Ohta


> 
> In order to achieve complete compromise, the adversary (e.g. state)
> would need to compromise every software stack on every host and every
> resolver, and block access to every external place that could provide
> contradictory results.
> 
> Given that the root trust anchor is public, and published on the
> IANA's web site with all the appropriate protections, this means
> anyone can publish the same information on their own web site, e.g.
> protected by TLS.
> 
> The only way this would not be available to someone under the control
> of that adversary, would be the compromise of every CA's cert, or
> publishing competing certs for every TLS cert in existence, or to
> prevent any access to external sites entirely.
> 
> The notion that a state exercising that level of control would also
> permit the long-enough ID communication to enable your alternative to
> function, does not seem credible.
> 
> This devolves down to two possibilities: your method is not viable if
> the efforts needed to block use of the Root Trust Anchor are
> undertaken; or if the efforts needed to block the Root Trust Anchor
> are not undertaken (in their entirety), attempts to replace the Root
> Trust Anchor are detectable, which also means the real Root Trust
> Anchor can be obtained and validated, and once the latter is done,
> DNSSEC continues to be cryptographically secure.
> 
> The actual real root trust anchor is not feasible to compromise, nor
> are the signing mechanisms involved for signing the root zone. A
> secured root zone and root trust anchor makes it impossible to
> compromise any zone protected by its parent, with the root zone
> anchoring those protections.
> 
> DNSSEC is not blind trust. The ability to compromise via spoofing
> requires compromise of a parent. The root zone cannot feasibly be
> compromised. Therefore DNSSEC is secure.
> 
> I concur with the rest of the folks on this thread, this subject
> thread is effectively concluded.
> 
> This message is mostly for your (Ohta-san's) benefit to understand
> why DNSSEC is not in the same category as WebPKI in terms of the
> trust model and trust mechanisms.
> 
> There is an analogy in infinities: The rational numbers and real
> numbers are both infinite, but the infinity of the real numbers is
> "uncountable", a larger infinity than the infinity of the rational
> numbers, which are "countable".
> 
> Brian
>