Re: [DNSOP] DNSSEC threshold signatures idea

Hugo Salgado-Hernández <hsalgado@nic.cl> Thu, 06 September 2018 17:34 UTC

Return-Path: <hsalgado@nic.cl>
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 8FD94130EC8 for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 10:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9riCOViVioZ for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 10:34:23 -0700 (PDT)
Received: from mail.nic.cl (mail.nic.cl [IPv6:2001:1398:1::6008]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD72130DDA for <dnsop@ietf.org>; Thu, 6 Sep 2018 10:34:16 -0700 (PDT)
Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 1493F8003D2; Thu, 6 Sep 2018 14:34:14 -0300 (-03)
Received: from nic.cl (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 mail.nic.cl (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?= <hsalgado@nic.cl>
To: Mukund Sivaraman <muks@mukund.org>
Cc: dnsop@ietf.org, dns-operations@dns-oarc.net
Message-ID: <20180906173412.og736bryaeqbwjds@nic.cl>
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: <https://mailarchive.ietf.org/arch/msg/dnsop/RN01bEugxGjowyBrG_E5JhwLZTM>
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 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.

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
>