[ietf-provreg] Recovered from a spam trap:

[Jaap Akkerhuis <jaap@nlnetlabs.nl>]

Date: Tue, 26 Jan 2010 14:00:12 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
From: Olafur Gudmundsson <ogud@ogud.com>
Subject: Re: [ietf-provreg] Revision of 4310  
In-Reply-To: <20100126164121.GF93724@shinkuro.com>
References: <20100126145123.GD93724@shinkuro.com>
 <C7847EE8.37081%jgould@verisign.com>
 <20100126164121.GF93724@shinkuro.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
        
What Andrew is saying below is real important, Key rollover without
parent prepublication is bound by the time it takes to update DNSKEY
RRset (at child)
plus passing the new records to the parent then wait
          max(DS TTL, DNSKEY TTL).
With prepublication the onus only is on the child to publish the new
key.       
The only participation by the parent is to delete the old DS record(s).

I think the knob that 4310 (and 4310-bis) have allowing children to
affect the
lifetime of signatures is a horrible idea, it probably was my idea in
the first place,
as that sets parents up for Signature regeneration DoS attacks.

It is much better to allow the child to affect the TTL on the DS record.
Reasons:
   - In the old days we worried a lot about reuse of old/bad signatures
     ==> data packet forgery is harder than it was unless the
attacker is on-the-wire
a         in which case it can do much more damage.
   - If something bad happens it is more important to get the correct
data to the
     majority of the world, then protect the small corner case that

may get spoofed with
     old/bad data.
Signature Lifetime is about the window of vulnerability, TTL is about
recovery time.

 From a parent perspective this is a choice between more frequent
resigning or
more DS queries, the frequency of DS queries is going to be more
affected by the
TTL of the DNSKEY set than the TTL on the DS set.
 
 From a cryptographic point of view it is better to publish a DS for a
the
"hot-standby" key than publishing the key it self.  In particular
when generating
a key that matches the fingerprint in the DS record(s), than breaking
the key itself.
The consequence of this is that the parent MUST not store the key or
at least not
make it available.

Each operator should set limits on the minimum and Maximum TTL on the
DS records they
allow and how many DS records each child can have.
It is not unrealistic to  assume a child will request DS records for
2-4 different
keys and two or more DS digest algorithms for each.


         Olafur



At 11:41 26/01/2010, Andrew Sullivan wrote:
>On Tue, Jan 26, 2010 at 11:13:44AM -0500, James Gould wrote:
>
> > What is the fundamental difference between a deactivate and a
remove?  It
> > sounds like exactly the same from a DNS perspective and the TTL.
The
> > emergency key rollover use case that you present will be handled
> exactly the
> > same way if the client were to remove the DS from the Registry as
> opposed to      
> > deactivating it and than later removing it.  The deactivate from my
> > understanding will not remove it from the zone any faster then the
existing
> > remove.  Please explain the difference.
>
>It's the other way around.  Having a bad key around that you're not
>using does no harm.  But _adding_ a key isn't instant either.
>
>If I validate your key, I look up the DS from the parent.  That DS
>RRSet ends up cached in the cacheing resolver in front of me.
>
>If you now add a new DNSKEY in an emergency, and stop using your old
>key, then the DS that is cached is still the one I use when
>validating.   
>
>Now, if you have a short TTL on your own DNSKEY record, your old
>DNSKEY will expire from my cache quickly.
>
>But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
>zone.
>
>That means that the fastest you can roll your key is the maximum TTL
>on the DNSKEY or DS records.  So if the parent has long TTLs, you're
>stuck with the TTL on the DS record.
>
>Now, if you can add a DS into the parent _before_ you add the DNSKEY
>to your zone, then the DNSKEY need not actually be in your zone when
>the DS is available in the parent.
>
>Now, some zone operators have said they want to validate that the
>DNSKEY is available in the child before publishing the corresponding
>DS in the parent.  But if EPP were to offer a mechanism whereby you
>could say, "I want you to have this DS record in the DS RRSet, but
>_don't_ expect a DNSKEY in the child yet," then the parent would know
>not to perform that check when adding the DS record.  (By policy, I
>suppose, the "activation" bit could cause the check against the
>child.)
>
>So that's the use case.  I don't know how important this is to
>operators, however.
>
>A
>
>--
>Andrew Sullivan
>ajs@shinkuro.com
>Shinkuro, Inc.
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>List run by majordomo software.  For (Un-)subscription and similar
details
>send "help" to ietf-provreg-request@cafax.se

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