[dns-operations] [dnsext] BlackHat Presentation on DNSSEC Downgrade attack

Viktor Dukhovni ietf-dane at dukhovni.org
Fri Aug 12 03:40:21 UTC 2022


On Thu, Aug 11, 2022 at 07:31:04PM -0700, Phillip Hallam-Baker wrote:

> Looks like the 'downgrade attack' is actually a consequence of the fact
> that support for multiple algorithms means that you end up with the
> security of the weakest. So not really an 'attack' but a consequence of the
> design approach not considering the downgrade issue worth addressing
> because people should not be signing under multiple algorithms for very
> long.

No, the downgrade in question is not from a stronger algoritm to a
weaker (generally accepted, because multi-algorithm signed zones are a
short-term affair), rather, it is a downgrade from "signed" to
"unsigned", which is a serious implementation error.  The paper's
authors did not break any crypto, they just sent replies that some
implementers failed to anticipate (for plausible lack of clear explicit,
however obvious it should have been, advice in RFC 4035).

> But given that, I think we are long past the time when anyone is doing
> anything of the slightest value signing with SHA-1. There is no reason to
> pick SHA-1 over SHA-2. You are not going to improve interop, you are much
> more likely to harm it. So moving SHA-1 to MUST NOT seems like the way to
> go.

Again, SHA-1 has nothing to do with this.  It is already NOT RECOMMENDED
(i.e. SHOULD NOT) for signing:

    https://stats.dnssec-tools.org/explore/?ietf.org
    https://www.rfc-editor.org/rfc/rfc8624#section-3

but still a MUST for validation.  The numbers have improved a lot since
the RFC was published, see the algorithm counts under "DNSSEC parameter
frequency analysis" at:

    https://stats.dnssec-tools.org/

but we're not quite there yet:

    https://stats.dnssec-tools.org/explore/?nsa.gov
    https://stats.dnssec-tools.org/explore/?icann.org
    ...

-- 
    Viktor.


More information about the dns-operations mailing list