Subject: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

From: 神明達哉 <[email-masked]>
Date: Thu, 6 Feb 2014 10:29:50 -0800

I have one quick question about CDS/CDNSKEY: what's the (or "an")
expected operation for the parent to remove a DS RR of a child that
was obsolete and is now removed from the child zone?

This point is not clear to me on a quick rescan of
draft-ietf-dnsop-delegation-trust-maintainance-02.

According to Section 3:

   The CDS / CDNSKEY record is published in the child zone and gives the
   child control of what is published for it in the parental zone.  The
   CDS / CDNSKEY RRset expresses what the child would like the DS RRset
   to look like after the change; [...]

it could read the child would remove the CDS or CDSKEY for the
now-removed DNSKEY, but it may contradict Section 4.1:

   Absence of CDS / CDNSKEY in child signals "No change" to the current
   DS set.

(BTW: this sentence is a bit ambiguous to me.  Does this mean there's
no CDS/CDNSKEY RR for the apex name, or the absence of CDS/CDNSKEY for
a specific DNSKEY?)

and also Section 5:

   When the Parent DS is "in-sync" with the CDS, the Child DNS Operator
   MAY delete the CDS RRset.

i.e., if the child may delete a CDS for a new DNSKEY after
synchronization, clearly it cannot use the removal of CDS as an
indication of the removal of DNSKEY.

Am I missing some part of the draft that answers my question, or is
this actually out of scope of CDS/CDNSKEY?

p.s. apologize in advance this was already discussed; I don't remember
all previous discussions of the proposal.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Thu, 6 Feb 2014 14:13:05 -0500

> no CDS/CDNSKEY RR for the apex name, or the absence of CDS/CDNSKEY for

Hmmm...

What we were trying to say is that the parent publishes verbatim what
the child says.

So, lets say that at time T things look like this:
Parent:
  example.com. 300  IN DS 31589 8 1 123456.....
Child:
   example.com. 300  IN CDS 31589 8 1 123456......
[ The parent and child are in sync ]

At time T+1 the child decides to perform a key rollover, so they
generate a new DNSKEY, compute the DS, etc.
Parent:
  example.com. 300  IN DS 31589 8 1 123456.....
Child:
  example.com. 300  IN CDS 31589 8 1 123456......
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ The parent still has not updated yet ]

At time T+2 the parent performs the CDS action (either they polled, or
the person operating the child logged onto the web interface and
clicked a button):
The parent sees that what the child has published does not match with
the parent currently has, and so the parent copies the contents from
the child. Now things look like:
Parent:
  example.com. 300  IN DS 31589 8 1 123456......
  example.com. 300  IN DS 31589 8 1 789ABC......
Child:
  example.com. 300  IN CDS 31589 8 1 123456......
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ The parent and child are now in sync / agreement again ]

At time T+3 the child sees that the parent has published the new key
information ( and the standard keyroll stuff has all happened (records
are signed with new key, waited for old TTLs to expire, etc)) and so
wants to remove the old key.
** This is, as far as I understand, what you were  asking about)
The child now publishes just the new key info. They stop publishing the old one.
Parent:
  example.com. 300  IN DS 31589 8 1 123456......
  example.com. 300  IN DS 31589 8 1 789ABC......
Child:
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ Child is only publishing new record / they stop publishing the old one ]

At time T+4 the parent checks agin (it polls, the human clicks the
button on the web page, some other trigger happens, etc):
It sees that what the child has published does not match what the
parent currently has, and so it copies the contents from the child.
Parent:
  example.com. 300  IN DS 31589 8 1 789ABC......
Child:
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ The child and parent are back in sync. The old key (123456...) is no
longer in use anywhere. ]

The CDS RR set says, in effect, "Please replace *all* of the key
information for me with *this* set of info."

> indication of the removal of DNSKEY.

It at any point during this process the parent contacts the child and
does NOT find any CDS records, it simply does nothing.
This means that you can use this to update / replace / remove existing
DS records (if you have keys A, B, C and D and want to stop using C,
you simply publish A, B, D), but you cannot remove *all* DS records /
go unsigned.

