Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Warren Kumari <[e-mail]>]

On Thu, Apr 10, 2014 at 3:54 PM, Patrik Fältström <[e-mail]> wrote:
> On 10 apr 2014, at 18:34, Warren Kumari <[e-mail]> wrote:
>
>>> Because of this, I do not mind having some extra words here, like:
>>>
>>> "This proposal do not include all operations needed for maintenance of DNSSEC key material, specifically introduction and complete removal of all keys. Because of this alternate communications mechanisms must always exist, which might introduce extra complexity."
>>
>> DONE.
>
> Thanks!


No worries, we aim to please!

>
>>>> 2.2.1.  Solution Space
>>> :
>>> :
>>>>   Some parents want the child to express their DNSKEYS in the form of
>>>>   DS records, while others want to receive the DNSKEY records and
>>>>   calculate the DS records themselves.  There is no consensus on which
>>>>   method is better; both have good reasons to exist.  The proposal
>>>>   below can operate with both models, but the child needs to be aware
>>>>   of the parental policies.
>>>
>>> Mumble...I really dislike the fact we have not agreed on what to do. It increases complexity _a_lot_. And yes, this is one of the reasons why we do not see more deployment of DNSSEC.
>>>
>>> Why do we (IETF) fail on this?
>>>
>>
>> Yes; however, we want this to be deployed and usable by as many people
>> as possible, so we are avoiding the religious argument in this
>> document. Registry operators are entitled to their own opinion, as
>> much as we dislike it....
>
> This is not YOUR fault, and you can not fix this problem in THIS draft. I just find it being...not fun.

Yup, me too.
If they made me President of the Universe:
1: SPAM would be a capitol offense.
2: All movies **MUST** (RFC2119-style) contain a blooper reel (if
nothing funny happened while filming, well then film some more...)
3: Everyone would take DNSKEYs (I used to think DS but Antoin
convinced me otherwise....).
4: By the time they reach 21, everyone would have to have visited at
least 3 other countries, with noticeably different language and
culture (government assistance would be provided to those who really
cannot afford this on their own).
5: Kylie Minogue's "Locomotion" would be banned. I dislike censorship
as much as the next person, but you have to draw the line somewhere.

>
>>>> 2.2.2.  DNSSEC key change process
>>>>
>>>>   After a Child DNS operator first signs the zone, there is a need to
>>>>   interact with the Parent, for example via the delegation account
>>>>   interface, to "upload / paste-in the zone's DS information".  The
>>>>   action of logging in through the delegation account user interface
>>>>   authenticates that the user is authorized to change delegation
>>>>   information for the child published in the parent zone.  In the case
>>>>   where the "Child DNS Operator" does not have access to the
>>>>   registration account, the Child needs to perform the action.
>>>>
>>>>   At a later date, the Child DNS Operator may want to publish a new DS
>>>>   record in the parent, either because they are rolling keys, or
>>>>   because they want to publish a stand-by key.  This involves
>>>>   performing the same process as before.  Furthermore when this is a
>>>>   manual process with cut and paste, operational mistakes will happen
>>>>   -- or worse, the update action is not performed at all.
>>>
>>> Should it not be mentioned here that child might want to remove all keys as well? I mean, if this is supposed to be a complete list of potential operations the child is interested in?
>>>
>>> I see in fact (with some special cases):
>>>
>>> A. Introduction of new keys
>>>
>>> A.1. Introduction when old keys exists and can be used
>>>
>>> A.2. Introduction when no old keys can be used (because they can not be trusted or because no such exists)
>>>
>>> B. Removal of keys
>>>
>>> B.1. Removal of old keys when at least one key still remains in the RRSet of zone apex
>>>
>>> B.2. Removal of last key from the RRSet of the zone apex
>>>
>>> If I understand things correctly, you say this draft can only be used for A.1 and B.1?
>>>
>>> I think that should be spelled out very explicitly in section 2.
>>
>> We had specifically decided not to allow B.2 because we don't want
>> this be be used to go from signed to unsigned.
>
> That is fine.
>
>> You also cannot use
>> this for initial enrollment of keys (A.2 - explained in Section 2.2.2
>> & the security considerations section), you can only use it for
>> introducing new keys when you have one working key and removing all
>> except the last key. Added text to clarify what use cases we do and do
>> not support.
>
> Thanks!
>
>> We also had, in the intro: "This proposal does not include all
>> operations needed for the maintenance of DNSSEC key material,
>> specifically the introduction or complete removal of all keys."
>
> Yup, I did understand this, but just felt it was not really crystal clear enough. I know DNSSEC (I think....:-) ) and still had to look at some of the text a few times to ensure that there where no loopholes.

