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

[Simon Kelley]

On 25/11/15 07:40, Michał Kępień wrote:
>> Caveat. I'm not sure what the answer is. I'm certainly not arguing for a
>> fixed interpretation, not even the current behaviour of dnsmasq, and I'm
>> trying to understand what the correct behaviour should be. As always,
>> I'm terrified of breaking people's DNS by rejecting something that's OK,
>> and I'm also terrified or creating a security hole by accepting a answer
>> that's actually an attack which should be rejected.
> 
> I understand your position and I think that this is a fine approach.
> 
>> The difference between unknown DS hashes, and unknown signature is as
>> follows, as best I understand it. In the DS case, we have a DS RRset
>> which is signed, and validated. We know it has been signed, and it says
>> that a key in the child zone has some hash value, for some algorithm we
>> don't support. The DS RRset is signed, so we know it's not a forgery. We
>> can therefore be sure that there really is no way for us to validate the
>> DNSKEY RRset in the child zone, because of the actions of whoever has
>> the private key which signed the DS RRset.
> 
> Yes, I agree.
> 
>> Next stage, assume that the hash value for one of the DNSKEYS in the
>> child zone is correctly given by the DS record, but the signature
>> algorithm for the DNSKEY RRset is unknown to us. We have no way of
>> validating the DNSKEYs. We know that the DNSKEY which matches the hash
>> in the DS is good, but the others may be impostors. Indeed an attacker
>> may have given us an answer with one good DNSKEY (matching the DS hash)
>> and another DNSKEY for a non-implemented algorithm. If we use the rule
>> that non-implemented algorithm -> insecure, then that's enough for an
>> attacker to ensure that any zone becomes insecure, and records are
>> returned by the validator.
> 
> No, I don't think so.  For the signature of the DNSKEY RRset to be
> validated, it would need to be generated using the private counterpart
> of the key whose hash has been published in the DS record in the parent
> zone.  RFC 4035 section 5.2 lists three prerequisites for authenticating
> a DNSKEY RRset, the last of which is:
> 
>     The matching DNSKEY RR in the child zone has the Zone Flag bit set,
>     the corresponding private key has signed the child zone's apex
>     DNSKEY RRset, and the resulting RRSIG RR authenticates the child
>     zone's apex DNSKEY RRset.
> 
> So taking a valid DNSKEY record, adding a different one with a bogus
> algorithm and signing such a set with the private counterpart of the
> bogus algorithm key is not enough for a properly operating validator to
> authenticate such a set.
> 
> If you feel I am misunderstanding your argument or missing something, I
> would be grateful if you could provide further explanations.  Thanks for
> bearing with me :)
> 


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? That's easy to spoof too. That it exists
and is validated by a DS record? That seems more hopeful. Maybe that's
the fix?

Cheers,

Simon.