Subject: [DNSOP] Compromised-key Digest Signature(ckds) draft

From: zhanghaikuo <[email-masked]>
Date: Wed, 6 Jun 2012 10:19:57 +0800

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 

I hope it is useful for DNSSEC.

Regards

Haikuo Zhang
Software Development Center  
---------------------------------------------------
= =Profession • Responsibility • Service= =
 
China Internet Network Information Center （CNNIC）
Tel: (8610)-58813163
Https//: www.cnnic.cn 
Add: 4 South 4th Street, Zhongguancun, Haidian district, 100190 Beijing, China
POB: Beijing 349, Branch 6

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Jun 2012 00:51:47 -0400 (EDT)

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

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?

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.

Could you explain what would trigger a resolver to check for a CKDS
record?

Paul

---

From: zhanghaikuo <[email-masked]>
Date: Wed, 6 Jun 2012 15:16:24 +0800

--------------
zhanghaikuo
>you did. Instead of writing "53" you should write "[TBD]" which means
Thanks for your feedback. I updated my draft just now, and changed "53" to "[TBD]"
>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.
 
>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
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-masked]
>https://www.ietf.org/mailman/listinfo/dnsop