Managing DS Records from the Parent via CDS/CDNSKEY
draft-ietf-dnsop-maintain-ds-06

[Ballot comment]
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.

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

[Ballot comment]
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."

[Ballot comment]
I don't have an objection to this document changing the status RFC7344 -- but as others have mentioned, the change should be more explicit in the document.  Marking this document as Updating RFC7344 is probably the minimum.

[Ballot comment]
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."

[Ballot comment]
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, ..."

[Ballot discuss]
Thanks for writing this and I think its useful for DNSSEC adoption, my DISCUSS is as follows.

I have a concern about changing the status of RFC7344 in this document from informational to standards track, especially given that this document builds on, or as I see it updates, 7344. This will surely be raised on the telechat. Especially given I still see gaps in the larger picture, such as:

  "In this case there is a possibility of setting up some kind of authentication mechanism and submission mechanism
  that is outside the scope of this document.." for enabling DNSSEC via CDS/CDNSKEY

Can you please promote the first 2 paragraphs of the security considerations section to either the abstract or introduction. When reading this document I had almost exactly those words echoing in my head, and having them up front would better set the scene for why this document should exist - since you have written them already.

[Ballot comment]
can you please clarify:

"In many people's minds, those two operations carry
  more risk than the first one."

I read this as; 'In many people's minds, those two operations carry
  more risk than operation 2."

There are other nits in this document, but I think Stephen has already identified them.

[Ballot comment]

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

[Ballot discuss]
Thanks for this document. I have today reviewed both draft-ietf-dnsop-maintain-ds and RFC 7344, and personally find the recommendations and actions reasonable.

I do have a similar concern as Robert did in his Gen-ART review, however, in making sure that the change to 7344 is properly highlighted. We should talk about this on the call on Thursday.

[Ballot comment]
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).

[Ballot comment]
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.

[Ballot discuss]
Overall, this draft seems like a very useful and helpful draft.  In reading it, I would like to see some security considerations around the methods in section 3, in particular section 3.2, which is the loosest.  Just seeing that the domain has been transferred seems like a risky check to rely on to me.  The risks of using these proposed methods should be stated.  Thanks.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dnsop-maintain-ds-03.txt. If any part of this review is inaccurate, please let us know.

NOTE: Because Section 6.1 does not involve IANA, its text should be moved to another section of the document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the DNS Security Algorithm Numbers subregistry of the Domain Name System Security (DNSSEC) Algorithm Numbers registry located at:

https://www.iana.org/assignments/dns-sec-alg-numbers/

the existing entry for number 0 is to be modified.

The reference [ RFC-to-be ] is to be added to the list of references for this value.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-maintain-ds@ietf.org, "Tim Wicinski" , joelja@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Managing DS records from parent via CDS/CDNSKEY) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Managing DS records from parent via CDS/CDNSKEY'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  RFC7344 specifies how DNS trust can be partially maintained in-band
  between parent and child.  There are two features missing in that
  specification: initial trust setup and removal of trust anchor.  This
  document addresses both these omissions.

  Changing a domain's DNSSEC status can be a complicated matter
  involving multiple unrelated parties.  Some of these parties, such as
  the DNS operator, might not even be known by all the organizations
  involved.  The inability to disable DNSSEC via in-band signalling is
  seen as a problem or liability that prevents some DNSSEC adoption at
  large scale.  This document adds a method for in-band signalling of
  these DNSSEC status changes.

  Initial trust is considered in general to be a hard technical
  problem, this document sets forth reasonable policies that clarify
  and simplify the initial acceptance policy.


Elevating RFC 7344 to standards-track.

Of note, the policy framework described in this document normatively references (thereby including it) a method described in the informational document RFC 7344 . This transition. should be considered it context of advancing this draft.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type: Standards Track

This document describes an in-band method for introducing and removing the Initial DNSSEC trust anchor between a parent and a child domain.  This is done by using the CDS/CDNSKEY DNS RR Types introduced in RFC7344. The document also attempts to produce reasonable initial acceptance policy.

This work is extending the work done in RFC7344, which was published as an Information document.  Time and experience has given the working group insight that the use and deployment of the CDS/CDNSKEY are useful in DNSSEC adoption.  Therefore, with the publication of this document, the previous document should be elevated to Standards Track.

2. Review and Consensus

This working group was very supportive of this document, and discussion was centered around assisting the adoption of DNSSEC, but also the management of the DS Records. There was many constructive comments on the draft that have all been addressed.  The consensus was broad across the working group and the authors addressed all issues raised.

The shepherd also did a detailed editorial review during WGLC to ensure that the document was in a more polished state.

3. Intellectual Property

There are no IPR related to this document.

IANA Considerations

The only IANA Considerations for this document is that the prior document RFC7344 will be elevated from Informational to Standards Track.  Real world experience has should that deploying CDS/CDNSKEY records are useful in the deployment of DNSSEC.

4. Other Points

Once the IANA Considerations above are addressed, There are no downward references in this document,

the

Explain anything else that the IESG might need to know when reviewing this document. If there is significant discontent with the document or the process, which might result in appeals to the IESG or especially bad feelings in the working group, explain this in a separate email message to the responsible Area Director.

Checklist

X Does the shepherd stand behind the document and think the document is ready for publication?

X Is the correct RFC type indicated in the title page header?

X Is the abstract both brief and sufficient, and does it stand alone as a brief summary?

X Is the intent of the document accurately and adequately explained in the introduction?

X Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?

X Has the shepherd performed automated checks -- idnits (see ​http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist),

X Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?

X Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?

X Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?

X If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction?