Subject: [DNSOP] If DNSSEC signatures do not validate ...

From: Davey Song <[email-masked]>
Date: Tue, 28 Apr 2020 21:10:46 +0800

Hi folks,

As far as I know, in DNSSEC the validating resolver is able to identify a
Bad response if signatures do not validate. But it unable to retrieve the
good one for stub resolver if there are other alternatives.

I'm thinking about a draft proposal if signatures do not validate, the
validating resolver can try other resolution path like DoT or DoH directly
to authoritative servers or other public DNS servers which open the DNS
encryption service. It aims to  work around the resolution path where DNS
hijack happened.

Do you think it is a good idea? or a useful use case for DNS encryption in
DNSEEC?

Best regards,
Davey

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Apr 2020 09:34:36 -0400 (EDT)

On Tue, 28 Apr 2020, Davey Song wrote:

> As far as I know, in DNSSEC the validating resolver is able to identify a Bad response if signatures do not validate. But it unable to retrieve the good
> one for stub resolver if there are other alternatives. 

I think you mean if you receive a BOGUS validation result (eg missing
RRSIG records, or otherwise are not getting the records needed for proof
of non-existance or signatures. In that case, I think the existing
DNS protocol already tells you to try other servers?

> I'm thinking about a draft proposal if signatures do not validate, the validating resolver can try other resolution path like DoT or DoH directly to
> authoritative servers or other public DNS servers which open the DNS encryption service. It aims to  work around the resolution path where DNS
> hijack happened. 

This looks exactly what the ADD working group is working on? The only
difference is instead of prefering some more private mechanism, you
only prefer the more private mechanism upon some failure case? And
I think that really comes down to the original politics of who decides
where and when to not use the local resolver. And we are already in
a heavy stale-mate there.

Paul

---

From: Davey Song <[email-masked]>
Date: Tue, 28 Apr 2020 21:48:12 +0800

> DNS protocol already tells you to try other servers?

According to RFC4035 section 5.5, there is  no retry to other servers.

> This looks exactly what the ADD working group is working on?

Thanks. I will check that.

The only
> only prefer the more private mechanism upon some failure case?

I prefer current infrastructure already deployed.

Davey

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Apr 2020 09:56:44 -0400

> According to RFC4035 section 5.5, there is  no retry to other servers.

That language could probably use some clarification. I would interpret
"if .. none of the RRSIGs can be validated" as "if .. none of the RRSIGs
can be validated from _any_ of the authority servers". In practice, every
validating resolver I'm familiar with will retry other servers upon
signature
validation failure. Otherwise, we would have a very fragile system - an
adversary would just have to be able to intercept one path between resolver
and one of the authority servers for a zone to cause resolution failure.

Shumon.

---

From: Davey Song <[email-masked]>
Date: Tue, 28 Apr 2020 22:22:18 +0800

> validation failure.

OK. It make sense to try every name servers to defend the case if the
adversary only intercept one path. But the adversary also know the resolver
will retry other servers. So a smarter adversary may intercept in the
aggregated upstreaming path where all queries are sent.

Otherwise, we would have a very fragile system - an

Davey

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Apr 2020 11:22:20 -0400 (EDT)

On Tue, 28 Apr 2020, Davey Song wrote:

> OK. It make sense to try every name servers to defend the case if the adversary only intercept one path. But the adversary also know the resolver will
> retry other servers. So a smarter adversary may intercept in the aggregated upstreaming path where all queries are sent. 

Then those adversaries that seem able to block any packets from reaching
you, can also block 8.8.8.8 and all known DoT and DoH servers by IP ?
And send you RST packets.

But if the attacks have that much power, they can also just RST all your
TLS connections to webservers and just let let you have your DNS
packets.

I think you need to be a little more exact on the attack you are
describing and what would be a sensible defense.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Tue, 28 Apr 2020 11:50:07 -0400

On Tue, Apr 28, 2020 at 11:22 AM Paul Wouters <[email-masked]> wrote:

> will
> > retry other servers. So a smarter adversary may intercept in the

+1

Davey - if there is a pervasive/omnipresent man-in-the-middle attacker,
then no security protocol (DNSSEC, TLS, HTTPS or any other) can
_prevent_ the attack. All they can do is to _detect_ that an attack is
taking
place (and probably abort).

Shumon.

---

From: Davey Song <[email-masked]>
Date: Tue, 28 Apr 2020 23:53:28 +0800

> place (and probably abort).

Fair enough.

Davey

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 29 Apr 2020 21:56:14 -0400

I think this would be a reasonable behavior for a "hybrid stub/recursive".
I would think about it as a performance optimization, allowing a recursive
resolver to avoid recursion if it can get the answer from another recursive
instead.

There are many other possible hybrid behaviors too, such as racing the stub
and recursive resolution processes.

Instead of describing this particular behavior, it might be more helpful to
attempt a general description of requirements on hybrid resolvers, i.e. a
set of requirements that apply to stubs, recursives, and everything in
between.

On Tue, Apr 28, 2020 at 11:54 AM Davey Song <[email-masked]> wrote:

>> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>