On Fri, Jan 5, 2018 at 13:42 David Conrad <david.conrad@icann.org> wrote:
Doug,
On January 4, 2018 at 11:50:02 PM, Doug Barton (dougb@dougbarton.email) wrote:
Since a little before September when the 8145 data started rolling in all I've heard discussed is the risk to the deployed base if we do the roll and their stuff breaks. But there is another, arguably greater risk that is not being discussed, what happens if we get ourselves into a position where we are forced to do an emergency roll? (The common scenarios for that are key compromise, which is very unlikely but not impossible, and alg failure.)
If they key gets lost or compromised, my understanding is that we cannot use RFC 5011 to do the roll and must fall back to doing an out-of-band key rollover. We aren’t really exercising this under this iteration of the community defined KSK rollover plan.
Um. No. In fact, at this point you’re closer to being able to use 5011 as I designed it than ever before. I.e., you have two trust Anchors. If you want to be able to support key compromise and emergency replacement the next step is to add anchor C . The step after that is to revoke the current (old/original) trust anchorA. Keep C’s private key off line and in threshold pieces. Sign the DNSKEY RRSet with B. Later, Mike There are only two conditions that can be true at this point:
[…] If #1 is true we should do the roll ASAP […] If #2 is true we should do the roll ASAP […]
As I’ve noted previously, this would appear to argue that SAC-063 rec#3 should not have been made and that the amount of “breakage” is irrelevant. It would be nice if SSAC were to weigh in on this.
Regards,
-drc
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover