Re: [DNSOP] On trust anchors, roots of trust, humans and indirection
Tony Finch <dot@dotat.at> Sat, 31 March 2018 23:09 UTC
Return-Path: <dot@dotat.at>
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 AD366126DFB for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 16:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 erFfElc8vgRr for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 16:09:12 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 B88D7126CE8 for <dnsop@ietf.org>; Sat, 31 Mar 2018 16:09:12 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:60479) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1f2PcT-000uB3-eO (Exim 4.89_2) (return-path <dot@dotat.at>); Sun, 01 Apr 2018 00:09:09 +0100
Date: Sun, 01 Apr 2018 00:09:09 +0100
From: Tony Finch <dot@dotat.at>
To: Paul Vixie <paul@redbarn.org>
cc: "dnsop@ietf.org" <dnsop@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <5ABE641F.6020501@redbarn.org>
Message-ID: <alpine.DEB.2.11.1803312346270.5300@grey.csi.cam.ac.uk>
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>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wesknpaZp4HzZjML1NMgqV9y-WI>
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: Sat, 31 Mar 2018 23:09:15 -0000
Paul Vixie <paul@redbarn.org> wrote: > > devices which cannot be updated by their makers must expire Definitely. I think the problem that most concerns me is the device that spends 3 or 6 months in a box between manufacturing and deployment, and which expects to do a software update when it is plugged in, but there was a DNSSEC root key rollover in the intervening time. At the moment the only solution we can offer is to turn off DNSSEC until the device has done enough updating to be able to turn DNSSEC on again. Which is to say, DNSSEC is a hindrance not a help. This is an embarrassing failure. RFC 5011 with long-lived standby keys helps with this problem, but it has not been deployed that way, and there are good engineering reasons for not changing that, and no desire to try to do so. My aim for the trust anchor witnesses is to cut the circular dependency loops as simply as I can, so that when a device boots and finds the world has changed around it, it has a straightforward way to get itself working. 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. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Sole: Southeast becoming cyclonic, 6 to gale 8. Moderate or rough. Rain or showers. Moderate, occasionally poor.
- [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