On 1/9/2018 2:35 AM, Jakob Schlyter wrote:
On 2018-01-09 at 01:33, David Conrad wrote:
Mike,
On January 7, 2018 at 12:53:15 PM, Michael StJohns (msj@nthpermutation.com<mailto:msj@nthpermutation.com>) wrote:
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.
As currently operationally practiced, I believe my statement is correct.
That's a different statement than "we cannot use RFC5011..."
Your statement is correct.
Adding has an emergency rollover key (as described by Mike) has been considered several times over the years, but has been rejected every time due to how the primary key is protected and maintained. No failure scenario has been identified where it wouldn't be possible to recover from a failure and still maintain public transparency. An emergency rollover key does not help us in the current design nor does it make the current key rollover easier.
Forgive me for saying this, but the above is either a failure of will or a failure of imagination. Try this on for size: 1) Have cheap HSMs (e.g. smart cards) that can generate EC or RSA key pairs. One for each shard holder. 2) Write an applet that can decrypt something encrypted under a public key, can generate a public key, and can certify that the public key is associated with the specific smart card and that there's a PIN known only to the card holder. 3) Send all of the smart card public keys to the central location, 4) Send all of the smart cards to a central location wrapped in tamper bags. 5) Generate an AES key (for key wrapping). 6) Generate a new KSK key pair and export the public key, and export the private key under the key wrapping key. Delete it from the HSM at this point. 7) Split (5) into N of K shares using shamir. Encrypt each share using the public key from a different smart card. Print out the encrypted shares and distribute them widely. Delete the AES key from the HSM. Make N greater than the normal KSK signing threshold ideally .5 * K + 1. 8) Pseudo-randomly send the smart cards to each of the share holders mainly ensuring that none of them get their own cards. Each entity is responsible for protecting the card using two man controls - e.g. dual signatures on a safe deposit box, dual locked safe... 9) Verify that all the cards are in place and that the verification seals are intact. 10) Add the new KSK to the DNSKey RRSet The key idea here is that you don't have to protect each shard to the level you have to protect the combined key and you use the difficulty of stealing and using the key cards (note that the people in (8) don't have the PINs for the cards they hold) to decrypt the shares as a security enhancement. You have the card holders check the tamper indications once a month and sign off or some other form. An attacker has to get surreptitious access to N cards to be able to reform the wrapping key and decrypt the KSK. And the price for breaking into most of the smart cards is pretty hefty. The above is off the top of my head, but something like the above is a good start. Another possibility for RSA based signatures is https://link.springer.com/chapter/10.1007/3-540-57220-1_47 - I built a DNSKEY signer using this scheme - the private key is never combined, the signing shards may be publicly combined to get a valid signature. Nice thing about this approach is that once the key is generated, there's no need for anyone to show up at a central location for signing ceremonies.
No failure scenario has been identified where it wouldn't be possible to recover from a failure and still maintain public transparency.
I can't parse this. Removing the double negative it reads - I think - "For all failure scenarios that have been identified it is possible to recover from a failure and still maintain public transparency"? If you mean that all failure scenarios you've consider involve a manual restart to the process with new roots being manually placed in 100s of 1000s of devices you're probably right - that's pretty transparent. On the other hand, revoking an existing key without warning based on a compromise and moving over to another KSK signing key that's already in the trust anchor set is also pretty transparent - 100s of 1000s of devices will see the revocation. Later, Mike
jakob