<div dir="ltr">Let me flag a key point.  You said this scheme will *detect* faked signatures.  If you want to *prevent* faked signatures, you need additional structure.<div><br></div><div>Steve</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 6, 2018 at 3:22 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 15:08 06/09, Steve Crocker wrote:<br>
> How do you prevent compromise of the central service?<br>
> <br>
<br>
</span>For the initial setup a physical ceremony is necessary,<br>
to check there's no extra subkeys and for secure transmision<br>
of them. But afterwards there's no need. Each node can check<br>
the final signature validates with the public key (just like<br>
a normal signature), and the plain data should be public<br>
(DNSKEY rrset).<br>
<br>
In this same first ceremony you can also share simmetric<br>
keys for the secure transmission of data and signature<br>
pieces.<br>
<br>
The system is fault-tolerant as a subset of nodes can fail<br>
and the signing process can be completed, and you can<br>
detect faked sub-signatures.<br>
<span class="HOEnZb"><font color="#888888"><br>
Hugo<br>
</font></span><span class="im HOEnZb"><br>
> Steve<br>
> <br>
> <br>
> On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández <<a href="mailto:hsalgado@nic.cl">hsalgado@nic.cl</a>><br>
> wrote:<br>
> <br>
> > 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>
</span><span class="im HOEnZb">> > > > [2] <<a href="https://indico.dns-oarc.net/getFile.py/access?contribId=" rel="noreferrer" target="_blank">https://indico.dns-oarc.net/<wbr>getFile.py/access?contribId=</a><br>
> > 22&sessionId=3&resId=1&<wbr>materialId=slides&confId=20><br>
> > > > [3] <<a href="http://buenosaires48.icann.org/en/schedule/wed-dnssec/" rel="noreferrer" target="_blank">http://buenosaires48.icann.<wbr>org/en/schedule/wed-dnssec/</a><br>
> > presentation-dnssec-<wbr>cryptographic-20nov13-en><br>
> > ><br>
</span><div class="HOEnZb"><div class="h5">> > > 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>
> > 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>
> ><br>
> > Hugo<br>
> ><br>
> ><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>
> ><br>
<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>
</div></div></blockquote></div><br></div></div></div>