I *think* the -04 version addresses this now -- good 'nuff?
Actually, in my edit buffer (which will become -05 -- "Launch and
iterate") I have:
"This proposal does not include all operations needed for the
maintenance of DNSSEC key material, specifically the initial
introduction or complete removal of all keys. Because of this,
alternate communications mechanisms must always exist, potentially
introducing more complexity."



>
>>>> 4.  Automating DS maintainance with CDS/CDNSKEY records
>>>>
>>>>   CDS/CDNSKEY records are intended to be "consumed" by delegation trust
>>>>   maintainers.  The use of CDS/CDNSKEY is optional.
>>>>
>>>>   Some parents prefer to accept DNSSEC key information in DS format,
>>>>   some parents prefer to accept it in DNSKEY format, and calculate the
>>>>   DS record on the child's behalf.  Each method has pros and cons, both
>>>>   technical and policy.  This solution is DS vs DNSKEY agnostic, and
>>>>   allows operation with either.
>>>>
>>>>   If the child knows what the parent prefers, they can publish the
>>>>   parent's preferred record type.  If the child does not know (or
>>>>   simply chooses to), they can publish both CDS and CDNSKEY.  If the
>>>>   child publishes both, the two RRsets they SHOULD match in content.
>>>
>>> Why not a MUST?
>>
>> DONE.
>> Ok, this is somewhat of a philosophical discussion -- I'm always
>> uncomfortable putting a MUST on anything where a user enters the
>> information.
>
> Aha.
>
>> Users (in my experience) seem to take a perverse pleasure
>> in ignoring MUSTs.
>
> I did not see this as a "GUI"-issue... Hmm...
>
>> Having this as a MUST makes me concerned that implementations will
>> treat cases where the data does not match as an error -- and we
>> specifically don't want that (more below).
>
> Hmm...
>
>> If you are one of the
>> registries that likes DNSKEYS (and so consumes CDNSKEY), you shouldn't
>> care what's in the CDS...
>> But, a number of folk have said that they would rather that this be a
>> MUST, so I've just changed it...
>
> The only alternative I can see is to not say anything about whether they are the same or not, but instead say that whoever consumes the CDS and CDNSKEY MUST be able to pick one of them (and not the other), and it is the parent that do the selection that can be random. Whether the CDS and CDNSKEY is the same or not is up to the child. The parent will only pick one. And things must still work.

That was what we were trying to say. I guess we failed. Anyway, we
have liberally sprinkled MUSTs all over what the child should^w must
do :-)
We specifically wanted to allow the child to publish only CDS if they
a: so choose and b: know that their parents take DS.
Some folk want to be able to prepublish DS and keep their DNSKEY
hidden until "needed". "

In my -05 edit buffer:
The child SHOULD publish both CDS and CDNSKEY. If the child knows
which the parent consumes, it MAY choose to only publish that record
type (for example, some children wish the parent to publish a DS, but
they wish to keep the DNSKEY "hidden" until needed). If the child
publishes both, the two RRsets MUST match in content. The parent
should use whichever one they choose, but SHOULD NOT query for both
and perform consistency checks between the CDS and CDNSKEY records.

Note: It is not an error for a child to have published CDS records and
not have CDNSKEYs that hash to those records, nor for there to be
CDNSKEY records without matching CDS records. This is because a child
might have been publishing CDS records and then the parent's policy
changes to require CDNSKEY records. The child might forget to remove
the CDS, etc. This avoids all sorts of error conditions / complexity,
etc"

