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

From: Tim Wicinski <[email-masked]>
Date: Wed, 02 Apr 2014 15:07:51 -0400

Greetings,

This is the starting of the WGLC on Automating DNSSEC delegation trust 
maintenance.  This was briefly covered in London and these are ready for 
WGLC.   The current versions of this documents can be found here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt

We'll have a 2 week period for comments, closing on April 16th, 2014.

thanks
tim

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 3 Apr 2014 12:09:30 +0200

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 3 Apr 2014 12:22:05 +0200

> What does "would be a good idea" mean in RFC 1918 speak? :-)

Hmm...not enough coffee...RFC 2119 of course.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Apr 2014 09:54:26 -0700

Greetings again. It is quite important that there be an interoperable mechanism where a child can say to its parent "please update your DS for me" in a secure fashion. Parents don't need to implement this mechanism: they can still do the updates in non-interoperable fashions like they do today and nothing will be worse. However, to get greater deployment of DNSSEC, we need to make the operations of the DNSSEC records more automated without reducing security.

At this point, I'm unconvinced that doing the DS update through the DNS is the right method. If it is the right method, draft-ietf-dnsop-delegation-trust-maintainance is probably OK after a bit of updating. However, the flaws that both Patrik and Ed have brought up indicate that the document might need even more words, and more mechanisms, than it has now. It feels like it has the same amount of creep that NSEC and NSEC3 did. Maybe that's a good thing, but it doesn't feel that way to me.

At various meetings, people have said that we should be doing this update using a real update protocol like HTTPS. I have thought that is right, but now I'm not sure. Each time I sketch that out, it is almost as complicated as this draft. Getting the authentication right will actually be harder than what is in this draft.

Some particular notes on the current draft:

- It says too much loosely. It can be shorted in ways that will make it less likely that people will mis-implement by taking out the off-hand remarks that are mostly about use cases. Search for "etc" and see whether those lists or whole paragraphs can be removed.

- There are places that use SHOULD instead of MUST but don't explain the exceptions. Some of those places open security holes if they are not explained. Every SHOULD needs an explanation.

- In Section 1, the phrase "their DS record(s) (or DNSKEY(s))" is completely unclear until you get to Section 3. Instead, until you say that there are two things that a child might tell its parent, consistently talk about "information that would cause the parent to update the DS record". Before 1.1, put a new section that describes why there are two records, admit that this might be confusing, and say that it's here because different parents want different things. But the big point is to not treat the two records as equivalent: treat them as both having the same result, that the parent will create a new DS.

- The document uses "change" and "roll" for the reasons for wanting a new DS. They are different, and "roll" is a subset of "change". (A child might want a change because they are changing signing algorithms, or they might want a change because they are rolling a key within the same algorithm.) Use "change" throughout, and leave "roll" to other documents.

- The text throughout would be easier to read if it used "Child DNS Operator" instead of "Child DNS operator"; same for the "Parent DNS Operator".

- In 6.2, the discussion of "old version" and "new version" is completely unclear. It needs to be specific about what the contents of a "version" is.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 9 Apr 2014 06:42:54 +0800

> We'll have a 2 week period for comments, closing on April 16th, 2014.

Just a quick note -- Olafur and I have been a little swamped (travel,
the TLS heartbeat vulnerability, etc), and have been having a hard
time sync'ing up to discuss the comments.
Just wanted to let y'all know that we are not simply ignoring you - we
appreciate the comments and want to deal with them all in one go...

W

>
> thanks
> tim
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Apr 2014 00:34:11 +0800

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

> "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 mech…

DONE.

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

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

>>    child publishes both, the two RRsets they SHOULD match in content.

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

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

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

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

> How can it be a MUST when Continuity include a SHOULD NOT?

DONE.
Yup, see above. Fixed.

> Does not match the MAY further up.

DONE.
Fixed.

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

> 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 zo…

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

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

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

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

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

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

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.

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

> Because I think that is what you try to say?

DONE.
Yup, this is cleaner.

> 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 usi…

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

> Please spell my last name "Faltstrom".

DONE.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Apr 2014 21:54:41 +0200

>> "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 mec…

Thanks!

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

> this be be used to go from signed to unsigned.

That is fine.

> You also cannot use

Thanks!

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

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

> specifically don't want that (more below).

Hmm...

> If you are one of the

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.

> records, nor for there to be CDNSKEY records without matching DS

This I understand.

> This is because a child might have been publishing CDS

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.

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

> enter them).  We'd much rather be liberal in what we accept when it

Agree.

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

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

> 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

> Yeah. This should be a MUST NOT. Fixed.

Thanks!

>> How can it be a MUST when Continuity include a SHOULD NOT?

+1

>> Does not match the MAY further up.

+1

> in the rough on this, so changed to a must...

Understood. Just ensure the text matches as this is covered in multiple places.

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

> Edited for clarity -- left over from an old version of the doc.

:-)

> the MUST as an error...). But, seems like I'm off in the rough,

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?

> Nope, you don't *have* to -- you probably would want to, but it isn't

:-)

> Let's say you start with a zone signed with K1

Plus:
K1 is in parent zone

> the parent publishes only K2.

Plus:
The parent removes K1

> Let's say you start with a zone signed with K1

Plus:
K1 published by parent

> - publishing only K2 would violate the continuity rule, and so the

Agree.

> little bit, then publish only K2, but this is not a required way of

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.

> telling people what to do!

See above. Just make text consistent!

> fetched and ask him to confirm the submission".

Something like that.

> used for initial key enrollment as we don't really want to be dictating parental

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? ;-)

> 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

Ok, I get it.

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

> what it publishes for the child.

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.

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

> I'll just remove that sentence...

:-)

>> Because I think that is what you try to say?

Phew...

> intermediaries that might cache information and because of that get

Thanks!

>> Please spell my last name "Faltstrom".

;-)

   Patrik

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 11 Apr 2014 11:36:21 +0200

