ceremonies in April, and managing things less critical and the KSK.
I was locating appropriate references for explaining Key signing ceremonies, and noticed the report of the safe problems at: https://www.theregister.co.uk/2020/02/13/iana_dnssec_ksk_delay/ https://www.icann.org/news/blog/root-key-signing-key-ceremony-postponed and then the schedule at: https://www.iana.org/dnssec/ceremonies in which April 23 is the next date. Will travel bans cause a problem? I kinda hope the travel bans are enforced. "Introduce HSM6E" Does this mean that a new HSM device will be added? I see RRSIG from keyid 20326 (current root) will expire 20200422000000. Maybe there is another RRSIG hidden away that I can't see? https://www.iana.org/dnssec/icann-dps.txt I am unclear from reading things over again how the ZSK gets to the ceremony. Is a new ZSK keypair generated during the KSK, or is it generated elsewhere and only the public part brought? But, I started re-reading things because I was looking for pointers to documents *less* secure practices for CA key management. That's poor wording. let me try again: Practices for lower value assets than the KSK. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Hi Michael, At 12:54 PM 04-04-2020, Michael Richardson wrote:
I was locating appropriate references for explaining Key signing ceremonies, and noticed the report of the safe problems at:
KSK Ceremony was held on February 15, 2020. There was an announcement at https://mm.icann.org/pipermail/root-dnssec-announce/2020/000125.html
and then the schedule at: https://www.iana.org/dnssec/ceremonies
in which April 23 is the next date. Will travel bans cause a problem? I kinda hope the travel bans are enforced.
I'll leave the above to PTI.
"Introduce HSM6E" Does this mean that a new HSM device will be added? I see RRSIG from keyid 20326 (current root) will expire 20200422000000. Maybe there is another RRSIG hidden away that I can't see?
The last SKR expires on July 7, 2020 at 00:00 (UTC).
https://www.iana.org/dnssec/icann-dps.txt I am unclear from reading things over again how the ZSK gets to the ceremony. Is a new ZSK keypair generated during the KSK, or is it generated elsewhere and only the public part brought?
Verisign generates a Key Signing Request. There is a sets of signed keys which are generated during a KSK Ceremony.
But, I started re-reading things because I was looking for pointers to documents *less* secure practices for CA key management. That's poor wording. let me try again: Practices for lower value assets than the KSK.
There may be some old documentation (it is around a decade ago) which might be of help to the alternatives which were considered. The requirements for the Root Zone are unique. I suggest assessing which of them you works for your case. Regards, S. Moonesamy
S Moonesamy <sm+icann@elandsys.com> wrote: >> But, I started re-reading things because I was looking for pointers to >> documents *less* secure practices for CA key management. That's poor >> wording. >> let me try again: Practices for lower value assets than the KSK. > There may be some old documentation (it is around a decade ago) which might > be of help to the alternatives which were considered. The requirements for > the Root Zone are unique. I suggest assessing which of them you works for > your case. My cases are varied and not "mine"; I wish to point my readers towards one or more survey articles that will point them in the right direction. At the least, will permit them to form their own order of magnitude cost estimates for different solutions. So I would love to have those pointers. I tried to follow "SAS 70 Root Key Ceremony", but SAS 70 is a different ISO 9000-type process, so it's a meta-process relating to auditing, not relating to Root Key Ceremony. But, a useful thing to apply to your Root Key Ceremony. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Michael Richardson <mcr+ietf@sandelman.ca> wrote: > I am unclear from reading things over again how the ZSK gets to the ceremony. > Is a new ZSK keypair generated during the KSK, or is it generated elsewhere > and only the public part brought? This is probably the wrong list to ask on. https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf says: 5.2.2. Private key (m-of-n) multi-person control Verisign has implemented technical and procedural mechanisms that require the participation of multiple trusted individuals to perform sensitive cryptographic operations. Verisign uses "Secret Sharing" to split the activation data needed to make use of a RZ ZSK private key into separate parts called "Secret Shares" which are held by trained and trusted individuals called "Shareholders." A threshold number of Secret Shares (m) out of the total number of Secret Shares created and distributed for a particular HSM (n) is required to activate a RZ ZSK private key stored on the module. The threshold number of shares needed to sign a root Zone File is 3. It should be noted that the number of shares distributed for disaster recovery tokens may be less than the number distributed for operational HSMs, while the threshold number of required shares remains the same. Secret Shares are protected in accordance with this DPS. --- I think that the HSM keeps the private key (RSA) encrypted. The key that is used to do this encryption (probably AES256) is the thing that is secret-split among the n-shareholders. I understand that m=3. It says "a particular HSM", so does this mean that the encryption key used to encrypt the private RSA key is different in different HSMs (at different locations), and a *different* m people are required to activate it? I would think that the different HSM would synchornize the encrypted copy of the private key, and thus the split secret would be the same n pieces. Of course, the key could be moved to another HSM by the initial m-of-n people, it could be *re*-encrypted to n' pieces and some other m' people required. The n and n' people could completely or partially overlap. {BTW: When I read the KSK ceremony script, at: https://data.iana.org/ksk-ceremony/40/20200216-KC40-Ceremony_Script_Annotate... I see that the KSR arrives on a smartcard.} It seems that the secrets which are split up are kept in the/a safe, using a safety deposit box, and it is further in a tamper resistant bag. The TCR retains the key to the safety deposit box. Am I correct that the secret split never leaves the room, so "m" TCRs can not actually reconstruct she key on their own? I'm unclear what kind of media the secret is stored on, but I understand it plugs straight into the HSM, not the control laptop. (BTW: I recognize that I'm reading KSK and ZSK documents at the same time) I was surprised at the lack of references in the dps documents to any theory about how this process was created. This is what I am looking for: a palette of ways to make key ceremonies for a variety of different threat levels. Still I learned something by actually watching the entire video (at 1.75x speed..) and reading the entire ceremony through. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Michael: IANA has emergency procedures that can be used to obtain the needed three shares. It is clear from the text that you quote, that emergency planning was considered fro the start. I assume that IANA will declare such an emergency in the next few days, and then generate the next KSK under those procedures. As I understand it, the auditor will be able to tell that the emergency procedure were properly followed. Russ
On Apr 4, 2020, at 9:39 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Signed PGP part
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
I am unclear from reading things over again how the ZSK gets to the ceremony. Is a new ZSK keypair generated during the KSK, or is it generated elsewhere and only the public part brought?
This is probably the wrong list to ask on.
https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf says:
5.2.2. Private key (m-of-n) multi-person control Verisign has implemented technical and procedural mechanisms that require the participation of multiple trusted individuals to perform sensitive cryptographic operations. Verisign uses "Secret Sharing" to split the activation data needed to make use of a RZ ZSK private key into separate parts called "Secret Shares" which are held by trained and trusted individuals called "Shareholders." A threshold number of Secret Shares (m) out of the total number of Secret Shares created and distributed for a particular HSM (n) is required to activate a RZ ZSK private key stored on the module. The threshold number of shares needed to sign a root Zone File is 3. It should be noted that the number of shares distributed for disaster recovery tokens may be less than the number distributed for operational HSMs, while the threshold number of required shares remains the same. Secret Shares are protected in accordance with this DPS.
---
I think that the HSM keeps the private key (RSA) encrypted. The key that is used to do this encryption (probably AES256) is the thing that is secret-split among the n-shareholders. I understand that m=3.
It says "a particular HSM", so does this mean that the encryption key used to encrypt the private RSA key is different in different HSMs (at different locations), and a *different* m people are required to activate it?
I would think that the different HSM would synchornize the encrypted copy of the private key, and thus the split secret would be the same n pieces. Of course, the key could be moved to another HSM by the initial m-of-n people, it could be *re*-encrypted to n' pieces and some other m' people required. The n and n' people could completely or partially overlap.
{BTW: When I read the KSK ceremony script, at: https://data.iana.org/ksk-ceremony/40/20200216-KC40-Ceremony_Script_Annotate...
I see that the KSR arrives on a smartcard.}
It seems that the secrets which are split up are kept in the/a safe, using a safety deposit box, and it is further in a tamper resistant bag. The TCR retains the key to the safety deposit box. Am I correct that the secret split never leaves the room, so "m" TCRs can not actually reconstruct she key on their own? I'm unclear what kind of media the secret is stored on, but I understand it plugs straight into the HSM, not the control laptop.
(BTW: I recognize that I'm reading KSK and ZSK documents at the same time)
I was surprised at the lack of references in the dps documents to any theory about how this process was created. This is what I am looking for: a palette of ways to make key ceremonies for a variety of different threat levels.
Still I learned something by actually watching the entire video (at 1.75x speed..) and reading the entire ceremony through.
-- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On 4/5/20 12:21 PM, Russ Housley wrote:
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
I am unclear from reading things over again how the ZSK gets to the>>> ceremony. Is a new ZSK keypair generated during the KSK, or is it generated>>> elsewhere and only the public part brought?
This is probably the wrong list to ask on.
IANA has emergency procedures that can be used to obtain the needed three shares. It is clear from the text that you quote, that emergency planning was considered fro the start. I assume that IANA will declare such an emergency in the next few days, and then generate the next KSK under those procedures. As I understand it, the auditor will be able to tell that the emergency procedure were properly followed.
Folks may find the discussion on this thread: https://lists.dns-oarc.net/pipermail/dns-operations/2020-March/019874.html also informative on this topic. Keith
Russ Housley <housley@vigilsec.com> wrote: > IANA has emergency procedures that can be used to obtain the needed > three shares. It is clear from the text that you quote, that emergency > planning was considered fro the start. I assume that IANA will declare > such an emergency in the next few days, and then generate the next KSK > under those procedures. As I understand it, the auditor will be able > to tell that the emergency procedure were properly followed. Wow, I didn't think that we'd have to generate a new KSK. I think it's enough to get a new ZSK signed, and my reading of the OARC email says that this is what they are trying to do. I guess that I'm right that the TCRs hold the keys to the safety deposit boxes. I find it interesting that the staff-only process means drilling them out. Should that room have a continuous video stream? :-) -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On Apr 5, 2020, at 5:01 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Russ Housley <housley@vigilsec.com> wrote:
IANA has emergency procedures that can be used to obtain the needed three shares. It is clear from the text that you quote, that emergency planning was considered fro the start. I assume that IANA will declare such an emergency in the next few days, and then generate the next KSK under those procedures. As I understand it, the auditor will be able to tell that the emergency procedure were properly followed.
Wow, I didn't think that we'd have to generate a new KSK. I think it's enough to get a new ZSK signed, and my reading of the OARC email says that this is what they are trying to do.
You are correct. That was my fingers doing something different from my brain. Russ
Hi Michael, At 06:39 PM 04-04-2020, Michael Richardson wrote:
https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf says:
5.2.2. Private key (m-of-n) multi-person control Verisign has implemented technical and procedural mechanisms that require the participation of multiple trusted individuals to perform sensitive cryptographic operations. Verisign uses "Secret Sharing" to split the activation data needed to make use of a RZ ZSK private key into separate parts called "Secret Shares" which are held by trained and trusted individuals called "Shareholders." A threshold number of Secret Shares (m) out of the total number of Secret Shares created and distributed for a particular HSM (n) is required to activate a RZ ZSK private key stored on the module. The threshold number of shares needed to sign a root Zone File is 3. It should be noted that the number of shares distributed for disaster recovery tokens may be less than the number distributed for operational HSMs, while the threshold number of required shares remains the same. Secret Shares are protected in accordance with this DPS.
---
The document which you cited is for the Root Zone Maintainer (Verisign).
I think that the HSM keeps the private key (RSA) encrypted. The key that is used to do this encryption (probably AES256) is the thing that is secret-split among the n-shareholders. I understand that m=3.
It says "a particular HSM", so does this mean that the encryption key used to encrypt the private RSA key is different in different HSMs (at different locations), and a *different* m people are required to activate it?
I would think that the different HSM would synchornize the encrypted copy of the private key, and thus the split secret would be the same n pieces. Of course, the key could be moved to another HSM by the initial m-of-n people, it could be *re*-encrypted to n' pieces and some other m' people required. The n and n' people could completely or partially overlap.
There are four HSMs. Any one of them can be used for a KSK Ceremony.
{BTW: When I read the KSK ceremony script, at:
https://data.iana.org/ksk-ceremony/40/20200216-KC40-Ceremony_Script_Annotate...
I see that the KSR arrives on a smartcard.}
A Flash Drive is inserted in Step 5 (Page 14). The KSR is on it.
It seems that the secrets which are split up are kept in the/a safe, using a safety deposit box, and it is further in a tamper resistant bag. The TCR retains the key to the safety deposit box. Am I correct that the secret split never leaves the room, so "m" TCRs can not actually reconstruct she key on their own? I'm unclear what kind of media the secret is stored on, but I understand it plugs straight into the HSM, not the control laptop.
The secret spit never leaves the room. The Crypto Officers cannot reconstruct the key on their own.
(BTW: I recognize that I'm reading KSK and ZSK documents at the same time)
I was surprised at the lack of references in the dps documents to any theory about how this process was created. This is what I am looking for: a palette of ways to make key ceremonies for a variety of different threat levels.
I suggest looking at NIST SP 800-57. Regards, S. Moonesamy
S Moonesamy <sm+icann@elandsys.com> wrote: > At 06:39 PM 04-04-2020, Michael Richardson wrote: >> https://www.iana.org/dnssec/dps/zsk-operator/dps-zsk-operator-v2.0.pdf says: >> >> 5.2.2. Private key (m-of-n) multi-person control >> Verisign has implemented technical and procedural mechanisms that >> require the participation of multiple trusted individuals to perform >> sensitive cryptographic operations. Verisign uses "Secret Sharing" >> to split the activation data needed to make use of a RZ ZSK private >> key into separate parts called "Secret Shares" which are held by >> trained and trusted individuals called "Shareholders." A threshold >> number of Secret Shares (m) out of the total number of Secret Shares >> created and distributed for a particular HSM (n) is required to >> activate a RZ ZSK private key stored on the module. The threshold >> number of shares needed to sign a root Zone File is 3. It should be >> noted that the number of shares distributed for disaster recovery >> tokens may be less than the number distributed for operational HSMs, >> while the threshold number of required shares remains the same. >> Secret Shares are protected in accordance with this DPS. >> >> --- > The document which you cited is for the Root Zone Maintainer (Verisign). yes, I realize that there are two documents. They are at least 70% identical. >> I would think that the different HSM would synchornize the encrypted copy of >> the private key, and thus the split secret would be the same n pieces. >> Of course, the key could be moved to another HSM by the initial m-of-n >> people, it could be *re*-encrypted to n' pieces and some other m' people >> required. The n and n' people could completely or partially overlap. > There are four HSMs. Any one of them can be used for a KSK Ceremony. Yes, I guess that split material contains the entire context needed, and that nothing is actually stored in the HSM. >> {BTW: When I read the KSK ceremony script, at: >> >> https://data.iana.org/ksk-ceremony/40/20200216-KC40-Ceremony_Script_Annotate... >> >> I see that the KSR arrives on a smartcard.} > A Flash Drive is inserted in Step 5 (Page 14). The KSR is on it. It seems like the weakest link, btw. >> (BTW: I recognize that I'm reading KSK and ZSK documents at the same time) >> >> I was surprised at the lack of references in the dps documents to any theory >> about how this process was created. This is what I am looking for: a >> palette of ways to make key ceremonies for a variety of different threat >> levels. > I suggest looking at NIST SP 800-57. Thank you. I knew that such a thing existed, but I am very weak in the NIST-fu. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On Apr 5, 2020, at 2:05 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
A Flash Drive is inserted in Step 5 (Page 14). The KSR is on it.
It seems like the weakest link, btw.
Hi Michael, Sections 5.6 and 6.7 of the KSK operator DNSSEC Practice Statement explain how the KSR is transferred and verified: 5.6. Network Security Controls No part of the signer system making use of the HSM is connected to any communications network. Communication of ZSK key signing requests (KSR) from the Root Zone Maintainer/ZSK Operator is done using a TLS client-side authenticated web server connected to the RZ KSK Operator's production network. Transfer of a KSR from the web server to the signer system is performed manually using removable media (refer to Section 6.7 for further details on verification of the KSR). 6.7. Verification of zone signing key set Each key set within the Key Signing Request (KSR) is self-signed with the active key to provide proof of possession of the corresponding private key. The signer system will automatically validate this signature and perform checking of available parameters before accepting the KSR for signing. The RZ KSK Operator will verify the authenticity of the KSR document by performing an out-of-band verification (verbally over the phone, by fax, or any other available method) of the hash of the KSR, before entering the KSR into the signer system. The resulting Signed Key Response (SKR) is transferred back using the same TLS client-side authenticated connection used to receive the KSR from the Root Zone Maintainer.
Quoting Michael Richardson on Saturday April 04, 2020:
I was locating appropriate references for explaining Key signing ceremonies, and noticed the report of the safe problems at: https://www.theregister.co.uk/2020/02/13/iana_dnssec_ksk_delay/ https://www.icann.org/news/blog/root-key-signing-key-ceremony-postponed
and then the schedule at: https://www.iana.org/dnssec/ceremonies
in which April 23 is the next date. Will travel bans cause a problem? I kinda hope the travel bans are enforced.
We are developing contingency plans for holding the key ceremony. At this stage the ceremony will not be held in its normal configuration. It _may_ be held on that date, or the date may be adjusted. Once we have a more definitive approach finalized we'll update the website and notify our normal channels. We expect it to be around that date, nonetheless.
"Introduce HSM6E" Does this mean that a new HSM device will be added?
That is part of the original agenda, but that will almost certainly be postponed until a later ceremony. We are trying to perform the bare minimum of operations for the forthcoming ceremony. In normal operations, we have a 5 year service life for our HSMs, and we have four in service, so we replace a HSM roughly once a year in a staggered fashion.
I see RRSIG from keyid 20326 (current root) will expire 20200422000000. Maybe there is another RRSIG hidden away that I can't see?
From the audit materials on the IANA website, here are the signatures generated at the last key ceremony:
Generated new SKR in /media/KSR/KSK40/skr-root-2020-q2-0.xml # Inception Expiration ZSK Tags KSK Tag(CKA_LABEL) 1 2020-04-01T00:00:00 2020-04-22T00:00:00 33853,48903 20326(Klajeyz)/S 2 2020-04-11T00:00:00 2020-05-02T00:00:00 48903 20326(Klajeyz)/S 3 2020-04-21T00:00:00 2020-05-12T00:00:00 48903 20326(Klajeyz)/S 4 2020-05-01T00:00:00 2020-05-22T00:00:00 48903 20326(Klajeyz)/S 5 2020-05-11T00:00:00 2020-06-01T00:00:00 48903 20326(Klajeyz)/S 6 2020-05-21T00:00:00 2020-06-11T00:00:00 48903 20326(Klajeyz)/S 7 2020-05-31T00:00:00 2020-06-21T00:00:00 48903 20326(Klajeyz)/S 8 2020-06-10T00:00:00 2020-07-01T00:00:00 48903 20326(Klajeyz)/S 9 2020-06-20T00:00:00 2020-07-11T00:00:00 46594,48903 20326(Klajeyz)/S
https://www.iana.org/dnssec/icann-dps.txt I am unclear from reading things over again how the ZSK gets to the ceremony. Is a new ZSK keypair generated during the KSK, or is it generated elsewhere and only the public part brought?
There is a encrypted authentication channel where the "key signing request" (KSR) and the "signed key response" (SKR) are exchanged between the KSK operator (IANA) and the ZSK operator (Verisign). Verisign representatives attend to the hash of the KSR that is sent as part of the ceremony to validate it hasn't been tampered with in transit. kim
participants (6)
-
Keith Mitchell -
Kim Davies -
Michael Richardson -
Russ Housley -
S Moonesamy -
Wessels, Duane