Re: [dnsext] Clarifying the mandatory algorithm rules

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "W.C.A. Wijngaards" writes:
> 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.

I want to make it possible to do incremental signing of new algorithms
which requires the rules to be relaxed but we can leave discussion of
that until we resolve the issue about whether the validator should be
checking or not.
 
> > 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.

Except the validator is not supposed to enforce it.  The point of
the rule, for the signer, was to ensure that there would be *a*
signature to validate with.

The downgrade attack it was supposed to protect against is downgrade
to insecure not downgrade between algorithms.

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

A zone is deem secure or insecure based on the list of algorithms
in the DS RRset.

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

No it isn't necessary.

I start out with algorithm A in DS and DNSKEY.  The DNSKEY has a
TTL of 600.  I have a TXT record with a TTL of 600 which is fetch
300 seconds after the DNSKEY record is fetched.  I add a DNSKEY
with algorithm B and re-sign the entire zone with A+B meeting the
MUST.  301 second later a downstream validating client asks for the
TXT record.  The client get a DNSKEY RRset with A+B and a TXT with
A signatures.  This will validate as secure by a validator that
supports A only.  This will validate as insecure by a validator
that supports B only as there is no secure path from the parent to
the child.  It will validate as secure by a validator that supports
A+B.

Only when you start enforcing that the TXT and DNSKEY records have
to have matching algorithms in the validator does this break despite
the signer meeting the MUST.

Similarly you can go from A+B to just A by removing the DS records
for A, waiting for the old DS RRset to expire then removing the A
DNSKEYs.

> 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-----
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]