Hi,

On 04/10/2014 09:54 PM, Patrik Fältström wrote:
>>>> 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.
>>> 
>> 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....
> 

I had proposed to have one CDS record that has the RDATA identical as
the DNSKEY record, plus a hash digest type field. For example:

    example.com. 86400 IN CDS *1* 257 3 8 AwEAA...

This would work for both agents that want DS and agents that want
DNSKEY. Counter arguments from Warren were:

1. No, because now the parents who want DS are not getting DS -- they
are getting DNSKEY.

My understanding was that the reason why parents want DS is so that the
child can determine the hash digest to be used. So the format of the CDS
record does not really matter.

2. Some children want to be able to publish a DS record, but not expose
the DNSKEY until they start using it -- the method you have described
doesn't allow for that

Why would you not want to expose the DNSKEY that you are going to use?

I had not yet received good responses for my 'counter-counter'
questions. But if Warren's arguments are valid, then having two
different records is imo the cleanest solution.

>>>> 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.
>>> 
>> state. If it queries the zone and sees no CDS records, it simply
>> goes back to sleep.

If the child will maintain the CDS/CDNSKEY RRset in its zone, the only
extra step the parental agent has to make is to do a compare and if the
compare returns 'in-sync', 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.

But you have to do the polling anyway. And there is no tracking or
maintaining state for the parent if the child maintains the CDS/CDNSKEY
RRset.

So, it makes it marginally more difficult (one compare per poll) for the
parent, while the rule of removing the CDS/CDNSKEY RRset when in-sync
makes it much more complex for the child, with all the polling and
additional state it needs to maintain.

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

I am a programmer. I do not want to track and remove the CDS/CDNSKEY if
they are in-sync.

> Maybe I am more relaxed if you explicitly say that is a normal case.

Fully agree.

>>>> 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)
>>> 
>> DONE. It seems like you feel strongly about this :-) My reason for 
>> 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...
> 
> I want to know what happens both from the child and parent
> perspective IF the CDS and CDNSKEY differs.
> 

At random? Then you still don't really know that the result would be ;)

Best regards,
  Matthijs

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 11 Apr 2014 11:42:15 +0200

> At random? Then you still don't really know that the result would be ;)

Exactly, thats why I think we should say MUST (but explain what we mean with it).

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 11 Apr 2014 12:03:26 +0200

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

What should a parent do when it fetches a CDS or CDNSKEY and the Rdata
does not make sense at all on its own? f.e. the Rdata does not parse
as a DNSKEY or DS? If a child puts a CDS in his zone where the Rdata
says "this is not a key at all", should I publish that?

I think since this is a protocol definition, CDS and CDNSKEY MUST
match. What a parent should do when the protocol is violated is I
guess an implementation issue, BCP, or perhaps even local policy. A
parent may only look at CDNSKEY or CDS or both. Saying they MUST match
when they are both in the zone does not state anything on what the
parent should do when they don't, same as when the Rdata is rubish.

I would personally accept a CDNSKEY that does not match a CDS, knowing
that the child may be in trouble when I change my policy in accepting
CDS in the future. But that's the price the child pays for violating
the protocol. I don't see any use case or excuse for the CDNSKEY and
CDS not matching -if- they are both in the zone.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 11 Apr 2014 12:44:52 +0200

Hi,

I support publication of this document, but I agree that some things
should be improved before its ready to do so. Mainly the RFC2119
language (raised by Patrik), the rule of removing the CDS/CDNSKEY RRset
at the child and missing/no clear guidelines to prevent "DS flapping".

Besides some nits which I will send the editors off-list, here are my
comments:

2.1.  DNS delegations

   But this
   fails to meet some operating needs, including the child having no
   influence what DS digest algorithms are used and DS records can only
   be published for keys that are in the DNSKEY RRset.

The reason why that is bad is because it then would not be compatible
with the Double-DS key rollover method. Perhaps it is good to add that
explicitly.

   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 SHOULD remove all CDS records from the zone.

I would rather see MAY here, having the retain RRset be the normal case,
agreeing with Patrik Faltstrom earlier comments.

In other words: The CDS and CDNSKEY RRsets MUST be signed with an active
KSK. This introduces new tasks for keys that have the role of KSK. In
current software, a KSK only signs the DNSKEY RRset. Basically, with
this rule you are extending the role to also sign the CDS and CDNSKEY
RRsets. I am fine with that, they all are there for the same main
purpose: maintaining the chain of trust. But I think this can be
mentioned more explicitly in the document.

Now do we also require the ZSK have signing these RRsets? I don't think
so. So also the signing rules for ZSKs can be adjusted.

   A child MAY publish both CDS and CDNSKEY.  If a child chooses to
   publish both, it MUST attempt to maintain consistency (a matching CDS
   for each CDNSKEY).

Another weak RFC2119 requirement: MUST attempt. I think you have to get
rid of the word attempt.

Patrik already asked what the RFC2119 equivalent for 'good idea' would
be. Perhaps this is a SHOULD. This way the parental agent can be more
sure of things being in-sync at the child name servers.

   The Parental Agent MUST ensure that old versions of the CDS / CDNSKEY
   RRset do not overwrite newer versions.  This MAY be accomplished by
   checking that the signature inception in the RRSIG for CDS / CDNSKEY
   is newer and/or the serial number on the child's SOA is greater.
   This may require the Parental Agent to maintain some state
   information.

Or use the good idea from above, to prevent maintaining state.

Best regards,
  Matthijs

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 11 Apr 2014 13:10:55 +0200

> parent should do when they don't, same as when the Rdata is rubish.

I support this. This makes possible for parents to decide themselves whether:

1. They only fetch CDNSKEY and will not fetch CDS
2. They only fetch CDS and will not fetch CDNSKEY
3. They fetch CDNSKEY first, and then CDS if CDNSKEY does not exist
4. They fetch CDS and first, and then CDNSKEY if CDS does not exist
5. They fetch both CDS and CDNSKEY and will only pick data if the two are the same
6, ...

