[dns-operations] Edge-case, zero-length DNSKEYs

[Viktor Dukhovni]

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[1] for:

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

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.

-- 
    Viktor.

[1]

-- | 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
  where
    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
     in tag
  where
    csum :: Word32 -> Int -> Word32
    csum !acc !ix | odd ix    = acc + lo w
                  | otherwise = acc + hi w
      where
        !w = B.unsafeIndex bs ix

hi, lo :: Integral a => a -> Word32
lo = fromIntegral
hi = flip unsafeShiftL 8 . lo