Great stuff Steve. John Gilmore and I talked about the use of byzantine quorum systems for key management at ISOC in 1998. And Olaf Kolkman, Johan Ihren and I proposed such a system in 2005 as an alternative to what became RFC 5011. I built a DNS system that used these ideas for DNS key management as part of my thesis work in 2013. If there is interest I'd be happy to join a conversation.
http://www.cs.cornell.edu/courses/cs5414/2017fa/papers/bquorum-dc.pdf /Wm On Thu, Sep 6, 2018 at 11:14 AM, Steve Crocker <st...@shinkuro.com> wrote: > I've been thinking about a version of this problem for several years. > Attached are a short paper and presentation on the topic of a tamperproof > root zone update system. The ideas are also applicable to other levels in > the DNS tree. > > In parallel, there is work on open source hardware crypto that can easily > be extended to include this functionality. > > There are some important governance and process details alluded to but not > fleshed out in the paper.. Happy to discuss with anyone interested. > > Steve > > > On Thu, Sep 6, 2018 at 1:34 PM, Hugo Salgado-Hernández <hsalg...@nic..cl> > wrote: > >> Hi Mukund. >> I talked about this to Davey in Montreal. There's an implementation >> in github[1] and presentations in OARC[2] and ICANN[3]. >> >> I'm not sure if its being used right now in a live zone, but certainly >> in labs and testing. There's been some interests with academic >> institutions, but don't think they're ready yet. >> >> We've been trying to focus this technology as a "poor-man" HSM, as >> having similar security features without buying an expensive HW. >> But I think the root and similar high-value zones will benefit for >> having an split of the private key AND the fact of not needing a >> "root key ceremony" to sign, because you can sign remotely with >> each piece of the private key, and transmit the "signature pieces" >> to a central place. >> >> Hugo >> >> [1] https://github.com/niclabs/docker/tree/master/tchsm >> [2] <https://indico.dns-oarc.net/getFile.py/access?contribId=22&; >> sessionId=3&resId=1&materialId=slides&confId=20> >> [3] <http://buenosaires48.icann.org/en/schedule/wed-dnssec/prese >> ntation-dnssec-cryptographic-20nov13-en> >> >> >> On 21:42 06/09, Mukund Sivaraman wrote: >> > During a coversation about the Yeti project, Davey Song brought up an >> > idea about using threshold signatures within DNSSEC. While he talked >> > about it primarily for the root zone within the context of having >> > multiple signers for it, I'm curious to know what operators think about >> > the concept for other zones, and if there's any interest in having a >> > working implementation. >> > >> > DNSKEY RRs contain public keys. Corresponding secret keys are managed by >> > signing entities in various ways: >> > >> > * It may be for a low-risk zone and a human may leave the key on the >> > nameserver itself >> > >> > * The key may be held by some number of trustworthy staff offline and >> > when signing is required, one of them signs the zone and returns the >> > signed zone >> > >> > * It may be managed by an automated system under the control of one or >> > more people >> > >> > * It may be held in a locked computer system which may be accessed when >> > multiple trustworthy "keepers" are present >> > >> > * There may be schemes like this: >> > https://www.icann.org/news/blog/the-problem-with-the-seven-keys >> > >> > In many of these cases, it may be possible for one rogue person to sign >> > records against the wish of the rest of the trustworthy group appointed >> > by a zone owner. Even though it's unlikely, it's possible to do so >> > because the control over secret key material may be available to one >> > person, even if it is wrapped in multiple layers. >> > >> > The concept of threshold crypto is that there is a public DNSKEY, for >> > which the secret key is not available in a single form where it can be >> > reconstructed. Instead, N members of a group have some key material each >> > respectively, and any M (< N) members of the group may work together to >> > prepare RRSIGs by using their respective key materials individually, and >> > collaborating to generate the signatures. >> > >> > It may be possible for such a scheme to be compatible with existing >> > DNSSEC algorithms. Is there any operator interest in this? >> > >> > Mukund >> > >> > _______________________________________________ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> > >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
