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

[Simon Kelley]

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



On 18/12/15 13:22, Michał Kępień wrote:
>>> First and foremost, the primary issue of returning SERVFAILs
>>> for zones with DNSKEY RRsets signed using _only_ unknown
>>> algorithms (even though we are able to hash the DNSKEY RRset
>>> and authenticate the DS at the parent) is not resolved.  Quick
>>> example: if you try to resolve anything within a zone signed
>>> using only ECC-GOST keys, with an SHA-256 DS at the parent,
>>> SERVFAIL is still returned as dnssec_validate_by_ds() still
>>> requires the validate_rrset() call for DNSKEY RRset to succeed
>>> for it to return anything else than STAT_BOGUS.  In my patch
>>> which started this thread I tried to demonstrate that if all
>>> DNSKEY RRset validations fail only due to the lack of support
>>> for the _signing_ algorithms used by its RRSIGs, the zone
>>> should be marked as insecure, not bogus.
>> 
>> 
>> Did you test this on a real domain and see a failure? The way
>> it's intended to work is that the call to zone_status() at line
>> 2042 will work down from the root to the DS, where it will find
>> that the SHA-256 DS covers a ECC-GOST key and return
>> STAT_INSECURE at line 1869. That will be returned from
>> dnssec_validate_reply at line 2049, before the call to
>> validate_rrset is even made. dnssec_validate_by_ds() should never
>> be called.
>> 
>> An example of a domain that fails here would be really useful. I
>> did testing by removing algorithms but as there are no rare
>> algorithms it's difficult not to cause early failure of the
>> process before the test case is reached.
> 
> Ah, it seems the bugs were intertwined.  You see, before 14a4ae8
> we could not tell ECC-GOST is not supported until an actual attempt
> was made to call verify() with algorithm 12, so
> dnssec_validate_by_ds() was called for the DNSKEY RRset after
> zone_status() "verified" that ECC-GOST is supported.  With the
> latest master this is no longer the case and the zone is processed
> exactly the way you described above.  Though the algorithm is still
> flawed, see below.
> 
>>> Then there's commit 2dbba34, whose log message says: "A zone
>>> which has at least one key with an algorithm we don't support
>>> should be considered as insecure."
>> 
>> 
>>> That's not right.  Only a zone whose _all_ keys use algorithms
>>> we don't support should be considered as insecure.
>> 
>> No, a zone may have a key we support but records are signed only
>> using the key we don't support.
>> 
>> If a zone has a key of a type we don't understand, than we must
>> accept an insecure answer, (one signed only with the unsupported
>> algorithm) so an insecure result is legitimate for that zone. In
>> the case that the records are actually signed by an algorithm we
>> do support, a secure result is possible and an insecure response
>> is sub-optimal, but it's not wrong.
> 
> Could you please provide a specific example?  Because I believe
> every such zone would violate RFC 4035, section 2.2, which says:
> 
> There MUST be an RRSIG for each RRset using at least one DNSKEY of 
> each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY
> RRset itself MUST be signed by each algorithm appearing in the DS
> RRset located at the delegating parent (if any).

That's very useful, and contradicts what I thought I understood from
our earlier conversation. Given that information, then you're
completely right. The test should return an INSECURE result only of
NONE of the algorithms are supported.
> 
> Assume we authenticated the DS RRset at the parent and that it
> only contains one hash of a key using a supported signing
> algorithm.  That means that the relevant key using that algorithm
> has to be present in the zone apex DNSKEY RRset.  Now, if we create
> another key with an unsupported algorithm and insert it into the
> zone apex DNSKEY RRset, we are free to sign that zone's records
> with it, but we still have to ensure that all records also have an
> RRSIG using the algorithm of the other key.
> 
> Try the following: compile dnsmasq with -DNO_NETTLE_ECC and then
> ask it for the DNSKEY RRset at dnssec-test.org.  You will notice
> that the answer incorrectly lacks the AD bit.  This zone has a
> single DS at the parent, pointing to an RSA/SHA-1 key.  Its DNSKEY
> RRset contains one RSA key (corresponding to the DS) and one ECDSA
> key.  All records in this zone are signed with both keys to fulfill
> the requirement specified by RFC 4035, section 2.2.  As dnsmasq
> supports RSA/SHA-1, why would it treat the whole zone as insecure
> for the sole reason that one of the authenticated DNSKEY RRs is
> using an algorithm it doesn't understand?
> 
> I also noticed that the DS processing loop in zone_status() is
> flawed as well.  It returns STAT_INSECURE whenever it encounters
> even a single hash/signing algorithm it doesn't support.  Why?  If
> there are two or more DS RRs for the same keytag-algorithm pair (so
> only the hashing algorithms are different), why would the zone be
> considered insecure, given that we understand at least one hashing
> algorithm of those used by the DS RRs?

