[DNSOP] DNSSEC threshold signatures idea

Mukund Sivaraman <muks@mukund.org> Thu, 06 September 2018 16:13 UTC

Return-Path: <muks@mukund.org>
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 E72FA130DE4 for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 09:13:01 -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 4vZDNDooZl-H for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 09:12:59 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9DC126CC7 for <dnsop@ietf.org>; Thu, 6 Sep 2018 09:12:59 -0700 (PDT)
Received: from jurassic (unknown [27.5.246.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 7595032C094E; Thu, 6 Sep 2018 16:12:55 +0000 (UTC)
Date: Thu, 06 Sep 2018 21:42:52 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: dnsop@ietf.org, dns-operations@dns-oarc.net
Message-ID: <20180906161252.GA2840@jurassic>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6DNtUJqAAd4ESL1fk2wWnuARSOc>
Subject: [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 16:13:02 -0000

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