[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DNSSECbis Q-2: degradation attack
I agree with the suggested text. Seems like something that should be stated
in the protocol draft when signed zones are discussed.
Scott
----- Original Message -----
From: "Sam Weiler" <weiler@tislabs.com>
To: <namedroppers@ops.ietf.org>
Sent: Wednesday, August 13, 2003 12:36 PM
Subject: DNSSECbis Q-2: degradation attack
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.)
>
> Both of these problems give zone owners a strong incentive to not
> add optional algorithms.
>
> 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.
>
>
>
>
> --
> 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/>
--
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/>