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

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OK. Fixing this turned into a marathon re-write session. The result is
a huge improvement: by doing the core things right I've vastly
simplified the code and made it much easier to understand and modify.

The final patch, to make a zone which has a valid key of an
unsupported algorithm count as insecure, even if also has a key with a
supported algorithm which is validated by the DS record, Just went in.
It's gratifyingly small and simple.

All the new code is in the git repo. Please test and play.


Cheers,

Simon.

On 09/12/15 12:32, Michał Kępień wrote:
>> This is starting to make much more sense to me now.
>> 
>> 
>> It seems to me that there may be a very simple way to implement
>> this, which is to simply disregard signatures for unknown
>> algorithms. Thus the answer is treated in the same way as an
>> unsigned answer: proof is sought that the zone is unsigned. At
>> the moment this is done by looking for proof of absence of a DS
>> record (NSEC or NSEC3). Extending this to aceept a validated DS
>> record with unknown hash or unknown algorithm make things work in
>> this case.
>> 
>> Later: there may be a problem with the above, under the
>> following circumstance.
>> 
>> 1) The DNKEY RRset contains at least two keys: one for a known 
>> algorithm and one for the unknown algorithm in the original
>> answer.
>> 
>> 2) The DNSKEY RRset is signed using the known algorithm.
>> 
>> 3) The key for the known algorithm is validated by the hash of
>> the corresponding DS record.
>> 
>> My test above would fail to determine that an unsigned answer
>> was legitimate under such circumstances and needs to be extended
>> to account for that case.
>> 
>> Sound reasonable?
> 
> Yes, I agree with everything you wrote above.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWcWujAAoJEBXN2mrhkTWie5AP/3anS91bgJgh7O8KsaAllr7p
/pxGnoovQiF0kLXk3BcpHmcg8No8KiVXMWSZivVVfshwoGT38Ur8++oDgIzXe7ov
vRoGTT4eheYnB0eFKBDROABJ8hz2NnsYGmRrdD2x1iYct/2HIG13ZVqf8hKiPMZl
H6San+izMkqAPn4rFDLFjIMM3FRNdcNiK+1r7dU0vOM3Dbdl2R51orEIBPDCtkVI
N1B77U8tvBIXIkqcVNzBZpVIMX5ZWOmAqOfprc4Yi8ZIHcEDy+m+VQHEq5Z+5nY5
zKe0Xduj1bdLavVLs1aNRwVDi25k3DfilQtQSB71HXqF8NS/6j3qrP2bYi6SNex6
l2hS3aNxmtlQm3XxjkrLGGf5I5Gtywo7jzV0J2BvVML0qFHecU65Lo3Nd9yPXCAG
EY4rKhiZCP8wQ8gQMo8DzJsztjaIBi/eHOAjG+3HcW/rL7d/15HQPcgngV8xgeai
uBBmvF0qbKLD4Wd+u6/jbbkB1WKrrydxnmwP2a9O+nJKdQVpj1J8xQvwgFcB4mdu
WyGLOcu1YFKEq6OdIv9ZbtqCH3k4bMNulzLD2eygRTilP9wLBRbjw/UEAIOwBzuL
stEk2SC34X7Nrgh7mhaGA8Xk+b71EFCHutY/SLh/sswpRPCnvW+8FRw74MovehKU
MpW1YYKfIHu1m5IWDdR6
=AM8C
-----END PGP SIGNATURE-----