Subject: [DNSOP] clarification suggestion for draft-mekking-dnsop-dnssec-key-timing-bis and draft-morris-dnsop-dnssec-key-timing

From: "Marc Lampo" <[email-masked]>
Date: Thu, 6 Oct 2011 09:06:39 +0200 (CEST)

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.

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 !

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 !)

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-masked]
    http://www.eurid.eu

Want a .eu web address in your own language? Find out how so you don’t
miss out!

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 06 Oct 2011 10:23:53 +0200

Hi Marc,

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

> and that TTL is actually the TTL of the RRset it signs - *not* the TTL of

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.

> 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

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Oct 2011 19:44:10 +0900

> in the zone.  Details below, example at the end of this email.

How about clock errors between servers and clients?

						Masataka Ohta

---

From: "Marc Lampo" <[email-masked]>
Date: Thu, 6 Oct 2011 12:51:47 +0200 (CEST)

True, of course, they can happen.
But I don't think special "cases" must be shown in these RFC's to reflect 
such errors ...

Best practice is to have authoritative and validating caching/forwarding 
name servers time sync'd.  I think this is in the DNSSEC best practices RFC, 
by the way.

Marc

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]]
Sent: 06 October 2011 12:44 PM
To: Marc Lampo
Cc: 'IETF DNSOP WG'; [email-masked]; [email-masked]
Subject: Re: [DNSOP] clarification suggestion for 
draft-mekking-dnsop-dnssec-key-timing-bis and 
draft-morris-dnsop-dnssec-key-timing

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Oct 2011 07:05:05 +0900

> True, of course, they can happen.

They always happen.

> But I don't think special "cases" must be shown in these RFC's
> to reflect such errors ...

How can you say them "special"?

						Masataka Ohta

---

From: "Marc Lampo" <[email-masked]>
Date: Fri, 7 Oct 2011 07:46:47 +0200 (CEST)

What makes them "special", in my opinion, is that they are sysadmin
errors, really.
Wrong setup of time-sync of the servers.
DNS(SEC) may suffer from the consequences, but is, by itself, not to
blame.

One can only anticipate by, at authoritative side, not follow the timing
recommendations
too strictly.
By which I mean, interpret the recommendations as minimum only,
wait some more time before taking the next action.

If DNSSEC RFC's can do more to take sysadmin errors into account ?
I think more then stating
   "timing are minimum only,
    in practice, allow some more time"
is the best that could be done.

Kind regards,

Marc Lampo

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]] 
Sent: 07 October 2011 12:05 AM
To: Marc Lampo
Cc: 'IETF DNSOP WG'; [email-masked]; [email-masked]
Subject: [POSSIBLY SPAM] Re: [DNSOP] clarification suggestion for
Importance: Low

They always happen.

						Masataka Ohta