Re: [DNSOP] New draft on delegation revalidation

[Shumon Huque <[e-mail]>]

On Thu, Apr 23, 2020 at 7:09 AM Vladimír Čunát <[e-mail]>
wrote:

> On 4/22/20 9:32 PM, Shumon Huque wrote:
> > Since delegation records and glue address records are unsigned, they
> > can be spoofed, and DNSSEC should really allow us to detect such
> > spoofing once a resolver sees referral data.
>
> I wouldn't put much energy into improving this part in *this* draft.
>

No worries! As I said at the DNSOP interim meeting yesterday, we
are *not* planning to take that problem on in this draft at all. That was
more of a side conversation because the topic has come up. You can
also argue that this is not technically a security issue, since the
misdirection
is detected later on. So this is an issue of efficiency and early detection,
that arguably is not critical.

Even DNSSEC-validated NSs and IPs aren't sufficient to ensure privacy,
> so I'd rather kill this problem by proper encrypted protocol towards
> authoritatives (in current dprive charter).
>

DNSSEC of course does not address privacy, that much is clear.
But I don't think I agree that encrypted transport addresses the
data authentication issue here.

In the general case, the DNSSEC security model does not rely on the
security of the authoritative servers themselves, but on the entities
that perform the signing. Encrypted and authenticated transport can
verify that you are obtaining the DNS response unmolested from the
correct authority server, but it doesn't protect you against compromise
of the server itself. DNSSEC protects you against this, if the signing
system is separately secured, as is the case with the DNS root, many
of the TLDs, and many enterprise deployments that use hidden and
inaccessible signing masters.

This is of course not true for the various online signing deployments. In
those cases, transport security is a more complete solution (because
the  signing keys are already exposed at the edges of the authority
server network).

Shumon Huque