Re: [DNSOP] On trust anchors, roots of trust, humans and indirection
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 30 March 2018 15:04 UTC
Return-Path: <hallam@gmail.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 6B2941270A3 for <dnsop@ietfa.amsl.com>; Fri, 30 Mar 2018 08:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oviMKDK3QKUO for <dnsop@ietfa.amsl.com>; Fri, 30 Mar 2018 08:04:49 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 5038412711E for <dnsop@ietf.org>; Fri, 30 Mar 2018 08:04:48 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id u141-v6so8019202oif.1 for <dnsop@ietf.org>; Fri, 30 Mar 2018 08:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=y8NsNq59YywRVGrvdBjtwQSidFYmP/kp0qx91oe6CLo=; b=Y61xBSri4qwf6eTsoUsZI2hl1PREbkvWSWGR+9JtsALv+bgNiHRGVxCLGUO1TTKhgB po43omDNRrDACRL8Z4NJgmu1n1FhNNxh/FVZMRTrUSDZ9kbe4KzHiB3g6DMdY4fDt8Dk rgZVsjhoCJuYcRI6VbS+dDWwosUr3uMC1l99SsS7eeQyiwLAOoU3f/KkHZ2tustPmsTQ NPfQY29uPLoK21rzP/PF6TR2I1b7H8UdQqdlHa3IAD+hK+VyeJn9qOfTXQgXu9KMLIEe M0AYL00KApMvOwoshUAHByF9CBZXY7vq7lNr+iZf0aky6buOMyUUu7vZwsRFheGhjTVq Pa9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=y8NsNq59YywRVGrvdBjtwQSidFYmP/kp0qx91oe6CLo=; b=keRSf8MIRRXUbMd3UzON2r9D10NzQzQ6N7FYC87T2zOeaQp1ZFGl8vCRdSsaRkDAT3 NxcMyCr26nYIbxtOB0nuaEAHMaQA4u+2f3wl19p3yh+fsPOKJFxDC8DwOu2zbwuuyPrY NKoO6QTlTf7dq7NpMbIQPEsamH/njb2w5ALmvF8e1ydcC92wPwQ0B4K55bCBL9jySyaH 07a6+7gBLFX0Wr7i9rBeetRCFyfs9BFY1nOQmTwIdEKXdabAD1nHOL0kgWSS66m2AY2w d5Innotl/six3tY7NA/LIdi3rMMYHpYYpCk0z6awqAES1aes6agO9UzBv0FGiD+ozXeV ZZjg==
X-Gm-Message-State: ALQs6tBy6w1vmW6EyH2rAhToWZ539kDg8ei39Mim8Pk2K3JLqUk/Ru5h wcSWe24IOwWcZC8qgl94bFTmxqz06EatcW0xu5U=
X-Google-Smtp-Source: AIpwx4/mjQ5Czj6kEejQLT4OrPgJ4TLGJ2AkraAq8tikypDvNyOH18RPOKPGXnKDpAKgIKST7p5hRtTsX23dPudbvbM=
X-Received: by 10.202.64.131 with SMTP id n125mr7489650oia.26.1522422287348; Fri, 30 Mar 2018 08:04:47 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 2002:a9d:233c:0:0:0:0:0 with HTTP; Fri, 30 Mar 2018 08:04:46 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.11.1803301403230.25657@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>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 30 Mar 2018 11:04:46 -0400
X-Google-Sender-Auth: xobrFU3kwMwY7nR0cnHmHT3IJm0
Message-ID: <CAMm+Lwj5JwrOTfWqNX740bgRYFn4k7gAhOB=cm=LYed=0Pu9pQ@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: Michael StJohns <msj@nthpermutation.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113de014a2d1990568a28ff9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zerzpi4jUg1DnPsRRBQUkLz-x9k>
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: Fri, 30 Mar 2018 15:04:51 -0000
It is a hard problem and it is possible that there is actually no solution. All these systems consist of a chain or a graph of signed assertions. There is no intrinsic ground truth in PKI. All that you can do is to define a particular key or set of keys as producing the ground truth for your particular application. There is also a psychological angle. People are uncomfortable with the idea of keys with infinite validity intervals. Yet we know that key rollover mechanisms are the most complex and error prone parts of any PKI. Another problem we face is the question of what a device or application should do if it cannot get an acceptable source of ground truth. A lot of people assume that the answer should be to simply halt. Which is kind of the wrong thing if the device is a pacemaker. ICANN has a mechanism for specifying their ground truth that is ultimately embodied in a sequence of root keys that are created over time. One consequence of that approach is that I cannot build a device today for a 20 year service life using the DNSSEC as ground truth for the PKI. No, don't tell me why that is not a requirement because it is. 95% of all the world's SCADA systems run code that was written in the 1990s and has not had one byte modified since. So don't you dare claim that software updates are essential, that is an ideological position learned from a limited set of experience. But even if we accept the need for updates, where does the ground truth for the updates come from? If you want to produce a device that has a 20 year service lifespan, the only way you can do that is to use a PKI that is expressly designed for that. Which is of course what CableLabs etc. do (or try to). And we need to encourage vendors to take that approach rather than assume that they can apply an off the shelf PKI for their purpose. All the problems of the SHA-1 phaseout in the WebPKI came from groups that had applied it to embedded devices assuming that this would be OK. This is of course the approach that browser and O/S vendors have taken. They do not rely on the DNSSEC or WebPKI for validating updates, they rely on their own PKI that is answerable only to their requirements. ... but what about user requirements? I have a perfectly good 36" plotter I paid $50 for that is just as good as a new $2500 machine for my needs. The only problem being getting round the planned obsolescence of ink cartridge manufacturing being shut down. That is why I have developed my SIN proposal which allows devices to be subordinated to a PKI that is managed by the User/Customer and is within their sole control. Let us say that MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ is the fingerprint of the master key for the enterprise PKI for example.net This then cross certifies the ICANN DNSSEC roots as they are published. Thus the interpretation of the following SIN becomes as robust as the management of the enterprise PKI: example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz Don't want to run the PKI yourself? Get a group of lime minded manufactuers together and run one as a co-op (e.g. Cable Labs). Outsource management, etc. etc.
- [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