Re: [dnsext] Clarifying the mandatory algorithm rules

[Ondřej Surý <[e-mail]>]

Hi Sam,

I actually gave it some thought yesterday and there is one thing I still 
don't understand.  If the case is indeed to protect against downgrade 
attack then if the resolver doesn't implement same strictness as zone 
operators then there is in fact no protection at all against downgrade 
attack.

Maybe it's a right time to clarify what the downgrade attack is.  My 
understanding is that:

1) there is a known cryptographic attack against algorithm A

2) there is a algorithm B which is safe to use

3) the zone operator publish zone with algorithm A and B in the apex

4) the zone is signed by both algorithm A and B (Note: when I say signed 
by algorithm I mean signed by key or chain of keys (KSK+ZSK) using that 
particular algorithm)

5) an attacker computes the signature for his spoofed records using 
algoritm A

6) an attacker injects his spoofed RRs together with computed sigs to a 
validating resolver

7) if the validating resolver is OK with just one or another and not 
both algorithm signatures, it could be convinced to validate the result 
just by seeing (spoofed) signatures with algorithm A.  So the validating 
resolver sees spoofed records and it's spoofed signatures using just 
algoritm A and it validates the result.


What do I miss here?  I really do think that there is no downgrade 
attack protection if it's not implemented on both sides (authoritative 
and validating-recursive).

Ondrej.

On 18.11.2010 12:02, Samuel Weiler wrote:
> Recently CZNIC reported on some algorithm rollover problems they
> encountered when they didn't follow the "mandatory algorithm rules" in
> the "Zone Signing" section of RFC4035. These rules create a method to
> signal to resolvers what algorithms are in use in a zone. As historical
> perspective, these rules were written in order to avoid the dilemma of
> opening resolvers to a downgrade attack or discouraging the use of new
> algorithms.
>
> CZNIC published a DNSKEY for a "new" algorithm without simultaneously
> publishing the corresponding RRSIGs. Unbound started rejecting answers
> from .cz because the zone didn't also include the new RRSIGs, even
> though Unbound fully supported the old algorithm and the RRSIGs for that
> old algorithm were present in the zone.
>
> These rules are indeed for zone operators and/or signers and do not need
> to be enforced by a validator. While I haven't worked through the
> validation sections of 4035 closely, I think Unbound is violating the
> RFC by checking for this. (It would fine for Unbound to disable support
> for the "old" algorithm entirely, in which case the answers should
> indeed be rejected, but that isn't what happened here.) In contrast,
> BIND found the signatures from the "old" algorithm sufficient.
>
>
> I've heard folks from CZNIC advocating adding some clarifications to
> 4641bis and other operational documents reminding zone operators of
> these rules, perhaps in better language. I generally support that.
>
> I've also been encouraged to add an explanation of this to
> dnssec-bis-updates. Since validator implementers did different things, I
> agree that clarification is in order.
>
> The most general thing we could say is "Pay attention to the section
> headings in RFC4035. Note that Section 2 ("Zone Signing") provides
> guidance to zone signers, not resolvers. Resolvers should pay careful
> attention to Sections 4 and 5 ("Resolving" and "Authenticating DNS
> Responses") and do not need to separately check for compliance with
> every item in Section 2. In particular the "mandatory algorithm rules"
> in the last paragraph of section 2.2 do not need to be enforced by a
> resolver. Note that this document makes some minor changes to the
> validation rules in RFC4035, including the rules for handling DS records
> with unknown message digest algorithms."
>
> I'm not sure if the generalization (that validators can ignore section
> 2) is 100% correct. Is it?
>
>
> Alternatively, we could say something specific:
>
> "The last paragraph of RFC4035 Section 2.2 includes rules for which
> algorithms must be used to sign a zone. Since these rules have been
> confusing, we restate them in different language here:
>
> Every algorithm present in a zone's DS RRset (if any) must also be
> present in its DNSKEY RRset. Every algorithm present in the DNSKEY RRset
> must be used to sign every RRset in the zone, including the DNSKEY RRset
> itself. If more than one key of the same algorithm is in the DNSKEY
> RRset, it is sufficient to sign each RRset with any subset of these
> DNSKEYs. It is acceptable to sign some RRsets with one subset of keys
> (or key) and other RRsets with a different subset, so long as at least
> one DNSKEY of each ALGORITHM is used to sign each RRset. Likewise, if
> there are DS records for multiple keys of the same algorithm, any subset
> of those may appear in the DNSKEY RRset.
>
> Furthermore, note that these rules are for zone operators and zone
> operators, as might be inferred from the Section 2 heading: "Zone
> Signing". These rules do not need to be separately enforced by
> validating resolvers."
>
>
> Does the WG have a preference for which version of this to add to
> dnssec-bis-updates? By default, I propose to add the specific one. If
> someone else has walked through RFC4035 Sections 4 and 5 carefully,
> perhaps we could use the general one. I also welcome other restatements
> of the rules: I wrote the original ones which have been confusing, and
> having someone else rewrite them might make more sense.
>
> -- Sam Weiler
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext


-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[e-mail]    http://nic.cz/
  tel:[phone]       fax:[phone]
  -------------------------------------------