Etc.

If that is not the case, i.e. that the wg want a specific algorithm, then that should be explicit.

Unless we have an algorithm, then I support the fact that according to the protocol, they MUST result in the same result, as the parent can choose what algorithm they use.

   Patrik

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Apr 2014 10:43:40 -0400

I’m a little confused by this:

> should be improved before its ready to do so. …

Perhaps this is more of a pet peeve than a to-the-point comment.

I don’t see how one can be in support of publishing a document and then suggest changes.

In the case of this document, I think it needs a lot of changes (already suggested by many), I think publishing it as is would not be very constructive.

Looking at the comments, I keep thinking of “what is the best way to specify a protocol.”  This comes up here in the discussion about whether a CDS and CDNSKEY, if both are present, MUST or not MUST be the same.

If you think my concern is academic, I’ll refer to the flap over the requirement that a set of data be signed with all algorithms in the DS and DNSKEY set being interpreted as “the validator must see all” even if the validator had a way to build a chain of trust.

The basics of protocol specification include:

A statement about the set of messages that are to be exchanged.
When causes a particular statement to be sent.
The reaction to the receipt of a particular statement.

I don’t think this version of the document does a good job of that - and my previous comment suggested some fixes.  Whether or not the particulars of what I wrote are adopted, I encourage structuring the document according to the three lines above.

One reason software is so badly implemented is that the specifications are poorly written.  "One reason" - for sure.  If you ask me (and you didn’t) it is the responsibility of the IETF to generate quality documents and effort should be extended to make sure what is produced is clear and every requirement testable.

When it comes to saying there are statements A and B and that the two are supposed to be equivalent - require that.  Require (MUST) the sender to make the two be equivalent.  Then write rules for the receiver to deal with “what happens when they are not equivalent.”  The latter is done to make the protocol exchange more robust.

“Be conservative in what you send, be liberal in what you accept” is advice for implementers, not necessarily protocol designers.  The role of the latter is to restrict communications into a form that makes sense.

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 11 Apr 2014 17:14:24 +0200

On 04/11/2014 04:43 PM, Edward Lewis wrote:
>> I support publication of this document, but I agree that some
>> things should be improved before its ready to do so. …
> 
> 

It is, I mean I want this document to published *in the end*, but we are
not there yet.

> In the case of this document, I think it needs a lot of changes
> (already suggested by many), I think publishing it as is would not be
> very constructive.

Thus not *as is*.

> Looking at the comments, I keep thinking of “what is the best way to
> specify a protocol.”  This comes up here in the discussion about
> whether a CDS and CDNSKEY, if both are present, MUST or not MUST be
> the same.
> 
> If you think my concern is academic, I’ll refer to the flap over the
> requirement that a set of data be signed with all algorithms in the
> DS and DNSKEY set being interpreted as “the validator must see all”
> even if the validator had a way to build a chain of trust.
> 
> A statement about the set of messages that are to be exchanged. When
> causes a particular statement to be sent. The reaction to the receipt
> of a particular statement.
> 
> I don’t think this version of the document does a good job of that -
> and my previous comment suggested some fixes.  Whether or not the
> particulars of what I wrote are adopted, I encourage structuring the
> document according to the three lines above.
> 
> One reason software is so badly implemented is that the
> specifications are poorly written.  "One reason" - for sure.  If you
> ask me (and you didn’t) it is the responsibility of the IETF to
> generate quality documents and effort should be extended to make sure
> what is produced is clear and every requirement testable.
> 
> When it comes to saying there are statements A and B and that the two
> are supposed to be equivalent - require that.  Require (MUST) the
> sender to make the two be equivalent.  Then write rules for the
> receiver to deal with “what happens when they are not equivalent.”
> The latter is done to make the protocol exchange more robust.
> 
> “Be conservative in what you send, be liberal in what you accept” is
> advice for implementers, not necessarily protocol designers.  The
> role of the latter is to restrict communications into a form that
> makes sense.
> 
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Apr 2014 11:17:42 -0400

> I don’t see how one can be in support of publishing a document and then suggest changes.

I read these to be translated to "I have issues/suggested changes, but 
they are not enough to warrant not publishing this document."

As Shepherd for this document I have been in contact with the authors on 
the issues being raised. All three of us have things that have caused us 
to be distracted from being more attentive.  I suspect in the next week 
all the issues raised will be addressed in some manner.

tim

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Apr 2014 08:24:26 -0700

> I don’t see how one can be in support of publishing a document and then suggest changes.

Because we believe that the basic idea of the document is sound. 

> In the case of this document, I think it needs a lot of changes (already suggested by many), I think publishing it as is would not be very constructive.

So far, no one has said "publish as is", have they?

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Fri, 11 Apr 2014 12:08:32 -0400

> So far, no one has said "publish as is", have they?

Considering the last call was for a specific version of a specific document[0], I interpret the “this" in "this document” to be the specific version.  So, yes, I think “they” have said so.

Perhaps it’s obvious I’m picking on Matthij’s comment, but don’t intend to single him out.

[0] http://www.ietf.org/mail-archive/web/dnsop/current/msg11542.html links to http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Apr 2014 09:54:18 -0700

> Considering the last call was for a specific version of a specific document[0], I interpret the “this" in "this document” to be the specific version.  So, yes, I think “they” have said so.

Then you simply aren't reading the messages: they all say the opposite. What can we do to help you read more of the message than just that one part?

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Apr 2014 17:48:26 -0400

>>> "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 me…

No worries, we aim to please!

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

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

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

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

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?

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

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

>> Yeah. This should be a MUST NOT. Fixed.

"Service with a smile"

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

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

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

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

W

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Apr 2014 17:58:38 -0400

> Why would you not want to expose the DNSKEY that you are going to use?

