Subject: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01

From: Michael StJohns <[email-masked]>
Date: Wed, 05 Sep 2012 13:20:10 -0400

Hi -

As the subject document seems to describe an operations problem rather 
than a protocol problem, I'm going to use the dnsop mailing list to post 
some comments.

While I haven't completely internalized this document, I'm pretty sure 
it's addressing the wrong problem.  The issue is not that there are too 
many DS in the parent zone as compared to DNSKEY in the child.  It's 
actually perfectly correct to publish a DS record in advance of 
publishing the related DNSKEY.   I *think* the issue they may be 
concerned with is a complete disjunction between the parent DS and child 
DNSKEY RRSets.  But that's not what the document says.

Case 1 - there is no such thing as a failing DS.   There is a DS that 
does not currently match a child DNSKEY, but that is not necessarily a 
"fail".  Case 1 - the appropriate problem is "no matching DS for zone 
DNSKEYs" - the resolution is "add a matching DS to the parent zone, or 
deploy a DNSKEY that matches an existing DS".

Case 2-5 seem to be the same problem as case 1, rather than separate 
problems - but the title of the cases does not reflect this.  In any 
event, "removal" of data is mostly not going to help the problem - you 
need to "add" the appropriate links in the trust chain.  Data that does 
not provide a link in a trust chain is just extraneous and may be safely 
ignored until it can be removed with normal practices.

At best this is an incomplete ID (and I'd recommend not posting 
something this incomplete), at worst it's headed in the wrong direction.

Mike

---

From: Yoshiro YONEYA <[email-masked]>
Date: Thu, 6 Sep 2012 17:36:16 +0900

Hi,

> than a protocol problem, I'm going to use the dnsop mailing list to post 

Thank you for bringing this to dnsop mailing list.

> DNSKEY RRSets.  But that's not what the document says.

Disjunction between DS and DNSKEY will happen.  That is premise of 
the document.  And the document (at least, one of the authors) is 
intent to indicate rational procedure to recover from the validation 
failure caused by the disjunction as soon as possible.

> ignored until it can be removed with normal practices.

Case 1-5 are alternate countermasures in case of disjunction has 
happened.  Of course, add appropriate DS in parent zone is correct 
way to recover the disjunction.  However, if DS is corrected, zone 
banishing may remain until DS cache is expired in validators.  This 
duration will take huge impact to the internet users.  As described 
above, the document is intent to indicate rational procedure to shorten 
the duration.

> something this incomplete), at worst it's headed in the wrong direction.

Indeed, the document is imcomplete, and need feedbacks from experiences. 

Regards,

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Phil Regnauld <[email-masked]>
Date: Thu, 6 Sep 2012 11:08:39 +0200

> Indeed, the document is imcomplete, and need feedbacks from experiences. 

	There are indeed many ways to facilitate recovery, not all of them
	practical or realistic.

	Here's one that's more in the realm of prevention, but would faciliate
	recovery, assuming the implementation doesn't suffer from the same
	operational errors that led the zone owner to consider recovery in
	the first place, and assuming the DS-set has been completely borked
	by the parent:

	Case 6: always have a backup (fallback) DS, published alongside the
	existing (production) DS record or records (during rollover) currently
	associated with the currently active (production) KSK.
	Keep this backup KSK in a safe place, and in case of serious SNAFU with
	the existing DS-KSK couple, pull the backup KSK out of the Safe Place,
	and start signing the ZSK with that. The DS-set containing the active +
	backup KSK being by definition always published, this should allow for
	faster convergence (assuming a fairly low TTL for the DNSKEY RRset in
	the signed zone).

	The problem with the ID may be that there are so many different ways
	of doing this (hinted at by the phrase "Registration system (or zone
	generation system) of parent zone will be complicated.")...

	Phil

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 Sep 2012 10:31:03 -0400 (EDT)

On Thu, 6 Sep 2012, Phil Regnauld wrote:

> Subject: Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01

I find this document does not add enough new information compared to
draft-ietf-dnsop-rfc4641bis-12#section-4.2 to warrant a new RFC.

Paul

---

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 7 Sep 2012 16:52:43 +0900

Hi,

> 	There are indeed many ways to facilitate recovery, not all of them

Yes, currently there are some cases listed in the document, but I'd 
like to narrow down the list and remain 1 or 2 as a best practice in 
the succeeding document.

> 	associated with the currently active (production) KSK.

This is yet another preventive countermeasure.  Child zone administrator 
who take this practice should use short TTL for DNSKEY.  I'll take into 
consideration your suggestion.

> 	generation system) of parent zone will be complicated.")...

As mentioned above, I'd like to compare each cases based on experiences 
and select 1 or 2 as best practice.

Regards,

---

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 7 Sep 2012 16:52:57 +0900

Hi,

> draft-ietf-dnsop-rfc4641bis-12#section-4.2 to warrant a new RFC.

The document intent to describe what to do when child zone administrator 
failed to do KSK rollover.  It also intent to advice to parent zone 
administrator for that case.  I think this concept is not included in 
rfc4641bis.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Sep 2012 10:54:49 -0400 (EDT)

> administrator for that case.  I think this concept is not included in

A lot of what can be done there will be framed by lawyers, not
engineers. I agree 4641bis tells you how to not get at a failed
rollover state. I just don't see much value in a document that
tells you what to do when you ignored 4641bis.

Paul