Just wondering, have you asked if 3 of the TCR's might be willing to actually come? With enough protections, would that be possible?
-- Bob Harold On Mon, Mar 30, 2020 at 3:19 PM Warren Kumari <war...@kumari.net> wrote: > On Fri, Mar 27, 2020 at 5:46 AM Erwin Lansing via dns-operations > <dns-operati...@dns-oarc.net> wrote: > > > > > > > > > > ---------- Forwarded message ---------- > > From: Erwin Lansing <er...@lansing.dk> > > To: Kim Davies <kim.dav...@iana.org> > > Cc: Sergey Myasoedov <s...@netartgroup.com>, "dns-operati...@dns-oarc.net" > <dns-operati...@dns-oarc.net> > > Bcc: > > Date: Fri, 27 Mar 2020 10:34:51 +0100 > > Subject: Re: [dns-operations] [Ext] Re: Contingency plans for the next > Root KSK Ceremony > > Hi Kim, > > > > > On 27 Mar 2020, at 01.55, Kim Davies <kim.dav...@iana.org> wrote: > > > > > > 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 think you hit the nail on the head here: it’s all about perception. > > Yup - just like a bank (or currency), the primary concern is the > perception of trust. For the sake of argument, let's pretend I don't > trust Kim et al at all / have some agenda to call the security / > stability of DNSSEC into question. > > So, the safes get drilled; on camera and with all of TCRs (and their > aunties) watching. Everyone watches the ceremony, and everyone agrees > that everything went perfectly and there were no shenanigans -- what > happens *after* the ceremony? > How can we prove that nothing bad occurred after the ceremony > concluded and the cameras were turned off? I'm assuming that new locks > will be installed, and materials returned to their rightful places, > but this still leaves Kim et al with a big pile-o-keys that they could > use. We could probably stick (on camera) numbered tamper evident seals > over the locks, and have Kim sign them, but now we have devolved the > security to just numbered stickers / numbered bags and the signature > of the same person/people who have the pile-o-keys. > > Before people get all up in arms, no, I'm not suggesting that IANA is > actually going to sneak in after the cameras are turned off and > <insert movie plot scenario here>, and I also recognize that these are > exceptional circumstances - what I'm trying to do is figure out how we > accomplish this while maintaining the actual and *perceived* trust in > the system -- it would be very sad if a few months from now we realize > that there was something really simple that we could have done to > maintain the trustworthiness, but didn't think of... The IANA and TCRs > have invested heavily in maintaining the trust in the system - I'd > hate to see that lost because we didn't think of something we could > have (easily) done... > > We also need to ensure that we don't end up too much in the tin foil > hat camp, but I don't think I've seen any discussion of what happens > after the ceremony and think it would be useful to try and cover the > re-securing phase (of course, it is entirely possible I missed it...) > > W > > > No matter how many other controls and layer of security, drilling a safe > bring up certain images in peoples minds. For that reason alone, I’d also > rather avoid that solution, but extraordinary circumstances require > extraordinary solutions. As you say, the process is a transparent as it can > be, and with enough emphasis on the existing, and possibly extra, security > measures, it should be no problem to dispel that perception, and it may > well be the most practical way to go. > > > > Best, > > Erwin > > > > > > > > ---------- Forwarded message ---------- > > From: Erwin Lansing via dns-operations <dns-operati...@dns-oarc.net> > > To: Kim Davies <kim.dav...@iana.org> > > Cc: "dns-operati...@dns-oarc.net" <dns-operati...@dns-oarc.net> > > Bcc: > > Date: Fri, 27 Mar 2020 10:34:51 +0100 > > Subject: Re: [dns-operations] [Ext] Re: Contingency plans for the next > Root KSK Ceremony > > _______________________________________________ > > dns-operations mailing list > > dns-operations@lists.dns-oarc.net > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > 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