Is this better / clearer? I'm uncomfortable with the "If the child
publishes both, the two RRsets MUST match in content.". It sort of
sounds like the rdata must be identical. Can anyone suggest better
text? "the two RRsets MUST have the same semantic meaning?" something?



>
>>>>   The parent should use whichever one they choose, but SHOULD NOT query
>>>>   for both and perform consistency checks between the CDS and CDNSKEY
>>>>   records.
>>>
>>> Why not? Why talk about it at all?
>>>
>>> I think this document should say:
>>>
>>>   The child can publish one or both of CDS and CDNSKEY.  If the
>>>   child publishes both, the two RRsets they MUST match in content.
>>>
>>> We do not need more RFCs that can be interpreted in multiple ways. And why use more words than what we need?
>>
>> See above, the Editor note ("It is not an error for a child to have
>> published CDS records and not have CDNSKEYs that hash to those
>> records, nor for there to be CDNSKEY records without matching DS
>> records.
>
> This I understand.
>
>> This is because a child might have been publishing CDS
>> records and then the parent's policy changes to require CDNSKEY
>> records. The child might forget to remove the CDS, etc. This avoids
>> all sorts of error conditions / complexity, etc"), and Section 6.
>
> Ack. I did not think of this situation. But the parent might also swap back, and then will eat the old DS again, which creates problems.

Yup. See new text above.

>
> So the parent might select randomly CDS or CDNSKEY, without the child knowing which one, and things should still work. This implies to me that from the parents perspective use of the CDS and use of CDNSKEY is to lead to the same result. Because of this, they MUST be the same.
>
> But I get the point about "error condition".
>
>> This data / information might be coming from user input (yes, we
>> expect that signer tools will create these, but user's might also
>> enter them).  We'd much rather be liberal in what we accept when it
>> comes to user input.
>
> Agree.
>
>> If we were to *require* that they match, what happens in the case
>> where they *don't*? Do we fail the keyroll? That seems suboptimal. Do
>> we throw a log message? No one will see it... If you consume CDS (or
>> CDNSKEY), you simply ignore the other one -- it's not really relevant
>> to you, and no good can come from looking at it. Ignorance is bliss...
>
> Understood.
>
> But I think you must explain what the parent should do.

How is:
"The child SHOULD publish both CDS and CDNSKEY records. If the child
knows which the parent consumes, it MAY choose to only publish that
record type (for example, some children wish the parent to publish a
DS, but they wish to keep the DNSKEY "hidden" until needed). If the
child publishes both, the two RRsets MUST match in content. The parent
should use whichever one they choose, but MUST NOT query for both and
perform consistency checks between the CDS and CDNSKEY records."

I cleaned this up (see above) - is it clear enough now?

>
> Fetch CDS and CDNSKEY, look at them and see that they lead to different result. What should then the parent do? Pick CDS or CDNSKEY, or pick one by random, or...?
>
>>>> 4.1.  CDS / CDNSKEY processing rules
>>>>
>>>>   If there are no CDS / CDNSKEY resource records in the child, this
>>>>   signals that no change should be made to the current DS set.  This
>>>>   means that, once the child and parent are in sync, the child DNS
>>>>   operator MAY remove all CDS records from the zone.
>>>
>>> I am really nervous we will have a state enforced somewhere, that must remember what has happened. I much rather want to see the child always have CDS/CDNSKEY for the proper key set.
>>>
>>> So, there must be a reason why this is not allowed?
>>
>> Much of the point of this is to *avoid* the parent having to keep
>> state. If it queries the zone and sees no CDS records, it simply goes
>> back to sleep.
>>
>> Let's say that example.com is signed but has never used CDS / CDNSKEY
>> (like every signed zone currently is). We really don't want the parent
>> going through and removing DS records because there is no CDS
>> published :-) By having a "take no action if there is no CDS/CNSKEY"
>> rule the parent doesn't need to track which children use this.
>
> Ok, I was thinking of the fact that one can not remove the last DS/DNSKEY, so "neither CDS, nor CDNSKEY" is a special case (as you say), so I do not see any problem with the situation you talk about.
>
> I was thinking of the last sentence that ask the child to poll parent and see whether DS is published, and if so, remove the CDS/CDNSKEY.
>
> What I do not want is having people enforcing children to keep polling parent. This by tell DNS hosting providers they are doing the wrong thing if they do not remove the CDS/CDNSKEY.
>
> Secondly, the reason why you have to remember state here and there is because of the following can happen:
>
> 1. Zone signed with K1
> 2. K1 is published in parent
> 3. CDS for K1 is published
> 4. CDS for K1 is removed
> 5. Zone signed with K1 and K2
> 6. CDS for K1 and K2 is added
> 7. Parent pick up CDS for K1 and K2
> 8. Parent publish data for K1 and K2
> 9. Child remove CDS for K1 and K2
> 10. Zone signed with K2
> 11. CDS for K2 is published
> 12. Parent pick up CDS for K2
> 13. Parent remove DS for K1
>
> Much easier, I claim, specifically when K1 disappears:
>
> 1. Zone signed with K1
> 2. K1 is published in parent
> 3. CDS for K1 is added
> 4. Zone signed with K1 and K2
> 5. CDS for K2 is added (CDS for K1 is already there)
> 7. Parent pick up CDS for K1 and K2
> 8. Parent publish data for K2 (in addition for already existing data for K1)
> 9. Zone signed with K2
> 10. CDS for K1 removed
> 11. Parent detect CDS for K1 is removed
> 12. Parent remove DS for K1
>
>>> Also, the MAY here does not match the SHOULD further down.
>>>
>>>>   Following acceptance rules are placed on the CDS / CDNSKEY records as
>>>>   follows:
>>>>
>>>>   o  Location: "the CDS / CDNSKEY record MUST be at the child zone
>>>>      apex".
>>>>
>>>>   o  Signer: "MUST be signed with a key that is represented in both the
>>>>      current DNSKEY and DS RRset's."
>>>>
>>>>   o  Continuity: "SHOULD NOT break the current delegation if applied to
>>>>      DS RRset"
>>>
>>> I do not understand the SHOULD NOT in this case. Specifically together with references to 4.1 below.
>>>
>>
>> DONE.
>> Yeah. This should be a MUST NOT. Fixed.
>
> Thanks!

