<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1068573626;
mso-list-template-ids:-1287730618;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mike-<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you very much for this. As clearly one of those experts, I appreciate the time (and patience) you have taken in an attempt to educate me. I will need read through this a few times more to get the full effect but I think I get the overall logic and agree. For some things the devil IS in the details and cannot be explained in a one-liner. I particularly like the scheme described in (2). As we all know no system is perfect and it was with this in mind that we made sure that the system we use now for root ksk management was not cast in stone. We have thought about many improvements and implemented some minor ones suggested by the TCRs but an in depth view like yours is, well, refreshing. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Rick<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] <b>On Behalf Of </b>Michael StJohns<br><b>Sent:</b> Thursday, October 02, 2014 9:49 AM<br><b>To:</b> ksk-rollover@icann.org<br><b>Subject:</b> Re: [ksk-change] Keeping two KSK keys long term<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On 10/1/2014 11:49 PM, Richard Lamb wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><o:p> </o:p></pre><pre>Security level/controls for all key material must be equal or better.<o:p></o:p></pre><pre>That's why we don't have a second backup key since the storage of the<o:p></o:p></pre><pre>additional key would incur the high costs of ensuring it to was equally<o:p></o:p></pre><pre>secured in a separate facility (5-6 tiers etc...). But of course I am just<o:p></o:p></pre><pre>parroting what I learned from the experts on the cc line. If the community<o:p></o:p></pre><pre>says they don't care, well.....<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>-Rick<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><br>Hi Rick - <br><br>This one is going to be long winded and slightly pedantic - details are important. It's a general follow up to your email and to the others on this thread.<br><br>"Security level/controls for all key material must be equal or better." As stated, this has a number of issues. I'm going to restate this in a slightly different way: "Cryptographic material (keys, hardware security modules, crypto ignition keys, backup material) must be protected in a manner to provide at least the minimum desired level of assurance for the system. This does not mean that all cryptographic material must be protected equally, but that, taken as a whole, the protections applied to each component enable at least that minimum level of assurance for the system as a whole."<br><br><br>There are two items of assurance that you have to address, and each has its own set of concerns: 1) Sufficient cryptographic material has to be available to complete a desired cryptographic operation when necessary; (e.g. assurance against loss); 2) Sufficient protections need to be in place to prevent the completion of the cryptographic operation unless the policy requirements are met (assurance against compromise - includes both using the HSM out of policy, and extracting key material from within any policy wrapper).<br><br><br>(1) is generally addressed through redundancy and backups. You provide sufficient copies of the material to reduce the chance of a complete loss of the material is less than your assurance threshold. That can be done through split key (threshold) paper systems, smart cards, backup HSMs etc. The hard part with (1) is preventing (1) from causing issues with (2). But that's not actually hard if you look at the math rather than the hardware. <br><br>There used to be a device called a STU III - secure telephone unit. It was certified to encrypt voice up to the US Top Secret level. The interesting thing about the device was that it was unclassified when separated from its crypto ignition key. The STU III and the CIK each had part of the key material necessary to enable secure communications and policy required nothing more than the operator carry the CIK with him when the STU III wasn't in use to make both pieces unclassified. (This by the way drove the crypto custodians bonkers as this was *something new*). <br><br>The point is that if its impossible to get enough of the parts of the private key together without someone finding out about it, then the protections on each share of the key do not need to be at the same level as the key when its assembled. Using more of the math based approaches (in addition to hardware based approaches) for key protection should be considered the next go round.<br><br>(2) Is slightly more interesting. One of the discussion points on an earlier thread was the issue of getting N people to show up every so often to do a key ceremony. Looking at this, I understand this is good theater, but maybe not a sustainable operational model. How about instead: <o:p></o:p></p><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Each partial signer has a smart card (miniHSM?) with a specific key pair where the public key is known to the HSM. <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'> ICANN publishes (a week before the due date) a draft "object to be signed" - basically the new DNSKEY RRSet with all the right times and keys.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>Each partial signer "signs" the object to be signed using its own key pair and publishes the result to a publicly available webpage.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>ICANN, on the date of the signing ceremony:<o:p></o:p></li><ul type=circle><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>Verifies each signature from (3) external to the HSM and <o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>randomly selects K (where K is the minimum necessary signers) step (3) signed objects<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>Feeds the step (3) signed objects into the HSM where each is independently verified<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1'>When the HSM verifies K signed objects, it produces its own signature over the "object to be signed" and emits it.<o:p></o:p></li></ul><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1'>ICANN publishes the new signed DNSKEY RRSet.<o:p></o:p></li></ol><p class=MsoNormal style='margin-bottom:12.0pt'>This requires a change to the policy engine of the HSM obviously (e.g. PKCS11 isn't sufficient), but means that you can securely sign the root with remote actions in a publicly verifiable manner. It also means that you can increase the number of possible partial signers (with the resultant broader community participation) with minimal cost. Note that you still need some sort of ceremony to generate new keys.<br><br>An even more comprehensive change would be something like "Practical Threshold Signatures, Victor Shoup (<a href="mailto:sho@zurich.ibm.com">sho@zurich.ibm.com</a>), IBM Research Paper RZ3121, 4/30/99" where there is no central HSM, but where the partial signatures are done remotely and then assembled into a full signature by anyone who wanted to do so. I built DNSSEC signing code for this that works quite nicely That paper applies to RSA, but there are similar (not equivalent) schemes for EC.<br><br>There are a number of ways to enhance this using cryptographic techniques combined with hardware policy enforcement to minimize the chance of even one of the remote private keys being compromised (e.g. 2of2 or 2of3 secret sharing of the partial signer's private key with reassembly only for signing). <br><br>I said earlier that it's a numbers game and if - mathematically - you need N pieces to do the crypto operation, preventing an attacker from getting N-1 is a win. If there are K total elements, then you also need to ensure that no more than K-N elements are irrevocably lost. <br><br>Going back to the original comment that not all cryptographic material requires the same level of protection. Consider a two key trust anchor set for the root. One key is used fairly regularly, the second is the back up. 3 parts of the backup key pair resides in a PCIe HSM card locked in a safe deposit box near the ICANN facility, three parts on a second PCIe HSM at the back up facility, part of the key pair is on a smart card in Paris, part on a smart card in London and part on a smart card in ??. Also, none of those smart cards actually give you credentials to enable the HSM - those are held by other people. The backup system requires a 4 of 6 key recovery (an HSM plus one smart card). The cost for the PCIe HSMs is ~$5k, but even if they're stolen they're useless without one of the 3 smart cards, and without the operational credentials for the HSM. The smart cards on the other hand are mathematically useless without the data in the HSM. The cost for doing the separation of operational key from backup key becomes the cost of two safe deposit boxes, 2 PCIe HSMs and 3 smart cards being carried around in wallets. (Or maybe 6 - the 4 of 6 for HSM A may not be the same split of 4 of 6 keys for HSM B).<br><br>Mike<br><br><o:p></o:p></p></div></body></html>