> this actually out of scope of CDS/CDNSKEY?

I think that it in in the draft, but we need to be clearer that the
CDS/CDNSKEY *RRset* that the child publishes should be published in
the parent exactly (after transforming DNSKEYs to DS if needed). This
isn't a "please add record X" or "please remove record Y", it is
"Please publish this *list*"
We specifically want to remove the need for the parent to maintain state, etc.

> all previous discussions of the proposal.

Me neither!
:-)

W

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Feb 2014 19:26:16 +0000

> no CDS/CDNSKEY RR for the apex name, or the absence of CDS/CDNSKEY for

I think this second quote from the draft is supposed to mean: absence of
any CDS or CDNSKEY RRsets signals no change.

If there is a CDS or CDNSKEY RRset then the DS RRset should be changed to
match (provided the other acceptance rules are satisfied).

I believe the intent of the draft is that this mechanism cannot be used to
go insecure - though I cannot immediately find text which explicitly says
that. So for a CDS or CDNSKEY RRset to have any effect, it must exist,
which implies there must be at least one DS in the parent zone, which
implies you cannot go insecure.

> indication of the removal of DNSKEY.

This quote from the draft talks about removing the entire RRset, so it is
consistent with my explanation above.

To indicate the removal of a DNSKEY, the child uses a CDS RRset which
does not include a record matching the removed DNSKEY, but does include
the other DNSKEYs that are still present.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Feb 2014 09:18:20 -0800

At Thu, 6 Feb 2014 14:13:05 -0500,

> ** This is, as far as I understand, what you were  asking about)

Yes, and...

> longer in use anywhere. ]

...this makes sense, and actually matches what I first thought was the
intent of the draft.  With this clarification I guess my confusion
mainly came from the first sentence of Section 4.1:

Now I understand this is intended to mean "absence of CDS / CDNSKEY
*RRset*", i.e., absence of any CDS / CDNSKEY.  But it was not super
clear when I first read it and it could also mean the absence
(removal) of this CDS at time T+4

maybe I was the only person who was confused about this, but it
wouldn't do any harm to clarify the wording.

My original question is now resolved, but I have now another about the
"absence of CDS / CDNSKEY"...

> you simply publish A, B, D), but you cannot remove *all* DS records /

This is fine, but technically doesn't it contradict Section 3?

   The CDS / CDNSKEY record is published in the child zone and gives the
   child control of what is published for it in the parental zone.  The
   CDS / CDNSKEY RRset expresses what the child would like the DS RRset
   to look like after the change;

In that, technically, an empty CDS / CDNSKEY RRset should mean the DS
RRset at the parent should be empty.  I have no problem with treating
an empty set as an exception, but I think it would help if the draft
explains that more explicitly.

I'd also note that "absence of CDS" (or CDNSKEY) cannot happen once
one such RR is published, and it should mean something erroneous (most
likely an operation error at the child or a bug in its tool).  I think
it's worth noting in Section 4.1.

Finally, I'd suggest explicitly clarifying that CDS / CDNSKEY cannot
be used for a child from signed to unsigned (since it would have to
remove all CDS / CDNSKEY records to do so).  And, I suspect this is a
"MUST NOT", unlike the case of initial enrollment described in Section
9, because this would break interoperability.

--
JINMEI, Tatuya

---

From: Doug Barton <[email-masked]>
Date: Fri, 07 Feb 2014 10:12:37 -0800

On 02/06/2014 11:13 AM, Warren Kumari wrote:
> you simply publish A, B, D), but you cannot remove*all*  DS records /
> go unsigned.

If we're willing to allow zones to go from unsigned to signed via CDS, 
why not go from signed to unsigned? Both situations represent DOS 
vectors via MITM.

Doug

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Feb 2014 13:14:39 -0500

