[dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Viktor Dukhovni]

On Thu, Aug 11, 2022 at 09:56:31PM +0000, Phillip Hallam-Baker wrote:

> Looks to me like there is a serious problem here.

There is not a problem with the specification.  DNSSEC algorithm agility
works when implemented correctly.  Now that DNSSEC adoption is finally
becoming noticeable (though at ~5% of global domains, still far from the
norm), the DNS community is addressing operational issues and ferreting
out the latent implementation bugs.

> NSEC record specifies what is signed but not the algorithm used to
> sign. DNSSEC allows multiple signature and digest algorithms on the
> same zone. If a zone does this, validators are prohibited from
> rejecting records only signed using one of the algorithms rather than
> both.

This is misleading.  If any of the algorithms present in the zone's DS
RRset published in the parent zone are supported by the validating
resolver, then the zone is *signed*, and all authoritative response
RRsets from the zone must be accompanied by a valid RRSIG that chains
back to a valid SEP and is mutually supported by the resolver and zone
signer.  If only unsupported RRSIGs are returned, the response is BOGUS.
Implementations that fail to make that conclusion are in error.

Apparently, bugs in some implementations until recently tolerated
responses that carried only unsupported RRSIGs, erroneously treating
these as "insecure", by failing to require the presence of a shared
supported ZSK algorithm chaining up to a valid SEP.

This was an implementation bug, that can at most charitably be treated
as missing explicit guidance in the specification to do the "obvious
right thing(TM)".  Such explicit guidance can be added in a new
clarification RFC, if deemed appropriate, though my personal view is
that it should not have been necessary.  That said, on the evidence of
the recent implementation bugs, perhaps being needlessly explicit is at
times the prudent thing to do.

> Won’t go into extreme detail here as researcher’s slides will be
> available tomorrow.
> 
> This definitely needs fixing.
> 
> One near term fix is to make SHA-1 a MUST NOT. It is long past its
> sell-by date now.

SHA-1 is not the problem here.  The downgrade issue is equally a problem
with NSEC (which does not use SHA-1) and NSEC3 (where use of SHA-1 for
light obfuscation to discourage zone-walking is just fine), and even for
cases that are not denial of existence at all.  And the problem exists
also for zones signed with only SHA-256 (e.g. algorithms 8 and 13 if
some now rare resolver supports only one and not the other).

The abstract makes no mention of NSEC records or denial of existence:

    In this talk, we show that the cryptographic agility in DNSSEC,
    although critical for making DNS secure with strong cryptography,
    also introduces a severe vulnerability. We demonstrate that
    adversaries, by manipulating the cryptographic material in signed
    DNS responses, can reduce the security level provided by DNSSEC, or,
    even worse, prevent resolvers from validating DNSSEC at all. We
    experimentally and ethically evaluate our attacks against popular
    DNS resolver implementations, public DNS providers, and DNS services
    worldwide. We validate the success of DNSSEC-downgrade attacks by
    poisoning the resolvers: we inject fake records, from our own signed
    domains, into the caches of validating resolvers. Our findings show
    that major DNS providers, popular resolver implementations, and many
    other DNS services are vulnerable to our attacks.

The abstract is IMNSHO misleading.  Agility is not the problem,
incorrect implementation is the problem, though perhaps the requirements
for correctly handling multiple algorithms could have been more clearly
spelled out in RFC 4035, which covers signer responsibility in full
detail, but omits some of the (I claim obvious as a matter of logic, but
it seems still perhaps worth stating explicitly) corresponding
requirements on validators.

-- 
    Viktor.