Some folk believe that publishing only the DS, and keeping the standby
DNSKEY in your pocket for later use is "safer".
By only publishing the DS, the attacker cannot see the DNSKEY and so
cannot try factor it. It doesn't matter is this is a valid concern or
not -- it's a viewpoint that some hold and so we should accomodate it.

> compare returns 'in-sync', it simply goes back to sleep.

Yup.

> additional state it needs to maintain.

Yup. I just posted mail to the list (Argh! Forgot a subject on the
mail!) asking for feedback on which folk would prefer. I personally
like the "just leave the record in the zone" view. Hopefully others
will too...

> At random? Then you still don't really know that the result would be ;)

Hopefully the text is now clearer. The parent should choose either DS
*or* DNSKEY (based upon local registry policy - they have already done
this). They then poll for the corresponding RR (CDS *or* CDNSKEY) and
ignore the other one.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Apr 2014 18:06:55 -0400

> Unless we have an algorithm, then I support the fact that according to the protocol, they MUST result in the same result, as the parent can choose what algorithm they use.

Yup. The document currently (-04) says that if the child publishes
both, they MUST match. However, it also says that the parent MUST NOT
perform a consistency check -- it chooses either DS or DNSKEY based
upon local policy and then consumes the corresponding record type.

Relevant text:
"Some parents prefer to accept DNSSEC key information in DS format,

The child SHOULD publish both CDS and CDNSKEY records. If the child

"The parent MUST choose to accept either CDS or CDNSKEY records (based
upon local policy), and MUST NOT expect there to be both. A parent
MUST NOT perform a consistency check between CDS and CDNSKEY (other
than for informational / debugging use)."

Is this A: sane and B: reasonable?

W

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 12 Apr 2014 09:00:31 +0200

> as much as the next person, but you have to draw the line somewhere.

Where do I cast my vote?

> introducing more complexity."

Excellent!

> text? "the two RRsets MUST have the same semantic meaning?" something?

Excellent.

The rest of the comments are approximately this. You only have to say this once.

> Hopefully folk will want the behavior you (and Matthijs) are asking for.

We'll see.

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

Mumble, I blame a few reports from the Swedish Government on Fibre deployment that was pure crap, lack of coffee and other things.

> zone does not contain the DS for this delgation). "

Good!

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

Thank you VERY much!

Hint: Try to register a domain name in the .IS ccTLD. That is the latest hangup I have regarding broken policy by a registry. There are probably others as well, but this is my latest "interesting" case.

   Patrik

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 12 Apr 2014 20:41:41 -0400

> Considering the last call was for a specific version of a specific document[0], I interpret the “this" in "this document” to be the specific version.  So, yes, I think “they” have said so.

FWIW….I wasn't thinking of WGLC as an assertion the document was ready to publish as-is, which we'd move forward unless actively challenged with an argument that it wasn't. I was thinking of it more as a question: "Does this document we've been working on have consensus support that it's ready to publish? If not, what do you think it still needs in order to get that consensus?" 

For anyone pondering additional comments-- if you have comments please make them, so we can answer the second part of the question as well as the first.

thanks,
Suzanne

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 14 Apr 2014 11:27:01 +0200

op 12-04-14 00:06, Warren Kumari schreef:
> The parent should use whichever one they choose, but MUST NOT query
> records."
> "A parent MUST NOT perform a consistency check between CDS and
> CDNSKEY (other than for informational / debugging use)."

I want this part deleted. Whether or not parents do DNS protocol
verification is local policy and up to the parent. While pedantic to
some, it may serve a local need to others. An RFC is not the place to
enforce a specific local policy to parents that annoys only a certain
part of the DNS community. Just state how the protocol works, but do
not state it may or may not be verified. This protocol does not only
work for TLD registries, but especially also lower down the tree, and
I know protocol verification is a reasonable requirement there for
certain use cases. If you're not happy with that local policy, choose
a different parent or complain to your local parent, not the IETF.

You can publish a CDNSKEY or CDS or both.
If you publish both, they MUST match.

I can live with this line (watch the "MAY"):

"The parent MAY choose to only accept either CDS or CDNSKEY records
(based upon local policy), but MUST NOT expect there to be both."

Because it is perfectly sane from a protocol perspective to only have
one type and not the other if you know the local policy of your parent
or have a preference as a child in case they accept both.

Since CDNSKEY and CDS MUST match, the parent can:
- -accept CDNSKEY and only receive CDNSKEY
- -accept CDS and only receive CDS
- -accept both and have a preference for CDNSKEY if they receive both
- -accept both and have a preference for CDS if they receive both
- -accept both and use CDNSKEY if they only receive CDNSKEY
- -accept both and use CDS if they only receive CDS
- -accept CDNSKEY and not verify if they receive both
- -accept CDS and not verify is they receive both
- -accept CDNSKEY and verify if they recieve both
- -accept CDS and verify if they receive both
- -.....

- -- 
Antoin Verschuren

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 14 Apr 2014 13:09:04 +0200

op 10-04-14 21:54, Patrik Fältström schreef:

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

While I agree with you some (TLD) parents are sometimes too pedantic,
it may serve a need for parents to refuse certain use cases under
their parenthood. If the rules are stupid, complain to the parent if
you want to be his child.

> Parent should not control the child.

I don't agree you can put it that generic. Some parents only want
specific use under their tree, and you cannot force a parent to grant
you a use case you want. While I agree with you some parents want to
control their children too much, and hence have silly rules that don't
match the use case they want to accommodate, it's not always the case.
Don't throw away the child with the bathwater.

Let me give you a use case where this may be clear.
Suppose I want to set up a network of probes under a parent
"probenetwork.example.com". Every probe gets a registration, but for
the probenetwork to work, every delegation MUST do DNSSEC with an
algoritm the probe architecture can handle and know the whereabouts of
every other probe. Every probe handles it's own delegation so queries
over the network requires the zones to contain specific records the
probes use. So my local policy is to only allow delegations for
certain DNSSEC algorithms, and every delegated zone MUST contain a LOC
record.
In order not to disturb the running probe network, I only accept new
delegations after I verify the child zone for that.