On Fri, Feb 7, 2014 at 1:12 PM, Doug Barton <[email-masked]> wrote:
> If we're willing to allow zones to go from unsigned to signed via CDS, why
> not go from signed to unsigned? Both situations represent DOS vectors via
> MITM.

We are not allowing zones to go from unsigned to signed:
"This document does not address the initial configuration of trust
anchors for a domain."
and
"While it may be tempting, this SHOULD NOT be used for initial
enrollment of keys since there is no way to ensure that the initial
key is the correct one. If is used, strict rules for inclusion of keys
like hold down times, challenge data inclusion etc., ought to be used,
along with some kind of challenge mechanism."

W

---

From: Doug Barton <[email-masked]>
Date: Fri, 07 Feb 2014 10:18:46 -0800

> We are not allowing zones to go from unsigned to signed:

Right, and because it says not to do it in the RFC no one is going to do 
it? :)

Doug

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 7 Feb 2014 13:26:53 -0500

> (removal) of this CDS at time T+4

Jinmei thanks for pointing this out 
yes you are absolutely right and I have added the word "RRset" into this sentence. 
I'm reading the rest of the document to make sure we are clear in all places 
like this one. 

> explains that more explicitly.

Semantics semantics,  
No we are defining the semantics to be "IF C* is published parent DS should mirror that,
if no C* in child --> parent has no action to perform" 

> it's worth noting in Section 4.1

Why?
Here is a perfectly fine time line
<At start parent DS reflects key A and child uses A to sign DNSKEY RRset> 

Child publishes CDS with A and B 
Parent updates DS to reflect A and B 
Child deletes CDS   

<child performs key roll over from A to B> 

Child publishes CDNSKEY reflecting B 
Parent changes DS to reflect only B 
Child deletes CDNSKEY 

Do you think it is helpful to add an appendix with some examples of use of C* records ? 

> .

In theory we can use C* to perform the Going-Unsigned operation, and earlier version of this
document proposed that, but people objected and we removed that text. 
We explicitly outlaw going from Unsigned --> Signed w/o some out-of-band validation. 

	Olafur

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 8 Feb 2014 00:01:27 +0530

Hi Warren

Did you see my reply to your email a few weeks ago where I asked why new
CDS/CDNSKEY RR types are required instead of adding a new bit to the
Flags field of the DNSKEY RR. Please can you look for my last email
which lists some advantages? There may be a good reason for it, but I
don't want you to miss considering it. :)

		Mukund

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Feb 2014 13:43:27 -0500

> wouldn't do any harm to clarify the wording.

Yup, the wording was unclear / ambiguous.
I tried "The absence of *any* CDS..." but that was also unclear. I
also tried "Absence of a CDS / CDNSKEY *RRset* in child...", but ended
up settling on:
"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."
It this better?

> explains that more explicitly.

Yup. I'm currently trying to craft text to that effect. Unfortunately
I'm having a hard time doing so cleanly.
I've just added "An empty CDS / CDNSKEY RRset means that no change is
needed." in my edit buffer, but I'm unclear on something -- is an
empty RRset the same as a non-existing RRset? I *think* it is, but it
somehow feels weird...

> it's worth noting in Section 4.1.

Um, I think I'm confused now.
Absence of CDS / CDNSKEY can happen. The child just stops including
CDS / CDNSKEY records in their zone - this signals "No change", and is
a special case.

Some background / justification for this:
Let's say that example.com is a company that sells Examples for use in
presentations. They have a few departments (accounting, sales and
development) who each run their own DNS servers, and currently have
the following in their zone:

accounting.example.com IN DS 1 1 12345...
sales.example.com   IN DS 1 1 6789....
development.example.com IN DS 1 1 ABCD123...

The IT group (who runs the main example.com nameservers) get tired of
each department rolling keys and asking for their DS to be updated, so
they decided to start using CDS for this. They mail the DNS person in
each department and say "Starting April 1st we will be supporting CDS,
so you can manage your own stinking DS records without us having to do
any work".

