[dns-operations] [DNSOP] DNSSEC threshold signatures idea

Fri Sep 7 09:45:35 UTC 2018

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 <steve at 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 <hsalgado at 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 at ietf.org
>> > https://www.ietf.org/mailman/listinfo/dnsop
>> >
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP at ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP at ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180907/c57522a0/attachment.html>