<div dir="ltr"><div dir="ltr">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.<div><br></div><div><a href="http://www.cs.cornell.edu/courses/cs5414/2017fa/papers/bquorum-dc.pdf">http://www.cs.cornell.edu/courses/cs5414/2017fa/papers/bquorum-dc.pdf</a><br></div><div><br></div><div><br></div><div>/Wm</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 6, 2018 at 11:14 AM, Steve Crocker <span dir="ltr"><<a href="mailto:steve@shinkuro.com" target="_blank">steve@shinkuro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>In parallel, there is work on open source hardware crypto that can easily be extended to include this functionality.</div><div><br></div><div>There are some important governance and process details alluded to but not fleshed out in the paper..  Happy to discuss with anyone interested.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Steve</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 6, 2018 at 1:34 PM, Hugo Salgado-Hernández <span dir="ltr"><<a href="mailto:hsalgado@nic.cl" target="_blank">hsalgado@nic.cl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mukund.<br>
I talked about this to Davey in Montreal. There's an implementation<br>
in github[1] and presentations in OARC[2] and ICANN[3].<br>
<br>
I'm not sure if its being used right now in a live zone, but certainly<br>
in labs and testing. There's been some interests with academic<br>
institutions, but don't think they're ready yet.<br>
<br>
We've been trying to focus this technology as a "poor-man" HSM, as<br>
having similar security features without buying an expensive HW.<br>
But I think the root and similar high-value zones will benefit for<br>
having an split of the private key AND the fact of not needing a<br>
"root key ceremony" to sign, because you can sign remotely with<br>
each piece of the private key, and transmit the "signature pieces"<br>
to a central place.<br>
<br>
Hugo<br>
<br>
[1] <a href="https://github.com/niclabs/docker/tree/master/tchsm" rel="noreferrer" target="_blank">https://github.com/niclabs/doc<wbr>ker/tree/master/tchsm</a><br>
[2] <<a href="https://indico.dns-oarc.net/getFile.py/access?contribId=22&sessionId=3&resId=1&materialId=slides&confId=20" rel="noreferrer" target="_blank">https://indico.dns-oarc.net/g<wbr>etFile.py/access?contribId=22&<wbr>sessionId=3&resId=1&materialId<wbr>=slides&confId=20</a>><br>
[3] <<a href="http://buenosaires48.icann.org/en/schedule/wed-dnssec/presentation-dnssec-cryptographic-20nov13-en" rel="noreferrer" target="_blank">http://buenosaires48.icann.or<wbr>g/en/schedule/wed-dnssec/prese<wbr>ntation-dnssec-cryptographic-<wbr>20nov13-en</a>><br>
<div class="m_3291907265156461598HOEnZb"><div class="m_3291907265156461598h5"> <br>
<br>
On 21:42 06/09, Mukund Sivaraman wrote:<br>
> During a coversation about the Yeti project, Davey Song brought up an<br>
> idea about using threshold signatures within DNSSEC. While he talked<br>
> about it primarily for the root zone within the context of having<br>
> multiple signers for it, I'm curious to know what operators think about<br>
> the concept for other zones, and if there's any interest in having a<br>
> working implementation.<br>
> <br>
> DNSKEY RRs contain public keys. Corresponding secret keys are managed by<br>
> signing entities in various ways:<br>
> <br>
> * It may be for a low-risk zone and a human may leave the key on the<br>
>   nameserver itself<br>
> <br>
> * The key may be held by some number of trustworthy staff offline and<br>
>   when signing is required, one of them signs the zone and returns the<br>
>   signed zone<br>
> <br>
> * It may be managed by an automated system under the control of one or<br>
>   more people<br>
> <br>
> * It may be held in a locked computer system which may be accessed when<br>
>   multiple trustworthy "keepers" are present<br>
> <br>
> * There may be schemes like this:<br>
>   <a href="https://www.icann.org/news/blog/the-problem-with-the-seven-keys" rel="noreferrer" target="_blank">https://www.icann.org/news/bl<wbr>og/the-problem-with-the-seven-<wbr>keys</a><br>
> <br>
> In many of these cases, it may be possible for one rogue person to sign<br>
> records against the wish of the rest of the trustworthy group appointed<br>
> by a zone owner. Even though it's unlikely, it's possible to do so<br>
> because the control over secret key material may be available to one<br>
> person, even if it is wrapped in multiple layers.<br>
> <br>
> The concept of threshold crypto is that there is a public DNSKEY, for<br>
> which the secret key is not available in a single form where it can be<br>
> reconstructed. Instead, N members of a group have some key material each<br>
> respectively, and any M (< N) members of the group may work together to<br>
> prepare RRSIGs by using their respective key materials individually, and<br>
> collaborating to generate the signatures.<br>
> <br>
> It may be possible for such a scheme to be compatible with existing<br>
> DNSSEC algorithms. Is there any operator interest in this?<br>
> <br>
>               Mukund<br>
> <br>
> ______________________________<wbr>_________________<br>
> DNSOP mailing list<br>
> <a href="mailto:DNSOP@ietf.org" target="_blank">DNSOP@ietf.org</a><br>
> <a href="https://www.ietf.org/mailman/listinfo/dnsop" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/l<wbr>istinfo/dnsop</a><br>
> <br>
</div></div><br>______________________________<wbr>_________________<br>
DNSOP mailing list<br>
<a href="mailto:DNSOP@ietf.org" target="_blank">DNSOP@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/dnsop" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/l<wbr>istinfo/dnsop</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
DNSOP mailing list<br>
<a href="mailto:DNSOP@ietf.org">DNSOP@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/dnsop" rel="noreferrer" target="_blank">https://www.ietf.org/mailman/<wbr>listinfo/dnsop</a><br>
<br></blockquote></div><br></div>