Re: [dnsext] Clarifying the mandatory algorithm rules

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

Sam,

we discussed it with Jaromir on our walk to Vatican Museum and came to 
conclusion that validating resolver only needs to stop and declare 
security problem only when there is a chain of trust leading to a key 
with a new algorithm and there are missing signatures for that algorithm.

So the resolver should return SERVFAIL only when (all conditions must 
apply):

a) there are DS records in parent zone for algorithm A and algorithm B

b) the zone has keys for algorithm A and algorithm B in the zone apex 
(it has to according to RFC)

c) there are signatures either only for algorithm A or only for algorithm B

The idea is that just adding a new key with algorithm B (the strong) 
without chaining it to the parent zone doesn't add any new security, 
since the chain of trust is secured by the (the weak) algorithm A.

So, yes the RFCs need a clarification and yes the unbound is 
unnecessarily strict since such strict implementation doesn't add any 
additional security (because you don't have a chain of trust leading to 
a key).  Wouter, object now or never :).

Sam, thanks for your persistence :), the "unsupported algorithm" was the 
missing piece I was looking for.

Ondrej

On 18.11.2010 12:37, Samuel Weiler wrote:
> On Thu, 18 Nov 2010, Ond?ej Sur? wrote:
>
>> 1) there is a known cryptographic attack against algorithm A
> ...
>> 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.
>
> This is a different sort of downgrade attack than the one these rules
> were designed to protect against. Indeed, to address this attack within
> the protocol, we'd need to require resolvers to check EVERY algorithm's
> signature (if they can). We didn't do that before, and it's probably
> unwise to make that change now.
>
> The current work-around is for the zone owner to STOP signing with the
> known-broken algorithm A. That leaves code that only supports A out in
> the cold. If you're assuming resolvers support both A and B (as your
> clarification says), there's no problem.
>
>> 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).
>
> Indeed, for the attack you're describing, the resolver would need to be
> involved, and it would need to change.
>
> The downgrade attack that led to this is documented in a message to
> namedroppers on 13 August 2003, Subject line "DNSSECbis Q-2: degradation
> attack". With the archives off-line, perhaps I should resend it.

Please do.

Ondrej
-- 
  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]
  -------------------------------------------