Re: [DNSOP] DNSSEC threshold signatures idea

Hugo Salgado-Hernández <> Thu, 06 September 2018 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FD94130EC8 for <>; Thu, 6 Sep 2018 10:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F9riCOViVioZ for <>; Thu, 6 Sep 2018 10:34:23 -0700 (PDT)
Received: from ( [IPv6:2001:1398:1::6008]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9AD72130DDA for <>; Thu, 6 Sep 2018 10:34:16 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 1493F8003D2; Thu, 6 Sep 2018 14:34:14 -0300 (-03)
Received: from (unknown [IPv6:2001:1398:4:6:fab1:56ff:fed0:2618]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 040778003B0; Thu, 6 Sep 2018 14:34:14 -0300 (-03)
Date: Thu, 6 Sep 2018 14:34:12 -0300
From: Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?= <>
To: Mukund Sivaraman <>
Message-ID: <>
References: <20180906161252.GA2840@jurassic>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rgxduzyetkvydw2f"
Content-Disposition: inline
In-Reply-To: <20180906161252.GA2840@jurassic>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Virus-Scanned: ClamAV using ClamSMTP on Thu Sep 6 14:34:14 2018 -0300 (-03)
Archived-At: <>
Subject: Re: [DNSOP] DNSSEC threshold signatures idea
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Sep 2018 17:34:26 -0000

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.


[2] <>
[3] <>
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:
> 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