[DNSOP] 答复: DNSSEC threshold signatures idea

Davey Song(宋林健) <ljsong@biigroup.cn> Fri, 07 September 2018 04:51 UTC

Return-Path: <ljsong@biigroup.cn>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 08A11130E3D for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 21:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.353
X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CU1f5f0mhW09 for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 21:51:15 -0700 (PDT)
Received: from smtpbgau2.qq.com (smtpbgau2.qq.com []) (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 1B7DF128CE4 for <dnsop@ietf.org>; Thu, 6 Sep 2018 21:51:14 -0700 (PDT)
X-QQ-mid: bizesmtp9t1536295867tayknec0w
Received: from sljpc (unknown []) by esmtp4.qq.com (ESMTP) with id ; Fri, 07 Sep 2018 12:51:06 +0800 (CST)
X-QQ-SSF: 00400000002000F0FLF0B00A0000000
X-QQ-FEAT: nhEjhfUUPITK5p8JqG5I+M/h+y+z6gxet/iFarHxIBFpInfbrYcg5S+S/VY/B d9vW08akiZwTGObe3QjPByKAjcHs8ZKAZVWiFDAuNT5Zu2ZT6c8qVg4O7RMdYumRrLko5Lc NqFQoqRgk4nynYRNEaTvBQhGWWmQ0PEp4kOkGywKvTrfoMGzIOG5LUKyl+DmPUZAIYZJiml 9NriCMFb8iqkSK1SoJXbBQOT+rV9zrcoxxQLxhKSvecV0RBFLK9FarEj81aePgmoMjsXr9w yIj0TzoGOcezG7OFj9rHr+F6U9z9gnz/O8B2HvgohA6Sf/yLBnjFzUIAg=
X-QQ-GoodBg: 2
From: =?gb2312?B?RGF2ZXkgU29uZyjLzsHWvaEp?= <ljsong@biigroup.cn>
To: "'Mukund Sivaraman'" <muks@mukund.org>, <dnsop@ietf.org>, <dns-operations@dns-oarc.net>
References: <20180906161252.GA2840@jurassic>
In-Reply-To: <20180906161252.GA2840@jurassic>
Date: Fri, 7 Sep 2018 12:51:06 +0800
Message-ID: <01b301d44666$640191e0$2c04b5a0$@cn>+9FD6C31F1551386E
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdRF/Iloev/Xbu6KRbuOmGJJQfSl9gAZEiJA
Content-Language: zh-cn
Feedback-ID: bizesmtp:biigroup.cn:qybgforeign:qybgforeign1
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rdpzwA33wAytpad5FkFtpZyo_kQ>
Subject: [DNSOP] =?gb2312?b?tPC4tDogIEROU1NFQyB0aHJlc2hvbGQgc2lnbmF0dXJl?= =?gb2312?b?cyBpZGVh?=
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 04:51:21 -0000

Hi Mukund,

Thank you for proposing here for comments and discussion. I would like to
share more background on this if people are interested. 

Actually I was inspired by several sources. One is the Multisignature
(https://en.bitcoin.it/wiki/Multisignature ) concept from Bitcoin which help
to reduce the risk of wallet keys be stolen.

One is from Yeti work we are doing where Hugo gave me some ideas. In Yeti
testbed, we try to implement the concept of "Share Zone Control" proposed by
PVM in ICANN ITI report. We firstly constructed the root system with 3
signers (3ZSK and 1 KSK) . We would like improve this system with more
fault-tolerant property and less dependency on a central entity. There is a
post I put in Yeti blog (https://goo.gl/7i4NxB ). 

When I survey on this, I learnt some concept of threshold signature
algorithms in the crypto academic field, like BLS , Boldyreva and PBC
(Pairing based crypto). But I'm not a crypto guys . I'm just looking for
mature and reliable crypto tool to fit my case, then we can test and try it
in existing testbed. Maybe people on this mailing list can help.

Best regares,

> -----邮件原件-----
> 发件人: DNSOP [mailto:dnsop-bounces@ietf.org] 代表 Mukund Sivaraman
> 发送时间: 2018年9月7日 0:13
> 收件人: dnsop@ietf.org; dns-operations@dns-oarc.net
> 主题: [DNSOP] DNSSEC threshold signatures idea
> 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
> 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
> 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
> 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
> Instead, N members of a group have some key material each respectively,
> any M (< N) members of the group may work together to prepare RRSIGs by
> using their respective key materials individually, and collaborating to
> 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