Re: [DNSOP] DNSSEC threshold signatures idea

Steve Crocker <steve@shinkuro.com> Thu, 06 September 2018 18:14 UTC

Return-Path: <steve@shinkuro.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 90F06130E5C for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 11:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.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 AaN9qPQPBuOf for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 11:14:47 -0700 (PDT)
Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 46F35130E1A for <dnsop@ietf.org>; Thu, 6 Sep 2018 11:14:47 -0700 (PDT)
Received: by mail-yw1-xc2f.google.com with SMTP id w202-v6so4434602yww.3 for <dnsop@ietf.org>; Thu, 06 Sep 2018 11:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sBYF5RGA3y3IhEPb/HThT8ZzVfAAIMgOuuMt66v8sYY=; b=AutJl5fD8NCF9moIzl7mfgKf7W+dxoJLgujLnzCn7WtUKtkxmE3N2aSCudfbesNB3Q Mc3jtERX/UBHehnAcUovyPVO7CLnTb8tFz3eqDdIfGWeN76KH056Zm4/N51XAkWXZrTs 4aKJlPfYe8696H/D0JpS/sG5FvD4AwHtcO7DdfFznBGhRl8SiW4QznCCOMn4kBpUw/IJ H6yel5JIfAETOO2WALyJJLH8dgYsmVHVWB7+S+JHoI+QaokeWGk/5H1rGksczJdOwGbU addkzrvP/HxTh04tFna5F91E0+0V6Ka+lamqT3S0kk1dd7wZN7YMoQyAx+3JAUUkWL5E yhJw==
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=sBYF5RGA3y3IhEPb/HThT8ZzVfAAIMgOuuMt66v8sYY=; b=CDZoB88YnT0jWTmPJU3txEYop3fSXcDbFOhIZwR0g6R7FNG3XghN0hi/+XGWj+ofTx ZG1fBB2xmj8sFzE5lHj9ZkBSoTD2K9gna2grWN5DtjQn4IGBe3rWG9+gQXPQBKWU7h9n pQqbaLUJasI+6coJGPzuIdJkxK1pLIglOreZ5xCrCIZIVVYqjTwgHZWscGVjTdf5gML3 S5JE+rvrFjzkHZDWtmucI9Iwhuq1Z5D2IerZR0A1EXAsFfIfxwUA2nOe5rl4WukoXr0E Cy2Dz9jMD4u8wWHkqIKThHZQsRlVUGGr05+memyxjR7lMCr3eCMcAxIdaJRGJi4f/Ksp /T6A==
X-Gm-Message-State: APzg51DGitP0kwc7o5ilR8WZX/fizg01DbtScv9hRpL16ACYCqpGqVp1 mkwQzNwD6GdijSj/W6GyP71p8LlFdVePCJKfKPe0/Q==
X-Google-Smtp-Source: ANB0VdZ2C3NtRRRei/R3Vk+QNs1+G+UJ6N6BP9EaTN/+kGYPtlt13mwb+Owf1UWToaccRn9m0YvLohXvz1YxlAWOQfQ=
X-Received: by 2002:a81:ac27:: with SMTP id k39-v6mr2293463ywh.341.1536257686039; Thu, 06 Sep 2018 11:14:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:5d0e:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 11:14:44 -0700 (PDT)
In-Reply-To: <20180906173412.og736bryaeqbwjds@nic.cl>
References: <20180906161252.GA2840@jurassic> <20180906173412.og736bryaeqbwjds@nic.cl>
From: Steve Crocker <steve@shinkuro.com>
Date: Thu, 6 Sep 2018 14:14:44 -0400
Message-ID: <CABf5zvKPhX_t8oHJmsLEB3SxrAptyec9NVXx0sxfievc19wW1w@mail.gmail.com>
To: =?UTF-8?Q?Hugo_Salgado=2DHern=C3=A1ndez?= <hsalgado@nic.cl>
Cc: Mukund Sivaraman <muks@mukund.org>, dnsop <dnsop@ietf.org>, dns-operations@dns-oarc.net
Content-Type: multipart/mixed; boundary="000000000000a9aa27057537dd3c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IGGJQz2vMUqQaS_cZ1RdnOSkWng>
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: Thu, 06 Sep 2018 18:14:52 -0000

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/
> presentation-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
>
>