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

[Simon Kelley]

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



On 08/12/15 09:51, Michał Kępień wrote:
>> I wish I was on firmer ground than I am in arguing this.
>> Nevertheless, if we keep going, we might be able to reach the
>> conclusion.
>> 
>> 
>> Let's start with a concrete example:
>> 
>> srk at holly:~/dnsmasq/dnsmasq$ dig @8.8.8.8  +dnssec isc.org
>> 
>> ; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @8.8.8.8 +dnssec isc.org 
>> ; (1 server found) ;; global options: +cmd ;; Got answer: ;;
>> ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19706 ;; flags:
>> qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;;
>> QUESTION SECTION: ;isc.org.			IN	A
>> 
>> ;; ANSWER SECTION: isc.org.		3	IN	A	149.20.64.69 isc.org.		3	IN
>> RRSIG	A 5 2 60 20151231222650 20151201222650 6003 isc.org.
>> j+b9GkjJBbzEi9tw6205EUqry+RC/7X2fjRHfB1KKxRXIMKj34h3RtY5 
>> ng77uzNJ22qyTwXxboiqMkTYoSCD0l3hFwwrv/SDDneri+VKwN5wwxDA 
>> 5A75h03KfMxubg6N4cBDHHhWUp1Nim9pwge9xy3AUGorugA+WP0wvAfA iq0=
>> 
>> ;; Query time: 65 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN:
>> Wed Dec 02 15:50:11 GMT 2015 ;; MSG SIZE  rcvd: 219
>> 
>> specifically
>> 
>> RRSIG A 5 2 60 ......
>> 
>> which says that this is a signature for algorithm type 5
>> (RSA/SHA-1)
>> 
>> to verify that this record is good we need the DNSKEY for
>> isc.org, which provides the public key. Public key/hash of
>> data/signature and we're good to go.
>> 
>> Now assume instead that we get a reply including as signature.
>> 
>> RRSIG A 100 2 60 ......
>> 
>> algorithm type 100! Can't verify that signature.
>> 
>> Now, if at this point there are three possible things to do. 1)
>> BOGUS, return SERVFAIL. - the current dnsmasq behaviour. 2) do no
>> further checking, return the reply, without an AD bit. 3) Attempt
>> further checks on the DNSKEY with algo 100 and return answer 
>> without AD bit is that pass.
>> 
>> Option 2 is what worries me. It allows an attacker to provide an
>> answer which will be returned to the original requestor, and
>> which will likely be used, even if the AD bit is not set.RRSIG A
>> 5 2 60 ......
>> 
>> Option 3 seems the way to go, but what checks should be made?
>> That the DNSKEY for algo 100  exists?
> 
> Yes, that it exists within the (authenticated) DNSKEY RRset at the 
> zone's apex (for the example above: at isc.org. IN DNSKEY).
> 
>> That's easy to spoof too.
> 
> How so?  For the DNSKEY RRset to be authenticated, it has to be
> signed using the private key whose public counterpart's hash is
> exported into the DS record in the parent zone, which itself has to
> be signed by the parent etc.  If an attacker inserts a rogue key
> into the DNSKEY RRset, the latter needs to be signed with the
> correct private key.  Returning _only_ a signature made using a
> bogus algorithm (different than the one given in the DS record)
> along with the malicious DNSKEY RRset is not enough for the latter
> the be authenticated, so such responses should definitely result in
> a SERVFAIL as they are likely a spoofing attempt.
> 
> However, if the zone's "righteous owner" decides to sign its
> DNSKEY records using only algorithms the resolver does not
> understand, the latter will learn that it won't be able to
> authenticate the DNSKEY RRset the moment it checks the algorithms
> given in the DS record in the parent zone.  That should _not_ cause
> a SERVFAIL, because the chain of trust is intact.  Instead, that
> zone's records should be returned without the AD bit set.
> 
>> That it exists and is validated by a DS record? That seems more
>> hopeful. Maybe that's the fix?
> 
> RFC 4035, section 5.3.1 says that for any RRSIG in the zone to be 
> considered authentic:
> 
> ...
> 
> o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields
> MUST match the owner name, algorithm, and key tag for some DNSKEY
> RR in the zone's apex DNSKEY RRset.
> 
> ...
> 
> Note that this authentication process is only meaningful if the 
> validator authenticates the DNSKEY RR before using it to validate 
> signatures.  The matching DNSKEY RR is considered to be authentic
> if:
> 
> o  the apex DNSKEY RRset containing the DNSKEY RR is considered 
> authentic; or
> 
> o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset
> itself, and the DNSKEY RR either matches an authenticated DS RR
> from the parent zone or matches a trust anchor.
> 
> So for the example above, if the resolver receives an A RRset along
> with an RRSIG using algorithm 100 and keytag X, it has to check
> whether there is a DNSKEY RR using algorithm 100 and keytag X in
> the DNSKEY RRset at that zone's apex.  If there is (and the DNSKEY
> RRset is authenticated and the resolver does not understand
> algorithm 100), the response should be returned without setting the
> AD bit; if there isn't, that is a possible spoofing attempt which
> should elicit a SERVFAIL.
> 
> As always, if anything I wrote above is not clear (or you believe I
> am wrong), I will be happy to discuss this further.
> 

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?

Cheers,

Simon.



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

iQIcBAEBCAAGBQJWaBKPAAoJEBXN2mrhkTWisJIP/Rv4Lx4pYKE+1lpBdbpGuegp
btME4eEN8J8fZiN4S3cQSc3LnJ/KmkmlC/kHEkNKNkOsM0Jk0ZSl+92H5dL90LlW
rDNkmPlFclW2ORsu5cMbsyMGYn082pkJz1JihRzgXCPEKHg4fLciGU3FBqzecA80
NrsH+ISiLhcva2rSVuF4N3I6gr6A3d6ov9clhCBBgg06/JokEfaRmWm+LNUZmiq2
7AJlas4trtF5UMOiBStIc3Q7CnaEHjBy695Y+fSvB2umFMW1UpIXkOD2R7nGgFQ4
7nJ2/YPzirlTYecV2UKNJyQ7ltrn3fdtL3mf23BHkz2wW2ea9SQadzg6YE0Rgul/
rpWwhMI7r0x0dlD61FHESFF4kprOkyhgbFhLBAK7xEsGmAktxceYdOGav+zxgWis
AMs6J02pNqs5hqvQy3l9iAf1UaYi7zdWuUgLrtCPx1zsOmZ/c9KTWlWJSiulgu01
Q69ypFsfKMplPM/5++GIP8hNzB1FsnGNbWBAjOrbhv7p5WDsUFoBKXFGhq3p/c60
AhQOusFhfvBzqN1ggXnSpx8biiN5PPySRFlhqWwhNdM4hoJnZrRljyX5KY9AeXfa
mE9KYL19WS4wpVFDflkCa8/c1vZCwCaqd1clY4qrXMrYHYqxKoi5K8jtqmOQaQS/
njvzG/sjkxad+gkMIXDv
=szfb
-----END PGP SIGNATURE-----