Another example may be that as a parent, we do not want too short
TTL's on the child's NS RRset because our infrastructure is hit with
more queries that are useless with our zone's publication frequency.
And we don't want too long TTL's as a countermeasure against ghost
domains misused by botnets. Now the botnet herders may be against that
policy, but it's our choice as a parent not to accommodate that use
case in our tree unless someone convinces us there's a legitimate
other use case that cannot live with those rules.

- -- 
Antoin Verschuren

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Apr 2014 09:05:52 -0400

Perhaps again I’ll be labelled as a potential troll for this.  Again, using an example for a non-specific comment...

On Apr 14, 2014, at 7:09, one person wrote:

> At 10-04-14 21:54, someone else:
> 
>> stupid rules for ...

It is not in scope for the WG to judge the requirements which various DNS registries (TLD and otherwise) have signed up to meet.  It would be far more constructive to accept actual, demonstrated needs than such for a tech-utopia.  One of the things I learned when comparing DNSSEC operations to protocol engineering was that operators face a wide range of environments.  If the IETF is to produce protocols that are universally appealing, then the protocol has to pander - or be so good that it results in “simplifying” the number of different environments.  The IETF desires greater operator involvement, you don’t get that by complaining about the operators’ use cases.

Process-wise I’m surprised to see a new version come out before the end of the last call.  There was a draft a few years ago that I was following.  Each time I’d redline half a copy I’d learn that the one I was reading had been replaced by the next.  That wasn’t a last call time, so it was annoying.  But this time there is a last call and I would think the editors should wait for any stragglers.  (This time I did respond earlier.)

The rest of this I may have said before.  This draft (the CDS/CDNSKEY) describes an interchange from essential the key manager of the child zone and the provisioning system of the parent zone.  The communications medium is one direction, no feedback possible, but the client (in the sense that one end takes the initiative) can detect changes made by the server.

This is like (analogy time) one person who can speak to another and see the result, but there’s no other communication path. (Unrelated, this also applies to praying.)  Staying in-band only, the only way to make this work is to involve relative time (time-outs).

I do not to intend to say this is dead when I say: this cannot scale (unquantifed).  I mean that, in the sense we give up on scaling, we can define a protocol.

I think it is silly to burn two RR types to communicate the same thing.  You’re inviting debate on testing and handling the two being out of sync.

I don’t have a problem with leaving the records in as long as the parent is supposed to have the record represented in its zone - but only because I’m willing to sacrifice scaling.  This causes less state to be maintained (but is does create a greater load on a parent system that is polling).

I think that all use of the communications medium has to adhere to the basic rules of security.    Here that being ZSK signed - knowing that the validation engine does not inspect the SEP bit - but that when considering this is a client key manager to parent provisioning protocol (not DNS), the extra signature should be there.  (Come to think of it, the ZSK RRSIG is a redundant, but don’t expect cache-protecting validators to respect the SEP bit.)

Please take steps to simplify the protocol and discussion.  Giving up on scaling can make this a tool that some operators can use - and perhaps on a small scale within an organization.  It would be interesting to see is a general purpose DNS implementation will try this to manage a set of zones (as opposed to managing zones in isolation).

DNSSEC is clumsy.  It needs a solution here.

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 14 Apr 2014 15:16:31 +0200

On 04/14/2014 03:05 PM, Edward Lewis wrote:
> I think it is silly to burn two RR types to communicate the same
> thing.  You’re inviting debate on testing and handling the two being
> out of sync.

Would you prefer one RR type with varying RDATA format (like with
IPSECKEY)? I don't.

Best regards,
  Matthijs

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 14 Apr 2014 15:21:46 +0200

> Would you prefer one RR type with varying RDATA format (like with

...or NAPTR...

No thank you. :-)

I.e. completely agree with Matthijs!

You want RRTypes that are designed so that the triple {owner,class,type} do select an RRSet that is appropriate for whatever use it has.

   Patrik

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 14 Apr 2014 09:37:32 -0400

> You want RRTypes that are designed so that the triple {owner,class,type} do select an RRSet that is appropriate for whatever use it has.

My first thought for this was "Why don't we use TXT records with a 
specific format string to represent these"?

But then you would just realize I was making sure everyone was awake and 
alert.

tim

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Apr 2014 10:06:01 -0400

In the world of trade-offs:

Having one record:

1) Can retrieve it in one query
2) Easier to specify what to publish and what to read
3) Parsing involved inspection of RDATA

Having two records:

1) Need two queries or rely on ANY
2) Have to explain to the client what to publish, server has to deal with inconsistencies
3) Parsing reuses existing code

I invite more trade-offs to be added.

The parsing should not be in the DNS client or server, that would be buried in the client key manager and the parent provisioning systems.  Each of those have to add and check a that there’s a other-wise valid signature corresponding to a key with a SEP bit set, so, they have some rewriting to do anyway.

There’s no reason that a RFC 1034-style DNS server and client need to read these records.  They are not used by the name server.  By RFC-1034 style I am excluding DNS servers that have on-line key management built in (such as ISC’s BIND 9.7 and on - don’t quote me on version numbers, it may have been earlier).

I don’t see why the RDATA presentation can’t just be a hex sequence (or Base64)….so long as the end points can read and write it.

Come to think of it - we can use the TXT record for maximum flexibility! ;)

