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

[ Top post ]
We have received a number of comments, and are integrating them.
So far we have mostly just covered Patrik's - I'm posting a newer
version with some of these integrated, so it's easier for folk to see
what the doc looks like with the changes. We plan to post a more
updated version with Paul / Ed's comments later...

On Thu, Apr 3, 2014 at 6:09 PM, Patrik Fältström <paf@frobbit.se> wrote:
> First of all, let me thank the people that have been working so hard on this. I have followed the process, but now again re-read the whole thing, and because of that have some comments. Ignore or think about... :-)
>
>>    This document describes a method for automating maintanance of the
>>    delegation trust information, and proposes a polled / periodic
>>    trigger for simplicity.  Some users may prefer a different trigger,
>>    such as a button on a webpage, a REST interface, DNS NOTIFY, etc.
>>    These alternate / additional triggers are not discussed in this
>>    document.
>
> This is good, but as I would like to have added in the Security Considerations Section (see below) having multiple paths between child dns operator and parental agent increases the risk there are inconsistencies (if intermediary systems are caching information flowing along the paths).
>
> 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.

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

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

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

>> 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. Users (in my experience) seem to take a perverse pleasure
in ignoring MUSTs.

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

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

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

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

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

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

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

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

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

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

A sad day:
Let's say you start with a zone signed with K1
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.

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.

 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!

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

>
>>    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".
Or, the parent polls once a day, but the user can request an immediate
action by asking for 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"?

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

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

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

>
>> 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
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

On Thu, Apr 3, 2014 at 6:09 PM, Patrik Fältström <paf@frobbit.se> wrote:
> First of all, let me thank the people that have been working so hard on this. I have followed the process, but now again re-read the whole thing, and because of that have some comments. Ignore or think about... :-)
>
>>    This document describes a method for automating maintanance of the
>>    delegation trust information, and proposes a polled / periodic
>>    trigger for simplicity.  Some users may prefer a different trigger,
>>    such as a button on a webpage, a REST interface, DNS NOTIFY, etc.
>>    These alternate / additional triggers are not discussed in this
>>    document.
>
> This is good, but as I would like to have added in the Security Considerations Section (see below) having multiple paths between child dns operator and parental agent increases the risk there are inconsistencies (if intermediary systems are caching information flowing along the paths).
>
> 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."
>
>> 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?
>
>> 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.
>
>> 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?
>
>>    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?
>
>> 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?
>
> 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.
>
> 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?
>
> 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.
>
>>    The CDS /
>>    CDNSKEY RRset SHOULD be compliant with the rules in Section 4.1.
>
> Does not match the MUST that covers 4.1.
>
>>    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.
>
>>    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?
>
>>    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!
>
> 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. 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...
>
>>    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.
>
>>    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.
>
>> 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. 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.
>
>> 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?
>
> :
> :
>>    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?
>
>> 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.
>
>> 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".
>
>    Patrik
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>