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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
