Re: [DNSOP] DNSSEC as a Best Current Practice

[Ted Lemon <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On Tue, Mar 22, 2022 at 7:12 AM Masataka Ohta <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>