Re: [DNSOP] DNSSEC as a Best Current Practice

[Masataka Ohta <[e-mail]>]

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

Technically, yes, but, socially, no, not at all.

It can be practically possible only if ISPs employees are socially
compromised, which is criminal, or the ISP is ordered to do so
by government.

The problem of DNSSEC, or PKI in general, is that, assuming such
attacks, it is equally easy to socially compromise a zone with
DNSSEC signature.

It's pretty easy to forge certificates.

Never rely on untrustworthy TTPs.

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

Technically, maybe, but, socially, it is not detectable at
least legally, if such detection is defined to be (may be
criminally) unlawful.

> The way to detect them
> is to notice these forcibly injected certificates based on the public keys
> presented in them.

And you can be arrested.

It should be noted that google's attempt to statically install
some certificate in their browser is subject to MitM attacks
on employees of google or distribution chain of the browser.
Moreover, such software may be legally banned by some government.

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

Because security by PKI including DNSSEC is not end to end, it is
impossible to detect security breach so quickly.

Or, can you improve DNSSEC to instantly invalidate compromised zone
information, which is impossible with slowly acting CRLs.

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

Socially, having long enough message IDs is as secure as DNSSEC.

> So although DNSSEC is complicated,

That is because authors of the original specification of DNSSEC
ignored my comments (at that time, I was not aware of fundamental
lack of security of PKIs), as a DNS expert having enough knowledge
on PKI, to make it highly compatible with existing DNS.

As a result, DNSSEC was modified to be so complicated trying to
incorporate my earlier comments in ugly manners.

> and it's easy to talk about simpler
> solutions,

For me, it was, has been and still is easy.

						Masataka Ohta