The accounting and development groups read this, shout "Yay!, no more
having to deal with the rude IT folk", and start publishing CDS
records.
The folk in the sales group are wither off playing golf, or see the
April 1st date and figure it's a very subtle joke. Anyway, they don't
bother publishing a CDS record....

If the "Empty CDS / CDSKEY RRset == no change" rule did NOT exist (or
if "Empty CDS / CDSKEY RRset" meant please go unsigned), what would
happen would be that, on April 1st the IT group would turn on some
home grown CDS tool. It would go off and look at all the child zones.
If would be happy with accounting,example.com and
development.example.com. For sales it would see no CDS record, and so
would "helpfully" remove all DS records, making the sales.exmaple.com
zone be unsigned.

Yes, there could be all sorts of logic built into the tool to keep
state / a record of which zones had opted into using CDS / CDNSKEY,
but this is a: error prone and b: requires state on the parent.

> 9, because this would break interoperability.

I just added:
"While it may be tempting, this SHOULD NOT be used for initial
enrollment of keys since there is no way to ensure that the initial
key is the correct one. If is used, strict rules for inclusion of keys
like hold down times, challenge data inclusion etc., ought to be used,
along with some kind of challenge mechanism. A child cannot use this
mechanism to go from signed to unsigned (publishing an empty CDS /
CDNSKEY RRset means no-change should be made in the parent)."

Is this clear? I suspect I'm missing some subtleties here.

W

---

From: Joe Abley <[email-masked]>
Date: Fri, 7 Feb 2014 14:10:30 -0500

> don't want you to miss considering it. :)

The apex of a signed child zone already contains a DNSKEY RRSet, and that whole RRSet is retrieved by validators who want to validate signatures within the child zone.

Adding extra RRs to that set would inflate the response sizes towards those validators with information that is of no practical benefit to them.

Putting those extra RRs in a different RRSet (CDNSKEY) means they can be explicitly retrieved by clients (provisioningware of parents, or parental agents) who need them, without sending them to other clients unnecessarily.

We are, I think, more comfortable with large responses in 2014 than we were in 2010 (at least, we are more comfortable that there are not hideous, fireball-type consequences) but I don't think we should be in the business of inflating responses for no reason.

Also, reflection attacks, amplification potential.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 7 Feb 2014 14:12:00 -0500

On 2014-02-07, at 13:18, Doug Barton <[email-masked]> wrote:

> Right, and because it says not to do it in the RFC no one is going to do it? :)

I don't see how it would work. The parental agent has no automated way to trust the C* RRSets published in a zone with no secure delegation from its parent.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Feb 2014 14:22:36 -0500

> I don't see how it would work. The parental agent has no automated way to trust the C* RRSets published in a zone with no secure delegation from its parent.
No no no... You don't see how it would work *securely*.

We actually say:
along with some kind of challenge mechanism. "

The thought behind this was that an unsigned child *could* start
publishing a CDS / CDSNKEY record. The child would then "securely,
through some out of band mechanism" (hand wave, hand wave) contact the
parent and they would agree that this is the correct key and the
parent would then manually include it. Please note that A: we say
don't do this, B: the hand-wave, and c: the fact that we are not
specifying how this should happen.

W

---

From: Joe Abley <[email-masked]>
Date: Fri, 7 Feb 2014 14:56:24 -0500

> No no no... You don't see how it would work *securely*.

Fair enough. I had taken that as a given, but you're right, it makes sense to spell it out.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Fri, 7 Feb 2014 18:30:59 -0500 (EST)

On Sat, 8 Feb 2014, Mukund Sivaraman wrote:

> Flags field of the DNSKEY RR.

That does not allow prepublishing of DS records for DNSKEY's not
published in the zone yet, which is a strategy for publishing an
emergency rollover key at the parent in case of a compromise of
the signer. This key can be completely offline and even the public
key part unknown to any party.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 7 Feb 2014 18:46:05 -0500

> don't want you to miss considering it. :)

We considered it but there are drawbacks including:
- changing a flag on a DNSKEY record means the key footprint and hash of key change, so matching 
  a key after a change in flags is hard for parents as they do not know which flag was changed. 
