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, 07 Sep 2018 02:45:35 -0700
Message-ID: <CACfw2hi7UK_rU_mw+GvTc5ZVS9sZoKAKoGEVu+hz9DwdjYZX-A@mail.gmail.com>
To: Steve Crocker <steve@shinkuro.com>
Cc: Hugo Salgado-Hernández <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 > >
- [DNSOP] DNSSEC threshold signatures idea Mukund Sivaraman
- Re: [DNSOP] DNSSEC threshold signatures idea Hugo Salgado-Hernández
- Re: [DNSOP] DNSSEC threshold signatures idea Mukund Sivaraman
- Re: [DNSOP] DNSSEC threshold signatures idea Steve Crocker
- Re: [DNSOP] DNSSEC threshold signatures idea Hugo Salgado-Hernández
- Re: [DNSOP] DNSSEC threshold signatures idea Steve Crocker
- Re: [DNSOP] DNSSEC threshold signatures idea Hugo Salgado-Hernández
- Re: [DNSOP] DNSSEC threshold signatures idea Steve Crocker
- Re: [DNSOP] DNSSEC threshold signatures idea Michael StJohns
- Re: [DNSOP] DNSSEC threshold signatures idea Hugo Salgado-Hernández
- Re: [DNSOP] DNSSEC threshold signatures idea Steve Crocker
- [DNSOP] 答复: DNSSEC threshold signatures idea Davey Song (宋林健)
- [DNSOP] 答复: DNSSEC threshold signatures idea Davey Song (宋林健)
- Re: [DNSOP] DNSSEC threshold signatures idea william manning
- Re: [DNSOP] DNSSEC threshold signatures idea Warren Kumari