Subject: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Apr 2014 18:11:39 -0400

[ Apologies all - I initially sent this with no subject line.
Resending. Hopefully this makes things clearer... Also, unless we hear
strong objections I'm planning on doing what Patrik and Matthijs
suggested, option A ]

On Fri, Apr 11, 2014 at 5:12 PM, Warren Kumari <[email-masked]> wrote:
> Hi there all,
>
> At the moment this document says that the child SHOULD remove the
> CDS/CDNSKEY record once the parent has consumed / acted on it (this
> behavior was requested by someone -- unfortunately I cannot remember
> whom).
>
> I *think* that I'm hearing that folk would prefer that the child
> SHOULD leave it in, or, less strongly MAY remove it.
>
> This (IMO) makes the doc and the child's life simpler, but potentially
> makes a bit more work for the parent -- currently most of the
> time the parent will see no CDS, and so will go back to sleep. If the
> child leaves them around, the parent will need to check them against
> what is currently published and take action if they differ.
>
> Can folk please let us know if they would prefer:
> A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the
> parent has published it (currently documented behavior) or
>
> B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a
> small edit to the doc)
>
> My personal preference is for B - it seems more elegant, but (as
> always) we'll do whatever the WG wants.
>
> W
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 12 Apr 2014 09:28:30 +0200

No, I want B. That CDS and CDNSKEY is staying in the zone.

  Patrik

---

From: Warren Kumari <[email-masked]>
Date: Sat, 12 Apr 2014 09:04:07 -0400

> No, I want B. That CDS and CDNSKEY is staying in the zone.

Doh! Yes.
Sorry, when I resent this with the subject added I forgot which order
I'd listed the two options - I'd though A was B and B was A.
Unless we hear objections I'm planning on doing what Patrik and
Matthijs suggested, option ***B***.

Gods I suck at this.
W

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 13 Apr 2014 08:53:04 +0200

> Gods I suck at this.

No, you are good at this!

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 14 Apr 2014 14:32:10 +0200

> No, I want B. That CDS and CDNSKEY is staying in the zone.

To keep it in the same thread,
I want:

C: The child MAY remove the CDS/CDNSKEY RR from the zone once the
parent has published it, and this is how to do that safely.

So I'm ok if they stay in, but we need a way to get them out for the
ones that need that.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 14 Apr 2014 14:50:14 +0200

> So I'm ok if they stay in, but we need a way to get them out for the

I am fine with C.

   paf

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 14 Apr 2014 15:10:56 +0200

> So I'm ok if they stay in, but we need a way to get them out for the

I actually am for C too, mainly because the parental agent has to deal
with this scenario anyway. As long as this is not the default scenario,
it is fine with me. Hence MAY sounds reasonable to me.

The rules can be:

Wait until the new CDS and/or CDNSKEY RRsets have propagated to all the
child name servers. Then, for each parent name server, query the DS
RRset and make sure it is in sync with the CDS and/or CDNSKEY RRset.
Only then it is safe to remove the CDS and/or CDNSKEY RRsets again.

Best regards,
  Matthijs

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 14 Apr 2014 09:17:23 -0400

>> So I'm ok if they stay in, but we need a way to get them out for the

Actually C helps me with some of  the wording, as I spent some time 
yesterday with a red pen going over editorial issues.

tim

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2014 11:10:27 -0400

> yesterday with a red pen going over editorial issues.

Hopefully you are reviewing the latest (-05) :-)

Actually, I'm planning on incorporating C - chairs, please let me know
if this does not align with your view of consensus.

W

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2014 12:09:20 -0400

> if this does not align with your view of consensus.

... and I've just posted -06, incorporating option C.
I have outlined the changes in the Change / Author Notes section --
they were primarily to ensure consistency and to remove duplicated
text.
One of the bits that is a larger change, and that I'd like some feedback on is:
Section 6:
I changed:
"Regardless of how the Parental Agent detected changes to a CDS /
CDNSKEY RR, the Parental Agent MUST use a DNSSEC validator to obtain a
validated CDS / CDNSKEY RRset from the Child zone."
to:
"Regardless of how the Parental Agent detected changes to a CDS /
CDNSKEY RR, the Parental Agent SHOULD use a DNSSEC validator to obtain
a validated CDS / CDNSKEY RRset from the Child zone. The only
exception to this is if the parent perfoms some additional validation
on the data to confirm that it is the "correct" ket. This behavior is
NOT RECOMMENDED."

As Patrik (and others) have pointed out, a number of folk would like
to use this for initial enrollment. How do folk feel about the above?
Plan is that a user will publish a CDS in an (e.g) unsigned zone, and
will then logon to the registrars web interface. They click "Fetch
CDS/CDNSKEY" and the web interface displays the key. They user
checks[0] that it is correct then click "LGTM". Now they are signed...
I'm somewhat uncomfortable with the above, but, hey, whatever...

W
[0]: Yup, they really check it, and make sure the key matches. They
don't, for example just blindly click OK :-P

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
e5:33:f0:e6:22:24:0c:ee:e2:ed:f2:d2:e7:a0:3f:a6.
Please contact your system administrator.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 14 Apr 2014 10:30:56 -0700

At Mon, 14 Apr 2014 15:10:56 +0200,

> Only then it is safe to remove the CDS and/or CDNSKEY RRsets again.

I'm fine with option C (but not "RR", but "RRset"), too, but probably
more important, I'd like the draft to explain why one might want to
remove the CDS/CDNSKEY RRsets.  Warren's explanation makes sense to
me:

At Fri, 11 Apr 2014 18:11:39 -0400,

> > what is currently published and take action if they differ.

(except the "and take action if they differ" part; we can't avoid this
overhead by removing the CDS/CDNSKEY RRsets when there is no change)
but the rationale is not obvious, at least to me.

--
JINMEI, Tatuya