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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
