[dns-operations] Algorithm but no signature in .in?
Some resolvers protest on .in. It seems they have a RSASHA256 key but no RSASHA256 signatures, thus violating RFC 4035, section 2.2 "There MUST be an RRSIG for each RRset using at least one DNSKEY of EACH ALGORITHM". (Cannot show a nice DNSviz picture, DNSviz seems broken at this time.) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony
Hi Sergey, Quoting Sergey Myasoedov on Friday March 27, 2020: > > There is no specific concern. Any KSK operation can be performed without the > physical > TCRs presence. There is no other source of confidence except TCRs, and their > absence > or accessing the private key without their presence isn’t good for trust. Hopefully our approach does not depend solely on TCRs for confidence. We've consciously sought to operate a highly transparent process that allows anyone who is interested - not just TCRs - to witness proceedings and be involved, either in person or remotely. Further, we are audited by a third-party audit firm using the SOC 3 framework (formerly SysTrust), and have received unqualified opinions each year since we first started in 2010: https://www.iana.org/about/audits Another key protection is we seek to disseminate all the relevant materials from the ceremony. All audit footage, software used, and the logs and artefacts generated are posted online for download and inspection. Certainly if there is a perception that trust hinges critically on TCRs, we've either not communicated the breadth of the controls well enough, or we need to do more to instill trust. Just as the security envelope for the KSK involves multiple overlapping physical security controls, maintaining trust in KSK management should involve multiple overlapping trust mechanisms to satisfy the community. > I understand the extraordinariness of the moment, and if you have no choice, > you’ll jump to > Option 2 and Option 3 then. Is the disaster recovery procedure (Option 3) the > one that should’ve > been done on Verisign’s disaster recovery site? Does it require to access the > cards? Or we’re > discussing the non-disaster remote ceremony? We do not have any disaster recovery sites, and we do not use any sites operated by Verisign. We have two replica sites which, in normal operations, we alternate holding key ceremonies. We can use either to perform a key ceremony. Verisign operates their own infrastructure as it pertains to managing the ZSK for the root zone. kim ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony
There is no specific concern. Any KSK operation can be performed without the physical TCRs presence. There is no other source of confidence except TCRs, and their absence or accessing the private key without their presence isn’t good for trust. I understand the extraordinariness of the moment, and if you have no choice, you’ll jump to Option 2 and Option 3 then. Is the disaster recovery procedure (Option 3) the one that should’ve been done on Verisign’s disaster recovery site? Does it require to access the cards? Or we’re discussing the non-disaster remote ceremony? -- Kind regards, Sergey Myasoedov > On 26 Mar 2020, at 23:21, Kim Davies wrote: > > Quoting Sergey Myasoedov on Thursday March 26, 2020: >> >>> • Using 3 TCRs’ credentials, either by having their access key >>> transferred to us in a secure manner in advance of the ceremony, or by >>> drilling the safety deposit box that holds their secure elements. >> >> Accessing the credentials without the TCRs present will shatter confidence >> in TCR model. Better avoid that. > > It would be good to better understand this concern, because we are > facing scenarios where we may not have a choice but to do it in this > manner. What is your specific concerns about the lack of physical TCR > participation, and what would be the best way to remediate them? > > Bear in mind our goal is to continue to involve TCRs remotely in an > active role as much as possible, much in the same way they would > participate in a regular ceremony. They would oversee custody of their > credential, along with having the opportunity to interject and advise > along the way. > > kim ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony
Quoting Sergey Myasoedov on Thursday March 26, 2020: > > > • Using 3 TCRs’ credentials, either by having their access key > > transferred to us in a secure manner in advance of the ceremony, or by > > drilling the safety deposit box that holds their secure elements. > > Accessing the credentials without the TCRs present will shatter confidence in > TCR model. Better avoid that. It would be good to better understand this concern, because we are facing scenarios where we may not have a choice but to do it in this manner. What is your specific concerns about the lack of physical TCR participation, and what would be the best way to remediate them? Bear in mind our goal is to continue to involve TCRs remotely in an active role as much as possible, much in the same way they would participate in a regular ceremony. They would oversee custody of their credential, along with having the opportunity to interject and advise along the way. kim ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Contingency plans for the next Root KSK Ceremony
> • Using 3 TCRs’ credentials, either by having their access key > transferred to us in a secure manner in advance of the ceremony, or by > drilling the safety deposit box that holds their secure elements. Accessing the credentials without the TCRs present will shatter confidence in TCR model. Better avoid that. -- Kind regards, Sergey Myasoedov > On 26 Mar 2020, at 02:52, Kim Davies wrote: > > Colleagues, > > The IANA team, and the broader ICANN organization, have been giving > significant thought to the Coronavirus pandemic and its impact on root zone > KSK operations. Managing the KSK is centred on conducting "key signing > ceremonies", where trusted community representatives (TCRs) attend from > around the world to witness utilization of the root zone KSK private key. > This approach seeks to engender trust in the broader community that the key > has not been compromised, in addition to more typical controls such as > third-party auditing. > > In light of world events we have developed contingency plans around how to > hold key ceremonies in the short term. To that end, we identified a graduated > set of options, in summary: > • Hold the next ceremony as planned on April 23, with a quorum of > participants globally. > • Hold the next ceremony on a different date using only US-based TCRs. > • Hold the next ceremony using our disaster recovery procedure, which > provides for a staff-only ceremony (i.e. no TCRs would be physically present). > In general, our goal has been to navigate from Option 1, and if that is not > possible, Option 2, and so on. However, at this time, our focus is on > developing a plan around Option 3. > > The ceremony is currently scheduled unusually early in the quarter (it is > typically held in May), and needs to be held to generate signatures that will > be needed in production for July. Our contingency plan is comprised of: > > • Holding the ceremony with a bare minimum of staff (approximately 6); > • Using 3 TCRs’ credentials, either by having their access key > transferred to us in a secure manner in advance of the ceremony, or by > drilling the safety deposit box that holds their secure elements. > • Holding the ceremony under typical audit coverage, allowing for > remote witnessing of events by all, plus providing additional opportunities > for TCRs to stay involved in the process remotely. > • Signing key materials to cover one or more subsequent quarters, to > provide relief from the need to necessarily hold ceremonies later in 2020 if > circumstances disallow it. (The additional signatures would be withheld > securely until they are needed.) > Our key management facilities were designed with the disaster recovery > capability of performing staff-only ceremonies in mind, but this is a > significant shift from normal operations and we want to promote broader > community awareness of this work. Those directly involved in key ceremonies - > the trusted community representatives, our vendors and auditors - have been > consulted and are broadly supportive of this effort. > > Should there be any specific feedback you would like to share with our team, > please let me know or respond to this thread. We will take it into > consideration as we finalize our plans. > Thank you for your support, > > > Kim Davies > VP, IANA Services, ICANN > President, Public Technical Identifiers (PTI) > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
