<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
This got stuck in my outbound queue for a few days.<br>
<br>
On Saturday, September 20, 2014, David Conrad <<a
href="mailto:david.conrad@icann.org">david.conrad@icann.org</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Tomofumi,<br>
<br>
On Sep 19, 2014, at 11:46 AM, Tomofumi Okubo <<a
href="javascript:;" onclick="_e(event, 'cvml',
'tomofumi.okubo@gmail.com')">tomofumi.okubo@gmail.com</a>>
wrote:<br>
> The former is emergency roll and the latter is planned roll.<br>
><br>
> The rollover we are discussing now falls under the latter.<br>
<br>
Actually, I don’t think we’ve started the discussion on changing
the key as yet :).<br>
<br>
Is there a need to have a different set of policies/processes for
an emergency roll vs. a planned roll?<br>
<br>
Is a planned roll a proper subset of an emergency roll?</blockquote>
<div><br>
</div>
<div>Yes and no. If you're using 5011 as the model, and you have two
keys as trust anchors, and one associated private key is
compromised, then there really isn't a lot of difference in
proceedures. You revoke the compromised key, and start the process
of getting a new key accepted as a trust anchor. </div>
<div><br>
</div>
<div>The emergency thing shows up when all of your existing trust
anchor keys are compromised. And there really isn't a way to deal
with that contingency, planned or not. Basically, if A[public]
is your only root trust anchor and A[private] is compromised,
you're dead in the water. You can attempt to add new B[public]
keys to the trust anchor set using 5011, but there's a good chance
that your attacker is attempting to dothe same thing. If the
attacker revokes A[public] by setting the bit and signing the root
DNSKEY RRSet with that key, what probably happens is that ALL data
without subordinate trust anchors is considered invalid by
resolvers and rejected.<br>
<br>
5011 gave very specific guidance on what needed to go into the
root DNSKEY RRSet to avoid this case - but the current RRSet and
Trust Anchor set are missing the second KSK.<br>
</div>
<div><br>
</div>
<div>Mike </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
-drc<br>
<br>
</blockquote>
</body>
</html>