"Service with a smile"

>
>>> I presume what this says is that the DNSKEY that is signing the CDS/CDNSKEY SHOULD be included in what the CDS / CDNSKEY is covering?
>>>
>>> If that is true, are we sure that the SHOULD NOT is inverse to SHOULD in this case?
>>>
>>>>   If any these conditions fail the CDS / CDNSKEY record MUST be
>>>>   ignored.
>>>
>>> How can it be a MUST when Continuity include a SHOULD NOT?
>>
>> DONE.
>> Yup, see above. Fixed.
>
> +1
>
>>> I am a bit confused, but maybe it ends up being clearer if I actually wrote code that implemented this ;-)
>>>
>>>> 5.  Child's CDS / CDNSKEY Publication
>>>>
>>>>   Child DNS Operator SHOULD only publish a CDS or CDNSKEY RRset when it
>>>>   wants to make a change to the DS RRset in the Parent.
>>>
>>> Does not match the MAY further up.
>>
>> DONE.
>> Fixed.
>
> +1
>
>>>>   The CDS /
>>>>   CDNSKEY RRset SHOULD be compliant with the rules in Section 4.1.
>>>
>>> Does not match the MUST that covers 4.1.
>>
>> DONE.
>> I guess this is a philosophical difference. I am somewhat leery about
>> using MUST when it comes to user input. We put in SHOULD, to
>> acknowledge that users will often do "wrong" things, it just means
>> that the record will not be valid/processed. I recognize that I'm off
>> in the rough on this, so changed to a must...
>
> Understood. Just ensure the text matches as this is covered in multiple places.
>
>>>>   When the Parent DS is "in-sync" with the CDS / CDNSKEY, the Child DNS
>>>>   Operator MAY delete the CDS / CDNSKEY RRset(s).
>>>
>>> See above. How does the child know? Do you because of this require the child to poll the parent zone? And if the parent want to re-fetch the data for some reason, it might be gone from the child zone. Not good.
>>
>> Yes, the child checks the parent to see if it's in sync. A number of
>> working group participants (I had thought yourself included), had
>> indicated that they would rather have this as more of a transaction
>> system, so that the user publishes a record, the parental agent
>> performs the operation, and then the user is expected to remove the
>> "instruction." The reason for this was so that the user's intent is
>> clear and parental agents can, if they wish, log the "transaction." I
>> will see if I can find references to that (it's not noted in the minutes, but
>> I think Antoin Verschuren said it and a bunch of other folk agreed).
>
> See above.
>
> I am lazy as a programmer. I do not want people to start to REQUIRE the CDS/CDNSKEY to be removed. It must be perfectly ok to have the CDS/CDNSKEY in the zone all the time.
>
> Maybe I am more relaxed if you explicitly say that is a normal case.

