Subject: [DNSOP] Inconsistency in validator behavior vs. downgrade attacks

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 18 Feb 2015 23:50:46 +0530

Hi all

This came up after a thread by Stephane Bortzmeyer on the bind-users@
list. There seems to be an inconsisteny in how a validator should behave
in following authentication chains vs. avoiding downgrade attacks.

Consider the following:

1.  RRSIGs are required from every DNSKEY algorithm type, and one of its
    effects is to prevent downgrade attacks. This is not mentioned as
    the reason for it in RFC 4035 sec. 2.2, but a follow up RFC
    introducing RSASHA256 presents a case for it (RFC 5702 sec. 8.2).

2. Matching DNSKEYs in child for every DS algorithm type in parent are
   not required in validator requirements to allow them to be more
   accomodating with configuration mistakes. This doesn't give
   importance to the possibility of downgrade attacks as much as
   allowing validation to succeed through any chain. The possibility of
   downgrade attacks are mentioned in RFC 4509 sec. 6.1, but nothing is
   done towards avoiding it.

3. DS digest selection prefers digest SHA-256 even though an
   authentication chain may not exist through that path, while a
   successful chain may be available through digest SHA-1. This doesn't
   give importance to the possibility of allowing validation to succeed
   through any chain as much as preventing downgrade attacks. See RFC
   4509 sec. 3.

Items (2) and (3) are inconsistent against each other in accomodating
some chain of validation to succeed vs. avoiding downgrade attacks.

As an example, consider the attached PNG image generated by DNSviz for
the case that Stephane Bortzmeyer emailed about on bind-users@.

In this image, there are two DS RRs for "cepn.asso.fr." in the "fr."
zone:

cepn.asso.fr. DS alg=5 digest_type=2 <digest>
cepn.asso.fr. DS alg=8 digest_type=2 <digest>

This is a mis-configured zone on the authoritative server for zone
cepn.asso.fr.  There is only the DNSKEY matching alg=5 in the child
zone, and no DNSKEYs to match the other DS with alg=8.

Validation into the cepn.asso.fr. zone succeeded in DNSviz (~ the green
outlines; ignore the exclamations which report warnings) and was also
successful via BIND. This is because BIND allowed the chain through the
alg=5 DNSKEY, because both DS digests were of digest_type=2.

Now consider the case where the DS RRs in the parent had different
digest types:

cepn.asso.fr. DS alg=5 digest_type=1 <digest>
cepn.asso.fr. DS alg=8 digest_type=2 <digest>

Here, there is still a valid authentication chain path through the
DNSKEY for alg=5, but it is completely abandoned in favour of pursuing a
chain through the DS RR with digest_type=2 for DNSKEY with alg=8, but
this DNSKEY is not present in the child zone.

The validator is not so accomodating in this case. The two cases seem
inconsistent with each other. One would expect any one of the following
outcomes:

(1) DS RR with digest SHA-256 to be picked over DS RR with digest SHA-1
    if the algorithms and tags were equal, i.e., accomodating, OR

(2) DS RR with digest SHA-256 is always picked over DS RR with digest
    SHA-1, and DS RR with algorithm RSASHA256 is always picked over DS
    RR with algorithm RSASHA1, i.e., avoiding downgrade attacks. In this
    case, validation would not succeed if the corresponding DNSKEY
    doesn't exist at the child.

		Mukund

---

From: Tony Finch <[email-masked]>
Date: Thu, 19 Feb 2015 10:41:15 +0000

>    done towards avoiding it.

I would have thought that mistakes are not the concern here: surely you
have to allow a mismatch between algorithms in parent and child to support
algorithm rollovers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay, Southeast Fitzroy: Variable 4, becoming southwesterly 5 or 6.
Rough or very rough. Fair. Good.

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 19 Feb 2015 16:49:36 +0530

Hi Tony

> have to allow a mismatch between algorithms in parent and child to support

Is there a need for a DS RR to be dangling at the parent (i.e., not
pointing to any available DNSKEY at the child) during algorithm
rollovers?

Matching DNSKEY in child for every DS algorithm type in parent is a MUST
requirement for auth servers (RFC 6840 sec. 5.11). It's just not a
validator requirement.

		Mukund

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Feb 2015 12:50:28 +0000

Not Tony, but a partial reply from me:

>pointing to any available DNSKEY at the child) during algorithm

“Need” isn’t the right question.  However, there are some, even TLDs, that
seem to have chosen to pre-publish DS records for DNSKEYs.  These cases
are same-algorithm though.

>requirement for auth servers (RFC 6840 sec. 5.11). It's just not a

Yes, or a client wouldn’t be able to determine whether someone stripped
something out.

If a client can trust (meaning has an implementation of the algorithm)
used at the parent, they can trust what the child has - whether the client
can deal with the child’s algorithm or not.  So if the parent says the
child has an algorithm the client can use but the child doesn’t have it -
the client SERVFAILs.  If the child can’t deal with any of the
parent-reported child algorithms, the client can choose to downgrade to
unsigned, downgrading ‘securely.’

Hope that’s clear enough, I haven’t had breakfast yet.  (Empty stomach
typing is always more hurried.)