Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

[Scott Schmit <[e-mail]>]

On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext:
> On Tue, 8 Mar 2011, Roy Arends wrote:
> >
> >    D.    Motivation for the new RRTYPE application?
> >
> >          To allow a copy of the DS RRset [RFC4034] to be published
> >          in the child zone, which is used to update the parent DS RRset.
> >          It is expected that this will allow the rollover of a key signing
> >          key to be automated.
> 
> Why not just use the child zone's SEP DNSKEY RRs for this purpose?

I'm inclined to agree with this, but even if it's decided that the
DNSKEY RRs aren't sufficient, why not just use DS on the client side? I
see that RFC 3658 forbids it, but I'm not sure I understand why.  We
don't have CNS in addition to NS, so why should DS be different? I can
understand that DS must be ignored by a client unless it's signed by the
parent, but if that check doesn't already exist, we're already in
trouble.

So, maybe they didn't think of the use case this draft is trying to
address and forbade it to keep the software implementations simpler? But
that could have been accomplished simply by saying that a DS on the
child side is ignored for validation purposes (it now becomes pointless
(but harmless) to include it, except as a way to securely send DS
records from the child to the parent).

Even if this language tweak were to be applied after the fact, I don't
think there is an interoperability problem.  There are 4 cases:

1) the parent has no DS, nor does the child -- the pre-DNSSEC case

2) the parent has no DS, but the child does -- the DS must be regarded
as fake and ignored by resolvers already, or we have problems.  (Even
with the new draft, the parent MUST NOT attempt to use the DS in the
child to seed anything -- it needs to be supplied by a secure
mechanism, and a child DS signed by an untrusted DNSKEY isn't it)

3) the parent has a DS, but the child doesn't -- the current DNSSEC case

4) the parent has a DS, and so does the child -- this is the new thing
that this draft is trying to enable to support KSK rollover.

I would argue that case 4 should be harmless, unless I've overlooked
something: either nothing is looking for this and should ignore it, or
the DS should be regarded as fake by older software and ignored by
resolvers (if it's not, the software already has a security hole --
simply DOS a zone with an unsigned parent by sending fake DS records
purportedly from the child), or the DS should look valid (because it
fits a chain of signatures) and possibly extra DNSKEYs match & are
regarded as valid.  But since the chain of signatures is valid, it's
still secure.

If people started writing zone signers to rely on this mechanism to
introduce new keys, I could see there being interoperability issues
(some resolvers would treat the domain as secure, and others wouldn't),
but since this is new behavior, this draft can (and should) explain that
this cannot be relied upon (and DNSKEYs should be used instead for this
purpose).  Alternatively, to keep implementations simple, state that
child DS RRs MUST NOT be used as part of authenticating RR contents, but
they are allowed to exist and be queried for (and I could almost imagine
that the only code this would affect is zone checker tools). The only
place where that would be a problem is for people who want to use this
mechanism, so that's motivation to update the checkers anyway.

I can understand the motivation of introducing a new RRTYPE to avoid
needing to alter existing MUST NOTs, but CDS just seems unnecessary.

Maybe there's another reason to forbid DS on the child side that I've
overlooked?

-- 
Scott Schmit