[ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)

David Conrad david.conrad at icann.org
Mon Sep 22 05:46:36 UTC 2014


On Sep 21, 2014, at 9:02 PM, Michael StJohns <msj at nthpermutation.com> wrote:
> *sigh*


>> Or do you believe we should revise the key handling policies and processes to roll _much_ more frequently?
> I'd suggest 1-2 years.  Or basically once every 4-8 times you do a ZSK replacement.

The current DPS has 5 years. On what analysis do you base your suggestion?

> I think you're underestimating by perhaps several orders of magnitude the cost of a "full trust reboot”.

Actually, not. I believe we have to be prepared for a "full trust reboot” _regardless of 5011 support_ and part of the exercise with the key change exercise we’re discussing/planning a workshop for is to ensure that preparation.

> If the end result of the discussion is already pre-disposed to be one of these results, 

As far as I am aware, nothing has been decided. The point of this mailing list (and the workshops) is to understand the issues more fully, expose assumptions, and establish community consensus in how to move forward.

> The comment about irrelevancy of the CA model is that none of these are universal global roots of trust.  They compete and mostly that causes really interesting interoperability problems.  Failure of one of them is not going to have the universal/broad impact that the failure of the single DNSSEC root of trust would have.

Which would seem to argue that one must be extremely careful, much more careful than CAs, if you have a single root of trust and not expose that trust to potential risk unnecessarily. You appear to be arguing that rolling the key every 1-2 years would not increase risk over rolling it less frequently. I do not agree.

> Going back to trust reboot - think about the timeline used for the original key creation and signing ceremonies.  Pretend a compromise happens "now".  How long until DNSSEC is back up using the trust reboot process?  Oh yeah - the compromise happened because the HSM you're using  was found to be insecure.  Ready,..... GO!

What is the difference in this scenario without 5011 and with 5011 if you assume a compromise of all keys?  Do you believe we do NOT need to be prepared for the latter?

You also seem to assume there will be universal deployment of 5011 and that everyone will allow 5011 to operate on their infrastructure.  Neither of these assumptions seem realistic to me.

> By the way, your attacker *is* using 5011.  Since he now has access to the trust anchor private key, he's using it to place new trust anchors for the BOA, Google and the IRS local resolvers by intercepting and replacing root zone queries.

_Exactly_ the reason I would see some folks choosing not to support 5011.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20140922/362ee4ad/signature-0001.asc>

More information about the ksk-rollover mailing list