[Dnsmasq-discuss] [PATCH] Treat records signed using unknown algorithms as unsigned instead of bogus

[Michał Kępień]

> Caveat. I'm not sure what the answer is. I'm certainly not arguing for a
> fixed interpretation, not even the current behaviour of dnsmasq, and I'm
> trying to understand what the correct behaviour should be. As always,
> I'm terrified of breaking people's DNS by rejecting something that's OK,
> and I'm also terrified or creating a security hole by accepting a answer
> that's actually an attack which should be rejected.

I understand your position and I think that this is a fine approach.

> The difference between unknown DS hashes, and unknown signature is as
> follows, as best I understand it. In the DS case, we have a DS RRset
> which is signed, and validated. We know it has been signed, and it says
> that a key in the child zone has some hash value, for some algorithm we
> don't support. The DS RRset is signed, so we know it's not a forgery. We
> can therefore be sure that there really is no way for us to validate the
> DNSKEY RRset in the child zone, because of the actions of whoever has
> the private key which signed the DS RRset.

Yes, I agree.

> Next stage, assume that the hash value for one of the DNSKEYS in the
> child zone is correctly given by the DS record, but the signature
> algorithm for the DNSKEY RRset is unknown to us. We have no way of
> validating the DNSKEYs. We know that the DNSKEY which matches the hash
> in the DS is good, but the others may be impostors. Indeed an attacker
> may have given us an answer with one good DNSKEY (matching the DS hash)
> and another DNSKEY for a non-implemented algorithm. If we use the rule
> that non-implemented algorithm -> insecure, then that's enough for an
> attacker to ensure that any zone becomes insecure, and records are
> returned by the validator.

No, I don't think so.  For the signature of the DNSKEY RRset to be
validated, it would need to be generated using the private counterpart
of the key whose hash has been published in the DS record in the parent
zone.  RFC 4035 section 5.2 lists three prerequisites for authenticating
a DNSKEY RRset, the last of which is:

    The matching DNSKEY RR in the child zone has the Zone Flag bit set,
    the corresponding private key has signed the child zone's apex
    DNSKEY RRset, and the resulting RRSIG RR authenticates the child
    zone's apex DNSKEY RRset.

So taking a valid DNSKEY record, adding a different one with a bogus
algorithm and signing such a set with the private counterpart of the
bogus algorithm key is not enough for a properly operating validator to
authenticate such a set.

If you feel I am misunderstanding your argument or missing something, I
would be grateful if you could provide further explanations.  Thanks for
bearing with me :)

-- 
Best regards,
Michał Kępień