Re: [DNSOP] DNSSEC as a Best Current Practice

[Ted Lemon <[e-mail]>]

On Mon, Mar 21, 2022 at 9:02 AM Masataka Ohta <
[e-mail]> wrote:

> 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.
>

It's pretty easy to intercept all packets destined for a particular IP
address and spoof the responses.

IETF can do nothing if some government legally force
> people to install some government provided certificates
> to some PKI, including DNSSEC, which is as easy as
> MitM attacks on ISP chain may be by government order.


Attacks of this nature are in principle detectable. The way to detect them
is to notice these forcibly injected certificates based on the public keys
presented in them. Of course, you need to have a source of truth, and
nothing is perfect, but also, the best is the enemy of good enough. There's
been plenty of discussion and research on the topic of how to notice that
forged certificates are being presented. What I don't see happening (maybe
I'm missing it) is this stuff being deployed in the real world.

As for using "something like cookies" to secure the communications channel,
this is functionally the same problem as noticing that certificates have
been forged, but gets you a lot less benefit in practice, because you have
to have a secure channel to each thing you want to be able to validate, or
else you have to have  a server that is able to do such validation for you
and a secure channel to it (which amounts to the same thing).

So although DNSSEC is complicated, and it's easy to talk about simpler
solutions, whenever you dig into the details, what you find is that either
they don't actually deliver what DNSSEC delivers, or else they wind up
being more complicated and harder to operate. Security doesn't come for
free.