Re: [DNSOP] DNSSEC threshold signatures idea

Hugo Salgado-Hernández <hsalgado@nic.cl> Thu, 06 September 2018 19:53 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 8E25A130F66 for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 12:53:04 -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 CsKDwGn3sJQL for <dnsop@ietfa.amsl.com>; Thu, 6 Sep 2018 12:53:00 -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 E6A82130F72 for <dnsop@ietf.org>; Thu, 6 Sep 2018 12:52:59 -0700 (PDT)
Received: from mail.nic.cl (localhost [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 72A298004B2; Thu, 6 Sep 2018 16:52:57 -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 628218004AA; Thu, 6 Sep 2018 16:52:57 -0300 (-03)
Date: Thu, 6 Sep 2018 16:52:56 -0300
From: Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?= <hsalgado@nic.cl>
To: Steve Crocker <steve@shinkuro.com>
Cc: dnsop <dnsop@ietf.org>, Mukund Sivaraman <muks@mukund.org>, dns-operations@dns-oarc.net
Message-ID: <20180906195256.azwvh3x2adgoab6b@nic.cl>
References: <20180906161252.GA2840@jurassic> <20180906173412.og736bryaeqbwjds@nic.cl> <20180906174926.GA9614@jurassic> <20180906190257.ig6yqgi5fsfepklz@nic.cl> <CABf5zv+-qH+k6Ts6W-+1Z4QsGYYPrtNiqgTL9jgZORcURFQ1vg@mail.gmail.com> <20180906192209.uryzvdyosnjfptmp@nic.cl> <CABf5zv+cLT2ifAmS0Bz3FdcKu4DOVV1mpoZgnZ0YS33d5hYg2g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t4j7azvb66d4vm65"
Content-Disposition: inline
In-Reply-To: <CABf5zv+cLT2ifAmS0Bz3FdcKu4DOVV1mpoZgnZ0YS33d5hYg2g@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Virus-Scanned: ClamAV using ClamSMTP on Thu Sep 6 16:52:57 2018 -0300 (-03)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fs5zg3e94oSigVqr5vgdEQSb-kw>
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 19:53:11 -0000

On 15:25 06/09, Steve Crocker wrote:
> Let me flag a key point.  You said this scheme will *detect* faked
> signatures.  If you want to *prevent* faked signatures, you need additional
> structure.

The orchestrator can detect faked signature pieces when is
merging them, before going live. So for this definition of
"prevent" should be sufficient. If you're referring to
prevent the orchestrator with faking the resulting signature,
I think we're gonna fail preventing but only reacting after
detecting it alive.

Hugo

> 
> Steve
> 
> 
> On Thu, Sep 6, 2018 at 3:22 PM, Hugo Salgado-Hernández <hsalgado@nic.cl>;
> wrote:
> 
> > On 15:08 06/09, Steve Crocker wrote:
> > > How do you prevent compromise of the central service?
> > >
> >
> > For the initial setup a physical ceremony is necessary,
> > to check there's no extra subkeys and for secure transmision
> > of them. But afterwards there's no need. Each node can check
> > the final signature validates with the public key (just like
> > a normal signature), and the plain data should be public
> > (DNSKEY rrset).
> >
> > In this same first ceremony you can also share simmetric
> > keys for the secure transmission of data and signature
> > pieces.
> >
> > The system is fault-tolerant as a subset of nodes can fail
> > and the signing process can be completed, and you can
> > detect faked sub-signatures.
> >
> > Hugo
> >
> > > Steve
> > >
> > >
> > > On Thu, Sep 6, 2018 at 3:02 PM, Hugo Salgado-Hernández <hsalgado@nic.cl>;
> > > wrote:
> > >
> > > > On 23:19 06/09, Mukund Sivaraman wrote:
> > > > > On Thu, Sep 06, 2018 at 02:34:12PM -0300, Hugo Salgado-Hernández
> > 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].
> > > > >
> > > > > Aha so you're the original source :)
> > > > >
> > > > > > 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>
> > > > >
> > > > > So this's implemented as a PKCS 11 provider.. interesting. In my
> > mind I
> > > > > was thinking along the lines of updates to dnssec-keygen +
> > > > > dnssec-signzone + intermediate RRSIG representation using new RR
> > type +
> > > > > zone transfers to share intermediate effects.
> > > >
> > > > In our implementation you'll need a central "orchestrator" who
> > > > creates the first key and split the private pieces to each
> > > > signing node. This same orchestrator later send signature
> > > > requests to each node, collect the signature pieces and
> > > > defines the "consensus" of M/N. Finally, there's an PKCS11
> > > > interface between this orchestrator and the zone signing
> > > > policy machinery (OpenDNSSEC in our setup).
> > > >
> > > > Hugo
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> >
> >

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop