Re: [dnsext] Clarifying the mandatory algorithm rules

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

On 19.11.2010 10:46, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 11/18/2010 09:16 PM, Ondřej Surý wrote:
>> 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.
>
> Today, the RFC has rules for DS-DNSKEY and rule for DNSKEY-DATA.  You
> want to create new rules for DS-DATA.

Just to clarify - I agree that what Unbound does is in alignment with 
what RFC says.

>> 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 :).
>
> You called?  Yes, unbound is strict, it enforces the exact zone signing
> requirements from the RFC.  But, I am not objecting to you strongly.  I
> want to caution making changes to RFC4035, there must be backwards
> compatibility.
 >
> But the above makes the algorithm-set determined by the parent.
> Now, the algorithm set is determined by the child (when you get there).
> I appreciate the concern that if you want to protect a downgrade, then
> you must signal this at the parent.

Yes.

> Mark Andrews wrote:
>> Additionally the MUST is a directive to *zone operators*.  A zone
>> operator can comply with that MUST but validation will still fail
>> with unbound as unbound requires that a zone be signed with DNSKEYs
>> which are NOT in the zone prior to adding the DNSKEY to the zone
>> due to caching.  On this alone it is clear that unbound is in the
>> wrong.
>
> Let me try to understand this and then respond.  You talk about having
> to prepublish signatures before the keys are published.
>
> This is necessary with the current rules today for algorithm-support
> reasons.  It does not go away if unbound has less strict checking.  The
> affected servers could be bind, unbound or other implementations.
>
> Your change to the rules makes it possible to add the key, and then
> signatures slowly, with a new algorithm, (as long as the DS is not added
> yet).  I appreciate that niceness.
>
> You are correct that you must also take the trust-anchors into account
> to do it properly (and I do not do that today).

I suggest we all think about that and put the result into a -bis document.

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