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

[Mark Andrews]

> On 7 Oct 2020, at 10:20, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> 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.

If it doesn’t poison the entire RRset then *everything* that touches the
RRSET has to handle malformed records.  The zone parser has to accept
them, think secondary servers.  The parser needs to differentiate between
primary and secondary rolls.  You have to ensure that the validating
code properly handles them.  You need to be able to write them out.
You need to write test code for all of this.

DNSSEC is complicated enough without having to handle malformed records
like this.

> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org