Managing DS Records from the Parent via CDS/CDNSKEY
draft-ietf-dnsop-maintain-ds-06
Yes
No Objection
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
Note: This ballot was opened for revision 03 and is now closed.
Joel Jaeggli Former IESG member
(was Discuss, Yes)
Yes
Yes
(2016-12-12 for -04)
Unknown
Separate standards action was carried for the RFC 7344 Standards action. Draft 04 moved the status change to the front-matter. Was Discuss: Place holder for the discussion of a standards action for 7344 discussion I'm taking this off agendas until I get an update and the standards action.
Stephen Farrell Former IESG member
Yes
Yes
(2016-08-30 for -03)
Unknown
- I support Jari's discuss - but it might be fine to just chat about the 7344 status change, not sure. But that said, I'm balloting yes, as this bootstrapping is definitely needed if DNSSEC is going to prosper. - please check and respond to the secdir review, [1] which overlaps a bit (but not totally) with my comments. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06685.html - 1.3: s/digiest/digest/ - 1.3: definition of RRR isn't clear (enough) - I think you want to define RRR to mean the current public DNS ecosystem maybe, but not sure if there's a subtlety somewhere in e.g. 3rd level and other domains. This might be clearer if you mention the PSL as a way to explain (not define) RRR. OTOH, you don't use RRR later at all, so you could just delete that term entirely and say a parent is typically an entity one above what's in the PSL, but can be lower down the naming hierarchy, e.g. within an enterprise. - section 2: calling operation 2 the "first one" is confusing, maybe re-order for clarity. Oh, and then you later mean "first one" == "operation 1" - so that does need fixing. Or just delete that para. - 2.1: I think you need to say that the acceptance policy for the very first use of CDS requires some out-of-band agreement, or is just done at the whim of the parent based on a possibly unknown policy. Ah, you do say that in section 3 - maybe consider re-doing the split into sections, e.g. make 2.1 be text at the start of 3. - section 3: I think it'd be good to call out the case where the domain is brand-new (i.e. never before existed) and has a CDS from the very first instant. That might fit in to 3.1, but I think it is worth a mention as a) it's a good goal to have (since it minimises the window without DNSSEC to zero) and so hopefully worth supporting and b) there's arguably no additional risk due to the CDS in this case, since the parent is also adding the delegation at the same time and c) it makes for better automation. That said, I'm not sure what s/w changes supporting that'd imply, but since a lot of parent registry code (APIs and such) are likely home-grown today, calling it out here might help ensure that parents don't all e.g. follow 3.3 or otherwise make DNSSEC-from-the-getgo hard or impossible. - 3.4: Do you need to say that the parent in this case ought monitor the child's DNS and react when the right challenge is visible? If it wasn't already done, this section might also be worth checking with some folks working on acme, as they have analysed such cases.
Alexey Melnikov Former IESG member
No Objection
No Objection
(2016-08-29 for -03)
Unknown
I agree with Kathleen that this is useful document. I also agree with her DISCUSS. I wish you could mandate use of S/MIME or OpenPGP for confirmation emails suggested in the document, but this might be too much to ask for.
Alia Atlas Former IESG member
No Objection
No Objection
(for -03)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2016-09-28 for -03)
Unknown
Will be following the resolutions of others' DISCUSSes. One more place where normative language seems inappropriate: "Turning off DNSSEC reduces the security of the domain and thus should only be done carefully, and that decision SHOULD be fully under the child domain's control."
Alvaro Retana Former IESG member
No Objection
No Objection
(2016-12-13 for -04)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2016-08-30 for -03)
Unknown
I agree with Jari's and Terry's respective discusses. I will watch for the outcome of those discussions. Some other minor comments (I've skipped some that other people have already commented on, but I'm sure there's still overlap): - 1.2: It seems like scenarios 1 and 3 are restatements of the same thing. That is, cannot/does-not-want-to seems to count as an operational limitation. -4, 3rd paragraph: "If a validator sees a DNSKEY or DS record with this algorithm value, it MUST treat it as unknown." I suspect that, in the context of "Right now", this is talking about the current state of affairs, rather than defining a new requirement. Thus the 2119 MUST is probably not appropriate. -- 4th paragraph: I think this MUST is also not appropriate. It's part of the definition of algorithm "0", and not a procedural requirement. Editorial Comments: -1.3, first paragaph: "When this document uses the word CDS it implies that the same applies to CDNSKEY and vice verse." I don't understand this sentence. -2, first paragraph: s/influence/performe -2, operation 2: Please expand KSK on first use -2, 5th paragraph: It’s sort of confusing to talk about options labeled with ordinal numbers in a different order than their labels. -3, first paragraph: First Sentence: I'm not sure what "... enable... for the future." means. Does that mean “for the foreseeable future”, or perhaps “indefinitely enable”? -- 2nd sentence is hard to parse. I suggest the following: OLD Thus during the period from the time the child publishes the CDS until the corresponding DS is published at the parent is the period that DNS answers for the child could be forged. NEW DNS answers could be forged during the period between when the child publishes the CDS until the parent publishes the corresponding DS. -4, third paragraph: "Right now, ..." That language will quickly become dated. I suggest "At the time of this writing, ..."
Benoît Claise Former IESG member
No Objection
No Objection
(for -04)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(for -04)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2016-12-15 for -04)
Unknown
Thanks for the added text.
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2016-08-31 for -03)
Unknown
One technical comment: How does the client know that the parent supports the DNSSEC Delete Algorithm and it actually can turn of DNSSEC after a while? What how long is a while? Would it be possible to define a reply message from the parent to the client to confirm that the deletion was understood? One more or less editorial comment: I agree with Spencer that the use of normative language in the security section is odd. All used SHOULDs should be lower case. But I would also recommend to rephrase to give clear guidance, e.g. OLD: "A parent zone might also consider sending an email to its contact addresses to give the child zone a warning that security will be enabled after a certain amount of wait time - thus allowing a child administrator to cancel the request." NEW: "A parent zone may send an email to its contact addresses to give the child zone a warning that security will be enabled after a defind amount of wait time - thus allowing a child administrator to cancel the request." OR: "A parent zone MAY send an email to its contact addresses to give the child zone a warning that security will be enabled after a defined amount of wait time - thus allowing a child administrator to cancel the request."
Spencer Dawkins Former IESG member
No Objection
No Objection
(2016-08-29 for -03)
Unknown
I understand why most of the 2119 language appears in this draft, but the SHOULDs in this text Users SHOULD keep in mind that re-establishing trust in delegation can be hard and takes a long time. Before deciding to complete the rollover via an unsigned state, all options SHOULD be considered. don't look like 2119 SHOULDs to me. I also note that there's a SHOULD in section 1.2, but 2119 terminology isn't introduced until section 1.4 (easy enough to fix, by moving section 1.4 up, but).
Suresh Krishnan Former IESG member
No Objection
No Objection
(2016-08-31 for -03)
Unknown
Agree with Jari, Terry and would like to see the 7344 situation resolved.
Terry Manderson Former IESG member
(was Discuss)
No Objection
No Objection
(2016-12-15 for -04)
Unknown
Thank you for addressing my concerns. Clearing my DISCUSS.