[nab-iha3]

dns.dnssec.validate() with an RRSIG whose signature has extra zero octets inserted before S:

ECDSAP256SHA256 original      64 VALIDATES
ECDSAP256SHA256 zero-padded s 65 VALIDATES
ECDSAP384SHA384 zero-padded s 97 VALIDATES
DSA             zero-padded s 42 VALIDATES
DSA             T changed     41 VALIDATES
ED25519         padded        65 rejected

PublicECDSA.verify slices signature[:octets] / signature[octets:] and PublicDSA.verify slices signature[1:21] / signature[21:], then turns each half into an int, so the length is never checked and leading zeros in S (and the DSA T octet) don't matter. RFC 6605 section 4 fixes the ECDSA signature at 64 or 96 octets, and RFC 2536 section 3 fixes DSA at 41 octets with T matching the key. The result is that RRSIG signatures are malleable, and dnspython accepts signatures that conforming validators reject. EdDSA and RSA are already strict because cryptography checks the length for them.

Both verify methods now raise InvalidSignature on a bad length (and on a mismatched T for DSA). _validate_rrsig already catches that exception. I added tests to tests/test_dnssecalgs.py, a whatsnew note, and RFC 2536 to doc/rfc.rst.