Just sent mail to the list explicitly asking which folk would prefer.
My preference is that children just leave the records around (and
update the doc to say so). We had originally put this in because
someone asked us too (and we cannot remember who that was!).
Hopefully folk will want the behavior you (and Matthijs) are asking for.

>
>>>>   Note that if the
>>>>   child has published a DNSKEY RR in the CDS, it will have to calculate
>>>>   the DS (using the requested digest algorithm) to do the comparison.
>>>
>>> Hmmm..."published a DNSKEY RR in the CDS"? The CDS was to include a DS. Right?
>>
>> Edited for clarity -- left over from an old version of the doc.
>
> :-)
>
>>>>   A child MAY publish both CDS and CDNSKEY.  If a child chooses to
>>>>   publish both, it SHOULD attempt to maintain consistency (a matching
>>>>   CDS for each CDNSKEY)
>>>
>>> No, it MUST represent the same data. Please!
>>
>> DONE.
>> It seems like you feel strongly about this :-) My reason for
>> originally having this as a SHOULD are described above (expecting
>> users the follow a MUST leads to implementers to treat "violations" of
>> the MUST as an error...). But, seems like I'm off in the rough,
>> changed...
>
> Ha ha ha...
>
> See above, I now understand.
>
> I want to know what happens both from the child and parent perspective IF the CDS and CDNSKEY differs.
>
> Just say what the result should be.
>
> Parent pick one at random?

In edit buffer (S4):
"The child SHOULD publish both CDS and CDNSKEY. If the child knows
which the parent consumes, it MAY choose to only publish that record
type (for example some children wish the parent to publish a DS, but
they wish to keep the DNSKEY "hidden" until needed). If the child
publishes both, the two RRsets MUST match in content. The parent
should use whichever one they choose, but MUST NOT query for both and
perform consistency checks between the CDS and CDNSKEY records."



