Brian, what you said about the crypto is right but there are definitely opportunities to compromise trust at the tlds. I don’t think it’s wise to ignore this type of attack. However, in order to make such an attack, you have to do things which can be noticed (e.g. signing a zone delegation with a forged key).
So the threat model for a viable DNSSEC attack is quite a bit different than for a recursive resolver attack, and is not something that could be easily effected by a small entity. Or to put it differently, the cost of a successful attack on DNSSEC would be orders of magnitude higher than for an attack on a resolver. And unlike a resolver attack, it is possible to detect a DNSSEC attack by comparing known keys to detect a compromise. With a resolver attack, you have no way to know that you’ve been spoofed. On Tue, Mar 22, 2022 at 22:12 Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > > On Tue, Mar 22, 2022 at 7:12 AM Masataka Ohta < > mo...@necom830.hpcl.titech.ac.jp> wrote: > >> Paul Wouters wrote: >> >> >> 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. >> > >> > I think at this point we have reached a point where your repeated >> > claims lack any merit >> >> So, you ignore diginotar to have demonstrated that PKI to >> blindly trust untrustworthy TTPs is cryptographically >> insecure. >> > > This is where your error is introduced. DNSSEC does not involve blind > trust. > > Previous statements by you (Ohta-san) in this thread, and observations or > counter-points: > > If a resolver correctly knows an IP address of a nameserver of a >> parent zone and the resolver and the nameserver can communicate >> with long enough ID, the resolver can correctly know an IP >> address of a nameserver of a child zone, which is secure enough >> data origin security. >> > > 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. > > It is correct that the single element is a necessary component of the > trust model for DNSSEC. It is not a dependency within DNSSEC that the > endpoint's connectivity must be transport-secured or impervious to hijack. > DNSSEC does not care where the data lives or how it is retrieved. It > protects the data cryptographically. > > The point is that DNSSEC, or PKI in general, is not cryptographically >> secure merely blindly trusting untrustworthy intermediate systems, >> which means it is against the end to end principle, improperly >> called TTPs (Trusted Third Parties). > > > 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. > > 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
