[ksk-rollover] [Ext] Re: Starting discussion on acceptable criteria for proceeding with the root KSK roll

[Michael StJohns]

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 at nthpermutation.com<mailto:msj at 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
>