[ietf-provreg] Recovered from spamtrap

[Jaap Akkerhuis <jaap@nlnetlabs.nl>]

From: Olafur Gudmundsson <ogud@ogud.com>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
Cc: EPP Provreg <ietf-provreg@cafax.se>
In-Reply-To: <C784D53E.370DD%jgould@verisign.com>
References: <a06240803c7850afffec4@[10.31.200.236]>
 <C784D53E.370DD%jgould@verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4

At 17:22 26/01/2010, James Gould wrote:
>Yes, we kind of got into the weeds of DNSSEC specifics.
>
>I believe the request was to add a flag to the draft to allow the
>client to indicate to the server that the DNSKEY is active in the
>child zone.  The definition of this needs to be clearly defined, but
>I would assume that it is that the DNSKEY is published in the child
>zone DNSKEY RRset.  This is an optional attribute that the server
>can use for additional validation based on server policy.  If the
>attribute is supported by the server it should be returned in the
>secDNS:infData of the domain info response.  This optional attribute
>would be added to the secDNS:keyData and the secDNS:dsData
>elements.  I recommend calling this attribute childKeyActive.  I
>also recommend that there are no changes to the secDNS interface to
>optimize changing this attribute in a domain update.


Would Present/Not-Present be a better definition?
Present is implies the corresponding key is in the DNSKEY set at that
moment and can be checked. Not-Present says no check can be performed at
this point. As far as the parent is concerned Active is not important,
and implies that when key changes between Active and Non-Active then the
registry SHOULD be updated, which I do not think is desirable.



>Do registries in general need this and do clients want to add this
>complexity to the draft?
>
>--
>
>
>JG
>
>-------------------------------------------------------
>James F. Gould
>Principal Software Engineer
>VeriSign Naming Services
><jgould@verisign.htm>jgould@verisign.com
>Direct: 703.948.3271
>Mobile: 703.628.7063
>
>
>21345 Ridgetop Circle
>LS2-2-1
>Dulles, VA 20166
>
>Notice to Recipient:  This e-mail contains confidential, proprietary
>and/or Registry  Sensitive information intended solely for the  
>recipient and, thus may not be  retransmitted, reproduced or       
>disclosed without the prior written consent of  VeriSign Naming and
>Directory Services.  If you have received  this e-mail message in
>error, please notify the sender immediately by  telephone or reply
>e-mail and destroy the original message without making a  copy.  Thank
you.
>
>
>
>From: Edward Lewis <<Ed.Lewis@neustar.htm>Ed.Lewis@neustar.biz>
>Date: Tue, 26 Jan 2010 16:24:45 -0500
>To: Andrew Sullivan <<ajs@shinkuro.htm>ajs@shinkuro.com>
>Cc: EPP Provreg <<ietf-provreg@cafax.htm>ietf-provreg@cafax.se>
>Subject: off-list was Re: [ietf-provreg] Revision of 4310
>
>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.)
a>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.htm>ietf-provreg-request@cafax.se
> 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se