Re: [Iot-onboarding] what can pinned-domain-cert actually pin?

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 30 August 2019 20:37 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33711209A0 for <iot-onboarding@ietfa.amsl.com>; Fri, 30 Aug 2019 13:37:42 -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, SPF_HELO_NONE=0.001, 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 Y-jXeNj14qck for <iot-onboarding@ietfa.amsl.com>; Fri, 30 Aug 2019 13:37:40 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65E0120922 for <iot-onboarding@ietf.org>; Fri, 30 Aug 2019 13:37:40 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 82BC8380BE; Fri, 30 Aug 2019 16:36:26 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 106A6B1C; Fri, 30 Aug 2019 16:37:39 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Owen Friel \(ofriel\)" <ofriel@cisco.com>
cc: "iot-onboarding\@ietf.org" <iot-onboarding@ietf.org>
In-Reply-To: <CY4PR1101MB22789600E60FFA85053CEFDFDBBD0@CY4PR1101MB2278.namprd11.prod.outlook.com>
References: <2693.1566923418@localhost> <0100016cd46359e7-8c844438-dc7a-45df-9868-ba0957bcc89f-000000@email.amazonses.com> <CY4PR1101MB22782817AA5A55C3812A3EEFDBA30@CY4PR1101MB2278.namprd11.prod.outlook.com> <12883.1567010221@localhost> <CY4PR1101MB22788341CC8F7D5EBB72C33EDBA30@CY4PR1101MB2278.namprd11.prod.outlook.com> <16322.1567104534@localhost> <CY4PR1101MB22789600E60FFA85053CEFDFDBBD0@CY4PR1101MB2278.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Fri, 30 Aug 2019 16:37:39 -0400
Message-ID: <2318.1567197459@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/aZYcoAjXISm38KWf6ax8fdlcuW8>
Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2019 20:37:43 -0000

Owen Friel (ofriel) <ofriel@cisco.com> wrote:
    >> > Regardless, LE root rotation is not at issue here. The issue is what
    >> > happens if an operator wants to move from GoDaddy to
    >> > LetsEncrypt. Either (i) all existing vouchers are dead or (ii) we need
    >> > multiple pinned-domain-cert entries. And maybe (i) is fine and if an
    >> > operator wants to change root CA providers, then the operator sucks it
    >> > up and reissues all nonceless vouchers.
    >>
    >> We could also consider pinning the public key of the Registrar.
    >> This is how constrained-BRSKI works.  There are crypto-hygiene issues here,
    >> but maybe it's better than putting more fragile logic into a device that might
    >> remain on a shelf for many years.

    > Right. You could pin the raw public key and then the RA EE cert could
    > rotate provided the key remained the same. Obviously any changes to the
    > key (length, algorithm, etc.) invalidate vouchers.

Depending upon what kind of processing we could assume on the pledge
(thus the tussle), one could imagine that if the key/algorithm/etc. became
too weak, that one could use the key to sign another stronger certificate
to be used going forward.

This doesn't make the key stronger suddenly, but unless the key is actually
compromised, it allows the old nonceless vouchers to be used in the future.

My take is that this is a lot of code effort in the Pledge.
If the Enterprise/Registrar would cause to be operated a long-lived private
CA, then the problem goes away.   It doesn't have to be operated by the
Enterprise itself; it could be operated by a service provider that they
trust.  In effect, it's just a new form of MASA.

I think that this is really the right way to go: to allow chains of
vouchers pinning keys, which can then be used to issue new vouchers
(which could pin new keys).  This solves the long-term problems you have
mentioned, and removes the external dependancy upon a MASA.... by createing a
new dependancy upon an internal MASA.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-