- Publishing a future TA in the DNSKEY set makes the DNSKEY RRset larger 

There are advantages to the new RR types 
- CDS allows the publication of a new Trust Anchor without exposing the public key of the new trust anchor 
- Putting a new key in a different RRset keeps DNSKEY smaller 
- less chance of confusion by parents. 

So in short we considered it and rejected that approach. 

	Olafur

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 08 Feb 2014 10:59:20 -0800

At Fri, 7 Feb 2014 13:43:27 -0500,

> operator MAY remove all CDS records from the zone."

(Now that I've understood the intent I may not be in a good position
for judging the clarity of the text, but anyway) Yes, I think so.

> empty RRset the same as a non-existing RRset? I *think* it is, but it

Mathematically I think so, but in any case, the point here is to make
the draft so it won't be misunderstood, rather than try to give
a mathematically perfect definition.  In that sense I think it's
sufficient as long as it's clear that "the fact that there are no CDS
/ CDNSKEY records in the child does *not* mean that DS records should
be removed from the parent" around this text of Section 3.

   The

For example, we could say something like "note, however, that the
absence of CDS / CDNSKEY RRset does not mean that the DS RRset be
removed (see Section 4.1)".

This additional note might be too obvious and sound redundant for some
people, but it would help readers like me to avoid possible confusion.

> CDS / CDNSKEY records in their zone - this signals "No change", and is

Sorry, it was actually me who was confused.  When I made this comment
I thought the only possible case where the child zone admin removes
all CDS is an (incorrect) attempt of going unsigned.  That's why I
said "it should mean something erroneous".  With this being
clarified...

[...]

> would "helpfully" remove all DS records, making the sales.exmaple.com

...note the "once one such RR (= CDS/CDNSKEY) is published" part of my
original comment.  It's about the case where all CDS/CDNSKEY RRs are
removed, and is different from the scenario of the lazy child admins.

> but this is a: error prone and b: requires state on the parent.

Note that I'm not against the "no change if no CDS / CDNSKEY RRs" rule
at the parent side.  This is a discussion about a child removing all
CDS / CDNSKEY RRs.  My original comment was based on my confusion that
it could only happen when the child (incorrectly) tries to signal to
the parent that it goes unsigned.  Now I understand it *MAY* do it for
some other reason, so this is not necessarily an erroneous
condition...but, at this point I also wonder, mainly just out of
curiosity: what's the intended reason(s) for the child to do that?  If
there's no specific purpose for the operation but it's allowed (as a
MAY) just to give the child the flexibility, isn't it better to say
"the child MUST NOT (or if it's too strong, SHOULD NOT) remove all CDS
/ CDNSKEY RRs"?  Then, even if the parent side of operation or tool
has a defect and (incorrectly) interprets the removal as the child
going unsigned, that accident will be even less likely to happen.

Just a thought, not a strong opinion.

> Is this clear? I suspect I'm missing some subtleties here.

Yes, I think so.

--
JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 08 Feb 2014 11:06:20 -0800

At Fri, 7 Feb 2014 13:26:53 -0500,

> if no C* in child --> parent has no action to perform" 

Yes, I now understand that.  Please see my latest response to Warren;
I still think it helps to clarify that explicitly.

> Parent updates DS to reflect A and B 

Right, I was still a bit confused here.  Now I understand it, but I
also wonder why would the child deletes the CDS's (again, please see
my latest response to Warren).

> Do you think it is helpful to add an appendix with some examples of use of C* records ? 

Yes, I think so (I don't think I wouldn't need the example myself now
that I understand it, but I guess it helps other fresh readers:-).

> We explicitly outlaw going from Unsigned --> Signed w/o some out-of-band validation. 

That's fine.  I just tried to point out that (even if allowed)
"removing all *Cs as a signal of signed->unsigned" and the "no change
if no *Cs rule" can't coexist.

--
JINMEI, Tatuya