Re: [DNSOP] On trust anchors, roots of trust, humans and indirection
Michael StJohns <msj@nthpermutation.com> Wed, 11 April 2018 22:32 UTC
Return-Path: <msj@nthpermutation.com>
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 6C69D1277BB for <dnsop@ietfa.amsl.com>; Wed, 11 Apr 2018 15:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
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 b8ybvu76WH-G for <dnsop@ietfa.amsl.com>; Wed, 11 Apr 2018 15:32:02 -0700 (PDT)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EE812D94F for <dnsop@ietf.org>; Wed, 11 Apr 2018 15:31:55 -0700 (PDT)
Received: by mail-qt0-x233.google.com with SMTP id j17so3991797qtp.1 for <dnsop@ietf.org>; Wed, 11 Apr 2018 15:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=P/uSdOlcDwyItqMKiVVQcGW1wgRODXTRvlo3lPV6l/M=; b=HGBEoUVxaL5EsNusdPV35bjD3Nv9WRCrQxLeK/O8Z58PYjFXViE9aQK8iDCSjuVJg0 CnU2fbGr9T58Pp2eSol+ovRlSBAfsUut6Ud8zlY+PHu8raxq4ssLh2Uz7Mt48C+63zUr 3tDyLUIpGfdwS0hHguA0+cpUxY2/OTJsYL28VUmaomlAKhBSM9x25fdwn6cfG8RGM3rg xPbeyhpgubRBWvNNr32AWpEMc06V1FfcF3RehMaOhX/y1jxGcm2Kx6gD20HQu8hz60bH Zks94BMFFgF7NmYWQZ0p3DNW0VnlUrA3MTpe2mm5O45F2tEMQ5juPniieZ4L/rD3fll0 Eh7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=P/uSdOlcDwyItqMKiVVQcGW1wgRODXTRvlo3lPV6l/M=; b=CO4+eVNwhm5gbZIoxYCjZLlrZD5NnM1Z73b4BM8JHS9z2tXtRJ8i/UuUe33uxFxtaG KDZ+7LVaFJpaLjWWvwqkc73Ya5+KAab3M5Kira/q1hkV9cN5RkpefYTu09g8GnctXOa0 Hh16M8qDSFR9KS++MnaPXs5+1xPv8p7vZ5lzeb6iVL9hoOPZ2291LTAUkTqF3VrvKuBS 2RiimA3T5EfLpvTecGJUNpyz7fnx/+rVIy6MpNJgKeJB+JENP+eRiUeIoUzAfsPPn+T2 V2LlnRIxfzlTU8J4xCY49+c1PhHFI6jlWseCb/T91/uiu9Lv2d6ZmmpSQw2CK32xiEgl iXig==
X-Gm-Message-State: ALQs6tCLRXql887v5afuJt+AJ6KUAscQzCM3RYHSg2Jp1UZ0NfDMYC/b chjBbh1vfVDGBdDOl/ccIK4Ki5KY
X-Google-Smtp-Source: AIpwx4/3RVg6+43gv9RRlPpnUeVQhNDhlAD3pcF7dOIrqBOO2llhDoQTwiLng1D6sy1w5b/XaDyJWQ==
X-Received: by 10.200.1.79 with SMTP id f15mr10263503qtg.177.1523485914357; Wed, 11 Apr 2018 15:31:54 -0700 (PDT)
Received: from ?IPv6:2601:152:4400:4013:c8b9:a87e:20d2:7f1e? ([2601:152:4400:4013:c8b9:a87e:20d2:7f1e]) by smtp.gmail.com with ESMTPSA id r64sm1639327qkf.50.2018.04.11.15.31.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 15:31:53 -0700 (PDT)
To: Tony Finch <dot@dotat.at>, Paul Vixie <paul@redbarn.org>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>
References: <a9bd794f-41bc-9593-db0d-5424c84431a3@nthpermutation.com> <alpine.DEB.2.11.1803281105310.10477@grey.csi.cam.ac.uk> <cfc66d01-c8ce-b605-8074-8400b377f414@nthpermutation.com> <alpine.DEB.2.11.1803301403230.25657@grey.csi.cam.ac.uk> <CAMm+Lwj5JwrOTfWqNX740bgRYFn4k7gAhOB=cm=LYed=0Pu9pQ@mail.gmail.com> <alpine.DEB.2.11.1803301700030.30706@grey.csi.cam.ac.uk> <5ABE641F.6020501@redbarn.org> <alpine.DEB.2.11.1803312346270.5300@grey.csi.cam.ac.uk>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <9705c15e-b65c-8d29-e35f-8849d05abe2e@nthpermutation.com>
Date: Wed, 11 Apr 2018 18:31:43 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1803312346270.5300@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p04PVo6g7MqduifWnrwIWJtIZRA>
Subject: Re: [DNSOP] On trust anchors, roots of trust, humans and indirection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 11 Apr 2018 22:32:04 -0000
Sorry its taken me so long to get back to this. On 3/31/2018 7:09 PM, Tony Finch wrote: > There are a few pertinent differences between trust anchor witnesses and > the undeployed RFC 5011 many-keys setup: > > * in RFC 5011 each key is completely trusted, whereas no witness is > trusted; compromise of an RFC 5011 key compromises the whole system, > whereas compromise of a witness is equivalent to unavailability (up > to the quorum size); > > * RFC 5011 requires close co-operation between key holders for updating > the DNSKEY RRset and its signatures, whereas trust anchor witnesses > operate independently. > > * Part of the circular dependency loop is accurate time, and it's easy to > get trust anchor witnesses to tell you the time as well; not so easy > purely within the DNS. > > Tony. You forgot: * A 5011 trust system is maintained as part of the root zone - as long as the root zone is maintained, the 5011 trust system is maintained. * The "requires close cooperation" bullet is just wrong. It turns out that the SPECIFIC mechanism they're currently using requires everyone to show up in a certain place, but that's an artifact of process, not of protocol. (Happy to sketch out a different protocol - its pretty straight forward). * But time also requires a source of trust - if you can spoof enough witnesses, you can spoof time. In any event, time is irrelevant at the system level- each relying party is responsible for figuring out its source of time - in both systems. One of the reasons I went away was to try and figure out how to accurately analyze your approach. Before you start down this approach, you need to figure out at least a few parameters: 1) How many total witnesses? (Since you won't be maintaining the system, these are all there ever will be) 2) How many of the witnesses are enough to assume trust? 3) How long do you want this system to work? It turns out that the lifetime of an un-maintained M of N system has exactly the same characteristics as a nuclear decay analysis. E.g. Given a starting population of N, an ending population of M and a period of Y, what is the half-life of the system? From the half-life of the system, you can calculate the minimum average mean time to failure of any given witness. And its nice that there is this http://www.calculator.net/half-life-calculator.html online. So let's start out with a 3 of 10 system with a required lifetime of 20 years (240 months). The half-life of the system is 138.2 months and the average required MTTF is 199 months or about 16.5 years. That means that you have to expect that any given witness will be around and available AT the place it was originally available at for around 17 years. It gets better with more witnesses, say 3 of 15: 149 months or about 12.5 years MTTF. That's a bit better, but that's an average - you still have to ensure that 3 of those systems will be around for the 20 years, and you have to ensure they aren't compromised in the mean time. But it gets worse if you increase the number of required witnesses - say 5 of 15 - 218 months or a required average MTTF of 18.2 years for that set of 15 witnesses. Now you could add a maintenance protocol, and the ability to add and delete witnesses, but guess what - you end up looking like 5011, but with the problem of how to manage the trust set of the trust set. This reminds me of the "Turtles all the way down" recursion. Later, Mike
- [DNSOP] On trust anchors, roots of trust, humans … Michael StJohns
- Re: [DNSOP] On trust anchors, roots of trust, hum… Tony Finch
- Re: [DNSOP] On trust anchors, roots of trust, hum… Michael StJohns
- Re: [DNSOP] On trust anchors, roots of trust, hum… Tony Finch
- Re: [DNSOP] On trust anchors, roots of trust, hum… Phillip Hallam-Baker
- Re: [DNSOP] On trust anchors, roots of trust, hum… Tony Finch
- Re: [DNSOP] On trust anchors, roots of trust, hum… Paul Vixie
- Re: [DNSOP] On trust anchors, roots of trust, hum… Tony Finch
- Re: [DNSOP] On trust anchors, roots of trust, hum… Paul Vixie
- Re: [DNSOP] On trust anchors, roots of trust, hum… Tony Finch
- Re: [DNSOP] On trust anchors, roots of trust, hum… Paul Vixie
- Re: [DNSOP] On trust anchors, roots of trust, hum… Phillip Hallam-Baker
- Re: [DNSOP] On trust anchors, roots of trust, hum… Michael StJohns