<div dir="ltr">How do you prevent compromise of the central service?<div><br></div><div>Steve</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 6, 2018 at 3:02 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"><span class="">On 23:19 06/09, Mukund Sivaraman wrote:<br>
> On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández wrote:<br>
> > 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>
> Aha so you're the original source :)<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/<wbr>docker/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/<wbr>getFile.py/access?contribId=<wbr>22&sessionId=3&resId=1&<wbr>materialId=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.<wbr>org/en/schedule/wed-dnssec/<wbr>presentation-dnssec-<wbr>cryptographic-20nov13-en</a>><br>
> <br>
> So this's implemented as a PKCS 11 provider.. interesting. In my mind I<br>
> was thinking along the lines of updates to dnssec-keygen +<br>
> dnssec-signzone + intermediate RRSIG representation using new RR type +<br>
> zone transfers to share intermediate effects.<br>
<br>
</span>In our implementation you'll need a central "orchestrator" who<br>
creates the first key and split the private pieces to each<br>
signing node. This same orchestrator later send signature<br>
requests to each node, collect the signature pieces and<br>
defines the "consensus" of M/N. Finally, there's an PKCS11<br>
interface between this orchestrator and the zone signing<br>
policy machinery (OpenDNSSEC in our setup).<br>
<span class="HOEnZb"><font color="#888888"><br>
Hugo<br>
<br>
</font></span><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></div></div>