[ksk-change] Monolithism considered harmful...

[Michael StJohns]

Hi -

I'm noticing some issues with terminology that are tending to make 
discussion about the topic difficult.  For example " rollover" is 
actually the monolithic combination of a number of discrete actions.  
Let me suggest we try hard to talk about the discrete actions rather 
than "rollover" as it will make our life a bit easier in figuring out 
timing, resources and plans.

Here's my break down.  This assumes that we eventually get to a steady 
state of at least two trust anchors; that 5011 is used; and that the 
other mechanisms have sufficient assurances to them that providing them 
does not adversely affect the security model for DNSSEC.

Note that nowhere below discusses the time lines necessary for the 
discrete actions due to the current root signing processes (eg 
scheduling and travel time).


Trust anchor actions (from zone owner point of view):
      add trust anchor
          generate a key pair
          publish via  5011
              format the trust point DNSKEY RRSet
              sign the trust point DNSKEY RRSet with an existing trust 
anchor private key
              publish the signed DNSKEY RRSet via DNS for twice the add 
hold down period
          publish via ICANN web page
              format the XML trust anchor record
              update the web page
              publicize the update (for those doing manual updates)
          publish via software vendors
              sign the new trust anchor set with an as yet to be 
determined ICANN credential
              send trust anchor set to vendors
              publicize the update and participating vendors
              publicize the update and participating vendors
              publicize the update and participating vendors
              publicize the update and participating vendors
          return to normal signing policies (e.g. 1 key signs DNSKEY 
RRSet, stand by key(s) present or not present) after a
                minimum of twice the add hold down time; additional time 
may be needed to allow keys to propogate through
                vendor and manual processes.

    revoke trust anchor
          set revoke bit on key to be revoked
          format the trust point DNSKEY RRSet
          sign the trust point DNSKEY RRSet with both a still valid 
trust anchor key and the private key being revoked
          publish the signed DNSKEY RRSet via DNS for twice the remove 
hold down period or longer.
          update the ICANN web page list of trust anchors
          update the signed trust anchor set for vendors
          send the updated signed trust anchor set to the vendors
          publicize the revocation [[ level of effort for this action 
depends on whether revocation was due to compromise or
                 routine supercession actions]]


    supercede a key [ two stage]
         add a trust anchor
         wait for completion of add
         revoke an old trust anchor
         return to normal signing procedures after twice the removal time

    emergency revocation without immediate supercession (assumes 2 or 
more keys, of which at least N-1 keys are not compromised)
         [[ Same actions as "revoke trust anchor"]]

[[ In the model below, for non emergency supercessions, the publish to 
the icann web page and publish to the vendor channel can be moved
ahead of 5011 in the time line and a delay imposed between. However, the 
semantics which describe the TA (icann xml, signed TAs for
vendors) will need to be rich enough to describe future events as the 
revocation won't necessarily have occurred when the update data
reaches the end user; there's also the question of what happens if a 
compromise occurs between the ICANN/Vendor publish and the effective date]]

    supercede a key [ one stage ] aka
    emergency or non-emergency revocation with immediate supercession 
(assumes 1 compromised or superceded key and at
              least 1 non compromised key, can scale to more than 1 
compromised key)
         generate a key pair
         set revoke bit on key to be revoked
         publish via 5011
              format the trust point DNSKEY RRSet to include both 
revoked key and new public key
              sign the trust point DNSKEY RRSet with both the revoked 
key and a different valid trust anchor private key
              publish the signed DNSKEY RRSet via DNS for the greater of 
twice the hold down period or twice the removal period
         publish via the ICANN web page
              format the XML trust anchor object to add the new trust 
anchor and remove the old
              publish the new object on the ICANN web page
              publicize the change
         publish via the Vendor channel
              sign the revised trust anchor set
              send the signed set to the participating vendors
              have them publicize to their own customers (customers will 
have also seen the above announcement).
         return to normal signing procedures after the greater of twice 
the hold down period or twice the removal period; can be
                   extended to allow for more time for completion of web 
page and vendor channel updates.

   trust reboot [compromise]
         [[ publicize the compromise - may be deferred if impact 
assessment dictates]]
        generate new key pairs
         publish via the ICANN web page
              format the XML trust anchor object (containing only the 
new trust anchors)
              publish the new object on the ICANN web page
         publish via the vendor channel
              sign the revised trust anchor set (containing only the new 
trust anchors)
              send the signed set to the participating vendors
         wait 30 days
         publicize the compromise and updates
         wait 60 more days
         revoke all the compromised trust anchors via 5011
               root DNSKEY RRSet will include old trust anchors as well 
as new trust anchor and will be signed by new trust anchor as well as old.
         wait twice the remove hold down time
         resume normal signing procedures

   trust reboot [ routine ]
         generate new key pairs
         do 5011 add of the new trust anchors
         publish via the ICANN web page
              format the XML trust anchor object (containing old AND new 
trust anchors)
              publish the new object on the ICANN web page
         publish via the vendor channel
              sign the revised trust anchor set (containing old AND new 
trust anchors)
              send the signed set to the participating vendors
         publicize the compromise and updates
         wait 60 days at least
         revoke all the old trust anchors via 5011
         wait twice the remove hold down time
         resume normal signing procedures