Subject: [DNSOP] Thoughts on CDS

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Apr 2013 13:27:02 -0400

I was thinking a bit about the CDS draft, not specifically it, but the problem it is addressing.

This message was spurred by a comment that "in a key emergency where the private key is exposed" the only way to go forward is to completely stop DNSSEC and then do a re-start from state "0."  The rationale for that was, if I had your private key I could sign the DNSKEY set, add keys at will and generate signatures into the future.  Thus "forward security" would always be suspect.

I don't entirely agree with that.  After thinking some, the reason is that any new key in the DNS is, yes, signed by the old key, but also relies on the presence of a "sympathenic" DS record at the parent.  This represents a "two factor" approach to authenticating the new key - signed by the current zone administrator and also registered with the parent through some other security barrier.

For example, the new key is signed by an old key over the DNSKEY set.  And, assuming EPP, then the key has to come through the registration system's security too.  Yes, you can game either and maybe even both injection paths, but to be effective you have to game both.  Simply put, with just basic security hygiene, it's much harder to game both than to game either one.

From this, one of the important ideas is "two factor" authentication.  "Three factor" might be even more beneficial, but let's shoot for two first.

I think of the CDS proposal as having two components.  One is a means to marshall the information from child to parent.  The other is the way in which the data is transferred and handled.  In concept I wholeheartedly support the former component.  It's the latter component that gives me angina.  (I.e., heart burn, but I was trying to avoid using heart twice in the same sentence in those ways.)

The marshaling is very beneficial, it's much better than the current state of the art of cut-n-paste when the operator of the DNS is not the editor of the registry's contents.  Even if the registry wants DNSKEY records, having an indication of the DS desire allows the registry to get the DNSKEY unless the desire is for an un-published DNSKEY's DS record.  (Which does happen.)  IMHO, I don't support adding DS records based on DNSKEY - I say this not to mean I believe it is wrong but I say it to mean that someone that believes this has to come up with someway to get the un-published DNSKEY from the child to parent to accommodate this OR declare it operationally forbidden (which is also acceptable).

But when it comes to the "how" the data is transferred I have a lot of problems.

First, the draft says that the CDS has to be signed by the KSK and not a ZSK.  This is a problem to me because it's the first time an RRSIG over data is restricted to one kind of key or another.  To me that's a precedent setter, and as such needs scrutiny.  I understand that the requirement is because the KSK manager and the ZSK manager could be different (and are so for the root zone), but this is a change to the protocol in a way that hasn't been explored.  I think that there's something to be learned from the two factor observation though.

The most visible key management function where this plays a role is the root.  But, it doesn't play a role because the root has no parent and thus no need to marshall the key.  (In reality, the keys are marshaled via other means, out of band and play a role in the ICANN KSK ceremonies that happen 4 times a year.)

In any other situation, the CDS ought to just be the marshaling and the RRSIG over it just authenticating that the record got from the child to the parent with integrity.  The "out of band" environment that gets the parent to insert the DS has got to kick in to provide the second factor.

Switching to another environment, the usual case of a registrant in an ICANN-SRM-style zone (shared registry model) using EPP and registrars, this can play out using the following (I switch here because I believe it is a model fot the split KSK ZSK key management system - if they exist other than the root).  The new KSK is made and a CDS set is generated, signed, and published in the zone (omitting details on what is in the CDS for now).  The key management function then alerts the registrar that there's a new DS needed.  Today this is cut and paste and some say that registrars want customers to log in, see ads and then make the request.  True or not, this doesn't have to change, just instead of cut and paste, there's a notification button to click.  No polling, no looking, no pro-activeness needed by registrar.  The second factor here is logging into the registrar portal.

For registries that are willing or want to poll their registrants for CDS records, I'd caution that they might not be doing anyone a favor.  If the KSK was exposed, then a forged CDS might pass as real and the registrant can loose control of the zone - because only one factor was involved and the one factor was gamed.

I'll end this here.  I know that CDS isn't at the foremost of minds now.  There's no sense in a new draft to "compete" and we no longer have higher bandwidth workshops to go over these ideas.  So maybe this will get some others thinking, and whether there's merit to "two factor" approaches to key changes.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 18 Apr 2013 15:15:14 -0700

Edward Lewis <[email-masked]> writes:

[Ed's well written and long thoughts about transfer issues removed]

Security vs operational practice has always been a contention.  Security
purists want the strictest of controls so that nothing can ever be
stolen, misused, abused, modified, etc.  They'd use 4-factor
authentication if they could get away with it (something you have,
something you know, something you are and something from another time
and another galaxy that's amazingly hard to retrieve).  I admit, when I
lean, I lean this direction.

But I've also done enough operational work in my life to know that in an
ideally secure world where security is the only metric, nothing would
get done.  You can't leave the lead box and certainly penetrating wires
wouldn't be permitted through it.  But the internet itself was founded
at the opposite end of the spectrum: purely concerned with operational
practice.  There was no need to secure IP, DNS, BGP, telnet, imap, etc.
Security is often an afterthought, because the first thought is *always*
"can we get it up and running quickly?".  Not, "can we get it up and
running quickly and securely?".  Primarily because "quick security" is
an oxymoron.

So, as always: we're left with a need to make a balanced decision.
Which is better: multi-factor authentication or real-world operational
practice.  Or something in between.  I'll agree with you that by forcing
a user over TLS to make any DS changes in the parent, you're
functionally adding a second authentication form: (a really badly
implemented, ad-laden, web login subject to password database theft and
social engineering...  but still a second authentication form).  Or is
it?  Really it's "a different form".

> If the KSK was exposed, then a forged CDS might pass as real and the
> registrant can loose control of the zone - because only one factor was
> involved and the one factor was gamed.

If your password gets stolen, guessed, entropied away (yes, that's a
verb; shut up spell checker), socialized, etc then you're just as
vulnerable to a take over as if a fake CDS was inserted.  It's still
only "one factor", unless your registar requires two factors itself to
log in (and most certainly don't).  And the key/password bits needed to
log in to your registrar are likely smaller than the entropy used to
sign your zone.  And the registrar login data is usually stored in two
places: their data base and on your post-it note.

Plus, as a colleague of ours frequently likes to iterate "Protecting
your DNS keys with uber-security and not protecting the DNS data source
itself buys you nothing -- Russ Mundy.  Ish; I don't think he'd use 'uber'"
If you have lost control of your zone enough that someone has inserted a
CDS record, they can also insert a new KSK or ZSK to forge records
with.  So denying them the ability to publish a CDS record doesn't
really prevent things anyway.

But all of this brings me back to my starting point: security vs
operation.  It's not up to us to decide which zones are so critical that
they should never be allowed to use CDS records because they must
physical visit their registar with 5 forms of authentication (#5 being
star dust from Justin Bieber's head to prove you have the right to
modify JustinBieber.com).  It's not up to us to deny an operator of 100k
zones the ability to roll keys on a regular basis because it's easy to
do and his organization has a high administrative turnover rate (Justin
Bieber fan club (TM)).

It's not up to us to give them absolute security or operational
mandates.  It's up to us to give them the tools so they can make the
choices themselves for their environment.  It takes the registrar and
the registrant to want to publish a CDS for it to be used.  Either one
can decide they would prefer to use the ad-laden web page login because
it's more secure or it has pretty pictures of Justin Bieber in a
skin-tight racing suit.

CDS is at least a decent middle ground that offers a middle point in the
balance equation.  It provides a decent point where security and
operational practice might be at the top of the tradeoff bubble.  And,
that's why we have operational and security sections in RFCs in the
first place: to document concerns and let the real world make their
decisions based on that discussion.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Joe Abley <[email-masked]>
Date: Thu, 18 Apr 2013 20:11:10 -0400

> decisions based on that discussion.

I wonder actually why we're discussing CDS at all, and are not just sitting back and watch people deploy signed apex DS RRSets. (I understand why we're discussing the general approach. I just don't know why the approach is tied to a new RRType).

There's no protocol meaning at present for an apex DS RRSet, which means it ought to be harmless to add one. A parent (or the parent's agent) could decide to act upon the presence of a signed apex DS RRSet just as easily as it could with CDS. It might as well pick up the signed NS set while it's there.

By this thinking, a signed apex DS RRSet with the meaning discussed for CDS could be deployed today, with no need for code point assignment. What am I missing?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Apr 2013 17:35:14 -0700

> There's no protocol meaning at present for an apex DS RRSet, which means it ought to be harmless to add one. A parent (or the parent's agent) could decide to act upon the presence of a signed apex…

because much of the dnssec infrastructure "knows" that DS is an
exception to delegation, and that it's above the zone cut, there is no
reliable way to query for it under the zone cut.

paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Apr 2013 22:21:33 -0400 (EDT)

> By this thinking, a signed apex DS RRSet with the meaning discussed for CDS could be deployed today, with no need for code point assignment. What am I missing?

Let's not repeat root-servers.net and .net on the same nameserver
leading to overly complex interpretations of old DNS clients vs new DNS
clients for DS records. Or what to serve when parent and child have a
different DS set on the same name server :)

Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 Apr 2013 10:07:13 -0400