>
>>> I also want to have it spelled out explicitly here whether the CDS/DNSKEY MUST include the data for the dnssec key material that signs the CDS/DNSKEY or not. I think it MUST include the current key as well.
>>> Otherwise it ends up being same as having no CDS/CDNSKEY and that way removing keys.
>>
>> Nope, you don't *have* to -- you probably would want to, but it isn't
>> (IMO) a strict MUST.
>
> :-)
>
>> A happy day:
>> Let's say you start with a zone signed with K1
>
> Plus:
> K1 is in parent zone
>
>> You generate a new key, K2.
>> You sign your zone with K1 and K2.
>> You publish K2 (only) in the zone (in a CDS), signed with K1.
>> Your parent picks up the CDS and validates the K2 CDS using K1.
>> The draft says: "In particular the Parental Agent MUST double check
>> the Continuity rule and do its best not to invalidate the Child zone."
>> - publishing only K2 will not break the Continuity rule (Continuity:
>> "MUST NOT break the current delegation if applied to DS RRset") and so
>> the parent publishes only K2.
>
> Plus:
> The parent removes K1
>
>> A sad day:
>> Let's say you start with a zone signed with K1
>
> Plus:
> K1 published by parent
>
>> You generate a new key, K2.
>> You get sidetracked and forget to sign your zone with K2 (or you
>> somehow otherwise screw up).
>> You publish K2 (only) in the zone (in a CDS), signed with K1.
>> Your parent picks up the CDS and validates the K2 CDS using K1.
>> The draft says: "In particular the Parental Agent MUST double check
>> the Continuity rule and do its best not to invalidate the Child zone."
>> - publishing only K2 would violate the continuity rule, and so the
>> parent does not proceed.
>
> Agree.
>
>> If it were *me*, I'd publish a CDS with *both* K1 and K2, wait a
>> little bit, then publish only K2, but this is not a required way of
>> rolling keys.
>
> Nope, the fact there is no CDS/CDNSKEY for K1, data for K1 MUST be removed (as there is CDS/CDNSKEY for K2). So with your way of doing things, you would violate some earlier rules in the RFC. Right?
>
> I.e. you either break the continuity rule OR you break the rule that K1 MUST be removed when the CDS/CDNSKEY is removed.
>
>> So that at every point in time the chain of trust is secured.
>>>
>>> So one go from:
>>>
>>> 1. No keys at all
>>>
>>> This process can not be used, but say DNSKEY K1 is added. CDNSKEY K1 is added to the zone.
>>>
>>> 2. K1 is in use
>>>
>>> K2 is introduced by adding CDNSKEY for K1 and CDNSKEY K2 be added to the zone. Signed by at least K1.
>>>
>>> 3. K1 and K2 is in use
>>>
>>> Ensure that CDNSKEY for K1 and CDNSKEY K2 are both signed with at least K2.
>>>
>>> 4. K2 is in use
>>>
>>> Remove CDNSKEY for K1.
>>>
>>> 5. K2 is in use
>>>
>>> Removal of K2 without introducing K3 is not possible.
>>>
>>> 6. No key is in use
>>>
>>> See 1.
>>>
>>>> 6.  Parent side CDS / CDNSKEY Consumption
>>>>
>>>>   The CDS / CDNSKEY RRset MAY be used by the Parental Agent to update
>>>>   the DS RRset in the parent zone.  The Parental Agent for this uses a
>>>>   tool that understands the CDS / CDNSKEY signing rules from
>>>>   Section 4.1 so it may not be able to use a standard validator.
>>>
>>> What do the author know about "standard validators"? :-)
>>>
>>>>   Parent SHOULD treat the Continuity rule as "MUST".
>>>
>>> Well...here we have confusion. The continuity rule is a SHOULD, the whole block is a MUST and above it is sort of wobbly...
>>>
>>
>> DONE.
>> Ok. This was yet another instance of me being timid and not not liking
>> telling people what to do!
>
> See above. Just make text consistent!
>
>>>>   The parent MUST choose to accept either CDS or CDNSKEY records, and
>>>>   MUST NOT expect there to be both.  A parent SHOULD NOT perform a
>>>>   consistency check between CDS and CDNSKEY (other than for
>>>>   informational / debugging use).
>>>
>>> Ok. Do though see above about MUST regarding client requirement on having the two RR in sync if both exists.
>>>
>>>> 6.1.  Detecting a changed CDS / CDNSKEY
>>> :
>>>>   Pushing  The delegation user interface has a button {Fetch DS} when
>>>>         pushed preforms the CDS / CDNSKEY processing.  If the Parent
>>>>         zone does not contain DS for this delegation then the "push"
>>>>         MUST be ignored.
>>>
>>> Well, I do not think there should be a MUST. As written below there might be other means that can be used to ensure the data is correct. Saying SHOULD is ok. Together with explanation what risk exists. Like:
>>>
>>> ...then the "push" SHOULD be ignored. Reasons for the "push" to be trusted might be additional user interface/interactions, two factor authentication to validate the "push" and similar.
>>
>> Hmmm.. If I'm understanding what you are suggesting, you would like a
>> user to be able to go to a web page, click the "Fetch DS" button and
>> have this used for initial enrollment? This still seems like a bad
>> idea to me -- unless it is explicitly a "Fetch DS, show user what was
>> fetched and ask him to confirm the submission".
>
> Something like that.
>
>> We do have some text in the security section saying that this should not be
>> used for initial key enrollment as we don't really want to be dictating parental
>> behavior for this.
>
> The problem is that exactly this is what people ask for... :-P
>
> How often do you click "yes" and "no" when your ssh client show you an initial fingerprint? ;-)

