--------------
zhanghaikuo
>On Wed, 6 Jun 2012, zhanghaikuo wrote:
>
>> Dear dnsop work group,
>> I wrote a draft for DNSSEC, and it is a new method to deal with the
>> emergency rollover for the compromised key.
>> the draft is followed:
>> https://datatracker.ietf.org/doc/draft-haikuo-ckds/?include_text=1
>
>First, I don't think a draft should grab an IANA DNS type code like
>you did. Instead of writing "53" you should write "[TBD]" which means
>"to be decided"
>
Thanks for your feedback. I updated my draft just now, and changed "53" to
"[TBD]"
>Now on to the proposal,
>
>The issue I see is that a CKDS needs to be explicitely queried for. Do
>I have to re-query this when the negative cache ttl runs out? I cannot
>only query it when I want to lookup DS records, or I would miss this
>"revocation" of the key. If I hae a DS record that is cached for 1day
>or 1week, when would I query for CKDS?
>
In my draft, the CKDS should be responed to the resolver when resolver query
for DS.
If the DS did not expire in the cache of resolver, the resolver should not take
the initiative to get the CKDS.
The CKDS is used to explicietely point at the compromised key only.
When the KSK is compromised and the situation is very severe, it is worse if
the administrator set "revocation" bit immediately, because it could impact the
resolvers which is not under the attacks from the hacker.
My method which is methioned in the draft could reduce the loss. One reason is
that my method could not impact the resolver which is not under attack; the
other reason is that the CKDS could explicietely point at the compromised key
and the CKDS should trigger the resolver to clean up the related records in the
cache, so the new key could be published more quickly than traditional DNSKEY
rollover method.
Both my method and the traditonal DNSKEY rollover method are useless for the
resolvers which is under the attack.
There is no conflict between revocation bit and CKDS.
the revoke bit could be set after one TTL of DS which point at the compromised
key when the CKDS is visible from the parent name server.
>I understand you do not want to check the revoke bit in the DNSKEY,
>because if compromised you could be given that key without the revoke
>bit. But I'm still not sure when a resolver should look for a CKDS
>record. And defining a null-CKDS would run into the exact same caching
>problem as the actual DS record does.
Sorry, you might misunderstand the relation of CKDS and revoke bit in the
DNSKEY.
The CKDS looks like a signal which is used to tell the resolver that the DNSKEY
is compromised, and the signal should be verified by the DNSKEY from the parent
domain.
The CKDS has only one purpose that it tell everyone the DNSKEY is compromised
explicietely. The revoke bit is used to regular DNSKEY rollover no matter
whether DNSKEY is compromised or not.
My draft introduce a new emergency DNSKEY rollover method, and the method is
shown that the CKDS is visiable a TTL-time latter, then the revoke bit in the
DNSKEY should be set.
>
>Could you explain what would trigger a resolver to check for a CKDS
>record?
When the DS is expired at the resolver side and the resolver lookups the DS,
the CKDS would be received to the resolver. That means not all of resolver
could get the CKDS at the same time or immediately.
The method can reduce the loss, but could not get rid of it completely.
>
>Paul
>_______________________________________________
>DNSOP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
