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

Michał Kępień michal.kepien at nask.pl
Tue Dec 8 09:51:58 GMT 2015


> 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.

-- 
Best regards,
Michał Kępień



More information about the Dnsmasq-discuss mailing list