Well, I never click Yes *and* No :-)

Do you like:
"The delegation user interface has a button {Fetch DS} when pushed
preforms the CDS / CDNSKEY processing. If the Parent zone does not
contain DS for this delegation then the "push" SHOULD be ignored. If
the Parental Agent displays the contents of the CDS / CDSNKEY to the
user and gets confirmation that this represents their key, the
Parental Agent MAY use this for initial enrolment (when the Parent
zone does not contain the DS for this delgation). "



>
>>>>   In either case the Parental Agent MAY apply additional rules that
>>>>   defer the acceptance of a CDS / CDNSKEY change, these rules may
>>>>   include a condition that the CDS / CDNSKEY remains in place and valid
>>>>   for some time period before it is accepted.  It may be appropriate in
>>>>   the "Pushing" case to assume that the Child is ready and thus accept
>>>>   changes without delay.
>>>
>>> Does not work if you have a MUST above. Just remove this paragraph.
>>>
>>> Either you have a MUST or not. Not MUST and then a paragraph that make things not a MUST.
>>
>> Um, what? Above doesn't parse for me.
>> A legitimate use case is that the parent polls for keys, but doesn't
>> do anything with them until the user click "Please make the change".
>
> Aha.
>
>> Or, the parent polls once a day, but the user can request an immediate
>> action by asking for it.
>
> Ok, I get it.
>
>>>> 6.2.  Using the new CDS / CDNSKEY records
>>>>
>>>>   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.  It would be a
>>>>   good idea if the Parental Agent checked all NS RRs listed at the
>>>>   delegation.
>>>
>>> What does "would be a good idea" mean in RFC 1918 speak? :-)
>>>
>>> More seriously, no, I do not think that requirement should be there at all.
>>
>> Which one? I'm assuming you are fine with / like the "Parental Agent
>> MUST use a DNSSEC validator"?
>
> I just wanted to know in official MAY/MUST/SHOULD language what "be a good idea" means first of all.
>
>>> How to handle lame delegation, inability to use cached information, what TTL can be acceptable etc is hidden in this "good idea". Just remove it.
>>>
>>> Either DNS is used to fetch the RR or not.
>>>
>>>>   The Parental Agent MUST ensure that old versions of the CDS / CDNSKEY
>>>>   RRset do not overwrite newer versions.
>>>
>>> I do not think this is a good idea. See above.
>>>
>>> Please remove.
>>>
>>> This is because there is a requirement on state in the parent. I dislike that. Much better if the CDS/CDNSKEY is always reflecting the current state in the child zone. And just say so.
>>
>> This was specifically added because folk asked for it. You have a
>> "primary" DNS server and a bunch of "secondaries" (by "primary" and
>> "secondary" I mean you have one server where you make the changes, and
>> the others all slave from it).
>> You are in the process of rolling from key BAR to key FOO.
>>
>> You have:
>> . CDS KEY_FOO on the primary.
>> and
>> . CDS KEY_BAR on the secondaries because they have not yet AXFRed the zone.
>>
>> The parent chooses an NS at random - it picks the "primary" and
>> updates what it publishes for the child.
>> It then tries again, and happens to hit a "secondary".. and updates
>> what it publishes for the child.
>> Lather, rinse, repeat.
>
> No, I absolutely do not like this.
>
> You also have caching, you have lame delegation and a million other things.
>
> This is why we do key rollover with multiple keys.
>
> So you never jump from CDS KEY_FOO to CDS KEY_BAR in one hop. You always have them overlap, OR, you get the problem you talk about. And it is not the parents responsibility to ensure you do not as a child shoot yourself in your foot.
>
> We already have too many parents that have I do not know how many stupid rules for what various values must be in the child hosting situation, and in many cases that make it plain impossible to do what you want as a child. Really silly rules.
>
> Parent should not control the child.
>
> If the child do NOT want the problem you talk about, have overlapping CDS/CDNSKEY. If you want to jump quickly, do what you suggest with non overlapping CDS/CDNSKEY but risk that the wrong DS might be published in parent zone. Up to you as a child.
>
> Compared to many other things that I suggest, I can give up my arguments, but not this. This I must really be convinced why I am wrong.