A good point, but made irrelevant by our insight above. That code is
attempting to cover the case that an RRset in the zone may be signed
only by an algorithm we can't understand. Given the 4035 paragraph you
quoted, the actual inference is that if there's a DS with both hash
and sig algos we understand, then we can assmune that 1) we are able
to prove the DNSKEY RRSET is good and 2) we'll find an RRSIG for an
algorithm we understand for any RRset in the zone. The checks after
"if (secure_ds) need to go completely.


> 
> Moreover, I believe we can break out of that loop immediately
> after setting secure_ds to 1 as finding one DS RR whose hashing and
> signing algorithms are both supported is enough to be sure that we
> will be able to attempt validation of at least one of the zone's
> DNSKEY RRs (as long as it actually exists in the zone, of course,
> but we're checking that anyway in dnssec_validate_by_ds()).
> 
> A useful test subject for these issues is the caint.su zone, which
> uses two keys, each using a different algorithm (RSA and ECC-GOST)
> and also provides three separate hashes of each of those keys in
> its parent zone. Using this zone as an example for the reasoning
> above, it shouldn't be considered insecure just because we don't
> understand GOST hashes and/or signing.
> 


That's a good test case, thanks.

> Thanks, as I already stated above, this fixed quite some of the
> problems I observed.

I'll make further changes ASAP and get back to you.


Cheers,

Simon.

> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWdFKEAAoJEBXN2mrhkTWiV6IP/jxUFqsrIjy5tCgjS2U/xxJK
zKpXDHiG/A7l/+AdGZ5XyKTntclF+vjddbegFrfkGAWMekkKVaQAGPEbJxqC8goZ
VzLOSUpPFq8mtgQvMAsTdIA0tTYfj7qT7CnGIonBemx7RzYciv6j8qqDtsAs87jn
9N2Xr94E290gKyOtQP8cVHj1+2Nw7t61tOXnL/b8vJLnNNzANVJHSF3e7eN1vzSs
P655BBJW9UqfDtTlyktlbPALCeAXKnPcvBduCRa+qDy6QOQiUVjkhzVkst/rUhLY
oQGndK+CilF9aLFxkbP2qj4JPrramH2w8DWpXCX9htmUpNmVgMIc6NzxVfwtPCrI
d29hRUWjVrA9YfeLpr2HdqRvyJYKS7VOTx+eB9PeQeEK7J7Ei5NJeqRP1Uz6DfKI
Xs92SON+Y9X7TY6GTzAjTzYPVUFFfDYlcLy8YOKOONfxWDHlhXtg3i+mMhUvI7Nm
EN01LXVMC2ngKRkHFxcFPoiUSamfxhEmID6IhJJH0IV7Uc1sCGxYuzpSNHSo5LjS
5vntwWfoLk9F+ugSHFE1DLD54Z9KevZFJ7O8BrGrLesddPybBKSF9nRY62S5TSZt
8AoJNrfe1Tk6qDcZv+7wfBJ+JXoTAM271s1QuMNz6viyypErJziDG4lhMnTet0Df
rTp4LwukyeZO7G2sEGcJ
=ewuU
-----END PGP SIGNATURE-----