> reliable way to query for it under the zone cut.

... except that the clients that would use the apex DS RRSet are special, in that they know precisely what servers to query.

But this would not be an aid to users who would suffer troubleshooting confusion galore, and that seems like a perfectly good reason not to do it.

Joe

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Apr 2013 15:14:47 +0100

Joe Abley <[email-masked]> wrote:
>
> ... except that the clients that would use the apex DS RRSet are
> special, in that they know precisely what servers to query.

That isn't enough to disambiguate which DS is being asked for if child and
parent zones share a server.

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: Joe Abley <[email-masked]>
Date: Fri, 19 Apr 2013 10:15:56 -0400

> parent zones share a server.

Ah yes, also that. OK, I've thrown it in the bad idea bucket. :-)

Joe

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 10:23:29 -0400

> Ah yes, also that. OK, I've thrown it in the bad idea bucket. :-)

One of the regrets about DNS design is that we used NS above and below the zone cut.  That complicated DNSSEC.

We resisted the temptation to have KEY (later called DNSKEY) at both parent and child because of the issues.  NSEC, yes, sigh, it was a headache but we scaled that mountain.

So, "in the big book of boo-boos" (to quote Doc McStuffins), we should avoid having the same type appear above and below a cut.  It pays to have a separate name - even if that alone is the difference (in the presentation format ;)).

---

From: P Vixie <[email-masked]>
Date: Fri, 19 Apr 2013 07:55:23 -0700

Ns, above and below, was easy to handle even in dnssec, since it was always part of the delegation and was only signed in the child. Making any other rrtype above and below would be much harder since it would not automatically be exposed on every referral.

The boo boo was putting ds at the delegation point. Had we put it at _ds._dnssec.$delegationpoint then it would have an unambiguous location in the parent and could be queried via non dnssec aware middle boxes. Which would make stub validation a lot more practical. Oh well.

Paul

Edward Lewis <[email-masked]> wrote:

>We resisted the temptation to have KEY (later called DNSKEY) at both
>parent and child because of the issues.  NSEC, yes, sigh, it was a
>headache but we scaled that mountain.
>
>So, "in the big book of boo-boos" (to quote Doc McStuffins), we should
>avoid having the same type appear above and below a cut.  It pays to
>have a separate name - even if that alone is the difference (in the
>presentation format ;)).
>
>------------------------------------------------------------------------
>
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: P Vixie <[email-masked]>
Date: Fri, 19 Apr 2013 07:57:29 -0700

Joe the special clients still have to forward through middle boxes sometimes. This special rule won't be known there. 

Paul

Joe Abley <[email-masked]> wrote:

>>> There's no protocol meaning at present for an apex DS RRSet, which
>means it ought to be harmless to add one. A parent (or the parent's
>agent) could decide to act upon the presence of a signed apex DS RRSet
>just as easily as it could with CDS. It might as well pick up the
>signed NS set while it's there.
>> 
>But this would not be an aid to users who would suffer troubleshooting
>confusion galore, and that seems like a perfectly good reason not to do
>it.
>
>
>Joe

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 19 Apr 2013 08:21:29 -0700

Joe Abley <[email-masked]> writes:

> By this thinking, a signed apex DS RRSet with the meaning discussed
> for CDS could be deployed today, with no need for code point
> assignment. What am I missing?

Besides the other two comments: DS records are signed with the ZSK, and
the CDS document explains why it needs to be signed with the KSK instead
(also).
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 Apr 2013 11:28:18 -0400

> the CDS document explains why it needs to be signed with the KSK instead

I'm not sure I fully understand the logic of that, actually.

Surely the important thing is that the apex CDS RRSet in the child zone can be verified to be authentic. Whether that means that CDS has an RRSIG created by a KSK or a ZSK should make no difference, so long as the chain of trust from the parent zone is intact.

Why is it not sufficient to specify that the authenticity of the CDS RRSet in the child zone should be able to be verified using DNSSEC, or else that the CDS RRSet should be ignored?

Joe

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 11:29:20 -0400

> the CDS document explains why it needs to be signed with the KSK instead

That is one of the things I don't like about the CDS semantics.  I don't want special signing rules and would hope that using a "second factor" would suffice.

When it comes to the root zone, the example given to me as the justification for this, CDS wouldn't apply and if it did, there's the second factor being the transport of the keys via the KSR and specific steps in the KSK ceremony script.  (For some reason, when I try to write this, I lose the terminology I want to use.)

I am unconvinced that the special signing rules mentioned in the draft are warranted and is one of the main reasons I am not a supporter of the draft.  I have a fundamental objection to that specific provision.  Yes, even understanding the rationale for it, I don't buy the reason.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Apr 2013 11:33:53 -0400 (EDT)

On Fri, 19 Apr 2013, Joe Abley wrote:

> Surely the important thing is that the apex CDS RRSet in the child zone can be verified to be authentic.

and that it is signed by the KSK holder - not the ZSK holder. If the
parent would update its DS based on the child's ZSK's signature, then
the ZSK is used as KSK and the ZSK holder can bypass the KSK, and thus
seperation of duties and/or different HSM/storage/security is bypassed.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 19 Apr 2013 11:37:12 -0400

> Why is it not sufficient to specify that the authenticity of the CDS RRSet in the child zone should be able to be verified using DNSSEC, or else that the CDS RRSet should be ignored?

Flippant answer: in the case where same entity operates both KSK and ZSK keys, just use singe key in both roles. 
Serious answer: CDS becomes part of the Trust Anchor authentication chain, in RFC5011 Trust Anchor Maintainers only accept new trust anchors that
are signed by the old Trust Anchor, and CDS copied that requirement. 

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 11:58:19 -0400

> are signed by the old Trust Anchor, and CDS copied that requirement. 

I don't buy into that.  That 5011 depends on "X" (which is fine) does not imply to me that the CDS has to also have that requirement.

Once 5011 believes the new trust anchor is earnest, why does this need to be further checked?

And, in the case of a compromise of a key's secrecy, which I see as a problem for 5011, is the situation any better if the CDS is signed by a KSK?