Looking at these tradeoffs, I see the expense of trying to specify and explain to operators - via the tools they use - of why there are two records and what happens if they aren’t the same as far more costly than having the name server need to deal with varying formats.  Yes, I know that NAPTR is also a poor example, in fact, there aren’t too many examples of varying record formats out there - except of course for TXT.  (Hmmm, perhaps that is one reason why it is so popular.  I mean, besides the firewall pass through and other acceptance “features.")

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2014 15:18:46 -0400

On Mon, Apr 14, 2014 at 7:09 AM, Antoin Verschuren
<[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Just checking -- do you want any action *on this doc*? I *think* that
we are generic/non-prescriptive enough that you can implement whatever
policy you want...
If you'd like something additional (probably in Section 6.2) saying
something like "Acting on CDS/CDNSKEY records may be subject to local
policy" or something, please help by providing text...

I *think* that we are generic enough that this is covered, but...

W

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQEcBAEBAgAGBQJTS8HQAAoJEDqHrM883Agn8XYIANEHTXRmoAgK0nFN+UXLcjY3
> SU8c9x0C2ZIgVFpPm1jIyyetFhzVgtHh6IzJb0BRINziRYYaXkR0sNxC0feCpboP
> sv4nPBw3JkY24rZ6xFJ9O+vSA3TLujp9JlgudZLAPVx/g2LuGeO7jwGXssF95I5F
> Uv9eFOLH6Nul3KVynN6osRaE6fgHyaFppOb/SvkCVRwpccyrGTH+jQzlHhdhL9rv
> ra+VG5G3pDrRND4LcRAHpev14QYhZejmyXsf4scIy/fh4SSCvUZ5wuwhTbMWPMtG
> ocVAZFqibdVZWJ1E/xDxSXSqqXU3lGCuDHGvFe8P+fZcUO5lHuPjBRK3NnSimag=
> =khPI
> -----END PGP SIGNATURE-----
>

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Apr 2014 00:14:17 +0200

> Looking at these tradeoffs, I see the expense of trying to specify and explain to operators - via the tools they use - of why there are two records and what happens if they aren’t the same as far m…

How much code, in the number of implementations, have you _personally_ written that parses RRSets returned from a query and selects the subset you want to actually use? Including issues with size of RRSets? ;-)

Just Do Not Go In That Direction!

Yes, I once upon a time supported NAPTR strongly, but because of that I also now hate it and support URI.

For this very reason.

;-)

   Patrik

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 15 Apr 2014 10:23:51 +0200

op 14-04-14 21:18, Warren Kumari schreef:

>> Just checking -- do you want any action *on this doc*? I *think*
>> that we are generic/non-prescriptive enough that you can
>> implement whatever policy you want...

Yes, like I said, I would like to have this line deleted in section 6:

  "A parent MUST NOT perform a consistency check between CDS and
   CDNSKEY (other than for informational / debugging use) resource
   records."

That's not protocol, but prescriptive language that a parent is
disallowed to have a policy to verify the records.

I also think the line just above that:

  "The parent MUST choose to accept either CDS or CDNSKEY resource
   records (based upon local policy), and MUST NOT expect there to be
   both."

is mixing up 2 things:
- -What the parent -accepts-
- -What the parent -uses- when both are present.

I think it's perfectly fine for a parent to accept both, but it must
state which it will use when it sees both in the zone to manage
expectancy.

So suggested text to replace that with:

"The parent MUST choose to use either CDNSKEY or CDS resource records
as their default updating mechanism.
The parent MAY only accept either CDNSKEY or CDS, but it MAY also
accept both, so it can use the other in the absence of the default
updating mechanism, but it MUST NOT expect there to be both."

- -- 
Antoin Verschuren

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Apr 2014 16:28:05 -0400

> disallowed to have a policy to verify the records.

Ah. Sorry, was not intentionally ignoring you, I just missed where you
were meaning...

> updating mechanism, but it MUST NOT expect there to be both."

DONE!
Nice, thanks for the text...

W

> iQEcBAEBAgAGBQJTTOyRAAoJEDqHrM883Agn5JYH+gIEg2aLAcaDTvJfa5I23vAY
> rGyiBmT0oL9AmihDC1nNnFMascqev70Uu3txc1bKYOnhrLFCzqUwudcEnu4l1ha8
> JdQv8GfotXdwRHCuYxxEtn22J8XOtH+bCSVfvZlirJtCW3jCLQqNq3rZHOd1xGs6
> anocAxV5Sm6+btkrmxXCIMktt92uG4FXEGVgSaPxUO57K6+j5hVxS71VpGid2r77
> iqx3f0xl9p6AjKwJz2c0la1CuE/+mG0/8uH6m/rSQXfB/nYDzDPa9IO74baEjRkO
> 5WOxVJ7WBiFfpGX6UNdN9ui+dixHqn0ugkOAWz89Pu0k7fbaEzI1Z4nME0dBhvU=
> =H1BY

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Apr 2014 17:06:40 -0700

This looks greatly improved from the -03 that started the WG Last Call. It clears almost all of my concerns, particularly about the overly-loose language.

There is still one assumption being made of the reader that I think can cleanly be cleared up. The first paragraph of the introduction says:

   When a DNS operator first signs their zone, they need to communicate
   their DS record(s) (or DNSKEY(s)) to their parent through some out-
   of-band method to complete the chain of trust.

I think the concept of what is being told to the parent would be much clearer as:

   When a DNS operator first signs their zone, they need to communicate their
   keying material to their parent through some out-of-band method to complete
   the chain of trust. Depending on the desires of the parent, the child might
   send their DNSKEY record, a DS record, or both.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 15 Apr 2014 20:39:54 -0400

>   send their DNSKEY record, a DS record, or both.

I agree this text is much better. 

	Olafur

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Apr 2014 22:22:55 -0400

On Tuesday, April 15, 2014, Paul Hoffman <[email-masked]> wrote:

> This looks greatly improved from the -03 that started the WG Last Call. It
> clears almost all of my concerns, particularly about the overly-loose
> language.
>
> There is still one assumption being made of the reader that I think can
> cleanly be cleared up. The first paragraph of the introduction says:
>
> their

