Re: [DNSOP] draft-fanf-dnsop-trust-anchor-witnesses-00.txt

Matthäus Wander <matthaeus.wander@uni-due.de> Thu, 13 February 2014 23:45 UTC

Return-Path: <matthaeus.wander@uni-due.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736BB1A04E3 for <dnsop@ietfa.amsl.com>; Thu, 13 Feb 2014 15:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Level:
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548] autolearn=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 UbFBE4Xo7vRs for <dnsop@ietfa.amsl.com>; Thu, 13 Feb 2014 15:45:46 -0800 (PST)
Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1431A0037 for <dnsop@ietf.org>; Thu, 13 Feb 2014 15:45:45 -0800 (PST)
Received: from [192.168.178.20] (dsbg-4db57a18.pool.mediaWays.net [77.181.122.24]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id s1DNjfme026140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Feb 2014 00:45:41 +0100
Message-ID: <52FD5922.40205@uni-due.de>
Date: Fri, 14 Feb 2014 00:45:38 +0100
From: Matthäus Wander <matthaeus.wander@uni-due.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>, dnsop@ietf.org
References: <alpine.LSU.2.00.1402132050440.18502@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1402132050440.18502@hermes-1.csi.cam.ac.uk>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020203030500020003010400"
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/NnXd54oqn-N06R3GP9IZnkxs1xE
Subject: Re: [DNSOP] draft-fanf-dnsop-trust-anchor-witnesses-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 13 Feb 2014 23:45:49 -0000

* Tony Finch [2014-02-13 21:56]:
> There was some discussion last month about dispersing trust in the root.
> http://www.ietf.org/mail-archive/web/dnsop/current/msg10977.html
> 
> This inspired me to write up a concrete proposal for the
> quorum-of-witnesses idea that I have vaguely suggested several
> times over the last few years.

The proposed approach disperses the trust into which TA to choose and
when to rollover to a new TA. However, it does not disperse the trust
that the TA is not misused and not compromised. If I have to fully trust
the TA private key holder anyway, my personal assessment would be to
trust their TA publication channel as well, e.g. the ones in
draft-jabley-dnssec-trust-anchor.

The problem I see is the asymmetry of roles between the TA private key
holder and the witnesses. The witnesses have no means to assert that the
TA holder does not share the key with their government or anybody else.
To disperse the trust of a key, you would need a threshold cryptosystem
where the TA private key portions are shared among equal peers.

Regards,
Matt

-- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg