-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Marc,
On 10/06/2011 09:06 AM, Marc Lampo wrote:
> Hello,
>
> Presently experimenting with key-rollover scenario's (and timing)
> and it seems that both drafts should be somewhat more specific about
> which TTL (Mekking), whose (which RRset's) expiration time (Morris),
> is actually meant !
>
>
> To make a long story short :
> ZSK rollover timing must take into account max TTL of any *other* then
> DNSKEY RRset
> in the zone. Details below, example at the end of this email.
You are right. Therefor, in key-timing-bis, I define the TTL delay
(Dttl) to be:
The time it takes to expire the previous information from the validator
caches. This delay depends on what RRsets need to expire from the
caches. If not explicitly mentioned otherwise, Dttl is considered the
maximum TTL of the information that needs to expire from caches.
> ZSK double-sign rollover :
> Step 1 : new ZSK, RRSIG's generated with new ZSK added simultaneously to
> the zone
> Step 2 : old ZSK, RRSIG's generated with old ZSK removed simultaneously
> from the zone
>
> The timing between both steps needs to take TTL into account,
> as both drafts indicate :
> Quoting from draft Mekking :
>>>>
> The information for Ks must be published long enough to ensure that
> the information have reached all validators that may have RRsets from
> this zone cached. At the point in time that the DNSKEY RRset
> including Ks has been propagated and Ks is said to be Known (Tkno).
> ---
> At the point in time that the other RRsets including signatures of Ks
> have been propagated (Tsaf), Ks is said to be Safe.
> <<<
> Before the "---" (I added) the text refers to the DNSKEY RRset (and its
> TTL).
> The last line, implicitly refers to TTL of RRSIG's (generated with the new
> key),
> and that TTL is actually the TTL of the RRset it signs - *not* the TTL of
> the DNSKEY !
That is correct. The formulas show that the time that Ks is considered
to be Known depends on DcacheK, while the time that Ks is considered to
be Safe depends on DcacheZ.
Tkno(Ks) >= Tpub(Ks) + DcacheK
Tsaf(Ks) >= Tact(Ks) + DcacheZ
In Section 2.5 on Delay Timings, those values are defined:
DcacheZ = Dsfw + Dprp + Dttl
DcacheK = Dsfw + Dprp + Dttl(DNSKEY)
There you can see indeed that the last line (that depends on DcacheZ)
implicitly, but correctly, refers to the maximum zone TTL.
>
> Quoting from draft Morris :
> <<<
> TTLsig Time to live of an RRSIG record.
>>>>
> TTLsig is used in calculating minimum delay,
> but to avoid misunderstanding (I misunderstood, but practice thought me
> differently)
> it could be clarified that the TTL of an RRSIG is actually the TTL of the
> RRset it signs.
>
>
> While the draft of M. Mekking tries to bring more details
> in the timelines, some wrong impression can be given.
> Extract from the timeline for double-sign :
>>>>
> Ks | | | | |
> - RRSIG | |DcacheZ|----|-------|---
> - DNSKEY | |DcacheK|----|-------|---
> | | | | |
> Tgen Tpub Tkno
> Tact Tsaf
> <<<
> DcacheK includes, in its definition, the TTL of the DNSKEY RRset;
> and DcacheZ includes the "TTL" (no further specification).
> But the timeline can be misleading by suggesting they are identical,
> which they need not be !
> Unfortunately including this detail will make the timeline even
> more complicated (- sorry, Matthijs, but in the end the effort
> should be worthwhile, if people avoid mistakes. Good job !)
That is indeed unfortunate, because I aimed to make the timelines less
complicated:). But you have a good point there, and I think I have to
rethink about how to represent the timelines (maybe going back to the
style of the Morris key timing document).
Best regards,
Matthijs
> As I misinterpreted myself, I stumbled over the scenario with
> longer TTLs for eg SOA record (eg 1 week), then for DNSKEY RRset (eg 1
> day).
> Event 1 : before the start of zsk rollover
> A caching name server fetches SOA
> --> in the cache : SOA + RRSIG with TTL of 1 week
> (old) DNSKEY + RRSIG with TTL of 1 day
> Event 2 : ZSK rollover completed in 3 days
> --> after the rollover, the old ZSK is no longer published
> --> in the cache : SOA + RRSIG with TTL of 1 week - time needed for
> this rollover
> ((old) DNSKEY + its RRSIG have expired from cache)
>
> Now a validating *forwarding* name server addresses this cache
> --> it receives : (cached) SOA + (old) RRSIG (no need to refresh, not
> expired)
> (fresh) (new) ZSK
> and *fails* to validate correctly.
>
> Incidentally, the validating caching name server with only
> the SOA and the (old) RRSIG in its cache,
> still returns answers with AD set
> (though it also can no longer fetch the old ZSK for validation).
> In my setup, that name server is Bind 9.7.
> I assume the result of correct validation is also cached.
> Seems OK to me, don't known if this is RFC prescribed or implementation.
>
>
> Kind regards,
>
>
>
> Marc Lampo
> Security Officer
>
> EURid
> Woluwelaan 150
> 1831 Diegem - Belgium
> [email protected]
> http://www.eurid.eu
>
>
>
> Want a .eu web address in your own language? Find out how so you don’t
> miss out!
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOjWWYAAoJEA8yVCPsQCW5PqsIAIwE7za5K0BC6/WIQ7iuZq2d
46LXAW/7Nn++M+q0nIDoN93pvg7TIhoQA9UrO59FW5aqsxb42cGgSaXvbyDJVo2p
zZBkihxV7KZiM+PT57VonIFkeZqzPk5q6C6+stzcN4vDBFyDJONpYFdeej3hxZR4
gicHs+wgr66zotjvuvNJs6/+M1VUqNw00HqxvkKrz1bou1qwYIMVoBB0LducJ+BO
SFvWQ+Gpo+5XGBytArBsOcZEKUYs2KzNNMTH/O+jvusLHHF4bDguN9u+95nTVO7W
lBGgki08DSfhWSSnQiTn+AoFcuWXIQfXOGqmyPIiS5wcn95pWlJNU1/x380KEq4=
=q0ru
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