Looks good, thank you for the text, I'll integrate it tomorrow.

W

> [email-masked] <javascript:;>

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 16 Apr 2014 09:34:28 +0200

> keying material to their parent through some out-of-band method to complete

And changing opening sentence to:

	The first time a DNS operator signs the zone, they need to
	communicate the keying ..."

Make it even more clear.

	jaap (nitpicking mode)

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Apr 2014 08:02:48 -0400

>         communicate the keying ..."

Thank you.
I think I made it even clearer:
The first time a DNS operator signs a zone, they need to communicate
the keying material to their parent through some out-of-band method to
complete the chain of trust. Depending on the desires of the parent,
the child might send their DNSKEY record, a DS record, or both.

Good?
W

---

From: Dan York <[email-masked]>
Date: Wed, 16 Apr 2014 13:19:11 +0000

On Apr 16, 2014, at 8:02 AM, Warren Kumari <[email-masked]<mailto:[email-masked]>>
 wrote:

Good?

Looks good to me.    The whole document is looking very good.  I've been reading the conversation and initially had some concerns but others already addressed the points (and so I felt no need to add to the queue of messages).

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Apr 2014 12:40:35 -0400

On Wed, Apr 16, 2014 at 9:19 AM, Dan York <[email-masked]> wrote:
>
> On Apr 16, 2014, at 8:02 AM, Warren Kumari <[email-masked]>
>  wrote:
>
> Looks good to me.    The whole document is looking very good.  I've been
> reading the conversation and initially had some concerns but others already
> addressed the points (and so I felt no need to add to the queue of
> messages).

... and I got an off-list comment pointing out that:
"Section 6.1
         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).

But in section 4.1 you say
   o  Signer: "MUST be signed with a key that is represented in both the
       current DNSKEY and DS RRset's."

One of the two must be reworded."

Doh! So, I have updated the "Signer" rule to be:
o  Signer: "MUST be signed with a key that is represented in both the
    current DNSKEY and DS RRset's" (unless the parent validates the
    CDS / CDNSKEY though some other means (see Section 6.1 and the
    Security Considerations.))

Any (major) objections?

This time for sure,
W

> [email-masked]   +1-802-735-1624
> Jabber: [email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 17 Apr 2014 10:46:11 +0200

>     Security Considerations.))

Yes:)

The comment in 6.1 is meant for a way to use this technique for initial
enrollment. So I would rather see that the rewording in 4.1 also
reflects that: I don't want the regular maintenance to be susceptible to
'other means validation'. Suggestion:

(unless the parent uses the CDS / CDNSKEY RRset for initial enrollment,
in that case the parent validates the CDS / CDNSKEY though some other
means (see Section 6.1 and the Security Considerations.))

Best regards,
  Matthijs

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Apr 2014 13:08:19 -0400

> means (see Section 6.1 and the Security Considerations.))

Oooh! Nice.
I was unable to come up with a succinct way of saying that. Changed.
I also fixed a typo / thinko in the Acknowledgements section.

*This* time for sure,
W

---

From: Joe Abley <[email-masked]>
Date: Mon, 21 Apr 2014 09:34:08 -0400

> the child might send their DNSKEY record, a DS record, or both.

I don't think you mean "the first time a DNS operator signs a zone". You're making an assumption that a zone, once signed, will never be unsigned. In fact, a zone can be signed, then unsigned, any number of times.

"Whenever a zone's insecure delegation is replaced by a secure delegation, the DNS operator needs to communicate the keying material..."

Joe

---

From: Jacques Latour <[email-masked]>
Date: Wed, 23 Apr 2014 16:57:34 +0000

"The Child may also remove old  keys, but this document does not support removing all keys."
"When the Parent DS is "in-sync" with the CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the CDS / CDNSKEY record(s);"

Read the whole thing a couple of times and it's not clear to me how to remove one or more DS? Once "in-sync", If the parental agent polling/mechanism detect a CDS for an existing DS, or a CDNSKEY for a matching DS, then you remove the DS but not if it's the last one? Right? Or there's a "ADD/DELETE" parameter to the proposed CDS and CDNSKEY resource records to instruct the parental agent on the type of operation to perform?

Jack

> -----Original Message-----
> From: DNSOP [mailto:[email-masked]] On Behalf Of Joe Abley
> Sent: April-21-14 9:34 AM
> To: Warren Kumari
> Cc: dnsop; Paul Hoffman
> Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-
> delegation-trust-maintainance
> 
> 
> I don't think you mean "the first time a DNS operator signs a zone". You're
> making an assumption that a zone, once signed, will never be unsigned. In
> fact, a zone can be signed, then unsigned, any number of times.
> 
> "Whenever a zone's insecure delegation is replaced by a secure delegation,
> the DNS operator needs to communicate the keying material..."
> 
> 
> Joe

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 24 Apr 2014 07:55:52 +0200

Hi Jacques,

On 04/23/2014 06:57 PM, Jacques Latour wrote:
> "The Child may also remove old  keys, but this document does not
> support removing all keys." "When the Parent DS is "in-sync" with the
> CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the
> CDS / CDNSKEY record(s);"
> 
> Read the whole thing a couple of times and it's not clear to me how
> to remove one or more DS? Once "in-sync", If the parental agent

By removing the corresponding CDS/CDNSKEY from the CDS/CDNSKEY RRset.

> polling/mechanism detect a CDS for an existing DS, or a CDNSKEY for a
> matching DS, then you remove the DS but not if it's the last one?

No: The parent would never remove a DS when it sees a CDS/CDNSKEY for an
existing DS.

> Right? Or there's a "ADD/DELETE" parameter to the proposed CDS and
> CDNSKEY resource records to instruct the parental agent on the type
> of operation to perform?

Let me try to rephrase:

The child can signal its desire to add DS records by publishing
corresponding records in the CDS/CDNSKEY RRset.

