Re: [dnsext] Clarifying the mandatory algorithm rules

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

Based on off-list discussion with Sam, I should add that both algorithm 
A and algorithm B in my example are supported by the validating resolver.

Ondrej

On 18.11.2010 12:20, Ondřej Surý wrote:
> 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]
  -------------------------------------------