Subject: Re: [DNSOP] Fw: New Version Notification for draft-morris-dnsop-dnssec-key-timing-02

From: Stephen Morris <[email-masked]>
Date: Wed, 7 Jul 2010 09:52:20 +0100

On 15 Jun 2010, at 14:49, Hugo Salgado Hernandez wrote:

> I have a comment regarding the KSK rollover with the "Double-DS" method,
> section 3.3.2.
> 
> The ICANN draft procedure for submitting DS to the root zone require
> that:
>   "At the time of the trust anchor request, there must be a DNSKEY that
>   matches the DS record present in the child zone. This will be tested
>   for the presence of a matching DNSKEY record as part of the
>   implementation of the record. As with most technical
>   conformance criteria for the root zone, if a top-level domain
>   operator has a situation where this is not the case, but this is by
>   design and can be demonstrated not to affect the stability of the TLD
>   or the root zone, it is possible to request that the trust anchor be
>   listed regardless." [1]
> 
> 
> But in the Double-DS timeline the DS is submitted in Event 2, and the
> key "could be" introduced in Event 4.
> 
> I think it is safe to publish the key N even before Event 2 (but not
> activate it before Trdy). And like the root procedure, it could
> be recommended to do this way for any zone whose parent requires a
> published-matching-key along with the DS submission.

The scenario of publishing the KSK in the child zone before publishing the DS record in the parent is what the double-signature KSK method describes, and that would better fit the process outlined above.

The KSK rollover methods described in the draft are really extremes:

* Double-signature method describes the case where there is only ever a single DS record in the parent zone at a given time; but during the rollover there are two KSK DNSKEY records in the child.

* Double-DS method describes the converse, where there is only ever a single KSK DNSKEY record in the child zone at any time but during the rollover there are two DS records in the parents.

* Double-RRset describes the rollover that takes the least time.  But the penalty for this is that during the rollover the parent must have two DS records and the child two KSK DNSKEY records.

Although the timings are conservative - the aim is to ensure that during a rollover it is always possible to retrieve a consistent DS/DNSKEY combination - there is room for flexibility.  For example, in a double-RRset KSK rollover, there is a separation between the dead time (event 6) - which is when the old DS/DNSKEY records could be removed and the removal time (event 7) - when they actually are. Theoretically this interval could be zero, but in practice an operator may choose to leave the old DS/DNSKEY pair in their respective zones for an extended period because their signing policy demands a certain degree of key overlap.

Stephen

---

From: Hugo Salgado <[email-masked]>
Date: Fri, 09 Jul 2010 15:32:54 -0400

> * Double-signature method describes the case where there is only ever a single DS record in the parent zone at a given time; but during the rollover there are two KSK DNSKEY records in the child.

But with the Double-signature method, besides the two KSK DNSKEY
records, you need two *RRSIG* records, one with each KSK.

I think the Double-DS method still fits in the process of IANA,
if we take care that in the child you'll nedd to have the new KSK
DNSKEY record published before submitting your new DS, but not signing
with it. The only KSK RRSIG for the DNSKEY rrset should be with the old
KSK.

Thanks,

Hugo

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

---

From: Hugo Salgado <[email-masked]>
Date: Fri, 09 Jul 2010 15:41:18 -0400

> with it. The only KSK RRSIG for the DNSKEY rrset should be with the old

My proposal is to add to the Event 1 in 3.3.2 a paragraph like this:

  "If the parent zone policy requires a published DNSKEY before accept
  a DS submission, add the key N into the DNSKEY RRset at this time, (or
  any time before Event 2) is a standby state (not yet used to sign the
  RRset)"

Hugo

---

From: Stephen Morris <[email-masked]>
Date: Wed, 21 Jul 2010 22:02:10 +0100

>> with it. The only KSK RRSIG for the DNSKEY rrset should be with the old

OK, I see what you mean.

>  any time before Event 2) is a standby state (not yet used to sign the

My concern is whether this draft is the right place for such text.  The IANA process is a special case and is not concerned with the timing issues that are the focus of the document; as such, it may belong more in something that describes how that timing sequence has been implemented in a particular case.

Stephen

---

From: [email-masked]
Date: Sun, 25 Jul 2010 22:39:15 +0200

Quoting Stephen Morris <[email-masked]>:

> My concern is whether this draft is the right place for such text.    
> The IANA process is a special case and is not concerned with the   
> timing issues that are the focus of the document; as such, it may   
> belong more in something that describes how that timing sequence has  
>  been implemented in a particular case.
>

But that particular case could be the norm!
Currently, not only the root has this policy. RIPE[1] and .br[2] also
requires prepublication of dnskeys.

Hugo

[1]: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html
[2]: http://registro.br/faq/faq8.html#18 (portuguese only)

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Jul 2010 18:37:58 -0400

> requires prepublication of dnskeys.

I'm not entirely sure that the draft ought to reflect what people do,
because one could argue that that requirement is a mistake.  But in
any case, they're still infrastructure domains, just as is ., and the
analogy between them and everything else breaks down pretty quickly.

I think the draft is _not_ the place for this advice.  If advice is
needed, it should go in 4641-bis.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.