The child can also signal its desire to remove DS records by removing
the corresponding records from the CDS/CDNSKEY RRset again.

If the CDS/CDNSKEY RRset is in-sync with the DS RRset at the parent, the
child MAY remove the CDS/CDNSKEY RRset from its zone.

If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
this means there is no action to perform for the parent. Hence, this
document does not support removing all DS records from the parent.

Best regards,
  Matthijs

> 
> Jack
> 
>> -----Original Message----- From: DNSOP
>> [mailto:[email-masked]] On Behalf Of Joe Abley Sent:
>> April-21-14 9:34 AM To: Warren Kumari Cc: dnsop; Paul Hoffman 
>>> I think I made it even clearer: The first time a DNS operator
>>> signs a zone, they need to communicate the keying material to
>>> their parent through some out-of-band method to complete the
>>> chain of trust. Depending on the desires of the parent, the child
>>> might send their DNSKEY record, a DS record, or both.
>> 
>> I don't think you mean "the first time a DNS operator signs a
>> zone". You're making an assumption that a zone, once signed, will
>> never be unsigned. In fact, a zone can be signed, then unsigned,
>> any number of times.
>> 
>> "Whenever a zone's insecure delegation is replaced by a secure
>> delegation, the DNS operator needs to communicate the keying
>> material..."
>> 
>> 
>> Joe _______________________________________________ DNSOP mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Apr 2014 08:41:22 -0700

At Thu, 24 Apr 2014 07:55:52 +0200,

> the corresponding records from the CDS/CDNSKEY RRset again.

...unless that would make the resulting CDS/CDNSKEY RRset empty.

> document does not support removing all DS records from the parent.

I guess this discussions is essentially the same as what I asked a few
months ago:
http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html

and while I thought revised versions of the draft were clear about
this point, but the fact that we still have this discussion seems to
suggest it's probably not sufficiently clear.  Perhaps the problem is
that many of us already knows how it works and it's difficult for us
to see how it could be interpreted by first-time readers.  So, while
it may look redundant, it may help if we show a specific example of
how the child adds/removes CDS/CDNSKEY and how it works at the parent:

0. the child becomes signed from unsigned, tells the parent its
   DNSKEY (say KSK1), the parent has a DS.  this step is out of scope
   of CDS/CDNSKEY:
   child.example. DS ....(for KSK1)
1. the child adds the corresponding CDS in the child zone:
   child.example. DNSKEY ....(for KSK1)
   child.example. CDS ....(for KSK1)
2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the
   child zone:
   child.example. DNSKEY ....(for KSK1)
   child.example. DNSKEY ....(for KSK2)
   child.example. CDS ....(for KSK1)
   child.example. CDS ....(for KSK2)
3. the parent notices or is notified of a change in the child, and
   finds there's a new CDS (for KSK2) that doesn't match its set of
   CDS, and adds a new DS corresponding to that one:
   child.example. DS ....(for KSK1)
   child.example. DS ....(for KSK2)
4. the child confirms the DS and CDS are now synchronized, and removes
   the old DNSKEY (KSK1) and corresponding CDS:
   child.example. DNSKEY ....(for KSK2)
   child.example. CDS ....(for KSK2)
5. the parent notices or is notified of a change in the child, and
   finds a CDS (for KSK1) that currently matches one of its DS's is
   now removed.  the parent removes the corresponding DS:
   child.example. DS ....(for KSK2)
6. the child confirms the DS and CDS are now synchronized.  at this
   point, it MAY remove the remaining CDS for the reason explained in
   Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11:
   child.example. DNSKEY ....(for KSK2)
   (no CDS records)
7. the parent notices the change in the child, but does nothing since
   there's no CDS record in the child:
   child.example. DS ....(for KSK2) ; still exist
8. eventually the child might go unsigned again.  all of its DNSKEYs
   will be removed, but the child needs to tell the parent about the
   change and have them remove the DS records in some other way than
   CDS/CDNSKEY.  removing all CDS records can't be used since it
   doesn't make any change at the parent as shown in steps 6 and 7.

--
JINMEI, Tatuya

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 25 Apr 2014 08:28:56 +0200

Hi,

> Otherwise it can contradict this one:

Of course. I tried to rephrase it in four short lines. That does not
mean that one line that stands alone is the absolute truth: you have to
consider the complete context.

> how the child adds/removes CDS/CDNSKEY and how it works at the parent:

I am indeed pretty clear about how this should work and I think the
draft reflects that. But indeed: there is nothing wrong with adding an

>    child.example. CDS ....(for KSK1)

The child does not necessarily need to add the CDS now: The parent
already has the correct DS RRset (step 0) and no rollover has happened
since then.

>    child.example. CDS ....(for KSK2)

Depending on the type of rollover, the child might not want to add the
CDS directly (Double-Signature KSK Rollover) or might want to add the
CDS before adding the DNSKEY (Double-DS KSK Rollover).

>    child.example. CDS ....(for KSK2)

You want to remove DNSKEY and CDS for KSK1 here.

Again: The old CDS may be removed earlier, at the time of adding the CDS
for KSK2 (Double-Signature) or later (Double-DS).

>    doesn't make any change at the parent as shown in steps 6 and 7.

Other than that, I think these examples are very clear, and I support
adding them as an appendix.

Best regards,
  Matthijs

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 25 Apr 2014 09:48:07 -0400

> adding them as an appendix.

I'm willing add an appendix that has Double DS KSK rollover to the appendix with reference to RFC6781 figure 7, as an example. 
I will think about the dual KSK example. 

Tim tell me if you DO NOT want this added to the document. 

	Olafur

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 25 Apr 2014 19:46:59 -0700

Olafur

Please add this. I'll get caught back up on the rest of this by the time warren returns from his walkabout. 

Sent from my Hi-Tech Gadget. 

> On Apr 25, 2014, at 6:48, Olafur Gudmundsson <[email-masked]> wrote:
> 
>