Re: [dnsext] Clarifying the mandatory algorithm rules

["W.C.A. Wijngaards" <[e-mail]>]

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

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

(the security of that parent is that of a new zone; with different owners).

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).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzmR4UACgkQkDLqNwOhpPh6FACeLAsw/oeIyPpsA4YIL0Bn0jom
YBoAnRm3491f7m5Y4ipbNc5bpYPNTb6U
=e/Yn
-----END PGP SIGNATURE-----