[dns-operations] Edge-case, zero-length DNSKEYs
ietf-dane at dukhovni.org
Tue Oct 6 23:20:21 UTC 2020
On Wed, Oct 07, 2020 at 08:22:31AM +1100, Mark Andrews wrote:
> >> They are just malformed. No key material is not permitted with DNSKEY.
> >> it’s one of the differences to KEY.
> > Yes, I am aware they're malformed, my question is whether this then
> > causes problems for various tools and resolvers. Among the major
> > public DNS providers, a DNSKEY lookup returns:
> > * CloudFlare - NOERROR
> > * Google - SERVFAIL
> > * OpenDNS - NOERROR
> > * Quad9 - NOERROR
> > * Verisign - NOERROR
> > So at least Google finds the DNSKEY RRset in question problematic
> > overall, despite the valid ECDSA P256 signature.
> This is where garbage should be rejected as soon as possible. At least
> we won’t have to deal with “but it works with Google” this time.
> Edge-case implies it is something that should be accepted which is why
> I came back the unequivocal malformed.
I wasn't aiming to state a case for accept/reject, though my personal
take is a bit more liberal here, in that while the specific RR is
malformed, I am not sure it should poison the entire RRset. And if a
resolver is happy enough to use algorithm 13, it might not even look at
the algorithm 8 keys.
Which isn't to say that the two zones in question should expect a good
outcome from this configuration. Whichever side of the edge they're
on, this is not a sensible configuration.
When I was writing the server-side code for:
I took care to handle truncated RSA keys without throwing exceptions,
though no examples were present in the database at the time. Now I have
some... :-) Still haven't seen any truncated (long obsolete algorithm
1) "RSAMD5" keys, the naïve keytag calculation for those is even more
likely to run into trouble when the key is truncated.
-- | Compute an RFC 4034 Appendix B key tag over the DNSKEY RData: 16 bit flags,
-- 8 bit proto, 8 bit alg and key octets.
-- With the obsolete algorithm 1 we assign key tag 0 to truncated keys, but
-- RSAMD5 keys are no longer seen in the wild. We check that the modulus
-- actually has at least 3 octets.
keytag :: DnskeyRdataRow -> Word32
keytag rd@(dkdAlgor -> 1) =
if | len > 3
, let elen = fromIntegral $ B.unsafeIndex bs 0
, elen < len - 3
-> hi (B.unsafeIndex bs (len - 3))
+ lo (B.unsafeIndex bs (len - 2))
| otherwise -> 0
bs = dkdValue rd
len = B.length bs
keytag rd@(dkdValue -> bs) =
let len = B.length bs
!z = lo (dkdFlags rd) + hi (dkdProto rd) + lo (dkdAlgor rd)
!raw = foldl' csum z [0..len-1]
!tag = (raw + (raw `unsafeShiftR` 16)) .&. 0xffff
csum :: Word32 -> Int -> Word32
csum !acc !ix | odd ix = acc + lo w
| otherwise = acc + hi w
!w = B.unsafeIndex bs ix
hi, lo :: Integral a => a -> Word32
lo = fromIntegral
hi = flip unsafeShiftL 8 . lo
More information about the dns-operations