[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNSSECbis Q-2: degradation attack

At 12:36 2003-08-13, Sam Weiler wrote:

This grew out of Q2 discussions (re: moving DSA to optional).  I like
the idea of moving DSA to optional (it's a weak liking -- I don't
care that much), but we need to address the following first:

A degradation attack is possible when multiple algorithms appear in an
apex DNSKEYset and/or DSset.  If not fixed, this attack will make new
(or optional) algorithms undeployable.  First, the proposed change
that avoids the attack:

   Every RRset MUST be signed by at least one DNSKEY of each algorithm
   in the DSset and each additional algorithm, if any, in the apex
   DNSKEYset.  The apex DNSKEYset itself must be signed by each
   algorithm appearing in the zone's DSset.

IMHO this is an overkill and is restricting operation too much.
What this is saying is if there is more than one alg in DS set then
every RRset MUST be signed by all the algorithms at all times.
How is this to be enforced ?
We can not enforce this is in a signer, as someone may elect to implement
algorithm independent signers.
Should the master server can refuse to load zone that violates this
for a single RRset?
(Current protocol document does not say what to do if a master server
sees an unsigned RRset in a secure zone).

The basic premise for DNSSEC has been: if validator can verify RRset
against ONE temporarily valid RRset signature it may to mark the
RRest as secure. A paranoid validator should validate ALL available valid
signatures before marking the set secure.
I do not think it the protocol document role to dictate one or the
other behavior. IFF we want to dictate behavior there are
many other cases that need to be nailed down.


And the implications for a validator:

   1) If the only algorithms in a DSset aren't ones you understand,
   you may treat the zone as unsigned (as things are now).

   2) If there are algorithms you grok in the DSset, but the only
   algorithms signing the DNSKEYset are ones you don't understand, you
   should assume something bad is happening.  (this is a change)

   3) And if there are algorithms you grok in the DSset and DNSKEYset,
   but the only signatures on some RRset are made with algorithms you
   don't understand, you should assume something bad is happening
   (this is a change).

This change is based on the premise that the failure mode when "I
don't grok your algorithm(s)" may be different from the "this RRset
looks like it should be signed, but I haven't gotten a good RRSIG"
failure mode.  In the former case, current code may treat the zone as
unsigned and keep giving answers.  In the latter, current code
(generally) won't return an answer.

The Problem:

   As currently specified, it's sufficient for an RRset to be signed
   by any of the zone's apex DNSKEYs.  There's no way for a validator
   to tell which DNSKEYs the zone used (or intended to use) to sign a
   given RRset.

   If a zone includes an optional algorithm in its apex DNSKEYset,
   then signs some RRs with only that algorithm, a validator can't
   tell whether or not it's supposed to be getting other RRSIGs or
   not.  For example, a zone with a type 5 DNSKEY (RSA/SHA-1) and a
   type 42 DNSKEY (CryptSam, yet to be specified) might choose to sign
   its DNSKEYset with the type 5 DNSKEY and everything else with the
   type 42 DNSKEY.  In that case, you'd want a validator that doesn't
   understand type 42 to do something gentle, such as treating the
   zone as unsigned.

See RFC3090 sections 2.1 and 2.2. If validator understands type 42
it may elect to use it.  IFF some RRset is only signed with type 42
then any validator that does not understand/use that type, will drop
this RRset as bad, this is the publishers choice.
Unfortunately in 2535 there is no way for validator to detect if this
is by choice or some of the RRSIG's where stripped from the answer.
Your text attempts to differentiate between the cases, but I think
the solution is worse than the problem.


   The problem is that an attacker can strip RRSIGs.  Assume, in the
   example above, that the zone owner signed the whole zone with BOTH
   DNSKEYs.  That would let well-behaved clients, absent an attack,
   validate the data.

according to DNS-Threats document if an attacker can do this,
all bets are off for DNSSEC, thus this is not a justification
for a change.



   But an attacker, knowing that type 42 DNSKEYs aren't widely
   supported, could forge answers in the zone and forge type 42 RRSIGs
   (with random data), knowing that virtually no one would be able to
   validate those signatures.  There's no way for most validators to
   tell the difference between this case and the "I only signed with
   type 42" case above.  Hence, adding a DNSKEY of a non-mandatory
   type to your apex DNSKEYset opens the door to a degradation attack.


Validator can attempt to get a SIG(0)/TSIG signed answer from
Authorative server to detect this.



   The same problem exists in the DS-->DNSKEYset security chain.  If a
   parent adds a DS record of an optional type, the attacker can forge
   a DNSKEYset signed by only the optional algorithm type that appears
   in the DSset.  A liberal validator, assuming that an RRSIG made by
   any of the DS's is sufficient, will treat the zone as unsigned.
   (Presumably the attacker would want the forged DNSKEYset to include
   the real DNSKEY of the optional algorithm, since any validator can
   at least check to see if there's a DNSKEY corresponding to one of
   the DS RRs and that at least one of the signatures on the DNSKEYset
   purports to have been made by a DNSKEY of the same tag.)

If attacker can do this, it is simpler for him to flip bits in RRsigs
to make zone date look bogus.


   Both of these problems give zone owners a strong incentive to not
   add optional algorithms.

Identifying the problems is a good thing


The Fix:

   In broad terms, we need to add a mechanism that says "you can
   expect this RRset to be signed by these algorithms".  Rather than
   specify a new (or per-RRset) mechanism, this fix assigns some
   additional semantics to existing data.  Specifically, "if the
   algorithm is in the DNSKEYset, you have to sign everything with
   it".  This avoids making any bits-on-the-wire protocol changes.

   And for the DSset, the rule looks like "if an algorithm is in the
   DSset, it has to be used to sign the DNSKEYset (hence it has to be
   in the DNSKEYset, hence it has to sign the whole zone)".  Again,
   these are all client (and signer) behavior changes.  Authoritative
   servers don't change, and bits on the wire don't change.

   This isn't to say that each key in the DNSKEYset or each key
   corresponding to a DS must be used, just that every algorithm must
   be used.

   Furthermore, a validator should accept ANY valid signature chain,
   even if it doesn't get RRSIGs of all algorithms types or if some
   RRSIGs fail to validate.  A validator may ignore an algorithm,
   perhaps because that algorithm is weak, in which case it may make
   its validation decision as though the algorithm is completely
   unknown to it.  For example, if the only DS records at a delegation
   are for such an algorithm, the validator probably treats the
   delegation as unsecured.


I repeat, IMHO the fix proposed is worse than the problem.

Can you demonstrate a need for this change where attacker can succeed
without gaining access to an Authorative server or see the query ?

After I figure out the private part of the SEP key for the NL. TLD,
what can I do ?
How can I spread a bogus DS set for minbuza.nl ?
        Olafur


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>