draft-ihren-dnsop-interim-signed-root-00.txt

["Loomis, Rip" <GILBERT.R.LOOMIS@saic.com>]

Johan--
I started out to write comments on specific technical issues
or possible clarifications of the draft, but I discovered that
I had more fundamental questions to ask first.  [KSK=Key Signing
Key, and ZSK=Zone Signing Key in my notes below.]

=-=-=-=

Right now, to my knowledge, there is a single hidden master
that all the roots obtain the zone from (AXFR+TSIG); it is
also possible to download the root zone file with a detached
signature.  In both cases, there are fallback methods that
may require a human-in-the-loop but which minimize the "single
point of failure" issue.

In the scheme you describe in the draft, you state that you
are trying to eliminate single points of failure, but I'm not
clear that the proposed scheme makes things better.  For one
thing, it appears that the proposed usage of the RIRs with respect
to ZSKs doesn't really add anything to the security/reliability
of the overall system.  You state,
  "The RIRs should all perform the task of generating individual
   key-signing keys and signing the "keyset".  However, only one
   keyset should be included in the signed zone file."

I assume the former requirement is to ensure that all the RIRs
are familiar with the procedure.  However, what's the benefit
here?  If, in the final operational configuration, the root zone
KSK would be expected to have a long lifetime (on the order of
13 - 36 months based on various discussions), then it's probably
impossible to have multiple organizations that can generate/field
a KSK *and* remember how to do it the next time it's their "turn"
(I'm assuming you want to round-robin between RIRs.)  This also
brings up potential issues with different RIRs using different
methods to protect the all-important private portion of the KSK
public/private pair.

In the end, I'm not convinced that there needs to be more than
one organization involved in the KSK generation/fielding.  It
does need to be done well, and I admire your intent to remove
single points of failure--but there's also such a thing as "learn
to do something well, and then keep doing it well" instead of
each RIR re-learning the process every several years.  I think
there only needs to be one entity generating/fielding/managing
protecting KSKs--there need to be many distribution media to
remove the single point of failure issue, and there probably
does need to be some off-site secure backup of the KSK pair.
(If that one entity gets physically destroyed and there *is*
no backup of the KSK pair, the process of generating a new KSK
pair is actually not that challenging but the recovery method
to get the new trusted-key deployed would be painful.)

If your scheme is simplified to a single point of origin (and
multiple distribution channels) for the KSK, then it might
actually work.  I would strongly prefer to avoid even a pretense
of "online while-you-wait" re-signing of the root zone with
new ZSKs, though.  As you state in the draft,
   "every change [to the root zone] is preceded by an administrative
    process that takes several days."
There's no reason why that very deliberate process can't also
include the action of signing the zone with the current ZSK(s)
off-line prior to placing the zone on the hidden master.
I'm not sure what the "signing primaries" bring to the mix,
other than another level of complexity *and* online while-you-wait
signing.  Neither of those seems to be a Good Thing to me.
If the goal is to run a signed root hierarchy in parallel with
the "real" one, then a "signing primary" might make sense, but
I think there already is such a testbed--and the root zone for
such a testbed would differ from the "real" root zone anyway.

I may have missed something in the focus of your draft--I do
strongly (if it wasn't obvious) support getting the root signed,
but I'm not sure that this is the right way to do the interim
scheme.  I'm writing operational procedures for a TLD to begin
its signing (for testing, obviously) and I had not contemplated
anything so complex.  Please let me know if there are other
behind-the-scenes reasons why your scheme is set up this way,
but as it stands I would recommend against it.

Please let me know if there's anything unclear in my rambling
above, or any other questions I can help answer.

Very Respectfully,
--
Rip Loomis
Senior Systems Security Engineer
SAIC Secure Business Solutions Group 

#----------------------------------------------------------------------
# To unsubscripbe, send a message to <dnsop-request@cafax.se>.