Ok. Fair. Removed.

>
> And you have btw not said what happens when you have a lame delegation in your scenario. Or when you do not get a response. Or when you get a response over IPv4 but not IPv6. Or when you can not even send a DNS query to the IP address of one of the auth servers because you do not have that IP address in your routing table. It might be an RFC 1918 address. Or you might be behind a firewall that do not allow any direct DNS queries, you can only issue queries via a forwarder. Or...
>
>>>> 6.2.1.  Parent calculates DS
>>>>
>>>>   There are cases where the Parent wants to calculate the DS record due
>>>>   to policy reasons.  In this case, the Child publishes CDNSKEY records
>>>>   containing DNSKEYs.
>>>>
>>>>   The parent calculates the DS records on behalf of the children.  The
>>>>   DNS Parent needs to publish guidelines for the children as to what
>>>>   digest algorithms are acceptable in the CDS record.
>>>
>>> What is "needs to"? MUST?
>>
>> I guess. This wasn't a requirement, more of a "I think that parents
>> should do this sort of thing anyway."
>> I'll just remove that sentence...
>
> :-)
>
>> :
>>> :
>>>>   Implications on Parental Agent are that the CDNSKEY and DS are not
>>>>   exactly the same after update thus it needs to take that into
>>>>   consideration when checking CDNSKEY records.  Same goes for the Child
>>>>   DNS Operator, it needs to be able to detect that the new DS RRset is
>>>>   "equivalent" to the current CDNSKEY RRset, thus it can remove the
>>>>   CDNSKEY RRset.
>>>
>>> Why not say instead:
>>>
>>> In the case the parent fetch the CDNSKEY and calculate the DS it MAY be the case that the DS published in the parent zone is not identical with the data in the CDS record made available by the child.
>>>
>>> Because I think that is what you try to say?
>>
>> DONE.
>> Yup, this is cleaner.
>
> Phew...
>
>>>
>>>> 9.  Security Considerations
>>>
>>> Please add something like:
>>>
>>> As this introduces a mechanism to contact the parent it MUST be clear who is fetching the records and creates the appropriate records in the parent zone. Specifically as some operations MUST be using other mechanisms than what is described here. If for example communication normally is done via a registrar that via epp is communicating with the registry, the registrar is normally "caching" the data passed to it. If then the registry is fetching the CDS / CDNSKEY then the registry have a different view of the DNSSEC key material situation than the registrar, and the result of such a situation is unclear. Because of this, this mechanism SHOULD NOT be use to bypass intermediaries that might cache information and because of that get the wrong state.
>>
>> I reworded this to be:
>> "As this introduces a new mechanism to update information in the
>> parent it MUST be clear who is fetching the records and creating the
>> appropriate records in the parent zone. Specifically some operations
>> may use other mechanisms than what is described here. For example, a
>> registrar may assume that it is maintaining the DNSSEC key information
>> in the registry, and may have this cached. If the registry is fetching
>> the CDS / CDNSKEY then the registry and registrar may have different
>> views of the DNSSEC key material and the result of such a situation is
>> unclear. Because of this, this mechanism SHOULD NOT be use to bypass
>> intermediaries that might cache information and because of that get
>> the wrong state. "
>
> Thanks!
>
>>>> 10.  Acknowledgements
>>>>
>>>>   We would like to thank a large number of folk, including: Mark
>>>>   Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian
>>>>   Dickinson, Paul Ebersman, Tony Finch, Patrik Faltsrom, Jim Galvin,
>>>
>>> Please spell my last name "Faltstrom".
>>>
>>
>> DONE.
>
> ;-)
>
>    Patrik
>

W