Subject: [dnsop] More comments on key rollover req. draft -01

From: "Loomis, Rip" <[email-masked]>
Date: Fri, 19 Nov 2004 13:09:57 -0500

First:
I would like to recommend, as Sam Weiler and Miek Gieben
already did, that this draft be dropped by the WG.  I
believe that the concept of a requirements draft is useful
but that this particular one is so flawed that it needs
to go away entirely rather than being "fixed".

Chairs, there has been no on-list dissent with dropping this
as a WG item...so if anyone *does* dissent then please make
your feelings known...

Second:
As promised, I'm following up on my question/comments during
the DC meeting of the WG.  I think my comments are reasonable
enough that I'm simply sending them to the list rather
than only to the editors.  Comments on my comments are
welcome, of course.

Summary of my big issues with the draft, for consideration
by the current authors and/or whoever wants to undertake
a rewrite:
 - Although the draft doesn't clearly state it anywhere at the
   top, the draft is actually specifying in-band key rollover
   using DNS methods (based on the first part of section 4:
       Every exchanged message MUST be authenticated and
       the authentication tool MUST be a DNSSEC tool such
       as TSIG [6], SIG(0) [5] or DNSSEC request with
       verifiable SIG records. )
   Of the total set of "methods for automated key rollover",
   restricting to only those that meet the above condition
   seems to be a major decision point--which I don't agree
   with and for which the logic probably needs to be
   specifically discussed.  There's no discussion of the fact
   that out-of-band (not over DNS [0]) automated (or semi-
   automated) key rollover is realistic.

 - No mention of the fact that automated key rollover
   implies that if the child's authenticator (whatever it is)
   is compromised then a "bad guy" can commandeer the zone
   entirely, making it nearly impossible for the real child
   zone admins to regain control of the DS set--even if the
   actual private KSK/SEPK for the zone was not affected/compromised.

   If the actual private KSK/SEPK for the zone *was* compromised,
   then accepting SIGs generated by that KSK as the authenticator
   means that the child may have no valid method of recovering
   from the compromise (the bad guy can roll the KSK to a new
   one automatically, and then the actual child admins have no
   basis for the parent to trust them and not the bad guy).

 - No discussion of the fact that in-band methods like this imply
   that the parent zone's authoritative servers would AFAICT need
   to allow dynamic update requests, which has significant security
   implications.  (If the goal is to allow automated key rollover
   using DNSSEC for authentication, then either the draft is specifying
   the use of secure dynamic update of the DS records, or the draft
   is postulating addition of new functionality to DNSSEC that
   essentially would replicate secure dynamic update--unless I've
   missed something).

   In an off-list discussion, someone else postulated the use of
   an intermediate server that would accept the dynamic update
   requests and group/store them for insertion into the parent
   zone during the next regular "maintenance period".  I think that
   this is probably the most reasonable way to do a completely
   in-band DS/DNSKEY rollover, but I'll let others flesh that out
   if they so choose--I'm more focused on the OOB automated or
   semi-automated updates for a variety of reasons (mostly because
   I need them *now*.

 - More discussion/details on the actual process envisioned would
   be very useful in figuring out whether these "requirements" are
   both a complete and correct list.  I realize that this detail
   doesn't belong in the requirements draft itself, but such detail
   could be put somewhere else or sent to the WG list and I think
   it would be helpful.  Even a notional implementation, in my
   experience, can help to identify whether a set of requirements
   is coherent and cohesive.

The even shorter summary:
Basically, the "security considerations" section needs to be about
a page and a half (or more), instead of a single paragraph.

  --Rip

[0]  There was an off-list discussion on terminology for "in band"
     and "out of band".  I'm using "out of band" here to reflect
     the use of non-DNS protocols to communicate DS/DNSKEY
     information, probably HTTPS or SMIME/SMTP [1]  --but since
     both of those will likely depend on DNS resolution I am also
     assuming that the DNS tree is available and signed.  Since
     that assumption may not always be correct, any parent zone
     that is signed probably needs to have a truly OOB method for
     child zones to send their information--snail mail, fax, voice,
     etc.  Use of this method would only be an absolute last resort,
     of course...but this document probably should note that such
     a fall-back method is still needed.

[1]  My assumed initial condition is that the child zone admin
     already has an acceptable way to authenticate to the parent zone
     admin--whether it's a credit card used to pay for the zone, or
     some organizational link, or what have you.  If so, then let's
     figure out how to use it as the first step and then move to
     a better situation where the parent-child trust relationship
     has a stronger authenticator for the child.
     Notional things that would work:
       - Cut and paste new DS set into web-based form, with
         authentication based on client-side X.509 cert or HTTP Basic
         Auth, with SSL on the parent side.  This seems reasonable to
         me since it matches the way I request changes in parent TLDs
         today (user -> registrar, allowing the registry -> registrar
         changes to take place behind the scenes over epp or what
         have you).  Automation of this at the parent seems reasonable,
         and the burden on the child does not appear severe.
       - Send DS set as PGP-signed (or X.509 client cert signed)
         e-mail.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html