Re: [DNSOP] DNSSEC threshold signatures idea

william manning <chinese.apricot@gmail.com> Fri, 07 September 2018 09:45 UTC

Return-Path: <chinese.apricot@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4C128CB7 for <dnsop@ietfa.amsl.com>; Fri, 7 Sep 2018 02:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZx06r0KabxM for <dnsop@ietfa.amsl.com>; Fri, 7 Sep 2018 02:45:37 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87943130DE9 for <dnsop@ietf.org>; Fri, 7 Sep 2018 02:45:37 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id q4-v6so1070121iob.8 for <dnsop@ietf.org>; Fri, 07 Sep 2018 02:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FLhkBYNPObEQ7+LyXJ2A6ZM49ThCt2zNga4RctPqheQ=; b=ZLKdbyBf69IlvNP51Y/Ie1XZVvlznwgSPGGoD3JdLw6Uxl8IpDA1B0HyF6ZlK4T+pO ZYvd4uVtqWpUn4nrIANYMDZgdLU2NhJ1Kw9qmP0D7ZIcV/ETA/d6GAWQLOOHYoDguiKd 7VkMdiOE9MnJjghEVVXeem07UCNz7qBgl/ww+1E7ZHt7yXNqh2lES4+wf95hPHGK7G79 PuA0nZhB7cr5xykKthos0CP5/GQQ1aI2A7Mr2xUCp7EMSbuPcRVOrqWFNyelS06+6zVd zLr7fgZHjbXqQ7/WJ4z81cYrR5Io9rPkybWUTbNunnfy2rASOCympHg9knOsnSVu4lsH u6uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FLhkBYNPObEQ7+LyXJ2A6ZM49ThCt2zNga4RctPqheQ=; b=gH+6/FU//JlZ7ox0sULlQZke2gPxrSCXhqVJ0SoDxe+0QTOb4oJV/e0V5oeQ/wFD4o 1Zs1ZIjB9vb1HQ/ERlzz7T2RVqtg1Nikj/QC6AVRazINjx2Qp+pO6BDuXbsuV1gEL9wv yPj6j1WEFeOyKWtOA0Xw3gccd9NYOydolrhAYD1r0A4sf8von2dyYngTmEwAwAUEu6Sz vGA+u3sb3QV2MzEGdL8QmOSNaj5+sa0VMmd8L2YvvuQTFp9Wix8N/wAfjUNt8rJniJr+ 3xtFtzT2imHSeOtsfroHoZuLA4JX9J2p4FYTh72Y4WSnRVJe3Vpm4d9+ym0MGeUJchmc /y/A==
X-Gm-Message-State: APzg51AMXfWsJNZBx/nnoOZ5/6yjAhYeQj7LlwerzTZj1p/91DgCkSmr SehTsF5Hs7H5iwAJTB8AihWjH5xsiJ4SF7uMQ7NEC/12520=
X-Google-Smtp-Source: ANB0VdbzD4khWeH9TGgIDhev0JaO/o3DTo5OsosRHY3chNnBmRoHMSihEis/xKyG+/J6G7LXplKRqEKB9cvAIntqJR0=
X-Received: by 2002:a6b:440f:: with SMTP id r15-v6mr5648405ioa.107.1536313536571; Fri, 07 Sep 2018 02:45:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a5e:8f44:0:0:0:0:0 with HTTP; Fri, 7 Sep 2018 02:45:35 -0700 (PDT)
In-Reply-To: <CABf5zvKPhX_t8oHJmsLEB3SxrAptyec9NVXx0sxfievc19wW1w@mail.gmail.com>
References: <20180906161252.GA2840@jurassic> <20180906173412.og736bryaeqbwjds@nic.cl> <CABf5zvKPhX_t8oHJmsLEB3SxrAptyec9NVXx0sxfievc19wW1w@mail.gmail.com>
From: william manning <chinese.apricot@gmail.com>
Date: Fri, 7 Sep 2018 02:45:35 -0700
Message-ID: <CACfw2hi7UK_rU_mw+GvTc5ZVS9sZoKAKoGEVu+hz9DwdjYZX-A@mail.gmail.com>
To: Steve Crocker <steve@shinkuro.com>
Cc: =?UTF-8?Q?Hugo_Salgado=2DHern=C3=A1ndez?= <hsalgado@nic.cl>, dnsop <dnsop@ietf.org>, dns-operations@dns-oarc.net, Mukund Sivaraman <muks@mukund.org>
Content-Type: multipart/alternative; boundary="0000000000009c6e89057544de1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oJWY-IO3DNcV3nwr7616ZzsLfCA>
Subject: Re: [DNSOP] DNSSEC threshold signatures idea
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2018 09:45:42 -0000

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@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@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
>
>