The point I am coming back to is that if a ZSK is exposed, false RRSIGs will validate until the ZSK disappears from the DNSKEY set (in caches).  The zone administrator can roll out of the compromised ZSK to eventually end the abuse - but in the interim the false ZSK can be used to extend signatures over the DNSKEY for a very long time.  Only when the DS set (which is beyond the ZSK's reach) eliminates a chain through the ZSK can the abuse end.

Question: If you get a DNSKEY set that has these records:

$TTL=1 week
ZSK - compromised
KSK - "safe"
RRSIG by KSK good from now until May 1, 2013
RRSIG by ZSK good from now until December 31, 2038

would you validate this on April 30, 2013 and hold it for a week?  Assuming that there's still a DS record that "works?"  (Would this extend the damage?)

I.e., sometimes rolling out the ZSK isn't enough, the KSK/DS has to go too.

It seems to me that no matter what key is compromised, KSK or ZSK - or even a CSK - the DS has to be changed.  The DS is a "second factor" here because it would take a different key compromise to game that (assuming cross-organizational delegations).

Sorry folks, this discussion is probably a bit much in email, but it's the only venue we have.  I appreciate the reluctance to have long, boring yes/no debates, but I think there's some fundamental issues to hammer out first.  When I say I'm unconvinced, I don't mean the requirement is wrong, I mean that I don't see a clear reason for what I think is potentially just an invitation for yet another corner case.

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Apr 2013 17:33:12 +0100

Edward Lewis <[email-masked]> wrote:
>
> The point I am coming back to is that if a ZSK is exposed, false RRSIGs
> will validate until the ZSK disappears from the DNSKEY set (in caches).
> The zone administrator can roll out of the compromised ZSK to eventually
> end the abuse - but in the interim the false ZSK can be used to extend
> signatures over the DNSKEY for a very long time.  Only when the DS set
> (which is beyond the ZSK's reach) eliminates a chain through the ZSK can
> the abuse end.

The lifetime of this kind of compromise is limited by the expiry time of
the KSK's RRSIG over the DNSKEY RRset. The attacker with the compromised
ZSK can't extend this since they can't re-sign the DNSKEYs in a way that
will be authenticated by the DS.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Apr 2013 12:41:08 -0400 (EDT)

> will be authenticated by the DS.

Which is why the ZSK should never be trusted for a RRSIG over CDS to
update the DS recors, because then it could cycle the existing KSK out
of the DNSKEY RRset.

Paul

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 Apr 2013 13:07:24 -0400

> seperation of duties and/or different HSM/storage/security is bypassed.

I understand that concern, but I think we need to be pragmatic and avoid being overly prescriptive.

If an individual zone maintainer's processes impose a separation of duties between KSK management and ZSK management, then they should make decisions that they are comfortable with. The decisions as to how any CDS RRSet should be signed are in the right place, and I don't think it's sensible to require that the parent make assumptions about what is good or bad practice at the child.

I think that documenting these concerns (to encourage people to think about them) is sensible.

I don't think it's sensible to make assumptions and prohibit behaviour that in many cases might be perfectly sensible.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 13:15:07 -0400

> will be authenticated by the DS.

The question is whether the expiry of the KSK matters more than the expiry of the ZSK.

The case we are talking about here is the ZSK being compromised.  What I was also thinking about is a compromise of the KSK.  Or more accurately, compromise of the SEP.

I'm trying to work out whether it's sufficient to just roll out of the ZSK to end the suffering of a compromise (realizing that there's the signature effectivity and ttls to expire) or if you'd have to roll the KSK too - assuming a ZSK (non-SEP) compromise.  It's clear that if the SEP is compromised, I have to clear it out of the DS set.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 13:22:43 -0400

> update the DS recors, because then it could cycle the existing KSK out

My response is that the CDS should not automatically cause a change to the DS, just marshall the data.

I am pushing to rely on a second factor (the security over the c&c channel to the parent) to verify the request.

I'm not comfortable with in-band scraping.

PS - What if the KSK/SEP is compromised?  Then the attacker can roll the legitimate KSK out and replace it with their own (assuming that they could do it as described).

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Apr 2013 10:36:23 -0700

> I am pushing to rely on a second factor (the security over the c&c channel to the parent) to verify the request.

But what if that second factor is compromised?!?! :-)

As Wes pointed out, the choice is adding in more things that an attacker must surmount versus making the normal thing happen easily.

In every system that requires authentication for an action to happen, there will be chances of compromise of the authentication mechanism. Operators get to decide how much they care about that.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 14:45:00 -0400

> But what if that second factor is compromised?!?! :-)

I'm going out on a limb but I believe compromising two things is harder than compromising just one.  Perhaps "harder or just as hard as" but not "is easier".

At some point, the question is - what if the earth blows up?

Seriously...so what I'm trying to do is make sure operators have the chance to do things right.  If the IETF comes up with a process that has a single point of security engineering failure, it's a single point of failure in operations.

If there are two or more factors, it is possible for me to split the roles around my organization.  I might not, but I have the ability to do so.

I work in a fairly large organization.  If you look at just one line or business we have a separation between those that push the DS record around and those that have access to the key management machinery.  In another area, some of the bits of this are embedded (or will be) in a completely separate location (architecturally) from the other half.  (I'm not diving into that detail.)

We didn't try to make "it" two factor, but that's the way it has naturally fallen out.  And it turns out to be a good thing.  It's harder to corrupt the practice.  Again, that wasn't the goal, but in thinking over CDS and our position - and see a nice alignment.

I'm not saying it's always this way.  For smaller operations these functions might reside in one place, one person.  And if we were forced to use a one-factor way, we'd work it but the result would be less than optimal.

What I'm hammering is - give me, the operator, the ability to do my job right.  I'm a bit frustrated when I'm handed technology that assumes I'll make the wrong choices and tries to shoe horn my operations into the one true way.  That stifles innovation.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Apr 2013 15:02:27 -0400 (EDT)

> I am pushing to rely on a second factor (the security over the c&c channel to the parent) to verify the request.

We don't need the CDS to do that. We already have EPP for that. We _are_
trying to automate this. That's the whole point of CDS.

> I'm not comfortable with in-band scraping.

That's fine. Don't publish CDS as a child, or ignore CDS as a parent.

> PS - What if the KSK/SEP is compromised?  Then the attacker can roll the legitimate KSK out and replace it with
> their own (assuming that they could do it as described).

If the KSK is compromised, they likely can redirect email too, so making
a registry password reset is not that far off either.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Fri, 19 Apr 2013 15:26:43 -0400

> trying to automate this. That's the whole point of CDS.

No, "we" don't.  "I'm" a DNS service operator.  "I'm" not a registrar.  There is no EPP server that will accept a connection from us (if we had an EPP client.)

Please remember that the entire world is not subject to ICANN requirements nor follows it's advice.  (This is not a slam on ICANN, their heart is in the right place.  But they are not a monopoly.)  It's not "our" choice anyway.  Imagine that I am serving a customer base that collectively has 10 delegations in each and every TLD out there.  And some customers are just subdomains of an enterprise DNS set up.  Think about that end of the connection.

In as much as a the Internet is not the Web...for DNS operators, CDS could fill a gap that is not currently addressed.

> That's fine. Don't publish CDS as a child, or ignore CDS as a parent.

How do my customers then get the DS from our servers to their registration systems (registrars with EPP or not)?  The state of the art is cut and paste for most.  Without a standard here, we are stuck with a lowest common denominator situation.

> a registry password reset is not that far off either.

This expression is an example of what I'm trying to fight.  The IETF should not assume anything about how operators work.  Seriously.

I have to sound insulting, but does the IETF really think operators are idiots?  This is why I'm so frustrated.  We protect our businesses.  For the most part, "things work."  From what I see on these lists I'd think that all that operators ever do is fraught with peril and nothing is progressing.  I.e., don't assume that email is the only way we communicate.  Don't assume registry passwords are protected one way or another...

Sorry - it's Friday.  It's been a long week.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 20 Apr 2013 13:40:05 -0400 (EDT)

Sorry. You are right. CDS is a method for non-TLD paren-children to
communicate the KSK information from child to parent. And even more
important because there might be no EPP or other standarized channel.

> How do my customers then get the DS from our servers to their registration systems (registrars with EPP or not)?
>  The state of the art is cut and paste for most.  Without a standard here, we are stuck with a lowest common
> denominator situation.

Now I'm confused about what you would like to see.  You wrote:

> I am pushing to rely on a second factor (the security over the c&c
> channel to the parent) to verify the request.
> 

I guess we could add language that states the intention of the child.

If the CDS is signed by the KSK, the child agrees for the parent to update the DS.

If the CDS is signed by the ZSK, the child is just "marshalling the data" and the
parent should look elsewhere for the authentication of that data.

This still leaves open that a compromised KSK can lead to parent DS
changes, but I don't see a way around that without sacrifcing the
requirement that fully automated KSK rollovers using just DNSSEC data
in the zone should be possible.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Apr 2013 09:32:55 -0400

> I guess we could add language that states the intention of the child.

First, some use cases, written from the child operator's perspective:

I want to add a DS record for a key that is not yet published.
I want to delete a DS record for a key that has never been published. (*)
I want to add a DS recrord for a key that is in use.
I want to delete a DS record for a key that is in use.
I want to add DS records for hashes not previously supported.
I want to add DS records for hashes I am moving away from.
...and others in the "I want to add/delete" category.

> parent should look elsewhere for the authentication of that data.

We really do need to drop the KSK and ZSK terminology because there are Common Signing Keys coming "back" in vogue.  The factor is whether a key is a SEP or not.  Recall that in the validation and signing engines, the SEP bit is not significant, it is there for the convenience of key management tools.

What if I use a key in the role of a ZSK and then decide to convert it into an SEP?  Today I can do this by just adding a DS record for the key.  But if we start with rules on what roles can sign what record sets and in what ways, I'd have to flip the SEP bit - which then changes the identity of the key.  (Same issue as in revoking keys a la RFC 5011.)

> in the zone should be possible.

I think you can close that vulnerability by relying on "some other factor" in the key change process.

Where is the requirement for "fully automated KSK rollovers using just DNSSEC data" come from?  I don't mean a document citation, I mean the basis in reality?  I can see the allure but I don't think it is wise.

What  I have in mind - and this isn't a "has to be this way" - is this kind of a specification.

1. A definition of the CDS record set that conveys the hashes from the child to the parent or a means for the parent to get keys if they so desire.  What I don't have a solution for is supporting DS records of unpublished DNSKEYs in zones were the parent wants the keys.  Included would be ways to specify hash functions that the parent hasn't implemented, etc., i.e., the ability for the child to be totally autonomous in the management of their zone.  I am not overly aggressive parental actions, but there should be support for "true" delegations of authority.

2. From the child side, when a child publishes CDS record(s), a statement of what that means.  In some sense it will be dependent on step 1.  My preference is that a CDS record is an incremental change request of the parent, others want the set to be the desired state at the end of all operations.  Either one is possible, my preference is just "that" at this point.

(As far as what key signs the see my previous words.)

What's to be left out of the "spec" and addressed in words is that the child might have to alert the parent.

3. Again from the child side, when does it withdraw the CDS record(s) (set).  Could be that the child keeps it there until the parent held DS set matches (polling) or some other event happens.  I'd default to a zone polling the parent over event driven because removal of records is the forgotten step in most operations.

4. From the parent, words on detection of the record(s) (set), words on how to perform the operations, and then a discussion on letting the child know.  Here's where I see a lot of pitfalls in IETF document processing.  If the document specifies one way to do detection or another, this will be burned into the RFC.  From then on, all those following the RFC would have to deal with compliance questions...so even if I just want to make use of what is in part 1, I'll have to address why part 4 is or is not applicable.

---

From: Chris Thompson <[email-masked]>
Date: 22 Apr 2013 18:50:38 +0100

On Apr 22 2013, Edward Lewis wrote:

>We really do need to drop the KSK and ZSK terminology because there are
>Common Signing Keys coming "back" in vogue.  The factor is whether a key
>is a SEP or not.  Recall that in the validation and signing engines,
>the SEP bit is not significant, it is there for the convenience of key
>management tools.

I was extremely pleased to see that draft-kumari-ogud-dnsop-cds-01 dropped
all mention of KSK and ZSK (well, almost - there is a reference to KSK in
the introduction). It may be that there is still too much talk about the
SEP bit.

The essence of the previous requirement that CDS RRsets were to be signed
with a KSK is much better captured by the current text:

   The CDS record MUST be at the zone apex, and MUST be signed with a
   key that is represented in the current DNSKEY and DS RRset's.  If
   these conditions are not met the CDS record MUST be ignored.

That is, the chain of trust used by the parent to validate a CDS is
restricted to be of length 1. That is all it knows on earth, and all
it needs to know (with apologies to John Keats).

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Apr 2013 15:15:54 -0400

>  these conditions are not met the CDS record MUST be ignored.

What confuses me is that signing in DNSSEC is not done on a record by record basis but on a set basis.  Meaning, you can't "ignore" a record within a set.  For the use case of wanting to publish a DS record for an unpublished DNSKEY, how will this work?  In this case, I can sign the set with an existing DNSKEY that is represented in the DS set.  With that, all CDS records would be authenticated.  Perhaps this is just a wording issue, but the alternative to that is that none of the CDS set is valid.

Requiring a CDS to be signed by a key that is present and signs the DNSKEY set as well as being referenced in the DS set before it is accepted as a request of the child is different from requiring the set be signed by a key with a KSK designation or even an SEP bit turned on.  The former is setting up rules "above" the normal validation of DNSSEC data and therefore can be set into a code path reserved for a special function.  The latter (placing more requirements on what key can be used to validate data) represents a change to the basic validation rules in DNSSEC - that is something I want to avoid because it would open up a new set of issues that we've not explored.  (Well, actually, in the early days, we toyed with key role-based rules for authentication and the models failed.  If anyone reads the ancient texts, there's a talk about key strength, which was part of the failed experiments.)

I would accept that the parent ought to be aware of what key signs the CDS set and could use that information in determining the authenticity and authorization of the request.  In some use cases this could be acceptable to me (said in the sense that I'm not sure yet.)  However, in other cases, I would want stronger checks to take place.

Note that I am not saying that it would be bad to define a key change where the parent only needs the CDS set to be signed by (ultimately) a key represented in the existing DS set.  (I'm using multiple negatives here on purpose "not saying...it would be bad".)  I think that such a practice can co-exist with stronger practices, like those requiring out of band notifications and confirmations.  I want there to be the possibility of more than one model for authentication and authorization, based on the existence of a "standard" CDS.  I don't want "my way" to be the one, I just want to make sure that I can handle multiple ways with a common data representation.

In my code, I'd want to sign the CDS set like it was an A record set.  For zones that need the signer to be in the DS set too, that would be a special case but one that could be triggered automatically.  Somehow, perhaps in the CDS record itself ("request for SEP signature bit").

> it needs to know (with apologies to John Keats).

I really don't think this is important.  For example you might have a registrant who "owns" a name, outsource it's web and dns operations to a third party, register the name via a reseller (that provides a WhoIs proxy service to hide the registrant) who then uses a registrar that talks to a registry to get a name into TLD that is run by a backend operator.  Having a trust chain of length 1 in DNSSEC is a false sense of "closeness" here.  We talk of trying to prevent a false sense of security at times.

In sum, think of the way the SEP bit was born.  As a help to tools that set up a zone.  Not as a factor in normal line DNSSEC processing, something not to be used or assumed by the validators.  For the CDS, the special processing line is tied to how you provision the parent than how data is validated.  For this I'd make sure the recommendations and/or rules in the document take steps to enforce the nature of the SEP bit and not lead us into confusion.  And, again, I want to be able to deal with multiple back-end procedures for finding, accepting, and processing the request that a CDS represents.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 22 Apr 2013 13:15:44 -0700

> channel to the parent) to verify the request.

Nothing is preventing that from happening too.   IE, there is nothing in
the existing document that prevents a registar or other parent from
putting this on their webpage:
                             
   Update the DS record when (pick one):
     [ ] Ever a properly signed CDS record exists
     [ ] Ever a properly signed CDS record exists and I click an OK button here
     [ ] Never.  I enjoy the ctrl-v experience.

There is still no point in mandating that an auto-accept can't happen
for those that want to.  There is no point in pushing that option into
the spec itself; the parent already has a database of options the child
wants.  The parent already has the ability to require a user to push an
OK button if it wants it.  So does the child (assuming the parent has a
radio-dialog as indicated above).

There is nothing preventing a CDS record from doing both automated
marshaling and accept *or* just automated marshaling.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 22 Apr 2013 13:19:07 -0700

Edward Lewis <[email-masked]> writes:

> I am unconvinced that the special signing rules mentioned in the draft
> are warranted and is one of the main reasons I am not a supporter of
> the draft.  I have a fundamental objection to that specific provision.
> Yes, even understanding the rationale for it, I don't buy the reason.

For what it's worth: I'm sort of on the fence when it comes to needing
to sign with the KSK.  There are so very very few key-split owners out
there that it's not a huge market for them, and I doubt any of them will
want to do CDS anyway to their parent.

So, if it didn't change the what-must-sign it rule, would you come to
support it?
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 22 Apr 2013 14:17:21 -0700

> want to do CDS anyway to their parent.

FYI: I meant to mention that there is a significant number of operators
that do actually protect their keys with different levels of protection
and keep their KSKs in a "better vault".  Those folks might be a bit
more perturbed if a ZSK could publish a new KSK.  And there is more than
a single-hand-count of them, unlike the ZSK/KSK ownership split.

And yes, anywhere I said "KSK" you should read it as "key with the SEP
bit set"
-- 
Wes Hardaker
Parsons

---

From: Joe Abley <[email-masked]>
Date: Mon, 22 Apr 2013 17:19:34 -0400

On 2013-04-22, at 17:17, Wes Hardaker <[email-masked]> wrote:

> and keep their KSKs in a "better vault".

That's interesting. Can you cite examples?

The only example I know of is the root zone, which is weird and special for a variety of non-technical reasons. Last time I looked neither the BIND9 nor OpenDNSSEC toolchains supported offline-KSK operations without a lot of hackery.

Joe

---

From: Doug Barton <[email-masked]>
Date: Mon, 22 Apr 2013 14:41:35 -0700

> The only example I know of is the root zone, which is weird and special for a variety of non-technical reasons. Last time I looked neither the BIND9 nor OpenDNSSEC toolchains supported offline-KSK…

Various TLDs discussed their plans to take similar steps at various 
points in the past. There is no reason to believe that other sites 
(particularly large financials) wouldn't be doing the same.

That said, I don't see any reason to introduce "ZSK can validate a CDS 
record," and lots of reasons to require the KSK(s) to do so. If off-line 
KSK users can't use CDS to do their thing, I'm sure they would consider 
that an acceptable compromise.

Doug

---

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Apr 2013 17:48:25 -0400

On Apr 22, 2013, at 5:41 PM, Doug Barton <[email-masked]> wrote:

> Various TLDs discussed their plans to take similar steps at various points in the past. There is no reason to believe that other sites (particularly large financials) wouldn't be doing the same.
> 
> That said, I don't see any reason to introduce "ZSK can validate a CDS record," and lots of reasons to require the KSK(s) to do so. If off-line KSK users can't use CDS to do their thing, I'm sure they would consider that an acceptable compromise.

Um, I'm probably missing something obvious here, but you cannot use CDS to enroll in DNSSEC. This means that you'll have to use the original out-of-band system -- what if we extend Wes's radio buttons to include ZSK / KSK[0]?

 Require that this is signed with the KSK?
    [] Yes, I have separate process for my keys.
    [] Nope, they all live on the same filesystem. If someone gets one, they have the other.

Obviously the parent now has more state (and the child's logic is a little trickier), but...

W

[0]: s/KSK/a key with the SEP bit  set/G

> Doug

---
Schizophrenia beats being alone.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Apr 2013 19:53:51 -0400 (EDT)

> Obviously the parent now has more state (and the child's logic is a little trickier), but...

You are making keys without the SEP bit an indirect Secure Entry Point.
They become their own boss. In such a case, you might as well give that
key the SEP bit (and not ruin the meaning of the bit for others)

Paul

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Apr 2013 10:21:36 -0400

I'm going to attempt to reply to a few messages in one.

> marshaling and accept *or* just automated marshaling.

I agree - in the sense that the "science behind it" allows for one marshaling mechanism to be used different ways.

What I am leery of is that once an RFC is published saying "here's how you marshall it" and "here's how the data transfer works" the perception is that to "do" CDS at all you have to both use the record and do it that way.  I speak from the experience of answering RFPs that ask for comments about compliance with a laundry list of RFCs.  Buyers (RFP issuers) rarely show that they've read the RFCs by referencing only the applicable sections to the bid, and commonly an RFP writer will copy another RFP lock, stock and barrel when it comes to things like technical details.

So, my "gating requirement" for the proposal is that the document does it's best to say "here's a good marshaling data structure" and separably "here's one way to use it" and preferably "here's another way to use it."

This gating requirement is strictly a "how it is written" issue.  And, I do think it is very important that the document is very clear so that when it comes to RFP or compliance or even audit time, legal/contractural issues are minimized.

> So, if it didn't change the what-must-sign it rule, would you come to

It is not so simple.  In one of my long-winded, rambling, stream of consciousness messages I suggested that there be no change to "how it is signed" and "how it is validated" rules.  Special rules can be written for the provisioning system - an yes, the signer has to know to support that.

I firmly believe that a validator (as described in 4033-4035) should have to be altered for the CDS proposal.  But I have far less of an objection to having the element that accepts the CDS from the child having special rules - mostly because these do not exist today, there's no code to retrofit, no backwards compatibility concerns.

> That said, I don't see any reason to introduce "ZSK can validate a CDS record," and lots of reasons to require the KSK(s) to do so. If off-line KSK users can't use CDS to do their thing, I'm sure t…

Back in the day, (meaning in the late 90's before the first workshops) we (Olafur, Brian, Russ and I) toyed with many ways to do DNSSEC.  One was to have off-line keys like KSKs (well before we made the split in the workshops) and to have on-line keys like ZSKs and denote them with "key strength" bits.  The idea was that we'd have a protected key for data that needed high assurance and a vulnerable key for data that needed convenience.  We quickly realized that this was non-sense as "a chain is only as strong as it's weakest link."  In normal operations it just doesn't make sense to split the key management.

Now, Joe is right.  The root zone is a special case.  While "weird" is a flippant word to use here, it seriously deserves a different treatment - and the root zone gets that treatment.

What I am saying is, if there are cases of someone thinking that it is worth the time to split KSK and ZSK, I'd urge them to reconsider.  It's not terrible but it is over engineering.  I'm not inclined to "optimize" for such an use case.  I'm for choice in how to operate.  But there are limits to what you can support.  If the system is too invertebrate-ish, it won't provide any support and will just become a morass of useless tissue. 

> Um, I'm probably missing something obvious here, but you cannot use CDS to enroll in DNSSEC. This means that you'll have to use the original out-of-band system -- what if we extend Wes's radio butt…

Ultimately, I'm still uncomfortable with anything that does not use the out-of-band mechanism.  At the start of this thread was the question of "what if the secrecy of the KSK private key is lost? How do you go forward?"

Conventional wisdom du jure is that the only "gotta do it" reason for a key change is just about that case.  All the other reasons are more or less window dressing.  (Yes, you could totally lose the private key, but then there's no way to roll out of it "in band.")

 I can't see how a reasonable approach can be made to work only in-band.  Ever.  Where reasonable means "has no gaping holes that might actually happen in operations."

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Apr 2013 10:44:37 -0400

> I'm going to attempt to reply to a few messages in one.

… and I'm going to snip a whole bunch of text and just respond to part of it :-)

[ SNIP ]

> Ultimately, I'm still uncomfortable with anything that does not use the out-of-band mechanism.  

Unfortunately the whole point of the CDS draft is to allow rolling of keys without having to do the whole out-of-band thing. 

The problem statement is basically: "It is really annoying to have to go to my registrar (or whatever other parental relationship I have) and click through a whole bunch of screens to finally get to the place where I enter the DS. I'm ok to do this once or twice, but having to do it <blargh> times every <foo> sucks and so I just don't do it at all".

(where <blargh> is the number of domains I hold and <foo> is my key roll interval (and *please* let's not get into any religious arguments about the value (or even units) of <foo>))

> At the start of this thread was the question of "what if the secrecy of the KSK private key is lost? How do you go forward?"

You:
1: Curse.
2: Figure out how it happened.
3: Bitch at Bob, who decided to back it up by printing it out on a pile of 8.5"x11" and then left it under his keyboard.
4: Suck it up and log onto the registrars web site (or however else you securely communicate with your parent) and click the "Delete *ALL* DS records" button, then click the "Add DS record" button and manually enroll a new DS (just like you currently do…)
5: Remove Bob's sudo access.
6: Profit!

> Conventional wisdom du jure is that the only "gotta do it" reason for a key change is just about that case.  All the other reasons are more or less window dressing.  (Yes, you could totally lose th…

This is only "conventional wisdom" amongst some folk -- some folk wish to be able to roll their keys every X weeks / months / years. This is for a variety of reasons, from the sane to the crazy, but it (IMO) their right to decide how often (or even if) they wish to roll.

>  I can't see how a reasonable approach can be made to work only in-band.  Ever.  Where reasonable means "has no gaping holes that might actually happen in operations.
> 
> 

-- 
There are only 10 types of people in this world -- those who understand binary arithmetic and those who don't.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Apr 2013 11:18:41 -0400

> Unfortunately the whole point of the CDS draft is to allow rolling of keys without having to do the whole out-of-band thing. 

What's really unfortunate is that the CDS record could be flexible enough to work with an out-of-band arrangement if the proposal well-designed, but if the document insists on weaving in an in-band only arrangement, the idea will flail.  Opportunity to be useful is lost.

> The problem statement is basically: "It is really annoying to have to go to my registrar (or whatever other parental relationship I have) and click through a whole bunch of screens to finally get t…

For zones that operate under a mandate of the ICANN-style shared registry model, you can't bypass the registrar.

If this is something that a registrar will make use of to allow it's customers to pass DS material to the parent, if there is not significant support from registrars then this will be a hollow proposal.  My challenge then is to see demonstrated support from the registrars and sufficient adoption that there's pay off.  Or else we wasting our time.

I say that because it's been suggested that registrars would rather have registrants log in more often than less for other marketing reasons.  (But I don't know, I'm just saying I've heard that.)

. . .

I see great potential in this proposal as the corner stone of a general approach to the problem.  Weighing it down by tying it to one use case or one set of operational assumptions will not only kill it's payoff the weight will kill off the ability to use the important bits and pieces in a more general approach.  That is why I bother thinking about CDS at all.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 23 Apr 2013 11:35:44 -0400

On Apr 23, 2013, at 11:18 AM, Edward Lewis <[email-masked]> wrote:

> If this is something that a registrar will make use of to allow it's customers to pass DS material to the parent, if there is not significant support from registrars then this will be a hollow proposal.

If you build it they may come. If you don't build it you'll never know… A number of registrars have mumbled that it seems like a reasonable idea. There are also registrars that cater to larger customers (with thousands of domains), they would rather keep the account instead of displaying ads. This is apse designed for places where you don't have a traditional registrar (think organizations / educational institutes, etc)

>  My challenge then is to see demonstrated support from the registrars and sufficient adoption that there's pay off.  Or else we wasting our time.
> 
> I see great potential in this proposal as the corner stone of a general approach to the problem.  Weighing it down by tying it to one use case or one set of operational assumptions will not only kill it's payoff the weight will kill off the ability to use the important bits and pieces in a more general approach.  

See Wes's suggestion on radio buttons.

If you are a registrar[0] who wants to specify that your users have to login and click a "I've published a CDS record, please import that" button no-one[1] can stop you…

W
[0]: as an example
[1]: I'm assuming no-one can stop you, but who knows...

> That is why I bother thinking about CDS at all.
> 

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Apr 2013 08:52:09 -0700

> What's really unfortunate is that the CDS record could be flexible enough to work with an out-of-band arrangement if the proposal well-designed, but if the document insists on weaving in an in-band…

You are conflating two features that you want: in-band signaling and out-of-DNS-band authorization.

It is perfectly reasonable for a parent to have a policy of "we will not look for a CDS until we have gotten an authenticated request to do so", and that request mechanism can be a standardized HTTP request. Designing the latter is trivial and can be done in parallel with the CDS work.

FWIW, I think that the out-of-band "make me look" protocol is quite worthwhile. The more I look at some of the weirdness that is in CDS (artificial differences of KSK and ZSK, partial signing, etc.), the more I think that trying to do this in DNS under DNSSEC is stretching the DNS too far. 

> By this thinking, a signed apex DS RRSet with the meaning discussed for CDS could be deployed today, with no need for code point assignment. What am I missing?

... was followed by throwing out the idea because:

> parent zones share a server.

With a secure out-of-DNS-band authorization that says "please fetch my DS records, and they will look like X" where X is the record or a hash of the record, there is no problem with signed apex DS RRsets even when the child and parent zones share a server.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Apr 2013 11:58:48 -0400 (EDT)

On Tue, 23 Apr 2013, Edward Lewis wrote:

> What I am saying is, if there are cases of someone thinking that it is worth the time to split KSK
> and ZSK, I'd urge them to reconsider.

If your nameserver requires the private ZSK for inline/ondemand signing,
like bind or powerdns, then having the KSK offline on another machine is
a very valid use case. The CDS record should not break that.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Apr 2013 12:07:34 -0400 (EDT)

> For zones that operate under a mandate of the ICANN-style shared registry model, you can't bypass

Thing could change.

> If this is something that a registrar will make use of to allow it's customers to pass DS material
> to the parent, if there is not significant support from registrars then this will be a hollow
> proposal.

There are many very sane CC:TLDs out there too.

> I say that because it's been suggested that registrars would rather have registrants log in more
> often than less for other marketing reasons.  (But I don't know, I'm just saying I've heard that.)

I believe in the free market. I recommend gkg.net as a registrar because
they do allow me to send JSON requests to them for DS updates of my
domains. So let's not use marketing arguments for protocol design.

Paul

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Apr 2013 12:11:31 -0400

> FWIW, I think that the out-of-band "make me look" protocol is quite worthwhile. The more I look at some of the weirdness that is in CDS (artificial differences of KSK and ZSK, partial signing, etc.…

I agree with both of those statements.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Apr 2013 12:15:40 -0400

> a very valid use case. The CDS record should not break that.

I don't agree with that - if the ZSK is compromised, what good is having a non-compromized KSK?  For anyone other than the root, changing the KSK is pretty trivial.  Even without CDS.

Back in the day, one of the fears was weak host security.  That's gotten a lot better.  And the use of hidden masters inside protected enclaves has become much more common.   With these advancements over time, complicating key management is less desirable.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Apr 2013 12:26:55 -0400

> There are many very sane CC:TLDs out there too.

The point is that there are arrangements where you can't talk directly.  And there are arrangements were you can talk directly.  And there are arrangements where the lingua franca is DNSKEY and not DS.  There are many environments.  That is why I'm fighting a one-size fits all, in-band only solution.

> domains. So let's not use marketing arguments for protocol design.

I have a hard time not saying this sarcastically - yeah, let's ignore reality.

"Marketing" and "market forces" determine our requirements.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Apr 2013 12:39:18 -0400 (EDT)

On Tue, 23 Apr 2013, Edward Lewis wrote:

> The point is that there are arrangements where you can't talk directly.  And there are
> arrangements were you can talk directly.  And there are arrangements where the lingua franca is
> DNSKEY and not DS.  There are many environments.  That is why I'm fighting a one-size fits all,
> in-band only solution.

People suggesting CDS are not suggesting implementing this is mandatory,
and is the One True Way. In fact, it is quite the reverse. CDS proponents
want to _ability_ to signal inband using the DNS and existing trust
anchors (DS-KSK pairing), and no desire to abolish existing out of band
methods.

Everyone who does not like any of this in-band DNS stuff is free to
ignore CDS records at children, and not publish them for parents. Whether
dictated by (in)sanity, lawyers, or the White Knights scaling the ICANN
Ivory Towers or Ayn Rand.

I get it, you don't like the concept. So don't use it. For those who _do_
like the concept, let's get to a specification that can be useful to most
without crippling the basic use case of "using an existing authenticated
trust relationship in-band to the DNS for automated updates of the DS
record" (and/or NS/GLUE records)

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Apr 2013 10:16:08 -0700

> record" (and/or NS/GLUE records)

Except that this thread has brought out many problems in the -01 draft that will likely result in changes that will make CDS special, not just like other records. At that point, you will have to decide if having a CDS record is a better idea than just re-using DS.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Tue, 23 Apr 2013 14:37:29 -0400

On Apr 23, 2013, at 12:39, Paul Wouters wrote:

> I get it, you don't like the concept.

No, that's not true.

I see great utility in placing whatever is needed to describe the desired DS set state into a record to avoid having to transfer the data in any other format.

I fear that specifying a single in-band signaling mechanism could wind up tying a potentially valuable means of ferrying data to a particular use case, preventing a more general solution from moving into use.

If I didn't like concept, I wouldn't have been thinking about it and how close it is to begin useful.

What I feel I am reading in this thread is that some folks are already wedded to the current document and are unwilling to alter it for greater applicability.

Alarming to me is the thought that changing the basic validation algorithm to require a particular data set be signed with a particular key (role) would be something "simple."

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 23 Apr 2013 15:33:40 -0400

> Except that this thread has brought out many problems in the -01 draft that will likely result in changes that will make CDS special, not just like other records. At that point, you will have to de…

The first rule of protocol extensions is "avoid harm" to existing systems. 
Reusing DS at child side of delegation is likely to cause harm. 
In order to signal TA changes in-band thus has to be done either using new RRtype or only DNSKEY records. 

From a regular validator perspective CDS is a normal record, that is signed by a key that is in the DNSKEY RRset thus 
it validates like any any other record. 

A system that consume CDS records as a matter of Trust Anchor Maintenance require special rules before using the records content 
to update trust anchors these rules are likely to apply to any other mechanism used in-band. 
Mandatory Rules are: 
	- signed by one of current trust anchor(s)
	- applying new trust anchor(s) will not break chain of trust 
	- absence of CDS implies NO change in Trust Anchor 

Optional Rules: 
	- accept after delay similar to RFC5011 
	- accept only if DNSKEY contains all keys referred to in the CDS 
	- accept only if DS algorithms are "acceptable"
	- accept if there is a <push action> by "child" 

If you agree with the mandatory rules and a subset of the optional rules then you agree with the basic premise of the next version of the
draft that will be much clearer on what is Required and what is Optional.

	Olafur

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Apr 2013 13:40:57 -0700

FWIW, I agree with Ed's points below (some of which I have expressed 
previously).

Doug

On 04/23/2013 11:37 AM, Edward Lewis wrote:
> I see great utility in placing whatever is needed to describe the
> desired DS set state into a record to avoid having to transfer the data
> in any other format.
>
> I fear that specifying a single in-band signaling mechanism could wind
> up tying a potentially valuable means of ferrying data to a particular
> use case, preventing a more general solution from moving into use.
>
> What I feel I am reading in this thread is that some folks are already
> wedded to the current document and are unwilling to alter it for greater
> applicability.
>
> Alarming to me is the thought that changing the basic validation
> algorithm to require a particular data set be signed with a particular
> key (role) would be something "simple."
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 13:50:52 -0700

>     [] Nope, they all live on the same filesystem. If someone gets one, they have the other.

That's a very good addition; thank you.
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 13:53:21 -0700

Edward Lewis <[email-masked]> writes:

> I firmly believe that a validator (as described in 4033-4035) should
> have to be altered for the CDS proposal.

I don't think so at all.  Validators will still provide you with a
"valid" answer for the CDS record no matter which key is used to sign
the RRSIG for it.  That's all well and good already.

It's the (non-existent) application that will need the special rules.
It will have to do additional checks beyond ensure the record is simply
"valid".  It'll have to check which key was used to sign it.

And to say that we don't have that elsewhere and this is new isn't
correct either.  5011 has a number of similar semantics.  Consider the
revoke bit for the simplest and closest to this case.
-- 
Wes Hardaker
Parsons

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Apr 2013 13:59:16 -0700

> "valid".  It'll have to check which key was used to sign it.

... thus creating a support problem when the customer checks their CDS 
record, sees that it is "valid," and then doesn't understand why the 
parent won't accept it.

IMO both signers AND validators would have to be (should be) updated 
after this draft. Signers should not sign a CDS record with a non-SEP 
key, validators shouldn't accept those signatures if they are sent.

> revoke bit for the simplest and closest to this case.

Perhaps you could elaborate? It's not clear to me how that case applies 
in the child -> parent signalling direction.

Doug

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 14:02:36 -0700

Edward Lewis <[email-masked]> writes:

> Ultimately, I'm still uncomfortable with anything that does not use
> the out-of-band mechanism.  At the start of this thread was the
> question of "what if the secrecy of the KSK private key is lost? How
> do you go forward?"

So, you have the following radio buttons in front of you now:

- [ ] Write up your solution to the problem (aka, "show me the draft").
      I'd really like to see it (truly! I love options!  See!  Radio buttons!)

- Realize that CDS is likely to go forward because a lot of people like it and:

  - [ ] choose to ignore it because it doesn't fit your desires

  - [ ] offer concrete suggestions to change it so it does fit your
        needs (without removing the features that everyone else keeps saying
        they want (in-band acceptance))

- Try and stop CDS from going forward by:

  - [ ] Objecting up to WG last call
  - [ ] Objecting up till IETF last call
  - [ ] Objecting and then filling an IESG appeal before publication
  - [ ] Objecting and then pushing the appeal as far you can make it go
        and stomp your feet really loudly on the ietf@ mailing list.

So, unless you're in the last two camps, I probably don't have much more
to say on the subject because persuading you likely won't happen if
you're anywhere near the last 4.  Objecting to the notion without
offering fixes is like saying "I don't want soup to exist because
watching people eat it might make me want it in the future".

I very much understand that you don't want to use the technology.  The
solution there is still simple: offer a fix (or replacement suggestion)
to make it what you want, or don't use it!

Which box are you picking?

[please don't be the last one; please don't be the last one]
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 14:12:07 -0700

Edward Lewis <[email-masked]> writes:

> wedded to the current document and are unwilling to alter it for
> greater applicability.

No one has given alternative suggestions yet, so I fail to see how
you're assuming that everyone is wedded to the current one.  There is
only one proposed solution at this point.

[now...  the number of times something has been published in the past
that I'd have preferred to have the idea in my head published instead
but failed to get it out into a draft in time can be counted, hopefully,
on the legs of a centipede]
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 14:20:40 -0700

> record, sees that it is "valid," and then doesn't understand why the

Yes, but a CDS management tool wouldn't.  It's a specific use case.  The
above is like saying "my MX record validates with DNSSEC so it must be
valid", even though the label doesn't point to a real name.  It is not
the job of a validator to judge how the data itself will be used and
guess at any additional constraints that may be placed on it.  A CDS
record, just like an MX record, can be valid but not usable.

[and don't get me started on CNAME breakage in the wild]

> Perhaps you could elaborate? It's not clear to me how that case
> applies in the child -> parent signalling direction.

A revoke bit is only considered "actionable" (IE, revoke it from your
trust storage) if it was signed by the same key that produced the key
with the revoke bit turned on.  IE, you can have a "valid" key with the
revoke bit set, but you shouldn't actually act on it because it wasn't
signed by the key itself.  See RFC5011, section 2.1, last sentence for
the quick summary.

The key would still be considered valid by a validator but you shouldn't
act on the knowledge of the data in the key.
-- 
Wes Hardaker
Parsons

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Apr 2013 15:17:18 -0700

On 04/23/2013 02:20 PM, Wes Hardaker wrote:
> Yes, but a CDS management tool wouldn't.

Yeah, I get that. What I'm saying is, that's the problem.

> It's a specific use case.  The
> valid", even though the label doesn't point to a real name.

No, the cases you describe bear only a surface similarity (they both 
have RRSIGs). Whereas given that CDS is a record specifically designed 
to signal something to the parent _about DNSSEC_, the fact that (from 
the customer's perspective) the DNSSEC is valid would cause confusion as 
to why the parent won't accept it.

I realize that you and I understand the fine distinction you are 
attempting to make, my point is that customers won't.

> It is not

I would argue that as a matter of protocol clarity it shouldn't be 
possible for a signer to create a RRSIG that the intended consumer of 
that signature will discard as ... inappropriate(?) in spite of the fact 
that it validates just fine. But from the standpoint of having been in 
the registrar business in the past, I would not want to have to explain 
this problem to a customer (not to mention the revenue-destroying nature 
of any customer support call in the first place).

> [and don't get me started on CNAME breakage in the wild]

https://dougbarton.us/DNS/MX.html  :)

> act on the knowledge of the data in the key.

Sorry, I don't regard that situation as equivalent at all. I understand 
your reasoning, I just don't agree with it.

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Apr 2013 15:26:45 -0700

On 04/23/2013 02:02 PM, Wes Hardaker wrote:
> Objecting to the notion without

Wes, that's not only not true, it's at best inflammatory, and IMO ad 
hominem.

As I pointed out in previous posts (where I was loudly shouted down) 
there is a rather large opportunity cost to creating something that's 
sort of good, but not likely to be deployed due to fundamental flaws. 
Arguably there are several opportunity costs involved, but the most 
important may be that by the protocol wonks claiming to have solved the 
problem, but the RRR community not deploying the solution because it 
doesn't meet their needs, we risk a repeat of the same situation we have 
had in the past where both sides stand in their respective corners 
pointing fingers and calling each other names.

Completely ignore me and my registry/registrar experience if you like. 
Ed is coming from the perspective of one of the largest registries in 
the world (read, the intended audience for this draft[1]), and telling 
you that there are problems with it. It might be worth a listen.

Doug

[1] I realize that non-TLD parents can also use this mechanism, but that 
use case is in the margins relative to the utility that it would have at 
the TLD level.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 16:55:44 -0700

> Wes, that's not only not true, it's at best inflammatory, and IMO ad

Well, I'll happily retract it then.  It certainly wasn't meant in a
negative way.  I have an amazing amount of respect for Ed as his
arguments are always well thought out and well stated.  The only
argument I have against Ed in this particular discussion is that the
resulting solution will be harmful to him since he can simply "not use
it".

-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 17:03:52 -0700

Doug Barton <[email-masked]> writes:

> Sorry, I don't regard that situation as equivalent at all. I
> understand your reasoning, I just don't agree with it.

And that's why we probably need to agree to disagree.  They're very
similar to me.  It's easy, using standard tools today, to create a RRSIG
on a DNSKEY with a revoke bit set that signals "something about DNSSEC"
to external parties that can't be used because it was signed with the
wrong key.  I'd been assuming you'd probably have a problem with this
too, since it meets the criteria you've been against with CDS as well.

Anyway...  I'm perfectly fine agreeing to disagree about this.  I do
think we are understanding each other and much more text won't help get
beyond the disagreement, which is not stemming from lack of
communication.
-- 
Wes Hardaker
Parsons

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Apr 2013 20:07:43 -0400

> resulting solution will be harmful to him since he can simply "not use

I confess that I haven't been following this discussion as closely as
I ought (every time I start to try to read the thread, I feel like the
thread gets longer).  But in the little I've managed to read, it
seemed to me that the points Ed was making were (1) that this is an
important additional move on the supposed insignificance of the SEP
bit, and that is worrisome and (2) if this mechanism were altered
slightly, then it could be more generic and therefore more useful.

Those both seem to me to be substantive and important points that
ought to give us pause about the existing proposal.  If I had a hope
of getting through Zeno's mail thread this week, I'd try to read it
all and respond.  Instead I'm just pointing out that a dismissal along
the lines of "just don't use it" seems to ignore at least part of the
point of reviewing things in the IETF.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 24 Apr 2013 13:36:39 +0200

Op 23-04-13 17:18, Edward Lewis schreef:
> 
> For zones that operate under a mandate of the ICANN-style shared 
> registry model, you can't bypass the registrar.

I think this is the essence of why previous attempts to automate
technical DNS maintenance were unsuccessful.
I actually think it's the ICANN-style translation of the RRR model
that is wrong and why we don't go forward.

Registrars were invented to distribute administrative load for the
registry, and create competition in financial and customer care.

Because we started to use that same channel for the technical
bootstrapping of a delegation by the absence of a technical channel to
do so, ICANN has translated that into it's agreement as not only
bootstrapping, but also maintenance of technical data.

It is my firm believe that a registrar's role is administrative, and
after the sale is done, the registrant controls the technical data.
I can see that registrars are happy with the ICANN mistake because
they can now control their customers by allowing or disallowing
transfer of technical data, but it breaks the technical DNS model if
registrars do this based on business rules rather than that it
technically has to work parent to child. But registrars couldn't care
less, as they are not responsible for any part of the technical
infrastructure. It's about power and money, not correctness.

Since I'm not a lawyer, nor have lot's of money or trademarks or both,
it's almost impossible to bring this to the ICANN agenda, and we are
all hostage of this situation.

- -- 
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: Tony Finch <[email-masked]>
Date: Thu, 25 Apr 2013 19:03:43 +0100

Paul Hoffman <[email-masked]> wrote:
>
> Except that this thread has brought out many problems in the -01 draft
> that will likely result in changes that will make CDS special, not just
> like other records. At that point, you will have to decide if having a
> CDS record is a better idea than just re-using DS.

Re-using DS simply won't work, because you can't specify which side of the
zone cut to query when the child and parent are on the same server.

>From the point of view of name servers and resolvers, CDS is not special.

It is slightly special for signers, and the parent update systems that
consumes CDS records need slightly special validators.

Tony.

---

From: P Vixie <[email-masked]>
Date: Thu, 25 Apr 2013 11:14:06 -0700

Note that this is rendezvous information for the management plane and has no protocol significance. A distinct name in the child like _cds._dnssec.@ could hold a DS record without confusion.

Similarly, the current DS RR should really have been placed at _ds.child label._dnssec.parentdomain to keep it unambiguously in the parent zone and away from the delegation name.

Is to late for the latter but not for the former.

Let's not burn a type code just to keep CDS separate.

---

From: Joe Abley <[email-masked]>
Date: Thu, 25 Apr 2013 15:19:05 -0400

> Let's not burn a type code just to keep CDS separate.

Note that the type code for CDS has already been assigned, see:

http://www.iana.org/assignments/dns-parameters/dns-parameters.xml

(it's 59)

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Apr 2013 15:50:44 +1000

In message <[email-masked]>, P Vixie wr
ites:
> 
> Note that this is rendezvous information for the management plane and has no 
> protocol significance. A distinct name in the child like _cds._dnssec.@ could
>  hold a DS record without confusion.

Which doesn't work if you have a DNAME at the zone apex.
 
> Similarly, the current DS RR should really have been placed at _ds.child labe
> l._dnssec.parentdomain to keep it unambiguously in the parent zone and away f
> rom the delegation name.
> 

If there is going to be zone scraping then the record must be at
the zone apex.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: P Vixie <[email-masked]>
Date: Thu, 25 Apr 2013 22:55:37 -0700

Mark's right.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Apr 2013 14:00:41 -0400

Another omnibus response to a few.  (Had to step away for a few days.)

>        they want (in-band acceptance))

I think that the above statement is indicative of what I see wrong in the IETF process.  Sorry that this is off-topic, but I feel the need to pick this out as something to look out for in the consideration of the proposal.

"A lot of people like it" - but that is not consensus.  And, I can't say that I even agree with "a lot" and "like it".  What is "a lot" when you consider that very, very few people have ever recorded a public opinion on this?  I haven't counted (to be fair) but I bet it is less than 25.  We had more than that in the DNSOP meeting in Orlando.  To go quickly to the point, there are a lot of people in the DNS industry that don't participate in the IETF, so "a lot" is kind of a weak bar.  As for "like it", this is a first draft and I'd say I like it because it has potential.  Olafur has a framework for going forward which is good.  As for an concrete alternative - if I'm not mistaken, this is a working group.  I have ideas, but because I time slice through life's issues, I don't want to fix my mind up with a solution that I'd fall in love with.

I have in the past offered up criteria for opening this up.  But I don't have a solution.  I'm trying to avoid having an opinion, because I don't think the problem is completely understood.  Sorry for this rant, took more time than I thought.

>        and stomp your feet really loudly on the ietf@ mailing list

Frankly, I really don't have even just the time to think about that much less launch a complaint.  If the IETF promotes a document, I let it go.  I honestly don't care that much about the process.  There are a lot of bad documents out there already, what's one more?  Well, in this case, if the proposal isn't general, you've added one more obstacle to a general solution.  I do care about engineering something useful, document quality is not what I'm going to bark about - just not enough time.

On Apr 23, 2013, at 20:07, Andrew Sullivan wrote:

> ... (1) that this is an

Exactly.

>  Instead I'm just pointing out that a dismissal along

Exactly.

(I guess this is more of +1 to Andrew's message.)

> that is wrong and why we don't go forward.

That's not a a helpful response to the problem.  Whether you are right or not, you can't wave a wand and see requirements go away.  No matter what one feels about a set of business rules, you have to deal with anything that others want to participate in.  I have a hard time seeing how a model that accounts for 100's of millions of domain registrations can be so flawed it can't work - especially when there are, what 250 million total domain registrations?  I"m just saying - you can't discount something that is so prevalent even if it is flawed.

> Mark's right.

Not so much as a reply to that but a reply to the alternate engineering solutions and a reason to keep an open mind.  If this were easily solved, it would have been in RFC 4034 and RFC 4035.  Recall that in 2002-2003 (when the work behind the RFCs happened) we did not have the experiences we have now.  And EPP had just started rolling out, etc....

Pretty much we need to have something in the CDS record at the apex of the zone.  And to make this work really well, we have to figure out how I'd get a DS record for an unpublished DNSKEY into a zone like .NL (Antoin's - well, not his personally) that wants keys to work on, not DS records.  To hark back to Wes, I don't have answer for that, I don't want to propose a solution - like, hey Antoin, you're wrong, use DS instead - that would prevent Antoin from operating under his model.  I can see having CDS be used to indicate what DNSKEY Antoin would have to pull - if the key is in the DNS.  And yes, there is a DS record in the root zone (as of last time I checked) that pointed to an un-published DNSKEY.  And it is not one I put there just to mess with Antoin's model. ;)

I'm looking forward to the next document on this, and we can continue working on it.  Problems are solvable, even more so when the problem statement is clear and agreed upon.  And - the problem statement might morph as we progress.

---

From: "Dickson, Brian" <[email-masked]>
Date: Mon, 29 Apr 2013 19:01:11 +0000

Ed Lewis wrote:
 And to make this work really well, we have to figure out how I'd get a DS record for an unpublished DNSKEY into a zone like .NL (Antoin's - well, not his personally) that wants keys to work on, not DS records.  To hark back to Wes, I don't have answer for that, I don't want to propose a solution - like, hey Antoin, you're wrong, use DS instead - that would prevent Antoin from operating under his model.  I can see having CDS be used to indicate what DNSKEY Antoin would have to pull - if the key is in the DNS.

Okay, here's an open question (as in, if anyone knows, please chime in):

Is it possible/feasible/easy, to use DNSKEYs as public/private crypto tools' keys, generally?

E.g. If I have a public key (from a DNSKEY), say for my zone's parent-zone's ZSK, could I encrypt something (like a public DNSKEY value, which has not been published), and have the parent-zone's operator decrypt it (with their private key(s), either offline, online, or using an HSM which performs decryption without exposing the private keys)? This would avoid the act of publishing the DNSKEY, while still having the general mechanism of using DNS to publish CDS data. The DNSKEY is transferrable only to the parent, presuming no leakage of private keys on the parent's side, so the DNSKEY remains "unpublished", yet Antoin's model should still work (albeit with the addition of "encrypt" to the web-form).

If so, then I think this may be a feasible solution:

Have support for encrypted DNSKEY data, with fields indicating signer name (parent zone apex), key tag and algorithm.

NB – the parent's DNSKEY used for encrypting the child's DNSKEY, might possibly be used ONLY for encrypting/decrypting CDS data, I.e. be yet another member of the DNSKEY set, but be neither a ZSK nor a KSK. Maybe we could have another bit assigned to signal this particular use/purpose?

Thoughts?

Brian