Re: [dd] [Ext] Downgrade attack on legacy resolvers and DELEG only delegations

[Edward Lewis <[e-mail]>]

On 2/10/24, 18:16, "dd on behalf of Roy Arends" <[e-mail] on behalf of [e-mail]> wrote:

>    The following situation requires proper handling:
>
>In a pathological case, an adversary has the ability to replay an authenticated denial record that exists at a DELEG-only delegation (note that the NS Type Bit in the Type Bit Maps is not set) to a legacy resolver/validator. In this replay, the RCODE is altered from NOERROR to NXDOMAIN.
>
>It's evident that the delegation is present, as indicated by the DELEG record, but its existence can be falsely negated.
>
>In the typical case, the legacy resolver lacks understanding of DELEG and cannot pursue the delegation. 
>
>It's important to note that this inability to follow the delegation results in a failure scenario (SERVFAIL) that is distinct from an NXDOMAIN response.

The querier sends a request, expecting an answer (data or no), a redirection (CNAME, DNAME) possibly combined with an answer, or a referral with DELEG based on...(what?)...there being a validated DNSKEY resource record with a DELEG flag set.

I mention expecting DELEG because then a DELEG-denial "make sense" if it is validated.

A querier may not be expecting DELEG If the querier does not have DELEG code paths, or if there are DELEG code paths, other factors indicate there is no DELEG record, like validated absence of DELEG-flagged keys.  In this case, a DELEG denial would not be meaningful.  (I used to use the word 'germane' when talking about getting DNSKEY resource records for data from a zone expected to be unsigned.)

In the question above, what authenticated denial is offered?  Saying there is no DS resource record set, no NS resource record set, no DELEG resource record set at a configured name, or that there is no source of data for the name?  If the name is a delegation, then you are ruling out "so source of data" (Name Error/NXDOMAIN).  And if the question states that the name is a delegation there is either an NS resource record set or a DELEG resource record set configured in the authoritative servers.  (Remember caching makes reality fuzzy.)

I guess I don't get what it means to have an authenticated denial record at a delegation point showing a DELEG record but no DS or NS record with a response code of NXDOMAIN.  Perhaps the "next name" is what is being declared "NXDOMAIN", not the name with DELEG.

I don't understand "as indicated by the DELEG record, but its existence can be falsely negated" - unless one has access to private keys, producing valid signatures over data that is misleading is really, really hard.  Replay is somewhat thwarted by the use of inception and expiration times - but due to caching, there's always uncertainty when time is close to one of those or if a record was signed with a regrettable (too far in the future) expiration time.  (You can't undo that.)

If "the legacy resolver lacks understanding of DELEG" then the DELEG resource record set is an unknown type, lacking any NS resource record set, the name is not a delegation point.  (Having a DS resource record set and no NS resource record set outside the apex is a protocol violation.)  In this case, the response would just not make sense to the querier as the DELEG type would not match the QTYPE (unless the QTYPE was DELEG or T_ANY, come to think of it, or any other possible edge matching cases.)

If the querier is unaware of DELEG, then whatever comes back here is going to be taken as an improper protocol response, I would discard it before even applying DNSSEC to it - because the message itself might be a DDoS payload (taking down the querier via making it do a bunch of crypto routines for no benefit).

If the querier is aware, then a replay of an otherwise valid record sets - meaning, once validly signed and temporally current despite the authority having changed their data - can only be solved with the passing of time.  (DNSSEC never had a good certificate revocation list alternative.)

If a querier is a aware and the records are no longer temporally valid, the response ought to be discarded, no attempt to validate (other than to establish the time data), and not result in a SERVFAIL unless a true response never arrives (later on).