Resolving sas.com with dnssec-validation fails though signed delegations seem to be (mostly) correct

[gongsearch]

Not sure if this is really a bug but I would like to note this. Trying to resolve "sas.com" fails with unbound (head) if dnssec-validation is enabled:

2024-01-04T10:40:01 sdb unbound: [898890:1] info: validation failure <sas.com. A IN>: signature for expected key and algorithm missing from 40.120.32.101 for key sas.com. while building chain of trust
2024-01-04T10:40:01 sdb unbound: [898890:2] info: validation failure <sas.com. HTTPS IN>: signature for expected key and algorithm missing from 40.120.32.101 for key sas.com. while building chain of trust
2024-01-04T10:40:01 sdb unbound: [898890:1] info: validation failure <sas.com. AAAA IN>: signature for expected key and algorithm missing from 15.197.178.251 for key sas.com. while building chain of trust
2024-01-04T10:40:01 sdb unbound: [898890:3] info: validation failure <sas.com. A IN>: signature for expected key and algorithm missing from 3.33.177.68 for key sas.com. while building chain of trust
2024-01-04T10:40:01 sdb unbound: [898890:0] info: validation failure <sas.com. AAAA IN>: signature for expected key and algorithm missing from 15.197.178.251 for key sas.com. while building chain of trust
2024-01-04T10:40:01 sdb unbound: [898890:0] info: validation failure <sas.com. HTTPS IN>: signature for expected key and algorithm missing from 3.33.177.68 for key sas.com. while building chain of trust

Checking dnssec-setup with verisign says everything is fine:

https://dnssec-analyzer.verisignlabs.com/sas.com#

Checking against dnsviz.net. As far as I understand there seems to be a valid path and also an invallid path in the trust-chain:

https://dnsviz.net/d/sas.com/dnssec/

For my very limited understanding of dnssec the chain of trust has at least one valid path and for this unbound should resolve - or am I wrong here?

[wcawijngaards]

The failure is exactly the invalid path in the trust chain. This is the option, harden-algo-downgrade: no. The default is 'no' and this makes the lookup work for me, since the trust chain works for one path. If you have the option enabled, this is why it fails, because the option specifically detects this situation, one path has a bad signature, and then fails it for you. Since one trust path has a bogus signature and one trust path has a working signature, there is a choice what to do, more lenient, or more strict. With the option this can be controlled. The default is 'no' for it, and this makes unbound accept the working signature.

I guess the option is enabled in your config. If so, I guess you want to disable the option, since you say you expect the working trust path to be accepted.

[BrianDead]

I've just encountered an issue with this as well, this time with the domain trustwave.com.

The description of this option is:

       Harden  against algorithm downgrade when multiple algorithms are
       advertised in the DS record.  If no, allows  the  weakest  algo-
       rithm  to  validate the zone.  Default is no.  Zone signers must
       produce zones that allow this feature  to  work,  but  sometimes
       they  do not, and turning this option off avoids that validation
       failure.

So with harden-algo-downgrade: no it will allow the weakest algorithm to validate, if the stronger ones are not working. But that would imply that with harden-algo-downgrade: yes it would still validate if the strongest algorithm is working, even if the weaker one is broken.

But in the case of trustwave.com, the working chain appears to be the 'stronger' one using algorithm 13 (an ECDSA algorithm) and the broken chain is the weaker one (RSA-based). However, with harden-algo-downgrade: yes it just refuses to validate at all because of the failure of the RSA chain.

So is this feature really supposed to fail validation on any domain where there is any alternate chain that is broken? Or just to prevent against possible downgrade attacks by preventing injection of a working, weaker chain to validated malicious changes that break the original, stronger algorithm?

[wcawijngaards]

The selection of alternate chains is made by the domain owner, who selects what algorithms to include. The option stops if one of them fails. It does not actually 'score' the algorithms to see which one is stronger and then use that one. How would it be coded to know which one is currently correct? Also a broken signature means that there is then, an attack in progress, even if you think the stronger one is correct, but is maybe correct? Also your opinion on which one is better in this case is a point of view, that may not actually be true. But the option stops for an alternate trust path that fails.

[BrianDead]

Thank you for clarifying. I read too much into the description of the option, which talks about 'the weakest algorithm'. Perhaps it should say 'If no, allows any one supported algorithm to validate the zone, even if other advertised algorithms are broken'.

[wcawijngaards]

The commit fixes the documentation with the explanation. Thank you for improving the documentation!