Re: [dnsext] Clarifying the mandatory algorithm rules

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

On 21.11.2010 22:20, Doug Barton wrote:
> I agree with Mark here, and my recollection of the history is the same
> as Mark's and Sam's.
>
> Assume all of the following:
> 1. Alg(A) is still considered "secure" (validator local policy)
> 2. There is a DS/DNSKEY/RRSIG chain for Alg(A) in the zone already
> 3. A new DNSKEY for Alg(B) is added to the zone, but no RRSIGs using
> that key exist (with or without a DS for DNSKEY(B) in the parent).

I don't think you can mix the "with or without".  If you publish DS for 
DNSKEY(Alg(B)) you must have signatures created by DNSKEY(Alg(B) in the 
zone (ie. double sign over all your zone).

> That situation is NOT a downgrade attack, and should never be considered
> one. (And yes, arguably the authoritative server should not have allowed
> the zone to be loaded, but that's another issue.)
>
>
> Doug
>
>
> On Sat, 20 Nov 2010, Mark Andrews wrote:
>
>> 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
>>
>>
>
>


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