Re: off-list was Re: [ietf-provreg] Revision of 4310

[Edward Lewis <Ed.Lewis@neustar.biz>]

Was meant to be off-list.  Because I'm diving into the details of 
DNSSEC itself.  (And not saying anything new.)

To come back to EPP, I think we need to revisit "active/inactive" and 
the implications it has to a registry.

At 16:24 -0500 1/26/10, Edward Lewis wrote:
>I think this has veered off-topic for EPP. ;)
>
>At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
>>On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
>>>>   I don't think I understand this one.  Do you mean that there's no
>>>>   RRSIG for that DNSKEY record?
>>>
>>>   To clarify - Yes.  In this instance, "in-active" would cover having a DS
>>>   appear, the DNSKEY appear, but no RRSIG created by the private key.  That
>>>   would make the DS "in-active" in terms of building a chain of trust.
>>
>>I like this idea better than just not putting the DNSKEY in the DNSKEY
>>RRset.  Is anyone doing their deployment this way?
>>
>>On the other hand, I suppose it doesn't really matter whether one does
>>it this way or by just not including the DNSKEY on the child side.  In
>>either case, you have to use the old key until the TTL expires
>>(because without an RRSIG, the new key won't be useful either).
>
>If you are doing SEP=KSK and ZSK for all other keys, the best (IMO) 
>thing to do is to add the SEP to the DNSKEY set and include the 
>signature when you begin the process of changing.  After appropriate 
>timing, add the new DS and remove the old DS (or swap in one atomic 
>transaction).  After more appropriate time, revoke and later remove 
>the old key.
>
>We plan to always have an emergency key on-line.  So, add new key #3 
>to the set of #1 and #2.  Later swap #1 with #2.  Eventually revoke 
>#1.  One cycle later, add new key #4, swap #2 with #3, retire #2. 
>And so on.  From add new key to remove there are three KSK 
>signatures, two otherwise.  There is always just one DS record (per 
>key algorithm and DS hash).
>
>If one does not have a KSK/ZSK model, things will be different.  I 
>haven't thought through that though.
>
>>So why add the key to the DNSKEY RRset at all?
>
>So the validator can get the key.  (If it weren't there, it's not 
>going to be anywhere.)
>
>Put the key at the parent...you're back to RFC 2065...;)
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis
>NeuStar                    You can leave a voice message at +1-571-434-5468
>
>As with IPv6, the problem with the deployment of frictionless surfaces is
>that they're not getting traction.
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>List run by majordomo software.  For (Un-)subscription and similar details
>send "help" to ietf-provreg-request@cafax.se

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se