[dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Bob Harold]

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 <warren at kumari.net> wrote:

> On Fri, Mar 27, 2020 at 5:46 AM Erwin Lansing via dns-operations
> <dns-operations at dns-oarc.net> wrote:
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Erwin Lansing <erwin at lansing.dk>
> > To: Kim Davies <kim.davies at iana.org>
> > Cc: Sergey Myasoedov <s at netartgroup.com>, "dns-operations at dns-oarc.net"
> <dns-operations at 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.davies at 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-operations at dns-oarc.net>
> > To: Kim Davies <kim.davies at iana.org>
> > Cc: "dns-operations at dns-oarc.net" <dns-operations at 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 at 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 at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200330/778dfab8/attachment.html>